Firstly, if you know anything about me, you’ll know that I LOVE retrospectives! 10 years ago I was busting out my Rocky, Top Gun and other 80’s & 90’s movies , music and game retrospectives with my teams. The more creative the better was my mantra. I want teams to be rewarded with something a little fun after their sprint, and to find new ways to be able to articulate sometimes the same problems and come up with new ways to improve.

The Scrum Guide says ‘The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.’

This is looking through the lens of individuals, interactions, processes, tools, and their Definition of Done. Ultimately we want to discuss the good, the bad and the ugly and come up with those creative ways to solve our issues and improve effectiveness.

It’s important to note that Scrum calls these meetings ‘events’.

Naturally, I have seen my fair share of terrible retrospectives, but it’s not my job today to help solve that one!

So how is Kanban different?

We like to call these meetings ‘Cadences’ and they form part of the 5th practice ‘Feedback Loops’

Since the introduction of the Kanban Maturity Model in 2018, how we articulate our retrospectives has changed. We look at them depending on the level of maturity you are at currently, and where you want to be. One of the benefits is that you can see the different levels of growth you need to make to make sure your service is fit for purpose. One of the negatives is that the names change as you evolve and it can get a little confusing. At the end of the day, you can call them what you want, it is the good practice that they introduce that is important.

Level 1 (Team focussed) – Team Retrospective

This can closely be compared to what we recognise in the scrum retrospective. Kanban describes it as a specific practice where teams reflect on how they work and which aspects of the process could be improved to get better outcomes.

At this level, it is very much focussed on the team.

Level 2 (Customer Driven) – Flow Review

From this point you will see that I start to use the word service. Kanban encourages you to take a service-oriented approach to understanding your organisation and how work flows through it. This service-oriented organisational paradigm is based on the idea that your organisation is an organic entity consisting of a network of services, each of them living and breathing, and evolving.

The Flow Review (FR) is to develop an initial understanding of the delivered service and use it to facilitate work planning and thereby improve predictability. At this stage of maturity, you would have introduced some data insights into the service such as:

  • The cumulative flow diagram (CFD)
  • Lead time distribution
  • Item age
  • Control Chart
  • Blockers
  • Levels of defects

We would use these with the services to sit down and have conversations. For example, we might identify that our lead time is currently 15 days. We could discuss what we could do to reduce this and then action. We could then revisit the data in an agreed period and see if what we have done, has helped us reduce the lead time and increased our delivery rate.

These types of retros require an upskill of understanding of the data, and psychological safety in the team so they do not feel judged or compared.

The key to think about here is, whether the service we provide to our customers is good enough, and improving. It’s an inward service conversation about what our customer thinks of how we get work done.

So for me this is where we start to see the difference. The Scrum guide does not mention the customer at this point. The customer perspective comes in for the Review event and that is more about the product, rather than how the work gets done and the expectations around this.

Level 3 (Fit For Purpose) – Service Delivery Review

The Service Delivery Review (SDR) is to examine and improve the effectiveness of a selected service. But this time it has more of a customer focus and will include delivery team(s), customers, and other external stakeholders. To be clear, at this point it might be a number of service teams that could come together to discuss collaboration, progress and issues.

Rather than just that inward view of the service, we now want to know explicitly what our customers think about our service. For example, they tell us we are ‘Too slow’ and we ask ‘ We deliver 85% of the time in 5 days or less, what would your desired be?’ We can then have a realistic conversations about whether their desire is even possible. It works both ways, we might have needs and expectations from them.

So we are closing the loop and bringing the service team(s) and customer(s) closer together. This close relationship and feedback loop is going to help build us a strong and adaptable end to end service.

Pick and Mix – Conclusion

In the UK we have this concept of pick and mix. It’s where they have rows of sweets and you can pick as many as you can fit into a tub for a set price. The beauty is you can just pick all your favourites.

I see the above as a pick and mix. You wouldn’t just do one of them, to get the best value you need to do them all at different points. You still need to make sure the team is happy, you still need to look at the data and you still need to make sure the customer is getting what they need.

So as a service you need to sit down and look at what that schedule is. This does not mean you pile in 4 new meetings, this means you potentially change the format of your existing 2 week retro to hit all the key needs.

Bringing it back to the original question. Both Scrum and Kanban are both looking to improve the way we do things. Kanban for more is a little clearer on expectations with the introduction of the different levels.

But why do I need to be Scrum or Kanban? Everything above can be applied in both methods and so don’t limit yourself. Take the best of both and adapt for your situation.

If you want to learn more about the Kanban Cadences you can join me on my next Kanban System Improvements Class.