The last software development practice
diluting agile software development until one thing remains 2026-10-27 #agile
Allen Holub recently posted something interesting about agile software development:
Though I’m probably nuts to flog the Agile dead horse, I have to point out that the only concrete practice in the Agile Manifesto is the retrospective. […] If Agile is a “methodology” (it isn’t), the only method it requires is continuous improvement.
Indeed, not only does the Manifesto for Agile Software Development only mention one practice, but after its four values, it appears last in the list of twelve principles:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
I found this interesting, because while the agile manifesto focused on values and principles, our concrete practices reveal how we interpret agile software development.
Revealed preferences
Scrum eventually became unfashionable on software development teams, and Kanban proved too difficult to become standard practice. Since then, software development teams find it harder to identify the least controversial way to work.
In economics, revealed preference theory explains understanding consumer preferences by observing their actual behaviour. Loosely adapted to software development methodology, we can make the analogy that despite what software development teams might tell you, looking at how they actually work reveals that waterfall thinking persists in the workplace.
Revealed preference theory’s weaknesses include its inability to reveal which options people discarded before making a choice. A software development team may show off the classic agile methodology books on their bookshelf, while the forces and constraints on how they actually work remain hidden.
Agile manifesto obsolescence
Today, the agile manifesto has reached obsolescence. We no longer need to base current practice on something a group of middle-aged white men wrote 25 years ago. At the same time, the agile manifesto has largely achieved its goals by becoming the dominant way of thinking about software development.
Even if teams don’t appear to follow those principles and practices in daily work, they don’t argue for the waterfall-shaped opposites either. This seems to leave a muddy middle ground, that we no longer translate into new and opinionated practices.
Modern software development practices
Books on software development practices such as Extreme Programming, Scrum, Lean Software Development and Kanban all appeared around the five-year period from 1999 to 2004. For example, Jim Highsmith’s 2002 book Agile Software Development Ecosystems describes most of the methods we have focused on since then:
- Scrum
- Dynamic Systems Development Method (DSDM)
- Crystal Methods
- Feature-Driven Development (FDD)
- Lean Development (LD)
- Extreme Programming (XP)
- Adaptive Software Development (ASD)
Kanban doesn’t appear in the book’s table of contents, because it only became popular in the five years that followed.
The last practice
Looking back, it looks like some kind of development methodology golden age produced the greatest hits of the genre in the years 2000–2010. Since then we’ve only had progressively worse remixes. With luck, your team at least has a regular retrospective – the original agile development practice.
Ultimately, software development methods live on, even if only as pale shadows of Scrum, Kanban and Lean software development, while software development methodology went out of fashion. We continue to design and build software, but don’t pay much attention to designing and building software development processes.
