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

Release Planning based on Velocity

Expand Messages
  • Ajithesh Hegde
    Hi, A team s velocity might vary if: i) the iteration length varies, ii) the team size/team composition varies If a team is to ramp up progressively in number
    Message 1 of 18 , Jun 30, 2012
    • 0 Attachment
      Hi,

      A team's velocity might vary if:
      i) the iteration length varies,
      ii) the team size/team composition varies

      If a team is to ramp up progressively in number (and later progressively
      ramp down) over iterations, how to do the release planning based on
      velocity? The same question when the iteration length is not kept constant
      over iterations.

      Rgds
      Ajithesh


      [Non-text portions of this message have been removed]
    • RonJeffries
      Hello Ajithesh, Your question explores an interesting area, tracking velocity and using it for prediction. I often wish that the idea of velocity had never
      Message 2 of 18 , Jun 30, 2012
      • 0 Attachment
        Hello Ajithesh,

        Your question explores an interesting area, tracking velocity and using it for prediction. I often wish that the idea of velocity had never been imported into Scrum from XP, and I often wish we had not invented it or made such a big deal of it in XP.

        That said, the same issues will arise even if all one does is use the old idea of the Product Burndown, so I suppose it's not fair to blame velocity for all the misconceptions that arise.

        However it came about, and I blame myself, an unhealthy focus on velocity is often a big impediment to doing Scrum well. It is important that velocity be consistent. Increasing it is not usually the most important thing a Scrum Team can do.

        Anyway ...

        On Jun 30, 2012, at 3:02 AM, Ajithesh Hegde wrote:

        > A team's velocity might vary if:
        > i) the iteration length varies,
        > ii) the team size/team composition varies
        iii) the story size changes;
        iv) the stories involve a domain the team is more, or less, familiar with;
        v) the code becomes more clean, or becomes less clean;
        vi) the team does more, or less, testing;
        vii) the team does more, or less, refactoring;
        viii) the team undergoes more, or fewer interruptions;
        ix) the team injects more, or fewer, defects;
        x) ... i can think of more ... can you?
        >
        > If a team is to ramp up progressively in number (and later progressively
        > ramp down) over iterations, how to do the release planning based on
        > velocity? The same question when the iteration length is not kept constant
        > over iterations.


        Do you mean that the team is supposed to ramp up velocity, and ramp it back down? If so, why would they be supposed to do that?
        Or do you mean that they in fact do that without being asked? What is causing the ramping?
        Or do you mean something else?

        Basically, predictability is only possible in the presence of consistent velocity. Consistent velocity is only possible if all of the items in the list above are controlled rather tightly. In the case of a software project, the best known ways to do that are thorough testing, mostly automated, continuous design improvement, and a number of other well-known if rarely done technical practices.

        Furthermore, the desire for predictability often indicates that the Scrum process is being used in an ineffective fashion. It usually carries the idea of "when is the team going to be done with all this". Scum requires the Product Owner, not the team, to be responsible for maximizing the value of the project by the due date. This is accomplished by the PO managing the value of what the team does rather than trying, somehow, to manage the volume of what they do.

        Ron Jeffries
        www.XProgramming.com
        I'm not bad, I'm just drawn that way. -- Jessica Rabbit



        [Non-text portions of this message have been removed]
      • Ajithesh Hegde
        Thanks Ron Jeffries. By team ramping up in number progressively , I meant that the team size is ramped up progressively. For eg., the team size is 5 this
        Message 3 of 18 , Jun 30, 2012
        • 0 Attachment
          Thanks Ron Jeffries.

          By "team ramping up in number progressively", I meant that the team size
          is ramped up progressively. For eg., the team size is 5 this month, 7 next
          month and 9 finally. Same way, the gradual decrease in team's size towards
          the end of the project. I did not mean anything about increase/decrease of
          velocity here. Sorry if I was unclear on this earlier.

          Rgds
          Ajithesh

          On Sat, Jun 30, 2012 at 5:25 PM, RonJeffries <ronjeffries@...> wrote:

          > **
          >
          >
          > Hello Ajithesh,
          >
          > Your question explores an interesting area, tracking velocity and using it
          > for prediction. I often wish that the idea of velocity had never been
          > imported into Scrum from XP, and I often wish we had not invented it or
          > made such a big deal of it in XP.
          >
          > That said, the same issues will arise even if all one does is use the old
          > idea of the Product Burndown, so I suppose it's not fair to blame velocity
          > for all the misconceptions that arise.
          >
          > However it came about, and I blame myself, an unhealthy focus on velocity
          > is often a big impediment to doing Scrum well. It is important that
          > velocity be consistent. Increasing it is not usually the most important
          > thing a Scrum Team can do.
          >
          > Anyway ...
          >
          >
          > On Jun 30, 2012, at 3:02 AM, Ajithesh Hegde wrote:
          >
          > > A team's velocity might vary if:
          > > i) the iteration length varies,
          > > ii) the team size/team composition varies
          > iii) the story size changes;
          > iv) the stories involve a domain the team is more, or less, familiar with;
          > v) the code becomes more clean, or becomes less clean;
          > vi) the team does more, or less, testing;
          > vii) the team does more, or less, refactoring;
          > viii) the team undergoes more, or fewer interruptions;
          > ix) the team injects more, or fewer, defects;
          > x) ... i can think of more ... can you?
          >
          > >
          > > If a team is to ramp up progressively in number (and later progressively
          > > ramp down) over iterations, how to do the release planning based on
          > > velocity? The same question when the iteration length is not kept
          > constant
          > > over iterations.
          >
          > Do you mean that the team is supposed to ramp up velocity, and ramp it
          > back down? If so, why would they be supposed to do that?
          > Or do you mean that they in fact do that without being asked? What is
          > causing the ramping?
          > Or do you mean something else?
          >
          > Basically, predictability is only possible in the presence of consistent
          > velocity. Consistent velocity is only possible if all of the items in the
          > list above are controlled rather tightly. In the case of a software
          > project, the best known ways to do that are thorough testing, mostly
          > automated, continuous design improvement, and a number of other well-known
          > if rarely done technical practices.
          >
          > Furthermore, the desire for predictability often indicates that the Scrum
          > process is being used in an ineffective fashion. It usually carries the
          > idea of "when is the team going to be done with all this". Scum requires
          > the Product Owner, not the team, to be responsible for maximizing the value
          > of the project by the due date. This is accomplished by the PO managing the
          > value of what the team does rather than trying, somehow, to manage the
          > volume of what they do.
          >
          > Ron Jeffries
          > www.XProgramming.com
          > I'm not bad, I'm just drawn that way. -- Jessica Rabbit
          >
          > [Non-text portions of this message have been removed]
          >
          >
          >


          [Non-text portions of this message have been removed]
        • RonJeffries
          Hi Ajithesh, ... I understand. Probably my misreading of that part of your question in light of the earlier question about velocity. I would wonder why this is
          Message 4 of 18 , Jun 30, 2012
          • 0 Attachment
            Hi Ajithesh,

            On Jun 30, 2012, at 12:38 PM, Ajithesh Hegde wrote:

            > By "team ramping up in number progressively", I meant that the team size
            > is ramped up progressively. For eg., the team size is 5 this month, 7 next
            > month and 9 finally. Same way, the gradual decrease in team's size towards
            > the end of the project. I did not mean anything about increase/decrease of
            > velocity here. Sorry if I was unclear on this earlier.


            I understand. Probably my misreading of that part of your question in light of the earlier question about velocity.

            I would wonder why this is going to be done without something going on inside the project that indicates it is needed.

            There is no way to predict what will happen. Adding people will not make a project go faster and can slow it down. Removing people can speed it up.

            Ron Jeffries
            www.XProgramming.com
            I'm really pissed off by what people are passing off as "agile" these days.
            You may have a red car, but that does not make it a Ferrari.
            -- Steve Hayes



            [Non-text portions of this message have been removed]
          • Steven Gordon
            ... Come on! Occasionally, adding people *can* make a project go faster. It would depend on the particular people and the state of the project. Also, it make
            Message 5 of 18 , Jun 30, 2012
            • 0 Attachment
              On Sat, Jun 30, 2012 at 10:05 AM, RonJeffries <ronjeffries@...> wrote:

              > **
              >
              >
              > Hi Ajithesh,
              > I understand. Probably my misreading of that part of your question in
              > light of the earlier question about velocity.
              >
              > I would wonder why this is going to be done without something going on
              > inside the project that indicates it is needed.
              >
              > There is no way to predict what will happen. Adding people will not make a
              > project go faster and can slow it down. Removing people can speed it up.
              >

              Come on!

              Occasionally, adding people *can* make a project go faster. It would
              depend on the particular people and the state of the project. Also, it
              make take some time before you would see the effects.

              I would just say "the effect on velocity of adding, removing or replacing
              people on a project is not easily predicted and quite often will result in
              the opposite of the naively expected effect".


              >
              > Ron Jeffries
              > www.XProgramming.com
              > I'm really pissed off by what people are passing off as "agile" these days.
              > You may have a red car, but that does not make it a Ferrari.
              > -- Steve Hayes
              >
              >
              > [Non-text portions of this message have been removed]
              >
              >
              >


              [Non-text portions of this message have been removed]
            • RonJeffries
              Yes, I meant to say will not necessarily . R ... Ron Jeffries www.XProgramming.com You never know what is enough unless you know what is more than enough. --
              Message 6 of 18 , Jun 30, 2012
              • 0 Attachment
                Yes, I meant to say "will not necessarily".
                R
                On Jun 30, 2012, at 1:28 PM, Steven Gordon wrote:

                > Occasionally, adding people *can* make a project go faster. It would
                > depend on the particular people and the state of the project. Also, it
                > make take some time before you would see the effects.


                Ron Jeffries
                www.XProgramming.com
                You never know what is enough unless you know what is more than enough. -- William Blake



                [Non-text portions of this message have been removed]
              • George Dinwiddie
                Ajithesh, ... It s been my experience (and a lot of others have written on the subject, also) that a team whose membership is frequently changed is a work
                Message 7 of 18 , Jun 30, 2012
                • 0 Attachment
                  Ajithesh,

                  On 6/30/12 3:02 AM, Ajithesh Hegde wrote:
                  > Hi,
                  >
                  > A team's velocity might vary if:
                  > i) the iteration length varies,
                  > ii) the team size/team composition varies
                  >
                  > If a team is to ramp up progressively in number (and later progressively
                  > ramp down) over iterations, how to do the release planning based on
                  > velocity? The same question when the iteration length is not kept constant
                  > over iterations.

                  It's been my experience (and a lot of others have written on the
                  subject, also) that a team whose membership is frequently changed is a
                  work group, not a team. It doesn't gain the synergies of a true team.
                  Therefore, changing the team size to chase what you perceive is the
                  needed velocity has, for the most part, the effect of making the team
                  less effective. It makes it harder to accomplish your goals.

                  A constant iteration length allows a team to develop a rhythm, and to
                  concentrate on the goal rather while the cycle of work becomes an
                  ingrained habit. Here, again, constantly changing the iteration length
                  will keep a team focused on how to get the work done rather than on
                  getting the work done.

                  Why would you want to vary team size, team composition, and iteration
                  length? Isn't the work hard enough as it is?

                  - George

                  --
                  ----------------------------------------------------------------------
                  * George Dinwiddie * http://blog.gdinwiddie.com
                  Software Development http://www.idiacomputing.com
                  Consultant and Coach http://www.agilemaryland.org
                  ----------------------------------------------------------------------
                • JeffGrigg
                  Yes! Exactly! ..., an *unhealthy* focus on velocity ... is a bad thing. As a responsible practitioner, I am continuously striving to improve the velocity /
                  Message 8 of 18 , Jul 1, 2012
                  • 0 Attachment
                    Yes! Exactly!
                    "..., an *unhealthy* focus on velocity ..."
                    is a bad thing.

                    As a responsible practitioner, I am continuously striving to improve the velocity / effectiveness / productivity of myself, my team, and the business people I serve. But I find it hard to *IMAGINE* that I would stand up in front of the team and say "Team, we need to increase our velocity." Why? Well, it would put an excessive focus in the wrong place. We must focus on doing our job well. Mistakes cost time and money. Quality, far exceeding customer expectations, is the key to high productivity. We need to focus on doing our jobs well and effectively. A *RESULT* of that will be increased velocity.

                    Focusing directly on velocity rewards short-term thinking. It encourages people to take shortcuts to boost productivity/velocity NOW at the expense of costs (and productivity/velocity dropping) tomorrow. Bad idea. An excessive focus on velocity will reduce it.


                    --- RonJeffries <ronjeffries@...> wrote:
                    > ... I often wish that the idea of velocity had never been
                    > imported into Scrum from XP, and I often wish we had not
                    > invented it or made such a big deal of it in XP.
                    > ...
                    > However it came about, and I blame myself, an unhealthy
                    > focus on velocity is often a big impediment to doing Scrum
                    > well. ...
                  • JeffGrigg
                    ... Don t do that. ... Strive to minimize that. But vacations and such are OK. If velocity is proportional to the number of people (or regular hours), then
                    Message 9 of 18 , Jul 1, 2012
                    • 0 Attachment
                      > --- Ajithesh Hegde wrote:
                      >> A team's velocity might vary if:
                      >> i) the iteration length varies,

                      Don't do that.

                      >> ii) the team size/team composition varies

                      Strive to minimize that.

                      But vacations and such are OK. If velocity is proportional to the number of people (or regular hours), then you're doing good.

                      --- RonJeffries <ronjeffries@...> wrote:
                      > iii) the story size changes;

                      Shouldn't happen. When it does, it's often a sign of excessively large stories, which need to be broken down.

                      > iv) the stories involve a domain the team is more, or less, familiar with;

                      True. Try not to stress over it.

                      > v) the code becomes more clean, or becomes less clean;
                      > vi) the team does more, or less, testing;
                      > vii) the team does more, or less, refactoring;

                      Don't accept that these things are varying. We should do as much as possible, as you know. (Or at least as much as reasonable.)

                      > viii) the team undergoes more, or fewer interruptions;

                      And that's a problem that can and should be addressed.

                      > ix) the team injects more, or fewer, defects;

                      Sometimes it's time for a good night's sleep!

                      > x) ... i can think of more ... can you?

                      Yes, of course.

                      Quite often the code base does not have consistent quality throughout. So velocity will vary based on working being more in the "good" parts or more in the "bad" parts of the code. Over time, we strive to make all of the code good. But within more reasonable planning horizons, we can expect investment to be needed, from time to time, to bring old work "up to code."
                    • MarvinToll.com
                      Ron, hmmm... Truthfully, I ve pretty much ignored the velocity nuances that have sparked debate for many years - not that veloctiy doesn t have value. I ve
                      Message 10 of 18 , Jul 1, 2012
                      • 0 Attachment
                        Ron,

                        hmmm... Truthfully, I've pretty much ignored the 'velocity' nuances that have sparked debate for many years - not that veloctiy doesn't have value.

                        I've also pretty much ignored Scrum. (My wife accuses me of selective hearing - but that is another topic.)

                        However, I was in a Scrum class (as a participant joining a new Scrum team) this past week and was a bit unnerved by the strong emphasis on velocity... and more specifically by the context that was established... that management needs predictability so 'velocity' is (ultimately) the answer to THAT problem.

                        Call it a Scrum smell... which led your statement to resonate sharply:

                        "an unhealthy focus on velocity is often a big impediment to doing Scrum well."

                        So I'm trying to come to terms with why I was intuitively bothered and your strong statement.

                        Said another way, I'm wondering if I was bothered for the same reason(s) you made your statement?

                        So... with your indulgence... let me combine my emerging thoughts with your elbatoration and see if we are (however unlikely) on the same page:

                        1. That determining velocity is an enabler - not an end in itself.
                        2. That velocity enables workload planning - not predicting.
                        3. That extending a workload planning tool into a predicting tool can damage the effectiveness of the planning tool.
                        4. That the type of predictability leadership (aka management) needs is related to amount of value... not volume of work... so there is no reason to damage the effectiveness of velocity as a tool for planning.

                        _Marvin
                        http://PatternEnabled.com


                        --- In extremeprogramming@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
                        >
                        > Hello Ajithesh,
                        >
                        > Your question explores an interesting area, tracking velocity and using it for prediction. I often wish that the idea of velocity had never been imported into Scrum from XP, and I often wish we had not invented it or made such a big deal of it in XP.
                        >
                        > That said, the same issues will arise even if all one does is use the old idea of the Product Burndown, so I suppose it's not fair to blame velocity for all the misconceptions that arise.
                        >
                        > However it came about, and I blame myself, an unhealthy focus on velocity is often a big impediment to doing Scrum well. It is important that velocity be consistent. Increasing it is not usually the most important thing a Scrum Team can do.
                        >
                        > Anyway ...
                        >
                        > On Jun 30, 2012, at 3:02 AM, Ajithesh Hegde wrote:
                        >
                        > > A team's velocity might vary if:
                        > > i) the iteration length varies,
                        > > ii) the team size/team composition varies
                        > iii) the story size changes;
                        > iv) the stories involve a domain the team is more, or less, familiar with;
                        > v) the code becomes more clean, or becomes less clean;
                        > vi) the team does more, or less, testing;
                        > vii) the team does more, or less, refactoring;
                        > viii) the team undergoes more, or fewer interruptions;
                        > ix) the team injects more, or fewer, defects;
                        > x) ... i can think of more ... can you?
                        > >
                        > > If a team is to ramp up progressively in number (and later progressively
                        > > ramp down) over iterations, how to do the release planning based on
                        > > velocity? The same question when the iteration length is not kept constant
                        > > over iterations.
                        >
                        >
                        > Do you mean that the team is supposed to ramp up velocity, and ramp it back down? If so, why would they be supposed to do that?
                        > Or do you mean that they in fact do that without being asked? What is causing the ramping?
                        > Or do you mean something else?
                        >
                        > Basically, predictability is only possible in the presence of consistent velocity. Consistent velocity is only possible if all of the items in the list above are controlled rather tightly. In the case of a software project, the best known ways to do that are thorough testing, mostly automated, continuous design improvement, and a number of other well-known if rarely done technical practices.
                        >
                        > Furthermore, the desire for predictability often indicates that the Scrum process is being used in an ineffective fashion. It usually carries the idea of "when is the team going to be done with all this". Scum requires the Product Owner, not the team, to be responsible for maximizing the value of the project by the due date. This is accomplished by the PO managing the value of what the team does rather than trying, somehow, to manage the volume of what they do.
                        >
                        > Ron Jeffries
                        > www.XProgramming.com
                        > I'm not bad, I'm just drawn that way. -- Jessica Rabbit
                      • RonJeffries
                        Oddly enough, yes R ... Ron Jeffries www.XProgramming.com There s no word for accountability in Finnish. Accountability is something that is left when
                        Message 11 of 18 , Jul 1, 2012
                        • 0 Attachment
                          Oddly enough, yes
                          R
                          On Jul 1, 2012, at 9:54 AM, MarvinToll.com wrote:

                          > So... with your indulgence... let me combine my emerging thoughts with your elbatoration and see if we are (however unlikely) on the same page:
                          >
                          > 1. That determining velocity is an enabler - not an end in itself.
                          > 2. That velocity enables workload planning - not predicting.
                          > 3. That extending a workload planning tool into a predicting tool can damage the effectiveness of the planning tool.
                          > 4. That the type of predictability leadership (aka management) needs is related to amount of value... not volume of work... so there is no reason to damage the effectiveness of velocity as a tool for planning.


                          Ron Jeffries
                          www.XProgramming.com
                          There's no word for accountability in Finnish.
                          Accountability is something that is left when responsibility has been subtracted.
                          --Pasi Sahlberg



                          [Non-text portions of this message have been removed]
                        • Jonathan Harley
                          Hey Ron, I ve always viewed velocity as a fact rather than a goal, and use it to try to have a sense of what the team has been capable of, capacity-wise rather
                          Message 12 of 18 , Jul 1, 2012
                          • 0 Attachment
                            Hey Ron,

                            I've always viewed velocity as a fact rather than a goal, and use it to try
                            to have a sense of what the team has been capable of, capacity-wise rather
                            than a promise of delivery.

                            Is your regret about use of velocity in Scrum and XP that it takes so long
                            for management to understand the nuances thereby causing undue heartburn
                            all around? Or is there some other deep seated reason that I've missed
                            along the way? (My fault for not reading all the posts regularly?)

                            Thanks - Jon

                            On Sun, Jul 1, 2012 at 11:04 AM, RonJeffries <ronjeffries@...> wrote:

                            > **
                            >
                            >
                            > Oddly enough, yes
                            > R
                            >
                            > On Jul 1, 2012, at 9:54 AM, MarvinToll.com wrote:
                            >
                            > > So... with your indulgence... let me combine my emerging thoughts with
                            > your elbatoration and see if we are (however unlikely) on the same page:
                            > >
                            > > 1. That determining velocity is an enabler - not an end in itself.
                            > > 2. That velocity enables workload planning - not predicting.
                            > > 3. That extending a workload planning tool into a predicting tool can
                            > damage the effectiveness of the planning tool.
                            > > 4. That the type of predictability leadership (aka management) needs is
                            > related to amount of value... not volume of work... so there is no reason
                            > to damage the effectiveness of velocity as a tool for planning.
                            >
                            > Ron Jeffries
                            > www.XProgramming.com
                            > There's no word for accountability in Finnish.
                            > Accountability is something that is left when responsibility has been
                            > subtracted.
                            > --Pasi Sahlberg
                            >
                            >
                            > [Non-text portions of this message have been removed]
                            >
                            >
                            >


                            [Non-text portions of this message have been removed]
                          • RonJeffries
                            ... Yes. It was originally used as yesterday s weather to help the team decide how much work to take on in the next iteration. Then we began using it in a
                            Message 13 of 18 , Jul 1, 2012
                            • 0 Attachment
                              On Jul 1, 2012, at 11:25 AM, Jonathan Harley wrote:

                              > I've always viewed velocity as a fact rather than a goal, and use it to try
                              > to have a sense of what the team has been capable of, capacity-wise rather
                              > than a promise of delivery.

                              Yes. It was originally used as "yesterday's weather" to help the team decide how much work to take on in the next iteration.

                              Then we began using it in a healthy way -- yes, that is actually possible -- to give an indication of progress, to get a sense of whether we would be done on time. I don't remember now why we felt the way we did.
                              >
                              > Is your regret about use of velocity in Scrum and XP that it takes so long
                              > for management to understand the nuances thereby causing undue heartburn
                              > all around? Or is there some other deep seated reason that I've missed
                              > along the way? (My fault for not reading all the posts regularly?)


                              In my opinion, "predicting" is not good thinking. Steering, by selecting high value things to do, is important. Having a potentially shippable "product increment" all the time, is important.

                              Generally -- almost always -- management's focus on velocity is a focus on "doing more". This is -- almost always -- an indication that they are not focused on having an always-ready increment and always putting the most important new features into it. They are managing the cost end of the equation, not the value end.

                              That way lies pain, mediocrity, and bad software.

                              Ron Jeffries
                              www.XProgramming.com
                              I know we always like to say it'll be easier to do it now than it
                              will be to do it later. Not likely. I plan to be smarter later than
                              I am now, so I think it'll be just as easy later, maybe even easier.
                              Why pay now when we can pay later?



                              [Non-text portions of this message have been removed]
                            • Ajithesh Hegde
                              Hi, My clarifications on the two varying parameters: 1. Gradual increase in the team size in the beginning and gradual decrease in the team size towards the
                              Message 14 of 18 , Jul 2, 2012
                              • 0 Attachment
                                Hi,

                                My clarifications on the two varying parameters:

                                1. Gradual increase in the team size in the beginning and gradual decrease
                                in the team size towards the end of the project. Why should this happen?:

                                Answer: I have seen such a practice in many of the projects as a
                                tradition. In the beginning of a project, the core team is formed with a
                                fewer members (generally the senior members). The initial ground work
                                such as high level requirements and architecture starts happening.

                                With the high level details reasonably worked out, the team size is
                                increased with more members (generally relatively junior members).

                                A size down happens when the project is nearing completion on similar
                                grounds. As the project is well on the track and most of the project is
                                done by now, more senior members are pulled out gradually and are put on
                                newer projects.

                                2. Iteration length. Why is this varied?
                                I have seen the teams taking such a decision as part of their sprint
                                retrospectives to experiment with different iteration lengths to find out
                                which is the more optimal iteration length for their work. Sometimes,
                                based on the theme that they are taking for the next iteration, I have seen
                                the teams dynamically changing the iteration length as well.

                                Rgds
                                Ajithesh


                                On Sun, Jul 1, 2012 at 9:06 PM, RonJeffries <ronjeffries@...> wrote:

                                > **
                                >
                                >
                                >
                                > On Jul 1, 2012, at 11:25 AM, Jonathan Harley wrote:
                                >
                                > > I've always viewed velocity as a fact rather than a goal, and use it to
                                > try
                                > > to have a sense of what the team has been capable of, capacity-wise
                                > rather
                                > > than a promise of delivery.
                                >
                                > Yes. It was originally used as "yesterday's weather" to help the team
                                > decide how much work to take on in the next iteration.
                                >
                                > Then we began using it in a healthy way -- yes, that is actually possible
                                > -- to give an indication of progress, to get a sense of whether we would be
                                > done on time. I don't remember now why we felt the way we did.
                                >
                                > >
                                > > Is your regret about use of velocity in Scrum and XP that it takes so
                                > long
                                > > for management to understand the nuances thereby causing undue heartburn
                                > > all around? Or is there some other deep seated reason that I've missed
                                > > along the way? (My fault for not reading all the posts regularly?)
                                >
                                > In my opinion, "predicting" is not good thinking. Steering, by selecting
                                > high value things to do, is important. Having a potentially shippable
                                > "product increment" all the time, is important.
                                >
                                > Generally -- almost always -- management's focus on velocity is a focus on
                                > "doing more". This is -- almost always -- an indication that they are not
                                > focused on having an always-ready increment and always putting the most
                                > important new features into it. They are managing the cost end of the
                                > equation, not the value end.
                                >
                                > That way lies pain, mediocrity, and bad software.
                                >
                                > Ron Jeffries
                                > www.XProgramming.com
                                > I know we always like to say it'll be easier to do it now than it
                                > will be to do it later. Not likely. I plan to be smarter later than
                                > I am now, so I think it'll be just as easy later, maybe even easier.
                                > Why pay now when we can pay later?
                                >
                                >
                                > [Non-text portions of this message have been removed]
                                >
                                >
                                >


                                [Non-text portions of this message have been removed]
                              • George Dinwiddie
                                Ajithesh, ... That s a tradition from a phased, plan-driven project lifecycle. It s a tradition that treats software development as an endeavor of a group of
                                Message 15 of 18 , Jul 2, 2012
                                • 0 Attachment
                                  Ajithesh,

                                  On 7/2/12 4:55 AM, Ajithesh Hegde wrote:
                                  > Hi,
                                  >
                                  > My clarifications on the two varying parameters:
                                  >
                                  > 1. Gradual increase in the team size in the beginning and gradual decrease
                                  > in the team size towards the end of the project. Why should this happen?:
                                  >
                                  > Answer: I have seen such a practice in many of the projects as a
                                  > tradition. In the beginning of a project, the core team is formed with a
                                  > fewer members (generally the senior members). The initial ground work
                                  > such as high level requirements and architecture starts happening.

                                  That's a tradition from a phased, plan-driven project lifecycle. It's a
                                  tradition that treats software development as an endeavor of a group of
                                  individuals rather than as a team activity.

                                  > With the high level details reasonably worked out, the team size is
                                  > increased with more members (generally relatively junior members).
                                  >
                                  > A size down happens when the project is nearing completion on similar
                                  > grounds. As the project is well on the track and most of the project is
                                  > done by now, more senior members are pulled out gradually and are put on
                                  > newer projects.

                                  That's always a good idea, so that the more senior members don't get
                                  tarred by the project failure during final integration and test. ;-)
                                  Seriously, I've seen that play out on a number of occasions in just such
                                  a fashion. It's one of the frequent plot lines of a serial project
                                  lifecycle, and one of the problems that an adaptive, team-driven
                                  lifecycle is intended to avoid.

                                  > 2. Iteration length. Why is this varied?
                                  > I have seen the teams taking such a decision as part of their sprint
                                  > retrospectives to experiment with different iteration lengths to find out
                                  > which is the more optimal iteration length for their work. Sometimes,
                                  > based on the theme that they are taking for the next iteration, I have seen
                                  > the teams dynamically changing the iteration length as well.

                                  Why do these teams dynamically change their iteration length?

                                  - George

                                  --
                                  ----------------------------------------------------------------------
                                  * George Dinwiddie * http://blog.gdinwiddie.com
                                  Software Development http://www.idiacomputing.com
                                  Consultant and Coach http://www.agilemaryland.org
                                  ----------------------------------------------------------------------
                                • Tim Ottinger
                                  Goodhart s law applied to software productivity. :-) Roughly, If you lean on a gauge, it quits providing useful information.   Tim Ottinger
                                  Message 16 of 18 , Jul 2, 2012
                                  • 0 Attachment
                                    Goodhart's law applied to software productivity. :-)

                                    Roughly, "If you lean on a gauge, it quits providing useful information."

                                     
                                    Tim Ottinger
                                    http://agileinaflash.blogspot.com/
                                    http://agileotter.blogspot.com/
                                  • Curtis Cooley
                                    Sorry for the top post, using my phone :-( Others have hinted but I ve not seen anyone say, building projects is easy, building teams is hard. On the off
                                    Message 17 of 18 , Jul 2, 2012
                                    • 0 Attachment
                                      Sorry for the top post, using my phone :-(

                                      Others have hinted but I've not seen anyone say, building projects is easy,
                                      building teams is hard. On the off chance you manage to build a high
                                      performance team, you already have plans to tear of down.

                                      I suggest you don't do that.
                                      On Jul 2, 2012 1:55 AM, "Ajithesh Hegde" <ajithesh.gh@...> wrote:


                                      [Non-text portions of this message have been removed]
                                    • MarvinToll.com
                                      Is this akin to the notion that: If you push a metaphor too hard the wheels kind of fall off. [Richard Greene]
                                      Message 18 of 18 , Jul 3, 2012
                                      • 0 Attachment
                                        Is this akin to the notion that:

                                        "If you push a metaphor too hard the wheels kind of fall off." [Richard Greene]

                                        --- In extremeprogramming@yahoogroups.com, Tim Ottinger <linux_tim@...> wrote:
                                        >
                                        > Goodhart's law applied to software productivity. :-)
                                        >
                                        > Roughly, "If you lean on a gauge, it quits providing useful information."
                                        >
                                        >  
                                        > Tim Ottinger
                                        > http://agileinaflash.blogspot.com/
                                        > http://agileotter.blogspot.com/
                                        >
                                      Your message has been successfully submitted and would be delivered to recipients shortly.