The agile practises we use are inspired by agile methodologies in the original Agile Manifesto. It is interesting to track the development of these methodologies, and consider how they have evolved to serve our business today.
Now companies can be confronted with frequent changes due to innovations and new technology. New concepts such as cloud-based services, big data and digitalization are spreading into all markets. Innovation can be achieved ‘at pace’ with a combination of software and new types of devices. Consequently, the amount of software and connected solutions across industry has increased exponentially during the last decade and it has become a competitive advantage to develop and distribute high-quality software and connected solutions. This agile transformation of organisations is a frequently discussed topic as agile ways of working promise to make companies future-proof.
The rise of agile practice started to become significant 17 years ago, alongside other new project management languages such as Six Sigma. The manifesto for project management was increasingly known as agile software development it was often referred to as the ‘Agile Manifesto’.
Trade publishing at the time interpreted the statements from the manifesto to formalise agile principles and practices. The manifesto is often referred to when developers plan agile developments, and key development principles evolved from:
- Uncovering better ways of developing software by implementation and teaching
- Learning to value human interaction over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Adapting to change rather than rigidly following a plan
The Manifesto was written by 17 software practitioners in 2001 and examined interest in ‘Extreme Programming’ – now recognised as ‘XP’, which sought to improve the working conditions for developers. The manifesto for agile software development seemed to promise a more successful way of developing software than by simply following the original values and principles that were practised thus far, and this was one reason for its success.
‘Iterative and Incremental Software development’ (IID), started in the early 1970s and arguably culminates with the manifesto in 2001. The relationship between the IID mindset and agile methods started in the 1930s with the idea of ‘plan-do-study-act’ cycles. Several projects, such as NASA’s project Mercury (the first human spaceflight program of the United States) or the software development for the US Navy’s helicopter-to-ship weapon system applied IID practices. Practices such as short iterations and test-first development were already being used and remain present in agile methods such as Scrum or XP.
In the 1970s, managing large software developments and considering what is ‘necessary to transform a risky development process into one that will provide the desired product’ produced an approach aimed at reaching the condition of working software delivered on-time and within costs known as the ‘Waterfall Model’ (Royce 1970). Royce proposed to use the waterfall model’s phases with an ‘iterative’ relationship between successive phases, benefitting by confining the development process to manageable limits and using prototypes to get early simulations of the final product.
In the 1980s, many approaches of incremental software development were presented, such as Boehm’s ‘Spiral Model’ (Boehm 1986). The spiral model is a risk-driven approach to software development that resulted from a ‘risk-management variant of the waterfall model’ where the development process is divided into several circles which include steps like risk analysis, circle planning and reviews. This risk-driven approach proved more adaptable than prior document-driven (waterfall) and code-driven (evolutionary development) approaches.
The work of Boehm and others led to the development of ‘Rapid Iterative Production Prototyping’ (RIPP) in the mid-to-late 1980s (Du Pont). This project management methodology was instrumental in introducing ‘time-boxed’ development and customer collaboration bringing further benefits and leading to the creation of the ‘Rapid Application Development’ (RAD).
The RAD approach included a quick delivery with a small team of highly skilled developers and set the basis for the ‘Dynamic Systems Development Method’ (DSDM), which had a wide user audience in north-west Europe such as the United Kingdom, the Netherlands, Sweden, and Denmark.
DSDM, first published in February 1995, is an agile framework developed and supported by the DSDM Consortium for dynamic, non-predictable projects. It focuses on early delivery in an iterative development process with close customer collaboration. Now it also includes project management (the Agile PM Framework).
It consists of seven phases including preparation of a project and deployment to the customer. One practice of DSDM is ‘time-boxing’. The project is sliced into time-boxes which could themselves be sliced into smaller time-boxes, and requirements are prioritised accordingly.
Several decades of software development and best practices from development approaches and applications in industry resulted in a practitioners’ meeting in Utah in 2001, where the most suitable techniques were combined within the Manifesto for Agile Software Development.
after the manifesto
It is interesting to consider the evolution of agile software development after 2001. Diverse theoretical approaches and numerous points of view on the manifesto, the practices used, the implementation of the principles, or human involvement has led to much discussion in the last 16 years.
Dingsøyr et al. (2012) present a literature review of the evolution in the agile community of over 1551 papers on agile development until 2010. This reflects the still increasing interest in adapting agile methods whose applications are considered in many different contexts and combinations.
Theocharis et al. (2015) conducted a literature study in 2015 resulting in a variety of different development approaches. The approaches identified often came from a combination of traditional and agile methods. They called those combinations hybrid approaches and identify the method Water-Scrum-Fall (Theocharis et al. 2015) as the most widely used. This model, a combination of the Scrum and Waterfall model, is seen as one approach to the adaption of agile elements into traditional development approaches.
Kuhrmann et al. (2017) set up the HELENA study in 2017 to figure out how hybrid approaches have spread into the development of software worldwide.
The HELENA team, consisting of more than 80 researchers from all over the world, investigates the distribution of hybrid software and system development in practice. The HELENA study is ongoing and results have not yet been presented.
In 2002, Abrahamsson published a literature review aiming at the analysis of agile methods. They analysed ten methods such as Extreme Programming and Scrum which are characterised as ‘being agile’ with respect to the authors’ definition. Furthermore, they compared the similarities and differences between these methods.
In 2013, Pathak and Saha again reviewed different agile methods and compared them with conventional process methods. Furthermore, they analysed the pros and cons of applying these agile processes to projects. The contribution focused on existing literature in that field, instead of presenting the thoughts of those who started ‘thinking agile’.
In 2002, Highsmith described the most important principles of agile development, such as delivering value to the customer and focusing on individual developers and their skills. He also presented all major agile methods such as Scrum or Extreme Programming with proposals of a method of transforming a company into a truly agile organization. Highsmith mentions that the success of the Manifesto is that the focus was on the similarities of the methodologies for software development.
It is this reason why Agile is still valid and we are able to adapt and utilise it in our ever-growing business. It is not based on processes that can easily date, rather on values and principles that are able to evolve.
