What is a Kanban Retrospective

Since the time the concept of Kanban started on Toyota’s factory floor, it has been evolving. Kanban has proven to be a set of ideas, if not a complete methodology that can be implemented successfully in a wide variety of industries and applications. One industry where Kanban, and especially Kanban boards, have been embraced on a large scale is software development. While being implemented in that industry, it cross-pollinated with ideas from Agile development, and especially Scrum. This gave birth to the idea of Kanban retrospectives.

What are Scrum Retrospectives?

Scrum is a development management methodology that depends on sprints short periods of a week or two of intense development efforts with specific goals and deadlines. After each sprint is over, there is a retrospective, which is a meeting that allows the development team to discuss problems and successes encountered during the last sprint. This meeting can be used to come up with improvements to the way the team operates that can be put to practice as part of the next sprint. This type of activity allows Agile teams to ensure continuous iterative improvement.

Kanban Retrospectives

As software development teams and organizations, that were used to the Agile and Scrum methodology, started employing Kanban boards to manage their tasks and workflows, the idea of retrospectives became part of the way they saw Kanban. As Kanban boards were mainly dealing with the workflow, they felt that a codified approach to solving problems and challenges was needed. They adapted retrospectives as a way to interrupt the regular flow, and to institute improvements.

Since this was not a centralized process, a few different approaches to Kanban retrospectives were developed. Each of them has its own pros and cons, its own focus, and each might be suitable for a different type of organization. Teams that are using a Kanban board to manage their tasks might actually want to look into the different types of Kanban retrospectives, and implement one of them to help facilitate regular improvement. An added benefit of having retrospectives is that it allows team members to feel involved and connected to the project, and to express their opinions and concerns.

Type 1: Scheduled Retrospectives

The simplest option, that probably lies closest to the Scrum roots of the idea, is to hold retrospective meetings at regular intervals. This means that there can be a regular retrospective that takes place at a recurring day and time, usually once or twice a week. A discussion about problems, issues and blockers, about possible improvements, and about the workflow in general, is held every time regardless of the size of the agenda for each meeting.

While if conducted well, such regular retrospectives can boost morale by making team members feel listened to, and could keep them motivated and invested. If there aren’t that many issues, those meetings might start to become a waste of time, which contributes very little to the overall performance of the team or organization. This is the most natural way to conduct retrospective for software developers used to Scrum, but it doesn’t seem to be the most effective or efficient one for other industries, so looking into the other options might be a good idea.

Type 2: Stop and Solve

Having regularly scheduled retrospectives doesn’t fit with the typical way work items are handled by Kanban boards and systems, so another simple way to do retrospectives started to become popular. The stop-and-solve or stop-the-line’ approach  means that every time there is an issue (that the person who encountered it can’t solve it on their own), an immediate retrospective involving the full team is called. Everyone looks into the problem, and brainstorms for possible solutions until a solution is found.

While this might be a fast way to fix a problem from the point of view of the individual facing it, forcing everybody to drop what they are doing is extremely inefficient. Additionally, in many cases this might even turn out to be impossible to implement. Larger organizations, or teams where the team member are not always at the same location, wouldn’t be able to implement this, even if they wanted to. It comes with a few additional cons. For instance, it’s very easy for those impromptu retrospective to become a burden and a constant distraction. While Kanban is usually supposed to facilitate flow, these might disrupt it. Still, there are certainly industries and organization where this particular type of Kanban retrospectives might actually be useful, and would benefit the organization and its competitiveness by manufacturing solutions to problems much quicker than usual.

Type 3: A Kanban Pull System

The last approach to holding retrospectives aims to fully integrate them into the Kanban system, and to treat them in the same way as all other operations. When this approach is implemented, the Kanban retrospective is an operation that needs to be triggered by a pull system. In other words, retrospectives get initiated when there is an actual reason to, and this is often based on explicit rules that are more complex than calling one right away.

When there is an issue, a Kanban card is assigned to it, and since all employees could discover or encounter issues, all employees should have the right to create such a card. One option is to have a separate board for issues with a backlog, and a limitation on the number of issues that can be worked on at the same time. The twist here is that the explicit rule should not just cover a maximum, but a minimum as well. When the required number of issues has accumulated, a retrospective is held, which is what makes this a pull system. This is an organized approach that makes sure there are neither pointless retrospectives with nothing to discuss, nor constant interruptions that disrupt the workflow.

Should Our Organization Implement Kanban Retrospectives?

Kanban retrospectives are not a requirement for a successful Kanban implementation. When Kanban is a part of a larger methodology like Lean, the process of continuous improvement will be handled in other ways. If you feel that your particular Kanban implementation would benefit from a version of the Kanban retrospectives, you should take advantage of the idea and make it part of your system.