- Introduction to Agile Development
- Our Position
- The Issues
- What's the Right Approach?
- Recommendations for Considering Agile
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
What's the Right Approach?
Since there are many different approaches to satisfying the goals of the CMMI, how do you choose? While different approaches may work, not all approaches are well suited for all situations.
One way to make the selection is to understand the profile of the most significant sources of risk to the project. Requirements are one source. Are the requirements stable or dynamic? Are they easy to understand, or are they complex? Do they encompass real-time or other high-performance attributes? Are there health or security concerns? Agile development techniques make a great deal of sense in environments with dynamic requirements. In an environment with real-time performance requirements or a safety-critical environment, however, a more traditional approach is called for.
Organizational complexity is another source. Are all of the stakeholders from the same organization, or are they spread across many organizations? Are the stakeholders co-located, or are they at different sites? Many agile techniques assume that the team is co-located or have a common managing structure. If these assumptions don't hold, the more formal communication and commitment mechanisms of a traditional approach make sense.
Size and technical complexity are also driving factors. The deployment costs are a particularly important attribute here. How complex is the system into which the software will be integrated? Is new hardware being developed? A spacecraft, to cite an extreme example, has tremendous deployment costs. You certainly want to make sure you get the deployment right the first time, and so the iterative nature of an agile technique would be difficult to apply. On the other hand, it's inexpensive to deploy an updated web application, and that's why agile approaches often thrive in this arena.
Select Approaches to Address the Profile
Traditional practices used under the CMM are suitable for addressing the primary risks in many environments. For example, for projects to replace multiple legacy systems from multiple organizations, a formal requirements approach would be needed to negotiate and communicate agreement between the organizations. In other cases, an architecture-driven approach is needed. For example, an architecture-driven approach is called for if disparate systems need to be integrated across organizations. These approaches address key organizational and technical risks in these environments.
Although not strictly a CMMI example, the Rational Unified Process (RUP) does provide a good illustration of this idea. RUP includes a vast array of tools and techniques that can satisfy many process requirements for the most complex projects. However, there's also the fact that not all projects need many of the tools RUP makes available. An important part of RUP is the development case, in which the relevant parts of the process are selected. It's possible to use RUP in an agile fashion, and it's possible to use RUP with a much more traditional approach. Which way you go depends on the development case decisions you make.
Similarly, organizations with agile techniques in their process library can select and tailor them to accommodate the inherent risks in any of their projects. In larger projects, more traditional architecture and requirements techniques may be needed to guide the overall system development, but specific sections may be portioned off and use agile methods within those boundaries. Even if methods such as XP are not applied, considering agile techniques for a process library may identify opportunities to simplify processes to make them faster, easier, and more flexible.