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

Re: Scrum (as a Maxwell Demon)

Expand Messages
  • Jeff Sutherland
    Mike Beedle s analysis is truly well spoken as Scrum was designed from the beginning as a metaprocess to transform an organization. Once it starts going in the
    Message 1 of 5 , Jun 2, 2005
      Mike Beedle's analysis is truly well spoken as Scrum was designed from
      the beginning as a metaprocess to transform an organization. Once it
      starts going in the smallest team, if impediments are logged and
      managed properly, the impact will be felt throughout the organization.

      It is interesting that as I do consulting engagements with companies,
      one of the elements that crops up most often that needs to be fixed is
      that ScrumMasters are not logging impediments, prioritizing them, and
      assigning resources to fix them. At the same time, the teams are not
      holding the ScrumMaster responsible in the daily meetings. The
      ScrumMaster should report on what he has done for the team today, i.e.
      impediments removed.

      As a result, I have been doing Scrum assessment days in the U.S. and
      Europe lately where I start off with a Scrum meeting with the
      following question that all pigs present must answer:

      1. What have you done to improve the development process in the last month?

      2. What will you do next month?

      3. What blocks are getting in your way?

      We then go through the basics of Scrum focused on theory, practice,
      and then ways people screw up the practice. I find that people don't
      understand the theory, therefore the practice misfires, and they fail
      to implement key practices that cause it to continue to misfire.

      By the end of the day after repeatedly going through theory, practice,
      misfires over and over again, we have an impediments list that is a
      work list for the team for the next 6-9 months.

      The summer is a slow period so I have time to do these assessments in
      Jun-Aug except for the CSM training I am doing with Ken Schwaber in
      July and the CSM at PatientKeeper in August if anyone is interested.
      Summer is a good time to do a restrospective on Scrum practice. It
      allows time to rethink some things and set up some new processes and
      procedures before everyone gets back from vacation. You can hit the
      deck running full steam by September and crack through resistance that
      has been creating impediments.

      Jeff Sutherland

      On 5/31/05, Mike Beedle <beedlem@...> wrote:
      >
      >
      >
      > (On relationships of Scrum,TOC, BPR, Systems' Thinking, Knowledge
      > Management, TQM, Complexity, Manufacturing, New Product Development, etc.)
      >
      > Although there are great synergies between TOC and Scrum, there are also
      > vast differences. Both provide patterns to resolve systemic problems akin to
      > those described in Systems' Thinking by Senge, but TOC resolves systemic problems
      > that are more akin to process improvement ala TQM, rather than complete overhauls
      > as in BPR, which I argue, is closer to what Scrum does – it reengineers the process
      > from scratch, by implementing high performance patterns altogether.
      >
      > For the most part, TOC, and The Goal, assume a somewhat repeatable business
      > process, where the process of removing constraints, exploiting constraints, finding
      > new ones, etc.; is an ongoing process in a somewhat stable, repeatable process.
      >
      > Scrum, on the other hand, generalizes this technique in the absence of a
      > repeatable process, it simply removes *any* constraints constantly, with no
      > assurance that the constraints removed will remain so the next day, and that the
      > particular constraint optimized "has been removed", and that we can move on to new
      > ones at that point. It is usually the case, however.
      >
      > Another important difference is that a Scrum team is already an
      > organizational structure that > avoids process anti-patterns like handoffs, iteration
      > and re-work (among different organizational structures, between an "analysis" team
      > and a "design team" for example, or between an organizational structure building
      > component A, communicating with another one building component B, in a Conway's
      > Law configuration i.e. where Organization Follows Architecture.
      >
      > In that sense, a Scrum team is a true "Case Team", as termed in Michael
      > Hammer's BPR, i.e. an organization structure that is *completely responsible* for the
      > success of a process or project, where the ScrumMaster is the "Case Manager* ala
      > Hammer, that > responds to the Product Owner.
      >
      > From the Knowledge Management perspective, TOC optimizes the process and
      > therefore, more knowledge of the processes themselves are more valued, while
      > in the Scrum (Case Team) perspective, the individual contributor's knowledge is
      > more valued.
      >
      > On the other, and to make things slightly more complicated, Scrum sits atop
      > a number of processes, that as more applications of the same kind are built, tend to be
      > more repeatable, like configuration management, testing of certain components,
      > vertical slice development or new applications on top of reusable
      > architectural services.
      >
      > The interesting thing to note, is that in Scrum, smaller reusable processes
      > develop underneath as a base of knowledge but they don't drive development, while
      > the Scrum process, acts as a "work generator/work management" "process envelope"
      > (a superprocess, or meta-process, if you prefer), that drives the work. (In Complexity
      > terms, it is the Maxwell Demon that provides the autocatalytic cycles to drive
      > self-organization, ala Kaufman's "Origins of Order"...
      >
      > - Mike


      --
      Jeff Sutherland, Ph.D.
      Chief Technology Officer
      PatientKeeper Inc.
      20 Guest Street, Suite 500
      Brighton, MA 02135

      Certified ScrumMaster Practitioner and Inventor of the Agile Scrum Process
      Microsoft Business Framework Advisory Council
      Object Management Group/HL7 Liaison Committee
      Co-Chair, HL7 Orders and Observations Technical Committee
      Co-Investigator, Operating Room of the Future, Univ. of Maryland Medical System
      (508) 644-8298
      jeff.sutherland@...
      ___________________________________
      KU Hospital, Dr. David Brailer, and PatientKeeper
      Featured on CNBC:
      http://www.patientkeeper.com/qt/cbs_high.html

      Brigham & Women's Hospital and PatientKeeper
      Featured on CBS News:
      http://www.patientkeeper.com/qt/cbs_high.html

      PatientKeeper Reports Record Growth:
      http://www.patientkeeper.com/pr/02_08_05.html

      Gartner's Analyst Insights on Mobile Healthcare:
      http://www.patientkeeper.com/pkgreport.html
    • Boris Gloger
      Hi Jeff, I really, really like your comment. see below... ... That is exactly my feeling and I always felt this. And we need to have this all the time in mind.
      Message 2 of 5 , Jun 2, 2005
        Hi Jeff,

        I really, really like your comment. see below...

        On 6/3/05, Jeff Sutherland <jeff.sutherland@... > wrote:
        Mike Beedle's analysis is truly well spoken as Scrum was designed from
        the beginning as a metaprocess to transform an organization.


        That is exactly my feeling and I always felt this. And we need to have this all the time in mind. A Scrum Master is a Change Agent. Scrum transforms organizations by showing what does not fit. So what we need is remove fear from Scrum Masters first. We need to find ways to give theme the security that they will have success as long as they care about the change. Although it is very very hard to do it.
         

        Once it
        starts going in the smallest team, if impediments are logged and
        managed properly, the impact will be felt throughout the organization.

        It is interesting that as I do consulting engagements with companies,
        one of the elements that crops up most often that needs to be fixed is
        that ScrumMasters are not logging impediments, prioritizing them, and
        assigning resources to fix them. At the same time, the teams are not
        holding the ScrumMaster responsible in the daily meetings. The
        ScrumMaster should report on what he has done for the team today, i.e.
        impediments removed.

        As a result, I have been doing Scrum assessment days in the U.S. and
        Europe lately where I start off with a Scrum meeting with the
        following question that all pigs present must answer:

        1. What have you done to improve the development process in the last month?

        2. What will you do next month?

        3. What blocks are getting in your way?


        thanks for this great idea!!!
         

        We then go through the basics of Scrum focused on theory, practice,
        and then ways people screw up the practice. I find that people don't
        understand the theory, therefore the practice misfires, and they fail
        to implement key practices that cause it to continue to misfire.


        Yes  - I agree and most of them are not really interested. Well this is not fully correct .... we need to find ways to explain the theory much better so that they will understand the theory.

        By the end of the day after repeatedly going through theory, practice,
        misfires over and over again, we have an impediments list that is a
        work list for the team for the next 6-9 months.

        The summer is a slow period so I have time to do these assessments in
        Jun-Aug except for the CSM training I am doing with Ken Schwaber in
        July and the CSM at PatientKeeper in August if anyone is interested.
        Summer is a good time to do a restrospective on Scrum practice. It
        allows time to rethink some things and set up some new processes and
        procedures before everyone gets back from vacation. You can hit the
        deck running full steam by September and crack through resistance that
        has been creating impediments.

        If you would do this on a weekend -- I will catch a flight and come to this meeting.
         
        Boris

        Jeff Sutherland

        On 5/31/05, Mike Beedle < beedlem@...> wrote:
        >
        >
        >
        > (On relationships of Scrum,TOC, BPR, Systems' Thinking, Knowledge
        > Management, TQM,  Complexity, Manufacturing, New Product Development, etc.)
        >
        > Although there are great synergies between TOC and Scrum, there are also
        > vast differences.  Both provide patterns to resolve systemic problems akin to
        > those described in Systems' Thinking by Senge, but TOC resolves systemic problems
        > that are more akin to process improvement ala TQM, rather than complete overhauls
        > as in BPR, which I argue, is closer to what Scrum does – it reengineers the process
        > from scratch, by implementing high performance patterns altogether.
        >
        > For the most part, TOC, and The Goal, assume a somewhat repeatable business
        > process, where the process of removing constraints, exploiting constraints, finding
        > new ones, etc.;  is an ongoing process in a somewhat stable, repeatable process.
        >
        > Scrum, on the other hand, generalizes this technique in the absence of a
        > repeatable process,  it simply removes *any* constraints constantly, with no
        > assurance that the constraints removed will remain so the next day, and that the
        > particular constraint optimized  "has been removed", and that we can move on to new
        > ones at that point.  It is usually the case,  however.
        >
        > Another important difference is that a Scrum team is already an
        > organizational structure that > avoids process anti-patterns like handoffs, iteration
        > and re-work (among different organizational structures, between an "analysis" team
        > and a "design team" for example, or between an organizational structure building
        > component A, communicating with another one  building component B, in a Conway's
        > Law configuration i.e. where Organization Follows Architecture.
        >
        > In that sense, a Scrum team is a true "Case Team", as termed in Michael
        > Hammer's BPR, i.e. an organization structure that is *completely responsible* for the
        > success of a process or project, where the ScrumMaster is the "Case Manager* ala
        > Hammer, that > responds to the Product Owner.
        >
        > From the Knowledge Management perspective, TOC optimizes the process and
        > therefore, more knowledge of the processes themselves are more valued, while
        > in the Scrum (Case Team) perspective, the individual contributor's knowledge is
        > more valued.
        >
        > On the other, and to make things slightly more complicated, Scrum sits atop
        > a number of processes, that as more applications of the same kind are built, tend to be
        > more repeatable, like configuration management, testing of certain components,
        > vertical slice development or new applications on top of reusable
        > architectural services.
        >
        > The interesting thing to note, is that in Scrum, smaller reusable processes
        > develop underneath as a base of knowledge but they don't drive development, while
        > the Scrum process, acts as a "work generator/work management" "process envelope"
        > (a superprocess, or meta-process, if you prefer), that drives the work.  (In Complexity
        > terms, it is the Maxwell Demon that provides the autocatalytic cycles to drive
        > self-organization,  ala Kaufman's "Origins of Order"...
        >
        > - Mike


        --
        Jeff Sutherland, Ph.D.
        Chief Technology Officer
        PatientKeeper Inc.
        20 Guest Street, Suite 500
        Brighton, MA 02135

        Certified ScrumMaster Practitioner and Inventor of the Agile Scrum Process
        Microsoft Business Framework Advisory Council
        Object Management Group/HL7 Liaison Committee
        Co-Chair, HL7 Orders and Observations Technical Committee
        Co-Investigator, Operating Room of the Future, Univ. of Maryland Medical System
        (508) 644-8298
        jeff.sutherland@...
        ___________________________________
        KU Hospital, Dr. David Brailer, and PatientKeeper
        Featured on CNBC:
        http://www.patientkeeper.com/qt/cbs_high.html

        Brigham & Women's Hospital and PatientKeeper
        Featured on CBS News:
        http://www.patientkeeper.com/qt/cbs_high.html

        PatientKeeper Reports Record Growth:
        http://www.patientkeeper.com/pr/02_08_05.html

        Gartner's Analyst Insights on Mobile Healthcare:
        http://www.patientkeeper.com/pkgreport.html


        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/

        <*> 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/




        --
        boris gloger
        www.glogerconsulting.de
        www.scrumeducation.com
      • Victor Szalvay
        Boris and Jeff, I absolutely agree with these observations. The more I work with agile transitions, the more I realize people have a very hard time
        Message 3 of 5 , Jun 3, 2005
          Boris and Jeff,

          I absolutely agree with these observations. The more I work with
          agile transitions, the more I realize people have a very hard time
          understanding (really understanding) Scrum theory and principles. Is
          it because Scrum is so antithetical to phase processes or chaos? In
          any case, Scrum seems difficult to digest in large doses. I've had
          better success with small batches and a longer, sustained training period.

          I've been away for a while, "Hi" to all my friends out there!

          -- Victor Szalvay

          --- In scrumdevelopment@yahoogroups.com, Boris Gloger
          <boris.gloger@g...> wrote:
          > Hi Jeff,
          >
          > I really, really like your comment. see below...
          >
          > On 6/3/05, Jeff Sutherland <jeff.sutherland@c...> wrote:
          > >
          > > Mike Beedle's analysis is truly well spoken as Scrum was designed from
          > > the beginning as a metaprocess to transform an organization.
          >
          >
          >
          > That is exactly my feeling and I always felt this. And we need to
          have this
          > all the time in mind. A Scrum Master is a Change Agent. Scrum
          transforms
          > organizations by showing what does not fit. So what we need is
          remove fear
          > from Scrum Masters first. We need to find ways to give theme the
          security
          > that they will have success as long as they care about the change.
          Although
          > it is very very hard to do it.
          >
          > Once it
          > > starts going in the smallest team, if impediments are logged and
          > > managed properly, the impact will be felt throughout the organization.
          > >
          > > It is interesting that as I do consulting engagements with companies,
          > > one of the elements that crops up most often that needs to be fixed is
          > > that ScrumMasters are not logging impediments, prioritizing them, and
          > > assigning resources to fix them. At the same time, the teams are not
          > > holding the ScrumMaster responsible in the daily meetings. The
          > > ScrumMaster should report on what he has done for the team today, i.e.
          > > impediments removed.
          > >
          > > As a result, I have been doing Scrum assessment days in the U.S. and
          > > Europe lately where I start off with a Scrum meeting with the
          > > following question that all pigs present must answer:
          > >
          > > 1. What have you done to improve the development process in the last
          > > month?
          > >
          > > 2. What will you do next month?
          > >
          > > 3. What blocks are getting in your way?
          >
          >
          >
          > thanks for this great idea!!!
          >
          > We then go through the basics of Scrum focused on theory, practice,
          > > and then ways people screw up the practice. I find that people don't
          > > understand the theory, therefore the practice misfires, and they fail
          > > to implement key practices that cause it to continue to misfire.
          >
          >
          >
          > Yes - I agree and most of them are not really interested. Well this
          is not
          > fully correct .... we need to find ways to explain the theory much
          better so
          > that they will understand the theory.
          >
          > By the end of the day after repeatedly going through theory, practice,
          > > misfires over and over again, we have an impediments list that is a
          > > work list for the team for the next 6-9 months.
          > >
          > > The summer is a slow period so I have time to do these assessments in
          > > Jun-Aug except for the CSM training I am doing with Ken Schwaber in
          > > July and the CSM at PatientKeeper in August if anyone is interested.
          > > Summer is a good time to do a restrospective on Scrum practice. It
          > > allows time to rethink some things and set up some new processes and
          > > procedures before everyone gets back from vacation. You can hit the
          > > deck running full steam by September and crack through resistance that
          > > has been creating impediments.
          >
          >
          > If you would do this on a weekend -- I will catch a flight and come
          to this
          > meeting.
          > Boris
          >
          > Jeff Sutherland
          > >
          > > On 5/31/05, Mike Beedle <beedlem@e...> wrote:
          > > >
          > > >
          > > >
          > > > (On relationships of Scrum,TOC, BPR, Systems' Thinking, Knowledge
          > > > Management, TQM, Complexity, Manufacturing, New Product
          Development,
          > > etc.)
          > > >
          > > > Although there are great synergies between TOC and Scrum, there
          are also
          > > > vast differences. Both provide patterns to resolve systemic
          problems
          > > akin to
          > > > those described in Systems' Thinking by Senge, but TOC resolves
          systemic
          > > problems
          > > > that are more akin to process improvement ala TQM, rather than
          complete
          > > overhauls
          > > > as in BPR, which I argue, is closer to what Scrum does – it
          reengineers
          > > the process
          > > > from scratch, by implementing high performance patterns altogether.
          > > >
          > > > For the most part, TOC, and The Goal, assume a somewhat repeatable
          > > business
          > > > process, where the process of removing constraints, exploiting
          > > constraints, finding
          > > > new ones, etc.; is an ongoing process in a somewhat stable,
          repeatable
          > > process.
          > > >
          > > > Scrum, on the other hand, generalizes this technique in the
          absence of a
          > > > repeatable process, it simply removes *any* constraints
          constantly, with
          > > no
          > > > assurance that the constraints removed will remain so the next
          day, and
          > > that the
          > > > particular constraint optimized "has been removed", and that we
          can move
          > > on to new
          > > > ones at that point. It is usually the case, however.
          > > >
          > > > Another important difference is that a Scrum team is already an
          > > > organizational structure that > avoids process anti-patterns like
          > > handoffs, iteration
          > > > and re-work (among different organizational structures, between an
          > > "analysis" team
          > > > and a "design team" for example, or between an organizational
          structure
          > > building
          > > > component A, communicating with another one building component
          B, in a
          > > Conway's
          > > > Law configuration i.e. where Organization Follows Architecture.
          > > >
          > > > In that sense, a Scrum team is a true "Case Team", as termed in
          Michael
          > > > Hammer's BPR, i.e. an organization structure that is *completely
          > > responsible* for the
          > > > success of a process or project, where the ScrumMaster is the "Case
          > > Manager* ala
          > > > Hammer, that > responds to the Product Owner.
          > > >
          > > > From the Knowledge Management perspective, TOC optimizes the
          process and
          > > > therefore, more knowledge of the processes themselves are more
          valued,
          > > while
          > > > in the Scrum (Case Team) perspective, the individual contributor's
          > > knowledge is
          > > > more valued.
          > > >
          > > > On the other, and to make things slightly more complicated,
          Scrum sits
          > > atop
          > > > a number of processes, that as more applications of the same
          kind are
          > > built, tend to be
          > > > more repeatable, like configuration management, testing of certain
          > > components,
          > > > vertical slice development or new applications on top of reusable
          > > > architectural services.
          > > >
          > > > The interesting thing to note, is that in Scrum, smaller reusable
          > > processes
          > > > develop underneath as a base of knowledge but they don't drive
          > > development, while
          > > > the Scrum process, acts as a "work generator/work management"
          "process
          > > envelope"
          > > > (a superprocess, or meta-process, if you prefer), that drives
          the work.
          > > (In Complexity
          > > > terms, it is the Maxwell Demon that provides the autocatalytic
          cycles to
          > > drive
          > > > self-organization, ala Kaufman's "Origins of Order"...
          > > >
          > > > - Mike
          > >
          > >
          > > --
          > > Jeff Sutherland, Ph.D.
          > > Chief Technology Officer
          > > PatientKeeper Inc.
          > > 20 Guest Street, Suite 500
          > > Brighton, MA 02135
          > >
          > > Certified ScrumMaster Practitioner and Inventor of the Agile Scrum
          Process
          > > Microsoft Business Framework Advisory Council
          > > Object Management Group/HL7 Liaison Committee
          > > Co-Chair, HL7 Orders and Observations Technical Committee
          > > Co-Investigator, Operating Room of the Future, Univ. of Maryland
          Medical
          > > System
          > > (508) 644-8298
          > > jeff.sutherland@c...
          > > ___________________________________
          > > KU Hospital, Dr. David Brailer, and PatientKeeper
          > > Featured on CNBC:
          > > http://www.patientkeeper.com/qt/cbs_high.html
          > >
          > > Brigham & Women's Hospital and PatientKeeper
          > > Featured on CBS News:
          > > http://www.patientkeeper.com/qt/cbs_high.html
          > >
          > > PatientKeeper Reports Record Growth:
          > > http://www.patientkeeper.com/pr/02_08_05.html
          > >
          > > Gartner's Analyst Insights on Mobile Healthcare:
          > > http://www.patientkeeper.com/pkgreport.html
          > >
          > >
          > > To Post a message, send it to: scrumdevelopment@e...
          > > To Unsubscribe, send a blank message to:
          > > scrumdevelopment-unsubscribe@e...
          > > Yahoo! Groups Links
          > >
          > >
          > >
          > >
          > >
          >
          >
          > --
          > boris gloger
          > www.glogerconsulting.de <http://www.glogerconsulting.de>
          > www.scrumeducation.com <http://www.scrumeducation.com>
        • Deb
          So, those of you with good experiences of changing the old paradigm for the new Agile one... What has worked best to induce the shift? Was it something obvious
          Message 4 of 5 , Jun 3, 2005
            So, those of you with good experiences of changing the old paradigm
            for the new Agile one...

            What has worked best to induce the shift? Was it something obvious and
            simple? Or drawn-out and arduous? Were the Scrum practices enough? Did
            you add something that "tipped" the group?

            Please share your successes at making the paradigm shift!

            --- In scrumdevelopment@yahoogroups.com, "Victor Szalvay"
            <victor@d...> wrote:
            > Boris and Jeff,
            >
            > I absolutely agree with these observations. The more I work with
            > agile transitions, the more I realize people have a very hard time
            > understanding (really understanding) Scrum theory and principles. Is
            > it because Scrum is so antithetical to phase processes or chaos? In
            > any case, Scrum seems difficult to digest in large doses. I've had
            > better success with small batches and a longer, sustained training
            period.
            >
            > I've been away for a while, "Hi" to all my friends out there!
            >
            > -- Victor Szalvay
            >
            > --- In scrumdevelopment@yahoogroups.com, Boris Gloger
            > <boris.gloger@g...> wrote:
            > > Hi Jeff,
            > >
            > > I really, really like your comment. see below...
            > >
            > > On 6/3/05, Jeff Sutherland <jeff.sutherland@c...> wrote:
            > > >
            > > > Mike Beedle's analysis is truly well spoken as Scrum was
            designed from
            > > > the beginning as a metaprocess to transform an organization.
            > >
            > >
            > >
            > > That is exactly my feeling and I always felt this. And we need to
            > have this
            > > all the time in mind. A Scrum Master is a Change Agent. Scrum
            > transforms
            > > organizations by showing what does not fit. So what we need is
            > remove fear
            > > from Scrum Masters first. We need to find ways to give theme the
            > security
            > > that they will have success as long as they care about the change.
            > Although
            > > it is very very hard to do it.
            > >
            > > Once it
            > > > starts going in the smallest team, if impediments are logged and
            > > > managed properly, the impact will be felt throughout the
            organization.
            > > >
            > > > It is interesting that as I do consulting engagements with
            companies,
            > > > one of the elements that crops up most often that needs to be
            fixed is
            > > > that ScrumMasters are not logging impediments, prioritizing
            them, and
            > > > assigning resources to fix them. At the same time, the teams are not
            > > > holding the ScrumMaster responsible in the daily meetings. The
            > > > ScrumMaster should report on what he has done for the team
            today, i.e.
            > > > impediments removed.
            > > >
            > > > As a result, I have been doing Scrum assessment days in the U.S. and
            > > > Europe lately where I start off with a Scrum meeting with the
            > > > following question that all pigs present must answer:
            > > >
            > > > 1. What have you done to improve the development process in the
            last
            > > > month?
            > > >
            > > > 2. What will you do next month?
            > > >
            > > > 3. What blocks are getting in your way?
            > >
            > >
            > >
            > > thanks for this great idea!!!
            > >
            > > We then go through the basics of Scrum focused on theory, practice,
            > > > and then ways people screw up the practice. I find that people don't
            > > > understand the theory, therefore the practice misfires, and they
            fail
            > > > to implement key practices that cause it to continue to misfire.
            > >
            > >
            > >
            > > Yes - I agree and most of them are not really interested. Well this
            > is not
            > > fully correct .... we need to find ways to explain the theory much
            > better so
            > > that they will understand the theory.
            > >
            > > By the end of the day after repeatedly going through theory, practice,
            > > > misfires over and over again, we have an impediments list that is a
            > > > work list for the team for the next 6-9 months.
            > > >
            > > > The summer is a slow period so I have time to do these
            assessments in
            > > > Jun-Aug except for the CSM training I am doing with Ken Schwaber in
            > > > July and the CSM at PatientKeeper in August if anyone is interested.
            > > > Summer is a good time to do a restrospective on Scrum practice. It
            > > > allows time to rethink some things and set up some new processes and
            > > > procedures before everyone gets back from vacation. You can hit the
            > > > deck running full steam by September and crack through
            resistance that
            > > > has been creating impediments.
            > >
            > >
            > > If you would do this on a weekend -- I will catch a flight and come
            > to this
            > > meeting.
            > > Boris
            > >
            > > Jeff Sutherland
            > > >
            > > > On 5/31/05, Mike Beedle <beedlem@e...> wrote:
            > > > >
            > > > >
            > > > >
            > > > > (On relationships of Scrum,TOC, BPR, Systems' Thinking, Knowledge
            > > > > Management, TQM, Complexity, Manufacturing, New Product
            > Development,
            > > > etc.)
            > > > >
            > > > > Although there are great synergies between TOC and Scrum, there
            > are also
            > > > > vast differences. Both provide patterns to resolve systemic
            > problems
            > > > akin to
            > > > > those described in Systems' Thinking by Senge, but TOC resolves
            > systemic
            > > > problems
            > > > > that are more akin to process improvement ala TQM, rather than
            > complete
            > > > overhauls
            > > > > as in BPR, which I argue, is closer to what Scrum does – it
            > reengineers
            > > > the process
            > > > > from scratch, by implementing high performance patterns
            altogether.
            > > > >
            > > > > For the most part, TOC, and The Goal, assume a somewhat
            repeatable
            > > > business
            > > > > process, where the process of removing constraints, exploiting
            > > > constraints, finding
            > > > > new ones, etc.; is an ongoing process in a somewhat stable,
            > repeatable
            > > > process.
            > > > >
            > > > > Scrum, on the other hand, generalizes this technique in the
            > absence of a
            > > > > repeatable process, it simply removes *any* constraints
            > constantly, with
            > > > no
            > > > > assurance that the constraints removed will remain so the next
            > day, and
            > > > that the
            > > > > particular constraint optimized "has been removed", and that we
            > can move
            > > > on to new
            > > > > ones at that point. It is usually the case, however.
            > > > >
            > > > > Another important difference is that a Scrum team is already an
            > > > > organizational structure that > avoids process anti-patterns like
            > > > handoffs, iteration
            > > > > and re-work (among different organizational structures,
            between an
            > > > "analysis" team
            > > > > and a "design team" for example, or between an organizational
            > structure
            > > > building
            > > > > component A, communicating with another one building component
            > B, in a
            > > > Conway's
            > > > > Law configuration i.e. where Organization Follows Architecture.
            > > > >
            > > > > In that sense, a Scrum team is a true "Case Team", as termed in
            > Michael
            > > > > Hammer's BPR, i.e. an organization structure that is *completely
            > > > responsible* for the
            > > > > success of a process or project, where the ScrumMaster is the
            "Case
            > > > Manager* ala
            > > > > Hammer, that > responds to the Product Owner.
            > > > >
            > > > > From the Knowledge Management perspective, TOC optimizes the
            > process and
            > > > > therefore, more knowledge of the processes themselves are more
            > valued,
            > > > while
            > > > > in the Scrum (Case Team) perspective, the individual
            contributor's
            > > > knowledge is
            > > > > more valued.
            > > > >
            > > > > On the other, and to make things slightly more complicated,
            > Scrum sits
            > > > atop
            > > > > a number of processes, that as more applications of the same
            > kind are
            > > > built, tend to be
            > > > > more repeatable, like configuration management, testing of
            certain
            > > > components,
            > > > > vertical slice development or new applications on top of reusable
            > > > > architectural services.
            > > > >
            > > > > The interesting thing to note, is that in Scrum, smaller reusable
            > > > processes
            > > > > develop underneath as a base of knowledge but they don't drive
            > > > development, while
            > > > > the Scrum process, acts as a "work generator/work management"
            > "process
            > > > envelope"
            > > > > (a superprocess, or meta-process, if you prefer), that drives
            > the work.
            > > > (In Complexity
            > > > > terms, it is the Maxwell Demon that provides the autocatalytic
            > cycles to
            > > > drive
            > > > > self-organization, ala Kaufman's "Origins of Order"...
            > > > >
            > > > > - Mike
            > > >
            > > >
            > > > --
            > > > Jeff Sutherland, Ph.D.
            > > > Chief Technology Officer
            > > > PatientKeeper Inc.
            > > > 20 Guest Street, Suite 500
            > > > Brighton, MA 02135
            > > >
            > > > Certified ScrumMaster Practitioner and Inventor of the Agile Scrum
            > Process
            > > > Microsoft Business Framework Advisory Council
            > > > Object Management Group/HL7 Liaison Committee
            > > > Co-Chair, HL7 Orders and Observations Technical Committee
            > > > Co-Investigator, Operating Room of the Future, Univ. of Maryland
            > Medical
            > > > System
            > > > (508) 644-8298
            > > > jeff.sutherland@c...
            > > > ___________________________________
            > > > KU Hospital, Dr. David Brailer, and PatientKeeper
            > > > Featured on CNBC:
            > > > http://www.patientkeeper.com/qt/cbs_high.html
            > > >
            > > > Brigham & Women's Hospital and PatientKeeper
            > > > Featured on CBS News:
            > > > http://www.patientkeeper.com/qt/cbs_high.html
            > > >
            > > > PatientKeeper Reports Record Growth:
            > > > http://www.patientkeeper.com/pr/02_08_05.html
            > > >
            > > > Gartner's Analyst Insights on Mobile Healthcare:
            > > > http://www.patientkeeper.com/pkgreport.html
            > > >
            > > >
            > > > To Post a message, send it to: scrumdevelopment@e...
            > > > To Unsubscribe, send a blank message to:
            > > > scrumdevelopment-unsubscribe@e...
            > > > Yahoo! Groups Links
            > > >
            > > >
            > > >
            > > >
            > > >
            > >
            > >
            > > --
            > > boris gloger
            > > www.glogerconsulting.de <http://www.glogerconsulting.de>
            > > www.scrumeducation.com <http://www.scrumeducation.com>
          • Deb
            And, while we re sharing success stories... I m dying to know: Something great is going on in VA - there seems to be a concentration of Scrum projects there.
            Message 5 of 5 , Jun 3, 2005
              And, while we're sharing success stories... I'm dying to know:

              Something great is going on in VA - there seems to be a concentration
              of Scrum projects there. So - who did what? A CSM course? Some
              influential CEO got a hold of Ken's book? What?

              Does anyone know what "tipped" VA? Tell me, tell me, I want to do the
              same in Toronto!

              deb

              (apologies, I didn't trim my last post, it was huge. Sorry!)

              --- In scrumdevelopment@yahoogroups.com, "Deb" <deborah@h...> wrote:
              > So, those of you with good experiences of changing the old paradigm
              > for the new Agile one...
              >
              > What has worked best to induce the shift? Was it something obvious and
              > simple? Or drawn-out and arduous? Were the Scrum practices enough? Did
              > you add something that "tipped" the group?
              >
              > Please share your successes at making the paradigm shift!
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.