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: