đ 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
Authors of The Agile Manifesto
Principles
Principles behind The Agile Manifesto
Timeline
Agile Practices Timeline
based on the timeline from Agile Alliance with fewer items:
Barry Boehm proposes âWideband Delphiâ, a forerunner of Planning Poker.
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.
Creation of the âmakeâ tool for Unix systems â the principle of automating software builds is not a new idea.
The notion of âvisual controlâ originating in the Toyota Production System is an anticipation of âinformation radiatorsâ.
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â.
Perhaps the first explicitly named, incremental alternative to the âwaterfallâ approach is Tom Gilbâs Evolutionary Delivery Model , nicknamed âEvoâ.
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.
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.
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â
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.
â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.
â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.
Jim Coplien writes the original Stand-Up Meeting pattern.
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.
Jeff Sutherland invents Scrum as a process at Easel Corporation.
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.
The earliest writings on Scrum introduce the notion of the âsprintâ as iteration, although its duration is variable.
Ken Schwaber and Jeff Sutherland co-present Scrum at the OOPSLA Conference.
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â.
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.
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 .
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.
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.
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â.
The practice of ârefactoringâ, incorporated a few years earlier into Extreme Programming, is popularized by Martin Fowlerâs book of the same name.
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 .
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 .
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
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:
- Martin Fowler: Agile Imposition (2006)
- Martin Fowler: Flaccid Scrum (2009)
- Dave Thomas: Agile is Dead (Long Live Agility) (2014)
- Ron Jeffries: Developers Should Abandon Agile (2018)
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:
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.