## Re: [scrumdevelopment] How to increase velocity

Expand Messages
• 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
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?

• ... 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 2 of 30 , Nov 28, 2012

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.
• 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 3 of 30 , Nov 28, 2012
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 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?

• ++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 4 of 30 , Nov 28, 2012
++1 to Laurent's excellent questions and advice (the other replies are also, of course, helpful).

-------
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

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/

<*> 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/

• Or put the customer on a spacecraft traveling away from Earth at a significant fraction of the speed of light.
Message 5 of 30 , Nov 28, 2012

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

• 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 6 of 30 , Nov 28, 2012
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 wrote:

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.

• ... 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 7 of 30 , Nov 28, 2012
>
> 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
• 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 8 of 30 , Nov 28, 2012

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 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/

<*> 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/

• 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 9 of 30 , Nov 29, 2012
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
----------------------------------------------------------------------
• 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 10 of 30 , Nov 29, 2012
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.

• 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 11 of 30 , Nov 30, 2012
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 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

• 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 12 of 30 , Nov 30, 2012

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 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

• 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 13 of 30 , Nov 30, 2012
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.

-------
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.

• 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 14 of 30 , Nov 30, 2012
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?
> >
> >
> >
> >
> >
>
• Going faster is not always a good thing. Although, sometimes it is. Pretending to go faster produces far more distress than value.
Message 15 of 30 , Dec 1 12:24 AM
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?
> >
> >
> >
> >
> >
>

• 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 16 of 30 , Dec 1 7:45 AM

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?
> >
> >
> >
> >
> >
>

• 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 17 of 30 , Dec 1 10:20 AM
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.

-------
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?
> >
> >
> >
> >
> >
>

• 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 18 of 30 , Dec 2 1:44 PM
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?
• 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 19 of 30 , Dec 2 3:00 PM
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.
• 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 20 of 30 , Dec 3 12:04 AM
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
• Well said
Message 21 of 30 , Dec 3 11:33 AM
Well said

On Sun, Dec 2, 2012 at 4:44 PM, Account 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?

• 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 22 of 30 , Dec 3 11:41 AM
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?

• 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 23 of 30 , Dec 3 11:53 AM
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: