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

Re: [scrumdevelopment] How to increase velocity

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