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. In theory, retrospective meetings are typically associated with Scrum.
Like all meetings, retrospectives can easily become time-wasters that do more harm than good. If held inertly, they tend to become a longer version of the daily standup, with no added value.
To avoid that, Kanban offers a simple solution: 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 in attending and deriving value from each meeting.
Service Delivery Review - The Kanban Retrospective
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 review your Kanban board in detail to address existing issues and identify opportunities for improvement in your process.
Service delivery reviews should enable a focused conversation between a manager and their team member about current demand, the observed capability of the system, how well that capability matches fitness-for-purpose criteria, the relevant metrics and target conditions, and the concrete actions needed to improve capability.
As an added benefit, these retrospective meetings help your team members feel more involved in managing the work process and voice their opinions and concerns.
How to Conduct a Service Delivery Review?
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".
10 Years Kanban Experience In 1 Free Book.
Project Manager's Guide to Kanban
1. Inspect Your Board
Once you've gathered everybody, you must go over the items on your Kanban board. To make the most of your time, start in the Done column and move left to Requested.
When using a digital Kanban solution, we recommend archiving cards only during the Service Delivery Review to avoid important work items slipping through the cracks.
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.
Businessmap is the most flexible software
to align work with company goals
2. Pay Special Attention to Experiments
Because experimentation plays a significant role in continuous improvement, you should give experiments special attention during your Kanban retrospective. Don't miss out on the chance to examine progress and discuss preliminary results. If there's a potential adjustment, be sure to get everyone in the loop and sync on the best way to implement it.
At Businessmap, 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.
Similar to regular cards, experiments must have one explicit owner. During each retrospective meeting, we go over the column where they live, and if there is any new relevant data, we discuss it and decide how to proceed with the experiment at hand.
3. Inspect Flow Metrics
After you are done with the retrospective of completed tasks and those in progress, proceed to inspect the flow metrics of your board.
Focus on key performance indicators for process flow efficiency and review them to assess your workflow state.
If you are using Businessmap or another digital project portfolio management software, this is a perfect opportunity to use any available workflow analytics.
Some of the most useful charts for the retrospective meeting include work items aging on your board, cumulative flow diagrams (CFD), heatmaps, blocker clustering charts, and cycle time trend analytics.
When reviewing them, your first concern is 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 the practice of swarming. It is a technique that enables your team to collectively focus their efforts on pulling a card to Done as quickly as possible to prevent delays.
To understand what created the danger at hand, review the data in 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 work leaving it. In addition, if the bands are rapidly going upward, then you have a high throughput. On the other hand, any plateaus would signal that the cards are not progressing toward Done.
Be wary of rapid band expansions, as they are likely to create plateaus due to accumulated 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 for dealin 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.
What to Avoid During a Service Delivery Review?
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 current state as it is. 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.
Combining the Service Delivery Review with Other Meetings
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 our SDR and Kanban Replenishment meetings. 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.
Businessmap is the most flexible software
to align work with company goals
In Summary
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:
- Share problems with the completed work on your board and spread new knowledge
- Discuss the progress of items that you’re currently working on
- Identify room for improvement in your workflow and plan how to fill it
