Ative at Work

Agile software development

Ative at Work

How Scrum Reduces Rework

I was talking to a group of project managers today in one of our inspiration meetings. One of the inspiring questions that came up was related to why we should use Scrum or agile methods.

One short answer is this: if we routinely plan to spend 1/3 of our project on testing and fixing defects there is a big benefit even if Scrum only helps reduce the amount of rework.

The next obvious question, then, is what are the most common causes of rework and how Scrum deals with these. Luckily we have some data on that, thanks to Otto Vinter ( and Søren Lauesen who wrote an article on the causes for rework (cited below).

In the project they analyzed they found four main causes of rework:

    ⁃    38% was caused by misunderstandings.
    ⁃    29% by missing requirements.
    ⁃    24% by changed requirements
    ⁃    9% by other causes.

Let's have a look at how Scrum addresses these.

Scrum Reduces Misunderstandings
The main problem is misunderstandings. This is why the "let's discuss the acceptance criteria" discussion between the Product Owner and Team before the development on a given feature starts is valuable. If we can avoid misunderstandings altogether the potential upside is a reduction in defects of 38%.

Scrum Reduces Superfluous Requirements
Then, the missing requirements. The just-in-time planning of Scrum and the demonstration of running tested software at the end of every iteration makes the identification of missing requirements trivial, so we will learn about these quickly. As such this does not reduce the amount of work due to missing requirements.

However, as we only commit to one sprint at a time it helps us to focus on building only the relevant, valuable features, which means that we also get a lot of feedback on which requirements are superfluous.

This means that we can more easily kill the half-baked ideas that we came up with in the beginning of the project when we had very little experience in the domain. Rather than building everything we thought of and then adding the missing stuff we look at the actual project and add the highest valued missing features week by week.

Thus, it gives the potential benefit of making us able to make the project smaller than if we had to commit early. That means less work, less rework and less complexity to maintain afterwards which is a great win over the lifetime of the project.

Scrum Makes Changing Requirements Inexpensive
One of the cornerstones of agile development is to make change cheap and easy. The reason we have Change Control Boards and other bureaucratic measures to prevent change from happening is that it is often very expensive and therefore we want to control it.

Agile development is all about making it inexpensive to adapt. If change was simple and did not introduce any huge risks of defects, downtime, deployment costs etc. we could happily embrace it. If we learned something new we could change the system accordingly, thus improving it and  increasing its value. That is why we cherish changes.

Scrum tackles this head-on. Going through a full development cycle from idea to production ready code every iteration it highlights all the expensive steps in our development process. It spotlights error-prone development practices, expensive manual testing, the bureaucratic inter-departmental coordination and the costly deployment procedures. By forcing our way through the entire pipeline every cycle we force ourselves to optimize the delivery pipeline. Not doing so is simply too expensive.

The key is to embrace the pain and use it as an impulse to fix the root causes of the problem rather than yielding to the lure of the palliative solution of resigning to doing it less frequently or managing the complexity rather than removing it.

It may take years to improve the organization to be able to do this efficiently, but the way there is rewarding. It gets better step by step, iteration by iteration. If you want to get to somewhere else you need only clear thinking and perseverance. It is as simple as that. Just get started - and keep going.

Read the article:

Analyzing Requirements Bugs (2000), Vinter O., S. Lauesen - Bug Report Department in Software Testing & Quality Engineering Magazine, Vol. 2-6, Nov/Dec 2000

For extra points, analyze your own projects and fix the causes that are most relevant to your organisation.

Published mar 25 2010, 11:05 by Martin Jul
Filed under: , ,



Peter Saddington said:

Great article on how Scrum reduces rework. One of the things that I would assume are obvious here is that you have a product owner that is available and apparent throughout the process to allow the team to make the changes necessary to utilize Scrum with these capabilities. You could almost say: "Having an involved and available Product Owner takes care of 91% of issues in rework."

september 8, 2010 3:43

Martin Jul said:

Yes, it is definitely our experience that getting the Product Owner role to work is the single most difficult thing in implementing Scrum.

In many large organisations the PO is usually a team of people since no single person has enough knowledge about the domain across all departments and this, of course, which makes things more difficult.

It is worth the effort, though.

I have process data showing how we evolved the scope along the way and discarded a huge amount of low-value ideas before implementing them (almost 2x the delivered scope) on a project that delivered a much better and relevant system on time and budget than originally planned all due to working closely with the product owner on backlog and priorities.

september 8, 2010 10:26

Peter Saddington said:

Sounds like those organizations need a "product management team" to align the work.

I've found that organizing such a team helps them (all those POs) get together and prioritize work, etc.

september 8, 2010 11:36

About Martin Jul

Building better software faster is Martin's mission. He is a partner in Ative, and helps development teams implement lean/agile software development and improve their craftmanship teaching hands-on development practises such as iterative design and test-first. He is known to be a hardliner on quality and likes to get things done-done.
© Ative Consulting ApS