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

R: [scrumdevelopment] Planning vs. Predicting (was Agile Development: Reforming Project Management)

Expand Messages
  • Adriano Comai
    Mary, maybe I don t understand English very well, but how can I plan without prediction (based on a different level of probability about each element of the
    Message 1 of 13 , Oct 12, 2002
    • 0 Attachment
      Mary,

      maybe I don't understand English very well, but how can I plan without
      prediction (based on a different level of probability about each element of
      the plan, of course)?

      I think the problem is only to accept that our predictions, hence our plans,
      can be wrong. That can be due, as you suggest, to the uncertainness of
      domains with high level of variations (most of domains, I fear), and also to
      our failure in specific predictions (so common in a not deterministic
      process like software development).

      And I think the answer is simply to be prepared to change our plans, every
      time we need it, to respond to change. And manage an honest and open
      relation to our customers, giving them frequent feedback and complete
      visibility, and helping them to change their assumptions and their plans
      accordingly with the change of ours.

      Adriano Comai
      www.analisi-disegno.com

      -----Messaggio originale-----
      Da: Mary Poppendieck [mailto:mary@...]
      Inviato: sabato 12 ottobre 2002 18.29
      A: scrumdevelopment@yahoogroups.com
      Oggetto: [scrumdevelopment] Planning vs. Predicting (was Agile Development:
      Reforming Project Management)


      I hear the term 'plan-based approaches' used as a pejorative, and I think we
      are using the wrong term. There is nothing wrong with planning. Planning
      goes wrong when it focuses on predicting how events will unfold and spelling
      out the responses to that prediction.

      Gantt charts can be used for envisioning, or they can be thought of as an
      exercise in predicting the future. When used create a model for thinking
      about the future, they make a lot of sense; when used as predictors of what
      the future will actually be, they fall apart.

      Endeavors which operate in uncertain domains have learned that predicting
      the future is relatively useless. Over time, mechanisms have been developed
      for uncertain domains which focus on effective ways to respond to events
      rather than predict them. This ranges from emergency response teams to
      warfare to Just-in-Time inventory movement. In every domain with variation,
      when the focus has shifted from predicting the future to preparedness to
      respond to it, results have been improved.

      The puzzle is, how do we switch the thinking patterns of people from
      prediction to preparedness? I'll bet that managers who do not know any
      other way to do IT except waterfall are quite good at responding to
      unfolding events in other areas. Do they coach little league? Do they have
      relatives in farming or who run their own businesses? Do they do work on
      the volunteer fire department? Are they hunters? Do they invest in the
      stock market? In these domains, they understand that being prepared to
      respond to events as they unfold is much more useful than predicting future
      events. We need to bring this thinking pattern from managers' 'free time'
      into their work environment.

      Mary Poppendieck
      www.poppendieck.com
    • Mary Poppendieck
      ... element of the plan, of course)? [Mary Poppendieck] I can see where the words could be confusing. What I meant by prediction is this: First we will do
      Message 2 of 13 , Oct 13, 2002
      • 0 Attachment
        > From: "Adriano Comai" <comai@...>

        > maybe I don't understand English very well, but how can I plan without
        > prediction (based on a different level of probability about each
        element > > of the plan, of course)?

        [Mary Poppendieck] I can see where the words could be confusing. What I
        meant by prediction is this: First we will do this, then that will
        happen, after which we will do this, then that will happen, and because
        of that we will do this --- you predict at the beginning of the plan
        exactly what will happen, and plan responses based on those predictions.

        What I meant by planning is this: We want to end up with this general
        accomplishment, so what different approaches might we use to get there?
        How will we know when we're there? What could go wrong? What
        preparations are needed? How do we start? How do we communicate with
        each other as things unfold? ---- you do not attempt to lay out how
        events will unfold; you are prepared and trained to deal with events as
        they happen.
      • Adriano Comai
        Mary, it seems to me that you use predict in the sense of a prophecy ( exactly what will happen ). Planning, in my opinion, needs the thoughts and the really
        Message 3 of 13 , Oct 13, 2002
        • 0 Attachment
          Mary,

          it seems to me that you use "predict" in the sense of a prophecy ("exactly
          what will happen").
          Planning, in my opinion, needs the thoughts and the really sound questions
          you refer to. But involves also the definition of milestones to reach, the
          partitioning of complex tasks, the discovering of dependencies between the
          tasks, the probabilistic setting of target dates for the completion of
          tasks.

          Sometimes, to achieve a complex goal, you have to "attempt to lay out how
          events will unfold"; even if, and I agree with you this is necessary, "you
          are prepared and trained to deal with events as they happen".

          Adriano Comai
          www.analisi-disegno.com

          > -----Messaggio originale-----
          > Da: Mary Poppendieck [mailto:mary@...]
          > Inviato: domenica 13 ottobre 2002 13.43
          > A: scrumdevelopment@yahoogroups.com
          > Oggetto: [scrumdevelopment] Re: Planning vs. Predicting (was Agile
          > Development: Reforming Project Management)
          >
          >
          >
          >
          > > From: "Adriano Comai" <comai@...>
          >
          > > maybe I don't understand English very well, but how can I plan without
          > > prediction (based on a different level of probability about each
          > element > > of the plan, of course)?
          >
          > [Mary Poppendieck] I can see where the words could be confusing. What I
          > meant by prediction is this: First we will do this, then that will
          > happen, after which we will do this, then that will happen, and because
          > of that we will do this --- you predict at the beginning of the plan
          > exactly what will happen, and plan responses based on those predictions.
          >
          > What I meant by planning is this: We want to end up with this general
          > accomplishment, so what different approaches might we use to get there?
          > How will we know when we're there? What could go wrong? What
          > preparations are needed? How do we start? How do we communicate with
          > each other as things unfold? ---- you do not attempt to lay out how
          > events will unfold; you are prepared and trained to deal with events as
          > they happen.
          >
          >
          >
          >
          > To Post a message, send it to: scrumdevelopment@...
          > To Unsubscribe, send a blank message to:
          > scrumdevelopment-unsubscribe@...
          >
          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >
          >
        • Mike Cohn
          I don t intend plan-based to be pejorative. I prefer Boehm s term plan-driven the others such as rigorous that have been suggested. It does miss the
          Message 4 of 13 , Oct 13, 2002
          • 0 Attachment

            I don’t intend ‘plan-based’ to be pejorative. I prefer Boehm’s term “plan-driven” the others such as “rigorous” that have been suggested. It does miss the point, though, that many agile projects include more planning than “plan-driven” projects.

             

            I’m not sure I get your distinction between “envisioning” and “predicting the future.” Isn’t all envisioning predicting the future? Or at least looking at different outcomes for the future?

             

            The real problems with Gantt charts when applied to software are that:

             

            1)       The Central Limit Theorem (“The sum of a number of independent samples from any distribution is approximately normally distributed.”) does not hold. For example, if I am programming 10 screens in a system and estimate how long they’ll take but then find out I’m wrong on the first it is very likely I’m wrong on all the rest—there is a systematic error here because I’ve made certain assumptions about how easy it will be to code these screens (perhaps in a language new to me). If I’m wrong on one I’m probably wrong on all the others.

            2)       Lateness is passed down a schedule; being early is not. Imagine a typical over-blown Gantt chart.  Bill and Mary are each scheduled to finish a task on Wednesday and then Mary is to write the server-side piece of Bill’s component starting Thursday. If Bill finishes early but Mary doesn’t then the benefit of Bill being early will not help the project because Mary isn’t available to capitalize on that earliness. However, if Bill is late but Mary is on time then Mary has to wait for Bill to finish—the lateness is passed down the schedule.

             

            Approaches like Critical Chain accommodate this by using late starts, and by incorporating “feeding buffers” and “project buffers”.

             

            To me that makes Gantt charts still occasionally useful. With Scrum I have used Critical Chain / TOC in the following situations:

             

            1)       To plan a sequence of sprints. I can look at “best case” (50% likely on-time completion) and “worst case” (90% likely completion) estimates and use these to size a project buffer which is added to the best cases for each sprint—that lets me pretty accurately estimate how many sprints a project will need. How else would you estimate multiple sprints? Most estimates are way too imprecise to just add up and unless you explicitly tell developers what type of estimate you want (e.g., my 50% estimate is described as “tell me how long this task will take in 50% of the cases if you did it 100 times without carrying knowledge from one time to the next and assuming that everything you need to start the task is ready when you start the task”). If you don’t make this explicit you get all sorts of combinations of estimates—some at the 50% accuracy, some 90%, some 99%, etc.

            2)       To plan the work of multiple teams each on a different sprint but working toward a common release. I found this very necessary when using Scrum to plan work among separate teams working on different products in a product line. In that case you need to plan out a sequence of sprints as in the above but you also need to coordinate work between the teams. For example, a database team may need to complete certain pieces before other teams start coding features against that database. For a variety of reasons you want to start that database change effort as late as possible (e.g., why start early if it’s not needed, might as well wait till some requirements stop changing, and you want to minimize work-in-progress). A Critical Chain approach is really the only way I know of to figure out when to start the task and how much of what I call “sprint buffer” (borrowing the Critical Chain “project buffer” term) to include.

             

            So, I think all of this is planning but I consider it inline with your (Mary’s ) comments below about the need to focus on responding to events rather than predicting them. When I look at a Critical Chain project plan I have no particular idea what a person will work on when it’s October 14th. But, I can tell about how much progress against a goal they thought they’d have and I can look at how much of a sprint or feeding buffer has been consumed and have a reasonable amount of knowledge about whether the planning I’ve done for responding to unpredictable events will let me finish a sprint/project on time. But, you’re right—that planning does not tell me what a person will work on on a given day (and it shouldn’t and can’t).

             

            --Mike

             

             

            -----Original Message-----
            From: Mary Poppendieck [mailto:mary@...]
            Sent:
            Saturday, October 12, 2002 10:29 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Planning vs. Predicting (was Agile Development: Reforming Project Management)

             

            I hear the term 'plan-based approaches' used as a pejorative, and I think we are using the wrong term.  There is nothing wrong with planning.  Planning goes wrong when it focuses on predicting how events will unfold and spelling out the responses to that prediction. 

             

            Gantt charts can be used for envisioning, or they can be thought of as an exercise in predicting the future. When used create a model for thinking about the future, they make a lot of sense; when used as predictors of what the future will actually be, they fall apart.

             

            Endeavors which operate in uncertain domains have learned that predicting the future is relatively useless.  Over time, mechanisms have been developed for uncertain domains which focus on effective ways to respond to events rather than predict them.  This ranges from emergency response teams to warfare to Just-in-Time inventory movement.  In every domain with variation, when the focus has shifted from predicting the future to preparedness to respond to it, results have been improved.

             

            The puzzle is, how do we switch the thinking patterns of people from prediction to preparedness?  I'll bet that managers who do not know any other way to do IT except waterfall are quite good at responding to unfolding events in other areas.  Do they coach little league? Do they have relatives in farming or who run their own businesses?  Do they do work on the volunteer fire department? Are they hunters?  Do they invest in the stock market?  In these domains, they understand that being prepared to respond to events as they unfold is much more useful than predicting future events.  We need to bring this thinking pattern from managers' 'free time' into their work environment.

             

            Mary Poppendieck

            www.poppendieck.com

            952-934-7998

             

            From: "Mike Cohn" <mike@...>

             

            Agreed--I don't come anywhere close to using a Gantt chart to drive

            daily activities. I do use it to try to find the critical chain in a

            project and then I use that as part of the macro-planning process. Even

            on agile projects there can be dependencies between tasks that can delay

            a project. These types of things are not hard to find with just the

            tiniest bit of upfront consideration.

             

            I also checked. My most recent Gantt chart was January 25 and outlined 6

            sprints for a project predicted to end on 7/19 (which actually shipped

            to its beta sites on 7/17). So--I hope no one thinks I'm Gantt-happy; I

            just don't write them off entirely.

             

            --Mike

             

             


             

          • Hal Macomber
            Hello folks, I m so glad I stirred up this conversation. I won t rehash my points, let me comment on a few of yours. Gantt charts are not inherently useful or
            Message 5 of 13 , Oct 13, 2002
            • 0 Attachment
              Hello folks,

              I'm so glad I stirred up this conversation. I won't rehash my
              points, let me comment on a few of yours.

              Gantt charts are not inherently useful or unuseful. They can serve
              for holding a group's attention in a conversation which would be
              extremely useful. However, I see trouble when Gantt charts are used
              for control purposes. There is rarely enough information available
              in Gantt format to allow a team of people to stay in sequence and
              handoff smoothly from one to the other. Projects get in serious
              trouble when they get out of sequence.

              My comments that were referenced were about the critical path
              method. I didn't see any debate with me among this crowd. (The
              construction folks are having a field day with this one!)

              Some of you might have figured out that I spent more time in software
              development than I have in construction. While there's almost
              nothing in common regarding the value-producing steps, the project
              planning and coordination is very similar. In the last year I've
              also worked extensively in the devense industry and in a nuclear
              power station. Again I found similarities. This is actually very
              good news. The problems that you all are setting out to address may
              also address long-standing issues elsewhere.

              Mary P. writes about listening to the word 'planning' being used in a
              pejorative sense in this forum. I hadn't noticed that. I will say
              that most places I go the way people speak of 'planning' might as
              well be pejorative. The common understanding of planning is as
              predicting: determining, telling, and knowing. As Mary stated (and
              many of you have also stated previously) this commom understanding of
              planning is bankrupt. We need a new way to think about planning.

              I ahve already floated some of my thinking about planning in
              the "Reforming Project Management" weblog. I'll share more of it
              here. First, I suggest planning is conversation not prediction. It
              is a particular kind of conversation...one that produces coherency of
              commitments through time to fulfill the promises of the project. As
              such we can start thinking of planning as 'preparing',as 'promising',
              and as 'learning'. From my vantage point, I see this as very
              consistent with what I read in this forum and around the Agile
              communities. The question I hold open is "How can we change our
              everyday practices to be consistent with this new understanding of
              planning?"

              Hal


              --- In scrumdevelopment@y..., "Mike Cohn" <mike@m...> wrote:
              > I don't intend 'plan-based' to be pejorative. I prefer Boehm's term
              > "plan-driven" the others such as "rigorous" that have been
              suggested. It
              > does miss the point, though, that many agile projects include more
              > planning than "plan-driven" projects.
              >
              >
              >
              > I'm not sure I get your distinction between "envisioning" and
              > "predicting the future." Isn't all envisioning predicting the
              future? Or
              > at least looking at different outcomes for the future?
              >
              >
              >
              > The real problems with Gantt charts when applied to software are
              that:
              >
              >
              >
              > 1) The Central Limit Theorem ("The sum of a number of
              independent
              > samples from any distribution is approximately normally
              distributed.")
              > does not hold. For example, if I am programming 10 screens in a
              system
              > and estimate how long they'll take but then find out I'm wrong on
              the
              > first it is very likely I'm wrong on all the rest-there is a
              systematic
              > error here because I've made certain assumptions about how easy it
              will
              > be to code these screens (perhaps in a language new to me). If I'm
              wrong
              > on one I'm probably wrong on all the others.
              >
              > 2) Lateness is passed down a schedule; being early is not.
              Imagine
              > a typical over-blown Gantt chart. Bill and Mary are each scheduled
              to
              > finish a task on Wednesday and then Mary is to write the server-side
              > piece of Bill's component starting Thursday. If Bill finishes early
              but
              > Mary doesn't then the benefit of Bill being early will not help the
              > project because Mary isn't available to capitalize on that
              earliness.
              > However, if Bill is late but Mary is on time then Mary has to wait
              for
              > Bill to finish-the lateness is passed down the schedule.
              >
              >
              >
              > Approaches like Critical Chain accommodate this by using late
              starts,
              > and by incorporating "feeding buffers" and "project buffers".
              >
              >
              >
              > To me that makes Gantt charts still occasionally useful. With Scrum
              I
              > have used Critical Chain / TOC in the following situations:
              >
              >
              >
              > 1) To plan a sequence of sprints. I can look at "best case"
              (50%
              > likely on-time completion) and "worst case" (90% likely completion)
              > estimates and use these to size a project buffer which is added to
              the
              > best cases for each sprint-that lets me pretty accurately estimate
              how
              > many sprints a project will need. How else would you estimate
              multiple
              > sprints? Most estimates are way too imprecise to just add up and
              unless
              > you explicitly tell developers what type of estimate you want
              (e.g., my
              > 50% estimate is described as "tell me how long this task will take
              in
              > 50% of the cases if you did it 100 times without carrying knowledge
              from
              > one time to the next and assuming that everything you need to start
              the
              > task is ready when you start the task"). If you don't make this
              explicit
              > you get all sorts of combinations of estimates-some at the 50%
              accuracy,
              > some 90%, some 99%, etc.
              >
              > 2) To plan the work of multiple teams each on a different
              sprint
              > but working toward a common release. I found this very necessary
              when
              > using Scrum to plan work among separate teams working on different
              > products in a product line. In that case you need to plan out a
              sequence
              > of sprints as in the above but you also need to coordinate work
              between
              > the teams. For example, a database team may need to complete certain
              > pieces before other teams start coding features against that
              database.
              > For a variety of reasons you want to start that database change
              effort
              > as late as possible (e.g., why start early if it's not needed,
              might as
              > well wait till some requirements stop changing, and you want to
              minimize
              > work-in-progress). A Critical Chain approach is really the only way
              I
              > know of to figure out when to start the task and how much of what I
              call
              > "sprint buffer" (borrowing the Critical Chain "project buffer"
              term) to
              > include.
              >
              >
              >
              > So, I think all of this is planning but I consider it inline with
              your
              > (Mary's ) comments below about the need to focus on responding to
              events
              > rather than predicting them. When I look at a Critical Chain project
              > plan I have no particular idea what a person will work on when it's
              > October 14th. But, I can tell about how much progress against a goal
              > they thought they'd have and I can look at how much of a sprint or
              > feeding buffer has been consumed and have a reasonable amount of
              > knowledge about whether the planning I've done for responding to
              > unpredictable events will let me finish a sprint/project on time.
              But,
              > you're right-that planning does not tell me what a person will work
              on
              > on a given day (and it shouldn't and can't).
              >
              >
              >
              > --Mike
              >
              >
              >
              >
              >
              > -----Original Message-----
              > From: Mary Poppendieck [mailto:mary@p...]
              > Sent: Saturday, October 12, 2002 10:29 AM
              > To: scrumdevelopment@y...
              > Subject: [scrumdevelopment] Planning vs. Predicting (was Agile
              > Development: Reforming Project Management)
              >
              >
              >
              > I hear the term 'plan-based approaches' used as a pejorative, and I
              > think we are using the wrong term. There is nothing wrong with
              > planning. Planning goes wrong when it focuses on predicting how
              events
              > will unfold and spelling out the responses to that prediction.
              >
              >
              >
              > Gantt charts can be used for envisioning, or they can be thought of
              as
              > an exercise in predicting the future. When used create a model for
              > thinking about the future, they make a lot of sense; when used as
              > predictors of what the future will actually be, they fall apart.
              >
              >
              >
              > Endeavors which operate in uncertain domains have learned that
              > predicting the future is relatively useless. Over time, mechanisms
              have
              > been developed for uncertain domains which focus on effective ways
              to
              > respond to events rather than predict them. This ranges from
              emergency
              > response teams to warfare to Just-in-Time inventory movement. In
              every
              > domain with variation, when the focus has shifted from predicting
              the
              > future to preparedness to respond to it, results have been improved.
              >
              >
              >
              > The puzzle is, how do we switch the thinking patterns of people from
              > prediction to preparedness? I'll bet that managers who do not know
              any
              > other way to do IT except waterfall are quite good at responding to
              > unfolding events in other areas. Do they coach little league? Do
              they
              > have relatives in farming or who run their own businesses? Do they
              do
              > work on the volunteer fire department? Are they hunters? Do they
              invest
              > in the stock market? In these domains, they understand that being
              > prepared to respond to events as they unfold is much more useful
              than
              > predicting future events. We need to bring this thinking pattern
              from
              > managers' 'free time' into their work environment.
              >
              >
              >
              > Mary Poppendieck
              >
              > www.poppendieck.com
              >
              > 952-934-7998
              >
              >
              >
              > From: "Mike Cohn" <mike@m...>
              >
              >
              >
              > Agreed--I don't come anywhere close to using a Gantt chart to drive
              >
              > daily activities. I do use it to try to find the critical chain in a
              >
              > project and then I use that as part of the macro-planning process.
              Even
              >
              > on agile projects there can be dependencies between tasks that can
              delay
              >
              > a project. These types of things are not hard to find with just the
              >
              > tiniest bit of upfront consideration.
              >
              >
              >
              > I also checked. My most recent Gantt chart was January 25 and
              outlined 6
              >
              > sprints for a project predicted to end on 7/19 (which actually
              shipped
              >
              > to its beta sites on 7/17). So--I hope no one thinks I'm Gantt-
              happy; I
              >
              > just don't write them off entirely.
              >
              >
              >
              > --Mike
            • Ron Jeffries
              ... Interesting and helpful. If I relate this to XP, I note these things: 1) We should consider redoing our plan whenever we learn something. One time is when
              Message 6 of 13 , Oct 14, 2002
              • 0 Attachment
                On Sunday, October 13, 2002, at 10:58:01 PM, Mike Cohn wrote:

                > The real problems with Gantt charts when applied to software are that:

                > 1) The Central Limit Theorem ("The sum of a number of independent
                > samples from any distribution is approximately normally distributed.")
                > does not hold. For example, if I am programming 10 screens in a system
                > and estimate how long they'll take but then find out I'm wrong on the
                > first it is very likely I'm wrong on all the rest-there is a systematic
                > error here because I've made certain assumptions about how easy it will
                > be to code these screens (perhaps in a language new to me). If I'm wrong
                > on one I'm probably wrong on all the others.

                > 2) Lateness is passed down a schedule; being early is not. Imagine
                > a typical over-blown Gantt chart. Bill and Mary are each scheduled to
                > finish a task on Wednesday and then Mary is to write the server-side
                > piece of Bill's component starting Thursday. If Bill finishes early but
                > Mary doesn't then the benefit of Bill being early will not help the
                > project because Mary isn't available to capitalize on that earliness.
                > However, if Bill is late but Mary is on time then Mary has to wait for
                > Bill to finish-the lateness is passed down the schedule.

                > Approaches like Critical Chain accommodate this by using late starts,
                > and by incorporating "feeding buffers" and "project buffers".

                Interesting and helpful. If I relate this to XP, I note these things:

                1) We should consider redoing our plan whenever we learn something.
                One time is when we learn that we were wrong about the estimate on
                those screens. If displaying the plan on a Gantt chart, we would
                resize all the screen bars.

                1) We should consider treating story estimates (Gantt bars) as
                estimates of difficulty, and measuring the teams's velocity against
                those estimates, using actual velocity to predict when things will be
                done.

                2)We should consider not assigning work, but letting people sign up
                for it. Then Mary can pair with whoever's available, reducing the
                frequency of late starts.

                Not that this resuscitates Gantt charts. But as an information
                display, they're not bad. As we have mostly agreed, the problems lie
                in how we use them and what we believe they are telling us.

                Ron Jeffries
                www.XProgramming.com
                I could be wrong, but I'm not. --Eagles, Victim of Love
              • Ken Schwaber
                Mary writes: The puzzle is, how do we switch the thinking patterns of people from prediction to preparedness? This was the heart of my issue with the XP
                Message 7 of 13 , Oct 14, 2002
                • 0 Attachment
                  Mary writes: "The puzzle is, how do we switch the thinking patterns of people from prediction to preparedness? " This was the heart of my issue with the XP plug-in for RUP. When people see Gantt charts, they start down a certain pattern of thought that tends to preclude agility. They then think that we've said that this is the write approach and they never get it.
                  Ken
                  -----Original Message-----
                  From: Mary Poppendieck [mailto:mary@...]
                  Sent: Saturday, October 12, 2002 12:29 PM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: [scrumdevelopment] Planning vs. Predicting (was Agile Development: Reforming Project Management)

                  I hear the term 'plan-based approaches' used as a pejorative, and I think we are using the wrong term.  There is nothing wrong with planning.  Planning goes wrong when it focuses on predicting how events will unfold and spelling out the responses to that prediction. 

                   

                  Gantt charts can be used for envisioning, or they can be thought of as an exercise in predicting the future. When used create a model for thinking about the future, they make a lot of sense; when used as predictors of what the future will actually be, they fall apart.

                   

                  Endeavors which operate in uncertain domains have learned that predicting the future is relatively useless.  Over time, mechanisms have been developed for uncertain domains which focus on effective ways to respond to events rather than predict them.  This ranges from emergency response teams to warfare to Just-in-Time inventory movement.  In every domain with variation, when the focus has shifted from predicting the future to preparedness to respond to it, results have been improved.

                   

                  The puzzle is, how do we switch the thinking patterns of people from prediction to preparedness?  I'll bet that managers who do not know any other way to do IT except waterfall are quite good at responding to unfolding events in other areas.  Do they coach little league? Do they have relatives in farming or who run their own businesses?  Do they do work on the volunteer fire department? Are they hunters?  Do they invest in the stock market?  In these domains, they understand that being prepared to respond to events as they unfold is much more useful than predicting future events.  We need to bring this thinking pattern from managers' 'free time' into their work environment.

                   

                  Mary Poppendieck

                  www.poppendieck.com

                  952-934-7998

                   

                  From: "Mike Cohn" <mike@...>

                   

                  Agreed--I don't come anywhere close to using a Gantt chart to drive

                  daily activities. I do use it to try to find the critical chain in a

                  project and then I use that as part of the macro-planning process. Even

                  on agile projects there can be dependencies between tasks that can delay

                  a project. These types of things are not hard to find with just the

                  tiniest bit of upfront consideration.

                   

                  I also checked. My most recent Gantt chart was January 25 and outlined 6

                  sprints for a project predicted to end on 7/19 (which actually shipped

                  to its beta sites on 7/17). So--I hope no one thinks I'm Gantt-happy; I

                  just don't write them off entirely.

                   

                  --Mike

                   

                   



                  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 the Yahoo! Terms of Service.
                • Mike Cohn
                  This is absolutely a problem associated with Gantt charts-people are so used to seeing them and thinking they can drive daily work. I *never* show a Gantt
                  Message 8 of 13 , Oct 14, 2002
                  • 0 Attachment

                    This is absolutely a problem associated with Gantt charts—people are so used to seeing them and thinking they can drive daily work. I *never* show a Gantt chart to the team working on the project. I will show it to project sponsors but always show it at a very high level just showing how sprints or major pieces fit together and for those purposes I’ll usually use Visio rather than MS Project.

                     

                    -----Original Message-----
                    From: Ken Schwaber [mailto:ken.schwaber@...]
                    Sent: Monday, October 14, 2002 8:30 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: RE: [scrumdevelopment] Planning vs. Predicting (was Agile Development: Reforming Project Management)

                     

                    Mary writes: "The puzzle is, how do we switch the thinking patterns of people from prediction to preparedness? " This was the heart of my issue with the XP plug-in for RUP. When people see Gantt charts, they start down a certain pattern of thought that tends to preclude agility. They then think that we've said that this is the write approach and they never get it.

                    Ken

                    -----Original Message-----
                    From: Mary Poppendieck [mailto:mary@...]
                    Sent: Saturday, October 12, 2002 12:29 PM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: [scrumdevelopment] Planning vs. Predicting (was Agile Development: Reforming Project Management)

                    I hear the term 'plan-based approaches' used as a pejorative, and I think we are using the wrong term.  There is nothing wrong with planning.  Planning goes wrong when it focuses on predicting how events will unfold and spelling out the responses to that prediction. 

                     

                    Gantt charts can be used for envisioning, or they can be thought of as an exercise in predicting the future. When used create a model for thinking about the future, they make a lot of sense; when used as predictors of what the future will actually be, they fall apart.

                     

                    Endeavors which operate in uncertain domains have learned that predicting the future is relatively useless.  Over time, mechanisms have been developed for uncertain domains which focus on effective ways to respond to events rather than predict them.  This ranges from emergency response teams to warfare to Just-in-Time inventory movement.  In every domain with variation, when the focus has shifted from predicting the future to preparedness to respond to it, results have been improved.

                     

                    The puzzle is, how do we switch the thinking patterns of people from prediction to preparedness?  I'll bet that managers who do not know any other way to do IT except waterfall are quite good at responding to unfolding events in other areas.  Do they coach little league? Do they have relatives in farming or who run their own businesses?  Do they do work on the volunteer fire department? Are they hunters?  Do they invest in the stock market?  In these domains, they understand that being prepared to respond to events as they unfold is much more useful than predicting future events.  We need to bring this thinking pattern from managers' 'free time' into their work environment.

                     

                    Mary Poppendieck

                    www.poppendieck.com

                    952-934-7998

                     

                    From: "Mike Cohn" <mike@...>

                     

                    Agreed--I don't come anywhere close to using a Gantt chart to drive

                    daily activities. I do use it to try to find the critical chain in a

                    project and then I use that as part of the macro-planning process. Even

                    on agile projects there can be dependencies between tasks that can delay

                    a project. These types of things are not hard to find with just the

                    tiniest bit of upfront consideration.

                     

                    I also checked. My most recent Gantt chart was January 25 and outlined 6

                    sprints for a project predicted to end on 7/19 (which actually shipped

                    to its beta sites on 7/17). So--I hope no one thinks I'm Gantt-happy; I

                    just don't write them off entirely.

                     

                    --Mike

                     

                     



                    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 the Yahoo! Terms of Service.



                    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 the Yahoo! Terms of Service.
                  • Mike Cohn
                    Absolutely true on all fronts, Ron. I currently use a defect tracking system called TestTrack for tracking activities in a sprint. We use XP stories where
                    Message 9 of 13 , Oct 14, 2002
                    • 0 Attachment
                      Absolutely true on all fronts, Ron.

                      I currently use a defect tracking system called TestTrack for tracking
                      activities in a sprint. We use XP stories where practical but when a
                      sprint starts we break those stories into one or more tasks that end up
                      in TestTrack. Programmers update estimates every day or two--this lets
                      us create sprint burndown charts showing how much we think is left at
                      any point. Sometimes a programmer will decide a couple of tasks are
                      irrelevant and he'll just close them out and enter very different tasks
                      with new estimates--all still targeted at the same "sprint goal" of
                      course. In this way we are re-estimating this project daily. I don't do
                      much with the info daily because there's too much noise when viewed
                      daily--I'm more interested in week to week trends.

                      No work is ever assigned rather programmers just pull it off the "sprint
                      backlog" (the work committed for this sprint). Ideally they do this
                      during the morning Daily Scrum meeting but realistically they do it
                      whenever they need more work.

                      Another benefit of not assigning work is that it avoids what Goldratt
                      called the "Student Syndrome" which is when you estimate a task to take
                      3 days so you start it with exactly 3 days until it's due (e.g., the way
                      most college students handled their assignments).

                      --Mike

                      -----Original Message-----
                      From: Ron Jeffries [mailto:ronjeffries@...]
                      Sent: Monday, October 14, 2002 2:52 AM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: Re: [scrumdevelopment] Planning vs. Predicting (was Agile
                      Development: Reforming Project Management)

                      > Interesting and helpful. If I relate this to XP, I note these things:
                      >
                      > 1) We should consider redoing our plan whenever we learn something.
                      > One time is when we learn that we were wrong about the estimate on
                      > those screens. If displaying the plan on a Gantt chart, we would
                      > resize all the screen bars.
                      >
                      > 1) We should consider treating story estimates (Gantt bars) as
                      > estimates of difficulty, and measuring the teams's velocity against
                      > those estimates, using actual velocity to predict when things will be
                      > done.
                      >
                      > 2)We should consider not assigning work, but letting people sign up
                      > for it. Then Mary can pair with whoever's available, reducing the
                      > frequency of late starts.
                      >
                      > Not that this resuscitates Gantt charts. But as an information
                      > display, they're not bad. As we have mostly agreed, the problems lie
                      > in how we use them and what we believe they are telling us.
                      >
                      > Ron Jeffries
                      > www.XProgramming.com
                      > I could be wrong, but I'm not. --Eagles, Victim of Love
                    • Ron Jeffries
                      ... Yes, I share this concern. Two approaches, at opposite poles, are 1. Stand over on what we see as the right side and talk to the people who wander over;
                      Message 10 of 13 , Oct 14, 2002
                      • 0 Attachment
                        On Monday, October 14, 2002, at 10:30:07 AM, Ken Schwaber wrote:

                        > Mary writes: "The puzzle is, how do we switch the thinking patterns of
                        > people from prediction to preparedness? " This was the heart of my issue
                        > with the XP plug-in for RUP. When people see Gantt charts, they start down a
                        > certain pattern of thought that tends to preclude agility. They then think
                        > that we've said that this is the [right] approach and they never get it.

                        Yes, I share this concern. Two approaches, at opposite poles, are

                        1. Stand over on what we see as the "right" side and talk to the
                        people who wander over;

                        2. Offer people on what we see as the "wrong" side ways to experience
                        things that will show them better ways of doing, and better ways of
                        thinking.

                        The latter is what the RUP plug-in, for example, is trying to do.

                        Ron Jeffries
                        www.XProgramming.com
                        The central "e" in "Jeffries" is silent ... and invisible.
                      • Jeff Sutherland
                        The purpose of the first SCRUM was not to measure managers or developers. I asked the CEO of Easel if he had ever seen a plan that he liked, had confidence in,
                        Message 11 of 13 , Oct 16, 2002
                        • 0 Attachment
                          The purpose of the first SCRUM was not to measure managers or
                          developers. I asked the CEO of Easel if he had ever seen a plan that
                          he liked, had confidence in, or was met on time in the software
                          business. He said, "NO!" I said if he could see real software running
                          once a month that could be shown to users, would that give him more
                          confidence that we were going to have a product that we could sell in
                          a reasonable amount of time.

                          When he said, "Yes," I said he would have to give up all management
                          controls on the SCRUM and let it self manage. Product marketing would
                          build a product backlog, we would select high priority items for a
                          Sprint. There would be no management interference during the Sprint.
                          At the end of the Sprint, if management didn't like the software or
                          the progress, they could change everything at Sprint boundaries.

                          He agreed. The rest is history.

                          So I think the only thing that should be measured is the size of the
                          Sprint backlog, the rate of burndown of the burndown chart, and the
                          value of the demonstrable working software at the end of the Sprint.

                          Anything more generates more work for people who are not writing code
                          and builds beaurocracy that gets in the way of building better
                          software faster.

                          That said, my Board needs a product roadmap and dates of delivery. We
                          prepare them as targets. Sometimes GANT charts are use to depict
                          these targets. They have no concrete reality until a burndown chart
                          is visible. We then report off the burndown charts showing clearly
                          where the customers and/or product marketing stuffed more
                          functionality into the release, where items were deferred to drive
                          toward a date, or where development stumbled on a technical problem.

                          The microdata that builds the burndown chart on each piece of
                          functionality with estimates and dates give more information than any
                          other scheme I have seen on team or individual output at the micro
                          level. We do not use these data as measures for managers as it would
                          distort estimates and corrupt the data.

                          Jeff Sutherland

                          --- In scrumdevelopment@y..., "Mary Poppendieck" <mary@p...> wrote:
                          > I hear the term 'plan-based approaches' used as a pejorative, and I
                          > think we are using the wrong term. There is nothing wrong with
                          > planning. Planning goes wrong when it focuses on predicting how
                          events
                          > will unfold and spelling out the responses to that prediction.
                        • Mike Cohn
                          I totally agree. Your approach below is perfect, Jeff. Any more detailed measurement of the process starts to alter the process. Once CEOs and Boards start to
                          Message 12 of 13 , Oct 16, 2002
                          • 0 Attachment
                            I totally agree. Your approach below is perfect, Jeff. Any more detailed
                            measurement of the process starts to alter the process.

                            Once CEOs and Boards start to see how Scrum and the believable reporting
                            that comes out of it they become its biggest fans.

                            --Mike

                            -----Original Message-----
                            From: Jeff Sutherland [mailto:jeff.sutherland@...]
                            Sent: Wednesday, October 16, 2002 9:08 AM
                            To: scrumdevelopment@yahoogroups.com
                            Subject: [scrumdevelopment] Re: Planning vs. Predicting (was Agile
                            Development: Reforming Project Management)

                            The purpose of the first SCRUM was not to measure managers or
                            developers. I asked the CEO of Easel if he had ever seen a plan that
                            he liked, had confidence in, or was met on time in the software
                            business. He said, "NO!" I said if he could see real software running
                            once a month that could be shown to users, would that give him more
                            confidence that we were going to have a product that we could sell in
                            a reasonable amount of time.

                            When he said, "Yes," I said he would have to give up all management
                            controls on the SCRUM and let it self manage. Product marketing would
                            build a product backlog, we would select high priority items for a
                            Sprint. There would be no management interference during the Sprint.
                            At the end of the Sprint, if management didn't like the software or
                            the progress, they could change everything at Sprint boundaries.

                            He agreed. The rest is history.

                            So I think the only thing that should be measured is the size of the
                            Sprint backlog, the rate of burndown of the burndown chart, and the
                            value of the demonstrable working software at the end of the Sprint.

                            Anything more generates more work for people who are not writing code
                            and builds beaurocracy that gets in the way of building better
                            software faster.

                            That said, my Board needs a product roadmap and dates of delivery. We
                            prepare them as targets. Sometimes GANT charts are use to depict
                            these targets. They have no concrete reality until a burndown chart
                            is visible. We then report off the burndown charts showing clearly
                            where the customers and/or product marketing stuffed more
                            functionality into the release, where items were deferred to drive
                            toward a date, or where development stumbled on a technical problem.

                            The microdata that builds the burndown chart on each piece of
                            functionality with estimates and dates give more information than any
                            other scheme I have seen on team or individual output at the micro
                            level. We do not use these data as measures for managers as it would
                            distort estimates and corrupt the data.

                            Jeff Sutherland

                            --- In scrumdevelopment@y..., "Mary Poppendieck" <mary@p...> wrote:
                            > I hear the term 'plan-based approaches' used as a pejorative, and I
                            > think we are using the wrong term. There is nothing wrong with
                            > planning. Planning goes wrong when it focuses on predicting how
                            events
                            > will unfold and spelling out the responses to that prediction.




                            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/
                          Your message has been successfully submitted and would be delivered to recipients shortly.