Resources / Blogs

How do Service Deliver Reviews differ from retrospectives and can they compliment each other?

How do Service Deliver Reviews differ from retrospectives and can they compliment each other?

How do Service Deliver Reviews differ from retrospectives and can they compliment each other?

What is a Service Delivery Review?

Firstly, what is a Service Delivery Review anyway? Essentially, it’s a type of agile retrospective. It’s one of the seven kanban cadences from the Kanban Methodology

“An opportunity to stop and reflect and look back and see, how we are navigating, how we are progressing, how our process is functioning, and do we need to make any course corrections? “

- Marcio Sete, Flomatika CPTO

It’s assessing the performance of the service being provided against a set of measures. Things like Lead Time, Quality, Customer Satisfaction, Fitness Level and so on. It’s a focus on how the work is flowing through the value stream.

A key component of a Service Delivery Review is the data brought in to have an informed view of these measures. It’s asking questions like: How is the work flowing through the system? What is our lead time? What is our fitness level? How is our productivity? What about our predictability? How is our flow efficiency etc.

How Do SDRs Differ from Scrum Retros?

From what we have seen, Scrum is by far the most widely adopted agile framework. As such, most people are familiar with end-of-sprint retrospectives. A common question we come across is: What are the differences between a Service Delivery Review and a Scrum Retro?

I already mentioned above that the Service Delivery Review is much more data-driven, with metrics a key focus within the session. As a consequence, it’s also more customer focused, as some of these metrics are through the lens of the customer. Lead time is how long the customer is waiting for their need to be fulfilled for example. Predictability is another: For a certain type of request, what’s the typical range on when (or how many) I can expect my request to be fulfilled. 

Your retrospectives are typically more focused on your ways of working within the team, and perhaps how they're interacting with the rest of the organisation (external to the team). The camera is typically focused on the people, and how they are working with each other.

With the Service Delivery Review, you're putting the camera squarely on the work. How is the work navigating through the system? Is the work actively receiving attention? Or is the work idling in queues? This view requires data to provide the visibility. We are retrospectively inspecting the work and not the team members. This can assist in making some of these conversations less on individuals, and more on the work. Hopefully fostering more objective discussions.  

Something else the Service Delivery Review provides is a view for the team to have an understanding of the consequences of their decisions. Someone has finished their piece of work, should they pick up a brand new piece? Or should they instead help out their teammate on their piece of work as that is about to surpass its service level expectation? Or maybe yes, I should pick up that new piece of work as it has come through as an ‘expedite’ class of service. By reviewing how these micro day-to-day decisions are made (and their impacts), they are better informed on how to make better decisions in the future.

How Often Should You Run SDRs?

Another common question we encounter is how often do you run your SDRs? With Scrum Retros, people know the answer: it’s at the end of your Sprint. For flow-based approaches, with no clearly defined timebox to trigger an SDR, when should these be run?

The answer is that it depends! :) It’s all based on your own context, and it should be answered in a similar fashion to how you select your sprint cadence. If your priority changes every week, you should have sprints no longer than weekly. If your pace of change runs on a monthly cadence, then a 4-week sprint might suit you better. 

We describe it as an ‘intensity’ pace. If you’re working in an environment that has high intensity, is fast pace, with small items following quickly through your system, you might want to have your SDRs at least weekly. If your pace is at a much lower intensity, with a lower rate of change, then a fortnightly or monthly SDR could suit you better. 

Ensure that your feedback loops are not too long. They need to be at a rate where you are getting strong signals so you can react and respond appropriately. Observe the rate of these signal changes. You might receive a particular strong signal in one SDR, but that same signal is much weaker in the next session, indicating things have changed and the decisions you made since the previous SDR, might not be the same decisions you should make now. These sessions need to be at a cadence where you can course correct in a timely manner. 

I like to picture it as a turning circle of a vehicle. The tighter you need your turning circle, the smaller the cadence. The larger the cadence, then the bigger your turning circle will be.

Something we’ve seen one of our customers do is to run a few variations of the SDR with different focuses, or time horizons. Their Service Delivery Manager conducts a weekly SDR, first thing Monday morning, focused on the completed work from the previous week. They analyse why these particular items surpassed their SLE, what were the delays, and what were the root causes.

They also run a monthly service delivery review. This is reflecting back on the previous month with a focus more on a holistic systemic root cause analysis rather than on the individual work items. So we've seen teams build several layers of SDRs running at different cadences. You may run a daily SDR, for example, purely focused on WIP Age.

Can Traditional Retros and Service Delivery Reviews Compliment each other?

So the natural follow-up question is can you run both traditional retros along with SDRs? The differences between them have been highlighted earlier in this blog. So the answer is: Yes, definitely!

They are looking from two different lenses. If you look through only one, you’re likely to miss the perspective of the other. You could be focused on getting the work to flow efficiently through your system, but completely miss a big cultural issue impacting your team. Alternatively, you could have a high-morale team, but the work is constantly getting stuck, waiting in queues, or bogged down in a lot of dependencies, resulting in unsatisfied customers. 

We’ve seen teams alternate between the two on a fortnightly cycle. We’ve also seen teams that conduct their SDRs weekly, whilst their retros are fortnightly. Once again it comes down to what best suits your context, and ensuring those feedback loops allow you to respond in a timely manner.

Blogs you might be interested in:

See an audio recording of Marcio Sete (Flomatika CPTO) and Tom Lim (Product Manager) discussing the Service Delivery Review here.

See how Flomatika make it easy to bring the data into your SDRs

Start your trial today!