Loading ...
Sorry, an error occurred while loading the content.

169RE: [scrumdevelopment] Agile and CMM are contradictory

Expand Messages
  • Ken Schwaber
    Dec 8, 2001
      Self-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.
      Ken

      -----Original Message-----
      From: Mike Beedle [mailto:beedlem@...]
      Sent: Wednesday, December 05, 2001 6:14 PM
      To: scrumdevelopment@yahoogroups.com; extremeprogramming@yahoogroups.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
      lifecycle:

      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
      be prescribed.

      Although the agile movement doesn't make the connection with
      creating NEW products explicitly:
      http://www.agilealliance.org
      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
      of comparison,

      Mike Beedle
      http://www.mikebeedle.com

      e-Architects Inc. http://www.e-architects.com
      Hipaa Accelerator http://www.hipaaccelerator.com

      XBreed http://www.xbreed.net
      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:
      scrumdevelopment-unsubscribe@...

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Show all 23 messages in this topic