CMMI and Agile Process Improvement

SEPG‐NA‐2010
Judah Mogilensky, Process Enhancement Partners, Inc.
Hillel Glazer, Entinex, Inc.

Your Hosts:
High Maturity Lead Appraisers
B&C Team Leaders
Instructors
DEV, SVC, P‐CMM
Previously also worked with ISO 9000 + you name it.
Degreed engineers
Combined 50+ years in process improvement
Profoundly NOT box‐checkers!

Today’s Discussion
Agile view of CMMI
CMMI view of Agile
Proof
Reconciling CMMI and Agile
Theory vs. Practice
Interpreting CMMI for Specific Contexts (such as
Agile)
Examples from Engineering PAs
Take‐Home

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/

Agile view of CMMI

24‐Mar‐10
Photo Credit:
prohibited.
Paper‐centric
http://www.flickr.com/photos/yusheng/3468324165/

CMMI
view of
Agile

24‐Mar‐10
Photo Credit:
prohibited.
Juvenile
http://www.flickr.com/photos/oybay/242535156/

CMMI
view of
Agile

24‐Mar‐10
Photo Credit:
prohibited.
Wild West
http://www.flickr.com/photos/jason_lloyd/2228091536/

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

Proof:

24‐Mar‐10
Photo Credit:
Interview or interrogation?
prohibited.
9
http://www.flickr.com/photos/30529616@N00/3208944772/

Proof:

24‐Mar‐10
Photo Credit:
Web Apps ≠ Flight Software
prohibited.
10
http://www.flickr.com/photos/nichola80/3163243854/

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/

Progress

24‐Mar‐10 More to come in v1.3
prohibited.
12

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.

It’s one thing
in theory…

Models need to be made concrete.
24‐Mar‐10
Photo Credit:
prohibited.
14
http://www.flickr.com/photos/68888883@N00/2582964078/

It’s one thing
in theory…

Many ways to look at the same thing.
24‐Mar‐10
Photo Credit:
prohibited.
15
http://www.flickr.com/photos/frizztext/1541584634/

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!

Just because we say these
things can be evidence
does not automatically
mean that what any one
organization is doing is
appropriate evidence.

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.

Backlog

24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution 19
prohibited.

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.

A User Story

prohibited.

User Stories on a wall

Photo Credit:
prohibited.
Corey Ladas

Establish Operational Concepts and Scenarios:
Usually, appraisal teams expect to see an Operational
Concept Document (OCD) or something similar.

In Agile projects, the team generally produces a set of
Use Cases or epic stories, which are typically
reviewed with, and often approved by, the customer.
The set of Use Cases would serve as evidence for this
practice

An Epic (mega‐story)

prohibited.

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.

Test‐Driven Development

Diagram Credit:
prohibited.
http://www.flickr.com/photos/brunobord/3987593006/

Many ways to "document"

24‐Mar‐10 Data flow
prohibited.
27


24‐Mar‐10 Architecture
prohibited.
28


24‐Mar‐10 Design
prohibited.
29


24‐Mar‐10
Sketch Credit:
prohibited.
User Functionality
Scott Ambler

Technical Solution SP 3.1
Implement the Design:
Usually, appraisal teams expect to see, for software
development projects, actual source code and/or
Version Description Documents (VDDs).

In Agile projects, also, source code would serve as
evidence for this practice.

Source
Code

Photo Credit:
prohibited.
http://www.flickr.com/photos/schoschie/8821223/

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.

Pair Programming

Is not an
automatic
“FI.”
Photo Credit:
prohibited.
http://www.flickr.com/photos/tojosan/152763907/

Refactoring

After

Before

24‐Mar‐10
Photo Credit:
prohibited.
A lot closer.
http://www.flickr.com/photos/progrium/

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

Demo
Day

Photo Credit:
prohibited.
http://www.flickr.com/photos/juanpol/5894688/

Take‐Home
Do not look at the names of documents or to insist on
certain pre‐defined types of evidence.
Understand what is the underlying purpose and
objective of the CMMI practices, and what is the project
doing to accomplish that purpose, even if what they are
doing may seem unconventional at first

Take‐Home
Some Lead Appraisers and Team Members (who have
only worked in an environment of large systems
developments for defense customers), may need
something of a mindset shift to see how Agile artifacts
fit into CMMI practices.

This isn’t only true when dealing with Agile projects!

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.

CAUTION:
You may not be doing engineering.

Session by Hillel on . . . @ . . . In . . . .

Don’t be strangers!

prohibited.

CMMI and Agile Process Improvement

Recommended

Recommended

More Related Content

Similar to CMMI and Agile Process Improvement

Similar to CMMI and Agile Process Improvement (20)

More from Hillel Glazer

More from Hillel Glazer (7)

Recently uploaded

Recently uploaded (20)

CMMI and Agile Process Improvement