Although “everyone is doing it” is a reason to consider Agile it isn’t necessarily a reason to go Agile. I’ve thought it useful to outline reasons for going Agile and where possible provides research data to back up the argument. The data can be used to form the basis of a Business Case for Agile.
Originator Case Studies
All of the established Agile methods originated as more or less successful projects in a single organisation (e.g. Extreme Programming and Feature Driven Development).
The originators of Extreme Programming (XP) found that informal requirements gathering, iterative development, rigorous testing, a small development team, and early customer feedback turned around the failing payroll project (Anderson et al., 1998). This was the now famous Comprehensive Compensation System (C3), started in 1995.
The originators of Feature Driven Development (FDD) found that iterative development, a focus on quality at each step, and frequent delivery demonstrated tangible progress and turned around a failing project at an international bank in Singapore (Palmer & Felsing, 2002).
High Profile Adopters
BT used Agile to transform their delivery function (Hoffman, 2008).
Scrum is being picked up by the major new media organisations including BBC (Lyons & Evans, 2007), Yahoo (Scotland, 2007), and Google (Sutherland, 2006). Microsoft has also picked up Agile and is keen on Scrum (Begel & Nagappan, 2007).
Even NASA is using Agile (Gaudin, 2008). In fact NASA are using XP to write the code that controls the Mars Lander robot. New code is uploaded each day.
Agile in Tools
Many Agile-related ideas are going mainstream among programmers and as a result are starting to appear in development tools. For example Ruby-on-Rails directly supports the Agile practice of Test-Driven Development and automated testing. Even more telling, Microsoft’s new MSF specifically supports Agile development.
Surveys 1: Everybody is doing it
Everybody really is doing it, or, at least, many people are now saying they are doing it at least a bit, and more are doing so all the time.
In 2005 Forrester (Schwaber & Fichera, 2005) found Agile software development processes are in use at 14% of North American and European enterprises, and another 19% of enterprises are either interested in adopting Agile or already planning to do so.
Scott Ambler runs an annual Agile Adoption Rate Survey. In the 2007 (Ambler, 2007) 69% of the 789 respondents said their company was practicing Agile in some way. This is up from the 2006 results where 59% of the 4232 respondents made the same claim (Ambler, 2006).
Methods and Tools have also seen an upturn in the use of Agile, but report lower numbers. (Methods & Tools, 2008). They found the total rate of various adoption levels is now 56% (from 512 respondents) compared to 41% (from 232) in 2005.
Surveys 2: What people say Agile gives them
A variety of research studies have essentially surveyed a group of respondents on Agile Software Development. The results show Agile software development methods are associated with:
- Increased website quality
- Increased productivity
- Increased number of requirements satisfied
- Enhanced ability to manage change
- Increased quality
- Increased customer satisfaction
- Increased market share
- Decreased engineering effort
- Decreased cost
- Decreased time-to-market
- Improved alignment between the business and IT
In a survey of 29 software projects from 15 Internet firms MacCormack (1998) found that greater architectural resources and early market feedback were associated with higher website quality. The same study found that greater experience among the programmes was not associated with higher website quality.
In a study of 391 respondents Thomke and Reinertsen (1998) found that inflexible product technologies required over twice as much engineering effort as flexible product technologies. ?? What is a (in)flexible product technology ??
In a case study of 28 software projects Fichman and Moses (1999) found that software projects using iterative development delivered working software 38% sooner, completed twice as fast, and satisfied over twice as many software requirements.
Reifer Consultants studied 78 projects from 18 firms to determine the benefits of using Agile methods on software development (Reifer, 2003) 14-25% of respondents experienced productivity gains, 7-12% reported cost reductions, and 25-80% reported time-to-market improvements.
Shine Technologies conducted a similar study on the effects of using Agile methods in software development (Johnson, 2003). Of the 131 respondents, 49% reported cost reductions, 93% reported productivity increases, 88% reported quality increases, and 83% reported customer satisfaction improvements.
CIO Magazine found that 43 of the 100 information technology executives they surveyed were using Agile management to improve organisational growth and market share (Prewitt, 2004). The executives surveyed had an average annual budget of $270 million.
Of the 722 respondents to the 2006 The state of Agile development study by VersionOne (VersionOne, 2006), 86% of respondents reported improved time-to-market, 87% reported productivity improvements, 86% reported quality improvements, 63% reported cost reductions, 74% reported improved morale, 72% reported risk reductions, and 66% reported satisfaction of business goals.
VersionOne repeated their study in 2007 with 1,500 respondents (VersionOne, 2007). 90% of respondents reported increased productivity, 85% reported reduced software defects, 83% reported accelerated time-to-market, and 66% reported reduced cost.
Ambysoft surveyed 4,232 respondents on the effects of using Agile methods in software development (Ambler, 2006). 44% of respondents reported improvements in productivity, quality, and cost reductions, and 38% reported improvements in customer satisfaction.
Interestingly in the 2007 survey by Ambysoft of 781 respondents found that co-located Agile projects are more successful on average than non-co-located, which in turn are more successful than projects involving offshoring (Ambler, 2007).
It has to be said that little of this research is very strong. Most of the studies report respondents’ impressions of the effects of Agile methods. It would be preferable if some of the studies offered more detailed data showing direct effects of particular Agile methods on the desired outcomes.
Contrary Research
Arisholm et al. (2007) conducted an experiment on 295 professional Java consultants from 29 international consultancy companies in Norway, Sweden, and the UK. The study showed that pair programming in general does not reduce the time required to solve the tasks correctly nor increases the proportion of correct solutions.
Conclusions
Agile is on the increase. More and more organisations are going Agile or at least trying it. Evidence suggests over 50% of software development organisations are using some Agile practices.
The reported benefits of Agile – from surveys – are many and varied but include
- Increased website quality
- Increased productivity
- Increased number of requirements satisfied
- Enhanced ability to manage change
- Increased quality
- Increased customer satisfaction
- Increased market share
- Decreased engineering effort
- Decreased cost
- Decreased time-to-market
- Improved alignment between the business and IT
It has to be said that little of this survey research is very strong. Most of the studies report respondents’ impressions of the effects of Agile methods rather than measuring the effects directly.
Detailed research on specific practices is more scarse.
References
Ambler, S. W. (2006). Agile Adoption Rate Survey: March 2006. [Available on-line http://www.ambysoft.com/surveys/AgileMarch2006.html.]
Ambler, S. W. (2007). Agile Adoption Rate Survey: March 2007. [Available on-line http://www.ambysoft.com/surveys/AgileMarch2007.html.]
Anderson, A., Beattie, R., Beck, K., Bryant, D., DeArment, M., Fowler, M., et al. (1998). Chrysler goes to extremes. Distributed Computing Magazine, 1(10), 24-28.
Arisholm, Gallis, Dybå, & Sjøberg. (Feb., 2007). Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise. IEEE Transactions on Software Engineering, 33(2), 65-86.
Begel, A., & Nagappan, N. (2007). Usage and Perceptions of Agile Software Development in an Industrial – An Exploratory Study. Microsoft Research. [Available on-line http://research.microsoft.com/hip/papers/AgileDevAtMS-ESEM07.pdf.]
Dybå, T., & Dingsøyr, T. (2008). Empirical Studies of Agile Software Development: A Systematic Review. Information and Software Technology. [Available on-line http://www.sintef.no/improve/downloads/articles/ist2008_dyba_dingsoyr.pdf.]
Fichman, R. g., & Moses, S. A. (1999). An incremental process for software implementation. Sloan Management Review, 40(2), 39-52.
Gaudin, S (2008). NASA: ‘Extreme programming’ controls Mars Lander robot. Computer World. [Available on-line http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9094138&pageNumber=1.]
Hoffman, T. (2008). How BT embraced agile programming. Computer World UK. [Available on-line http://www.computerworlduk.com/technology/development/software/in-depth/index.cfm?articleid=1236.]
Johnson, M. (2003). Agile methdologies: Survey results.Victoria, Australia: Shine Technologies.
Lyon, R., and Evans, M. (2007). Scaling Up – pushing Scrum out of its comfort zone. XPDay. [Available on-line http://www.xpday.org/node/141.]
MacCormack, A. (1998). Managing adaptation: an empirical study of product development in rapidly changing environments. Unpublished doctoral dissertation, Harvard University, Boston, MA, United States.
Methods & tools (2008). Adoption of Agile Methods. Author. [Available on-line http://www.methodsandtools.com/dynpoll/oldpoll.php?Agile2.]
Palmer, S. R., & Felsing, J. M. (2002). A practical guide to feature driven development. Upper Saddle River, NJ: Prentice Hall.
Prewitt, E. (2004). The Agile 100. CIO Magazine, 17(21), 4-7.
Reifer, D. J. (2003). The business case for Agile methods/extreme programming (XP). Proceedings of the Seventh Annual PSM Users Group conference, Keystone, Colorado, USA, 1-30.
Rico, D. F. (2007). Effects of Agile methods on website quality for electronic commerce. Unpublished doctoral dissertation, United States. [Available on-line http://trailridgeconsulting.com/blog/?p=102.]
Scotland, K. (2007). Integrating Scrum with the Process Framework at Yahoo!. Agile Practitioners. [Available on-line
http://agilepractitionersforum.com/2007/11/23/integrating-scrum-with-the-process-framework-at-yahoo/.]
Schwaber, C., and Fichera, r. (2005). Corporate IT Leads The Second Wave Of Agile Adoption. Forrester. [Available on-line http://www.forrester.com/Research/Document/Excerpt/0,7211,38334,00.html.]
Sutherland, J. (2006). Scrum Tuning: Lessons learned from Scrum implementation… Google Tech Talks. [Available on-line http://www.youtube.com/watch?v=9y10Jvruc_Q.]
Thomke, S., & Reinertsen, D. (1998). Agile product development: Managing development flexibility in uncertain environments. California Management Review 41(1), 8-30.
VersionOne (2006). The state of Agile development. Apharetta, GA: Author.
VersionOne (2007). The state of Agile development. Apharetta, GA: Author. [Available on-line http://www.versionone.com/Agilesurvey/index.asp.]