Agile Delivery Flow: 3 Steps to Deliver on Time Consistently
If you ask most managers about the “psychological safety” or the “vision” (more on this: Psychological safety) of their agile software development teams, they agree that these things are important, but… When the customer signals urgency or the deadline approaches, all these “softer” variables are typically put on the back burner. Managers are primarily concerned with a predictably functioning agile delivery flow of their agile team.
If you have read through the Echometer blog (to our blog) you know that our content tends to focus on improving the “soft skills” of teams and organizations. These are often underestimated by decision-makers. But not by Scrum Masters and Agile Coaches.
What Scrum Masters and Agile Coaches, in my opinion, underestimate in turn is focusing on improving the delivery flow - basically what managers want. In today’s post, I describe a simple technique to significantly increase the likelihood of delivering on time and on budget, again and again.
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 valid measurement of velocity etc. depends on “right sizing” of tasks or work items, where all work items are approximately the same size. Only then are story points (which are needed to measure velocity) useful for measuring velocity because they appear more like a comparable unit of time.
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, to become predictable, do the following: Monitor the rate of “new tasks started” compared to the rate of “tasks completed.” These two should be in balance. In other words, the “input” and “output rate” of tasks should be as close as possible, ideally even 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.
If, instead, you make sure that for every task started, there is also a task completed, it will be easier to unblock the few focused tasks in the Daily. Your overall performance will be more predictable - and the team will be happier because your supervisor and your customers will be happier.
Some “positive symptoms” of a healthy agile 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
In theory, you know what to do. Now, what is the best way to get started in practice? By creating awareness and “readiness to change” in the team. Ideally 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 from our retrospective template for “agile delivery” (more on this: 26 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
Agile Delivery Flow Retrospective: How the retro works
Random Icebreaker (2-5 minutes)
Echometer provides you with a generator for random check-in questions.
Review of open actions (2-5 minutes)
Before starting with new topics, you should talk about what has become of the measures from past retrospectives to check their effectiveness. Echometer automatically lists all open action items from past retros.
Health Check
All team members can answer the health checks anonymously on a scale. Then go through the results of the health checks together and record any additional comments if necessary. If you use the same health checks in several retrospectives, you can also track trends over time in Echometer.
- 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.
Discuss retro topics
Use the following open questions to collect your most important findings. First, everyone does it themselves, covered. Echometer allows you to reveal each column of the retro board individually in order to then present and group the feedback.
- 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 has our way of working led to a suboptimal workflow (e.g. due to unclear, unsuitable, or not followed guidelines)?
Catch-all question (Recommended)
So that other topics also have a place:
- What else would you like to talk about in the retro?
Prioritization / Voting (5 minutes)
On the retro board in Echometer, you can easily prioritize the feedback with voting. The voting is of course anonymous.
Define actions (10-20 minutes)
You can create a linked action via the plus symbol on a feedback. Not sure which measure would be the right one? Then open a whiteboard on the topic via the plus symbol instead to brainstorm root causes and possible measures.
Checkout / Closing (5 minutes)
Echometer enables you to collect anonymous feedback from the team on how helpful the retro was. This creates the ROTI score ("Return On Time Invested"), which you can track over time.
Agile Delivery Flow Retrospective
Health Check Questions (Scale)
Open questions
As you can imagine, the last point of the health check (checking the cause) already implies a potential measure, something you can try for one or two agile sprints to see if it might help you: Limiting the number of tasks with the status “Work in Progress.”
Laying the foundation: Defining team working agreements
Do you feel that your team is not yet ready for this type of reflection? In this case, you should first reflect on “good work” in general and then establish some basic rules, so-called working agreements. The following workshop template can help you with this. You can run it as a special form of retrospective at the beginning of a project or as an additional workshop.
First, you should get a sense of how much your team implicitly agrees - see the health check item for this. Then you should practically check this with a few open questions. Each team member must finish the sentence (see further questions) with as many answers as come to his/her mind:
Team Commitments Retrospective
Team Commitments Retrospective: How the retro works
Random Icebreaker (2-5 minutes)
Echometer provides you with a generator for random check-in questions.
Review of open actions (2-5 minutes)
Before starting with new topics, you should talk about what has become of the measures from past retrospectives to check their effectiveness. Echometer automatically lists all open action items from past retros.
Health Check
All team members can answer the health checks anonymously on a scale. Then go through the results of the health checks together and record any additional comments if necessary. If you use the same health checks in several retrospectives, you can also track trends over time in Echometer.
- We have a shared understanding in my team of what 'good work' is.
Discuss retro topics
Use the following open questions to collect your most important findings. First, everyone does it themselves, covered. Echometer allows you to reveal each column of the retro board individually in order to then present and group the feedback.
- Dealing with conflicting priorities: When I notice conflicting priorities, then ...
- Communicating blockers: When I get stuck on a task, I share it by ...
- Dealing with conflicts: When I notice a conflict emerging in our team, then ...
Catch-all question (Recommended)
So that other topics also have a place:
- What else would you like to talk about in the retro?
Prioritization / Voting (5 minutes)
On the retro board in Echometer, you can easily prioritize the feedback with voting. The voting is of course anonymous.
Define actions (10-20 minutes)
You can create a linked action via the plus symbol on a feedback. Not sure which measure would be the right one? Then open a whiteboard on the topic via the plus symbol instead to brainstorm root causes and possible measures.
Checkout / Closing (5 minutes)
Echometer enables you to collect anonymous feedback from the team on how helpful the retro was. This creates the ROTI score ("Return On Time Invested"), which you can track over time.
Team Commitments Retrospective
Health Check Questions (Scale)
Open questions
After you have collected the answers, you should of course try to find patterns and agree on concrete agreements on how you want to work together in the future - at least temporarily as an experiment.
A fun, creative alternative
If these retrospective methods seem too “dry” to you, there is another retrospective method that focuses on reflecting on 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:
Three Little Pigs Retrospective: How the retro works
Random Icebreaker (2-5 minutes)
Echometer provides you with a generator for random check-in questions.
Review of open actions (2-5 minutes)
Before starting with new topics, you should talk about what has become of the measures from past retrospectives to check their effectiveness. Echometer automatically lists all open action items from past retros.
Discuss retro topics
Use the following open questions to collect your most important findings. First, everyone does it themselves, covered. Echometer allows you to reveal each column of the retro board individually in order to then present and group the feedback.
- 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?\n 🪵
- House of bricks: What do we do that is rock solid? 🪨
Catch-all question (Recommended)
So that other topics also have a place:
- What else would you like to talk about in the retro?
Prioritization / Voting (5 minutes)
On the retro board in Echometer, you can easily prioritize the feedback with voting. The voting is of course anonymous.
Define actions (10-20 minutes)
You can create a linked action via the plus symbol on a feedback. Not sure which measure would be the right one? Then open a whiteboard on the topic via the plus symbol instead to brainstorm root causes and possible measures.
Checkout / Closing (5 minutes)
Echometer enables you to collect anonymous feedback from the team on how helpful the retro was. This creates the ROTI score ("Return On Time Invested"), which you can track over time.
Three Little Pigs Retrospective
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”, which I highly recommend (To the podcast: Agile Bites).
Have fun developing your team!
