 Development teams in large IT organizations need the best of both
worlds. They need to deliver systems that support rapidly changing business
requirements, while at the same time adhering to a process that not only
validates process improvement, but helps makes development more predictable. Agile development techniques provide a
short-cycle, iterative and incremental way to deliver working software, helping
enterprises support the need for rapidly changing business requirements. But often
enterprise agile teams need ways to benchmark and improve not only the software
but the process employed to deliver and support it. CMMI is an industry
standard way to achieve that goal.
The general perception is that the two are the antithesis of one
another. Process-centric CMMI
practitioners often think of developers that employ agile methods like XP and
Scrum as lacking in discipline and out of control. Development shops who employ
agile often view their more process-centric counterparts as slow-moving,
restrictive, and unproductive. Increasingly, successful IT enterprises tailor
their development teams such that they incorporate aspects of both
process-centric and agile development approaches. This article explores ways
that the enterprise can maintain and enhance the velocity of its development,
while maintaining quality and predictability.
Philosophical
differences
Agile
practices focus on people. They look to enhance developer productivity by empowering
the team as a whole and the team members individually by giving them
responsibility for project success and giving them the authority to make
changes that can ensure that success. Peer reviews ensure that each team member
is invested in the overall success of the project.
CMMI
is primarily focused on process and practices, rather than the people that
execute them. Compliance is the focus, and that focus can enhance organizational/enterprise
development maturity, not just at the project team.
On
the surface it appears that CMMI and agile are at opposite poles. But mature
CMMI enterprises are committed to tailoring their processes in a continuum of
continuous process improvement. Furthermore,
CMMI's embrace of teaming and the general organizational environment for integration
can be significant enablers for agile shops.
Mileage varies, but depending on an individual
implementation CMMI, can ensure that the process performers are process owners,
and thus enable the fundamental tenant of agile itself.
Success
with Agile and CMMI
Both CMMI and agile work in their own right,
as stand-alone models for improving software productivity and quality. According to the Software
Engineering Institute at Carnegie Mellon, creators of CMMI, a maturity
improvement from Level 1 to Level 2 alone speeds time to market by 38 percent,
eases the workload by 76 percent, and improves product quality by 80 percent
(in terms of number of defects shipped). According to the SEI, the cost at
Level 2 is only 25 percent of the costs at Level 1. 
One of the main reasons agile techniques work is
that they truly addresses the pain around requirements change and scope creep.
A survey published in Agile Journal in 2006 indicated that over 50% of
companies report a 25% or more increase in time to market, team productivity,
and reduced software defects. Furthermore, the survey showed that 52% say they
have improved or significantly improved their ability to manage changing
priorities and 44% say the same for aligning business and IT goals.
Complimentary,
not Opposed
It's a false dichotomy; process-centric approaches to application
development and agile are not adversarial. While CMMI and agile provide value in and
of themselves, enterprise development shops can benefit greatly by reconciling
and uniting these practices. In fact, the two are complimentary, and used together can help
enterprise development teams deliver better software faster, and for less
money. In some ways, CMMI and agile
simply see the same world through different lenses.
CMMI gives guidance on what the processes should do, not how it
should do it. It's the menu, rather than the recipe. CMMI provides a
ready-to-use acceptance test framework - the Standard CMMI Appraisal Method for
Process Improvement (SCAMPI). SCAMPI gives a way to validate and verify that a
company documents what it does, does what it documents. In essence, it requires
a company to prove process compliance. For
companies that are investing in process improvement, CMMI's external validation
and verification of their processes is an important step in moving toward a
continuous process improvement paradigm.
CMMI is often associated with waterfall development
methodologies, a serial fashion of application development that originated from
long-established engineering disciplines. Waterfall assumes perfect knowledge
of the requirements at the start of the project and uses the metaphor of "throwing the
product over the wall" as a means to describe what happens when the
project meets certain milestones. Because it lacks the integrated, high-trust,
highly communicative approach, development approaches which take this path are the
antithesis of agile development.
But CMMI is not a prescriptive methodology and
is only associated with waterfall because of historic reasons, not because
waterfall is inherently better at addressing CMMI than other processes. CMMI is
a process framework that allows a development team to employ any development
methodology that addresses its mandates. And although CMMI is rarely associated
with lightweight, flexible development, development teams can employ an agile
methodology and attain a CMMI rating at the same time. CMMI is the process improvement model, and
SCAMPI is the test harness that measures that improvement. It does not
explicitly prescribe or require any particular methodology, but instead
proposes and seeks evidence that processes and practices were performed.
Agile is a more prescriptive software development technique. Following
its tenants, development activities and deliverables are carefully planned and
disciplined.
Turnover procedures follow a well documented process that includes sign-off and
accountability. Communication and collaboration are at the heart of agile
development, but even those interactions are well scripted. For example, short daily
stand-up meetings and code peer reviews called for in agile development institutionalize
collaboration. The process is not wholly fixed, but can evolve as conditions in
the enterprise change.
Supporting
Tools
Tools enable process but they are not a substitute for it. Application
lifecycle management tools combined with project and portfolio management tools
can facilitate compliance with CMMI mandates by ensuring that processes are
understood and enforced. They can also automate the audit/reporting aspects of
CMMI helping companies to prove compliance. With the right feature set, these
kinds of tools can also enable an agile methodology.
Where companies are considering a continuous process improvement through
agile development practices, it should be understood that the tools need to enable
those agile practices. Key features may include support for use-case
requirements collection and management, "sprint" based iterative development,
backlog prioritization and burndown, test driven development, and so forth.
Project and cross-project visibility is important, allowing companies
to adhere to the agile tenants of "feedback early and often" and "fail fast". Tools
that provide an overlay of metrics and dashboards provide the visibility needed
to ensure robust project tracking and management.
Flexible process modeling needs to be a key consideration when looking
at tools because fine tuning processes is a fundamental aspect of CMMI as well
as agile. Tools that inhibit process improvement by being hard to customize are
simply unsuitable.
Conclusion
Enterprises should look at CMMI as a framework that encourages creativity, and one that can
accommodate agile development techniques and practices. Large enterprises can
benefit greatly by employing agile development practices to that allow them to
deliver and support working software quickly, but they also benefit from an external validation of their
processes. CMMI is a proven framework for this. In most cases, CMMI itself
should not be the primary goal - continuous process improvement should be.
However, an important side benefit of achieving CMMI accreditation is that it can
be the bar that allows a company to compete for certain contracts.
In summary, consider the following recommendations:
- Embrace agile
methods for building your software systems. Whether it's XP, Scrum, or some
other method, these practices enhance project success.
- Seek validation
of your process improvements with CMMI, and leverage those agile methods to
achieve it. CMMI tends to reduce risk in agile development.
- Although it may
have side benefits, think of CMMI as a means to achieve continuous process
improvement.
David Parker is the Director of Product
Marketing for Serena Software, Inc.
Trackback(0)
Comments 
Write comment
 |
CM Journal Articles 
TrackBack URI for this entry
Subscribe to this comment's feed