History of Agile

History of Agile - The Agile approach originated in the IT world in the eighties and nineties. At that time, there was a need for a more hands-on approach compared to the traditional waterfall method. Winston W. Royce (1929-1995), the named creator of the waterfall method, developed the method in 1970 with sequential steps to deliver software within budget and time. When a phase was completed, this was accompanied by a large amount of documentation. A completed phase could no longer be modified and was considered complete. Criticism of this waterfall method was that it was not very flexible with regard to changing requirements during the development process. The Waterfall model assumes that what has been determined in advance is no longer subject to change (Venneman, 2013). However, experience has shown that, partly due to the long lead time, the requirements of the deliveries are subject to change during the process (De Jonge, 2009). As a result, it was possible that at the end of the process the delivered software no longer met the wishes and requirements of the end user. Also, the extensive documentation was seen as a waste of time, rather than a support tool during the development process (Boehm, 1988). Completing a specification per phase was experienced as a major obstacle, because feedback obtained afterwards could no longer be processed in the relevant specification (Sommerville, 1996).

In response to this, a number of lightweight software methods were developed, such as Extreme Programming (XP), Crystal, Scrum and Adaptive software development (ASD). The approach within these methods is characterized by keeping the number of rules and regulations small and simple (Thomas et al., 2001). A number of software developers using these methods got together at one point to informally share their thoughts and experiences. During this meeting, the group found that they shared many views on software development and the approach used. they used in this. They have incorporated the values ​​they shared in this in the Agile Manifesto. The Agile Manifesto consists of a description of the values ​​shared by the seventeen authors and a dozen principles that support these values.

The Agile Manifesto

We show there are better ways to develop software
by demonstrating in practice that this works
and by helping others. That's why we prefer:

People and their mutual interaction over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiations
Responding to change over following a plan

While we appreciate all that is stated to the right,
we attach more importance to what is mentioned on the left.

Behind the Agile Manifest are a number of principles that are followed.

• Our top priority is customer satisfaction through early and continuous delivery of valuable software.
• Welcome changing needs, even late in the development process.
• Agile processes leverage change to the customer's competitive advantage.
• Deliver working software regularly. Preferably every few weeks, at most every few months.
• Business people and developers have to work together on a daily basis throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
• The most efficient and effective way to share information in and with a development team is by talking to each other.
• Working software is the most important measure of progress.
• Agile processes promote constant development. The clients, developers and users must be able to sustain a constant pace forever.
• Constant attention to high technical quality and good design enhance agility.
• Simplicity, the art of maximizing the work not being done, is essential.
• The best architectures, requirements and designs arise from self-managing teams.
• At set times, the team examines how it can become more effective and then adjusts its behavior accordingly.

History of Agile

Agile literally means: “agile, nimble”. In the ICT world, it stands for the development of software in short and well-arranged periods. These periods are called 'iterations' and are, as it were, small projects, in which working software is delivered each time. In agile development, the team involved works very closely together and communicates continuously in person, with each other and with other parties involved in the project. The team almost always tries to deliver something useful at the end of each iteration. After each iteration, thanks to customer feedback, the developers reconsider the interim results and adjust them where necessary.

In the meantime, agile has also found its way outside of ICT. The focus on customer value, self-organizing teams and the delivery of interim results appear to be of added value throughout the organization. Agile can be used alongside, for example, Lean and Six Sigma. Where Lean focuses on eliminating waste and Six Sigma focuses on process improvement, agile focuses on continuously delivering as much customer value as possible by delivering valuable products or services in iterations.

More information about the added value of Agile can be found in 'The critical success factors of agile'.

Source list:
Boehm, B.W. (1988). A spiral model of software development and enhancement† Computer, 21(5), 61–72. IEEE Computer.
Gerrits, T., Groot, R. de. & Venneman, (2013). Agile, pocket guide for agile organizations. Zaltbommel: Van Haren Publishing.
Young, M. de. (2009). Agile web development. http://naarvoren.nl/artikel/agile_webontwikkeling/.
Royce, W. (1970). Managing the development of large software systems† In Proceedings of IEEE Westcon.
Summerville, L. (1996). Software process models. ACM Computing Surveys. 28(1), 269-71.
Thomas, D. et al (2001). agile manifesto. http://agilemanifesto.org.