Agile Myths: No Documentation, No Planning and "Agile Means Scrum"
Agile has documentation, planning and architecture; it promises early feedback rather than speed, and it isn't the same as Scrum or Jira. We compare seven common myths with the text of the manifesto, summarize Fowler's Agile Industrial Complex critique, Dave Thomas's "agility" proposal and Dark Scrum, and list the symptoms of cargo cult Agile through the "transformation" of the company Bookstore belongs to.
Version note: This post is based on the text of the Agile Manifesto and its 12 principles (2001), Martin Fowler's 2018 talk "The State of Agile Software in 2018", Dave Thomas's 2014 article "Agile is Dead (Long Live Agility)" and Ron Jeffries's 2016 article "Dark Scrum".
Guess First
The company Bookstore belongs to started an "Agile transformation". In six months the following happened: Jira licenses were bought for everyone, team leads got Scrum Master certifications, every team holds a stand-up at 09:30 every morning, two-week sprints started, and manifesto posters went up on the walls. Releases still happen once every three months, developers have never talked to an end user, and management sets the scope of the sprints.
Guess: is this company Agile? By the checklist, yes: there is a tool, there are roles, there are meetings, there are sprints. By the Manifesto? This post takes on, one by one, the common misconceptions that create the difference between the two.
Misconceptions and What the Manifesto Actually Says
Most misconceptions about Agile come not from the text of the manifesto but from the narrative piled on top of it over twenty-five years. Comparing each misconception with the text itself moves the discussion from opinion to document:
| Misconception | What does the Manifesto say? |
|---|---|
| There's no documentation in Agile | Working software is preferred over comprehensive documentation; it says explicitly that the items on the right have value too |
| There's no planning in Agile | Responding to change is preferred over following a plan; there is a plan, but it can change |
| There's no architecture in Agile | The best architectures emerge from self-organizing teams, and continuous attention to technical excellence enhances agility |
| Agile is faster | Early and continuous delivery of valuable software; not speed, but early feedback and adaptation |
| Agile = Jira | Individuals and interactions are preferred over processes and tools |
| Agile = Scrum | The Manifesto names no framework; Scrum is only one of the methods the signatories represented |
| Agile is only for small teams | The Manifesto says nothing about scale; scaling is a separate and contested topic |
"No Documentation" and "No Planning"
We covered these two through the values in the first post of the series; here let's look at their common root. Both come from reading the manifesto's value statements as rules that ban the items on the right. The reason for that reading is often practical: writing documents and planning are tedious, and saying "we're Agile" looks like a legitimate excuse not to do them.
At Bookstore the cost of this is concrete. The payment module doesn't have a single ADR (Architecture Decision Record); the answer to "why asynchronous?" left with the developer who left the team. There is no quarterly goal; every sprint fills up with whatever the previous sprint didn't finish, and the Product Owner can't answer the customer's "when?" question. In Agile, planning happens more often and in smaller pieces; in Scrum, Sprint Planning, the Product Goal and the Product Backlog are the tools for it. Techniques for estimation and long-term planning are the subject of the upcoming Estimation and Planning series.
"No Architecture": Emergent Design and Big Design Up Front
The misconception that Agile is against design comes from XP's (Extreme Programming) critique of BDUF (Big Design Up Front). The critique is right: an architecture designed for six months without writing code often turns out wrong at its first contact with reality. But the alternative the critique proposes isn't "do no design" but emergent design: growing the design as needs arise, under the protection of refactoring and tests.
Emergent design doesn't mean postponing every decision either. Some decisions are expensive to change: the database engine, the authentication approach, the multi-tenancy model. These need enough thought up front; the next post of the series covers this balance with the concept of an architecture runway. What architecture is and which decisions count as architectural is in the Introduction to Architecture series post "What Is Software Architecture? How It Differs from Design and What an Architect Does".
"Agile Is Faster"
This is the promise heard most often in management presentations. The Manifesto doesn't promise speed; it asks for early and continuous delivery of value. The difference matters: an Agile team notices the wrong thing earlier and wastes less work, but it isn't guaranteed to finish the same scope with the same team faster than with Waterfall.
What's more, most teams slow down during the transition. Diana Larsen and James Shore's Agile Fluency Model says this openly: part of the investment in becoming a delivery-focused team is accepting a temporary drop in output while new skills are learned. The question "we moved to Agile, why haven't we sped up?" is the result of a wrong promise.
"Agile = Jira" and "Agile = Scrum"
Equating Agile with a tool means turning the first value upside down. Jira, Azure Boards or GitHub Projects are good tools for making work visible; but when the cards on the board replace conversation within the team, the tool starts managing the process, and the process starts managing the people.
Equating it with Scrum is an even more common misconception. Scrum is the most widespread Agile framework, but the manifesto mentions neither it nor any other framework. At Snowbird there were representatives of XP, Scrum, DSDM (Dynamic Systems Development Method), Crystal, FDD (Feature-Driven Development) and other methods. Today Kanban may suit a support team better than Scrum; a team can also work by the manifesto's values without using any framework name. Scrum itself is in the Scrum series, the flow-oriented alternative in the Kanban series.
Critiques: The Agile Industrial Complex, "Agile Is Dead" and Dark Scrum
The harshest critics of these misconceptions were the authors of the manifesto themselves. In his 2018 Agile Australia talk Martin Fowler criticized what he called the "Agile Industrial Complex": consultants and tool vendors imposing a ready-made process on teams. According to Fowler, teams should choose their own way of working and keep adapting it; in addition, technical excellence is neglected at Agile gatherings, and teams should be organized around long-lived products, not projects. He calls work that carries the Agile name without its values "faux-agile".
Signatory Dave Thomas went even further in 2014, writing that the word "Agile" had been captured by marketing and now describes a sales pitch rather than a method. His proposal was to drop the adjective and return to the noun, "agility", and he described it with a four-step loop: find out where you are, take a small step toward your goal, adjust your understanding based on what you learned, repeat. When options are of roughly equal value, choose the one that makes future change easier.
Ron Jeffries described in 2016 the situation he named "Dark Scrum": Scrum's events being filled with old command-and-control habits. The Daily Scrum turning into a status interrogation, Sprint Planning into piling work onto the team, the Review into a "you didn't do what you promised" meeting. The details of Dark Scrum and Zombie Scrum are in the Scrum series post "Scrum Anti-Patterns: Dark Scrum, Zombie Scrum and Mini-Waterfall Sprints".
Symptoms of Cargo Cult Agile
Cargo cult means imitating the outward appearance of something without imitating how it works; Richard Feynman used this analogy in 1974 for work that imitates the form of science. The company at the start of this post is a textbook example. Look for these symptoms in your own team:
- The stand-up is a status report: everyone turns to the manager and says what they did yesterday.
- There are sprints, but the release calendar hasn't changed; output still reaches users once a quarter.
- Sprint reviews show slides, not working software.
- Retrospective actions are written down again, unchanged, at the next retrospective.
- Velocity is compared across teams and used in performance reviews.
- Developers never talk to end users; the Product Owner isn't an intermediary but a wall.
What all the symptoms have in common is that the form of a practice is kept while its purpose is lost.
Production Notes
Define rituals together with their purpose. The Bookstore team wrote a single question for every meeting and checks at the end of the meeting whether it was answered: for the Daily Scrum, "how are we changing today's plan to reach the Sprint Goal?", for the Review, "what did we learn from users and how are we changing the backlog?". If there is no answer, the meeting has become mere form.
Measure the transformation by outcomes, not practices: release frequency, change lead time, how long it takes for user feedback to enter the backlog. Most of these metrics overlap with the DORA (DevOps Research and Assessment) metrics covered in the fifth post of the SDLC (Software Development Life Cycle) series.
Common Pitfalls
Putting rituals in place of values is the most basic pitfall. The stand-up, the sprint and the board are tools; if they don't bring the values to life, they only take up space in the calendar.
The second is reading the critiques as "Agile failed". The critiques of Fowler, Thomas and Jeffries are aimed not at the manifesto but at practices sold under its name. All three argue that the values still hold.
The third is swinging to the opposite extreme while fighting the myths: going back to 80-page design documents by saying "Agile has documentation". The manifesto's answer is a balance, not a pendulum.
A Small Experiment
★☆☆ Which of the seven misconceptions in the table did you hear most recently in your team? Show the person who said it the relevant sentence of the manifesto and see how the discussion changes.
★★☆ Go through the list of cargo cult symptoms with your team. How many symptoms are present, and what was the real purpose of the practice in each case?
★★★ Write a single question for each recurring meeting of your team, and for the next two sprints record at the end of every meeting whether that question was answered. Which meeting has turned into mere form?
We've cleared away the misconceptions; the hard part remains. In the next post we look at where Agile meets the real world: fixed-price contracts, deadlines that don't move and architectural decisions that are expensive to reverse.