This myth is my personal favorite. There are three challenges with this myth.
I assert that there is a bit of truth in this myth. However, it’s not as simple as saying Project X will be cheaper and faster if we use Scrum to deliver it. Let me explain.
Scrum delivers small, additive pieces of usable value At least every Sprint, we will have a Done Increment. This frequent cadence is what enables business agility. We have the opportunity to start earning return on investment (ROI) faster. We can also change direction to take advantage of new opportunities.
The Product Owner is accountable for optimizing the value of the product. We don’t want to spend money and time on functionality that does not have high enough value. The iterative-incremental nature of Scrum gives us feedback and tests our assumptions about value. And if necessary, we can change direction before investing too much in something that does not provide expected value.
And at the end of the day…
If you are delivering stuff that users don’t want, it doesn’t matter how fast or cheap you deliver it.
In traditional delivery models, the business funds a chunk of fixed scope up front. The team builds software until all of the scope is complete and/ or the money is spent. (The latter often involves a painful change request process to get more money.)
Scrum provides transparency to progress and value as functionality is delivered each Sprint. The business can choose to keep investing in an initiative or not based on the progress they see and the value delivered. Scrum helps stop the mentality that you should spend all of the money you’re given when a project gets funded.
The Definition of Done is the bar of quality and completeness in Scrum. We do not cut quality to deliver something faster or cheaper. In fact, we seek to increase quality over time through the inspect and adapt cycles of Scrum.
If you are delivering stuff that doesn’t work or makes the product brittle, it doesn’t matter how fast or cheap you deliver it.
You can argue there may be cost savings if the team is focused on a goal, and they do not have lost productivity due to context switching. There may be cost savings if the team is not battling technical debt and suffering from low morale.
But this first requires an investment in quality and continuous improvement. Teams need time to learn to work together effectively. Technical excellence takes time and money.
I choose effectiveness over efficiency when it comes to product development.
Belief in this myth sets teams up for failure because management is focusing on the wrong thing. They may use velocity to measure the performance of a team or individuals. There may be pressure to fix scope, schedule, and cost. This undermines team ownership and can lead to some unhealthy behaviors that impact transparency and much more.
The focus should be on empowering and enabling high performing teams. The focus should be on removing impediments. The focus should be on measuring value and figuring out what is valuable.
This myth can also be used to justify cutting budgets and giving teams less to work with.
Why do I think it’s impossible to prove one delivery approach is faster or cheaper than another?
Software development is complex. All knowledge work (aka creative work) isunique. So in order to compare two different approaches, you would need to have the exact same group of people with the same experiences, skills, and personalities working on the same project at the same time in parallel universes.
Scrum done well can help companies invest their money more wisely based on empirical evidence. Scrum done well can help companies get value in the hands of users and customers sooner, which means a faster ROI.
If you’ve worked on an effective Scrum Team, you know product development can seem faster and cheaper. And that is a welcome side effect. But faster and cheaper is not the value proposition of Scrum. It’s about high value, quality, frequent delivery, and fast feedback.
AGILE SOCKS is a registered trademark of Agile Socks LLC. Other marks used herein are the property of their respective owners. For more information see Trademark Notice in Terms & Conditions.