The age of cargo cult Agile must end.
Via LinkedIn, I learned about an article called “The age of Agile must end” by Michael Burnett, and I’ve since seen it pop up again in other forums.
I found the article to be filled with misconceptions but given enough people have somehow found it insightful, I thought it might be worth writing a response.
At first, I thought “The age of Agile must end” was an example of the cargo cult reinvention cycle but looking more closely, it seems like it’s both a cargo cult understanding of Agile AND arguing for something that is not aligned with Agile. I don’t necessarily think this was an intentional straw man argument though.
Misconception: Agile comes from Lean
Burnett suggests Agile came from trying to apply Lean principles to software development. This is incorrect.
Dr. Robert Charette explored Lean applied to software development in the early 1990s (and Kent Beck recalls hearing Dr. Charette talk at a Cutter Consortium meeting) but the Agile community didn’t really pick up on this until much later… so Lean applied to software development was mainly popularized by Mary and Tom Poppendieck in their books, Lean Software Development (2003), Implementing Lean Software Development (2006), Leading Lean Software Development (2009), and The Lean Mindset (2013). The Poppendieck Lean books provided both a conceptual explanation for why Extreme Programming / Agile worked and a source of new ideas, some from Lean Manufacturing (wastes, value stream mapping, etc.) but also some from Lean Product Development (Last Responsible Moment, Set-Based Concurrent Engineering, etc.).
An alternate path introducing “Lean” to software development came from David J. Anderson, initially Theory of Constraints in Agile Management for Software Engineering (2003) and then “kanban” in Kanban (2010). This “Lean” path is more about flow principles from Don Reinertsen’s Principles of Product Development Flow (2009) than “how Toyota approaches things” (i.e., Toyota Production System, Toyota Product Development System, Toyota Way). (NOTE: This is a simplified summary, see A Brief History of Kanban for Knowledge Work for a more detailed history)
Finally, Eric Ries would combine Extreme Programming and Steve Blank’s Customer Development to create Lean Startup (2011).
You might notice that all of this happened after the Agile Manifesto was published (2001), never mind when the pre-Agile lightweight methods were created (1990s). So, unless the Agile community invented time travel when I wasn’t looking, Agile didn’t come from Lean.
Modern day Agile has been influenced by Lean but it doesn’t come from it.
Agile is the latest evolution of iterative-incremental software development.
Back in 2003, Craig Larman and Victor R. Basili wrote Iterative and Incremental Development: A Brief History. This is closer to where Agile came from. It’s more the latest evolution of iterative-incremental software development. As I’ll discuss later, this is why some of Burnett’s arguments against Agile are actually him arguing against iterative-incremental development.
Argument: Is Agile incompatible with UX research, design, and scalable development?
Burnett says “Agile is incompatible with UX research, design, and scalable development.”
Burnett seems to be arguing that UX research, design, and scalable development is necessarily a mostly up-front process. This is consistent with his eventual conclusion that what we should do is:
Determine what needs to be built.
Determine how best to build it for scalability and future proofing.
Then build it, however long it takes.
One way to describe the issue is “build-it-right-the-first-time” vs “build-to-learn”.
The argument from the history of iterative-incremental development is that for large software systems, “build-it-right-the-first-time” is naive.
Software product development is too complex to reliably determine what needs to be built (including scaling and future proofing) up-front. As Dr. Winston W. Royce writes in his 1970 paper, Managing the Development of Large Software Systems, attempting to do so, “is risky and invites failure”.
Does this mean then that Agile is actually incompatible with UX research, design, scalable development? No, it means that the Agile approach to these things is evolutionary and continuous.
The Agile approach to research, discovery, design, scaling is evolutionary aka continuous.
The Agile approach to technical design is evolutionary aka continuous. A good summary of this is in “Is Design Dead?” (2004) by Martin Fowler and “Continuous Design” (2004) by James Shore. The short version:
- Keep code clear and simple — clear and simple code is easier to evolve;
- Get good at refactoring
The long version includes different tactics developed over the last 20 years including evolving databases and architectures.
The Agile approach to UX design is evolutionary aka continuous. From “Continuous Design and the NoPSD Movement” (2013) by Andrew Carr, Ryan Boucher, and Mike Gardiner:
“When the design comes over the wall you don’t get to see what drove the existing design; why the original designer made the decisions they did. Without this information you may be doomed to repeat design dead-ends. By being involved in the entire process you know how the design got to where it was and are better able to adapt it to the situation as it changes.
“When it comes to products, user experience trumps pretty pictures. It’s not easy for most designers to do, because you have to rebel against everything you’ve been taught as a designer: fight the pretty pictures, fight the urge to tweak your drop shadows or find the perfect border-radius.” Fast feedback is achieved by regularly putting things in front of users.”
The Agile approach to research and discovery is “dual track” aka continuous. An early reference for this is “Adapting Usability Investigations for Agile User-centered Design” (2007) by Desirée Sy describing the approach at Autodesk:
To allow the User Experience Team to iterate on designs, we usability tested prototypes at least one cycle ahead of developers, and then passed on the validated designs to be implemented. We would also conduct contextual inquiry for workflows at least two cycles ahead, and usability test the implemented working version to check for design drift.
I generally prefer approaching this less with n cycles ahead and more ongoing parallel activities that synchronize regularly. From “Dual Track Development is not Duel Track” (2017) by Jeff Patton:
Discovery work happens concurrently and continuously with development work.
Misconception: Agile treats humans like they are machines AND this idea comes from Lean
Burnett says that a fundamental flaw of Agile is treating humans like machinery AND implies that this comes from Lean:
Engineers are treated like machinery on an assembly line, always expected to be producing and delivering, incentivized to cut corners in order to get it “done.”
There are multiple corrections here:
- Always producing and delivering and cutting corners to get things done is explicitly not the Agile approach;
- Always producing and delivering and cutting corners to get things done is explicitly not the Lean approach;
- Lean explicitly does not treat humans like machinery.
The Agile preference is flexible scope, fixed quality (and time and cost)
Extreme Programming has a model called Four Variables: Cost, Time, Quality, Scope. Quick version: Flex scope, fix the rest.
Another way of saying this from Basecamp’s Getting Real is “Build half a product, not a half-ass product”.
Stop-the-line
Instead of keeping the assembly line running no matter what and then fixing things at the end (aka “always expected to be producing and delivering, incentivized to cut corners in order to get it done”), the expectation is instead to stop-the-line when problems are encountered so as not to leak quality issues to the next stage.
From The Toyota Way, principle #5:
Build a culture of stopping to fix problems, to get quality right the first time.
Jidoka: the harmonization of people and machines
From The Three Habits Required for Built-In Quality (Jidoka) by Jon Miller:
The first part of jidoka or “automation with a human touch” involves the harmonization of people and machines. Humans should do human work and machines should do machine work. Automation without human intelligence requires that people watch over the machine to catch possible defects, or for no good reason at all. This is a waste of human intelligence. The second part of jidoka is that machines should be designed or modified to include human intelligence. This means machines should detect errors and stop autonomously, demonstrating human intelligence rather than only mechanical properties.
Argument: Is design “inventory”?
Burnett says: “Design is not inventory”.
Short answer: Unless ideas are instantaneously transformed into value, the idea of “inventory” in product development is relevant.
Long answer…
Let’s imagine a workflow from concept-to-cash. We start with an idea and it goes through various stages before the idea is transformed into something that a customer pays for. There are problems associated with dealing with the idea as one big thing (aka large batch):
- Until the idea reaches the end of the workflow, it is what is known as “sleeping capital”, that is, we’ve invested money but have not yet received any return yet;
- The idea, as it transforms into a design, and then a product, may also suffer from obsolescence, that is, conditions in the external environment, or new learning, make decisions we previously made out of date;
- There is a lot of pressure to push the big thing through to the next stage as everyone else is waiting idle. This tends to lead to cutting corners and mistakes;
- Quality tends to be worse: Errors tend to accumulate and are detected late, typically with pressure not to send things back. There is also less practice because stages are only done once.
Unless ideas are instantaneously transformed into value, the idea of “inventory” in product development is relevant.
Misconception: Agile defines products in 2-week Sprints
Burnett says “Product can’t be defined by what can be accomplished by an arbitrary number of people of arbitrary skill and experience in a two-week sprint.” implying that Agile defines products in 2-week Sprints. This is incorrect.
Extreme Programming has Release Planning as a distinct concept from Iteration Planning. From “Release Planning” (1999) by Don Wells at https://www.extremeprogramming.org:
A release planning meeting is used to create a release plan, which lays out the overall project. The release plan is then used to create iteration plans for each individual iteration.
Iterations were originally 3 weeks, then more often 2 weeks, than 1 week, but now Extreme Programming teams are more likely to be doing Continuous Delivery. Iterations are a delivery construct. The product/project definition is a broader concept which is broken down into releases and the releases are broken down into iterations.
Scrum originally had larger Sprints (30 days) and were more like Extreme Programming’s Releases. From SCRUM: An extension pattern language for hyperproductive software development (1999) by Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, and Jeff Sutherland:
In a Sprint, during a period of approximately 30 days, an agreed amount of work will be performed, to create a deliverable.
The 6-week cycles in Shape Up are very similar to the original sentiment for Scrum Sprints.
we commit the six weeks and leave the team alone to get it done.
However, over time, many Scrum teams have borrowed the shorter Iterations from Extreme Programming and have forgotten the concept of a larger release. This is arguably what Burnett is complaining about.
Tree vs a bag of leaves
In The New User Story Backlog is a Map (2008), Jeff Patton described this problem as a tree vs a bag of leaves:
“We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details — the pieces of functionality we’d like to build. In my head [I] see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations.”
“After all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag — then cut down the tree.”
“That’s what a flat backlog is to me. A bag of context-free mulch.”
User Story Mapping is generally how I prefer modelling the broader “tree” of the product concept and designing potential releases.
Think Big Work Small
More recently, I like John Cutler’s phrasing Think Big Work Small. From Think Big, Work Small (Part 2) (2021):
The team rallies behind a compelling mission linked to a coherent strategy. The mission is outcome/impact oriented. The team contemplates a vision for the holistic experience but works with broad strokes. They sequence work with the riskiest assumptions first — experimenting, testing, and learning. This is not a ship-and-forget or a ship-and-maybe-in-a-year-we-come-back operation.
Think Big Work Small is a guiding principle for modern Agile product development. Think Small Work Small is a misconception typical of Agile novices. Think Big Work Big is naive. Think Small Work Big is worst of all.
Argument: Is Agile vs Waterfall a false dichotomy?
Burnett says: “The Agile vs. Waterfall argument is a false dichotomy: a company can have a long-term strategy and carry it out while still releasing the product incrementally, iteratively.”
“Waterfall” does not mean “long-term strategy”, it means a serial approach to software development. For example,
- Determine what needs to be built.
- Determine how best to build it for scalability and future proofing.
- Then build it, however long it takes.
- Etc.
I’d suggest that waterfall in response to the typical complexity of software product development to be an indication of bad strategy.
It’s a misconception to believe that long-term strategy is incompatible with Agile — see again Think Big, Work Small.
Misconception: Scrum was an attempt to apply Lean Manufacturing principles to software development
Burnett says: “As product owners and engineers attempted to apply lean manufacturing principles to software development, they found ways to mimic an assembly line. Requirements would be determined just in time and then a cross-functional team would sprint to release working software. The term Scrum was an apt choice…” essentially saying that Scrum was an attempt to apply Lean Manufacturing principles to software development. This is incorrect.
Scrum was more applying Japanese Product Development principles to software development.
One of the primary inspirations for Scrum was The New New Product Development Game (1986), by Hirotaka Takeuchi and Ikujiro Nonaka, which describes 6 characteristics from some Japanese new product development companies from the mid 1970s to early 1980s:
- “Built-in instability”: broad, challenging goals and a wide measure of freedom to accomplish them;
- “Self-organizing project teams”: autonomous, motivated, cross-functional teams;
- “Overlapping development phases”;
- “Multilearning”: learning at multiple levels (individual, group, company) and across multiple functions;
- “Subtle control”: deliberate design of systems to encourage desired behaviour (e.g., who’s selected for teams, work environment, encouraging direct engagement with customers, team-based evaluation and reward, celebrating failures, etc.);
- “Organizational transfer of learning”: Mechanisms for learning from one group to transfer to the rest of the organisation.
One could say Scrum was applying an interpretation of Japanese Product Development (not Lean Manufacturing) principles to software development.
I wrote a more involved summary of the New New Product Development Game. I’m reluctant to call it Lean Product Development because Toyota wasn’t part of the companies studied and key concepts are missing.
Misconception: No discussion is allowed in Daily Standups because that would leave “the machinery” idle
Burnett says: “There’s a Daily Standup to have on-the-fly “operational improvements.” (Only developers are allowed to speak and discussion is not allowed because that leaves the machinery idle.)”
From The 2020 Scrum Guide:
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management
If a Scrum team is more focused on not being idle than progressing toward the Sprint Goal, I’d call that more incompetence than official Scrum guidance.
There can be issues where a subset of the team hijacks the overall daily stand-up with a topic that not everyone needs to be involved in but addressing this is not about keeping “the machinery” busy.
Misconception: The purpose of retrospectives is to increase the quantity of output
Burnett says: “There’s also supposed to be a Retrospective to discuss what went well and what didn’t go well, in the interest of increasing the quantity of output.”
From The 2020 Scrum Guide:
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
If a Scrum team is only focused on increasing quantity of output rather than increasing quality and effectiveness of outcomes (which granted may include throughput), I’d call that more incompetence than official Scrum guidance.
Misconception: Backlogs aren’t core to Scrum
Burnett says: “The Backlog isn’t core to the Scrum practice, it’s an artifact of the collateral damage and detritus of everything jettisoned during the sprint.”
At first I was thinking that maybe Scrum removed Backlogs from their latest guide but nope, it’s still there. From The 2020 Scrum Guide, Product Backlog:
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
and Sprint Backlog:
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
Granted, I prefer User Story Maps over flat, ordered list backlogs.
Argument: The Agile Manifesto is one of the more pathetic documents ever created.”
Burnett says: “As far as manifestos go, this is one of the more pathetic documents ever created. It lists four “Values” and twelve “Principles.” They may have been well-intentioned at their inception — that intention was to treat developers as humans, not cogs in a machine — but now we’ve gone full circle. These principles have devolved into something caustic for organizations. Viewed now, they’re variations on a theme of how a scrum pod can absolve themselves of any accountability.”
From his subsequent translation of the Agile Manifesto, my guess is that Burnett assumes people will not be trustworthy (aka Theory X) which is why the Manifesto seems pathetic. This is why I have “people are trustworthy” as a core belief of effective Agile product development culture. If you don’t fundamentally believe people are trustworthy, a lot of what the Agile community advocates sounds like nonsense.
Argument: “Welcome changing requirements, even in late development.” means “We can also change our minds whenever”
This calls for a 2x2 matrix:
The idea is that we want low cost of change to enable deliberate changing of our minds to exploit unanticipated opportunities for competitive advantage (aka business agility).
Misconception: “Working software is the primary measure of progress.” means “The fact that we produced something, anything, is all that matters”
The idea is measuring progress from incremental outcomes, not internal activities. This is about not fooling yourself, not “just produce anything”. “Working software” seemed like a clear way of expressing that for software development back in 2001 but if I were to rewrite this today, I’d use “incremental outcomes”.
A related idea is Early Pain:
Iterative cycles try to flush out as many problems as possible as early as possible. This gives you more time to cope, or at least raises the problems early enough to cancel before investing too much money and effort in a problematic project.
See also
- We Tried Baseball and It Didn’t Work (2006) by Ron Jeffries
- BoiledCarrot (2016) by Martin Fowler
