Agile software development refers to a process that follows principles and practices which looks to resolve a number of the issues associated with more traditional software development methodologies such as the Waterfall approach.


Agile software development is a set of lightweight methodologies, some of which had been earlier applied in software development and were embodied by Kent Beck, Ward Cunningham and others. These processes, such as Scrum and Extreme Programming were known to be in existence since the 1990s however came together in 2001 under the Agile umbrella with the introduction of the Agile Manifesto.

Agile adoption has increased significantly in the past years. In fact it has more than doubled from 17% in 2006 to 35% in 2009 (Forrester Research 2007, 2010). This increase can be attributed to a desire to move away from the failure experienced within traditional and waterfall development methodologies and a desire to better control the software development process (Cohen, 2010).


Agile software development can be defined as a set of lightweight project management methodologies, engineering best practices, development concepts and tools that are oriented towards fast delivery of high quality software, alongside consideration of rapidly changing requirements, placing an emphasis on team and customer collaboration, working software and unburdened by bureaucracy (Holcombe, 2008 and Stober, 2010).

According to Forrester in 2007, there are 5 distinct processes that separate Agile Development from other more traditional development methodologies.
  1. Regular delivery of working software. Agile emphasizes working software rather than complex documentation and functions descriptions. In order to achieve this the whole product process is broken into iterations – small time boxes with durations of between one to four weeks. The task of each iteration is to deliver a set of system functions that are successfully tested, have minimal bugs and are completed in order to present to the customer (Schiel, 2010).
  2. The phases in each iteration overlap slightly, in other words each iteration contains full development cycle, including planning, requirements collecting, design and testing. This enables the project team competently allocate activities in each iteration and makes it possible to fit into a short period of time (Manandhar, 2008).
  3. Specific engineering practices (such as Test Driven Development and Re-factoring) are used to keep the code base of high quality and flexible.
  4. Teams are self-managing. In Agile projects the hierarchy of the teams are not as defined as in other development strategies. The management style in this type of project is bottom-up rather than top-down. Typically, after discussing and collecting requirements team members take responsibility to deliver particular features in each iteration.
  5. Elimination of waste whenever possible. This principle is taken from Lean manufacturing that implies taking important decisions as late as possible and to avoid investing significant effort on planning and extensive analysis.

Agile methodologies

A number of Agile methodologies have been identified from a number of user surveys. The Forrester Report (2010) identifies 13 different Agile Methodologies, including Scrum and Extreme Programming. With this accounting for 35% of the methodologies being used, it makes Agile the most popular software development technique currently used within the sample size. The 13 methodologies identified in the Forrester Report are:


  • Agile Development methods are 'adaptive rather than predictive' (Paestch et al, 2003), and are therefore more suited to handling requirement change than more traditional development methodologies. It also makes them ideal in circumstances when the customer may not be certain of what they require. Due to the nature of short iterations and close customer collaboration, the customer is in a position to provide feedback from a much earlier stage.

  • Further benefits identified by Schiel (2010) include:
    • Improved software quality.
    • Improved organisational commitment though using cross-functional and self-organising teams.
    • Reduced waste.
    • Improved customer relationship.

  • Douglas also identifies early return on investment (ROI); increased control; responsiveness to change and earlier and greater reduction to project risk (Douglas, 2009). In addition, Forrester notices such positive moments of Agile adaptation as better predictability; better morale and reduced time-to-market (Forrester Research, 2007).

  • Agile techniques are modular so they can be used in an existing culture without destroying what made that culture effective in the first place. Striebeck (2006) showed how agile techniques worked effectively within Google's bottom up culture without disrupting it.


  • There is a common misconception about a lack of planning, in particular the overall architecture planning, within Agile Software Development. Whilst it is true that months of planning are often removed from the project life-cycle, planning is present within every iteration, and the overall architecture evolves and improves via the use of re-factoring methods. Some Agile teams also give way to introducing an Iteration 0 which is used for general planning and discussion. Many software developers believe that the up-front design provides very few benefits to the software development life-cycle (Babar, 2009).

  • There is also a risk that the values of Agile Software Development are misinterpreted. A common example would be working software over comprehensive documentation. This gives rise to teams believing that documentation is non-existent, rather than seeing the value as to produce working software rather than copious amounts of documentation.

  • Pikkarainen et al. (2008) suggested that highly experienced developers could be extremely reluctant to change practices that they saw as effective to fit in with new/Agile processes.


Babar, M. (2009) An Exploratory Study of Architectural Practices and Challenges in Using Agile Software Development Approaches, IEEE Software Architecture & European Conference on Software Architecture 2009
Cohen, G. (2010) Agile Excellence for Product Managers. Silicon Valley: SuperstarPress.
Douglas, P.B. (2009) Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development. New Jersey: Pearson Education
Forrester Research (2007) The Truth About Agile Processes. Frank Answers To Frequently Asked Questions. Available at [Accessed: 3 February, 2012].
Forrester Research (2010) Agile Development: Mainstream Adoption Has Changed Agility. Available at [Accessed: 3 February, 2012].
Holcombe, M. (2008) Running an Agile Software Development Project. New Jersey: John Wiley & Sons, Inc.
Manandhar, N. (2008) Agile Software Development. Available at: [Accessed: 7 February, 2012].
Paetsch, F., Eberlein, A. and Maurer, F (2003) Requirements Engineering and Agile Software Development, Proceedings of the Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises 2003
Pikkarainen, M., Haikara, J., Salo, O., Abrahamsson, P. & Still, J. (2008) 'The impact of agile practices on communication in software development'. Empirical Software Engineering (13). pp. 303-337.
Stober, T. and Hannsmann, U. (2010) Agile Software Development: Best Practices for Large Software Development Projects. Verlag Berlin Heidelberg: Springer.
Schiel, J. (2010) Enterprise-Scale Agile Software Development. Boca Raton: Taylor and Francis Group, LLC
Striebeck, M.(2006) Shh! We are adding a process...: Proceedings form the Agile 2006 Conference.IEEE Computer society.

Subject Author Replies Views Last Message
No Comments