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

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

Expand Messages
  • Mike Beedle
    ... Lowell: There is only one minor problem. True agile teams will rely on cycles of inspection, adaptation and self-organization but to conform to the CMM
    Message 1 of 23 , Dec 6, 2001
    • 0 Attachment
      > > 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,
      >
      > I don't see teams making decisions between CMM and XP/Agile. I have
      > encountered a few, but they were still in the very early learning stages
      > about methods and process.
      >
      > Rather, things like CMM, ISO, and other standards are typically
      > constraints
      > to which teams must conform. Across the spectrum of implementations that
      > can qualify for various CMM levels, there will be some that are more Agile
      > than others. The more agile the compliant implementation the
      > better. It is
      > not about conformance to an Agile standard, just as is it not about
      > conformance to CMM. If is about better satisfying our customers.
      >
      > So, I disagree that this is nonsense. I believe the mission is
      > to make all
      > teams better, whatever their constraints. If exploring Agile CMM or
      > attempting the make variants of Scrum or XP compliant leads to CMM teams
      > that are more agile, then more power to those that are making the effort.

      Lowell:

      There is only one minor problem.

      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.

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

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

      - 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
    • Lowell Lindstrom
      ... 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
      Message 2 of 23 , Dec 6, 2001
      • 0 Attachment
        > 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.
      • Laurent Bossavit
        ... Playing Devil s advocate for a moment : I m not sure I see where the dichotomy comes from. Is it not possible to be agile and still promote reuse,
        Message 3 of 23 , Dec 6, 2001
        • 0 Attachment
          > The manufacturing-like paradigm imposed into software we mostly lived
          > for the last 30 years is being threatened and is crumbling. The new
          > paradigm is software as NEW product, following an R&D-like process
          > that is best exemplified by Scrum, XP and other agile methods,

          Playing Devil's advocate for a moment : I'm not sure I see where the
          dichotomy comes from. Is it not possible to be agile and still promote reuse,
          assembling software from components, and suchlike ? Being agile means we
          like working software. If you can get working software by slapping together a
          bunch of COTS, why should that be a problem ?

          Or do you mean something different by "software as NEW product" ?

          -[Morendil]-
          On a clear disk you can seek forever
        • vze2k2j6@verizon.net
          Agile and Scrum principles work for any type of new development.
          Message 4 of 23 , Dec 6, 2001
          • 0 Attachment
            Agile and Scrum principles work for any type of new development.
            >
            > From: "Laurent Bossavit" <morendil@...>
            > Date: 2001/12/06 Thu PM 04:25:04 CST
            > To: extremeprogramming@yahoogroups.com
            > CC: <scrumdevelopment@yahoogroups.com>
            > Subject: [scrumdevelopment] RE: [XP] Re: Agile and CMM are contradictory
            >
            > > The manufacturing-like paradigm imposed into software we mostly lived
            > > for the last 30 years is being threatened and is crumbling. The new
            > > paradigm is software as NEW product, following an R&D-like process
            > > that is best exemplified by Scrum, XP and other agile methods,
            >
            > Playing Devil's advocate for a moment : I'm not sure I see where the
            > dichotomy comes from. Is it not possible to be agile and still promote reuse,
            > assembling software from components, and suchlike ? Being agile means we
            > like working software. If you can get working software by slapping together a
            > bunch of COTS, why should that be a problem ?
            >
            > Or do you mean something different by "software as NEW product" ?
            >
            > -[Morendil]-
            > On a clear disk you can seek forever
            >
            >
            >
            > 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
            ... Lowell: I agree with the notion you explain above. _In practice_ there is a spectrum -- I have always thought of software methods that way. In fact, Ken
            Message 5 of 23 , Dec 6, 2001
            • 0 Attachment
              Lowell Lindstrom wrote:
              > > 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.

              Lowell:

              I agree with the notion you explain above. _In practice_
              there is a spectrum -- I have always thought of software
              methods that way. In fact, Ken Schwaber actually developed
              an "agility scale", and I think this is a useful measure.

              However, the concept itself, to be agile, does depend
              on cycles of inspection, adaptation and self-organization.

              And the CMM does require, in its goals, in its capabilities,
              and in its activates a detailed "defined software process".

              What I am saying is that whether they are practiced as
              more or less agile, or more or less "defined in detail",
              their _definition_, and their underlying paradigm is
              fundamentally different.

              Lowell Lindstrom wrote:
              > > 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.

              I agree again. In fact, there are stories about
              many certified CMM level 3 teams that break the
              "process rules" and start acting more
              "self-organized" to actually be successful at level 3.

              Unfortunately, that's not what they were supposed to do
              according to their process definition ;-)

              - Mike
            • Mike Beedle
              ... Laurent: I think I mean something different. By software as NEW product I mean software that gets _used_ differently. For example. We do a lot of
              Message 6 of 23 , Dec 6, 2001
              • 0 Attachment
                Laurent Bossavit wrote:
                >> The manufacturing-like paradigm imposed into software
                >> we mostly lived for the last 30 years is being
                >> threatened and is crumbling. The new paradigm is
                >> software as NEW product, following an R&D-like process
                >> that is best exemplified by Scrum, XP and other
                >> agile methods,
                >
                > Playing Devil's advocate for a moment : I'm not sure I
                > see where the dichotomy comes from. Is it not possible to
                > be agile and still promote reuse, assembling software
                > from components, and suchlike ? Being agile means we
                > like working software. If you can get working software
                > by slapping together a bunch of COTS, why should
                > that be a problem ?
                >
                > Or do you mean something different by "software as NEW product" ?

                Laurent:

                I think I mean something different. By "software as
                NEW product" I mean software that gets _used_
                differently.

                For example. We do a lot of enterprise development,
                where many teams reuse anything from:

                workflows
                visual business components
                non-visual business components
                services
                transactions
                business objects
                architectural services
                etc.

                (Note: this btw, is the inspiration of XBreed:
                http://www.xbreed.net)

                However, we find that the teams use things like
                visual business components differently because:

                - what is created with them is different all
                the time. For example, our "Find Patient"
                component, is in several screens for different
                applications playing different roles and
                creating NEW and different functionality.

                - they are configured differently i.e. they
                are passed different configuration parameters
                at init time

                - even though they talk with defined interfaces,
                they play different roles in the overall
                protocol. For example, our "Comments"
                component is used by some teams as a visual
                component, but some other teams use it
                for reports, as a non-visual component.

                - the components sometimes have overridden
                behaviors. Like different JSPs for display,
                different subclasses of state beans, or
                even invoke similar but different services
                and transactions for the back-end. This
                is the case of our "Find Drug" component --
                it displays the same component, but
                it actually is configured to call different
                services in the back-end for different
                applications,


                So, no I don't see a problem with being agile and promote:

                reuse and
                assembling software from components
                etc.

                - Mike
              • 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.