169RE: [scrumdevelopment] Agile and CMM are contradictory
- Dec 8, 2001Self-organization arising from inspection is right on. Another disconnect
with CMM is that CMM desires to increase the level of definition, through
increasing level of detail. For agile and Scrum, more detail removes the
self-organization inherent to agile.
From: Mike Beedle [mailto:beedlem@...]
Sent: Wednesday, December 05, 2001 6:14 PM
To: firstname.lastname@example.org; email@example.com
Subject: [scrumdevelopment] Agile and CMM are contradictory
Lately there have been a lot of claims that it is possible to
do agile development and call it CMM-complaint or that is possible
to do agile development and be within the requirements of the CMM.
My position is that this is nonsense. Let me explain.
The CMM comes from Crosby's MMM (Manufacturing Maturity Model), and
it was therefore defined in the context of a manufacturing-like model
for software development. For manufacturing it makes more sense to
require "repeatable and completely defined low-level processes" because
manufacturing is about building a predefined identical objects in
an assembly line i.e. a Ford Model T, a VCR model, or a jet engine.
Even when you add customization, you can still apply a manufacturing
framework that overrides some of the sub-process in order to
change parts of the finished product, but they are still defined
and repeatable processes with pre-defined overrides.
However, software is different: it requires research and creativity,
even for trivial projects. Even if components or frameworks are
used, which will lessen the requirements on research and creativity,
they are assembled in _different_ ways to create different
applications, so they are not used like in a manufactured
assembly i.e. always in the same way.
The acts of finding requirements, designing, and building a prototype
of a component are different than executing the assembly instructions
of a well-known component. Compare solving a jig-saw puzzle with
building an assembly-required book shelf. The former requires
research and creativity, the latter follows a recipe. Well,
software development is like a jig-saw puzzle where in most cases
both the jig-saw puzzle pieces and the picture they compose
are being defined simultaneously.
On the other hand, agile methods _are_ defined, repeatable and
predictable but only in statistical ways -- not in detail steps
because it is impossible to predict how many times one will have
to talk to the customer, how many times one will refactor a
piece of code, or how many times one will need to retest. To know
what to do next in an agile method, one depends simply has to
determine the current context by constantly being aware of
what is going on and then do whatever makes sense
at that time. In agile methods what is repeatable are
the practices that you can use to do software development but
certainly not the _detailed process_. In other words, there
is not much process definition beyond than partitioning a project
in iterations and following a set of practices.
This is the heart of agility:
constant inspection that leads to self-organization
as opposed to cookbook like recipes or assembly instructions.
Inspection on the other hand can take several forms: customer
feedback, developer feedback, testing feedback, iteration
reviews, code reviews, etc.
Scrum for example, is based on a model used by American and Japanese
companies for creating NEW products, not manufactured products,
that strongly relies on feedback loops throughout the development
Takeuchi, Hirotaka and Nonaka, Ikujiro. January-February 1986.
"The New New Product Development Game." Harvard Business Review.
This is fundamental because the act of software construction
requires a Gestalt-like, Do-All-At-Once, self-consistent,
iterative solution, that is _emergent_ in nature i.e. cannot
Although the agile movement doesn't make the connection with
creating NEW products explicitly:
its values and principles reinforce these beliefs:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
And these values are in direct conflict with the unadulterated
spirit of the CMM.
I see efforts to make things like Scrum and XP CMM compliant,
or efforts to make the CMM agile, as complete nonsense because
these approaches are _fundamentally different_.
So beware: until processes are described as emergent and
self-organizing by the CMM, there is no overlap and no point
e-Architects Inc. http://www.e-architects.com
Hipaa Accelerator http://www.hipaaccelerator.com
Agile Scrum http://www.agilescrum.com
Agile Alliance http://www.agilealliance.org
Living Metaphor http://www.livingmetaphor.org
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
- << Previous post in topic Next post in topic >>