Dr. Dobb's Journal - March 2008 - (Page 65)

by Scott W. Ambler The Agile Edge Agile is Relative When it comes to agile development, myths abound 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. ible 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 Gaining a clear understanding of agile software development is hobbled by agile myths 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, upfront 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. March 2008 l www.ddj.com l Dr. Dobb’s Journal 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 compat- 65 http://www.ddj.com/architect/204801134 http://www.ddj.com/architect/204801134 http://www.agilecmmi.com http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - March 2008

Dr. Dobb's Journal - March 2008 Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook Social Networks and Software Development Conversations Detecting Bugs in Safety-Critical Code Change Code Without Fear Continuous Integration and Performance Testing Wt: A Web Toolkit Automating Release Notifications The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.