If you ask most managers about "psychological safety" or "vision" (read more: Psychological safety) of their agile software development teams, they agree that these things are important, but… when the customer signals urgency or the deadline gets near, typically all these “softer” variables are being deprioritized. Managers mainly care about a predictably working agile delivery flow.
If you have read through the Echometer blog (to our blog), you will know that our content mainly focuses on improving the “soft skills” of teams and organizations. They are underestimated by decision makers. But not by Scrum Masters and Agile Coaches.
At the same time, in my opinion, what Scrum Masters and Agile Coaches underestimate is the power of focusing on improving delivery - basically, what managers want. In today’s post, I will write about a simple technique to get better at delivering on time and budget.
1. Step one regarding your agile delivery flow
I am talking about monitoring the agile delivery flow of your tasks. If you do just a few things right, you will be able to deliver way more predictable results. Even your cycle time scatter plots or your Monte Carlo simulation for calculating project estimates could finally show valid predictions instead of showing estimates for your future agile delivery flow that are completely off the mark (More on: 9 Agile metrics for decision makers).
First symptom to fight: There are tasks that take just a few days, and then there are tasks that take more than a month to finish. To counteract this, you should make sure to always have the smallest deliverable unit of value in a task. Basically the MVT, Minimum Viable Task. This doesn’t mean that every task is small. But it should help you reach a stage where tasks generally take a few weeks at most, not months.
2. Step two regarding your agile delivery flow: WIP instead of velocity
Many Scrum Masters or Kanban Coaches believe that for measuring velocity etc. in a valid way, it is about the “right sizing” of work items, where all work items have roughly the same size. Only then, story points (which are needed to measure velocity) are usable for measuring velocity, because they seem more like a comparable time unit.
But that is wrong: Tasks don’t even need a similar size. That is not what you should do, because it is simply too hard to control the estimation part of this. But the one thing you can control is how many new tasks you start.
So do the following to get predictable: Monitor the rate of “new work item started” compared to the rate of “work item finished”. These two should be in balance. In other words, the arrival and departure rate of work items should be as close together as possible, ideally matching.
An example: A typical behavior in software development teams is that, once your “in progress” task is blocked, you start a new work item. That leads to many tasks being open, making it way more complicated to unblock all of them.
Instead, if you make sure that for every started work item there is also a finished work item, the Daily will be more successful in unblocking only a few tasks. You will be more predictable - and the team will be happier because your manager and customers are happier.
Some “positive symptoms” of a healthy agile delivery flow
Practically, this would lead to the following behaviors:
- We don’t start new tasks when there are still many things in progress.
- We focus on finishing what we started before we start new things.
- The age of the tasks never goes beyond a few weeks.
- Unless there is a good reason not to, we always pull the oldest work item.
WIP (Work-in-Progress) limits also help with this, although they are often not enough. Generally, once the team learns to optimize for finishing tasks instead of only starting new ones, you will be better than most teams.
Having a great agile delivery flow
Just so set clear expectations: Through doing this, you will still not be able to control whether a task takes two or three days. But at least you will make sure that your team doesn’t work on so many tasks that 2-3 day-tasks end up taking a month.
Think about it: How much better would your team already be if you knew that basically all delivery commitments will be achieved within a few weeks? That of course requires you to do all of the above: Defining MVTs, having a strict WIP-limit and only committing on tasks once another task was completed.
Step 3: Starting to improve your agile delivery flow
You know what to do in theory. Now what is the best way to start improving? By creating awareness and “change readiness” in the team. In the best case through self-reflection.
You have to create transparency around and regularly review these numbers, checking if the rate of “work items started vs. finished” is in balance. It could be part of your retrospective to go a little deeper and investigate why the numbers might not have been in balance in the last cycle.
I can recommend reflecting the behaviors I mentioned with our agile retrospective tool Echometer in your retrospective (more on this: 7 Retrospective tools in comparison). You might even make it part of your working agreements or your regular mood health check to increase awareness, asking this very regularly.
The following questions are our “agile delivery” retrospective template (more on this: 22 fun templates for agile retrospectives). We are starting with a few health check items, asking the team if they agree or disagree. Afterwards there are a few open questions:
Agile Delivery Retrospective
Health Check Items
We get things done really fast. No waiting, no delays.
We can estimate exactly what we can deliver in a given cycle.
Our sprint results do not require any post sprint rework to be delivered.
We limit our 'work in progress' to be focused at all times.
When did our way of working really work well?
What are the biggest areas for improvement so that work packages move through our processes faster (eliminate waiting times, improve processes)?
What are recent examples for an increment that wasn't working / shippable at the end of the cycle?
When did your ways of working create a suboptimal flow of work (e.g., policies are unclear, not suitable or not adhered to)?
As you can guess, the last health check item (checking a potential root cause) already implies a potential action item, something you can try for one agile sprint to see if it might help you: Limiting ‘Work in Progress’.
Laying the foundation: Defining team working agreements
You feel like your team is not prepared for this kind of reflection yet? In that case, you might first want to reflect on “good work” in general and then set some ground rules, aka working agreements. This workshop template can help you with this. You can do this as a special form of retrospective at the beginning of a project, or as an extra workshop.
First, get a sense of how unified your team implicitly feels – see the Health Check Item for that. Then you should then check this with a few open-ended questions. Each team member must finish the sentence (see open questions below) with as many answers as come to his/her mind:
Team Commitments Retrospective
Health Check Items
We share a common understanding of what 'good work' is in my team.
Handling of contradictory priorities: ‘When I encounter contradictory priorities, I …’
Communication of blockers: ‘When I am stuck on a task, I announce this by …’
Navigation of conflicts: ‘When I notice a conflict start to build up in our team, I …’
Of course, after collecting these answers you should try to find patterns and align on actual agreements on how you want to work together - at least temporarily to try them out.
A fun, creative alternative
In case these retrospective ideas appear too “dry” for you, there is another retrospective idea that focuses on reflecting the quality of your team’s output (find fun 54 retrospective ideas here): The three little pigs retrospective. It is a simple alternative to start reflecting and improving your delivery based on the fairy tale of the three little pigs that built houses out of different materials:
Open Feedback Questions
House of straw: What do we do that is just holding together, but could topple over at any moment? 🌱
House of sticks: What do we do that is relatively stable, but could be improved? 🪵
House of bricks: What do we do that is rock solid? 🪨
Conclusion – Agile Delivery Flow
No matter how you start, just start. The teams that have an active eye on their delivery flow are better teams.
By the way, many of the ideas you find here are also well summarized in the Podcast “Agile bites” that I can highly recommend (To the podcast: Agile Bites).
Have fun developing your team!