Skip to main content
SpringerLink
Log in

The effect of moving from a plan-driven to an incremental software development approach with agile practices

An industrial case study

  • Published:
Empirical Software Engineering Aims and scope Submit manuscript

Abstract

So far, only few in-depth studies focused on the direct comparison of process models in general, and between plan-driven and incremental/agile approaches in particular. That is, it is not made explicit what the effect is of moving from one model to another model. Furthermore, there is limited evidence on advantages and issues encountered in agile software development, this is specifically true in the context of large-scale development. The objective of the paper is to investigate how the perception of bottlenecks, unnecessary work, and rework (from hereon referred to as issues) changes when migrating from a plan-driven to an incremental software development approach with agile practices (flexible product backlog, face-to-face interaction, and frequent integration), and how commonly perceived these practices are across different systems and development roles. The context in which the objective should be achieved is large-scale development with a market-driven focus. The selection of the context was based on the observation in related work that mostly small software development projects were investigated and that the investigation was focused on one agile model (eXtreme programming). A case study was conducted at a development site of Ericsson AB, located in Sweden in the end of 2007. In total 33 interviews were conducted in order to investigate the perceived change when migrating from plan-driven to incremental and agile software development, the interviews being the primary source of evidence. For triangulation purposes measurements collected by Ericsson were considered, the measurements relating to unnecessary work (amount of discarded requirements) and rework (data on testing efficiency and maintenance effort). Triangulation in this context means that the measurements were used to confirm the perceived changes with an additional data source. In total 64 issues were identified, 24 being of general nature and the remaining 40 being local and therefore unique to individual’s opinions or a specific system. The most common ones were documented and analyzed in detail. The commonality refers to how many persons in different roles and across the systems studied have mentioned the issues for each of the process models. The majority of the most common issues relates to plan-driven development. We also identified common issues remaining for agile after the migration, which were related to testing lead-time, test coverage, software release, and coordination overhead. Improvements were identified as many issues commonly raised for the plan-driven approach were not raised anymore for the incremental and agile approach. It is concluded that the recent introduction (start in 2005 with the study being conducted in the end of 2007) of incremental and agile practices brings added values in comparison to the plan-driven approach, which is evident from the absence of critical issues that are encountered in plan-driven development.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4

Similar content being viewed by others

