Depending on your situation, you can adopt some agile techniques but not others.

September 08, 2006
URL:http://www.drdobbs.com/architecture-and-design/imperfectly-agile-you-too-can-be-agile/192700252

Scott is a Canada-based software process improvement (SPI) consultant, mentor, and trainer with AmbySoft Inc. He has authored several books and is a regular speaker at software conferences worldwide. He can be contacted at www.ambysoft.com/scottAmbler.html.

People new to the idea of agile software development think that you can only be agile with small, co-located teams where you have no political constraints. Yes, that's ideal, but most teams aren't lucky enough to be in that situation. Does that mean they should give up on agile techniques? No! It means that they need to be smart about how they apply agile concepts and be as agile as possible given their current situation. This month, I explore strategies that people have used when they found themselves in not-so-ideal situations.

Dispersed Agile Development

In June I participated in the Perspectives on Systems Informatics at Akademgorodok, Siberia where I ran a tutorial on agile software development. After the tutorial, a couple of people came up to me and said this agile stuff was great in theory, but that it wouldn't work for them. One person worked in an outsourcing company where their clients were in Europe, and another worked for a company where the development team was split between Copenhagen and Moscow. Both were convinced that because their team wasn't co-located that they couldn't be agile. Nothing could be further from the truth.

Ideally, you want to co-locate your developers and stakeholders to improve their ability to collaborate and communicate, thereby reducing cost (they don't need to document as much) and risk (you increase the chance that they understand each other) on your project. In practice, many teams find themselves in a dispersed, multilocation environment and must find ways to overcome the inherent communication barriers. In "Bridging the Distance" (www.ddj.com/dept/architect/184414899), I describe strategies for doing exactly that. Dispersed agile teams will begin a project together so as to build a common vision, will get together occasionally to fortify that vision, and will have people traveling back and forth between locations as needed. They'll also adopt collaborative tools such as chat software, desktop sharing software, and Wikis. They'll communicate with each other via e-mail, telephone/video conferencing, and (egads!) even some written documentation.

Large Team Agile Development

As I describe in "Supersize Me" (www.ddj.com/dept/ architect/184415491), it's possible to have large agile teams. In fact, the first Feature Driven Development (FDD) team was 50 people and the second was 150 people—and both projects were a success. It's quite common to hear about agile teams of 30 or 40 people, and one of the most successful software development teams in history (see the sidebar "Large, Dispersed, Complex, Political, and Yet Still Agile") is much larger than that (and they're agile).

Large agile teams typically follow several common strategies.

• First, they organize themselves into several small, co-located subteams.
• Second, they model their requirements and architecture at a high level early in the project so as to set a common vision.
• Third, they deliver working software on a regular basis, often once every four to eight weeks, to ensure that the subteams are working toward the same goals.
• Fourth, they coordinate their efforts via regular communication.
• Fifth, they hire good people with the skills to work effectively with others and to produce actual working software.
• Sixth, they adopt common philosophies and guidance (such as coding conventions) to support consistency within and between the subteams.

Solving Complex Problems

Over the years I've heard several people claim that the problem that they were working on was so complex that an agile approach wouldn't work for them (see the sidebar "False Excuses for Not Becoming More Agile"). Wrong, wrong, wrong! When a problem is complex, shouldn't you produce working software regularly to increase opportunities for concrete feedback? Shouldn't you work closely with stakeholders to ensure you understand the actual problem? Shouldn't you maximize collaboration between team members so as to improve your chances of reaching the best solution? Shouldn't you test thoroughly to ensure you built the right thing? These are all aspects of an agile approach that traditional approaches struggle to achieve, so wouldn't greater complexity actually imply a need for greater agility?

Expensive Redeployment

Some people are wary of an agile approach when it's expensive to redeploy their system. An extreme example is a satellite, although more realistic ones are shrink-wrapped software and internal business systems that need to go through extensive testing phases. Once a satellite is in orbit it's a bit difficult to fix it if a hardware problem arises, discovering a software glitch once you've produced 250,000 CDs is clearly expensive, and do you really want to go through your three-month system testing process yet again?

I don't know anything about building satellites, so I can't say whether agile approaches would work there. However, the greater emphasis on testing and feedback inherent in agile approaches, and my actual experience developing both shrink-wrapped and business software, tells me that I'd want to be as agile as possible when redeployment is expensive—the greater quality that results from agile approaches reduces the chance of a serious defect that would require redeployment. Here's something to think about: Doesn't an extensive end of a lifecycle-testing effort imply an inherent lack of faith in traditional processes?

Regulated Development

Development teams often need to comply to external regulations, such as the Sarbanes-Oxley Act of 2002, Basel II, or the Food and Drug Administration's 21 CFR Part 11. Luckily, when you read the regulations (which I highly suggest that you do), none of them ever say that you need to be ineffective at software development. The secret is in how you interpret the regulations: Bureaucrats will define a documentation-heavy software process whereas agilists will define a streamlined one.

My experience is that many of the quality-oriented practices of agile development are far more conducive to regulated environments than traditional practices. For example, most regulations insist on holding reviews to ensure that someone other than the creator of a work product inspects it. Common agile techniques such as pair programming and modeling with others results in continuous review, and actually provide more effective feedback more quickly than formal reviews. As long as your auditors understand the implications of these practices, achieved through a bit of education, you should be able to take an agile approach. You will still have to hold some formal reviews, although they should be far less onerous.

Effective approaches to source control management (SCM), to testing, and to requirements traceability, and documented proof that you followed the process, are common regulatory requirements. In fact, agilists tend to do far more testing than traditionalists, and we consider SCM to be a fundamental activity. Requirements traceability is greatly simplified via the agile practice of single sourcing information (www.agilemodeling.com/essays/singleSourceInformation .htm). As far as documented proof goes, why not take an agile approach to documentation (www.agilemodeling.com/essays/ agileDocumentation.htm) and streamline this as much as possible? In short, not only is it possible to take an agile approach within a regulatory environment, it may even be preferable.

Capability Maturity Model Integrated (CMMI)

The CMMI does in fact introduce significant challenges for agility. First, the bad news. Regardless of what some may claim, there are some very nonagile concepts embedded within the CMMI. For example, the Requirements Management process area (a level 2 issue) states "Part of the management of requirements is to document requirements changes and rationale and maintain bidirectional traceability between source requirements and all product and product-component requirements." This is a costly endeavor that few project teams actually need in practice—a truly agile approach would be to do this only if the stakeholders require it, understand the true costs of doing so, understand the benefits of doing so, and have the ability to decide whether to do this and to what extent to do this. And this issue is just the tip of the "dysfunction iceberg."

The good news is that the CMMI community is trying to change. Hillel Glazer's agile CMMI blog (www.agilecmmi.com) is a great resource and the SEI does seem to be trying to embrace agile. Last year Software Development magazine published "Agile CMMI: No Oxymoron" (www.ddj.com/dept/architect/184415287) written by two senior SEI staff members. The article argued that the Team Software Process (TSP) is agile, but in my opinion that's quite a stretch. To be fair, TSP can be less bureaucratic than typical CMMI implementations, making it a step in the right direction for existing CMMI shops. But, compared to Extreme Programming (XP) or Open UP, the TSP has a long way to go.

So what do you do if you're trying to be agile in a CMMI environment? Once again, try to educate your auditors. I suspect that we'll soon start seeing agile CMMI appraisers hanging their shingle out there, but until then, agile approaches within CMMI shops will be a risky proposition. It's not impossible, but you'll be fighting against a lot of prejudices.

Outsourcing

Most outsourcing efforts are dispersed, CMMI-based development so applying the strategies discussed earlier will help you out here (also, see "Agile Outsourcing"; www.ddj.com/dept/ architect/184415344). The biggest challenge in an outsourcing situation is the propensity towards fixed bids. The challenge with fixed bids is that they force you into doing far more requirements modeling up front than is actually good for you. In "Examining the 'Big Requirements Up Front' Approach" (www.agilemodeling .com/essays/examiningBRUF.htm), I review evidence showing that writing a detailed requirements specification early in the lifecycle results in a clear 45 percent wastage on average, not to mention other problems.

Data Warehousing

There's nothing special about data warehousing projects—they can be agile, too. In fact, leading DW practitioners, particularly Bill Inmon (www.inmoncif.com) and Ken Collier, make it clear that you must take an incremental, if not agile, approach to succeed. My experience is that the secret is to downplay the data-modeling aspects and instead focus on usage and testing, but more on this in a future column.

Conclusion

To summarize, I've heard a lot of excuses over the years as to why a given project team or organization can't be agile, and frankly few of them have proven to be valid. In this column, I explored the most common reasons why teams supposedly can't be agile and then described how to overcome the inherent challenges. The secret is to recognize that agility is a spectrum, not a black-and-white issue. Depending on your situation, you will be able to adopt some agile techniques but not others. Strive to find your agile sweet spot.

DDJ

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