Skip to content

📚 Agile

Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it. — Agile Alliance

Manifesto

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Authors of The Agile Manifesto
from communities of various "Lightweight Methods" (re-named to "Agile"):
Kent Beck , Extreme Programming (XP)
Ward Cunningham , Extreme Programming (XP)
Martin Fowler , Extreme Programming (XP)
James Grenning , Extreme Programming (XP)
Jim Highsmith , Adaptive Software Development (ASD)
Andrew Hunt , The Pragmatic Programmer (PragProg)
Ron Jeffries , Extreme Programming (XP)
Jon Kern , Feature-Driven Development (FDD)
Robert C. Martin , Extreme Programming (XP)
Dave Thomas , The Pragmatic Programmer (PragProg)

Principles

Principles behind The Agile Manifesto
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily 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 method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Timeline

Agile Practices Timeline

based on the timeline from Agile Alliance with fewer items:

1970s Wideband Delphi

Barry Boehm proposes “Wideband Delphi”, a forerunner of Planning Poker.

1976 Automated Unit Testing

A series of articles by D. Panzl describing tools with features closely resembling those of JUnit attest to the long history of automated unit testing.

1977 Automating Software Builds

Creation of the “make” tool for Unix systems – the principle of automating software builds is not a new idea.

1980 Visual Control

The notion of “visual control” originating in the Toyota Production System is an anticipation of “information radiators”.

1984 Knowledge-based communication processes

While criticisms of the “waterfall” sequential approach have started much earlier, formulations of alternative incremental approaches are becoming more pointed; a good example is an early paper on ”Knowledge-based communication processes in software engineering” advocating incremental development for the specific reason that “complete and stable specifications are not available”.

1985 Evolutionary Delivery Model

Perhaps the first explicitly named, incremental alternative to the “waterfall” approach is Tom Gilb’s Evolutionary Delivery Model , nicknamed “Evo”.

1986 Scrum Framework Inspiration

Takeuchi and Nonaka publish their article ”The New New Product Development Game” in Harvard Business Review. The article describes a rugby approach where “the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish.” This article is often cited as the inspiration for the Scrum framework.

1988 Rapid Iterative Production Prototyping

The “timebox” is described as a cornerstone of Scott Schultz’s “Rapid Iterative Production Prototyping” approach in use at a Du Pont spin-off, Information Engineering Associates.

1990 Refactoring

Bill Opdyke coins the term “refactoring” in an ACM SIGPLAN paper with Ralph Johnson, “Refactoring: An aid in designing application frameworks and evolving object-oriented systems”

1991 Rapid Application Development

RAD, possibly the first approach in which timeboxing and “iterations” in the looser sense of “one repetition of the entire software development process” are closely combined, is described by James Martin in his ”Rapid Application Development” . This book also describes the details of the timebox in one of its chapters.

1992 Dynamic Duo Coding

“Dynamic Duo” is the term coined by Larry Constantine, reporting on a visit to Whitesmiths Inc., a compiler vendor started by P.J. Plauger, one of the implementors of C: “At each terminal were two programmers! Of course, only one programmer was actually cutting code at each keyboard, but the others were peering over their shoulders.” Whitesmiths existed from 1978 to 1988.

1993 The Benefits Of Collaboration For Student Programmers

“The benefits of collaboration for student programmers” by Wilson et al. is one early empirical study indicating benefits of pairing for programming tasks specifically. Posterior studies are more abundant and driven by the desire to “validate” pair programming after it had already gained popularity through Extreme Programming.

1993 Stand-Up Meeting Pattern

Jim Coplien writes the original Stand-Up Meeting pattern.

1993 Continuous Integration

The phrase “continuous integration” is already in use and thus predates what will later be known as Agile processes, for instance an article written this year contrasts it with “scheduled” integration, and recommends the latter, citing “lack of thorough testing” as one issue with continuous integration; this helps explain why the automated testing favored by Agile teams is an enabler for continuous integration.

1993 Invention Of Scrum

Jeff Sutherland invents Scrum as a process at Easel Corporation.

1995 Growth Of Human Factors In Application Development

An article by Alistair Cockburn, ”Growth of human factors in application development”, suggests one major reason why iterative approaches gradually gain acceptance: the bottleneck in software development is shifting to (individual and organizational) learning, and human learning is intrinsically an iterative, trial and error process.

1995 Sprint As Iteration

The earliest writings on Scrum introduce the notion of the “sprint” as iteration, although its duration is variable.

1995 Formal Introduction Of Scrum

