Agile software development practices have been adopted by many IT organizations, and it's fair to conclude that agile is very clearly mainstream and is on track to become the dominant approach to software development. Having said that, many people are still struggling to understand what agile is really all about, particularly when it comes to scaling agile approaches. People struggle because they've been misled by some of the popular myths surrounding agile, they're suffering from "versusitis," and they've been misled about the benefits of traditional approaches. This month, I hope to motivate you to pause and reconsider your approach to agile, even if you have years of successful experience with agile but particularly if you think that it won't work in your situation.
When you talk with people who are unfamiliar with agile, you quickly discover that there are a lot of myths and misunderstandings surrounding it. For example, I've lost track of the number of times I've been told that Agilists don't model or write documentation, which is particularly galling because I'm the person behind the Agile Modeling (AM) methodology. Learn how to use Google, people! Table 1 lists the common myths that I've run into over the years and provides some advice for overcoming them.
Do You Have Versusitis?
Gaining a clear understanding of agile software development is not only hobbled by agile myths, but also by versusitis—a debilitating disease that afflicts a large number of IT professionals. The symptoms of versusitis include the desire to think of things in absolute terms (for example, either you're doing Scrum fully or you're not doing it at all), or worse yet, in terms of absolute trade-offs (for example, you want to know the differences between agile versus CMMI). Versusitis reduces your effectiveness as an IT professional because it inhibits you from seeing the shades of gray that exist between the extremes of black and white.
The cure for versusitis is to become flexible—to recognize that although as technologists we work in a binary world of zeros and ones, that the real world is in fact analog. In particular, recognize that when it comes to soft issues such as process, there are no absolutes, and you must find the sweet spot between the extremes. For example, many organizations have adopted Scrum's daily stand-up meetings and its philosophy about prioritizing requirements, but have given up on Scrum's concept of Product Owner due to scalability concerns (see my January 2008 column, www.ddj.com/architect/204801134). Other people recognize that they can leverage agile techniques within a CMMI environment; see Hillel Glazer's blog at www.agilecmmi.com for some insights, because they prove compatible in practice. The point is that the religious fervor that we often see around process-related subjects rarely helps people to understand and identify how they can successfully benefit from new ideas. By working together, we can stamp out versusitis forever!
| Agile Myth | Reality |
| Agile teams don't write documentation | Agilists treat documentation like a requirement—it gets estimated, prioritized, and "implemented" in the appropriate order. By putting price tags on things, we find that our stakeholders are a bit more selective as to how they choose to invest their hard-earned money. We also prefer executable specifications in the form of tests over static documents (see my February 2008 column for details: www.ddj.com/architect/205207998), reducing the amount if interim documentation created. And of course, we'll still need to create user documentation, support documentation, operations documentation, and even system overview documentation for the maintenance team. |
| Agile teams don't model | DDJ's 2007 Agile Adoption Survey found that 93% of Agile teams do whiteboard modeling, 77% of teams do some up-front requirements and architecture envisioning, 66% of Agile teams do paper-based modeling, and 47% of Agile teams use some sort of electronic drawing or CASE tool. Visit www.agilemodeling.com for more information as to how Agilists model in practice, and www.ambysoft.com/surveys/ for details about the survey itself. |
| Agile is undisciplined | Agile requires greater discipline than traditional approaches, as I describe in my October 2007 column at www.ddj.com/architect/201804241. |
| Agile teams don't plan | Agile teams do as much planning, and often more, than traditional teams, but they do it in a different way. The 2007 Agile Adoption Survey explored the value of various work products on Agile teams and found that the 5th most valuable one was an iteration task list, the agile version of a detailed project plan. The 19th most valuable work product, out of 19, was a detailed Gantt chart (but as VersionOne's Robert Holler points out, at least it's in the top 20). Agilists plan, they're just not creating dubious management artifacts. |
| Agile only works for small, colocated teams | Agile works best in these situations, as do traditional approaches, but the survey also found that many organizations are now successfully running agile teams of 50, 100, and even over 200. Furthermore, the survey showed that organizations are even succeeding at agile offshoring (albeit at a lower success rate). |
| Agile is difficult to govern | As I showed in my November 2007 column (www.ddj.com/architect/202401107), agile projects are easier to govern due to the higher stakeholder involvement and greater visibility provided by the regular delivery of working software. |
| Agile requires talented people | Yes, but so does traditional. Agile does in fact motivate people to be generalizing specialists who have a wider range of skills than people who are just specialists. This is a good thing for the individuals because it makes them more employable and it's good for organizations because their people are more effective. |
The Myths of Bureaucracy
The traditional community places far more faith in bureaucracy than is justified. Several myths are based around the value of comprehensive specifications, namely that you need to document requirements in detail, that you need to document the design in detail, and that you need to create detailed test plans. The reality is that you need to understand and then implement the requirements; you should strive to think through the design before implementing it, and then you need to test your work. The relationship between these goals and detailed documentation is tenuous in the best of circumstances, let alone the less-than-ideal situations IT professionals regularly find themselves in. These myths assume that the static specifications are sufficiently correct and kept up to date, that they'll be read and understood by the intended audience, and that the specifications will be trusted and then followed. Agilists have found that capturing specifications in the form of tests, which you can execute as part of your regression test suite, is far more effective than capturing specifications as static documentation.
For decades, traditionalists have assumed that software development is similar to civil engineering, despite all evidence to the contrary, and have thus justified significant up-front work as a result. This leads to several myths surrounding the value of detailed, up-front planning and modeling. Significant effort is often expended early in the project to "set a solid foundation" from which to proceed. But people aren't good at defining requirements in detail and changes in the business environment will necessitate requirements changes no matter how good your documentation efforts. In practice, software development proves to be a dynamic endeavor that is better suited to the just-in-time (JIT) planning and modeling approach prevalent in the agile community. There is definitely value in planning and modeling, but that value is gained throughout the project, not just in the beginning.
