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

Re: [scrumdevelopment] How to increase velocity

Expand Messages
  • Anand Mahadevan
    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
    Message 1 of 30 , Nov 28, 2012
    View Source
    • 0 Attachment
      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


      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?



    • Bret Wortman
      To add to what Ron said, your goal really isn t increasing velocity, the goal is delivering a product at a particular time. Don t think of velocity as some
      Message 2 of 30 , Nov 28, 2012
      View Source
      • 0 Attachment
        To add to what Ron said, your goal really isn't increasing velocity, the goal is delivering a product at a particular time.

        Don't think of velocity as some magical number to be manipulated. It's more a vital sign for your team, a way to gauge how things are going. Establish a baseline and see what happens as the team makes alterations to its process. Viewed from outside, it's just a number. Viewed in the context of the inspect & adapt cycle, it's a valuable measure, but not the only one.

        But trying to manipulate it directly to speed the team up? Almost guaranteed to fail.

        On Wed, Nov 28, 2012 at 6:09 AM, RonJeffries <ronjeffries@...> wrote:
         

        Cut features. Nothing else works, ever.



        --
        Bret Wortman
        The Damascus Group
        Fairfax, VA

      • brian_bofu
        It s not manipulating the number. It s about how to get more things done or done faster. The management is willing to offer their resource and help. We re
        Message 3 of 30 , Nov 28, 2012
        View Source
        • 0 Attachment
          It's not manipulating the number. It's about how to get more things done or done faster. The management is willing to offer their resource and help. We're looking for constructive suggestions to improve the ability to deliver.

          --- In scrumdevelopment@yahoogroups.com, Bret Wortman <bret.wortman@...> wrote:
          >
          > To add to what Ron said, your goal really isn't increasing velocity, the
          > goal is delivering a product at a particular time.
          >
          > Don't think of velocity as some magical number to be manipulated. It's more
          > a vital sign for your team, a way to gauge how things are going. Establish
          > a baseline and see what happens as the team makes alterations to its
          > process. Viewed from outside, it's just a number. Viewed in the context of
          > the inspect & adapt cycle, it's a valuable measure, but not the only one.
          >
          > But trying to manipulate it directly to speed the team up? Almost
          > guaranteed to fail.
          >
          > On Wed, Nov 28, 2012 at 6:09 AM, RonJeffries <ronjeffries@...> wrote:
          >
          > > **
          > >
          > >
          > > Cut features. Nothing else works, ever.
          > >
          > >
          > --
          > Bret Wortman
          > The Damascus Group
          > Fairfax, VA
          > http://bretwortman.com/
          > http://twitter.com/BretWortman
          >
        • RonJeffries
          Brian, ... First, do Scrum. The point of Scrum is to improve your ability to deliver. So tell us a bit about what Scrum is telling you ... or why it isn t
          Message 4 of 30 , Nov 28, 2012
          View Source
          • 0 Attachment
            Brian,

            On Nov 28, 2012, at 6:29 AM, "brian_bofu" <brian_bofu@...> wrote:

            It's not manipulating the number. It's about how to get more things done or done faster. The management is willing to offer their resource and help. We're looking for constructive suggestions to improve the ability to deliver.

            First, do Scrum. The point of Scrum is to improve your ability to deliver. So tell us a bit about what Scrum is telling you ... or why it isn't telling you.

            Your mission is to build shippable software in every Sprint: try to do that and pay attention.
            You have a daily standup meeting to tell you what is in people's way: remove those obstacles.
            You have a retrospective every Sprint to decide what needs improvement: do that.

            To speed up you need to know what is slowing you down now. There are many possibilities, and what to do depends on the answer:
            • are you delivering a shippable product every two weeks?
            • is your product owner competent and empowered?
            • are requirements clear?
            • are you processing many defects?
            • are you writing tests before the code, or after?
            • are there lots of handoffs from person to person in the course of building a feature?
            • are your features large and complex, requiring more than a couple of days to build each one?
            • are team members available full time on the project?
            • are there changes and interruptions causing work to be thrown away or redone?

            In short, what's happening that is slowing you down? Quite likely, the team knows what to do about those things. So do the people here, if you need suggestions. However, with a deadline looming, you're not going to suddenly go twice as fast.

            Seriously, the question you were asked sounds a lot like how to get ten pounds into a five pound bag, and as phrased it didn't sound much like "what can I the manager do, or what can the product owner do, to help you?" It sounded like "what are you developers going to do to get all this stuff that I want when I want it."

            The answer to that is to choose what to do next, and to find and defer work that doesn't have to be done.
            Don't ignore your dreams; don't work too much; say what you think; cultivate friendships; be happy. -- Paul Graham

          • Paul Hudson
            Ask the team. What are your retrospective meetings discussing? What do the team think are the items that are impacting what they can get done? Work on removing
            Message 5 of 30 , Nov 28, 2012
            View Source
            • 0 Attachment
              Ask the team. What are your retrospective meetings discussing? What do the team think are the items that are impacting what they can get done? Work on removing those impediments.

              There's no magic item that you implement in any team and it automatically increases velocity. Overtime is one that's known not to work well or at all. Adding people was largely debunked by Brooks a long time ago.

              So you need to look at what is impacting what can be done in your team, in your context, and your organisation. Once you've identified some stuff, then the people on this list may be able to offer some advice.

              Who is your Scrum master? How experienced is she? You may benefit from an external Scrum coach (and I'm not one, so I'm not pushing the service :)) to help the team identify impediments and possible ways to mitigate or remove them.

              But these things take time. You should be telling your management that given what they've asked for and the team's current velocity, it is probable they cannot have all they want at the time they want. You will be looking to improve things, but it is not guaranteed (or indeed, probably not likely, depending on how far off you are now) to change this.

              And management that asks for fixed-scope  and fixed-date/effort probably counts as an impediment,


              On 28 November 2012 11:29, brian_bofu <brian_bofu@...> wrote:
               

              It's not manipulating the number. It's about how to get more things done or done faster. The management is willing to offer their resource and help. We're looking for constructive suggestions to improve the ability to deliver.



              --- In scrumdevelopment@yahoogroups.com, Bret Wortman <bret.wortman@...> wrote:
              >
              > To add to what Ron said, your goal really isn't increasing velocity, the
              > goal is delivering a product at a particular time.
              >
              > Don't think of velocity as some magical number to be manipulated. It's more
              > a vital sign for your team, a way to gauge how things are going. Establish
              > a baseline and see what happens as the team makes alterations to its
              > process. Viewed from outside, it's just a number. Viewed in the context of
              > the inspect & adapt cycle, it's a valuable measure, but not the only one.
              >
              > But trying to manipulate it directly to speed the team up? Almost
              > guaranteed to fail.
              >
              > On Wed, Nov 28, 2012 at 6:09 AM, RonJeffries <ronjeffries@...> wrote:
              >
              > > **

              > >
              > >
              > > Cut features. Nothing else works, ever.
              > >
              > >
              > --
              > Bret Wortman
              > The Damascus Group
              > Fairfax, VA
              > http://bretwortman.com/
              > http://twitter.com/BretWortman
              >


            • Bret Wortman
              Agreed and understood. Given your current velocity, figure out how many features or stories or BLIs you can get done in the time available. That s what your
              Message 6 of 30 , Nov 28, 2012
              View Source
              • 0 Attachment
                Agreed and understood. Given your current velocity, figure out how many features or stories or BLIs you can get done in the time available. That's what your team, today, can commit to complete.

                Anything we suggest might or might not work for this particular team and might reduce the team's velocity instead of increasing it. There are no magic pills, or we wouldn't have an inspect/adapt cycle for teams. What makes scrum work, and what makes performing teams actually increase their own velocity, is that there's enough freedom in the process to change things, that a team can work out for itself what helps it get more done well, and what doesn't.



                On Wed, Nov 28, 2012 at 6:29 AM, brian_bofu <brian_bofu@...> wrote:
                 

                It's not manipulating the number. It's about how to get more things done or done faster. The management is willing to offer their resource and help. We're looking for constructive suggestions to improve the ability to deliver.



                --- In scrumdevelopment@yahoogroups.com, Bret Wortman <bret.wortman@...> wrote:
                >
                > To add to what Ron said, your goal really isn't increasing velocity, the
                > goal is delivering a product at a particular time.
                >
                > Don't think of velocity as some magical number to be manipulated. It's more
                > a vital sign for your team, a way to gauge how things are going. Establish
                > a baseline and see what happens as the team makes alterations to its
                > process. Viewed from outside, it's just a number. Viewed in the context of
                > the inspect & adapt cycle, it's a valuable measure, but not the only one.
                >
                > But trying to manipulate it directly to speed the team up? Almost
                > guaranteed to fail.
                >
                > On Wed, Nov 28, 2012 at 6:09 AM, RonJeffries <ronjeffries@...> wrote:
                >
                > > **

                > >
                > >
                > > Cut features. Nothing else works, ever.
                > >
                > >
                > --
                > Bret Wortman
                > The Damascus Group
                > Fairfax, VA
                > http://bretwortman.com/
                > http://twitter.com/BretWortman
                >




                --
                Bret Wortman
                The Damascus Group
                Fairfax, VA

              • Laurent Bossavit
                ... How far away is that deadline: six days? Six weeks? Six months? A year or more? How large is the discrepancy between the date predicted by current velocity
                Message 7 of 30 , Nov 28, 2012
                View Source
                • 0 Attachment
                  > Your boss wants your team to deliver certain functionality by a certain date (deadline),

                  How far away is that deadline: six days? Six weeks? Six months? A year or more?

                  How large is the discrepancy between the date predicted by current velocity and the desired deadline?

                  > More people?

                  Won't work if the deadline is near.

                  > Overtime?

                  Won't work, and will lose talent you can't afford to lose.

                  > What else to increase the velocity?

                  That's not the only option; you can also cut scope.
                • Cass Dalton
                  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
                  Message 8 of 30 , Nov 28, 2012
                  View Source
                  • 0 Attachment
                    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


                    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
                    ++1 to Laurent s excellent questions and advice (the other replies are also, of course, helpful). If you re truly looking for practical advice, the answers to
                    Message 9 of 30 , Nov 28, 2012
                    View Source
                    • 0 Attachment
                      ++1 to Laurent's excellent questions and advice (the other replies are also, of course, helpful).

                      If you're truly looking for practical advice, the answers to Laurent's questions will be most helpful.
                       
                      -------
                      Charles Bradley
                      http://www.ScrumCrazy.com




                      From: Laurent Bossavit <lolists@...>
                      To: scrumdevelopment@yahoogroups.com
                      Sent: Wednesday, November 28, 2012 4:55 AM
                      Subject: Re: [scrumdevelopment] How to increase velocity

                      > Your boss wants your team to deliver certain functionality by a certain date (deadline),

                      How far away is that deadline: six days? Six weeks? Six months? A year or more?

                      How large is the discrepancy between the date predicted by current velocity and the desired deadline?

                      > More people?

                      Won't work if the deadline is near.

                      > Overtime?

                      Won't work, and will lose talent you can't afford to lose.

                      > What else to increase the velocity?

                      That's not the only option; you can also cut scope.



                      ------------------------------------

                      To Post a message, send it to:  scrumdevelopment@...
                      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                      <*> To visit your group on the web, go to:
                          http://groups.yahoo.com/group/scrumdevelopment/

                      <*> Your email settings:
                          Individual Email | Traditional

                      <*> To change settings online go to:
                          http://groups.yahoo.com/group/scrumdevelopment/join
                          (Yahoo! ID required)

                      <*> To change settings via email:
                          scrumdevelopment-digest@yahoogroups.com
                          scrumdevelopment-fullfeatured@yahoogroups.com

                      <*> To unsubscribe from this group, send an email to:
                          scrumdevelopment-unsubscribe@yahoogroups.com

                      <*> Your use of Yahoo! Groups is subject to:
                          http://docs.yahoo.com/info/terms/



                    • Adam Sroka
                      Or put the customer on a spacecraft traveling away from Earth at a significant fraction of the speed of light.
                      Message 10 of 30 , Nov 28, 2012
                      View Source
                      • 0 Attachment

                        Or put the customer on a spacecraft traveling away from  Earth at a significant fraction of the speed of light.

                        On Nov 28, 2012 3:11 AM, "RonJeffries" <ronjeffries@...> wrote:
                         

                        Cut features. Nothing else works, ever.

                        R
                        On Nov 28, 2012, at 4:38 AM, "brian_bofu" <brian_bofu@...> wrote:

                        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?


                        Ron Jeffries
                        www.XProgramming.com
                        It's true hard work never killed anybody, but I figure, why take the chance?
                        -- Ronald Reagan



                      • Ram Srinivasan
                        Great questions by Laurant which can provide you insights. Also, why not ask your team what challenges/impediments they are facing and then start to address
                        Message 11 of 30 , Nov 28, 2012
                        View Source
                        • 0 Attachment
                          Great questions by Laurant which can provide you  insights. Also, why not ask your team what challenges/impediments they are facing and then start to address those challenges ?

                          Ram

                          On Wed, Nov 28, 2012 at 6:55 AM, Laurent Bossavit <lolists@...> wrote:
                           

                          > Your boss wants your team to deliver certain functionality by a certain date (deadline),

                          How far away is that deadline: six days? Six weeks? Six months? A year or more?

                          How large is the discrepancy between the date predicted by current velocity and the desired deadline?

                          > More people?

                          Won't work if the deadline is near.

                          > Overtime?

                          Won't work, and will lose talent you can't afford to lose.


                          > What else to increase the velocity?

                          That's not the only option; you can also cut scope.


                        • banshee858
                          ... I agree with Ron s main point - cut features. I d also echo what someone else said in this thread Ask the Team. However, perhaps cutting features is not
                          Message 12 of 30 , Nov 28, 2012
                          View Source
                          • 0 Attachment
                            >
                            > 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?
                            >
                            I agree with Ron's main point - cut features. I'd also echo what someone else said in this thread "Ask the Team."

                            However, perhaps cutting features is not (perceived) as possible. In that case, if your organization truly has the resources available then it may make sense to hire more people. If you have more people available, you can do more things and increase output. Keep in mind, adding more bodies does not increase output overnight and at some point, too many people degrades your ability to deliver.

                            There are some technical trainings you might be able to do to help the Team improve their capability to deliver and improve quality, but I would consider those types of things a longterm investment. IME, any sort of investment in technical skills takes about 3 to 4 months to work their way into increased TEAM capability because the Team needs to continue to work with their legacy code.

                            Overtime is always an option, but I would recommend against reaching for the overtime lever since it burns out people, decreases morales, decreases quality and diminishes the ability of the Team to deliver a high-quality product that can change over time.

                            Carlton
                          • Jesse Houwing
                            What will most likely work: - Remove other functionality from the sprint and focus on what is really important - Dress down the requested functionality to it s
                            Message 13 of 30 , Nov 28, 2012
                            View Source
                            • 0 Attachment

                              What will most likely work:
                              - Remove other functionality from the sprint and focus on what is really important

                              - Dress down the requested functionality to it's bare minimum to deliver the value, without the need for more functionality

                              - Find a different solution for the problem. 

                              What most likely won't work in this short time span (but might have worked if you've seen this coming weeks ahead) :

                              - Enlarge the existing team (probably won't work since the velicity will fall considerably by changign a team)

                              - Line up an extra/new team (probably won't work, since the organisational changes will seriously impact your velocity before you start to benefit)

                              - Overtime (Should not really be considered, as quality always suffers and you will probably not deliver the new features satisfactory anyway)



                              On Wed, Nov 28, 2012 at 10:38 AM, brian_bofu <brian_bofu@...> wrote:
                              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?



                              ------------------------------------

                              To Post a message, send it to:   scrumdevelopment@...
                              To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                              <*> To visit your group on the web, go to:
                                  http://groups.yahoo.com/group/scrumdevelopment/

                              <*> Your email settings:
                                  Individual Email | Traditional

                              <*> To change settings online go to:
                                  http://groups.yahoo.com/group/scrumdevelopment/join
                                  (Yahoo! ID required)

                              <*> To change settings via email:
                                  scrumdevelopment-digest@yahoogroups.com
                                  scrumdevelopment-fullfeatured@yahoogroups.com

                              <*> To unsubscribe from this group, send an email to:
                                  scrumdevelopment-unsubscribe@yahoogroups.com

                              <*> Your use of Yahoo! Groups is subject to:
                                  http://docs.yahoo.com/info/terms/


                            • George Dinwiddie
                              Brian, ... You ve gotten some good suggestions about minimizing the work not done. Another approach is to buy the boss 4 copies of The Mythical Man-Month
                              Message 14 of 30 , Nov 29, 2012
                              View Source
                              • 0 Attachment
                                Brian,

                                On 11/28/12 6:29 AM, brian_bofu wrote:
                                > It's not manipulating the number. It's about how to get more things
                                > done or done faster. The management is willing to offer their
                                > resource and help. We're looking for constructive suggestions to
                                > improve the ability to deliver.

                                You've gotten some good suggestions about "minimizing the work not done."

                                Another approach is to buy the boss 4 copies of "The Mythical Man-Month"
                                so he can read it in 1/4 the time.

                                The only other approach I've seen that can actually increase
                                productivity is to focus on quality and learning. Developers CAN learn
                                to produce working software faster, but not if they're pushed to be
                                faster. They have to be asked for "better" and given time for learning.
                                Yes, it's likely they'll slow down a bit before they can become faster.
                                Yes, it's a long-term approach that might not show returns for this
                                current project. Yes, they still have to "want to" be better.

                                In the near term, cutting scope is THE way to meet a deadline. They
                                whole point of having a PO is adjusting scope in a way that gives the
                                best possible result by the time desired. Scrum is not a magic way to
                                speed up those lazy developers.

                                - George

                                --
                                ----------------------------------------------------------------------
                                * George Dinwiddie * http://blog.gdinwiddie.com
                                Software Development http://www.idiacomputing.com
                                Consultant and Coach http://www.agilemaryland.org
                                ----------------------------------------------------------------------
                              • RonJeffries
                                Cass, ... What if they learn something new? What if someone has a creative idea? Ron Jeffries www.XProgramming.com I have two cats, and a big house full of cat
                                Message 15 of 30 , Nov 29, 2012
                                View Source
                                • 0 Attachment
                                  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
                                  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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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 26 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 27 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 28 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.