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

RE: [scrumdevelopment] Re: Planning vs. Predicting

Expand Messages
  • Ken Schwaber
    Hal says: We can begin measuring the performance of our planning. That s a pretty significant shift from measuring why people can t do as we plan! I really
    Message 1 of 21 , Oct 15, 2002
      Hal says:
      "We can begin measuring the performance of our planning." That's a pretty
      significant shift from measuring why people can't do as we plan! I really
      like the human/people orientation of your comments, which I believe is the
      basis of agile processes. Do what is possible, do the best you can ... not,
      "do what we tell you to do."

      I think that the more complicated and stressful life becoms, the more people
      want to simplify and retreat. Working through complexities and anomalies
      takes time and effort, and communication with the most complex thing
      around - other people. So the natural desire is to believe that the plan can
      be enforced. I think the major benefit of agile is that it "dumbs down" the
      whole process so we stop expecting comlicated mechanisms and plans to
      substitute for communication, observation, and collaboration.

      Ken

      -----Original Message-----
      From: Hal Macomber [mailto:hal@...]
      Sent: Tuesday, October 15, 2002 9:57 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: Planning vs. Predicting


      The following thoughts were triggered by Mary's post, but relate to
      much more of the conversation of planning and predicting.

      We live in an environment that calls on us to be deterministic. We
      have theories that have allowed us to design with confidence: build
      bridges, make computers, and send people into space and return them
      safely. The confidence we gain in engineering is misplaced when we
      ask engineers to say how long it will take to perform a given task.
      The estimates we get, whether at a 10% or 90% confidence level are
      still estimates.

      We need to ask ourselves, "For the sake of what are we estimating?"
      Our history carries with it a concern for efficiency and a distrust
      of workers. Although we may not speak these concerns they loom in
      the background. People don't want to commit to an estimate nor a
      promise to complete for fear of retribution should they take longer
      or deliver late. That fear is well-placed. People do get punished.
      The future is uncertain and unknowable. Why should we expect people
      to give 'real' estimates when variables are uncontrollable and
      unrecognized, but the consequences are real? The 'new' reason for
      estimating is for making commitments that allow us to coordinate one
      with the other to fulfill the promises of the project. (Mary refers
      to this as "signalling and commitment".)

      Having said that, there's plenty we can do.
      ..We can stop multi-tasking. It creates delays, inferior results,
      frustrated people, and costs more.
      ..We can begin measuring the performance of our planning. How often
      are we able to do what we set out to do? And when we can't what was
      it that we missed?
      ..We can start treating planning as an on-going activity where we
      seek to benefit from time, learning, discovering, adjusting, and
      collaborating.
      ..We can create conditions for success by preparing work. Tasks go
      quickly when all resources are present and the outcome and means are
      in place.
      ..We can engage with each other like responsible people who when
      given a chance will act responsibly...because we know we will.
      ..And finally, we can work in a spirit of wonder of what we can do
      with each other creating worthwhileness wherever we go.

      Projects are human endeavors. We must embrace the human-ness of our
      work rather than the machine-like inference that lives in the
      metaphors of work. For those of us who took multivariate calculus we
      learned there is more than one right answer. Projects are not
      deterministic. Perhaps we can say they are stochastic (but not
      outside this forum). What we can say is projects involve people. We
      must plan, organize, and manage in ways that comes from a people-
      centric view.


      --- In scrumdevelopment@y..., "Mary Poppendieck" <mary@p...> wrote:
      > Hello Hal and Mike,
      >
      >
      >
      > Great discussion! (Oh, and Mike, I really like your Scrum Web
      Pages).
      >
      >
      >
      > I love the planning concept behind TOC, and was very interested in
      how
      > you get people to do 'real' estimates, Mike. In my experience, it
      is
      > difficult to get people to give the 50% estimate - they have
      developed a
      > habit of either giving the 10% (optimistic) estimate or the 90%
      (worst
      > case) estimate, based on the consequences of previous estimating
      errors.
      >
      >
      >
      >
      > The discussion has reminded me that the same word can mean different
      > things to different people. I think 'planning' has come to mean two
      > things - one meaning allows feedback (which Ken would call empirical
      > control) and one meaning does not (open loop or deterministic
      control).
      > When we talk to people, it would be good to understand which meaning
      > they attach to the word 'planning'.
      >
      >
      >
      > When I think of the first meaning of planning, I think of disaster
      > planning. We had a large disaster simulation at the Mall of
      America a
      > couple of weeks ago, involving many emergency response teams.
      There is
      > no intention to script what each person will do; the intention of
      the
      > exercise is (among other things) to improve the communications and
      > expectations between different emergency response groups.
      >
      >
      >
      > Another local event shows the opposite type of planning. This
      weekend
      > we had a marching band competition at our local high school. A
      couple
      > dozen marching bands / flags with up to 100 members were each given
      > about 20 minutes to perform. Believe me, every moment and every
      move
      > was scripted for every person in every group. Planning for this
      > competition would be open loop, or deterministic planning.
      >
      >
      >
      > Hal said that he considers planning a 'conversation', which I am not
      > sure I understand. But I'll take a stab at what I think he means.
      > First, a bit of background. All Just-in-Time systems work from some
      > sort of 'kanban'. Kanban is a way to signal the downstream process
      when
      > you need something made, and to find out from the upstream processes
      > what you should be making. A kanban may be implemented in many
      ways,
      > for example, with kanban cards or with full/empty locations for
      parts.
      > In lean manufacturing, all workstations are tightly coupled with
      > upstream and downstream workstations through a simple and fairly
      > well-understood mechanism of signaling and commitment between
      > workstations - some sort of kanban.
      >
      >
      >
      > I think that in agile software development, we need some sort of
      > equivalent way for different people or work groups to signal and
      obtain
      > commitments from each other. Another way to say this is that you
      do not
      > have a feedback loop unless you have a feedback mechanism. In lean
      > production, various kanban systems are the backbone of the feedback
      > loop. In software development, we use daily scrum meetings to
      provide
      > feedback (signaling and commitment) between developers on the same
      team;
      > meta-scrum (scrum-of-scrum) meetings to provide for signaling and
      > commitment between related development groups; sprint planning and
      > review meetings to provide feedback to customers; backlog lists,
      > burndown graphs and sometimes TOC Gantt charts to provide feedback
      to
      > stakeholders. Perhaps this is what Hal means by planning being a
      > conversation.
      >
      >
      >
      > Mary Poppendieck



      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • David J. Anderson
      This is an interesting thread. In my previous job at a large telco in the mid-west, the Senior Director for Engineering wanted to start reporting figures for
      Message 2 of 21 , Oct 15, 2002
        This is an interesting thread.

        In my previous job at a large telco in the mid-west,
        the Senior Director for Engineering wanted to start
        reporting figures for Feature Miletsones met/missed,
        at the business unit's monthly operations review.

        I turned this on its head and asked that the same
        metrics should be used to report "accuracy of our
        plans". I wanted the metric to measure the management
        (i.e. me and my colleagues) rather than the
        developers.

        I knew what a "milestones missed" metric would do to
        morale. The Senior Director was of the "thump fist and
        shout louder" school of IT management. Often I wonder
        how guys like that survive in this business.

        In summary: I agree entirely - we must measure the
        planning activity. I'd go further and say that it is
        more important to measure the performance of our
        managers than it is to measure the performance of our
        developers.

        David


        --- Ken Schwaber <ken.schwaber@...> wrote:

        <HR>
        <html><body>


        <tt>
        Hal says:<BR>
        "We can begin measuring the performance of our
        planning." That's a pretty<BR>
        significant shift from measuring why people can't do
        as we plan! I really<BR>
        like the human/people orientation of your comments,
        which I believe is the<BR>
        basis of agile processes. Do what is possible, do the
        best you can ... not,<BR>
        "do what we tell you to do."<BR>
        <BR>
        I think that the more complicated and stressful life
        becoms, the more people<BR>
        want to simplify and retreat. Working through
        complexities and anomalies<BR>
        takes time and effort, and communication with the most
        complex thing<BR>
        around - other people. So the natural desire is to
        believe that the plan can<BR>
        be enforced. I think the major benefit of agile is
        that it "dumbs down" the<BR>
        whole process so we stop expecting comlicated
        mechanisms and plans to<BR>
        substitute for communication, observation, and
        collaboration.<BR>
        <BR>
        Ken<BR>
        <BR>


        __________________________________________________
        Do you Yahoo!?
        Faith Hill - Exclusive Performances, Videos & More
        http://faith.yahoo.com
      • Pascal Roy
        IMHO, as long as measuring is done primarily to identify who is to blame (in this case measuring performance of the managers instead of developers), things
        Message 3 of 21 , Oct 15, 2002
          IMHO, as long as measuring is done primarily to identify who is to blame (in
          this case measuring "performance" of the managers instead of developers),
          things will never get any better for the team. It takes a pretty mature team
          and a lot of thrust to be able to use this measuring for team building.

          I'm thinking the problem we have in this industry has to do with how we
          define commitment and how commitments are made. As a software developer or
          development manager, what should I be expected to commit to?

          Nice thread BTW.

          Pascal Roy,
          Object Mentor Inc.

          >From: "David J. Anderson" <netherby_uk@...>
          >Reply-To: scrumdevelopment@yahoogroups.com
          >To: scrumdevelopment@yahoogroups.com
          >Subject: RE: [scrumdevelopment] Re: Planning vs. Predicting
          >Date: Tue, 15 Oct 2002 09:13:52 -0700 (PDT)
          >
          >This is an interesting thread.
          >
          >In my previous job at a large telco in the mid-west,
          >the Senior Director for Engineering wanted to start
          >reporting figures for Feature Miletsones met/missed,
          >at the business unit's monthly operations review.
          >
          >I turned this on its head and asked that the same
          >metrics should be used to report "accuracy of our
          >plans". I wanted the metric to measure the management
          >(i.e. me and my colleagues) rather than the
          >developers.
          >
          >I knew what a "milestones missed" metric would do to
          >morale. The Senior Director was of the "thump fist and
          >shout louder" school of IT management. Often I wonder
          >how guys like that survive in this business.
          >
          >In summary: I agree entirely - we must measure the
          >planning activity. I'd go further and say that it is
          >more important to measure the performance of our
          >managers than it is to measure the performance of our
          >developers.
          >
          >David
          >
          >
          >--- Ken Schwaber <ken.schwaber@...> wrote:
          >
          ><HR>
          ><html><body>
          >
          >
          ><tt>
          >Hal says:<BR>
          >"We can begin measuring the performance of our
          >planning." That's a pretty<BR>
          >significant shift from measuring why people can't do
          >as we plan! I really<BR>
          >like the human/people orientation of your comments,
          >which I believe is the<BR>
          >basis of agile processes. Do what is possible, do the
          >best you can ... not,<BR>
          >"do what we tell you to do."<BR>
          ><BR>
          >I think that the more complicated and stressful life
          >becoms, the more people<BR>
          >want to simplify and retreat. Working through
          >complexities and anomalies<BR>
          >takes time and effort, and communication with the most
          >complex thing<BR>
          >around - other people. So the natural desire is to
          >believe that the plan can<BR>
          >be enforced. I think the major benefit of agile is
          >that it "dumbs down" the<BR>
          >whole process so we stop expecting comlicated
          >mechanisms and plans to<BR>
          >substitute for communication, observation, and
          >collaboration.<BR>
          ><BR>
          >Ken<BR>
          ><BR>
          >
          >
          >__________________________________________________
          >Do you Yahoo!?
          >Faith Hill - Exclusive Performances, Videos & More
          >http://faith.yahoo.com




          Pascal Roy
          Object Mentor Inc.


          _________________________________________________________________
          MSN Photos is the easiest way to share and print your photos:
          http://photos.msn.com/support/worldwide.aspx
        • David J. Anderson
          Who said anything about blame? There is a difference between performance of a system and blaming an element in a system. Maybe I should have used the term
          Message 4 of 21 , Oct 15, 2002
            Who said anything about blame?

            There is a difference between performance of a system
            and blaming an element in a system. Maybe I should
            have used the term "management" rather than "manager".

            However, I take your point. We have too many bosses
            who believe that attributing blame and motivating by
            fear is the only way to run a software business. This
            is a sad reflection on reality.

            David

            --- Pascal Roy <pascal_roy_1967@...> wrote:

            <HR>
            <html><body>


            <tt>
            IMHO, as long as measuring is done primarily to
            identify who is to blame (in <BR>
            this case measuring "performance" of the
            managers instead of developers), <BR>
            things will never get any better for the team. It
            takes a pretty mature team <BR>
            and a lot of thrust to be able to use this measuring
            for team building.<BR>
            <BR>
            I'm thinking the problem we have in this industry has
            to do with how we <BR>
            define commitment and how commitments are made. As a
            software developer or <BR>
            development manager, what should I be expected to
            commit to?<BR>
            <BR>
            Nice thread BTW.<BR>
            <BR>
            Pascal Roy,<BR>
            Object Mentor Inc.<BR>
            <BR>
            >From: "David J. Anderson"
            <netherby_uk@...><BR>
            >Reply-To: scrumdevelopment@yahoogroups.com<BR>
            >To: scrumdevelopment@yahoogroups.com<BR>
            >Subject: RE: [scrumdevelopment] Re: Planning vs.
            Predicting<BR>
            >Date: Tue, 15 Oct 2002 09:13:52 -0700 (PDT)<BR>
            ><BR>
            >This is an interesting thread.<BR>
            ><BR>
            >In my previous job at a large telco in the
            mid-west,<BR>
            >the Senior Director for Engineering wanted to
            start<BR>
            >reporting figures for Feature Miletsones
            met/missed,<BR>
            >at the business unit's monthly operations
            review.<BR>
            ><BR>
            >I turned this on its head and asked that the
            same<BR>
            >metrics should be used to report "accuracy of
            our<BR>
            >plans". I wanted the metric to measure the
            management<BR>
            >(i.e. me and my colleagues) rather than the<BR>
            >developers.<BR>
            ><BR>
            >I knew what a "milestones missed" metric
            would do to<BR>
            >morale. The Senior Director was of the "thump
            fist and<BR>
            >shout louder" school of IT management. Often
            I wonder<BR>
            >how guys like that survive in this business.<BR>
            ><BR>
            >In summary: I agree entirely - we must measure
            the<BR>
            >planning activity. I'd go further and say that it
            is<BR>
            >more important to measure the performance of
            our<BR>
            >managers than it is to measure the performance of
            our<BR>
            >developers.<BR>
            ><BR>
            >David<BR>
            ><BR>
            ><BR>
            >--- Ken Schwaber <ken.schwaber@...>
            wrote:<BR>
            ><BR>
            ><HR><BR>
            ><html><body><BR>
            ><BR>
            ><BR>
            ><tt><BR>
            >Hal says:<BR><BR>
            >&quot;We can begin measuring the performance
            of our<BR>
            >planning.&quot; That's a pretty<BR><BR>
            >significant shift from measuring why people can't
            do<BR>
            >as we plan! I really<BR><BR>
            >like the human/people orientation of your
            comments,<BR>
            >which I believe is the<BR><BR>
            >basis of agile processes. Do what is possible, do
            the<BR>
            >best you can ... not,<BR><BR>
            >&quot;do what we tell you to
            do.&quot;<BR><BR>
            ><BR><BR>
            >I think that the more complicated and stressful
            life<BR>
            >becoms, the more people<BR><BR>
            >want to simplify and retreat. Working through<BR>
            >complexities and anomalies<BR><BR>
            >takes time and effort, and communication with the
            most<BR>
            >complex thing<BR><BR>
            >around - other people. So the natural desire is
            to<BR>
            >believe that the plan can<BR><BR>
            >be enforced. I think the major benefit of agile
            is<BR>
            >that it &quot;dumbs down&quot;
            the<BR><BR>
            >whole process so we stop expecting comlicated<BR>
            >mechanisms and plans to<BR><BR>
            >substitute for communication, observation, and<BR>
            >collaboration.<BR><BR>
            ><BR><BR>
            >Ken<BR><BR>
            ><BR><BR>
            ><BR>
            ><BR>
            >__________________________________________________<BR>
            >Do you Yahoo!?<BR>
            >Faith Hill - Exclusive Performances, Videos &
            More<BR>
            ><a
            href="http://faith.yahoo.com">http://faith.yahoo.com</a><BR>
            <BR>
            <BR>
            <BR>
            <BR>
            Pascal Roy<BR>
            Object Mentor Inc.<BR>
            <BR>
            <BR>
            _________________________________________________________________<BR>
            MSN Photos is the easiest way to share and print your
            photos: <BR>
            <a
            href="http://photos.msn.com/support/worldwide.aspx">http://photos.msn.com/support/worldwide.aspx</a><BR>
            <BR>
            </tt>

            <br>

            <!-- |**|begin egp html banner|**| -->

            <table border=0 cellspacing=0 cellpadding=2>
            <tr bgcolor=#FFFFCC>
            <td align=center><font size="-1"
            color=#003399><b>Yahoo! Groups Sponsor</b></font></td>
            </tr>
            <tr bgcolor=#FFFFFF>
            <td align=center width=470><table border=0
            cellpadding=0 cellspacing=0> <tr> <td
            align=center><font face=arial
            size=-2>ADVERTISEMENT</font><br><a
            href="http://rd.yahoo.com/M=234050.2482567.3895507.2273195/D=egroupweb/S=1707209021:HM/A=1274244/R=0/*http://webevents.broadcast.com/universal/8mile"><img
            src="http://us.a1.yimg.com/us.yimg.com/a/un/universal/8mile_hm_300x250.jpg"
            alt="" width="300" height="250"
            border="0"></a></td></tr></table></td>
            </tr>
            <tr><td><img alt="" width=1 height=1
            src="http://us.adserver.yahoo.com/l?M=234050.2482567.3895507.2273195/D=egroupmail/S=:HM/A=1274244/rand=952486610"></td></tr>
            </table>

            <!-- |**|end egp html banner|**| -->


            <br>
            <tt>
            To Post a message, send it to:  
            scrumdevelopment@...<BR>
            To Unsubscribe, send a blank message to:
            scrumdevelopment-unsubscribe@...</tt>
            <br>

            <br>
            <tt>Your use of Yahoo! Groups is subject to the <a
            href="http://docs.yahoo.com/info/terms/">Yahoo! Terms
            of Service</a>.</tt>
            </br>

            </body></html>



            __________________________________________________
            Do you Yahoo!?
            Faith Hill - Exclusive Performances, Videos & More
            http://faith.yahoo.com
          • Jonas Bengtsson
            ... Am I understanding you correctly if I read this as you are implying that by measuring the planning activity you measure the performance of management?
            Message 5 of 21 , Oct 15, 2002
              David J. Anderson wrote:
              > In summary: I agree entirely - we must measure the
              > planning activity. I'd go further and say that it is
              > more important to measure the performance of our
              > managers than it is to measure the performance of our
              > developers.

              Am I understanding you correctly if I read this as you are implying that by
              measuring the planning activity you measure the performance of management?

              Isn't planning a social activity of collaboration? Does poor planning
              indicate that the managers are doing a poor job, or that there are something
              wrong in the collaboration?

              /Jonas
            • David J. Anderson
              If there is something wrong with the collaboration is that not also the responsibility of the manager? ... David J. Anderson wrote:
              Message 6 of 21 , Oct 15, 2002
                If there is something wrong with the collaboration is
                that not also the responsibility of the manager?

                --- Jonas Bengtsson <jonas.b@...> wrote:

                <HR>
                <html><body>


                <tt>
                David J. Anderson wrote:<BR>
                > In summary: I agree entirely - we must measure
                the<BR>
                > planning activity. I'd go further and say that it
                is<BR>
                > more important to measure the performance of
                our<BR>
                > managers than it is to measure the performance of
                our<BR>
                > developers.<BR>
                <BR>
                Am I understanding you correctly if I read this as you
                are implying that by<BR>
                measuring the planning activity you measure the
                performance of management?<BR>
                <BR>
                Isn't planning a social activity of collaboration?
                Does poor planning<BR>
                indicate that the managers are doing a poor job, or
                that there are something<BR>
                wrong in the collaboration?<BR>
                <BR>
                /Jonas<BR>
                <BR>
                </tt>

                <br>

                <!-- |**|begin egp html banner|**| -->

                <table border=0 cellspacing=0 cellpadding=2>
                <tr bgcolor=#FFFFCC>
                <td align=center><font size="-1"
                color=#003399><b>Yahoo! Groups Sponsor</b></font></td>
                </tr>
                <tr bgcolor=#FFFFFF>
                <td align=center width=470><table border=0
                cellpadding=0 cellspacing=0> <tr> <td
                align=center><font face=arial
                size=-2>ADVERTISEMENT</font><br><a
                href="http://rd.yahoo.com/M=234050.2482567.3895507.2273195/D=egroupweb/S=1707209021:HM/A=1274244/R=0/*http://webevents.broadcast.com/universal/8mile"><img
                src="http://us.a1.yimg.com/us.yimg.com/a/un/universal/8mile_hm_300x250.jpg"
                alt="" width="300" height="250"
                border="0"></a></td></tr></table></td>
                </tr>
                <tr><td><img alt="" width=1 height=1
                src="http://us.adserver.yahoo.com/l?M=234050.2482567.3895507.2273195/D=egroupmail/S=:HM/A=1274244/rand=366796684"></td></tr>
                </table>

                <!-- |**|end egp html banner|**| -->


                <br>
                <tt>
                To Post a message, send it to:  
                scrumdevelopment@...<BR>
                To Unsubscribe, send a blank message to:
                scrumdevelopment-unsubscribe@...</tt>
                <br>

                <br>
                <tt>Your use of Yahoo! Groups is subject to the <a
                href="http://docs.yahoo.com/info/terms/">Yahoo! Terms
                of Service</a>.</tt>
                </br>

                </body></html>



                __________________________________________________
                Do you Yahoo!?
                Faith Hill - Exclusive Performances, Videos & More
                http://faith.yahoo.com
              • Jonas Bengtsson
                ... I agree that having good collaboration is the responibility of the manager. But it is also the responsibility of everyone else involved. It takes two to
                Message 7 of 21 , Oct 15, 2002
                  David J. Anderson wrote:
                  > If there is something wrong with the collaboration is
                  > that not also the responsibility of the manager?

                  I agree that having good collaboration is the responibility of the manager.

                  But it is also the responsibility of everyone else involved.

                  It takes two to tango...

                  /Jonas
                • Mike Cohn
                  One of the absolute keys is never to predict things with an implied margin of error greater than you believe. Saying we ll ship the product on June 13th is
                  Message 8 of 21 , Oct 15, 2002
                    One of the absolute keys is never to predict things with an implied
                    margin of error greater than you believe. Saying "we'll ship the product
                    on June 13th" is always a mistake because it implies the precision of
                    your estimation can be measured at the day level. It probably can't be.
                    Committing to things like "we'll finish in 4-5 sprints" is ideal because
                    you both give a range and very clearly show you don't have the precision
                    in your process to give anything more accurate than that.

                    Also, given that measuring will change behavior around what is measured
                    it is almost certain that if you start measuring the number of
                    milestones a manager misses the manager will pad those estimates. For
                    projects looking for quick delivery of value rather than ultimate
                    assurance about dates that's probably a really bad idea.

                    -----Original Message-----
                    From: Pascal Roy [mailto:pascal_roy_1967@...]
                    Sent: Tuesday, October 15, 2002 11:29 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: RE: [scrumdevelopment] Re: Planning vs. Predicting

                    IMHO, as long as measuring is done primarily to identify who is to blame
                    (in
                    this case measuring "performance" of the managers instead of
                    developers),
                    things will never get any better for the team. It takes a pretty mature
                    team
                    and a lot of thrust to be able to use this measuring for team building.

                    I'm thinking the problem we have in this industry has to do with how we
                    define commitment and how commitments are made. As a software developer
                    or
                    development manager, what should I be expected to commit to?

                    Nice thread BTW.

                    Pascal Roy,
                    Object Mentor Inc.

                    >From: "David J. Anderson" <netherby_uk@...>
                    >Reply-To: scrumdevelopment@yahoogroups.com
                    >To: scrumdevelopment@yahoogroups.com
                    >Subject: RE: [scrumdevelopment] Re: Planning vs. Predicting
                    >Date: Tue, 15 Oct 2002 09:13:52 -0700 (PDT)
                    >
                    >This is an interesting thread.
                    >
                    >In my previous job at a large telco in the mid-west,
                    >the Senior Director for Engineering wanted to start
                    >reporting figures for Feature Miletsones met/missed,
                    >at the business unit's monthly operations review.
                    >
                    >I turned this on its head and asked that the same
                    >metrics should be used to report "accuracy of our
                    >plans". I wanted the metric to measure the management
                    >(i.e. me and my colleagues) rather than the
                    >developers.
                    >
                    >I knew what a "milestones missed" metric would do to
                    >morale. The Senior Director was of the "thump fist and
                    >shout louder" school of IT management. Often I wonder
                    >how guys like that survive in this business.
                    >
                    >In summary: I agree entirely - we must measure the
                    >planning activity. I'd go further and say that it is
                    >more important to measure the performance of our
                    >managers than it is to measure the performance of our
                    >developers.
                    >
                    >David
                    >
                    >
                    >--- Ken Schwaber <ken.schwaber@...> wrote:
                    >
                    ><HR>
                    ><html><body>
                    >
                    >
                    ><tt>
                    >Hal says:<BR>
                    >"We can begin measuring the performance of our
                    >planning." That's a pretty<BR>
                    >significant shift from measuring why people can't do
                    >as we plan! I really<BR>
                    >like the human/people orientation of your comments,
                    >which I believe is the<BR>
                    >basis of agile processes. Do what is possible, do the
                    >best you can ... not,<BR>
                    >"do what we tell you to do."<BR>
                    ><BR>
                    >I think that the more complicated and stressful life
                    >becoms, the more people<BR>
                    >want to simplify and retreat. Working through
                    >complexities and anomalies<BR>
                    >takes time and effort, and communication with the most
                    >complex thing<BR>
                    >around - other people. So the natural desire is to
                    >believe that the plan can<BR>
                    >be enforced. I think the major benefit of agile is
                    >that it "dumbs down" the<BR>
                    >whole process so we stop expecting comlicated
                    >mechanisms and plans to<BR>
                    >substitute for communication, observation, and
                    >collaboration.<BR>
                    ><BR>
                    >Ken<BR>
                    ><BR>
                    >
                    >
                    >__________________________________________________
                    >Do you Yahoo!?
                    >Faith Hill - Exclusive Performances, Videos & More
                    >http://faith.yahoo.com




                    Pascal Roy
                    Object Mentor Inc.


                    _________________________________________________________________
                    MSN Photos is the easiest way to share and print your photos:
                    http://photos.msn.com/support/worldwide.aspx



                    To Post a message, send it to: scrumdevelopment@...
                    To Unsubscribe, send a blank message to:
                    scrumdevelopment-unsubscribe@...

                    Your use of Yahoo! Groups is subject to
                    http://docs.yahoo.com/info/terms/
                  • David J. Anderson
                    I agree entirely. However, getting a team to the point where they accept shared responsibility is the role of the manager. Short of introducing a hippocratic
                    Message 9 of 21 , Oct 15, 2002
                      I agree entirely. However, getting a team to the point
                      where they accept shared responsibility is the role of
                      the manager.

                      Short of introducing a "hippocratic oath" for
                      professional software engineers, it has to be the
                      responsibility of the manager to grow shared
                      responsibility.

                      Personally, I don't think 2 to tango is appropriate. I
                      continually repeat to my team that "software
                      development is a team sport" (implication that its not
                      a beach volley team but something larger)

                      --- Jonas Bengtsson <jonas.b@...> wrote:

                      <HR>
                      <html><body>


                      <tt>
                      David J. Anderson wrote: <BR>
                      > If there is something wrong with the
                      collaboration is<BR>
                      > that not also the responsibility of the
                      manager?<BR>
                      <BR>
                      I agree that having good collaboration is the
                      responibility of the manager.<BR>
                      <BR>
                      But it is also the responsibility of everyone else
                      involved.<BR>
                      <BR>
                      It takes two to tango...<BR>
                      <BR>
                      /Jonas<BR>
                      </tt>

                      <br>



                      __________________________________________________
                      Do you Yahoo!?
                      Faith Hill - Exclusive Performances, Videos & More
                      http://faith.yahoo.com
                    • Mary Poppendieck
                      As I understand Lean Construction, the crew leaders of each trade meet every week and agree among each other what will get done the next week. They also
                      Message 10 of 21 , Oct 16, 2002
                        As I understand Lean Construction, the crew leaders of each trade
                        meet every week and agree among each other what will get done the
                        next week. They also review their commitments from the week before,
                        using a measure called PPC (percent planned complete). They
                        evaluate what they agreed to do but could not get done, and try to
                        determine the causes of why things did not get done (it rained, the
                        material wasn't on site – well why not – the truck got a flat tire,
                        two guys on my crew got sick, etc.). They try to see if they can
                        eliminate whatever caused these problems the next time. In this
                        way, they learn how to make commitments they can keep, and the
                        weekly commitments become more reliable as time goes on.

                        Mary

                        --- In scrumdevelopment@y..., "Pascal Roy" <pascal_roy_1967@h...>
                        wrote:
                        > IMHO, as long as measuring is done primarily to identify who is to
                        blame (in
                        > this case measuring "performance" of the managers instead of
                        developers),
                        > things will never get any better for the team. It takes a pretty
                        mature team
                        > and a lot of thrust to be able to use this measuring for team
                        building.
                        >
                        > I'm thinking the problem we have in this industry has to do with
                        how we
                        > define commitment and how commitments are made. As a software
                        developer or
                        > development manager, what should I be expected to commit to?
                        >
                        > Nice thread BTW.
                        >
                        > Pascal Roy,
                        > Object Mentor Inc.
                        >
                        > >From: "David J. Anderson" <netherby_uk@y...>
                        > >Reply-To: scrumdevelopment@y...
                        > >To: scrumdevelopment@y...
                        > >Subject: RE: [scrumdevelopment] Re: Planning vs. Predicting
                        > >Date: Tue, 15 Oct 2002 09:13:52 -0700 (PDT)
                        > >
                        > >This is an interesting thread.
                        > >
                        > >In my previous job at a large telco in the mid-west,
                        > >the Senior Director for Engineering wanted to start
                        > >reporting figures for Feature Miletsones met/missed,
                        > >at the business unit's monthly operations review.
                        > >
                        > >I turned this on its head and asked that the same
                        > >metrics should be used to report "accuracy of our
                        > >plans". I wanted the metric to measure the management
                        > >(i.e. me and my colleagues) rather than the
                        > >developers.
                        > >
                        > >I knew what a "milestones missed" metric would do to
                        > >morale. The Senior Director was of the "thump fist and
                        > >shout louder" school of IT management. Often I wonder
                        > >how guys like that survive in this business.
                        > >
                        > >In summary: I agree entirely - we must measure the
                        > >planning activity. I'd go further and say that it is
                        > >more important to measure the performance of our
                        > >managers than it is to measure the performance of our
                        > >developers.
                        > >
                        > >David
                        > >
                        > >
                        > >--- Ken Schwaber <ken.schwaber@v...> wrote:
                        > >
                        > ><HR>
                        > ><html><body>
                        > >
                        > >
                        > ><tt>
                        > >Hal says:<BR>
                        > >"We can begin measuring the performance of our
                        > >planning." That's a pretty<BR>
                        > >significant shift from measuring why people can't do
                        > >as we plan! I really<BR>
                        > >like the human/people orientation of your comments,
                        > >which I believe is the<BR>
                        > >basis of agile processes. Do what is possible, do the
                        > >best you can ... not,<BR>
                        > >"do what we tell you to do."<BR>
                        > ><BR>
                        > >I think that the more complicated and stressful life
                        > >becoms, the more people<BR>
                        > >want to simplify and retreat. Working through
                        > >complexities and anomalies<BR>
                        > >takes time and effort, and communication with the most
                        > >complex thing<BR>
                        > >around - other people. So the natural desire is to
                        > >believe that the plan can<BR>
                        > >be enforced. I think the major benefit of agile is
                        > >that it "dumbs down" the<BR>
                        > >whole process so we stop expecting comlicated
                        > >mechanisms and plans to<BR>
                        > >substitute for communication, observation, and
                        > >collaboration.<BR>
                        > ><BR>
                        > >Ken<BR>
                        > ><BR>
                        > >
                        > >
                        > >__________________________________________________
                        > >Do you Yahoo!?
                        > >Faith Hill - Exclusive Performances, Videos & More
                        > >http://faith.yahoo.com
                        >
                        >
                        >
                        >
                        > Pascal Roy
                        > Object Mentor Inc.
                        >
                        >
                        > _________________________________________________________________
                        > MSN Photos is the easiest way to share and print your photos:
                        > http://photos.msn.com/support/worldwide.aspx
                      • Pascal Roy
                        Mary, Right, in XP we use yesterday s weather (you are more likely to get done this iteration the same amount of work as the previous iteration). Even so, that
                        Message 11 of 21 , Oct 16, 2002
                          Mary,

                          Right, in XP we use yesterday's weather (you are more likely to get done
                          this iteration the same amount of work as the previous iteration). Even so,
                          that doesn't take care of the initial commitment problem. Very often,
                          external commitments (the ones you can't break because you'll get sued or
                          worse) were made before a credible velocity can be established. In most
                          cases, initial velocity guesstimates are optimistic and the team pays for
                          that dearly till the end of the project because they have "commited" (or
                          forced to commit?) to something they can't deliver and their success is
                          based on meeting that initial guesstimate commitment.There is this idea
                          floating around that somehow the original plan is "THE PLAN" by which the
                          success of the project should be measured against. People can't get past
                          that apparently. After being hammered for not conforming to "THE PLAN" ,
                          teams get smart: the next time they estimate, they lie and give estimates so
                          big they can be sure to make it. In theory, that could work. However,
                          because people aren't generally stupid, they usually figure out they are
                          being lied to and then trust, if there was any already, just disappears
                          creating what I would call a fun and very productive place to work at... The
                          practice of buffering estimates to me is just a symptom of the fear we have
                          of this commitment and is just another way of covering our asses. It just
                          adds another level of complexity to the problem by introducing yet another
                          variable into the mix as if there weren't enough unknowns already. I don't
                          see a win/win situation in there. It feels more like people are playing not
                          to loose...

                          I'm really not advocating having no commitment at all (for obvious business
                          reasons but also for team motivation). I'm just trying to figure out how to
                          commit in a way that does not push team members (business, customer,
                          developers) to become at odds with each other as soon as things don't go as
                          originally planned and more critically when the hard decisions need to be
                          taken. Any ideas on how to deal with initial external commitments?

                          Pascal Roy
                          Object Mentor Inc.


                          >From: "Mary Poppendieck" <mary@...>
                          >Reply-To: scrumdevelopment@yahoogroups.com
                          >To: scrumdevelopment@yahoogroups.com
                          >Subject: [scrumdevelopment] Re: Planning vs. Predicting
                          >Date: Wed, 16 Oct 2002 08:15:21 -0000
                          >
                          >As I understand Lean Construction, the crew leaders of each trade
                          >meet every week and agree among each other what will get done the
                          >next week. They also review their commitments from the week before,
                          >using a measure called PPC (percent planned complete). They
                          >evaluate what they agreed to do but could not get done, and try to
                          >determine the causes of why things did not get done (it rained, the
                          >material wasn't on site � well why not � the truck got a flat tire,
                          >two guys on my crew got sick, etc.). They try to see if they can
                          >eliminate whatever caused these problems the next time. In this
                          >way, they learn how to make commitments they can keep, and the
                          >weekly commitments become more reliable as time goes on.
                          >
                          >Mary
                          >
                          >--- In scrumdevelopment@y..., "Pascal Roy" <pascal_roy_1967@h...>
                          >wrote:
                          > > IMHO, as long as measuring is done primarily to identify who is to
                          >blame (in
                          > > this case measuring "performance" of the managers instead of
                          >developers),
                          > > things will never get any better for the team. It takes a pretty
                          >mature team
                          > > and a lot of thrust to be able to use this measuring for team
                          >building.
                          > >
                          > > I'm thinking the problem we have in this industry has to do with
                          >how we
                          > > define commitment and how commitments are made. As a software
                          >developer or
                          > > development manager, what should I be expected to commit to?
                          > >
                          > > Nice thread BTW.
                          > >
                          > > Pascal Roy,
                          > > Object Mentor Inc.
                          > >
                          > > >From: "David J. Anderson" <netherby_uk@y...>
                          > > >Reply-To: scrumdevelopment@y...
                          > > >To: scrumdevelopment@y...
                          > > >Subject: RE: [scrumdevelopment] Re: Planning vs. Predicting
                          > > >Date: Tue, 15 Oct 2002 09:13:52 -0700 (PDT)
                          > > >
                          > > >This is an interesting thread.
                          > > >
                          > > >In my previous job at a large telco in the mid-west,
                          > > >the Senior Director for Engineering wanted to start
                          > > >reporting figures for Feature Miletsones met/missed,
                          > > >at the business unit's monthly operations review.
                          > > >
                          > > >I turned this on its head and asked that the same
                          > > >metrics should be used to report "accuracy of our
                          > > >plans". I wanted the metric to measure the management
                          > > >(i.e. me and my colleagues) rather than the
                          > > >developers.
                          > > >
                          > > >I knew what a "milestones missed" metric would do to
                          > > >morale. The Senior Director was of the "thump fist and
                          > > >shout louder" school of IT management. Often I wonder
                          > > >how guys like that survive in this business.
                          > > >
                          > > >In summary: I agree entirely - we must measure the
                          > > >planning activity. I'd go further and say that it is
                          > > >more important to measure the performance of our
                          > > >managers than it is to measure the performance of our
                          > > >developers.
                          > > >
                          > > >David
                          > > >
                          > > >
                          > > >--- Ken Schwaber <ken.schwaber@v...> wrote:
                          > > >
                          > > ><HR>
                          > > ><html><body>
                          > > >
                          > > >
                          > > ><tt>
                          > > >Hal says:<BR>
                          > > >"We can begin measuring the performance of our
                          > > >planning." That's a pretty<BR>
                          > > >significant shift from measuring why people can't do
                          > > >as we plan! I really<BR>
                          > > >like the human/people orientation of your comments,
                          > > >which I believe is the<BR>
                          > > >basis of agile processes. Do what is possible, do the
                          > > >best you can ... not,<BR>
                          > > >"do what we tell you to do."<BR>
                          > > ><BR>
                          > > >I think that the more complicated and stressful life
                          > > >becoms, the more people<BR>
                          > > >want to simplify and retreat. Working through
                          > > >complexities and anomalies<BR>
                          > > >takes time and effort, and communication with the most
                          > > >complex thing<BR>
                          > > >around - other people. So the natural desire is to
                          > > >believe that the plan can<BR>
                          > > >be enforced. I think the major benefit of agile is
                          > > >that it "dumbs down" the<BR>
                          > > >whole process so we stop expecting comlicated
                          > > >mechanisms and plans to<BR>
                          > > >substitute for communication, observation, and
                          > > >collaboration.<BR>
                          > > ><BR>
                          > > >Ken<BR>
                          > > ><BR>
                          > > >
                          > > >
                          > > >__________________________________________________
                          > > >Do you Yahoo!?
                          > > >Faith Hill - Exclusive Performances, Videos & More
                          > > >http://faith.yahoo.com
                          > >
                          > >
                          > >
                          > >
                          > > Pascal Roy
                          > > Object Mentor Inc.
                          > >
                          > >
                          > > _________________________________________________________________
                          > > MSN Photos is the easiest way to share and print your photos:
                          > > http://photos.msn.com/support/worldwide.aspx
                          >


                          _________________________________________________________________
                          Broadband?�Dial-up? Get reliable MSN Internet Access.
                          http://resourcecenter.msn.com/access/plans/default.asp
                        • Mary Poppendieck
                          I agree 100% with Jeff s response to this note. I would like to add that the kind of commitments I was discussing were the team members commitment to each
                          Message 12 of 21 , Oct 16, 2002
                            I agree 100% with Jeff's response to this note.

                            I would like to add that the kind of commitments I was discussing
                            were the team members' commitment to each other to make the sprint
                            goal. In construction, the weekly planning meeting is the forum
                            where crew heads make commitments to each other. In Scrum, I would
                            say the daily Scrum serves the same purpose.

                            Mary

                            --- In scrumdevelopment@y..., "Pascal Roy" <pascal_roy_1967@h...>
                            wrote:
                            > Mary,
                            >
                            > Right, in XP we use yesterday's weather (you are more likely to
                            get done
                            > this iteration the same amount of work as the previous iteration).
                            Even so,
                            > that doesn't take care of the initial commitment problem. Very
                            often,
                            > external commitments (the ones you can't break because you'll get
                            sued or
                            > worse) were made before a credible velocity can be established. In
                            most
                            > cases, initial velocity guesstimates are optimistic and the team
                            pays for
                            > that dearly till the end of the project because they
                            have "commited" (or
                            > forced to commit?) to something they can't deliver and their
                            success is
                            > based on meeting that initial guesstimate commitment.There is this
                            idea
                            > floating around that somehow the original plan is "THE PLAN" by
                            which the
                            > success of the project should be measured against. People can't
                            get past
                            > that apparently. After being hammered for not conforming to "THE
                            PLAN" ,
                            > teams get smart: the next time they estimate, they lie and give
                            estimates so
                            > big they can be sure to make it. In theory, that could work.
                            However,
                            > because people aren't generally stupid, they usually figure out
                            they are
                            > being lied to and then trust, if there was any already, just
                            disappears
                            > creating what I would call a fun and very productive place to work
                            at... The
                            > practice of buffering estimates to me is just a symptom of the
                            fear we have
                            > of this commitment and is just another way of covering our asses.
                            It just
                            > adds another level of complexity to the problem by introducing
                            yet another
                            > variable into the mix as if there weren't enough unknowns already.
                            I don't
                            > see a win/win situation in there. It feels more like people are
                            playing not
                            > to loose...
                            >
                            > I'm really not advocating having no commitment at all (for obvious
                            business
                            > reasons but also for team motivation). I'm just trying to figure
                            out how to
                            > commit in a way that does not push team members (business,
                            customer,
                            > developers) to become at odds with each other as soon as things
                            don't go as
                            > originally planned and more critically when the hard decisions
                            need to be
                            > taken. Any ideas on how to deal with initial external commitments?
                            >
                            > Pascal Roy
                            > Object Mentor Inc.
                            >
                          Your message has been successfully submitted and would be delivered to recipients shortly.