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

Re: [XP] Re: Release Planning based on Velocity

Expand Messages
  • 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 1 of 18 , Jul 1, 2012
      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 2 of 18 , Jul 1, 2012
        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 3 of 18 , Jul 1, 2012
          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 4 of 18 , Jul 2, 2012
            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 5 of 18 , Jul 2, 2012
              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 6 of 18 , Jul 2, 2012
                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 7 of 18 , Jul 2, 2012
                  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 8 of 18 , Jul 3, 2012
                    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.