By Ian Spence, SAFe Fellow, Scagilize, Original Post
Ian Spence is a SAFe Fellow with significant experience helping others with Lean Portfolio Management (LPM). We are excited to share some of his thoughts, experiences and research. Highlighted by an insightful CHAOS Report, he shares the positive influence of swift decision-making on outcomes on SAFe Portfolios. Organizations demonstrating efficient decision latency enjoy a significantly higher success rate, proving the profound impact of agility and rapid responsiveness beyond just the choice of methodology. Ian is a brilliant thinker and is great at bringing simplicity to the complex.
We hope you enjoy this share from Ian!
— Rebecca Davis and the Framework Team
There are two aspects of Lean Portfolio Management (LPM) that are often overlooked but are the real key to the success of any large-scale agile adoption. Everyone knows that effective Agile and LPM implementation requires high levels of decentralized decision-making, with empowered teams iterating towards cost-effective and profitable solutions.
The expectation is that the LPM Team can take a hands-off position and rely on the teams to be able to address all their impediments by themselves. Just give them the money, point them in the right direction, and get out of the way.
But there’s two particularly important aspects of Lean Portfolio Management that require frequent, hands-on input from the LPM Team.
The first is the need to support improved decision latency and the second, which we will look at in more detail in next month’s blog, is focus and the elimination of ‘dark work’.
The importance of good decision latency
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.
| Result | Good Decision Latency | Bad Decision Latency | Agile Method | Waterfall Method |
|---|---|---|---|---|
| Successful | 75% | 21% | 42% | 13% |
| Challenge | 21% | 36% | 47% | 59% |
| Failed | 4% | 43% | 11% | 28% |
Note: Successful is defined as ‘On Time, On Budget, with a satisfactory result’, Challenged is defined as ‘late, over budget or with an unsatisfactory result’ and Failed is defined as ‘cancelled or results not used’. Our desire for speed and an experimental approach requires us to think differently about the way we make decisions and report our progress.
So, what is decision latency?
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 makes a 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 that would 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 working 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 it 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.
What do LPM teams need to do to improve decision latency?
So, the ability for LPM to improve the decision latency for everyone and everything within the portfolio is one of its hidden benefits.
This is something that becomes even more important as organizations move away from portfolios of projects to portfolios of value streams and solutions (one of the key goals of any LPM adoption – see my previous two blogs that present a jargon-free comparison of Lean and Traditional approaches to portfolio management).
This need for a responsive LPM Team is why I blanch when I see LPM training materials recommending monthly portfolio synchs. My experience is that the portfolio team needs to synchronize itself at least once an Iteration / Sprint, if not even faster. If we have daily synchronization between the teams and the portfolio, we can have a decision made and acted on within a day; if we do this every two weeks, then it will be closer to two weeks.
It is also why I always recommend that the LPM team runs itself as an Agile team, called an Executive Action Team in Scrum@Scale and an Agile Executive Team in SAFe, that has daily Scrums/Synchs where it can hear about – and decide to act upon – any issues arising from any of the teams within its portfolio.
Remember, in an Agile environment, if a decision is made for the portfolio, action can start within two weeks somewhere within the portfolio, if not even quicker. But it doesn’t matter how agile the teams are in responding to the decisions if the decisions they depend on are not made quickly in an agile fashion.
Attributions:
- Scrum@Scale is a registered trademark of Scrum Inc.
- SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.
[1] See Henny Portman’s blog for an overview of the whole report.
[2] “The overall results clearly show that waterfall projects do not scale well, while agile projects scale much better.” See Standish Chaos Report 2015 for a publicly available discussion of this.