In-Depth

Puncturing The Top 7 Agile Myths

Although continuing to gain in popularity among developers, Agile methods still suffer from misperceptions. Here are seven of those myths, and why they're bunk.

• By Joel Semeniuk
• 03/01/2013

In the 11 years since the Agile Manifesto was created, the adoption of Agile concepts has continued to grow. The number of Agile user groups, conferences and books is a strong indication that more and more people are at least exploring the idea, if not working to improve its adoption and execution. This growth has been so significant that Gartner Inc. has declared "Agile is now mainstream."

Along with this growth in adoption and exploration of Agile, the number of myths surrounding Agile has grown as well.

In order to objectively look at some of the most-common myths, it's important to examine the Agile Manifesto itself. There are two parts of the Manifesto: four value propositions and 12 principles. The value propositions are a great place to start debunking some of the most common myths.

From the Manifesto: "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."

Myth No. 1: Agile Means 'No Commitment'
Some think that Agile teams don't make commitments -- it's just six to eight developers working until someone declares "We're done!" On the contrary, successful Agile teams are extremely realistic and transparent in what they promise to deliver.

Scrum and Extreme Programming (XP) have the concept of a "sprint backlog": the items that will be developed during a sprint or iteration. For some Scrum teams, the items on the sprint backlog are treated like a contract: the team is making a commitment that those items selected will be completed in that sprint (the newest version of Scrum backs off on the strength of the commitment).

XP teams sometimes allow change if all parties agree, and the item being replaced hasn't been started yet. In both cases, deferment -- not completing an item that was promised -- is treated as an exceptional occurrence, and not treated lightly. This commitment and regular cadence of delivering software in small increments builds a high degree of trust between the team and other interested parties, such as stakeholders, users and customers.

Scrum teams following the most recent teachings on Scrum don't commit on the scope of the sprint. This more closely fits the idea of not scope boxing anything, as scope boxing is a dangerously inaccurate game to play. Instead, the team renews its commitment on all of the tenets that make Scrum successful: rapid feedback loops, collaboration, and constant communication and transparency. Often, when teams are that communicative, there's less of a demand for an ironclad commitment. The trust and collaboration that results from teams working in this manner overrides the outdated requirement for commitments.

This is in contrast to typical waterfall projects -- because everything is based on estimates with waterfall, teams seldom deliver everything promised. It's not that they intentionally under-deliver, and it's not a reflection of skills or work ethic; estimates are seldom correct, and fixing scope and schedule based on inaccurate estimates quite often leads to features being dropped from the release.

Myth No. 2: Agile Development Is Not Predictable
This myth is closely related to Myth No. 1. But which is really more predictable in the following scenarios:

1. Code that's tested and delivered every two weeks; teams that are communicating their status every day (through stand-ups, burn-down charts and various other mechanisms); and requirements that are constantly being groomed and updated.
2. Code that doesn't get tested until the end of a six-, nine- or 12-month project cycle; teams that go dark for months at a time, not reporting status until the end of the construction phase; and a requirements document that never gets updated because the change-request process is too difficult to manage.

Successful Agile teams bring predictability to software development because every step of the way they're communicating, deploying real code and adapting to change (and keeping the documentation current). Every two weeks, they release a set of features that they stated two weeks prior they were going to work on. They meet expectations and deliver on their predictions.

Myth No. 3: Agile Is a Silver Bullet
Proponents of Agile will sometimes claim that moving to Agile will "fix all your problems." That isn't the case. It's important to stress that the Agile Manifesto is a set of values and principles that define a core attitude for software development. These values point to collaboration, rapid feedback loops and quality. In this way, Agile exposes your problems: Before any issue can be addressed, it needs to be surfaced. Once exposed, teams can work to eliminate friction and blocking issues.

Myth No. 4: Agility Helps in Every Case
Just as Agile isn't a silver bullet, there are cases where the popular Agile software development methodologies aren't a good fit. Developing systems that put human life at risk (such as the NASA space program) require a much higher level of requirement and design, and can be a good argument for a waterfall-style approach. Of course, even in those situations, the values of collaboration, high bandwidth, communication and rapid feedback loops -- as well as a focus on quality -- all apply. And the NASA space program didn't go from zero to a man on the moon; it iterated by starting with the X-15 rocket, and then the Mercury and Gemini programs, before the eleventh Apollo mission actually landed humans on the moon.

Myth No. 5: There's Only One Way to Do Agile
The Agile Manifesto consists of four values and 12 principles; it doesn't document implementation details. There are many interpretations of Agile, including Scrum, XP, Kanban and Feature-Driven Development, to name a few. Each style has benefits, as well as weaknesses, and you must evaluate your own specific situation to determine which interpretation is the best match. As long as you're adhering to the Agile Manifesto's values and principles, you should be considered Agile.

Myth No. 6: Agile Doesn't Need Up-Front Design
Just like the myth that "Agile has no architecture," there's a misconception that Agile teams do all their design work "on the fly." What is true is that design needs to be done at the last responsible moment. Some elements of design will be done long before any code is written, while other design elements will be completed a sprint (or more) prior to when they're needed. Some design will be done as the particular code is being written. This is commonly referred to as emergent architecture and design. It emerges as needed -- not before and not after.

"Big, up-front design" tries to answer every single question prior to the questions even being surfaced. Agile teams design the big rocks first, then the medium rocks and, finally, the small rocks. This process correctly identifies the questions as they become clear, therefore providing the correct answers when needed.

Myth No. 7: Agility Is Pain-Free
Transforming from a traditional waterfall team into a successful Agile team is not an insignificant effort. There are serious growing pains involved with such a transformation; you won't just completely change everything about your culture overnight. It will take study, practice and courage to make the change. The goal is to make sure that you fail fast when you try new things, so you can quickly try a new approach. If you can work your way through the learning curve, you'll end up much better off in the end.