Running a Kanban Standup Meeting

Scrum Standups: A Refresher

Engineers working in teams that use Scrum should be familiar with the format of a daily standup meeting. Every developer has to answer three questions:

What did you get done yesterday?
What will you do today?
Is there anything getting in your way?

The goal of a Scrum standup meeting is to contribute to the success of the current iteration of work (usually described as a “sprint” and lasting a week or two). During that time, the team stays focused on delivering an agreed set of features and fixes. To be effective, a standup meeting will help build awareness of the team’s progress, remove blockers and ensure that everyone is working on the right thing. And it has to do all of those things in only a few minutes so that everyone can get back to actually doing real work.

Using this type of meeting agenda for daily meetings helps the team stay coordinated while sprinting to the finish line over the iteration’s duration. Meeting the commitments made for the current iteration is the top priority.

Kanban vs. Scrum

Kanban is a system of organizing and tracking work items to ensure a smooth, predictable flow of output at all times. While Scrum is quite prescriptive about ceremonies and process, Kanban encourages teams to determine the best way for them to organize and communicate. Kanban teams are empowered to do what’s best to produce shippable results at a constant and steady rate. Working in this manner allows the team to have high-quality feedback loops with their users and learn about the impacts of their decisions soon after they’re made.

Kanban is about being flow-focused, not sprint-focused. The goal is to deliver results at a steady rate and that’s done by accurately tracking reality, reducing queues, limiting work-in-progress (WIP), fulfilling dependencies and removing impediments.

Focusing on Flow

Imagine a hypothetical team using a centralized source code control system for their project. Let’s say that the source code control system is accidentally disabled, but only one senior member of staff — currently away on vacation — has the permission to get it back up and running again. The team might be able to code for a little while with their local copies of the source code, but soon they will be unable to check in their changes for others to see.

A healthy Kanban team would spot the future flow problems immediately. Even though developers wouldn’t be immediately blocked from coding and building on their own machines, an impediment like an inoperable source code system will be quickly detected as the flow-killer that it is about to become. Kanban encourages teams to immediately fix potential problems like this.

This example highlights a number of flow-related issues: a growing queue, an impediment to delivery and a critical dependency on an unavailable resource. Kanban teams immediately swarm to resolve these kinds of issues and get things flowing again. Once things are moving along, they might decide to run an immediate retrospective on the situation and put in place measures to prevent it happening again. In this example, they might end up giving multiple people the ability to fully administer the system.

Are Standups Required by Kanban?

There is no document or standard that defines what a “Kanban standup” is. It’s something a Kanban team may choose to do, if they feel it would help them optimize their flow. Importantly, Kanban teams don’t even have to run a daily standup if they feel it wouldn’t help. They can do whatever works for them: chat on Slack about their work, move post-it notes around a whiteboard, not meet at all, whatever they wish.

Our Kanban Standup Agenda

The Conjur engineering team uses Kanban, and we currently choose to run daily standups. Our daily meetings follow this agenda:

We review our Kanban board by checking each column from right to left. We start with the work stages closest to “Done” and make sure that the state of all cards is accurate.
We look for any flow problems: growing queues, bottlenecks, impediments, high WIP.
We check that everyone has something to work on until we next meet and that there’s sufficient backlog for them to pull from if they finish their current work.
We ensure that there’s at least one internal improvement task in progress.
Any untracked work items (which we call “dark matter”) are raised and then put on the board.
We check for people having potential dependencies on others later in the day and resolve the dependencies before they stall a developer and become a flow problem.
We minimize potential interruptions for the team until the next standup. This may result in people declining to attend some meetings or deciding to take their email and chat clients offline for some lengthy concentration time.
We verify that nobody on the team is having to work late hours, because that would be unsustainable.

We practice kaizen (continuous improvement) on our daily standup agenda format. The format has changed many times since we started doing Kanban standup and always because of the team’s feedback. For example, our daily standup started life as an asynchronous chat-based meeting on Slack, but we found that the value of a single in-person daily meeting greatly outweighed the effort spent running it synchronously.

We are usually able to keep our meeting length to 15 minutes or less and we are pretty disciplined about preventing bikeshedding. Since we also forbid any meetings on Fridays, we don’t hold a standup on that day at all. So far, the team generally reports Fridays to be their most productive day of the week.

Finally, unlike Scrum, anyone is allowed to ask questions during the meeting if they feel it’s important to do so. There are no restrictions on who can participate, because we prefer that information be shared as needed. More complex discussions are quickly encouraged to be taken to another more appropriate forum.

Standups and Strategy

Kanban is not a strategic panacea. Like Scrum and other agile systems, Kanban helps teams organize their software delivery process and reduces the cost of “pivoting” to change product direction. But, while both methods are helpful in a tactical sense, they are incomplete without a solid strategy to guide them for the long term. Agile teams still need a shared mission, vision and strategy to frame their objectives.

Paired closely with a focus on business outcomes, Kanban teams can be superbly effective by driving constant small-batch delivery and generating frequent feedback from users. Having a strong strategic focus will also make daily meetings run smoothly, as they will be naturally anchored to the broader goals of the group. Conversely, if your daily Kanban standups are messy and disorganized, it may mean that your strategy isn’t fully formed or, perhaps, it hasn’t been communicated effectively to the team.

Daily team meetings have been around long before Scrum and Kanban and, as humans, we naturally gravitate to them to coordinate our work. They can be superbly effective for Kanban teams as a way to focus the group on optimizing for flow and smooth delivery. Just remember that a Kanban team can choose to do that in many ways, not just by making team members stand up and answer questions for a couple of minutes every morning.