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

Re: [scrumdevelopment] How to increase velocity

Expand Messages
  • Bret Wortman
    I think the illusion is being able to directly manipulate the velocity. It s like my car s mileage. I can t make it more fuel-efficient directly, but I can
    Message 1 of 30 , Nov 30, 2012
    View Source
    • 0 Attachment
      I think the illusion is being able to directly manipulate the velocity. It's like my car's mileage. I can't make it more fuel-efficient directly, but I can change the way I drive, which will have an effect on my MPG.

      There's no "velocity" dial in scrum, but there are lots of other dials which can effect velocity indirectly (and unpredictably).


      On Thu, Nov 29, 2012 at 4:04 PM, RonJeffries <ronjeffries@...> wrote:
       

      Cass,


      On Nov 28, 2012, at 8:46 AM, Cass Dalton <cassdalton73@...> wrote:

      Trying to increase the velocity means that you've fallen into the illusion of control mind trap.  You can't change velocity.  It is inherent in the team and their ability to work the stories.  As long as the team is estimating stories honestly and consistently and the team makeup does not change, the true team velocity will be effectively a constant. 

      What if they learn something new? What if someone has a creative idea?

      Ron Jeffries
      I have two cats, and a big house full of cat stuff. 
      The cats fight and divide up the house, messing up their own lives. 
      Nice work cats. 
      Meow.




      --
      Bret Wortman
      The Damascus Group
      Fairfax, VA

    • Cass Dalton
      Ron, Do are you suggesting that said creative idea will increase the teams velocity? That sounds like a major process improvement or something similar. There
      Message 2 of 30 , Nov 30, 2012
      View Source
      • 0 Attachment

        Ron,
        Do are you suggesting that said creative idea will increase the teams velocity?  That sounds like a major process improvement or something similar.  There are exceptions to every rule and good teams will always be improving themselves.  But those types of improvements are not induced by outside control, which was the context of the question.  If you have managers asking "how can we increase velocity", they are not thinking "how can the team improve", they're thinking "what resources do we need to throw at the problem to meet our deadline".  Suggesting that that type of control is real is dangerous.  Team improvement will happen, and it can even be accelerated by a good scrum master.  It can not be accelerated by the type of manager that asks the second question.  So in the context of the question as I heard it, there is no method of increasing velocity.

        On Nov 30, 2012 6:42 AM, "Bret Wortman" <bret.wortman@...> wrote:
         

        I think the illusion is being able to directly manipulate the velocity. It's like my car's mileage. I can't make it more fuel-efficient directly, but I can change the way I drive, which will have an effect on my MPG.


        There's no "velocity" dial in scrum, but there are lots of other dials which can effect velocity indirectly (and unpredictably).


        On Thu, Nov 29, 2012 at 4:04 PM, RonJeffries <ronjeffries@...> wrote:
         

        Cass,


        On Nov 28, 2012, at 8:46 AM, Cass Dalton <cassdalton73@...> wrote:

        Trying to increase the velocity means that you've fallen into the illusion of control mind trap.  You can't change velocity.  It is inherent in the team and their ability to work the stories.  As long as the team is estimating stories honestly and consistently and the team makeup does not change, the true team velocity will be effectively a constant. 

        What if they learn something new? What if someone has a creative idea?

        Ron Jeffries
        I have two cats, and a big house full of cat stuff. 
        The cats fight and divide up the house, messing up their own lives. 
        Nice work cats. 
        Meow.




        --
        Bret Wortman
        The Damascus Group
        Fairfax, VA

      • Charles Bradley - Professional Scrum Trai
        I ve observed something that supports Cass s theory somewhat.  In the case of learning something new, what I ve seen a couple of times is that the team has
        Message 3 of 30 , Nov 30, 2012
        View Source
        • 0 Attachment
          I've observed something that supports Cass's theory somewhat.  In the case of learning something new, what I've seen a couple of times is that the team has say four very similar stories, but they are using a new technology.  They will size the stories something like 8, 3, 3, 2, stating that the first story will take longer because they'll have to get up to speed on the new tech.  Then, the remaining stories should come faster.  Is the right thing from a user story perspective to size them all like a 5?  In that case, you would see an increase in velocity.

          OTOH, I've certainly seen cases where velocity has improved and even skyrocketed when some large impediment is removed.

          I have mixed feelings here -- while velocity can sometimes indicate increases in productivity, it's also pretty worthless IMO for indicating that at other times. 

          I mean, Ron, in your "count the stories" pattern, you indicate stories should be sized to be about 2-3 days in size.  If a team doubles their productivity, then they can theoretically get twice as much done in 2-3 days --- so the amount of work in their stories will increase, but their velocity will not increase.

          I return back to what I've learned from most folks on this list -- velocity is a planning tool, and trying to use it for any other purpose is very suspect.
           
          -------
          Charles Bradley
          http://www.ScrumCrazy.com




          From: RonJeffries <ronjeffries@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Thursday, November 29, 2012 2:04 PM
          Subject: Re: [scrumdevelopment] How to increase velocity



          Cass,

          On Nov 28, 2012, at 8:46 AM, Cass Dalton <cassdalton73@...> wrote:

          Trying to increase the velocity means that you've fallen into the illusion of control mind trap.  You can't change velocity.  It is inherent in the team and their ability to work the stories.  As long as the team is estimating stories honestly and consistently and the team makeup does not change, the true team velocity will be effectively a constant. 

          What if they learn something new? What if someone has a creative idea?

          Ron Jeffries
          I have two cats, and a big house full of cat stuff. 
          The cats fight and divide up the house, messing up their own lives. 
          Nice work cats. 
          Meow.





        • m1ke_pearce
          Cass, I don t agree with this at all. If a team is inspecting and adapting, constantly improving their practises and themselves, then their velocity will go
          Message 4 of 30 , Nov 30, 2012
          View Source
          • 0 Attachment
            Cass,

            I don't agree with this at all.

            If a team is inspecting and adapting, constantly improving their practises and themselves, then their velocity will go up. Not indefinitely of course, but until a team reaches high performance, which my experience tells me takes a long time, their velocity will gradually increase.

            So, instead of using the analogy of a generator, use one of a NASCAR. Until the driver hits his groove, making the turns at the right speed, the right angle in and out, his speed will continue to increase.

            Cheers,

            Mike Pearce
            http://blog.mikepearce.net



            --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@...> wrote:
            >
            > Trying to increase the velocity means that you've fallen into the illusion
            > of control mind trap. You can't change velocity. It is inherent in the
            > team and their ability to work the stories. As long as the team is
            > estimating stories honestly and consistently and the team makeup does not
            > change, the true team velocity will be effectively a constant. The team
            > can inflate the estimates, thus inflating the velocity, but that's just
            > smoke and mirrors. But this is one of the major benefits of Scrum from a
            > manager's perspective: Scrum gives you visibility into the team's ability
            > to deliver. Good managers know that a good team will deliver what it can
            > when it can. Scrum gives a rough measure of that performance in the
            > velocity metric, so good managers know that a good team's velocity can't be
            > increased. Velocity is a read-only parameter. It's like saying my
            > generator's maximum output is 10 kilowatts, but all my gadgets together
            > require 12 KW, how do I increase my generator's output?. You don't. You
            > can do things like drive the generator's gas motor harder for a little
            > while (i.e. overtime), but you will incur maintenance costs quickly if that
            > is sustained for any period of time. You can try to run all the gadgets,
            > but you will degrade all of your electronics with low quality line power
            > (i.e. buggy and half baked features). You can buy a second generator, but
            > how you connect the two generators may incur power loss if it's not done
            > right. So the best thing is to realize that you won't be able to power all
            > your gadgets. Once you make that realization, life becomes much simpler.
            > It is these decisions that make managers great.
            >
            >
            > On Wed, Nov 28, 2012 at 6:05 AM, Anand Mahadevan <anand_kasi@...>wrote:
            >
            > > **
            > >
            > >
            > > There is no magic to increase the velocity, not sure why they are very
            > > much interested in increasing the velocity rather than getting a shippable
            > > product.
            > >
            > > But if the management and your boss is only interested in increasing the
            > > velocity then ask your teams to estimate all PBI's as (even the smaller
            > > ones) Large & XL & XXL and your management would automatically see
            > > increased velocity from your teams. * if they are only interested in
            > > Velocity then we can not stop them from fooling them*
            > >
            > > Thanks,
            > > Anand
            > >
            > > <http://anand4agile.blogspot.in/>
            > > ------------------------------
            > > *From:* brian_bofu <brian_bofu@...>
            > > *To:* scrumdevelopment@yahoogroups.com
            > > *Sent:* Wednesday, 28 November 2012 3:08 PM
            > > *Subject:* [scrumdevelopment] How to increase velocity
            > >
            > >
            > > Your boss wants your team to deliver certain functionality by a certain
            > > date (deadline), but your velocity is unable to achieve that. What
            > > options/suggestions do you have for your management who really want this to
            > > get done? More people? Overtime? What else to increase the velocity?
            > >
            > >
            > >
            > >
            > >
            >
          • Adam Sroka
            Going faster is not always a good thing. Although, sometimes it is. Pretending to go faster produces far more distress than value.
            Message 5 of 30 , Dec 1, 2012
            View Source
            • 0 Attachment
              Going faster is not always a good thing. Although, sometimes it is.

              Pretending to go faster produces far more distress than value. 

              On Fri, Nov 30, 2012 at 11:10 PM, m1ke_pearce <mike@...> wrote:
               

              Cass,

              I don't agree with this at all.

              If a team is inspecting and adapting, constantly improving their practises and themselves, then their velocity will go up. Not indefinitely of course, but until a team reaches high performance, which my experience tells me takes a long time, their velocity will gradually increase.

              So, instead of using the analogy of a generator, use one of a NASCAR. Until the driver hits his groove, making the turns at the right speed, the right angle in and out, his speed will continue to increase.

              Cheers,

              Mike Pearce
              http://blog.mikepearce.net



              --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@...> wrote:
              >
              > Trying to increase the velocity means that you've fallen into the illusion
              > of control mind trap. You can't change velocity. It is inherent in the
              > team and their ability to work the stories. As long as the team is
              > estimating stories honestly and consistently and the team makeup does not
              > change, the true team velocity will be effectively a constant. The team
              > can inflate the estimates, thus inflating the velocity, but that's just
              > smoke and mirrors. But this is one of the major benefits of Scrum from a
              > manager's perspective: Scrum gives you visibility into the team's ability
              > to deliver. Good managers know that a good team will deliver what it can
              > when it can. Scrum gives a rough measure of that performance in the
              > velocity metric, so good managers know that a good team's velocity can't be
              > increased. Velocity is a read-only parameter. It's like saying my
              > generator's maximum output is 10 kilowatts, but all my gadgets together
              > require 12 KW, how do I increase my generator's output?. You don't. You
              > can do things like drive the generator's gas motor harder for a little
              > while (i.e. overtime), but you will incur maintenance costs quickly if that
              > is sustained for any period of time. You can try to run all the gadgets,
              > but you will degrade all of your electronics with low quality line power
              > (i.e. buggy and half baked features). You can buy a second generator, but
              > how you connect the two generators may incur power loss if it's not done
              > right. So the best thing is to realize that you won't be able to power all
              > your gadgets. Once you make that realization, life becomes much simpler.
              > It is these decisions that make managers great.
              >
              >
              > On Wed, Nov 28, 2012 at 6:05 AM, Anand Mahadevan <anand_kasi@...>wrote:
              >
              > > **

              > >
              > >
              > > There is no magic to increase the velocity, not sure why they are very
              > > much interested in increasing the velocity rather than getting a shippable
              > > product.
              > >
              > > But if the management and your boss is only interested in increasing the
              > > velocity then ask your teams to estimate all PBI's as (even the smaller
              > > ones) Large & XL & XXL and your management would automatically see
              > > increased velocity from your teams. * if they are only interested in
              > > Velocity then we can not stop them from fooling them*
              > >
              > > Thanks,
              > > Anand
              > >
              > > <http://anand4agile.blogspot.in/>
              > > ------------------------------
              > > *From:* brian_bofu <brian_bofu@...>
              > > *To:* scrumdevelopment@yahoogroups.com
              > > *Sent:* Wednesday, 28 November 2012 3:08 PM
              > > *Subject:* [scrumdevelopment] How to increase velocity

              > >
              > >
              > > Your boss wants your team to deliver certain functionality by a certain
              > > date (deadline), but your velocity is unable to achieve that. What
              > > options/suggestions do you have for your management who really want this to
              > > get done? More people? Overtime? What else to increase the velocity?
              > >
              > >
              > >
              > >
              > >
              >


            • Cass Dalton
              Several people have made similar responses, and I still assert that, in the context of management asking how to increase velocity, it is dangerous to consider
              Message 6 of 30 , Dec 1, 2012
              View Source
              • 0 Attachment

                Several people have made similar responses, and I still assert that, in the context of management asking how to increase velocity, it is dangerous to consider velocity something you can control.  Yes, the generator's power output will steadily increase as it warms up, but in the context of management control, my analogy holds that the generator has some basic maximum power output for a given temperature that the owner can't change.  The OP didn't ask if velocity can ever increase.  They asked what they should tell management that is asking to increase velocity based on some artificial constraint.  Any response other than "remove as many impediments as you can and decrease scope/features" is headed for failure of some sort.

                On Dec 1, 2012 2:12 AM, "m1ke_pearce" <mike@...> wrote:
                 

                Cass,

                I don't agree with this at all.

                If a team is inspecting and adapting, constantly improving their practises and themselves, then their velocity will go up. Not indefinitely of course, but until a team reaches high performance, which my experience tells me takes a long time, their velocity will gradually increase.

                So, instead of using the analogy of a generator, use one of a NASCAR. Until the driver hits his groove, making the turns at the right speed, the right angle in and out, his speed will continue to increase.

                Cheers,

                Mike Pearce
                http://blog.mikepearce.net

                --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@...> wrote:
                >
                > Trying to increase the velocity means that you've fallen into the illusion
                > of control mind trap. You can't change velocity. It is inherent in the
                > team and their ability to work the stories. As long as the team is
                > estimating stories honestly and consistently and the team makeup does not
                > change, the true team velocity will be effectively a constant. The team
                > can inflate the estimates, thus inflating the velocity, but that's just
                > smoke and mirrors. But this is one of the major benefits of Scrum from a
                > manager's perspective: Scrum gives you visibility into the team's ability
                > to deliver. Good managers know that a good team will deliver what it can
                > when it can. Scrum gives a rough measure of that performance in the
                > velocity metric, so good managers know that a good team's velocity can't be
                > increased. Velocity is a read-only parameter. It's like saying my
                > generator's maximum output is 10 kilowatts, but all my gadgets together
                > require 12 KW, how do I increase my generator's output?. You don't. You
                > can do things like drive the generator's gas motor harder for a little
                > while (i.e. overtime), but you will incur maintenance costs quickly if that
                > is sustained for any period of time. You can try to run all the gadgets,
                > but you will degrade all of your electronics with low quality line power
                > (i.e. buggy and half baked features). You can buy a second generator, but
                > how you connect the two generators may incur power loss if it's not done
                > right. So the best thing is to realize that you won't be able to power all
                > your gadgets. Once you make that realization, life becomes much simpler.
                > It is these decisions that make managers great.
                >
                >
                > On Wed, Nov 28, 2012 at 6:05 AM, Anand Mahadevan <anand_kasi@...>wrote:
                >
                > > **
                > >
                > >
                > > There is no magic to increase the velocity, not sure why they are very
                > > much interested in increasing the velocity rather than getting a shippable
                > > product.
                > >
                > > But if the management and your boss is only interested in increasing the
                > > velocity then ask your teams to estimate all PBI's as (even the smaller
                > > ones) Large & XL & XXL and your management would automatically see
                > > increased velocity from your teams. * if they are only interested in
                > > Velocity then we can not stop them from fooling them*
                > >
                > > Thanks,
                > > Anand
                > >
                > > <http://anand4agile.blogspot.in/>
                > > ------------------------------
                > > *From:* brian_bofu <brian_bofu@...>
                > > *To:* scrumdevelopment@yahoogroups.com
                > > *Sent:* Wednesday, 28 November 2012 3:08 PM
                > > *Subject:* [scrumdevelopment] How to increase velocity
                > >
                > >
                > > Your boss wants your team to deliver certain functionality by a certain
                > > date (deadline), but your velocity is unable to achieve that. What
                > > options/suggestions do you have for your management who really want this to
                > > get done? More people? Overtime? What else to increase the velocity?
                > >
                > >
                > >
                > >
                > >
                >

              • Charles Bradley - Professional Scrum Trai
                Good post, Cass. ...   I think this may be the heart of the problem.  The more I think about it, the more I think velocity should *almost never* be reported
                Message 7 of 30 , Dec 1, 2012
                View Source
                • 0 Attachment
                  Good post, Cass.

                  > ...what they should tell management that is asking to increase velocity
                   
                  I think this may be the heart of the problem.  The more I think about it, the more I think velocity should *almost never* be reported beyond the Scrum team.  I'd rather the PO report to the wider organization with value, "dates and dollars". 

                  Dates = Projected Release Dates based on what we know at this instant (Iterate towards better date accuracy)
                  *Dollars = Projected cost per feature, per sprint, per release, etc(Iterate towards better cost accuracy)
                  Value = Projected value per feature, per release, per bug(negative business value) etc  (With some "in production" validation of value -- iterate towards better projections/validations of value )

                  * Caveat:  In my view, there is very little value to the org to focus *heavily* on cost if you don't at least try to project and measure(validate) value.  Today, it seems like people focus on cost/value (as a percentage of effort) 90%/10%, when they should be focusing on cost/value as 10%/90%.  It'll probably take a few more MySpaces, Vistas, and Zunes to drive that point home.

                  -------
                  Charles Bradley
                  http://www.ScrumCrazy.com




                  From: Cass Dalton <cassdalton73@...>
                  To: scrumdevelopment@yahoogroups.com
                  Sent: Saturday, December 1, 2012 8:45 AM
                  Subject: Re: [scrumdevelopment] Re: How to increase velocity



                  Several people have made similar responses, and I still assert that, in the context of management asking how to increase velocity, it is dangerous to consider velocity something you can control.  Yes, the generator's power output will steadily increase as it warms up, but in the context of management control, my analogy holds that the generator has some basic maximum power output for a given temperature that the owner can't change.  The OP didn't ask if velocity can ever increase.  They asked what they should tell management that is asking to increase velocity based on some artificial constraint.  Any response other than "remove as many impediments as you can and decrease scope/features" is headed for failure of some sort.
                  On Dec 1, 2012 2:12 AM, "m1ke_pearce" <mike@...> wrote:
                   
                  Cass,

                  I don't agree with this at all.

                  If a team is inspecting and adapting, constantly improving their practises and themselves, then their velocity will go up. Not indefinitely of course, but until a team reaches high performance, which my experience tells me takes a long time, their velocity will gradually increase.

                  So, instead of using the analogy of a generator, use one of a NASCAR. Until the driver hits his groove, making the turns at the right speed, the right angle in and out, his speed will continue to increase.

                  Cheers,

                  Mike Pearce
                  http://blog.mikepearce.net

                  --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@...> wrote:
                  >
                  > Trying to increase the velocity means that you've fallen into the illusion
                  > of control mind trap. You can't change velocity. It is inherent in the
                  > team and their ability to work the stories. As long as the team is
                  > estimating stories honestly and consistently and the team makeup does not
                  > change, the true team velocity will be effectively a constant. The team
                  > can inflate the estimates, thus inflating the velocity, but that's just
                  > smoke and mirrors. But this is one of the major benefits of Scrum from a
                  > manager's perspective: Scrum gives you visibility into the team's ability
                  > to deliver. Good managers know that a good team will deliver what it can
                  > when it can. Scrum gives a rough measure of that performance in the
                  > velocity metric, so good managers know that a good team's velocity can't be
                  > increased. Velocity is a read-only parameter. It's like saying my
                  > generator's maximum output is 10 kilowatts, but all my gadgets together
                  > require 12 KW, how do I increase my generator's output?. You don't. You
                  > can do things like drive the generator's gas motor harder for a little
                  > while (i.e. overtime), but you will incur maintenance costs quickly if that
                  > is sustained for any period of time. You can try to run all the gadgets,
                  > but you will degrade all of your electronics with low quality line power
                  > (i.e. buggy and half baked features). You can buy a second generator, but
                  > how you connect the two generators may incur power loss if it's not done
                  > right. So the best thing is to realize that you won't be able to power all
                  > your gadgets. Once you make that realization, life becomes much simpler.
                  > It is these decisions that make managers great.
                  >
                  >
                  > On Wed, Nov 28, 2012 at 6:05 AM, Anand Mahadevan <anand_kasi@...>wrote:
                  >
                  > > **
                  > >
                  > >
                  > > There is no magic to increase the velocity, not sure why they are very
                  > > much interested in increasing the velocity rather than getting a shippable
                  > > product.
                  > >
                  > > But if the management and your boss is only interested in increasing the
                  > > velocity then ask your teams to estimate all PBI's as (even the smaller
                  > > ones) Large & XL & XXL and your management would automatically see
                  > > increased velocity from your teams. * if they are only interested in
                  > > Velocity then we can not stop them from fooling them*
                  > >
                  > > Thanks,
                  > > Anand
                  > >
                  > > <http://anand4agile.blogspot.in/>
                  > > ------------------------------
                  > > *From:* brian_bofu <brian_bofu@...>
                  > > *To:* scrumdevelopment@yahoogroups.com
                  > > *Sent:* Wednesday, 28 November 2012 3:08 PM
                  > > *Subject:* [scrumdevelopment] How to increase velocity
                  > >
                  > >
                  > > Your boss wants your team to deliver certain functionality by a certain
                  > > date (deadline), but your velocity is unable to achieve that. What
                  > > options/suggestions do you have for your management who really want this to
                  > > get done? More people? Overtime? What else to increase the velocity?
                  > >
                  > >
                  > >
                  > >
                  > >
                  >





                • Account
                  I ve been hanging back and watching this really interesting discussion evolve and thought I d jump in. My advice would be to have the Scrum Team and management
                  Message 8 of 30 , Dec 2, 2012
                  View Source
                  • 0 Attachment
                    I've been hanging back and watching this really interesting discussion evolve and thought I'd jump in.

                    My advice would be to have the Scrum Team and management get together to discuss this business problem. Why do we need to have this certain functionality (fixed scope) delivered by a certain date (fixed time)? If we assume management has noble intentions, perhaps they are trying to hit a market window, and the "certain functionality" is the minimally marketable features.

                    Once we understand the business objectives and the goal, then we can inspect and adapt to the situation. What's missing is the visibility into management's reasoning.

                    The point here is to be proactive, not reactive. Agile is about the "Art of the Possible.". For example: we figure out various implementation scenarios and we can explain the trade-offs with management. We can delivery sooner with fewer features to get early feedback, we can deliver all the desired features, but not go as deep with their functionality, etc.

                    If management is arbitrarily asking the team to meet the goal (fixed date/fixed scope), then find out what's behind it. Do they want to set a challenging goal to help the team improve, has an Executive made a promise to a customer to close business, etc. Does management not understand how/why agile works and they need education. There can be many good explanations.

                    Once you find out what is going on, it will change your mindset (paradigm shift) and many alternatives to solve the problem will emerge.

                    Regards,
                    Richard Knaster



                    Original question:
                    Your boss wants your team to deliver certain functionality by a certain date (deadline), but your velocity is unable to achieve that. What options/suggestions do you have for your management who really want this to get done? More people? Overtime? What else to increase the velocity?
                  • akoelewijnk
                    Velocity is an indication of what a team is capable of (within its current environment). You could approach this like a sports team trying to improve its
                    Message 9 of 30 , Dec 2, 2012
                    View Source
                    • 0 Attachment
                      Velocity is an indication of what a team is capable of (within its current environment). You could approach this like a sports team trying to improve its ranking:
                      1) try to improve the effectiveness of the team members by getting in the right trainers * coaches, and training them to do a better at their job. I think any programmer/analyst/tester/... can become better with the right training, just like athletes are always training to improve.
                      2) improve the team by replacing team members by more effective people. Sometimes people are very good, by not the right match for the team, sometimes there're just not good enough.
                    • Markus Gaertner
                      There is a third option to improve the velocity within that analogy, that is improve the team working together. Your first point seems to be directed at
                      Message 10 of 30 , Dec 3, 2012
                      View Source
                      • 0 Attachment
                        There is a third option to improve the velocity within that analogy,
                        that is improve the team working together. Your first point seems to
                        be directed at individual skills, your second one on the team
                        constellation. I experienced an out-performing team once we settled
                        the interpersonal conflicts that were lurking in our team. Once we
                        settled these, we were able to deliver more than we planned initially,
                        and it took us two failed sprints to realize we had to work on our
                        team issue.

                        Best
                        Markus

                        On Mon, Dec 3, 2012 at 12:00 AM, akoelewijnk <yahoo@...> wrote:
                        > Velocity is an indication of what a team is capable of (within its current environment). You could approach this like a sports team trying to improve its ranking:
                        > 1) try to improve the effectiveness of the team members by getting in the right trainers * coaches, and training them to do a better at their job. I think any programmer/analyst/tester/... can become better with the right training, just like athletes are always training to improve.
                        > 2) improve the team by replacing team members by more effective people. Sometimes people are very good, by not the right match for the team, sometimes there're just not good enough.
                        >
                        >
                        >
                        > ------------------------------------
                        >
                        > To Post a message, send it to: scrumdevelopment@...
                        > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                        >
                        >
                        >



                        --
                        Dipl.-Inform. Markus Gärtner
                        Author of ATDD by Example - A Practical Guide to Acceptance
                        Test-Driven Development
                        http://www.shino.de/blog
                        http://www.mgaertne.de
                        http://www.it-agile.de
                        Twitter: @mgaertne
                      • Cass Dalton
                        Well said
                        Message 11 of 30 , Dec 3, 2012
                        View Source
                        • 0 Attachment
                          Well said


                          On Sun, Dec 2, 2012 at 4:44 PM, Account <richardknaster@...> wrote:
                           

                          I've been hanging back and watching this really interesting discussion evolve and thought I'd jump in.

                          My advice would be to have the Scrum Team and management get together to discuss this business problem. Why do we need to have this certain functionality (fixed scope) delivered by a certain date (fixed time)? If we assume management has noble intentions, perhaps they are trying to hit a market window, and the "certain functionality" is the minimally marketable features.

                          Once we understand the business objectives and the goal, then we can inspect and adapt to the situation. What's missing is the visibility into management's reasoning.

                          The point here is to be proactive, not reactive. Agile is about the "Art of the Possible.". For example: we figure out various implementation scenarios and we can explain the trade-offs with management. We can delivery sooner with fewer features to get early feedback, we can deliver all the desired features, but not go as deep with their functionality, etc.

                          If management is arbitrarily asking the team to meet the goal (fixed date/fixed scope), then find out what's behind it. Do they want to set a challenging goal to help the team improve, has an Executive made a promise to a customer to close business, etc. Does management not understand how/why agile works and they need education. There can be many good explanations.

                          Once you find out what is going on, it will change your mindset (paradigm shift) and many alternatives to solve the problem will emerge.

                          Regards,
                          Richard Knaster

                          Original question:
                          Your boss wants your team to deliver certain functionality by a certain date (deadline), but your velocity is unable to achieve that. What options/suggestions do you have for your management who really want this to get done? More people? Overtime? What else to increase the velocity?


                        • Michael James
                          Richard, thank you for that dose of sanity. Our preoccupation with microefficiency is a habit from the industrial era when success depended on building more
                          Message 12 of 30 , Dec 3, 2012
                          View Source
                          • 0 Attachment
                            Richard, thank you for that dose of sanity.

                            Our preoccupation with microefficiency is a habit from the industrial era when success depended on building more Model-T Fords, more B-17 bombers, more houses on the hillside made of ticky tacky.  There were even people like Frank Gilbreth doing time and motion studies in this quest to increase production quantity.

                            But today success at knowledge work has more to do with being able to steer.  This means connecting the people implementing the product with the people who need the product, splitting the requirements into smaller portions, doing a great job at the top priority ones, keeping the feedback loop alive, and creating a *learning organization*.  The pursuit of speed at any cost is likely a symptom of one-way communication and broken feedback loops.

                            --mj


                            On Dec 2, 2012, at 1:44 PM, "Account" <richardknaster@...> wrote:

                             

                            I've been hanging back and watching this really interesting discussion evolve and thought I'd jump in.

                            My advice would be to have the Scrum Team and management get together to discuss this business problem. Why do we need to have this certain functionality (fixed scope) delivered by a certain date (fixed time)? If we assume management has noble intentions, perhaps they are trying to hit a market window, and the "certain functionality" is the minimally marketable features.

                            Once we understand the business objectives and the goal, then we can inspect and adapt to the situation. What's missing is the visibility into management's reasoning.

                            The point here is to be proactive, not reactive. Agile is about the "Art of the Possible.". For example: we figure out various implementation scenarios and we can explain the trade-offs with management. We can delivery sooner with fewer features to get early feedback, we can deliver all the desired features, but not go as deep with their functionality, etc.

                            If management is arbitrarily asking the team to meet the goal (fixed date/fixed scope), then find out what's behind it. Do they want to set a challenging goal to help the team improve, has an Executive made a promise to a customer to close business, etc. Does management not understand how/why agile works and they need education. There can be many good explanations.

                            Once you find out what is going on, it will change your mindset (paradigm shift) and many alternatives to solve the problem will emerge.

                            Regards,
                            Richard Knaster

                            Original question:
                            Your boss wants your team to deliver certain functionality by a certain date (deadline), but your velocity is unable to achieve that. What options/suggestions do you have for your management who really want this to get done? More people? Overtime? What else to increase the velocity?


                          • George Dinwiddie
                            Michael, ... Thanks for THAT earworm. I haven t thought of that song in a long, long time. For those that haven t heard it:
                            Message 13 of 30 , Dec 3, 2012
                            View Source
                            • 0 Attachment
                              Michael,

                              On 12/3/12 2:41 PM, Michael James wrote:
                              > more houses on the hillside made of ticky tacky

                              Thanks for THAT earworm. I haven't thought of that song in a long, long
                              time. For those that haven't heard it:
                              https://www.youtube.com/watch?v=HlSpc87Jfr0

                              - George

                              --
                              ----------------------------------------------------------------------
                              * George Dinwiddie * http://blog.gdinwiddie.com
                              Software Development http://www.idiacomputing.com
                              Consultant and Coach http://www.agilemaryland.org
                              ----------------------------------------------------------------------
                            Your message has been successfully submitted and would be delivered to recipients shortly.