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

Scrum "D" and Lean

Expand Messages
  • Ken Schwaber
    Scrum is a very simple process for managing complex work. It has many areas in which it is quiet, such as engineering practices, planning and estimating
    Message 1 of 11 , Jul 30, 2007
    • 0 Attachment

      Scrum is a very simple process for managing complex work. It has many areas in which it is quiet, such as engineering practices, planning and estimating approaches, risk management, and others because these are situational, dependent on who is using Scrum when. People will fill in these blanks and come up with a process or approach that helps them accomplish their results best, keeping in mind that Scrum will keep pointing out when they are deficient so they can continually improve their concocted process. To say there is a Scrum “A”, “B”, “C” or otherwise is to say that there are multiple foundations on which to build, when the base Scrum – described in the literature – is more than adequate. I believe that thinking this way will help us avoid the babble of OO in its early years, and also people who “modify” Scrum to remove its most important elements.

       

      As for the connection between Lean and Scrum: you and others know lean. You look at Scrum and you can see lean in it. You use lean words and thinking to describe what you see. Great. However, Scrum isn’t based on lean, it just exemplifies some of it as you see it.

       

      Ken

       


      From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Alan Shalloway
      Sent: Monday, July 30, 2007 1:47 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: Scrum Evolution: Type A, B, and C Sprints

       

      --- In scrumdevelopment@ yahoogroups. com, "Ken Schwaber"
      <ken.schwaber@ ...> wrote:

      >
      > There is only one Scrum,

      Ken:
      I am not sure how to interpret this. Are you saying that it is all
      Scrum regardless of where it is applying or that there is only one
      Scrum as defined by some person or body. Please explain more fully.
      Thanks,

      Alan Shalloway
      CEO, Net Objectives
      Gold Sponsor Agile 2007

    • Robin Dymond
      So, there was this project. We used scrum. We used a new COTS tool. We started the work based on our expert product owner s direction. We demonstrated the
      Message 2 of 11 , Jul 30, 2007
      • 0 Attachment
        So, there was this project. We used scrum. We used a new COTS tool. We started the work based on our expert product owner's direction. We demonstrated the software to our product owner, she was OK with it. After 3 iterations we piloted it with customers, and they hated it. This was the first big clue we did not take. The business stakeholders decided to change the product owner, and so she became a key stakeholder, and the visonary became the product owner. But the visionary didn't want to show any more software to the customers until it was just right, and the COTS tool's much anticipated config features were completed and shipped by the vendor. So we no longer showed features to the customers, only the visionary, who did not know the work. In the spring the project was cancelled. The project was replaced by a Lean process redesign and implementation initiative. This Lean process redesign effort has been very successful so far. It is fixing problems that were out of reach of the team, and the product owners. It is addressing the ROOT CAUSE of the problems in the business area. The COTS vaporware arrived too late, but more importantly, the implementation was based on a faulty premise, that the product owner would and could know what to do. The team spent hundreds of hours automating a business process that was full of hand-offs, waiting, over production, highly manual, etc.

        To me this is a vivid personal experience of how Agile methods can really fail to deliver what the business needed. IT set out to solve the wrong problem, and the smart, engaged business leaders did not know enough to recognize that. If you are doing enterprise software for business automation, then Lean is just as important as Scrum to ensure you have the right processes, the right backlog and the right business agenda for technology to accelerate.

        Regards,
        Robin Dymond.
        www.innovel.net

        On 7/30/07, Ken Schwaber < ken.schwaber@...> wrote:

        Scrum is a very simple process for managing complex work. It has many areas in which it is quiet, such as engineering practices, planning and estimating approaches, risk management, and others because these are situational, dependent on who is using Scrum when. People will fill in these blanks and come up with a process or approach that helps them accomplish their results best, keeping in mind that Scrum will keep pointing out when they are deficient so they can continually improve their concocted process. To say there is a Scrum "A", "B", "C" or otherwise is to say that there are multiple foundations on which to build, when the base Scrum – described in the literature – is more than adequate. I believe that thinking this way will help us avoid the babble of OO in its early years, and also people who "modify" Scrum to remove its most important elements.

         

        As for the connection between Lean and Scrum: you and others know lean. You look at Scrum and you can see lean in it. You use lean words and thinking to describe what you see. Great. However, Scrum isn't based on lean, it just exemplifies some of it as you see it.

         

        Ken

         


        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Alan Shalloway
        Sent: Monday, July 30, 2007 1:47 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Re: Scrum Evolution: Type A, B, and C Sprints

         

        --- In scrumdevelopment@yahoogroups.com , "Ken Schwaber"
        <ken.schwaber@...> wrote:
        >
        > There is only one Scrum,

        Ken:
        I am not sure how to interpret this. Are you saying that it is all
        Scrum regardless of where it is applying or that there is only one
        Scrum as defined by some person or body. Please explain more fully.
        Thanks,

        Alan Shalloway
        CEO, Net Objectives
        Gold Sponsor Agile 2007


      • srinivas chillara
        I am inclined to think of Scrum A/B/C as simply different work patterns of Scrum, coming from the same base, the standard Scrum roles and practices. Is this
        Message 3 of 11 , Jul 30, 2007
        • 0 Attachment
          I am inclined to think of Scrum "A/B/C" as simply
          different work patterns of Scrum, coming from the same
          base, the standard Scrum roles and practices.

          Is this wrong or is it useful?

          Design patterns "singleton/bricklayer etc.." are often
          short-hand for describing design among people who are
          knowledgeable about them.



          > Scrum is a very simple process for managing complex
          > work. It has many areas
          > in which it is quiet, such as engineering practices,
          > planning and estimating
          > approaches, risk management, and others because
          > these are situational,
          > dependent on who is using Scrum when. People will
          > fill in these blanks and
          > come up with a process or approach that helps them
          > accomplish their results
          > best, keeping in mind that Scrum will keep pointing
          > out when they are
          > deficient so they can continually improve their
          > concocted process. To say
          > there is a Scrum "A", "B", "C" or otherwise is to
          > say that there are
          > multiple foundations on which to build, when the
          > base Scrum - described in
          > the literature - is more than adequate. I believe
          > that thinking this way
          > will help us avoid the babble of OO in its early
          > years, and also people who
          > "modify" Scrum to remove its most important
          > elements.



          Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/
        • Mark Smeltzer
          Sounds like both of your product owners got big heads. ... -- ________________________________ Mark Smeltzer Living Agile, Inc.
          Message 4 of 11 , Jul 30, 2007
          • 0 Attachment
            Sounds like both of your product owners got big heads.

            On 7/30/07, Robin Dymond <robin.dymond@...> wrote:

            So, there was this project. We used scrum. We used a new COTS tool. We started the work based on our expert product owner's direction. We demonstrated the software to our product owner, she was OK with it. After 3 iterations we piloted it with customers, and they hated it. This was the first big clue we did not take. The business stakeholders decided to change the product owner, and so she became a key stakeholder, and the visonary became the product owner. But the visionary didn't want to show any more software to the customers until it was just right, and the COTS tool's much anticipated config features were completed and shipped by the vendor. So we no longer showed features to the customers, only the visionary, who did not know the work. In the spring the project was cancelled. The project was replaced by a Lean process redesign and implementation initiative. This Lean process redesign effort has been very successful so far. It is fixing problems that were out of reach of the team, and the product owners. It is addressing the ROOT CAUSE of the problems in the business area. The COTS vaporware arrived too late, but more importantly, the implementation was based on a faulty premise, that the product owner would and could know what to do. The team spent hundreds of hours automating a business process that was full of hand-offs, waiting, over production, highly manual, etc.

            To me this is a vivid personal experience of how Agile methods can really fail to deliver what the business needed. IT set out to solve the wrong problem, and the smart, engaged business leaders did not know enough to recognize that. If you are doing enterprise software for business automation, then Lean is just as important as Scrum to ensure you have the right processes, the right backlog and the right business agenda for technology to accelerate.

            Regards,
            Robin Dymond.
            www.innovel.net

            On 7/30/07, Ken Schwaber < ken.schwaber@... > wrote:

            Scrum is a very simple process for managing complex work. It has many areas in which it is quiet, such as engineering practices, planning and estimating approaches, risk management, and others because these are situational, dependent on who is using Scrum when. People will fill in these blanks and come up with a process or approach that helps them accomplish their results best, keeping in mind that Scrum will keep pointing out when they are deficient so they can continually improve their concocted process. To say there is a Scrum "A", "B", "C" or otherwise is to say that there are multiple foundations on which to build, when the base Scrum – described in the literature – is more than adequate. I believe that thinking this way will help us avoid the babble of OO in its early years, and also people who "modify" Scrum to remove its most important elements.

             

            As for the connection between Lean and Scrum: you and others know lean. You look at Scrum and you can see lean in it. You use lean words and thinking to describe what you see. Great. However, Scrum isn't based on lean, it just exemplifies some of it as you see it.

             

            Ken

             


            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Alan Shalloway
            Sent: Monday, July 30, 2007 1:47 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Re: Scrum Evolution: Type A, B, and C Sprints

             

            --- In scrumdevelopment@yahoogroups.com , "Ken Schwaber"
            <ken.schwaber@...> wrote:
            >
            > There is only one Scrum,

            Ken:
            I am not sure how to interpret this. Are you saying that it is all
            Scrum regardless of where it is applying or that there is only one
            Scrum as defined by some person or body. Please explain more fully.
            Thanks,

            Alan Shalloway
            CEO, Net Objectives
            Gold Sponsor Agile 2007





            --
            ________________________________
            Mark Smeltzer
            Living Agile, Inc.
            http://www.livingagile.com/consulting
          • Bas Vodde
            Why you didn t make the customer the product owner? Bas
            Message 5 of 11 , Jul 30, 2007
            • 0 Attachment
              Why you didn't make the customer the product owner?

              Bas

              Robin Dymond wrote:
              >
              >
              > So, there was this project. We used scrum. We used a new COTS tool. We
              > started the work based on our expert product owner's direction. We
              > demonstrated the software to our product owner, she was OK with it.
              > After 3 iterations we piloted it with customers, and they hated it. This
              > was the first big clue we did not take. The business stakeholders
              > decided to change the product owner, and so she became a key
              > stakeholder, and the visonary became the product owner. But the
              > visionary didn't want to show any more software to the customers until
              > it was just right, and the COTS tool's much anticipated config features
              > were completed and shipped by the vendor. So we no longer showed
              > features to the customers, only the visionary, who did not know the
              > work. In the spring the project was cancelled. The project was replaced
              > by a Lean process redesign and implementation initiative. This Lean
              > process redesign effort has been very successful so far. It is fixing
              > problems that were out of reach of the team, and the product owners. It
              > is addressing the ROOT CAUSE of the problems in the business area. The
              > COTS vaporware arrived too late, but more importantly, the
              > implementation was based on a faulty premise, that the product owner
              > would and could know what to do. The team spent hundreds of hours
              > automating a business process that was full of hand-offs, waiting, over
              > production, highly manual, etc.
              >
              > To me this is a vivid personal experience of how Agile methods can
              > really fail to deliver what the business needed. IT set out to solve the
              > wrong problem, and the smart, engaged business leaders did not know
              > enough to recognize that. If you are doing enterprise software for
              > business automation, then Lean is just as important as Scrum to ensure
              > you have the right processes, the right backlog and the right business
              > agenda for technology to accelerate.
              >
              > Regards,
              > Robin Dymond.
              > www.innovel.net <http://www.innovel.net>
              >
              > On 7/30/07, *Ken Schwaber* < ken.schwaber@...
              > <mailto:ken.schwaber@...>> wrote:
              >
              > Scrum is a very simple process for managing complex work. It has
              > many areas in which it is quiet, such as engineering practices,
              > planning and estimating approaches, risk management, and others
              > because these are situational, dependent on who is using Scrum when.
              > People will fill in these blanks and come up with a process or
              > approach that helps them accomplish their results best, keeping in
              > mind that Scrum will keep pointing out when they are deficient so
              > they can continually improve their concocted process. To say there
              > is a Scrum "A", "B", "C" or otherwise is to say that there are
              > multiple foundations on which to build, when the base Scrum –
              > described in the literature – is more than adequate. I believe that
              > thinking this way will help us avoid the babble of OO in its early
              > years, and also people who "modify" Scrum to remove its most
              > important elements.
              >
              >
              >
              > As for the connection between Lean and Scrum: you and others know
              > lean. You look at Scrum and you can see lean in it. You use lean
              > words and thinking to describe what you see. Great. However, Scrum
              > isn't based on lean, it just exemplifies some of it as you see it.
              >
              >
              >
              > Ken
              >
              >
              >
              > ------------------------------------------------------------------------
              >
              > *From:* scrumdevelopment@yahoogroups.com
              > <mailto:scrumdevelopment@yahoogroups.com>
              > [mailto:scrumdevelopment@yahoogroups.com
              > <mailto:scrumdevelopment@yahoogroups.com>] *On Behalf Of *Alan Shalloway
              > *Sent:* Monday, July 30, 2007 1:47 PM
              > *To:* scrumdevelopment@yahoogroups.com
              > <mailto:scrumdevelopment@yahoogroups.com>
              > *Subject:* [scrumdevelopment] Re: Scrum Evolution: Type A, B, and C
              > Sprints
              >
              >
              >
              > --- In scrumdevelopment@yahoogroups.com
              > <mailto:scrumdevelopment%40yahoogroups.com>, "Ken Schwaber"
              > <ken.schwaber@...> wrote:
              > >
              > > There is only one Scrum,
              >
              > Ken:
              > I am not sure how to interpret this. Are you saying that it is all
              > Scrum regardless of where it is applying or that there is only one
              > Scrum as defined by some person or body. Please explain more fully.
              > Thanks,
              >
              > Alan Shalloway
              > CEO, Net Objectives
              > Gold Sponsor Agile 2007
              >
              >
              >
            • Roy Morien
              Well, it seems to me that using Scrum ... or more to the point, using an iterative development approach, proved remarkably successful. After only 3 iterations,
              Message 6 of 11 , Jul 31, 2007
              • 0 Attachment
                Well, it seems to me that using Scrum ... or more to the point, using an iterative development approach, proved remarkably successful. After only 3 iterations, it is discovered that the potential users hate it. Isn't that far and away a better time to discover this unfortunate situation, than maybe after 2 years development.
                 
                In my opinion, the first failure here was to wait for 3 iterations before showing the potential users anything. This should have been done after the first iteration. In that first iteration, something should have been developed that could be shown to the users for their judgement. This has the potential to achieve many good outcomes. First, the users have the earliest opportunity to see the GUI interface, so far. Second, the user has the ability to actually use the software delivered; a small thing at this point, but it is an opportunity to create confidence in the development team's ability, to give the users confidence that even at this early point their requirements appear to be being met etc. There is almost a political agenda here.

                Clearly the wrong people were being asked about the requirements. But then , that can happen regardless of which development approach is followed.
                 
                But it does demonstrate a very real problem that Scrum or any other agile approach does not have a ready solution to. How do you get to know the needs of a possibly large, diverse and widely distributed group of users? I had the experience of developing in an agile, iterative, highly collaborative manner, with apparently great success. Then I was asked to travel 350 miles away to visit another group of users who I did not even know existed, to demonstrate the software to them. I immediately realised that this remote group had been totally disenfranchised from the development process, even though I had done everything possible to include and involve "the users" in the development. In this situation, I quickly realised that having a "testing environment' available to everyone on the organisation network was essential, and everyone should have access to the delivered components. One excellent outcome of this is that the ease of use of the software can be readily judged; if the remote users find it difficult to use, without expert guidance and training, then perhaps the interface is too complex and insufficiently intuitive.
                 
                So, Deliver Early, Deliver Often, Deliver Comprehensively could be a good motto. AND also make sure that youare asking the right people.
                 
                Regards,
                Roy Morien





                > To: scrumdevelopment@yahoogroups.com
                > From: basv@...
                > Date: Tue, 31 Jul 2007 14:15:45 +0800
                > Subject: Re: [scrumdevelopment] Scrum "D" and Lean
                >
                > Why you didn't make the customer the product owner?
                >
                > Bas
                >
                > Robin Dymond wrote:
                > >
                > >
                > > So, there was this project. We used scrum. We used a new COTS tool. We
                > > started the work based on our expert product owner's direction. We
                > > demonstrated the software to our product owner, she was OK with it.
                > > After 3 iterations we piloted it with customers, and they hated it. This
                > > was the first big clue we did not take. The business stakeholders
                > > decided to change the product owner, and so she became a key
                > > stakeholder, and the visonary became the product owner. But the
                > > visionary didn't want to show any more software to the customers until
                > > it was just right, and the COTS tool's much anticipated config features
                > > were completed and shipped by the vendor. So we no longer showed
                > > features to the customers, only the visionary, who did not know the
                > > work. In the spring the project was cancelled. The project was replaced
                > > by a Lean process redesign and implementation initiative. This Lean
                > > process redesign effort has been very successful so far. It is fixing
                > > problems that were out of reach of the team, and the product owners. It
                > > is addressing the ROOT CAUSE of the problems in the business area. The
                > > COTS vaporware arrived too late, but more importantly, the
                > > implementation was based on a faulty premise, that the product owner
                > > would and could know what to do. The team spent hundreds of hours
                > > automating a business process that was full of hand-offs, waiting, over
                > > production, highly manual, etc.
                > >
                > > To me this is a vivid personal experience of how Agile methods can
                > > really fail to deliver what the business needed. IT set out to solve the
                > > wrong problem, and the smart, engaged business leaders did not know
                > > enough to recognize that. If you are doing enterprise software for
                > > business automation, then Lean is just as important as Scrum to ensure
                > > you have the right processes, the right backlog and the right business
                > > agenda for technology to accelerate.
                > >
                > > Regards,
                > > Robin Dymond.
                > > www.innovel.net <http://www.innovel.net>
                > >
                > > On 7/30/07, *Ken Schwaber* < ken.schwaber@...
                > > <mailto:ken.schwaber@...>> wrote:
                > >
                > > Scrum is a very simple process for managing complex work. It has
                > > many areas in which it is quiet, such as engineering practices,
                > > planning and estimating approaches, risk management, and others
                > > because these are situational, dependent on who is using Scrum when.
                > > People will fill in these blanks and come up with a process or
                > > approach that helps them accomplish their results best, keeping in
                > > mind that Scrum will keep pointing out when they are deficient so
                > > they can continually improve their concocted process. To say there
                > > is a Scrum "A", "B", "C" or otherwise is to say that there are
                > > multiple foundations on which to build, when the base Scrum –
                > > described in the literature – is more than adequate. I believe that
                > > thinking this way will help us avoid the babble of OO in its early
                > > years, and also people who "modify" Scrum to remove its most
                > > important elements.
                > >
                > >
                > >
                > > As for the connection between Lean and Scrum: you and others know
                > > lean. You look at Scrum and you can see lean in it. You use lean
                > > words and thinking to describe what you see. Great. However, Scrum
                > > isn't based on lean, it just exemplifies some of it as you see it.
                > >
                > >
                > >
                > > Ken
                > >
                > >
                > >
                > > ------------------------------------------------------------------------
                > >
                > > *From:* scrumdevelopment@yahoogroups.com
                > > <mailto:scrumdevelopment@yahoogroups.com>
                > > [mailto:scrumdevelopment@yahoogroups.com
                > > <mailto:scrumdevelopment@yahoogroups.com>] *On Behalf Of *Alan Shalloway
                > > *Sent:* Monday, July 30, 2007 1:47 PM
                > > *To:* scrumdevelopment@yahoogroups.com
                > > <mailto:scrumdevelopment@yahoogroups.com>
                > > *Subject:* [scrumdevelopment] Re: Scrum Evolution: Type A, B, and C
                > > Sprints
                > >
                > >
                > >
                > > --- In scrumdevelopment@yahoogroups.com
                > > <mailto:scrumdevelopment%40yahoogroups.com>, "Ken Schwaber"
                > > <ken.schwaber@...> wrote:
                > > >
                > > > There is only one Scrum,
                > >
                > > Ken:
                > > I am not sure how to interpret this. Are you saying that it is all
                > > Scrum regardless of where it is applying or that there is only one
                > > Scrum as defined by some person or body. Please explain more fully.
                > > Thanks,
                > >
                > > Alan Shalloway
                > > CEO, Net Objectives
                > > Gold Sponsor Agile 2007
                > >
                > >
                > >
                >
                >
                > To Post a message, send it to: scrumdevelopment@...
                > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                > Yahoo! Groups Links
                >
                > <*> To visit your group on the web, go to:
                > http://groups.yahoo.com/group/scrumdevelopment/
                >
                > <*> Your email settings:
                > Individual Email | Traditional
                >
                > <*> To change settings online go to:
                > http://groups.yahoo.com/group/scrumdevelopment/join
                > (Yahoo! ID required)
                >
                > <*> To change settings via email:
                > mailto:scrumdevelopment-digest@yahoogroups.com
                > mailto:scrumdevelopment-fullfeatured@yahoogroups.com
                >
                > <*> To unsubscribe from this group, send an email to:
                > scrumdevelopment-unsubscribe@yahoogroups.com
                >
                > <*> Your use of Yahoo! Groups is subject to:
                > http://docs.yahoo.com/info/terms/
                >



                Explore the seven wonders of the world Learn more!
              • Ken Schwaber
                This is more a problem of the business thinking that IT can solve its problems. The idea of the Product Owner is someone responsible for the ROI of the
                Message 7 of 11 , Jul 31, 2007
                • 0 Attachment

                  This is more a problem of the business thinking that IT can solve its problems. The idea of the Product Owner is someone responsible for the ROI of the project. Your PO was interested in getting the work done (old definition of success) rather than providing value. I’m working with an organization to scale its business. It’s product backlog has a large number of process redesigns and then automation. Otherwise you are just automating junk.

                  Ken

                   


                  From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Robin Dymond
                  Sent: Tuesday, July 31, 2007 12:19 AM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: Re: [scrumdevelopment] Scrum "D" and Lean

                   

                  So, there was this project. We used scrum. We used a new COTS tool. We started the work based on our expert product owner's direction. We demonstrated the software to our product owner, she was OK with it. After 3 iterations we piloted it with customers, and they hated it. This was the first big clue we did not take. The business stakeholders decided to change the product owner, and so she became a key stakeholder, and the visonary became the product owner. But the visionary didn't want to show any more software to the customers until it was just right, and the COTS tool's much anticipated config features were completed and shipped by the vendor. So we no longer showed features to the customers, only the visionary, who did not know the work. In the spring the project was cancelled. The project was replaced by a Lean process redesign and implementation initiative. This Lean process redesign effort has been very successful so far. It is fixing problems that were out of reach of the team, and the product owners. It is addressing the ROOT CAUSE of the problems in the business area. The COTS vaporware arrived too late, but more importantly, the implementation was based on a faulty premise, that the product owner would and could know what to do. The team spent hundreds of hours automating a business process that was full of hand-offs, waiting, over production, highly manual, etc.

                  To me this is a vivid personal experience of how Agile methods can really fail to deliver what the business needed. IT set out to solve the wrong problem, and the smart, engaged business leaders did not know enough to recognize that. If you are doing enterprise software for business automation, then Lean is just as important as Scrum to ensure you have the right processes, the right backlog and the right business agenda for technology to accelerate.

                  Regards,
                  Robin Dymond.
                  www.innovel. net

                  On 7/30/07, Ken Schwaber < ken.schwaber@ verizon.net> wrote:

                  Scrum is a very simple process for managing complex work. It has many areas in which it is quiet, such as engineering practices, planning and estimating approaches, risk management, and others because these are situational, dependent on who is using Scrum when. People will fill in these blanks and come up with a process or approach that helps them accomplish their results best, keeping in mind that Scrum will keep pointing out when they are deficient so they can continually improve their concocted process. To say there is a Scrum "A", "B", "C" or otherwise is to say that there are multiple foundations on which to build, when the base Scrum – described in the literature – is more than adequate. I believe that thinking this way will help us avoid the babble of OO in its early years, and also people who "modify" Scrum to remove its most important elements.

                   

                  As for the connection between Lean and Scrum: you and others know lean. You look at Scrum and you can see lean in it. You use lean words and thinking to describe what you see. Great. However, Scrum isn't based on lean, it just exemplifies some of it as you see it.

                   

                  Ken

                   


                  From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelopment@ yahoogroups. com] On Behalf Of Alan Shalloway
                  Sent: Monday, July 30, 2007 1:47 PM
                  To: scrumdevelopment@ yahoogroups. com
                  Subject: [scrumdevelopment] Re: Scrum Evolution: Type A, B, and C Sprints

                   

                  --- In scrumdevelopment@ yahoogroups. com , "Ken Schwaber"
                  <ken.schwaber@ ...> wrote:

                  >
                  > There is only one Scrum,

                  Ken:
                  I am not sure how to interpret this. Are you saying that it is all
                  Scrum regardless of where it is applying or that there is only one
                  Scrum as defined by some person or body. Please explain more fully.
                  Thanks,

                  Alan Shalloway
                  CEO, Net Objectives
                  Gold Sponsor Agile 2007

                   

                • Ken Schwaber
                  The ScrumMaster can get everyone to participate by making sure that the people most likely to object see the increments of functionality as they are built.
                  Message 8 of 11 , Jul 31, 2007
                  • 0 Attachment

                    The ScrumMaster can get everyone to participate by making sure that the people most likely to object see the increments of functionality as they are built. Then let the objections fly.

                     


                    From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Roy Morien
                    Sent: Tuesday, July 31, 2007 7:37 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: RE: [scrumdevelopment] Scrum "D" and Lean

                     

                    Well, it seems to me that using Scrum ... or more to the point, using an iterative development approach, proved remarkably successful. After only 3 iterations, it is discovered that the potential users hate it. Isn't that far and away a better time to discover this unfortunate situation, than maybe after 2 years development.
                     
                    In my opinion, the first failure here was to wait for 3 iterations before showing the potential users anything. This should have been done after the first iteration. In that first iteration, something should have been developed that could be shown to the users for their judgement. This has the potential to achieve many good outcomes. First, the users have the earliest opportunity to see the GUI interface, so far. Second, the user has the ability to actually use the software delivered; a small thing at this point, but it is an opportunity to create confidence in the development team's ability, to give the users confidence that even at this early point their requirements appear to be being met etc. There is almost a political agenda here.

                    Clearly the wrong people were being asked about the requirements. But then , that can happen regardless of which development approach is followed.
                     
                    But it does demonstrate a very real problem that Scrum or any other agile approach does not have a ready solution to. How do you get to know the needs of a possibly large, diverse and widely distributed group of users? I had the experience of developing in an agile, iterative, highly collaborative manner, with apparently great success. Then I was asked to travel 350 miles away to visit another group of users who I did not even know existed, to demonstrate the software to them. I immediately realised that this remote group had been totally disenfranchised from the development process, even though I had done everything possible to include and involve "the users" in the development. In this situation, I quickly realised that having a "testing environment' available to everyone on the organisation network was essential, and everyone should have access to the delivered components. One excellent outcome of this is that the ease of use of the software can be readily judged; if the remote users find it difficult to use, without expert guidance and training, then perhaps the interface is too complex and insufficiently intuitive.
                     
                    So, Deliver Early, Deliver Often, Deliver Comprehensively could be a good motto. AND also make sure that youare asking the right people.
                     
                    Regards,
                    Roy Morien




                    > To: scrumdevelopment@ yahoogroups. com
                    > From: basv@...
                    > Date: Tue, 31 Jul 2007 14:15:45 +0800
                    > Subject: Re: [scrumdevelopment] Scrum "D" and Lean
                    >
                    > Why you didn't make the customer the product owner?
                    >
                    > Bas
                    >
                    > Robin Dymond wrote:
                    > >
                    > >
                    > > So, there was this project. We used scrum. We used a new COTS tool.
                    We
                    > > started the work based on our expert product owner's direction. We
                    > > demonstrated the software to our product owner, she was OK with it.
                    > > After 3 iterations we piloted it with customers, and they hated it.
                    This
                    > > was the first big clue we did not take. The business stakeholders
                    > > decided to change the product owner, and so she became a key
                    > > stakeholder, and the visonary became the product owner. But the
                    > > visionary didn't want to show any more software to the customers
                    until
                    > > it was just right, and the COTS tool's much anticipated config
                    features
                    > > were completed and shipped by the vendor. So we no longer showed
                    > > features to the customers, only the visionary, who did not know the
                    > > work. In the spring the project was cancelled. The project was replaced
                    > > by a Lean process redesign and implementation initiative. This Lean
                    > > process redesign effort has been very successful so far. It is fixing
                    > > problems that were out of reach of the team, and the product owners.
                    It
                    > > is addressing the ROOT CAUSE of the problems in the business area.
                    The
                    > > COTS vaporware arrived too late, but more importantly, the
                    > > implementation was based on a faulty premise, that the product owner
                    > > would and could know what to do. The team spent hundreds of hours
                    > > automating a business process that was full of hand-offs, waiting,
                    over
                    > > production, highly manual, etc.
                    > >
                    > > To me this is a vivid personal experience of how Agile methods can
                    > > really fail to deliver what the business needed. IT set out to solve
                    the
                    > > wrong problem, and the smart, engaged business leaders did not know
                    > > enough to recognize that. If you are doing enterprise software for
                    > > business automation, then Lean is just as important as Scrum to
                    ensure
                    > > you have the right processes, the right backlog and the right
                    business
                    > > agenda for technology to accelerate.
                    > >
                    > > Regards,
                    > > Robin Dymond.
                    > > www.innovel. net <http://www.innovel. net>
                    > >
                    > > On 7/30/07, *Ken Schwaber* < ken.schwaber@ verizon.net
                    > > <mailto:ken.schwaber @verizon. net>> wrote:
                    > >
                    > > Scrum is a very simple process for managing complex work. It has
                    > > many areas in which it is quiet, such as engineering practices,
                    > > planning and estimating approaches, risk management, and others
                    > > because these are situational, dependent on who is using Scrum when.
                    > > People will fill in these blanks and come up with a process or
                    > > approach that helps them accomplish their results best, keeping in
                    > > mind that Scrum will keep pointing out when they are deficient so
                    > > they can continually improve their concocted process. To say there
                    > > is a Scrum "A", "B", "C" or otherwise
                    is to say that there are
                    > > multiple foundations on which to build, when the base Scrum –
                    > > described in the literature – is more than adequate. I believe that
                    > > thinking this way will help us avoid the babble of OO in its early
                    > > years, and also people who "modify" Scrum to remove its
                    most
                    > > important elements.
                    > >
                    > >
                    > >
                    > > As for the connection between Lean and Scrum: you and others know
                    > > lean. You look at Scrum and you can see lean in it. You use lean
                    > > words and thinking to describe what you see. Great. However, Scrum
                    > > isn't based on lean, it just exemplifies some of it as you see it.
                    > >
                    > >
                    > >
                    > > Ken
                    > >
                    > >
                    > >
                    > > ------------ --------- --------- --------- --------- --------- --------- ------
                    > >
                    > > *From:* scrumdevelopment@ yahoogroups. com
                    > > <mailto: scrumdevelop ment@yahoogroups .com >
                    > > [mailto: scrumdevelo pment@yahoogroup s.com
                    > > <mailto: scrumdevelop ment@yahoogroups .com >]
                    *On Behalf Of *Alan Shalloway
                    > > *Sent:* Monday, July 30, 2007 1:47 PM
                    > > *To:* scrumdevelopment@ yahoogroups. com
                    > > <mailto: scrumdevelop ment@yahoogroups .com >
                    > > *Subject:* [scrumdevelopment] Re: Scrum Evolution: Type A, B, and C
                    > > Sprints
                    > >
                    > >
                    > >
                    > > --- In scrumdevelopment@ yahoogroups. com
                    > > <mailto:scrumdevelop ment%40yahoogrou ps.com>,
                    "Ken Schwaber"
                    > > <ken.schwaber@ ...> wrote:
                    > > >
                    > > > There is only one Scrum,
                    > >
                    > > Ken:
                    > > I am not sure how to interpret this. Are you saying that it is all
                    > > Scrum regardless of where it is applying or that there is only one
                    > > Scrum as defined by some person or body. Please explain more fully.
                    > > Thanks,
                    > >
                    > > Alan Shalloway
                    > > CEO, Net Objectives
                    > > Gold Sponsor Agile 2007
                    > >
                    > >
                    > >
                    >
                    >
                    > To Post a message, send it to: scrumdevelopment@ eGroups.com
                    > To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.com
                    > Yahoo! Groups Links
                    >
                    > <*> To visit your group on the web, go to:
                    > http://groups. yahoo.com/ group/scrumdevel opment/
                    >
                    > <*> Your email settings:
                    > Individual Email | Traditional
                    >
                    > <*> To change settings online go to:
                    > http://groups. yahoo.com/ group/scrumdevel opment/join
                    > (Yahoo! ID required)
                    >
                    > <*> To change settings via email:
                    > mailto:scrumdevelop ment-digest@ yahoogroups. com
                    > mailto:scrumdevelop ment-fullfeature d@yahoogroups. com
                    >
                    > <*> To unsubscribe from this group, send an email to:
                    > scrumdevelopment- unsubscribe@ yahoogroups. com
                    >
                    > <*> Your use of Yahoo! Groups is subject to:
                    > http://docs. yahoo.com/ info/terms/
                    >


                    Explore the seven wonders of the world Learn more!

                  • mike.dwyer1@comcast.net
                    Robin First Good job. you ran hard - hit a wall and found out where the edge of the envelope is. Now move the edge, that is the great part of Scrum, inspect
                    Message 9 of 11 , Jul 31, 2007
                    • 0 Attachment
                      Robin
                      First Good job. you ran hard -  hit a wall and found out where the edge of the envelope is.  Now move the edge, that is the great part of Scrum, inspect and adapt.
                       
                      Second, it sounds like the business community was on the ball.  They fired the 'single chokeable throat' twice, dumped a frame work that was not working in their environment and found one that would.
                       
                      Finally, have you held a retro on this?  have you figured out that the organization you are working in does not have enough self discipline at the level you are trying to work at to support the Scrum frames you employed?  have you talked with the 6 sigma people to see what they did with the Root Cause information? did any of this information surprise you?  Why?  What can you learn from their root cause process that will make Scrum better.
                       
                       
                      --
                      Perseverance is not a long race; it is many short races one after another. ~Walter Elliott, The Spiritual Life


                      The greatest oak was once a little nut who held its ground. ~Author Unknown
                       
                      -------------- Original message --------------
                      From: Bas Vodde <basv@...>

                      > Why you didn't make the customer the product owner?
                      >
                      > Bas
                      >
                      > Robin Dymond wrote:
                      > >
                      > >
                      > > So, there was this project. We used scrum. We used a new COTS tool. We
                      > > started the work based on our expert product owner's direction. We
                      > > demonstrated the software to our product owner, she was OK with it.
                      > > After 3 iterations we piloted it with customers, and they hated it. This
                      > > was the first big clue we did not take. The business stakeholders
                      > > decided to change the product owner, and so she became a key
                      > > stakeholder, and the visonary became the product owner. But the
                      > > visionary didn't want to show any more software to the customers until
                      > > ; it was just right, and the COTS tool's much anticipated config features
                      > > were completed and shipped by the vendor. So we no longer showed
                      > > features to the customers, only the visionary, who did not know the
                      > > work. In the spring the project was cancelled. The project was replaced
                      > > by a Lean process redesign and implementation initiative. This Lean
                      > > process redesign effort has been very successful so far. It is fixing
                      > > problems that were out of reach of the team, and the product owners. It
                      > > is addressing the ROOT CAUSE of the problems in the business area. The
                      > > COTS vaporware arrived too late, but more importantly, the
                      > > implementation was based on a faulty premise, that the product owner
                      > > would and could know what to do. The team spent hundreds of hours
                      > > automating a business process that was full of hand-offs, waiting, over
                      > > pr oduction, highly manual, etc.
                      > >
                      > > To me this is a vivid personal experience of how Agile methods can
                      > > really fail to deliver what the business needed. IT set out to solve the
                      > > wrong problem, and the smart, engaged business leaders did not know
                      > > enough to recognize that. If you are doing enterprise software for
                      > > business automation, then Lean is just as important as Scrum to ensure
                      > > you have the right processes, the right backlog and the right business
                      > > agenda for technology to accelerate.
                      > >
                      > > Regards,
                      > > Robin Dymond.
                      > > www.innovel.net
                      > >
                      > > On 7/30/07, *Ken Schwaber* < ken.schwaber@...
                      > > > wrote:
                      > >
                      > > Scrum is a very simple process for managing complex work. It has
                      > > many areas in which it is quiet , such as engineering practices,
                      > > planning and estimating approaches, risk management, and others
                      > > because these are situational, dependent on who is using Scrum when.
                      > > People will fill in these blanks and come up with a process or
                      > > approach that helps them accomplish their results best, keeping in
                      > > mind that Scrum will keep pointing out when they are deficient so
                      > > they can continually improve their concocted process. To say there
                      > > is a Scrum "A", "B", "C" or otherwise is to say that there are
                      > > multiple foundations on which to build, when the base Scrum �
                      > > described in the literature � is more than adequate. I believe that
                      > > thinking this way will help us avoid the babble of OO in its early
                      > > years, and also people who "modify" Scrum to remove its most
                      > > important elements.
                      > >
                      > >
                      > >
                      > > As for the connection between Lean and Scrum: you and others know
                      > > lean. You look at Scrum and you can see lean in it. You use lean
                      > > words and thinking to describe what you see. Great. However, Scrum
                      > > isn't based on lean, it just exemplifies some of it as you see it.
                      > >
                      > >
                      > >
                      > > Ken
                      > >
                      > >
                      > >
                      > > ------------------------------------------------------------------------
                      > >
                      > > *From:* scrumdevelopment@yahoogroups.com
                      > >
                      > > [mailto:scrumdevelopment@yahoogroups.com
                      > > ] *On Behalf Of *Alan Shalloway
                      > > *Sent:* Monday, July 30, 2007 1:47 PM
                      > > *To:* scrumdevelopment@yahoogroups.com
                      > >
                      > > *Subject:* [scrumdevelopment] Re: Scrum Evolution: Type A, B, and C
                      > > Sprints
                      > >
                      > >
                      > >
                      > > --- In scrumdevelopment@yahoogroups.com
                      > > , "Ken Schwaber"
                      > > wrote:
                      > > >
                      > > > There is only one Scrum,
                      > >
                      > > Ken:
                      > > I am not sure how to interpret this. Are you saying that it is all
                      > > Scrum regardless of where it is applying or that there is only one
                      > > Scrum as defined by some person or body. Please explain more fully.
                      > > Thanks,
                      > >
                      > > Alan Shalloway
                      > > CEO, Net Objectives
                      > > Gold Sponsor Agile 2007
                      > >
                      > >
                      > >
                      >
                      >
                      > To Post a message, send it to: scrumdevelopment@...
                      > To Unsubscribe, send a blank message to:
                      > scrumdevelopment-unsubscribe@...
                      > Yahoo! Groups Links
                      >
                      > <*& gt; To visit your group on the web, go to:
                      > http://groups.yahoo.com/group/scrumdevelopment/
                      >
                      > <*> Your email settings:
                      > Individual Email | Traditional
                      >
                      > <*> To change settings online go to:
                      > http://groups.yahoo.com/group/scrumdevelopment/join
                      > (Yahoo! ID required)
                      >
                      > <*> To change settings via email:
                      > mailto:scrumdevelopment-digest@yahoogroups.com
                      > mailto:scrumdevelopment-fullfeatured@yahoogroups.com
                      >
                      > <*> To unsubscribe from this group, send an email to:
                      > scrumdevelopment-unsubscribe@yahoogroups.com
                      >
                      > <*> Your use of Yahoo! Groups is subject to:
                      > http://docs.yahoo.com/info/terms/
                      >
                      </ html>
                    • Robin Dymond
                      Thanks Mike. It is a very interesting case study. I think the experience points out the weakness that I have been thinking and posting (occasionally) about for
                      Message 10 of 11 , Jul 31, 2007
                      • 0 Attachment
                        Thanks Mike.
                         
                        It is a very interesting case study. I think the experience points out the weakness that I have been thinking and posting (occasionally) about for a while - "the mystical omniscient enterprise product owner." I worked hard to find the "right person" for the PO who new the processes inside out. In fact we ended up getting another one from a different area as well to ensure another group's needs were visible. The customer team members were well intentioned and smart. What none of us (IT) realized was how broken the operations process was. A critical issue was also picking the tool based on features that were in the next release (that was very late). This broke the principle of deciding as late as responsibly possible. But part of the agenda was to go COTS. If we had gone with a set based approach we might have had a different outcome because we would have been able to get closer to the customer requirements more quickly with a custom application.
                         
                        Interestingly, we had process engineers on the IT project team, and they were ineffective at moving the needle in this area. However on the lean project they were key players, and IT less effective.
                         
                        My perspective has been changed by lean. If IT is an accelerator, it is only as effective as the processes and operations surrounding it. This is a very different perspective than what I have seen in the enterprise COTS space, where people are re-designing processes around the app.
                         
                        Also interesting is that the lean project required as much change management as any large Agile project I have seen. Lots of behaviors need to change along the way.
                         
                        cheers,
                        Robin Dymond.
                         
                        On 7/31/07, mike.dwyer1@... <mike.dwyer1@...> wrote:

                        Robin
                        First Good job. you ran hard -  hit a wall and found out where the edge of the envelope is.  Now move the edge, that is the great part of Scrum, inspect and adapt.
                         
                        Second, it sounds like the business community was on the ball.  They fired the 'single chokeable throat' twice, dumped a frame work that was not working in their environment and found one that would.
                         
                        Finally, have you held a retro on this?  have you figured out that the organization you are working in does not have enough self discipline at the level you are trying to work at to support the Scrum frames you employed?  have you talked with the 6 sigma people to see what they did with the Root Cause information? did any of this information surprise you?  Why?  What can you learn from their root cause process that will make Scrum better.
                         
                         
                        --
                        Perseverance is not a long race; it is many short races one after another. ~Walter Elliott, The Spiritual Life


                        The greatest oak was once a little nut who held its ground. ~Author Unknown
                         
                         
                        -------------- Original message --------------
                        From: Bas Vodde < basv@...>

                        > Why you didn't make the customer the product owner?
                        >
                        > Bas
                        >
                        > Robin Dymond wrote:
                        > >
                        > >
                        > > So, there was this project. We used scrum. We used a new COTS tool. We
                        > > started the work based on our expert product owner's direction. We
                        > > demonstrated the software to our product owner, she was OK with it.
                        > > After 3 iterations we piloted it with customers, and they hated it. This
                        > > was the first big clue we did not take. The business stakeholders
                        > > decided to change the product owner, and so she became a key
                        > > stakeholder, and the visonary became the product owner. But the
                        > > visionary didn't want to show any more software to the customers until
                        > &gt ; it was just right, and the COTS tool's much anticipated config features
                        > > were completed and shipped by the vendor. So we no longer showed
                        > > features to the customers, only the visionary, who did not know the
                        > > work. In the spring the project was cancelled. The project was replaced
                        > > by a Lean process redesign and implementation initiative. This Lean
                        > > process redesign effort has been very successful so far. It is fixing
                        > > problems that were out of reach of the team, and the product owners. It
                        > > is addressing the ROOT CAUSE of the problems in the business area. The
                        > > COTS vaporware arrived too late, but more importantly, the
                        > > implementation was based on a faulty premise, that the product owner
                        > > would and could know what to do. The team spent hundreds of hours
                        > > automating a business process that was full of hand-offs, waiting, over
                        > > pr oduction, highly manual, etc.
                        > >
                        > > To me this is a vivid personal experience of how Agile methods can
                        > > really fail to deliver what the business needed. IT set out to solve the
                        > > wrong problem, and the smart, engaged business leaders did not know
                        > > enough to recognize that. If you are doing enterprise software for
                        > > business automation, then Lean is just as important as Scrum to ensure
                        > > you have the right processes, the right backlog and the right business
                        > > agenda for technology to accelerate.
                        > >
                        > > Regards,
                        > > Robin Dymond.
                        > > www.innovel.net
                        > >
                        > > On 7/30/07, *Ken Schwaber* < ken.schwaber @verizon.net
                        > > > wrote:
                        > >
                        > > Scrum is a very simple process for managing complex work. It has
                        > > many areas in which it is quiet , such as engineering practices,
                        > > planning and estimating approaches, risk management, and others
                        > > because these are situational, dependent on who is using Scrum when.
                        > > People will fill in these blanks and come up with a process or
                        > > approach that helps them accomplish their results best, keeping in
                        > > mind that Scrum will keep pointing out when they are deficient so
                        > > they can continually improve their concocted process. To say there
                        > > is a Scrum "A", "B", "C" or otherwise is to say that there are
                        > > multiple foundations on which to build, when the base Scrum –
                        > > described in the literature – is more than adequate. I believe that
                        > > thinking this way will help us avoid the babble of OO in its early
                        > > years, and also people who "modify" Scrum to remove its most
                        > > important elements.
                        > >
                        > >
                        > >
                        > > As for the connection between Lean and Scrum: you and others know
                        > > lean. You look at Scrum and you can see lean in it. You use lean
                        > > words and thinking to describe what you see. Great. However, Scrum
                        > > isn't based on lean, it just exemplifies some of it as you see it.
                        > >
                        > >
                        > >
                        > > Ken
                        > >
                        > >
                        > >
                        > > ------------------------------------------------------------------------
                        > >
                        > > *From:* scrumdevelopment@yahoogroups.com
                        > >
                        > > [mailto:scrumdevelopment@yahoogroup s.com
                        > > ] *On Behalf Of *Alan Shalloway
                        > > *Sent:* Monday, July 30, 2007 1:47 PM
                        > > *To:* scrumdevelopment@yahoogroups.com
                        > >
                        > > *Subject:* [scrumdevelopment] Re: Scrum Evolution: Type A, B, and C
                        > > Sprints
                        > >
                        > >
                        > >
                        > > --- In scrumdevelopment@yahoogroups.com
                        > > , "Ken Schwaber"
                        > > wrote:
                        > > >
                        > > > There is only one Scrum,
                        > >
                        > > Ken:
                        > > I am not sure how to interpret this. Are you saying that it is all
                        > > Scrum regardless of where it is applying or that there is only one
                        > > Scrum as defined by some person or body. Please explain more fully.
                        > > Thanks,
                        > >
                        > > Alan Shalloway
                        > > CEO, Net Objectives
                        > > Gold Sponsor Agile 2007
                        > >
                        > >
                        > >
                        >
                        >
                        > To Post a message, send it to: scrumdevelopment@...
                        > To Unsubscribe, send a blank message to:
                        > scrumdevelopment-unsubscribe@...
                        > Yahoo! Groups Links
                        >
                        > <* gt; To visit your group on the web, go to:
                        > http://groups.yahoo.com/group/scrumdevelopment/
                        >
                        > <*> Your email settings:
                        > Individual Email | Traditional
                        >
                        > <*> To change settings online go to:
                        > http://groups. yahoo.com/group/scrumdevelopment/join
                        > (Yahoo! ID required)
                        >
                        > <*> To change settings via email:
                        > mailto: scrumdevelopment-digest@yahoogroups.com
                        > mailto:scrumdevelop ment-fullfeatured@yahoogroups.com
                        >
                        > <*> To unsubscribe from this group, send an email to:
                        > scrumdevelopment-unsubscribe@yahoogroups.com
                        >
                        > <*> Your use of Yahoo! Groups is subject to:
                        > http://docs.yahoo.com/info/terms/
                        >
                        / html>


                      • gddrennan
                        Hi All, Just wondering if anyone knows if there is a Scrum User Group or other gathering of Scrummy folks in or near the Phoenix area? If not, anyone
                        Message 11 of 11 , Aug 1, 2007
                        • 0 Attachment
                          Hi All,

                          Just wondering if anyone knows if there is a Scrum User Group or other
                          gathering of Scrummy folks in or near the Phoenix area?

                          If not, anyone interested in starting one?

                          The meeting should only last about 15 minutes ;-)

                          Gregg
                        Your message has been successfully submitted and would be delivered to recipients shortly.