This document discusses reconciling the Capability Maturity Model Integration (CMMI) framework with Agile development methods. It provides examples of how Agile artifacts and practices can provide evidence for satisfying various CMMI process areas, given that Agile and CMMI represent different perspectives and Agile practices may not directly align with traditional CMMI evidence expectations. The document suggests interpreting CMMI flexibly based on the context and purpose of practices, and provides examples of how user stories, test-driven development, source code, and incremental testing can serve as alternative forms of evidence to traditional documents.
4. Agile
view of
CMMI
24‐Mar‐10
Image Credit:
prohibited.
Bureaucracy
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 4
http://www.flickr.com/photos/genesgraphics/3795769986/
5. Agile view of CMMI
24‐Mar‐10
Photo Credit:
prohibited.
Paper‐centric
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 5
http://www.flickr.com/photos/yusheng/3468324165/
6. CMMI
view of
Agile
24‐Mar‐10
Photo Credit:
prohibited.
Juvenile
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 6
http://www.flickr.com/photos/oybay/242535156/
7. CMMI
view of
Agile
24‐Mar‐10
Photo Credit:
prohibited.
Wild West
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 7
http://www.flickr.com/photos/jason_lloyd/2228091536/
8. Proof:
24‐Mar‐10
Photo Credit:
Feet and Feet of binders!
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution
prohibited.
8
http://www.gruntledemployees.com/photos/uncategorized/2007/05/12/hr_file_binders.jpg
9. Proof:
24‐Mar‐10
Photo Credit:
Interview or interrogation?
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution
prohibited.
9
http://www.flickr.com/photos/30529616@N00/3208944772/
10. Proof:
24‐Mar‐10
Photo Credit:
Web Apps ≠ Flight Software
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution
prohibited.
10
http://www.flickr.com/photos/nichola80/3163243854/
11. Proof:
Photo Credit:
No policy, no plan, no discipline!
24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution
prohibited.
11
http://www.flickr.com/photos/tronics/380379732/
12. Progress
24‐Mar‐10 More to come in v1.3
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution
prohibited.
12
13. Reconciling CMMI and Agile
Communication:
Understanding how words are used.
Understanding how work is done.
Understanding what represents work done.
Practices, Models, Representations
There are many ways to represent reality.
Models require context.
In context, artifacts will vary greatly.
14. It’s one thing
in theory…
Models need to be made concrete.
24‐Mar‐10
Photo Credit:
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution
prohibited.
14
http://www.flickr.com/photos/68888883@N00/2582964078/
15. It’s one thing
in theory…
Many ways to look at the same thing.
24‐Mar‐10
Photo Credit:
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution
prohibited.
15
http://www.flickr.com/photos/frizztext/1541584634/
16. How to interpret CMMI for specific
contexts?
What is the point or purpose of the practice?
What risks or problems is the practice trying to avoid?
What is the organization or project doing to achieve the purpose
or avoid the problem?
Ask the question(s) backwards:
What are you doing that addresses the practices and goals?
How do you avoid the risks the practices (and goals) expect you to
be avoiding?
In which of your outputs do what you do to address the practices
and goals "show up"?
If your efforts accomplish what CMMI expects you to
accomplish, your interpretation is acceptable.
What does the CMMI expect you to accomplish?
Read the informative material!
18. Requirements Development SP 1.2
Develop Customer Requirements:
Usually, appraisal teams expect to see a requirements
document prepared by the developer that reflects the
requirements that have been elicited from the customer
and other stakeholders.
In Agile projects, the customer may provide a documented
set of requirements, but often the requirements are elicited
through a series of meetings and discussions, and are
captured in a spreadsheet or requirements data base. The
spreadsheet or data base itself serves as evidence for this
practice, even if no "requirements document" is ever
produced.
19. Backlog
24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 19
prohibited.
20. Requirements Development SP 2.1
Establish Product and Product Component
Requirements:
Usually, appraisal teams expect to see a System or Software
Requirements Specification (SRS), detailing the technical
requirements to be implemented.
In Agile projects, it is more common to capture technical
requirements to be implemented in the form of Stories.
The compilation of Stories, which may again be in a
spreadsheet or data base, or may simply be a digital photo
of sticky notes posted on a wall, would serve as evidence for
this practice.
21. A User Story
24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 21
prohibited.
22. User Stories on a wall
24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 22
Photo Credit:
prohibited.
Corey Ladas
24. An Epic (mega‐story)
24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 24
prohibited.
25. Technical Solution SP 2.1
Design the Product or Product Components:
Usually, appraisal teams expect to see a Systems or Software
Design Document (SSDD or SDD), or something similar.
In Agile projects, practitioners will often assert that "we
don't do designs." But, when asked "How do programmers
know what to implement?", they will often explain that
detailed Unit Tests are prepared for components or tasks,
before they are implemented, containing all the details of
the required behavior of the item. These Unit Tests would
serve as evidence for this practice.
26. Test‐Driven Development
24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 26
Diagram Credit:
prohibited.
http://www.flickr.com/photos/brunobord/3987593006/
27. Many ways to "document"
24‐Mar‐10 Data flow
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution
prohibited.
27
28. Many ways to "document"
24‐Mar‐10 Architecture
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution
prohibited.
28
29. Many ways to "document"
24‐Mar‐10 Design
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution
prohibited.
29
30. Many ways to "document"
24‐Mar‐10
Sketch Credit:
prohibited.
User Functionality
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 30
Scott Ambler
32. Source
Code
24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 32
Photo Credit:
prohibited.
http://www.flickr.com/photos/schoschie/8821223/
33. Verification SP 2.1 and SP 2.2
Prepare for Peer Reviews,
Conduct Peer Reviews:
In many Agile projects, pair programming is practiced,
where two developers work together at the same time to
develop code, constantly commenting on each other's
work. It is, therefore, tempting to treat pair programming
as "peer review" for purposes of these practices.
However, the nature of the activity is that little if any of the
pair interaction is actually recorded anywhere, and Agile
developers have objected that it would be very
burdensome, with no value added, to attempt to document
these interactions.
34. Pair Programming
Is not an
automatic
“FI.”
24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 34
Photo Credit:
prohibited.
http://www.flickr.com/photos/tojosan/152763907/
35. Refactoring
After
Before
24‐Mar‐10
Photo Credit:
prohibited.
A lot closer.
Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 35
http://www.flickr.com/photos/progrium/
36. Requirements Development SP 3.5
Validate Requirements, and the Validation Process Area:
Usually, appraisal teams expect to see pre‐development simulations or
prototyping for the validation of requirements, and testing of the
system using operational scenarios in real or simulated operational
environments for the Validation. PA.
In Agile projects, development consists of a series of increments,
typically produced at two‐week intervals, each with successively more
complete functionality. Every increment will undergo some level of
testing based on use cases. There is no clear, well defined break
between "early prototyping" and "final system development", since
both are done using essentially the same process. Therefore, the plans
and results of use case testing for very early increments can serve as
evidence for validation of requirements, while the same type of plans
and results for use case testing for the late increments can serve as
evidence for the Validation PA
37. Demo
Day
24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 37
Photo Credit:
prohibited.
http://www.flickr.com/photos/juanpol/5894688/
40. Take‐Home – Another angle
Some projects may not have even the types of artifacts
noted above.
Perhaps they are only doing configuration of off‐the‐shelf
products, or designing screens and reports using menu and
checklist‐based tools.
In such cases, it may be important to ask, "Is the project
actually doing engineering development, in any meaningful
sense?"
It may be that some projects are more like "paint‐by‐
numbers" than actual engineering developments, in which
case even attempting a CMMI‐DEV‐based appraisal may be
inappropriate.