Agile isn't faster, but you're done sooner
Let's examine two ways of working, in both cases the team's speed is exactly the same.
Agile transformations are always accompanied with an expectation of speed and when that speed doesn’t materialize we blame the methods instead of the mindset.
Following practices that have come to be associated with agile (e.g., XP) do result in faster delivery of software, but they aren’t the lever that results in material speed or value improvements.
A good agile team delivers faster because they have to deliver less. This is the fundamental idea that everyone, be it an executive, manager or developer, should internalize before beginning their agile journey, or else they’re in for disappointment and pain, in that order.
To illustrate, let’s contrast two types of organizing work.
In the first, we have a certain amount of scope that we think will delivery a certain amount of business value. We plan a launch date and work towards completing the scope (often in iterations) with frequent demos of the software along the way.
In this model, S units of scope are equated to B units of business value which cost C dollars. To benefit from B, we must complete S which costs C. Assuming everything goes well, we achieve this by a particular date. In this model, the project is over when the scope is complete.
The biggest mistake we make in agile transformations is to stick to this equation while expecting the date to be brought in. When done mechanically, iterating over the scope is this model can become an overhead, which may cost you time rather than saving it.
This is also a case where there is no value in Product Management, as all we are doing is sequencing work since scope and business value have a 1:1 relationship. A traditional Project Manager will be more effective than a Product Owner.
Let’s look at an agile approach to delivering this business value.
In this model, we aim to benefit from B but don’t assume that S is what’s going to get us there. We get feedback by releasing more frequently and assess whether the delivered scope is achieving the anticipated business value. As long as we prioritize by business value, at some point we discover that enough business value has been achieved that the remaining scope is not worth investing in, thus saving on the remaining time. Even though the speed of the team is the same as the previous model, we are done sooner.
This is a case where Product Management is critical as value decisions are frequent and impactful. A traditional Project Manager is the wrong choice in this model.
Accepting this method of going “faster” is a prerequisite to agile transformations. If we pull this thread more we quickly realize that working this way has deep impacts within an organization, all the way from how a team works to how the business manages PnL.
So, does agile make you go faster? Not necessarily, agile focuses us on the highest value work with the understanding that there’s stuff out there that’s simply not worth doing, and that we have the safety to say so when we realize it.