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

Multiple customers

Expand Messages
  • jonas.b@home.se
    This morning I interviewed a project manager at a multinational corporation. I managed to restrain myself from bringing Scrum up until the actual interview was
    Message 1 of 23 , Nov 30, 2001
    • 0 Attachment
      This morning I interviewed a project manager at a multinational
      corporation. I managed to restrain myself from bringing Scrum up
      until the actual interview was over. I did not think I could convince
      him to try Scrum out since the corporation use the same process model
      for all their projects. They experienced quite some problems with the
      software projects since the estimations were never satisfactory
      (surprise, surprise) unlike the hardware projects. The model they use
      seems to be quite waterfall-like with projects running for at least
      12 months. So I presented the iterative part of Scrum, to divide the
      project into Sprints. He said that it could be very useful to do so
      when you're working against one customer. But he felt that because
      they have sometimes up to 50 local companies as customers, which in
      their turn could have as much as 50 end-customers. Therefore there is
      no way they could satisfy all the customers so he didn't believe in
      the backlog-idea for their projects. Because I didn't see any chance
      of turning him into a Scrum-convert and felt I had to show him some
      respect I did not object.
      But how do you handle multitudes of customers (i.e. not end-users)? I
      believe that the chaos in such cases is greater than ever. Do you
      assign a person to be the ProductOwner who have to take all his
      customers into account? Is it possible to have a group of people as
      ProductOwner? I believe that the book says that one person shall be
      the ProductOwner and that all the others had to convince him. Is it
      possible to choose a person that everyone trust and can be a good
      representation of all the customers?

      Regards,
      Jonas Bengtsson
    • Ken Schwaber
      I wonder how much floundering occurs at this company. Not knowning their specifics, I don t understand why they haven t resolved this problem. If you have
      Message 2 of 23 , Nov 30, 2001
      • 0 Attachment
        I wonder how much floundering occurs at this company. Not knowning their
        specifics, I don't understand why they haven't resolved this problem. If you
        have multiple customers dicatating different priorities, how do one or more
        development teams work on a common product from a single code base? The
        errors and rework must be pretty impressive.

        We've always worked with multiple customers who often have different
        priorities and interests. The thirty day Sprint often makes them willing to
        subsume their immediate desires to another, since they aren't waiting years,
        only a Sprint before their interests are served. Scrum is common sense.
        Common sense says that a team can only work on one thing at a time -
        otherwise how do they self-organize? Multiple teams may work on differing
        functionality at a time, responding to different customer needs, but the
        functionality has to have maximum coupling and minimum cohesion to avoid
        floundering between teams.

        The product owner's job is to sort through the various needs of the
        customers and prioritize the product backlog so that their wants and needs
        are coherently represented as a queue of work. To save this person's sanity,
        the only important prioritization is for the next several Sprints. I've had
        customer review meetings (end of Sprint reviews) where multiple companies
        review what was just completed. The Product Owner then conducts the meeting
        to help the various customers decide what they want next. Every thirty days.

        It sounds like the person you interviewed has lost control of customer trust
        and satisfaction.

        Ken

        -----Original Message-----
        From: jonas.b@... [mailto:jonas.b@...]
        Sent: Friday, November 30, 2001 6:01 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Multiple customers


        This morning I interviewed a project manager at a multinational
        corporation. I managed to restrain myself from bringing Scrum up
        until the actual interview was over. I did not think I could convince
        him to try Scrum out since the corporation use the same process model
        for all their projects. They experienced quite some problems with the
        software projects since the estimations were never satisfactory
        (surprise, surprise) unlike the hardware projects. The model they use
        seems to be quite waterfall-like with projects running for at least
        12 months. So I presented the iterative part of Scrum, to divide the
        project into Sprints. He said that it could be very useful to do so
        when you're working against one customer. But he felt that because
        they have sometimes up to 50 local companies as customers, which in
        their turn could have as much as 50 end-customers. Therefore there is
        no way they could satisfy all the customers so he didn't believe in
        the backlog-idea for their projects. Because I didn't see any chance
        of turning him into a Scrum-convert and felt I had to show him some
        respect I did not object.
        But how do you handle multitudes of customers (i.e. not end-users)? I
        believe that the chaos in such cases is greater than ever. Do you
        assign a person to be the ProductOwner who have to take all his
        customers into account? Is it possible to have a group of people as
        ProductOwner? I believe that the book says that one person shall be
        the ProductOwner and that all the others had to convince him. Is it
        possible to choose a person that everyone trust and can be a good
        representation of all the customers?

        Regards,
        Jonas Bengtsson


        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/
      • jonas.b@home.se
        He must have thought that the ProductOwner was always an actual customer, now when I think of it. I didn t get a clear picture of how they managed their
        Message 3 of 23 , Dec 3, 2001
        • 0 Attachment
          He must have thought that the ProductOwner was always an actual
          customer, now when I think of it. I didn't get a clear picture of how
          they managed their customers. Perhaps I should have investigated the
          issue a little more... But I wasn't absolutely sure of how the
          ProductOwner worked (now I know).

          /Jonas

          --- In scrumdevelopment@y..., "Ken Schwaber" <ken.schwaber@v...>
          wrote:
          > I wonder how much floundering occurs at this company. Not knowning
          their
          > specifics, I don't understand why they haven't resolved this
          problem. If you
          > have multiple customers dicatating different priorities, how do one
          or more
          > development teams work on a common product from a single code base?
          The
          > errors and rework must be pretty impressive.
          >
          > We've always worked with multiple customers who often have different
          > priorities and interests. The thirty day Sprint often makes them
          willing to
          > subsume their immediate desires to another, since they aren't
          waiting years,
          > only a Sprint before their interests are served. Scrum is common
          sense.
          > Common sense says that a team can only work on one thing at a time -
          > otherwise how do they self-organize? Multiple teams may work on
          differing
          > functionality at a time, responding to different customer needs,
          but the
          > functionality has to have maximum coupling and minimum cohesion to
          avoid
          > floundering between teams.
          >
          > The product owner's job is to sort through the various needs of the
          > customers and prioritize the product backlog so that their wants
          and needs
          > are coherently represented as a queue of work. To save this
          person's sanity,
          > the only important prioritization is for the next several Sprints.
          I've had
          > customer review meetings (end of Sprint reviews) where multiple
          companies
          > review what was just completed. The Product Owner then conducts the
          meeting
          > to help the various customers decide what they want next. Every
          thirty days.
          >
          > It sounds like the person you interviewed has lost control of
          customer trust
          > and satisfaction.
          >
          > Ken
          >
          > -----Original Message-----
          > From: jonas.b@h... [mailto:jonas.b@h...]
          > Sent: Friday, November 30, 2001 6:01 AM
          > To: scrumdevelopment@y...
          > Subject: [scrumdevelopment] Multiple customers
          >
          >
          > This morning I interviewed a project manager at a multinational
          > corporation. I managed to restrain myself from bringing Scrum up
          > until the actual interview was over. I did not think I could
          convince
          > him to try Scrum out since the corporation use the same process
          model
          > for all their projects. They experienced quite some problems with
          the
          > software projects since the estimations were never satisfactory
          > (surprise, surprise) unlike the hardware projects. The model they
          use
          > seems to be quite waterfall-like with projects running for at least
          > 12 months. So I presented the iterative part of Scrum, to divide the
          > project into Sprints. He said that it could be very useful to do so
          > when you're working against one customer. But he felt that because
          > they have sometimes up to 50 local companies as customers, which in
          > their turn could have as much as 50 end-customers. Therefore there
          is
          > no way they could satisfy all the customers so he didn't believe in
          > the backlog-idea for their projects. Because I didn't see any chance
          > of turning him into a Scrum-convert and felt I had to show him some
          > respect I did not object.
          > But how do you handle multitudes of customers (i.e. not end-users)?
          I
          > believe that the chaos in such cases is greater than ever. Do you
          > assign a person to be the ProductOwner who have to take all his
          > customers into account? Is it possible to have a group of people as
          > ProductOwner? I believe that the book says that one person shall be
          > the ProductOwner and that all the others had to convince him. Is it
          > possible to choose a person that everyone trust and can be a good
          > representation of all the customers?
          >
          > Regards,
          > Jonas Bengtsson
          >
          >
          > To Post a message, send it to: scrumdevelopment@e...
          > To Unsubscribe, send a blank message to:
          > scrumdevelopment-unsubscribe@e...
          >
          > Your use of Yahoo! Groups is subject to
          http://docs.yahoo.com/info/terms/
        • Mike Beedle
          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
          Message 4 of 23 , Dec 5, 2001
          • 0 Attachment
            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
          • Andrey Khavryuchenko
            Michael, MB == Mike Beedle wrote: MB Lately there have been a lot of claims that it is possible to MB do agile development and call it CMM-complaint or
            Message 5 of 23 , Dec 5, 2001
            • 0 Attachment
              Michael,

              "MB" == Mike Beedle wrote:

              MB> Lately there have been a lot of claims that it is possible to
              MB> do agile development and call it CMM-complaint or that is possible
              MB> to do agile development and be within the requirements of the CMM.

              MB> My position is that this is nonsense.

              I think you're arguing the wrong point.

              One may put certify agile development organization to be CMM, if he needs
              to. For example, for marketing efforts (I see no other point, really).
              The CMM spirit and its basis have little common with this, since the
              process has to be certified to the conformance to formal criteria.

              On the other hand, XP, implemented properly, gives quality faster than
              CMM.

              So, before discussing XP vs CMM, I'd ask "Why you need CMM?"

              I'm not touching Scrum, since I know little about it.

              --
              Andrey V Khavryuchenko http://www.kds.com.ua/
              Offshore Software Development
            • Mike Beedle
              ... To understand the past, present and future of software development? The manufacturing-like paradigm imposed into software we mostly lived for the last 30
              Message 6 of 23 , Dec 6, 2001
              • 0 Attachment
                Andrey Khavryuchenko wrote:
                > So, before discussing XP vs CMM, I'd ask "Why you need CMM?"

                To understand the past, present and future of
                software development?

                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,

                - Mike
                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
              • Andrey Khavryuchenko
                Michael, MB == Mike Beedle wrote: ... MB To understand the past, present and future of MB software development? I d better rephrase my question: Why do
                Message 7 of 23 , Dec 6, 2001
                • 0 Attachment
                  Michael,

                  "MB" == Mike Beedle wrote:

                  MB> Andrey Khavryuchenko wrote:
                  >> So, before discussing XP vs CMM, I'd ask "Why you need CMM?"

                  MB> To understand the past, present and future of
                  MB> software development?

                  I'd better rephrase my question: "Why do you think you need implementing
                  CMM in your organization?"

                  Exploratory is good, but that wasn't the aim of my posting.

                  --
                  Andrey V Khavryuchenko http://www.kds.com.ua/
                  Offshore Software Development
                • Mike Beedle
                  ... Andrey: I think I am on the same side you are: I am trying to convince others to do something more agile i.e. I don t believe the CMM should be used. -
                  Message 8 of 23 , Dec 6, 2001
                  • 0 Attachment
                    Andrey V Khavryuchenko wrote:
                    > Michael,
                    >
                    > "MB" == Mike Beedle wrote:
                    >
                    > MB> Andrey Khavryuchenko wrote:
                    > >> So, before discussing XP vs CMM, I'd ask "Why you need CMM?"
                    >
                    > MB> To understand the past, present and future of
                    > MB> software development?
                    >
                    > I'd better rephrase my question: "Why do you think you
                    > need implementing CMM in your organization?"
                    >
                    > Exploratory is good, but that wasn't the aim of my posting.

                    Andrey:

                    I think I am on the same side you are:

                    I am trying to convince others to do something
                    more agile i.e. I don't believe the CMM should
                    be used.

                    - 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
                  • Andrey Khavryuchenko
                    Michael, MB == Mike Beedle wrote: MB Andrey: MB I think I am on the same side you are: MB I am trying to convince others to do something more agile i.e. I
                    Message 9 of 23 , Dec 6, 2001
                    • 0 Attachment
                      Michael,

                      "MB" == Mike Beedle wrote:

                      MB> Andrey:

                      MB> I think I am on the same side you are:

                      MB> I am trying to convince others to do something more agile i.e. I don't
                      MB> believe the CMM should be used.

                      Great!

                      Do you think there's lots of people on this forum that had to be convinced
                      in this? :)


                      --
                      Andrey V Khavryuchenko http://www.kds.com.ua/
                      Offshore Software Development
                    • Lowell Lindstrom
                      ... 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
                      Message 10 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

                        ==================================
                        Lowell Lindstrom
                        lindstrom@...
                        Object Mentor, Inc. | www.objectmentor.com
                      • 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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.