There is a high chance that you attend or have attended an inefficiently-run stand-up. I have seen various stand-up styles over the years. Sadly, most of the roughly 2000 stand-ups I attended were unproductive. Mildly put, most were status reports for some manager or higher up.
Over the years, I have tweaked my views on productive stand-ups and crafted a pattern that has been heavily influenced by the Toyota Kaizen process. This post describes a new approach to make stand-ups engaging, efficient and effective. This style assures a 10-minute stand-up for a team of 10.
Stand-ups are broken
It’s 11am so you walk to the corner for the daily stand-up. Your colleagues are already there, and you are the first to go today. You quickly utter a few sentences about what you did yesterday and what you plan to do today. Thereafter, you flip out your phone and wait for the stand up to be over.
The scenario above is an oversimplification, but interminable stand-ups are common. Disinterested attendees look at their phones or engage in small talk while waiting for the ordeal to be over.
Why even have stand-ups?
Stand-up meetings provide a means of delivering optimal output and rallying the team around goals. Thus, the focus should be on completing the most essential work efficiently and effectively.
The conventional stand-up style requires answering three questions:
- What did you do yesterday?
- What do you plan to do today?
- Are you blocked?
A set-up like this reinforces the habit of talking when it’s your turn and looking at your phone at other times. Why even have stand-up if the team only ends up going through the same monotonous routine daily? Everyone can save time by updating their statuses asynchronous (assuming there is a tracking board).
Another flaw of stand-ups is concentrating solely on the 3 questions without tracking progress towards the team’s goals. Tracking boards (software or whiteboard) provide a bird’s eye view of the team’s situation and reveal insights.
Efficiently run stand-ups are not status reports for some manager; they help the entire team identify blockers, unplanned work and validate progress. They provide options for restoring derailed projects, shielding developers from unforeseen work and establishing cultural expectations.
How to make stand-ups work
There are three pillars:
- Visualizing all work in progress.
- Signals that trigger action.
- Team-wide understanding of practices, expectations and culture.
These three pieces provide mutually-reinforcing relationships that accelerate team productivity.
Visualizing all work in progress
There are multiple tools for tracking work (e.g. Azure Dev Ops, Github, Asana, Trello, etc.). Feel free to use any tool that helps your team surface work; even if it is sticky notes on a wall.
Here is my favourite board layout (I use Azure Dev Ops mostly).
The board
What do the board columns mean?
The columns should show how the team does work with each card representing discrete work that delivers value.
| Column | Description |
|---|---|
| Untriaged | A backlog of potential work for future sprints. Work in this column has neither been planned nor prioritized |
| Triaged | Vital work to be completed in the current sprint. Triaged items will be activated as soon as engineers finish in-progress work. The cards in this column are ordered by priority with the most critical work at the top. |
| Active | This is work that the team is currently focused on, i.e. in-progress items. |
| Reviewing | This column captures peer reviews such as code reviews and design reviews. Ideally, all items get examined by fresh pairs of eyes to catch gaps, reduce familiarity bias and spread knowledge. |
| Testing In production | This penultimate stage verifies that expected outcomes for work match production usage by real customers. Some might consider a feature done after check-in, test automation signoff or QA signoff. From experience, there is no place like production to guarantee correctness. |
| Done | Once a work item moves through all the columns, it can be truly considered done. This technique helps to avoid rework and having to context switch 2 weeks later to revisit a bug. |
Signal: Colour code unusual states
Colours catch the eye and are a powerful tool to make silent distractions scream. I use colours heavily to highlight unwanted distractions like unplanned work, blocked work or stale work that has stopped moving. Because the cards stand out, this generates the right questions and helps the team focus on removing blockers.
| Colour | Indicator | Symptom |
|---|---|---|
| Red | Blocked | A lot of blocked work signifies sub-optimal engineering systems and/or processes. |
| Orange | Unplanned | A lot of unplanned work creeping unto the board implies a flawed planning process, unpredictability, or being too ambitious. The team is getting drawn in multiple directions so consider limiting work and addressing some of the unpredictability. |
| Grey | Stale | A lot of stale work indicates value inventory piling up. Is the team overstretched? Are there other reasons e.g. blockers or disruptive unplanned work? |
Using the Kanban board to Run the stand-up
This section describes using the columns and colours to facilitate efficient stand-ups. The goal is to build a self-regulating process ensuring uninterrupted optimal value delivery and guaranteeing quick detection and remediation of issues.
Simply put: move work as fast as possible from left to right with the highest quality bar. Start the stand up with talking about the rightmost item (ideally it is supposed to be the highest priority and getting it done means a win).
Start with the rightmost items
Start stand-ups by focusing on the item in the rightmost column (the column closest to the Done bucket, e.g. testing in production in the example above).
Here is why – assuming the team starts on the highest priority items at any given time. Items in columns to the right indicate high-value deliveries that are closer to completion. Why should an engineer start on new tasks rather than completing nearly-finished work?
Culture of finishing work – the team moves to a culture of completion over starting new things. This helps to curb the natural tendency to jump on the next shiny new thing. Over time, the team’s throughput increases since there are fewer distractions.
Context switching is expensive and focusing on fewer things mitigates the side effects. Also, truly completed work rarely resurrects, this saves the team from having to revisit old items.
How long should stand-up last?
The stand-up should not last longer than 15 minutes for a team of about 12 (e.g. 8 devs, 2 PMs, 2 designers). In the best scenarios, 10 minutes should be more than enough.
The table below describes common causes for extra-long stand-ups and suggests solutions.
| Root cause | Solution |
|---|---|
| Too much work-in-progress | Limit work in progress |
| Non-pertinent questions from stakeholders | Use a different approach/meeting to provide answers to stakeholders |
| Getting into the details | Use the parking lot for deep dives and analysis |
The only exception to this is a brand new team. The first few stand-ups can run long as the team jells, over time, the time spent reduces until it falls under 15 minutes.
Team Culture: The most important part of getting this to work.
The team has to share a common approach to work to make this style work. A collective understanding of expectations, work states and values leads to emergent and joint accountability.
The following steps describe steps to make this work out:
- Map columns to how work gets done: The board should capture all the work phases for your team. This might include designing, reviewing, coding, testing, and deployment. For example, a testing phase that validates production behaviour can be the threshold for considering work as done.
- Ensure all work shows up on the board: Every single piece of work should be tracked on the board. The board should show all known work at any point in time. Thus, everyone can see what the team is working on at any time. Unplanned work spreads silently like an invasive weed infestation; it is usually too late to do anything but scramble when the infestation’s scale becomes obvious. Suddenly, all engineers get mired in random tasks, and the team’s forward momentum slows to a halt. Untracked work is dangerous for the following reasons:
- The parasitic nature of unplanned work impedes planned work. Since these tasks are usually neither necessary nor urgent, precious resources and efforts are expended on matters that do not contribute to the bigger goal.
- Context switching is costly. Engineers get overwhelmed and frustrated as there are too many irons in the fire and multiple distractions.
- Enforce Work In Progress (WIP) limits:Limiting the amount of WIP helps the team focus on the most important things. Having too much WIP leads to thrashing and inefficiency due to context switching. Rethink what is essential to the team:
- Is the team spread too thin?
- Is everyone working on the most important projects? What can be cut? Saying no can be difficult, but it is imperative since it precipitates the most essential things and whittles off the non-essentials.)I have found a WIP limit of 1.5* team size to work well (e.g. for a team of 8, the WIP limit would be about 12).
- Use swim lanes if your team has multiple parallel efforts. Even at this, try to limit the work in progress by swarming or mob programming.
- Finish committed work before picking new projects: If the team keeps starting on new projects, nothing will get completed. Infuse a culture of finishing what is started. Spare no effort at minimizing costly context switches which is a high price to pay for everyone (engineers, managers, customers etc.). Unforeseen events might require the team to pivot to a new business priority. In such scenarios, ensure the team captures the current context before switching to the higher priority work. Half-finished projects require continuous monitoring and drain team efficiency. Stabilize deprioritized work before pivoting, this makes resurrecting such tasks effortless in the future.
Optimizing team performance by leveraging the 3 pillars
Here are some suggestions on integrating the board, the signals and culture to build a high performing team.
- Address blockers: The tool should reveal the team’s state and show if the team gets blocked often. Try to fund team-wide efforts to remove these blockers and smoothen value delivery. Whenever I see many reds on the board, that triggers some investigation.
- Prune unplanned work: If the team constantly gets distracted, it becomes crucial to identify and fix the upstream causes of distractions. Start by allocating a buffer to accommodate interruptions and build on that by identifying those root causes and removing them. A past team had a constant deluge of unplanned high-priority work every sprint; this seriously impacted our ability to deliver on our planned work. We started by allocating enough buffer to address unforeseen disruptors and then started engaging partner teams and leadership to address the root cause.
- Set a high-quality bar: Ensure the team ships high-quality code by minimizing rework. The introduction of an explicit quality check before completing work goes a long way in reducing rework. A feature is not done when the pull request is merged, it is actually done when it behaves as expected in production.
- Smoothen throughput through work phases: Signs of a bottleneck: constant pile-up of work and/or exceeding WIP limits. Fixing this can be counterintuitive – address the swarm by reducing the WIP limits on upstream work phases over-producing output. Empty columns signify an efficiency vacuum; i.e. upstream columns are not producing enough output for downstream consumers.
Frequently Encountered Scenarios
- Everything is important and needs to be done: Ensure that the team’s work aligns to the org goals – avoid investing in work that should not be done. Efficiently processing ineffective tasks achieves no goals (i.e. 100% of 0 is still 0).
- Should stand up be every day? I suspect less frequent stand-ups would work great for a high performing team. It takes time to establish the culture and blend so daily stand-ups can be started with and then the frequency tweaked as fits.
- The team gets a lot of random asks: The inefficiencies can be rooted out by observing and studying patterns of work. This makes it possible to apply targeted solutions at the pain points.Ensure all unplanned work shows up on the board. Add a work phase (or tag) for tracking the impact of incidental work and gather information over a few weeks. Eventually, the effect and source of such distractions will become evident. With this knowledge, you can form strategies to prevent unplanned work or at least mitigate.
- Work skips several columns: Work that zips across columns or skips columns might be missing out on some checks – ask questions. Is it truly done? Was it improperly estimated or planned?
- Colourful boards are a red flag: A multicoloured board means the team is spread too thin, frequently distracted or blocked.
Conclusion
As leads or managers, use the 3 pillars to spot inefficient work patterns or blockers and immediately address them.
It is easy to start new things, it is hard to complete committed work – don’t let promises go unfulfilled, complete what you start.
When run well, stand-ups are incredibly powerful at driving culture and helping teams achieve a high-performance culture.
Similar Posts
CodeKraft 
Wen book? 🙂
LikeLiked by 1 person
Some day soon? :)
LikeLike