References

  • Anderson DJ (2003) Agile management for software engineering: applying the theory of constraints for business results (the coad series). Prentice Hall PTR, Englewood Cliffs

    Google Scholar 

  • Bahli B, Abou-Zeid ES (2005) The role of knowledge creation in adopting xp programming model: an empirical study. In: ITI 3rd international conference on information and communications technology: enabling technologies for the new knowledge society

  • Baskerville R, Ramesh B, Levine L, Pries-Heje J, Slaughter S (2003) Is internet-speed software development different? IEEE Softw 20(6):70–77

    Article  Google Scholar 

  • Beck K (1999) Embracing change with extreme programming. IEEE Comput 32(10):70–77

    Google Scholar 

  • Benediktsson O, Dalcher D, Thorbergsson H (2006) Comparison of software development life cycles: a multiproject experiment. IEE Proc Softw 153(3):323–332

    Article  Google Scholar 

  • Ceschi M, Sillitti A, Succi G, Panfilis SD (2005) Project management in plan-based and agile companies. IEEE Softw 22(3):21–27

    Article  Google Scholar 

  • Cohen D, Larson G, Ware B (2001) Improving software investments through requirements validation. In: Proceedings of the 26th annual NASA Goddard software engineering workshop (SEW 2001). IEEE Computer Society, Washington, p 106

    Google Scholar 

  • Cohen D, Lindvall M, Costa P (2004) An introduction to agile methods. In: Advances in computers. Elsevier, Amsterdam

    Google Scholar 

  • Dagnino A, Smiley K, Srikanth H, Antón AI, Williams LA (2004) Experiences in applying agile software development practices in new product development. In: Proceedings of the IASTED conference on software engineering and applications (IASTED-SEA 2004), pp 501–506

  • Dai L, Guo W (2007) Concurrent subsystem-component development model (cscdm) for developing adaptive e-commerce systems. In: Proceedings of the international conference on computational science and its applications (ICCSA 2007), pp 81–91

  • Damm LO, Lundberg L (2007) Company-wide implementation of metrics for early software fault detection. In: Proceedings of the 9th international conference on software engineering (ICSE 2007), pp 560–570

  • Damm LO, Lundberg L, Wohlin C (2006) Faults-slip-through—a concept for measuring the efficiency of the test process. Softw Process Improv Pract 11(1):47–59

    Article  Google Scholar 

  • Dybå T, Dingsøyr T (2008) Empirical studies of agile software development: a systematic review. Inf Softw Technol 50(9–10):833–859

    Article  Google Scholar 

  • Fairley RE, Willshire MJ (2005) Iterative rework: the good, the bad, and the ugly. IEEE Comput 38(9):34–41

    Google Scholar 

  • Hanssen GK, Westerheim H, Bjørnson FO (2005) Using rational unified process in an sme—a case study. In: Proceedings of the 12th European conference on software process improvement (EuroSPI 2005), pp 142–150

  • Heijstek W, Chaudron MRV (2008) Evaluating rup software development processes through visualization of effort distribution. In: Proceedings of the 34th conference on software engineering and advanced applications (SEAA 2008), pp 266–273

  • Hirsch M (2005) Moving from a plan driven culture to agile development. In: Proceedings of the 27th international conference on software engineering (ICSE 2005), p 38

  • Ilieva S, Ivanov P, Stefanova E (2004) Analyses of an agile methodology implementation. In: Proceedings of the 30th EUROMICRO conference (EUROMICRO 2004), pp 326–333

  • Jarzombek J (1999) The 5th annual jaws s3 proceedings

  • Johnson J (2002) Keynote speech: build only the features you need. In: Proceedings of the 4th international conference on extreme programming and agile processes in software engineering (XP 2002)

  • Jones C (1995) Patterns of software systems: failure and success. International Thomson Computer Press, Boston

    Google Scholar 

  • Karlström D, Runeson P (2005) Combining agile methods with stage-gate project management. IEEE Softw 22(3):43–49

    Article  Google Scholar 

  • Koch AS (2005) Agile software development: evaluating the methods for your organization. Artech House, Boston

    MATH  Google Scholar 

  • Laplante PA, Neill CJ (2004) Opinion: the demise of the waterfall model is imminent. ACM Queue 1(10):10–15

    Article  Google Scholar 

  • Larman C (2003) Agile and iterative development: a manager’s guide. Pearson Education, Boston

    Google Scholar 

  • Layman L, Williams LA, Cunningham L (2004) Exploring extreme programming in context: an industrial case study. In: Proceedings of the agile development conference (ADC 2004), pp 32–41

  • Mannaro K, Melis M, Marchesi M (2004) Empirical analysis on the satisfaction of it employees comparing xp practices with other software development methodologies. In: Proceedings of the 5th international conference on extreme programming and agile processes in software engineering (XP 2005), pp 166–174

  • Martin A, Biddle R, Noble J (2004) The xp customer role in practice: three studies. In: Agile development conference, pp 42–54

  • McBreen P (2003) Questioning extreme programming. Pearson Education, Boston

    Google Scholar 

  • Merisalo-Rantanen H, Tuunanen T, Rossi M (2005) Is extreme programming just old wine in new bottles: a comparison of two cases. J Database Manage 16(4):41–61

    Google Scholar 

  • Petersen K, Wohlin C (2009a) A comparison of issues and advantages in agile and incremental development between state of the art and an industrial case. J Syst Softw 82(9):1479–1490

    Article  Google Scholar 

  • Petersen K, Wohlin C (2009b) Context in industrial software engineering research. In: Proceedings of the 3rd international symposium on empirical software engineering and measurement (ESEM 2009), pp 401–404

  • Petersen K, Wohlin C, Baca D (2009) The waterfall model in large-scale development. In: Proceedings of the 10th international conference on product focused software development and process improvement (PROFES 2009), pp 386–400

  • Poppendieck M, Poppendieck T (2003) Lean software development: an agile toolkit (the agile software development series). Addison-Wesley, Reading

    Google Scholar 

  • Raccoon LBS (1997) Fifty years of progress in software engineering. SIGSOFT Softw Eng Notes 22(1):88–104. doi:10.1145/251759.251878

    Article  Google Scholar 

  • Runeson P, Höst M (2009) Guidelines for conducting and reporting case study research in software engineering. Empir Softw Eng 14(2):131–164

    Article  Google Scholar 

  • Schwaber K (2004) Agile project management with Scrum. Microsoft Press, Redmond

    Google Scholar 

  • Sillitti A, Ceschi M, Russo B, Succi G (2005) Managing uncertainty in requirements: a survey in documentation-driven and agile companies. In: Proceedings of the 11th IEEE international symposium on software metrics (METRICS 2005), p 17

  • Stephens M, Rosenberg D (2003) Extreme programming refactored: the case against XP. Apress, Berkeley

    Google Scholar 

  • Svensson H, Höst M (2005) Introducing an agile process in a software maintenance and evolution organization. In: Proceedings of the 9th European conference on software maintenance and reengineering (CSMR 2005), pp 256–264

  • Tessem B (2003) Experiences in learning xp practices: a qualitative study. In: Proceedings of the 4th international conference on extreme programming and agile processes in software engineering (XP 2004), pp 131–137

  • Thomas M (2001) It projects sink or swim. In: British computer society review 2001

  • Tomaszewski P (2006) Software development productivity–evaluation and improvement for large industrial projects. PhD thesis, Dept. of Systems and Software Engineering, Blekinge Institute of Technology

  • Wils A, Baelen SV, Holvoet T, Vlaminck KD (2006) Agility in the avionics software world. In: XP, pp 123–132

  • Wohlin C, Runeson P, Höst M, Ohlsson MC, Regnell B, Wesslen A (2000) Experimentation in software engineering: an introduction (international series in software engineering). Springer, Heidelberg

    MATH  Google Scholar 

  • Yin RK (2002) Case study research: design and methods, 3rd edn. In: Applied social research methods series, vol 5. Prentice Hall, Englewood Cliffs

    Google Scholar 

