In his seminal work, The Mythical Man Month, one of the many lessons Fred Brooks teaches is that there is no silver bullet. There is no one management technique or technology that can create a 10X increase in productivity over a decade.
Scrum practitioners is learning this now, as are the management teams that went all-in on scrum. They bet their agile transformation on Scrum, and are now dealing with the fall out of its failure to deliver software faster. Waterfall teams knew this, and have long accepted their fate and priced it in. Scrum is a good software development process, as is Waterfall, as is Chaos Driven Development, as is Lean, as is any other process, in the right context. As much as we like to think of Software creation as an engineering project, it is a discovery process. If your team is discovering what the software should do, or what the customer wants, or how to be successful in your management environment, they’re discovering, they’re not engineering.
What’s the difference? Risk and uncertainty. The more known a system, process, and customer are, the less uncertainty and risk there is in delivering for that customer, process, or system.
The greater the uncertainty and risk, the greater the opportunity for increasing productivity.
Perhaps ironically, the less risk and uncertainty you have in your process, system, or customer, the easier it is to sustain productivity efficiencies as isn’t as much risk that it’ll be scrapped, but the potential percentage change will be less.
In order to identify the areas to improve, take the three parts: The system, the process, and the customer; and assign a risk and uncertainty score to each. 10 meaning extremely risky or uncertain, and 1 meaning no risk or uncertainty.
It’s preferable to have a score for both
risk and uncertainty, so as an example, if I were to apply this to Gusto
(a payroll system I use), from the perspective of the internal software
team working on the payroll (this is hypothetical): it may look like
this:
Customer: 3 Risk/2 Uncertainty (the customer is well known, the “Why” is well understood)
Process: 4 Risk/7 Uncertainty (development team is adopting “cloud CI/CD”)
System: 8 Risk/2 Uncertainty (the system is well known, but technical debt makes it risky to make changes)
With these numbers in hand, it’s easier to identify which parts to focus initial productivity efforts on.