Agile is Relative

Scott examines the myths surrounding agile software development.


February 12, 2008
URL:http://www.drdobbs.com/open-source/agile-is-relative/206501655

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!

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.

Table 1: The myths surrounding agile software development.

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.

Flexibility Scales

Once you get beyond all of the myths and recognize that it's not a black-and-white world, it soon becomes obvious that there is no one single agile strategy that is right for all situations. This is true even in the most simple of situations, let alone in the complex situations that we usually find ourselves in—teams are made up of individuals, people who have their own unique experiences, skills and preferences. The implication is that we need to be flexible in the way that we approach software process—that a single "repeatable" approach isn't going to work in all situations.

This is particularly true when you scale agile software development approaches, and that to do so effectively you need to recognize that there are many factors to consider. Each team finds itself in different situations, and depending on where it finds itself with respect to these various factors will determine which agile strategies to apply and how to do so. The critical complexity factors are:

1. Geographical distribution. Is your team colocated (working in the same room), near located (working in the same building or city), or dispersed to various locations around the world? Your communication strategy will vary; in particular, the more dispersed your team, the greater the need for coordination and interim documentation.

2. Regulatory compliance. Regulations such as the Sarbanes-Oxley Act and the Food and Drug Administration (FDA) statutes will increase the documentation and process burden on your projects.

3. Entrenched policies, people, and processes. The organization in which your agile team works may be very agile, it may be very traditional, or somewhere in between. Development teams will need to be flexible in the way that they work with enterprise support teams, and similarly these support teams will need to vary their strategy depending on the working styles of the various teams that they support.

4. Legacy assets. Does your system have to integrate with existing assets such as legacy databases, shared services, or legacy systems? Not only will your technical strategy change to reuse these assets, you may discover that you need to refactor them to bring their quality in line with what your team is creating.

5. Organizational distribution. Do you have people on your team from different work groups, divisions, countries, or even companies? This will impact the way that you organize your team, how you organize the work, and how you share information.

6. Degree of governance. If you have one or more IT projects underway, then you have a development governance program in place. How formal is it? Does it enable or hinder agile work practices? Does it add additional overhead or does it help to streamline your work?

7. Team size. The way that you organize, manage, and support a team of 5 people is very different than the way you do so for a team of 50 or 500.

8. System complexity. The more complex the system, the greater the need for a viable architectural strategy, although that doesn't necessarily imply the need for onerous documentation. Many agile teams adopt the Rational Unified Process (RUP)'s strategy of envisioning the architecture early in the lifecycle and then immediately proving that it works via the creation of an end-to-end, working skeleton of the system.

The values contained in the Agile Alliance's Agile Manifesto (www.agilemanifesto.org) implicitly promote the concept that agile is relative, yet it seems to me that we often forget this in practice. More and more we're applying agile approaches at scale and we're finding that we need to be flexible in our approach. We're also finding that at scale, we need to move towards the right-hand side of the agile values more than some agile zealots would prefer. The agile strategies that worked for small, colocated teams developing straightforward systems won't work very well for large, dispersed teams working in regulatory environments on very complex software. Different situations require different strategies, and the best advice that I can give is to embrace change.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.