Download references

Author information

Authors and Affiliations

  1. Blekinge Institute of Technology, 372 25, Ronneby, Sweden

    Kai Petersen & Claes Wohlin

Authors
  1. Kai Petersen
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Claes Wohlin
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Kai Petersen.

Additional information

Editor: Forrest Shull

Appendices

Appendix A: Interview Protocol

1.1 A.1 Introduction

  • Explain the nature of the study to the respondent, telling how or through whom he came to be selected:

    • Goal of the study: Understanding hindering factors in the different development models (traditional, streamline, streamline enhanced).

    • What is done: Compare the different models against each other in terms of bottlenecks, avoidable rework and unnecessary work.

    • Benefit for the interviewee: Interview is the basis for further improving the different models considering the different views of people within the organization, gives interviewee the chance to contribute to the improvement of the model they are supposed to apply in the future

  • Give assurance that respondent will remain anonymous in any written reports growing out of the study, and that his responses will be treated with strictest confidence.

  • Indicate that he may find some of the questions far-fetched, silly or difficult to answer, for the reason that questions that are appropriate for one person are not always appropriate for another. Since there are no right or wrong answers, he is not to worry about these but to do as best he can with them. We are only interested in his opinions and personal experiences.

  • Interviewee is to feel perfectly free to interrupt, ask clarification of the interviewer, criticize a line of questioning etc.

  • Interviewer is to ask permission to tape record the interview, explaining why he wishes to do this.

1.2 A.2 Warm-up and Experience

  • What is your professional background (how long at the company, education)?

  • What is your role within the development life-cycle at Ericsson (short description)? Include information such as department, discipline (there are a number of pre-defined disciplines at the company for different development activities). How long have you been working in this role?

  • In which other disciplines have you been working and for how long?

  • What is your experience with traditional development and streamline development? Select from the following options with multiple selections being possible (has to be done once for each model):

    • No previous experience

    • Studied documentation

    • Informal discussion with colleagues

    • Seminar and group discussions

    • Used in one project (started or completed)

    • Used in several projects

1.3 A.3 Main Body of the Interview

1.3.1 A.3.1 Plan-Driven Development

The first question concerns bottlenecks.

Definition provided to the interviewee: Bottlenecks is a phenomena that hinders the performance or capacity of the entire development lifecycle due to a single component causing it (=bottleneck). Bottlenecks are therefore a cause for reduction in throughput.

Question: What are three critical bottlenecks you experienced / you think are present in the traditional way of working (plan-driven)?

When describing three bottlenecks, please focus on:

  • Which product was developed?

  • Where in the development process does the bottleneck occur?

  • Why is it a bottleneck (ask for the cause)?

  • How does the bottleneck affect the overall development lifecycle?

The following questions concern waste. When talking about waste, we distinguish two types of waste we would like to investigate. These types of waste are unnecessary work and avoidable rework. A definition for each type is presented to the interviewee.

Type 1—Avoidable Rework: Investigating avoidable rework helps us to answer: “are we doing things right”? That is, if something has been done incorrectly, incompletely or inconsistently then it needs to be corrected through reworked.

Question: What avoidable rework (three for each) has been done in the plan-driven approach?

When describing the avoidable rework, please focus on:

  • Which product was developed?

  • Where in the development process is the avoidable rework done?

  • What was done incorrectly, incompletely or inconsistently?

  • Why is the rework avoidable?

Type 2—Unnecessary work: Investigating unnecessary work helps us to answer: “are we doing the right things”? That is, unnecessary work has been conducted that does not contribute to customer value. It is not avoidable rework, as it is not connected to correcting things that have been done wrong.

Question: What is unnecessary work (three for each) done in the plan-driven approach?

When describing the unnecessary work, please focus on:

  • Which product was developed?

  • Where in the development process is the unnecessary work done?

  • Why is the unnecessary work executed?

  • How is the unnecessary work used in the development?

1.3.2 A.3.2 Incremental and Agile Approach

After having identified the critical issues in plan-driven development we would like to capture what the situation is after introducing the new incremental and agile practices.

Note: In this part the same questions were asked as was the case for the plan-driven approach, now focusing on the situation after migrating to the incremental and agile approach.

1.4 A.4 Closing

Is there anything else you would like to add that you think is interesting in this context, but not covered by the questions asked?

Appendix B: Example of the Qualitative Analysis

Figure 5 illustrates the analysis steps presented in the description of the research methodology with an example of the identification of factor F01 shown in Table 6.

Fig. 5
figure 5

Example of analysis illustrating the identification of factor F01

Full size image

Rights and permissions

Reprints and permissions

About this article

Cite this article

Petersen, K., Wohlin, C. The effect of moving from a plan-driven to an incremental software development approach with agile practices. Empir Software Eng 15, 654–693 (2010). https://doi.org/10.1007/s10664-010-9136-6

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10664-010-9136-6

Keywords

Search

Navigation