What Is a Kanban Retrospective Meeting?
Retrospective meetings are typically associated with Scrum as they represent the last ‘ceremony’ of a Sprint. There is no equivalent process in Kanban as you start with what you do now, which is one of Kanban’s core principles. Though retrospectives aren’t common in Kanban, there are plenty of good reasons your team may want to introduce them.
The Agile Manifesto articulates this well:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Given Kanban’s focus on workflow and commitment to pursuing incremental and evolutionary changes, it makes sense to find time to review processes. However, Kanban’s approach is different from Scrum as it is more aligned with Lean project management methodology and focuses more on ways to speed up work and eliminate waste.
It is also true that Kanban itself has evolved over time. Practitioners such as David J Anderson, a pioneer of the Kanban framework, introduced a number of Kanban cadences to foster and promote communication and iterate processes.
The goal of these meetings, which are also referred to as service delivery reviews, is to reflect on the process, consider past decisions by the team, and determine what changes are needed to the Kanban system to improve. Client satisfaction is the main KPI that the team’s output needs to be measured against. It is also an opportunity to nurture culture and improve the relationship between the team and project stakeholders.
Types of Kanban retrospective meetings
There are different types of Kanban retrospectives that can fit into different implementations of Kanban. Here are three examples.
1. Scheduled retrospectives
As the name suggests, a cadence for the meetings is agreed to discuss workflow, blocks, issues, improvements, and pull together a set of action points to resolve them.
Scheduled retrospectives don’t necessarily have to be standalone meetings added to the team’s weekly schedule. David J Anderson recommends finding time in existing meetings as long as the right audience attends.
2. Stop & Solve retrospectives
If a team member is stuck unable to solve an issue they can call for an immediate retrospective to get help from the wider team. This enables them to come together and quickly resolve the issue.
There are both pros and cons to this approach. Whether it’s worth adopting depends on a number of considerations. To what extent will frequent stoppages affect workflow and delivery? How easy is it to organize these meetings when they’re not scheduled in advance? What if a team member requests them much more frequently than others — will they feel conscious about that?
Stop & solve retrospectives are critical steps in certain scenarios. For example, when developing software and dealing with zero-day vulnerabilities. Or resolving mechanical issues on a production line.
3. Pull system retrospectives
A pull system describes a process where items are only made when they are needed, an idea that lies at the heart of Kanban. Items move across and between workflows based on set triggers and rules. Similarly, retrospectives can be triggered when certain conditions are met.
For example, a separate board is created for team members to add Kanban cards for issues that need wider discussion among team members. Retrospectives are then held when a certain number of cards are added.
This approach is perhaps a compromise between the first two, where a hard stop is factored in the process but only when needed, which is how a pull system works. The other point of difference is that retrospectives are treated as an integral part of the system featuring their own dedicated board.
What should be included in a Kanban retrospective agenda?
Kanban retrospectives are data-driven and typically start with a review of a Cumulative Flow Diagram. This is an analysis of a workflow’s three KPIs: cycle time, throughput, and work in progress.
The team reflects on blockages and impediments to understand the root causes and determine how to resolve them.
There is no set agenda for Kanban retrospectives. You’ll be adding items to existing agendas when retrospectives are ‘appended’ to existing meetings. In many cases, agendas are adapted from Scrum and cover the following items:
1. Set the stage
Introducing new people and acknowledging the team, getting a sense of where team members’ energy levels are and if anyone is struggling.
Next, establish the context. This may involve looking back at the previous retrospective, reviewing any actions from them, and then proceeding to clarify scope and goals.
2. Look at the data
This could be a Cumulative Flow Diagram or any dataset that highlights issues that need to be tackled. This can be complemented by additional evidence shared by the team.
3. Brainstorm ideas and solutions
Armed with data, you can dive deeper into issues asking what went well, what didn’t, and what lessons can be learned. This exercise should generate a number of alternative solutions to consider in the next step.
4. Pick a solution
Reach a consensus and shortlist the most valid ones to be discussed in more detail, being realistic about their feasibility and considering what it takes to implement them. Then vote to decide which one to adopt.`
5. Conclusion
Close off with a recap of the main points, a list of action items, and a way to measure whether they have been successful or not. You’ll be discussing them at the next retrospective meeting.
As mentioned, the above isn’t the de facto Kanban retrospective agenda. You need to use one that makes sense for your process and how you intend to run retrospectives too.
For example, an agenda for a stop-and-solve retrospective run by a small team will look very different given it focuses on a single issue raised by a team member in urgent need of help.
Running a Kanban retrospective online
As organizations continue to make remote and flexible working part of their new normal, teams are continuing to adapt by embracing technology to recreate a similar experience that is both safe and familiar.
An online project management tool like Wrike that supports Kanban can either replace or complement physical boards. You will also need a tool to run virtual meetings, such as Zoom or Microsoft Teams that integrates with Wrike. You won’t need much else given these tools across all types of devices.
How retrospectives are run depends on what type they are, as described above. You can create and configure Kanban boards for each type. If you’re running pull system retrospectives you’ll need a board to manage issues and separate one for retrospectives. Fortunately, they can be easily linked in Wrike and more other platforms.
Cards (commonly called ‘tasks’ in online project management tools) can be used to set and share the agenda. Meeting notes can be either typed directly into the description area or in a document that can then be uploaded or linked to the card. Create sub-tasks for each action during the session too, assigning them to owners and adding notes as required.
While meeting physically is a different and better experience for running retrospectives, online platforms make up for it by streamlining them and saving time. You can set up and re-use templates and access advanced tools such as tagging, search, and filtering to better organize the information and knowledge you capture.
Running virtual meetings has advantages too. They can be recorded and replayed by those that are unable to attend, which is often the case when teams are distributed around the world. Platforms offer many in-meeting functions for people to share information, whether scribbling on a virtual whiteboard or sharing their screen.
If you’re looking to run Kanban retrospective online don’t attempt to build a complex solution for them. Remember that it is itself a process that you’ll need to fine-tune over time, just as Kanban reminds us to do.
