Learn how to conduct a retrospective in Kanban style. See how to inspect your workflow in detail and foster a spirit of continuous improvement.
Retrospectives are one of those Agile practices that you can’t just skip if you want to keep your performance top-notch. Of course, the benefit they bring is very much related to your approach to holding these meetings.
Like all meetings, retrospectives can easily become time-wasters that do more damage than good, because if held inertly, they tend to become a longer version of the daily standup meeting but with no added value.
To avoid that, Kanban provides a very simple solution called a Service Delivery Review (SDR). It allows you to inspect your workflow in detail and foster a spirit of continuous improvement by focusing on the work, not the responsible team member.
Additionally, these “Kanban retrospectives” can be customized to your team’s needs and way of work, so you don’t invest more time than necessary to attend them and get value from each meeting.
The Service Delivery Review is one of the seven Kanban cadences. It is the Kanban way of doing retrospectives and is focused on checking the team’s performance against commitments, customer-focused metrics, quality, lead time, classes of services, etc.
The goal of these retrospective meetings is to gather with the team and inspect in detail your Kanban board to solve existing problems and identify room for improvement in your process.
As the creator of the Kanban method David Anderson explains, “service delivery reviews must facilitate focused discussion between a superior and a subordinate about demand, observed system capability and fitness for purpose comparison of capability against fitness criteria metrics and target conditions, and agreement on actions to be taken to improve capability”
As an added benefit these retrospective meetings allow your team members to feel more involved in the management of the work process and voice their opinions and concerns.
To begin with, you have to agree with your team at a specific time of the week to hold the Service Delivery Review and stick to it. It will feel natural to teams used to the traditional way of doing Agile retrospectives after each delivery.
However, as the SDR is not tied to a particular event, such as the end of a sprint, holding a retrospective meeting this way may not be necessary. Instead, you need to define a cadence (e.g. every Tuesday at 10 o’clock) and stick to it.
After deciding on the time, you need to prepare for the actual meeting. Be sure to invite the whole team and any stakeholder of interest including customers if need be.
As the Delivery Director of 1904labs Mattew Philipp points out “the team may discuss in a retrospective ways to go faster, but without the customer, they can’t have a collaborative discussion about speed and tradeoffs, nor about the customer’s true expectations and needs”.
"Kanban works, with 76% reporting Kanban to be more or much more effective than other methods."
Once you’ve gathered everybody, you must go over the items on your Kanban board. To make the most of your time, you have to start from the Done column and move left towards Requested.
When using a digital Kanban solution, we advise you to archive cards only at the Service Delivery Review, so you don’t let an important work item slip by without getting the proper attention.
While going through the work items on the board one by one, discuss any issues you’ve faced with work items and share any valuable knowledge that you’ve gained while processing them. When doing so, it is important to keep your attention on the work itself, not the people responsible for it.
As experimentation has a significant role in achieving continuous improvement, you should give experiments special attention at your Kanban retrospective meeting. Don’t miss out on the chance to examine progress and discuss preliminary results. If there’s a possible adjustment, be sure to get everybody in the loop and sync how to implement it in the best way.
At Kanbanize, we are especially fond of running experiments. Depending on the team, they last between a couple of weeks and a whole quarter. To keep a close eye on them, we’ve added a dedicated “Experiment” column on our boards.
Similarly to regular cards, experiments must have one explicit owner. During each retrospective meeting, we go over the column where they live and if there are any new relevant data, we discuss it and decide how to proceed with the experiment at hand.
After you are done with the retrospective of completed tasks and ones in progress, proceed to inspect the flow metrics of your board.
Focus on key performance indicators regarding the flow efficiency of your process and go over them to evaluate the state of your workflow.
If you are using Kanbanize or another digital Kanban software solution, this is a perfect occasion to put to use any available workflow analytics.
Some of the most useful charts for the retrospective meeting are ones that show you how cards are aging on your board, cumulative flow diagrams (CFD), Heatmaps, Blocker clustering charts, and Cycle time trends analytics.
When looking at them, your first concern is related to meeting your service level agreements. Therefore, you have to pay special attention to how work is aging and be vigilant for possible delays.
If you are in danger of missing an important deadline, be sure to discuss how to apply Swarming. It is a technique that allows your team to collectively focus their efforts on pulling a card to Done in the fastest possible way to prevent delay.
To understand what created the danger at hand, you can go over the data on your cumulative flow diagram. This truly valuable chart will show you both how stable and how predictable your workflow is.
If there are no rapidly-expanding or shrinking bands, then there is a balance between the work entering your process and the one leaving it. In addition, if the bands are rapidly going upward, then you have high throughput. On the other hand, any plateaus would signal that cards are not progressing toward Done.
Be wary of rapid band expansions as they are likely to create plateaus caused by the accumulation of wait time. This can easily get you off course and create dangers of delay.
If this is the case, a heatmap can show you in detail how much time on average your cards spend at the problematic step of your workflow. As a result, you will be able to discuss potential solutions to workflow problems and base improvement initiatives on specific data.
To have an even better overview, we advise you to inspect any blockers you’ve accumulated for the discussed period of time.
Blocker clustering is a technique that could be especially useful at this moment to deal with recurring problems. Explained shortly, it allows you to gather repeating problems and track how much time it takes your team to solve them.
At the Service Delivery Review, you will have the opportunity to see how much blocked time was accumulated and dig deep to identify the root cause before figuring out how to solve it.
In addition, be wary of the cycle time trends in your workflow. Look out for fluctuations and discuss potentially harmful delays to avoid long-term dangers.
The SDR has some hidden dangers that you need to avoid at all costs if you want to make the most of this type of retrospective meeting.
As a start, keep your discussion focused on the work itself, not the person responsible for it. Don’t go on a witch hunt when things don’t go in the way you hoped for, but unite to identify a solution as a team.
Also, as a manager, we are sure that you’ve got quite a few suggestions for your team members on how to improve the way they work individually. Avoid the temptation to share them at the Service Delivery Review. This is a topic for a private discussion and is likely to have a very negative effect on the team spirit if reviewed in public.
Last but not least, present your state of affairs as they are. Don’t get carried away by vanity metrics such as the number of cards put to Done, but instead focus on the amount of value they brought to your customers. Don’t try to make your process look good, you will be fooling only yourself.
Our experience has shown that the Service Delivery Review can be combined with the other 7 Kanban Cadences in some cases.
For example, we have merged very naturally our SDR and Kanban Replenishment meeting. We strictly comply with everything that we preach in this article. After we are done with the retrospective, we dedicate 10-20 minutes to discuss what’s next for our team.
We always start from the initiatives that are currently in progress and look if we can pull in progress any task related to them. This way we ensure that the cards we work on are always related to something bigger.
We agree on which cards to pull in progress during the week and sync their priority. If nothing unexpected appears, we stick to the plan. Of course, as life happens, we don’t wait for the next meeting to deal with an emergency. Still, during the next retrospective meeting, we go over it and investigate the damage that was done to our flow.
Another option we’ve tried is combining the Service Delivery Review with the Strategy review. However, as the second one is held once per quarter and has to cover a large scope of topics, we decided to keep them separate due to the length of the meeting.
Still, you can experiment and see what works for you. The important thing is to remember that although these meetings are not prescribed by Kanban as mandatory, you should have them in one form or another.
Service Delivery Reviews are the Kanban way of doing retrospectives. They focus on the process and not the people, allowing you to improve your workflow collectively as a team. You should hold them regularly, preferably once per week. During the meetings, you need to:
During the 30-day trial period you can invite your team and test the application in a production-like enviroment.