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.
