Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Do You Have Versusitis? Flexibility Scales

Scott is a DDJ Senior Contributing Editor and author of numerous IT books. He can be contacted at www.ambysoft.com/scottAmbler.html.

---

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!

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.

1 Do You Have Versusitis? | 2 Flexibility Scales Next Page

RELATED ARTICLES Extending Continuous Integration Into ALM Beyond Functional Requirements On Agile Projects Product, Support Management Tools Announced Building a Robust Development Environment Code Signing in Adobe AIR		TOP 5 ARTICLES No Top Articles.