Agile Practices Reduces Software Development Issues

In a large study of the effects of switching to agile ways of working at a unit of Ericsson in Sweden researchers Kai Petersen and Claes Wohlin found a number of issues with Agile Software Development but far fewer than with the previous plan driven approach. The table below shows the issues found with the plan driven approach and the agile approach respectively. Issues are rated by their severity and frequency on the following scale “general problem”, “very common problem” and “common problem”.

Issues with Software Development
With PD With Agile
Test Coverage: A general problem. Due to verification being the last step in the development cycle. Lost time was recovered by reducing test coverage. Test Coverage: A common problem.
  1. Due to short cycle times (three months) it was hard to do thorough testing.
  2. The expensive equipment required was not sufficiently available – which does indicate higher test coverage?
  3. Due to working in the same feature teams, testers lost their independence from the developers thus covering less area outside the “box”.
Requirements waste: A general problem. A lot of work was wasted on requirements which were never fulfilled or marketed because planning started so early. Release: A common problem. Sometimes release was involved to late in the process.
Faults found late: A very common problem. Because testing was late in the process so were the faults found. Fault slip through analysis was developped to quantify this problem. Management overhead: A common problem. Because there were more and smaller teams more coordination was required between the teams.
Faults found late: A very common problem. Faults found late were more expensive to fix. Delayed deliveries. A very common problem. If a package was not of sufficient quality for the planned delivery, it had to wait until the next release cycle.
Requirements waste: A common problem. A lot of requirements documentation was produced but never used.
Resource waste: A common problem. Design units had free capacity because of requirements lead times.
Requirements confusion: A common problem. It was not clear who implemented which version of a requirement.
High FST to customers. A common problem. Faults were not found – due to low test coverage – and so found in the production system by the customer instead.
Project management. A common problem. ” Specialized competence focus and lack of con-

URL: User Requirements with Lego

URL: User Requirements with Lego by, on Flicker. Used under a create commons license, click image for details.

As you can see, the number of problems reported, the nature of the problems reported and the severity of the problems reported was much changed according to the report. With the plan driven approach, the company tried to anticipate years in advance what customers would like to purchase. Often these predictions were wrong leading to a lot of waste and a lot of pressure on the organization. This trend is not going to go away. So this research further emphasizes the importance of being agile.

Some of these issues had been reported in previous work by Petersen and Wohlin while other issues were reported for the first time in this publication.


About Greger Wikstrand

Greger Wikstrand, Ph.D. M.Sc. is a TOGAF 9 certified enterprise architect with an interest in e-heatlh, m-health and all things agile as well as processes, methods and tools. Greger Wikstrand works as a consultant at Capgemini where he alternates between enterprise agile coaching, problem solving and designing large scale e-health services ...


  1. Pingback: Agile Project Manager » Blog Archive » Fake or Real Agile?

  2. Pingback: Agile Project Manager » Blog Archive » Are We, like King Claudius, already Damned?

  3. Pingback: 4 myths about software development productivity - Greger Wikstrand

Leave a Reply

Your email address will not be published. Required fields are marked *