Best Practices for Implementing Agile Methods: A Guide for Department of Defense Software Developers

The Department of Defense needs to respond quickly to changing threats and requirements. Increasingly, this rapid response capability requires an ability to field new software applications quickly as well. Traditional software development methods can take too long, cost too much, or lead to a solution to a requirement that is not in fact what the user really needed. Agile software methods offer many advantages, including speed. They also have the ability to evolve quickly to meet users' real, as opposed to apparent, needs. In addition, they are cheaper than more traditional methods. Though not a panacea, agile methods offer a solution to an important class of problems faced by organizations today. This report offers a guide to how Department of Defense (DoD) organizations can use agile methods to meet DoD's mission more quickly and effectively at a lower cost. The best practices outlined in this report come from interviews with 11 project teams that have used agile methods to meet mission requirements. The techniques described have applicability to any organization facing fast-changing problems, the need to act and adjust quickly, and limited budgets. Agile software methods, like any software methodology, require technical sophistication, but it would be a mistake to focus only on the technical aspects. Because agile software methods represent a change from traditional approaches, organizational factors are very important. The culture of the organization needs to be open to change, not entrenched in traditional approaches. Communication must be open, and information should flow easily among participants. The information technology infrastructure must be robust. Using agile software methods will take sustained leadership from senior executives to be successful. It is too large a change from traditional practice to simply be delegated and delivered. The authors of this report found that a best practice is to form a small team, give team members good tools, start on small projects, and expand based on early successes. The team needs to have a " can do " attitude, be experienced problem solvers, and work well together in an atmosphere of mutual trust. These factors are as important as domain knowledge. As the organization builds experience with agile techniques and success builds credibility, their use can spread to other areas. The organization will then have the opportunity to make further improvements based on firsthand knowledge of what works. The best practices for implementing agile software methods are the same as for rolling out …

[1]  K. Beck,et al.  Extreme Programming Explained , 2002 .

[2]  Robert L. Glass,et al.  Matching methodology to problem domain , 2004, CACM.

[3]  Jeff Sutherland,et al.  Future of scrum: parallel pipelining of sprints in complex projects , 2005, Agile Development Conference (ADC'05).

[4]  Jeff Sutherland,et al.  Scrum and CMMI Level 5: The Magic Potion for Code Warriors , 2007, AGILE.

[5]  Bob Schatz,et al.  Primavera gets agile: a successful transition to agile development , 2005, IEEE Software.

[6]  Kent L. Beck,et al.  Extreme programming explained - embrace change , 1990 .

[7]  Richard T. Watson,et al.  Key Issues in Information Systems Management: An International Perspective , 1997, J. Manag. Inf. Syst..

[8]  AGILE DEVELOPMENT : LESSONS LEARNED FROM THE FIRST SCRUM , 2004 .

[9]  Tim Murphy,et al.  Extreme maintenance , 2001, Proceedings IEEE International Conference on Software Maintenance. ICSM 2001.

[10]  A. Cockburn,et al.  Agile Software Development: The People Factor , 2001, Computer.

[11]  John Armitage,et al.  Are agile methods good for design? , 2004, INTR.

[12]  Agile Manifesto,et al.  Manifesto for Agile Software Development , 2001 .

[13]  Miroslav Novak,et al.  A Practical Guide to eXtreme Programming , 2002 .

[14]  Barry W. Boehm,et al.  Value-based software engineering: reinventing , 2003, SOEN.

[15]  Linda Rising,et al.  The Scrum Software Development Process for Small Teams , 2000, IEEE Softw..

[16]  Jim Shore Continuous design , 2004, IEEE Software.

[17]  Barry W. Boehm,et al.  Get Ready for Agile Methods, with Care , 2002, Computer.

[18]  Mark C. Paulk,et al.  Extreme Programming from a CMM Perspective , 2001, IEEE Softw..

[19]  Peng Xu,et al.  How extreme does extreme programming have to be? Adapting XP practices to large-scale projects , 2004, 37th Annual Hawaii International Conference on System Sciences, 2004. Proceedings of the.

[20]  Barry W. Boehm,et al.  A spiral model of software development and enhancement , 1986, Computer.

[21]  W. W. Royce,et al.  Managing the development of large software systems: concepts and techniques , 1987, ICSE '87.

[22]  Suzanne Smith,et al.  What we can learn from extreme programming , 2001 .

[23]  Robert C. Martin Soapbox - eXtreme Programming Development through Dialog , 2000, IEEE Softw..

[24]  Gabrielle Benefield,et al.  Rolling Out Agile in a Large Enterprise , 2008, Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 2008).

[25]  Ann L. Fruhling,et al.  Designing and Evaluating Collaborative Processes for Requirements Elicitation and Validation , 2007, 2007 40th Annual Hawaii International Conference on System Sciences (HICSS'07).

[26]  Jeff Sutherland,et al.  Scrum and CMMI Level 5: The Magic Potion for Code Warriors , 2007, Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 2008).

[27]  Ann L. Fruhling,et al.  An Empirical Study Examining the Usage and Perceived Importance of XP Practices , 2007, AMCIS.

[28]  Laurie Williams,et al.  The costs and benefits of pair programming , 2001 .

[29]  Alistair Cockburn,et al.  Agile Software Development: The Business of Innovation , 2001, Computer.

[30]  Amr Elssamadisy,et al.  Recognizing and responding to "bad smells" in extreme programming , 2002, ICSE '02.

[31]  Kent L. Beck,et al.  Embracing Change with Extreme Programming , 1999, Computer.

[32]  Alistair Cockburn,et al.  Agile Software Development , 2001 .

[33]  Thomas E. Potok Extensions to the spiral model to support joint development of complex software systems , 1992, ACM-SE 30.

[34]  Matthias M. Müller,et al.  On the economic evaluation of XP projects , 2003, ESEC/FSE-11.

[35]  Michael Henderson,et al.  Making agile development work in a government contracting environment-measuring velocity with earned value , 2003, Proceedings of the Agile Development Conference, 2003. ADC 2003.

[36]  Rudy Hirschheim,et al.  A Dynamic Framework for Classifying Information Systems Development Methodologies and Approaches , 2000, J. Manag. Inf. Syst..