The impact of fast decision-making is often underestimated by people in leadership positions. Many people have studied this, particularly the Standish Group, who publish the CHAOS Report in the United States.

As an organization, they have looked at hundreds of thousands of projects over many, many years. The latest (and sadly it seems the last) results that I have seen were published in 2021 and are based on the results of 50,000 recent endeavours of various sizes and approaches [1].

For many years, I’ve used their reports to show how Agile compares to Waterfall, particularly when undertaking large endeavours [2]. But what they have found recently is that the biggest single factor in whether people are successful or unsuccessful isn’t their choice of method but their decision latency.

The table below shows the resolution of projects within the 2020 CHAOS database, segmented by
1) Good versus Bad Decision Latency and 2) Agile versus Waterfall Methods.

Source: Standish Group – CHAOS 2020: Beyond Infinity

Simply put, it is the time to make and act on decisions. It’s not just the time spent waiting for a decision to be made, but also the time spent waiting for a decision to be acted on once it has been made.

Now, I’m sure all of you can think of examples of poor decision latency in your own organization – with both extended times to make decisions and extended times to act on the decisions made. One of my personal favourites was an organization with a formal change control board for all changes involving their suppliers. When I was engaged, I asked for some data on decision-making for different sizes of investment (in this case, small enhancements and new initiatives). At the time (it was a long-time ago) I was amazed when I received the figures; on average it was 1 month to decide on whether to act on the expensive ideas and 3 months to decide on the small enhancements. I was so shocked, I thought they’d mislabelled the lines on the graph. But no, the numbers were accurate. A problem that was further compounded by the fact that there was a corresponding long lead time associated with acting on the big decisions, with the result that nothing was decided and acted upon in less than 4 months. This is not a good decision latency.

So, what impact does decision latency have on the overall performance of an organization? In the table above, you can see the success rates for organizations with good decision latency: those organizations where the decision latency is measured in hours and days. As you can see, if we have good decision latency, we can expect a 75% success rate and only a 4% failure rate.
 
That's independent of whether people are using framework X, Y or Z, and the method they are using. The fact that they make and act on their decisions quickly is making the big difference.
 
Compare that to the results for organizations with poor decision latency – where the decision latency is measured in weeks and months, and where we see a success rate of 21% and a failure rate of 43%.

Clearly, we need to have good decision latency.

Why is this important if we are already Agile?

The CHAOS Report also provides a comparison of project success for Agile and Waterfall methods, where Agile approaches clearly outperform Waterfall ones (see the right-hand side of the table above).

The two things are not unrelated. Doctor Jeff Sutherland the co-creator of Scrum and Scrum@Scale^Ò, and the person who introduced me to the concept of decision latency, likes to tell a story about the time he met with Jim Johnson the author of the 2020 CHAOS Report who said something along the lines of “Jeff, I’ve finally worked out why Agile beats Waterfall. It's the speed of decision-making”.
 

But why is the success rate for Agile initiatives not as high as it is for those with good decision latency? In my experience, this is because the decision latency of Agile Teams is highly constrained by the decision latency of the parent organization, and in particular the decision latency of the portfolio commissioning their work. This is true even when the organization and portfolio believe themselves to be agile. Although these organizations delegate to the teams as much as possible, they forget that the teams still need a quick response if there's something they can't handle by themselves.

For example, I was doing some consulting at an organization who’d set up a large team of teams to work on what was proclaimed to be the second-highest priority initiative in the whole organization. The team was great and empowered to get on with the work in their preferred way, including test-driven development and continuous integration – which was reflected in their Definition of Done. Unfortunately, they didn’t have the laptops they required to complete their testing, so they couldn’t get anything “actually” done. The request was escalated many times without any action being taken. It got so bad that the team recommended that they stop work and go home.

Eventually things were sorted out, and a decision was made to fund the acquisition of the new equipment, but the impact on morale, technical debt, and overall progress was severe. This was not a catastrophic failure, but is indicative of the situation faced by many agile teams and shows the consequences of poor decision latency: the time to make the decision was long and then further compounded by the need to go through procurement, which further delayed their ability to act once the decision was made. All that delay, and we’re still ignoring the fact that the laptops required cost less than the average daily cost of the developers involved.