Ken Schwaber and Jeff Sutherland co-present Scrum at the OOPSLA Conference.

1996 Daily Build And Smoke Test

Steve McConnell describes the “Daily Build and Smoke Test” technique, used at Microsoft for Windows NT 3.0 during the 1990’s; the emphasis is not so much on the automation as on the frequency, the daily cycle being at that time considered “extreme”.

1996 Acceptance Testing

Automated tests are a practice of Extreme Programming, without much emphasis on the distinction between unit and acceptance testing, and with no particular notation or tool recommended.

1997 Daily Scrum

Ken Schwaber describes the “daily scrum” (which does not appear in his earlier writings, such as the 1995 article “SCRUM Development Process”), this is later recast in pattern form by Mike Beedle .

1998 Extreme Programming

The earliest article about Extreme Programming, “Chrysler goes to Extremes”, describes several XP practices such as self-chosen tasks, test first, three week iterations, collective code ownership, and pair programming.

1999 System Metaphor

Early on in the elaboration of Extreme Programming, the “System Metaphor” practice is proposed to address the issues of business-technical translation and cognitive friction, however the practice is poorly understood and fails to catch on.

1999 Iterative And Incremental

In an article for the C++ Report, Robert C. Martin gives what is perhaps the earliest description of the Agile sense of the terms “iterative” and “incremental”.

1999 Refactoring Popularized

The practice of “refactoring”, incorporated a few years earlier into Extreme Programming, is popularized by Martin Fowler’s book of the same name.

2001 Agile Manifesto authored

Bob Martin called a “Lightweight Process Summit” to create a manifesto that outlined similarities between all the various lightweight processes. The 17 attendees decided to use the term “agile” and wrote the “Manifesto for Agile Software Development”. Some of the authors wrote up their recollections of writing the Agile Manifesto: Bob Martin , Martin Fowler , Dave Thomas , Jim Highsmith .

2009 Srumban

Corey Ladas suggested that Kanban could improve upon Scrum and suggested Scrumban as the transition from Scrum to Kanban in his book Scrumban – Essays on Kanban Systems for Lean Software Development .

2010 Kanban

David J. Anderson publishes Kanban: Successful Evolutionary Change for Your Technology Business as the first description of the method.

Frameworks and Practices

The Agile Subway Map from Agile Alliance is an excellent representation of major Agile frameworks and practices.

Extreme Programming (XP) focuses on practices and was the dominant Agile method in the late ’90s and early ‘00s.

Extreme programming practices
Extreme programming has 12 practices, grouped into four areas:

Scrum focuses on managing the flow of work and became dominant in the mid-’00s.

Adoption

Agile rapidly gained popularity within just a few years, which brought some problems. Several authors of the Agile Manifesto wrote about their concerns and suggestions:

Problems

The common problems are:

  • Instead of the values and principles, only project management processes are applied.
  • These project management processes (normally Scrum) are imposed on the team.

Which contradict the first value of Agile:

Individuals and interactionsoverprocesses and tools

And some of the principles:

  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The best architectures, requirements, and designs emerge from self-organizing teams.

Another Agile Manifesto author, Robert C. Martin (Uncle Bob), also talked about this in a recent interview (2024):

The project managers flooded into Agile to be “Certified ScrumMaster”, took over “Agile” and pushed programmers out. “Agile” became a project management idea.

Suggestions

The articles from the Agile Manifesto authors made similar suggestions:

Firstly, “back to the values and principles”. Agile is People Oriented , teams should be “self-organizing”, choose their own process and control how that process evolves.

Secondly, apply strong technical practices. The XP practices make a good starting point.

“Scrum is just XP without the technical practices that make it work.”

(XP is) “The Scrum That Actually Works”.

💭 My thoughts

The problem Agile try to solve:

Instead of failing in the end of a long painful waterfall process, how can a team keep delivering real value and respond to changes?

The answer is “early and continuous delivery” of “Working software”, with “Customer collaboration” and “Responding to change”.

For that we need “agility”, via “Individuals and interactions” of an empowered, self-organizing team, and strong technical practices.

Continuous attention to technical excellence and good design enhances agility.

However, after the project managers took over “Agile” via Scrum, engineering practices were omitted.

DevOps movement seems to me like the software engineers then splintered from “Agile” and expanded some of the XP practices (e.g. “Continuous integration” and “Small releases” ).

With modern DevOps and Continuous Delivery , iterations can be so small that some Agile practices, like the XP Planning Game , may no longer be needed.