If you work with complex systems (software, manufacturing, people, etc.), you know that agility increases productivity, quality, morale, and much more. Agility is a Good Thing.
That said, many teams and organizations have found success with predictive project management practices, and my hope is that sharing this model and visualization of how agility reduces risk may provide a useful lens for evaluating whether you need to invest in agility in your organization.
For example, suppose that you’re about to spend $100M over a couple of years on a large enterprise software project. It is only human to want to know what you’re going to get for $100M. In fact, I can think of a hundred million reasons why I’d like to know exactly what I’m going to get and when I’m going to get it! But the only way this kind of thinking makes sense is if I want to gamble with the organization’s money, morale, and operational effectiveness by loading the project with dangerous amounts of risk. For example, commitments to scope and schedule, technology platforms, and legacy business processes can all be sources of risk that may be opaque for teams that do not have risk accounting in place. Nor will it be obvious how much we increase that risk when we don’t use agile practices.
Thinking in terms of the area under the curve helps. As is always the case, the amount of risk your team is taking on is the area under the curve, so managing time-to-value is how you manage risk. Agile practices are your management toolkit.
Risks typically increase over time, sometimes much more than one might imagine if we don’t take the time to estimate them. If you have a choice of cutting time-to-market in half, you may reduce the amount of risk by substantially more than 50%. In absolute terms, a week’s worth of risk is much less than 1/13th of a quarter’s worth of risk. Wouldn’t it be relaxing to set asside of 95% of your project’s risk by looking at only this week’s risk instead of the whole quarter? And isn’t it even better to know that the whole point of agility is that that up to ~60-70% of it is gone for good?
When a project is especially risky, for example software for a rapidly evolving platform or to support a new business model, the risk curve will be especially steep, and efforts to increase agility may allow your team to mitigate a great deal more risk than you might intuit at first glance, especially if the team is still more comfortable with predictive project management practices than with agile.
That’s it: risk is the area under the curve, and if your time-to-value is long, you’re probably loading up on more risk than you realize. Sometimes much more!
Sometimes examples help. If the model above is not intuitive, a few examples of risk that impact most software projects (other types of complex projects typically have analogous risks):
Risk of building for the wrong platform: large software projects around 2010 typically assumed that their users would be using laptop or desktop computers (PCs). In fact, a large segment of business and consumer software was about to migrate to mobile. Agile efforts in this time period were able to adapt and start figuring out how to support mobile users. Teams that were confident that their users needed software that would work on PCs were introducing a substantial risk that by the time their software was delivered to users, those users would only be willing to support software that was available on their mobile devices.
Even in 2020, tens of thousands of organizations are investing billions of dollars on on-premise solutions that are obsolete and should be in the cloud. In part, this is because they are failing to account for platform risk.
Risk of deploying software that didn’t work: most of us know the story of the difficult launch of healthcare.gov in 2013. It is an unusual story mainly because it was largely remediated within a year, and by 2014 the app worked quite well. Large scale software projects fail regularly, usually in a much less public fashion than healthcare.gov (2).
The longer it takes your team to put software in users hands, the higher the probability that you’re not going to discover usability issues for many weeks or months.
Risk of solving a problem that no longer matters: we’re all playing Calvinball more often than we’d like to admit. Some salient examples: reorganizing where people work because of COVID; moving software for data centers to the cloud; Transitioning from print and TV to digital marketing; retail moving online. Products and projects in complex context that don’t constantly review how they’re delivering value are at risk of delivering value that nobody cares about.
We’re human, so we’re going to get trip over status quo bias on a regular basis. Teams that discard their priors faster have a competitive advantage: they minimize the risk of investing in problems that no longer matter.
(1) Risk visualization from Teal Unicorn training on new ways of managing: https://tealunicorn.com/training
(2) Too many sources to cite, chaos report is a good place to start: https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf