Welcome to our series looking at using Flomatika to run a Service Delivery Review. Today’s topic is going to focus on ‘Speed’. This is the delivery Lead Time from when the team starts a piece of work to when it is moved to Done. As part of this exercise, we’re also going to be looking at how the team is meeting their customer’s service level expectations (SLE).

Fitness Criteria

Fitness Criteria are your key performance metrics that represent the health of your delivery across several aspects. We can find the Fitness criteria as the first accordion on the Delivery Governance page.

If you look at the first two widgets, we have an indication on how the teams are going in terms of their lead time. 

In the Speed widget we can see at team-level items, the majority of the time (85th percentile) there are completing items in 15 to days or less.15 days might be good or bad, depending on your team’s context and the type of work they are doing. 

You can see the Portfolio level work items are showing as blank as they haven't completed any portfolio items within the selected time period. (Portfolio level work items are typically epics, initiative, phases, the larger items within your work item hierarchy.)

On the second widget in the fitness criteria we're looking at Service Level Expectation. We've got a traffic light that shows this is not a good number. We're meeting our service level expectations 54% of the time, a little over half the time. 

Flow Lens

You can deep dive and get a more detailed view of what is going on with your SLE and Lead Time using the Flow Lens. We can do this by navigating to the Delivery Management page. Lead time is based upon work that has been completed in the past, so we’ll look in the Completed Work perspective.

‍

Within the Flow Lens accordion, we can see the breakdown of our lead time for the various normalised demands that we have defined.

Let's look at Enhancements and Optimisations. We’ve completed 11 of these within the selected time period, with a Service Level Expectation of 7 days or less. We're achieving that expectation 64% of the time, but we're trending upwards. 

If we're looking at Enablers and Tech Debt, it has the same service level expectation of 7 days or less, achieving that at a similar rate of 62% of the time. However we are trending downwards. 

Through the Flow Lens, we can see via the Normalised Demands tab, how we're meeting our service level expectations of our customers. We can also jump across to the Flow Items tab to see the individual item types. 

We can see for Bug, the SLE is 3 days or less. We're achieving that less than half the time, but we're trending upwards. We can see across several work item types, we're not doing too great in meeting our customer expectations, but we're doing okay with Prototype (achieving the expectation 100% of the time). There is certainly room for improvement across the majority of the work items. 

Flow Analysis

You can conduct a more detailed analysis around your flow within Flow Analysis. Be able to ask ‘how might we’ questions. Such as ‘how might we reduce our lead times’? 

We can jump across to the Continuous Improvement page and have a look at our flow efficiency within the Flow Analysis accordion. What's the proportion of time being spent in queues versus active work time? 

With our Time in Stage widget, we can conduct deeper analysis on where our queues are. So with this current setting, we're looking at the Completed Work perspective, filtering for only Queued steps in our workflow, and only for the workflow steps that are within the In Progress step category. We can see for this team, the vast majority of the queue time is spent within the Dev Complete workflow step. 

We can then show the team that this is the biggest opportunity for the teams to reduce wait time, and ask “What might be the cause and how might we reduce that?” In this case, it could be that Dev Complete means they're waiting for a code review by perhaps the Technical Lead. The team could suggest a code review could be conducted by a peer and not necessarily only by the Technical Lead. In certain situations, the review could be bypassed entirely by relying on ‘code smell’ alarms. 

Here is just one example of how you can use Flomatika to conduct some analysis around your team’s speed, and how they might find opportunities to reduce their Lead Time. Stay tuned for more entries in this series.

If there are any aspects to a Service Delivery Review you would be interested in seeing how you could approach through the use of Flomatika, feel free to book a guided walkthrough with us.