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

Re: [XP] RE: [scrumdevelopment] Agile and CMM are contradictory

Expand Messages
  • mpoppendieck
    Mike, I am in agreement with you that Software Development will benefit most from applying New Product Development paradigms to it. However, I don t agree that
    Message 1 of 23 , Dec 8, 2001
    • 0 Attachment
      Mike,

      I am in agreement with you that Software Development will benefit
      most from applying New Product Development paradigms to it.
      However, I don't agree that all Manufacturing paradigms are
      inappropriate for software development. Interestingly, I found
      that manufacturing has been as adversely impacted by an overemphasis
      on ISO standards as software development has been adversely impacted
      by an overemphasis on CMM.

      I propose that Lean Manufacturing has a host of good things to teach
      the software development industry. But note that the operative word
      in here is `Lean'. Lean means :

      1. Eliminating Waste – which is to say doing only those things
      which add value. It is amazing how many things you do not have to
      do if you aggressively eliminate things which do not add value.

      2. Streamlining Flow – Which means using the shortest possible
      path and the most rapid time. In manufacturing, this is applied to
      materials. In software development, this is applied to information
      flow. XP has a very rapid flow: from customer to developer to
      working code. No waste in handoffs.

      I think of CMM more like ISO 900X – relatively process-neutral and
      occasionally necessary. I observe that some companies benefit from
      such programs, but more companies waste time on them. I don't see a
      large correlation between high maturity and high business success.
      This is researched in the book by Robert Austin, `Measuring and
      Managing Performance in Organizations'.

      I recall that a local company, Zeos, was a finalist for the Malcolm
      Baldrige quality award one year, but soon faltered and was purchased
      by Micron. Meanwhile, Dell was focusing on becoming `Lean'. Few
      companies understand `Lean' better than Dell, and they are one of
      the few survivors in their field. One can argue that the time spent
      on ISO or CMM tasks do not always add value, and if they don't, they
      would be waste.

      I agree that software development is more akin to New Product
      Development than Manufacturing. One of the world class new product
      development organizations is Toyota, the birthplace of Lean
      Manufacturing. I theorize that if one looks at how Toyota develops
      new products, then perhaps one could find some good software
      development practices.

      Toyota uses a concept called `set-based design'. Check out this
      link: http://mitsloan.mit.edu/smr/past/1999/smr4025.html

      The fundamental concept of set-based design is something I
      call "Decide as Late as Possible." I propose that allowing
      decisions to be made at the last possible moment is one of the
      foundations of good product design, and good software architecture.

      Mary
    • Ken Schwaber
      Self-organization arising from inspection is right on. Another disconnect with CMM is that CMM desires to increase the level of definition, through increasing
      Message 2 of 23 , Dec 8, 2001
      • 0 Attachment
        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/
      • Ken Schwaber
        agile isn t an adjective, like agile RUP. Agile has particular theoretical characteristics (www.controlchaos.com/excerpt.pdf) and mannerisms that arise
        Message 3 of 23 , Dec 8, 2001
        • 0 Attachment
          "agile" isn't an adjective, like "agile RUP." Agile has particular
          theoretical characteristics (www.controlchaos.com/excerpt.pdf) and
          mannerisms that arise from this theoretical base, like frequent inspection,
          self-organization, and emergence.
          Ken

          -----Original Message-----
          From: Lowell Lindstrom [mailto:lindstrom@...]
          Sent: Thursday, December 06, 2001 11:45 AM
          To: 'scrumdevelopment@yahoogroups.com';
          extremeprogramming@yahoogroups.com
          Subject: RE: [XP] RE: [scrumdevelopment] Agile and CMM are contradictory


          > True agile teams will rely on cycles of inspection, adaptation
          > and self-organization but to conform to the CMM process framework
          > one _must_ conform to an ETVX process description format.
          >

          I agree that teams that have the constraint of CMM will have a very
          difficult, if not impossible, time reaching what you describe as "true
          agile." But again, that is not the decision that people are confronted
          with. All projects have constraints of all sorts. Those constraints will
          affect the team's ability to achieve "true agile."

          >
          > This makes it impossible to be on both sides of the fence.
          >

          I don't agree that it is a 2 sided fence. It is helpful to polarize things
          to clarify what we mean, but in practice the world is not that clean. Teams
          deal with spectrums of how far they can take something like agile. In
          practice, there is no end point or side of the fence that is agile, there
          are only relative positions closer to one extreme or the other. Although I
          agree that the closer to "true agile" the better, I disagree that a project
          that has constraints that push to the other end of the spectrum should not
          explore how they can get as close to "true agile" as possible within their
          constraints.

          > Until the CMM is allows processes to be self-organized
          > and emergent, we will have two clearly distinct sides,
          >

          In theory, yes. But in practice, there are CMM level 3 teams that are more
          agile (i.e. self-organizing and emergent) than others. The more agile they
          are the better, regardless of the closeness to "true." We should encourage
          them to push their boundary, wherever it is.

          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/
        • Lowell Lindstrom
          ... Please elaborate. It is used as an adjective in every context I have seen it, including Agile software development. ... (www.controlchaos.com/excerpt.pdf)
          Message 4 of 23 , Dec 8, 2001
          • 0 Attachment
            > "agile" isn't an adjective, like "agile RUP."

            Please elaborate. It is used as an adjective in every context I have seen
            it, including Agile software development.

            > Agile has particular theoretical characteristics
            (www.controlchaos.com/excerpt.pdf) and mannerisms
            > that arise from this theoretical base, like frequent inspection,
            self-organization, and emergence.

            I don't see what the excerpt has to do with this thread. In practice, there
            are degrees of self-organization, etc. Perhaps we are discussing from
            different vantage points, one theoretical and one practical.
          • Ken Schwaber
            You are quite correct. I was trying to get across the point that this is a cross-species thing. Although the idea of mating a snake and a dog is quite
            Message 5 of 23 , Dec 9, 2001
            • 0 Attachment
              You are quite correct. I was trying to get across the point that this is a
              cross-species thing. Although the idea of mating a snake and a dog is quite
              interesting, it is impossible. We used to refer to thing like "agile rup" as
              a pig on roller skates; it's still a pig, just a little faster.

              The excerpt talks about the theoretical basis. Self-organization after a
              team has been give a definitive list of tasks to perform is quite different
              from a team that has to think up the list of tasks from scratch.
              Ken

              -----Original Message-----
              From: Lowell Lindstrom [mailto:lindstrom@...]
              Sent: Saturday, December 08, 2001 9:44 PM
              To: 'scrumdevelopment@yahoogroups.com';
              'extremeprogramming@yahoogroups.com'
              Subject: RE: [XP] RE: [scrumdevelopment] Agile and CMM are contradictory


              > "agile" isn't an adjective, like "agile RUP."

              Please elaborate. It is used as an adjective in every context I have seen
              it, including Agile software development.

              > Agile has particular theoretical characteristics
              (www.controlchaos.com/excerpt.pdf) and mannerisms
              > that arise from this theoretical base, like frequent inspection,
              self-organization, and emergence.

              I don't see what the excerpt has to do with this thread. In practice, there
              are degrees of self-organization, etc. Perhaps we are discussing from
              different vantage points, one theoretical and one practical.


              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/
            • Mike Beedle
              I propose that Lean Manufacturing has a host of good things to teach the software development industry. But note that the operative word in here
              Message 6 of 23 , Dec 9, 2001
              • 0 Attachment
                <Mary writes>
                I propose that Lean Manufacturing has a host of good things to teach
                the software development industry. But note that the operative word
                in here is `Lean'. Lean means :

                1. Eliminating Waste – which is to say doing only those things
                which add value. It is amazing how many things you do not have to
                do if you aggressively eliminate things which do not add value.

                2. Streamlining Flow – Which means using the shortest possible
                path and the most rapid time. In manufacturing, this is applied to
                materials. In software development, this is applied to information
                flow. XP has a very rapid flow: from customer to developer to
                working code. No waste in handoffs.
                <Mary writes>

                Mary:

                I agree. Back in 1995 I wrote a pattern language to construct
                optimized enterprises using business patterns:
                http://www.mikebeedle.com/pub/bpr-papers/bpr.pdf

                And then I turned around and applied those same patterns to
                software development. In fact, I wrote a few articles on
                how to apply these patterns in an article with the title
                "Reengineering the application development process".

                However, these optimizations, while important, and while beneficial
                to software development, don't get to the core of what software
                is, imo. They miss the questions:

                "how do you enable people to do research and
                creativity with in high degrees of cooperation
                and collaboration?"

                and,

                "how do you allow software development projects to
                violently change plans and generate schedules, scope,
                determine appropriate quality, and contain cost
                on-the-fly?"

                This is only that something like Scrum brings.

                These requirements are what makes software development different
                than manufacturing -- any manufacturing, because
                manufacturing, regardless of how optimized it is, it always
                builds the same products once you run a production cycle i.e. like
                building a particular model of a VCR.

                Even when you have customized manufacturing, like in the delivery
                of automobiles, expensive machinery or PCs, there are
                standard process overrides to deal with customization, so the
                requirements are never elevated to deal with the requirements
                of software development.


                <Mary writes>
                I think of CMM more like ISO 900X – relatively process-neutral and
                occasionally necessary. I observe that some companies benefit from
                such programs, but more companies waste time on them. I don't see a
                large correlation between high maturity and high business success.
                This is researched in the book by Robert Austin, `Measuring and
                Managing Performance in Organizations'.
                <Mary writes>

                This is true, all of it, but the CMM does require at level 3
                to define a "detailed, step-wise process". And this is also true
                in manufacturing -- regardless of how much you streamline or
                eliminate waste, and regardless of how much JIT and Supply
                Chain Management one uses, manufactured products in a "production
                batch" are _assembled_ using a pre-defined process.

                In some very trivial cases you can almost do the same in
                software, like in CRUD type screens, but once business rules
                start to play a strong role, or once there is diversity in
                the technologies used for different functionalities, etc.;
                one steps into the non-liner land of "research and creativity
                required".

                - Mike


                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
              • Mike Beedle
                I propose that Lean Manufacturing has a host of good things to teach the software development industry. But note that the operative word in
                Message 7 of 23 , Dec 9, 2001
                • 0 Attachment
                  <Mary proposed>
                  I propose that Lean Manufacturing has a host of good things to teach
                  the software development industry. But note that the operative word
                  in here is `Lean'. Lean means :

                  1. Eliminating Waste – which is to say doing only those things
                  which add value. It is amazing how many things you do not have to
                  do if you aggressively eliminate things which do not add value.

                  2. Streamlining Flow – Which means using the shortest possible
                  path and the most rapid time. In manufacturing, this is applied to
                  materials. In software development, this is applied to information
                  flow. XP has a very rapid flow: from customer to developer to
                  working code. No waste in handoffs.
                  <Mary writes>

                  <I responded earlier>
                  >And then I turned around and applied those same patterns to
                  >software development. In fact, I wrote a few articles on
                  >how to apply these patterns in an article with the title
                  >"Reengineering the application development process".
                  <I responded earlier>


                  Btw, here is the "radp" paper just in case anyone want to take
                  a look at it:
                  http://www.mikebeedle.com/pub/radp.pdf

                  As well as a few other related articles and a presentation
                  here:

                  [Beedle97] M. Beedle, Pattern Based Reengineering,
                  Object Magazine, January (1997).
                  http://www.mikebeedle.com/pbr.html
                  * This paper includes an extended version of the
                  Zachman Framework that some people found interesting
                  since it included objects and patterns.


                  [Beedle95] M. Beedle, Object Based Reengineering,
                  Object Magazine 4(2), (1995).
                  * The equivalent of IDEF only in objects -- not good for
                  software development!!!


                  Enterprise Architectural Patterns
                  http://www.mikebeedle.com/pub/patterns.ppt
                  See also at the old Bell Labs site:

                  http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?BPRPatternLanguage
                  * This dates back to the time when I was coordinating
                  a common pattern language to build business and
                  software organizations. This effort has been
                  continued at:
                  http://i44pc48.info.uni-karlsruhe.de/cgi-bin/OrgPatterns

                  - Mike
                  http://www.mikebeedle.com
                Your message has been successfully submitted and would be delivered to recipients shortly.