Increasing velocity.

[John Miller]

Can someone explain how increased velocity is metric we should actually consider for team performance? I keep hearing this and can not but forsee anything but bad consequences from it.

Thank You,

John 

Sent from my iPhone. It likes to sabotage my grammar. 

[George Dinwiddie]

John,

On 5/12/13 7:39 PM, John Miller wrote:
> Can someone explain how increased velocity is metric we should actually
> consider for team performance? I keep hearing this and can not but
> forsee anything but bad consequences from it.

I agree. The easiest way to get increased velocity is to increase the
estimates (or use smaller stories, if you're calculating velocity by
counting them). This will give you increased velocity, without any
increase in productivity.

Often when a team is focused on increased velocity, they try to hurry,
and they try to eliminate everything that doesn't immediately relate to
velocity. In this case, usually quality suffers and productivity goes down.

Velocity can go up, in my experience. But it goes up by focusing on
quality and self-improvement. Clean code allows you to extend it more
easily. Learning to work better, both individually and as a team, can
pay dividends in going faster. I've not seen this happen, though, when
there is an emphasis on velocity.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Mark Levison]

I can double or triple a teams velocity in 5 minutes. However nothing will change. Perhaps you had too many of those velocity cocktails last week in Vegas :-)

Cheers
Mark

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ron Jeffries]

Hi John,

On May 12, 2013, at 7:39 PM, John Miller <agiles...@gmail.com> wrote:

Can someone explain how increased velocity is metric we should actually consider for team performance? I keep hearing this and can not but forsee anything but bad consequences from it.

It's tricky. Suppose that there is some intrinsic difficulty for stories (relative to some team, software base, etc). So they can produce these stories at some "velocity". Now, if they are working well together, removing impediments, keeping their code clean, building up useful infrastructure, and so on, they'll become more competent, and the software will help them more and more and in fact there's a good shot their velocity will increase.

Thing is, if you ASK for this, they'll try to go fast, won't work well together, won't remove impediments, won't keep their code clean, will build up crappy infrastructure and everything goes to hell.

Neat, huh? You can only get it if you don't want it.

Ron Jeffries

www.XProgramming.com

Sometimes you just have to stop holding on with both hands, both feet, and your tail, to get someplace better. 

Of course you might plummet to the earth and die, but probably not: you were made for this.

[John Miller]

Yes, very Zen. Enlightenment can only be obtained if you do not seek it.

Good to hear that you all do not see increased velocity as a goal to shoot for. It seems to be the management fad of late : ( New metric, old management paradigm.

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

John Miller

Vibrant Lives, Work, Communities, and Schools

http://theagileschool.blogspot.com/

[John Miller]

Mark, lol, unfortunately I did not...

[Kurt Häusler]

Does measuring velocity in terms of number of PBIs rather than number of Story Points also suffer from the same bad consequences?

[John Miller]

I would think so. I can chop up the size of PBI's to make it appear I increased velocity. I can expect increased velocity as a manager and change behavior to getting more done rather than the right thing done. What are your thoughts, Kurt?

Thank You,
John
Sent from my iPhone. It likes to sabotage my grammar.

[Alan Dayley]

When we want a car to increase velocity we do not reach inside the dash and turn the speedometer needle, we press on the accelerator. We don't think about all the stuff it takes to get the added pressure on the accelerator pedal to result in an increased empirical measurement at the speedometer.

A few important things about the car going faster:

- All the stuff that causes the increase in velocity is complex but well understood and predictable.

- The pressure on the accelerator causes various inputs into the engine to change in the desired direction.

- The velocity is the outcome of those inputs. Change the inputs and the outcome changes.

Unlike a complex engine, teams and organizations are made up of independently acting agents, creating emergent and unpredictable behavior. We can't predict with certainly the effect on velocity of any one input. We have to learn over time and experimentation what is working. And what is working and even improving today will not work forever. There are just too many influences, even completely outside the team's organization, that can change the outcome. Thus the need for Agile ideas and agility.

The velocity (amount of work done) of a team is effected by various inputs. It is the outcome of those various inputs. Attempting to change the velocity directly bypasses the engine (the team capabilities) and all the inputs. The inputs are the same, the team capabilities haven't improved. In just asking for the needle to be moved directly, you have bypassed the path to viable capability improvement. And the value of velocity as an empirical indicator for planning is ruined.

Don't ask to increase velocity. Ask what inputs (priority, vision, clarity of purpose, customer delighters, individual and team autonomy, environments supporting collaboration, organizational structures that foster trust, etc., etc.) you can change so that your team (the engine) can improve.

And, if I may, some more of my recent comments about this: http://www.bigvisible.com/2013/03/agile-transformation-faster-not-magical/

Alan

[Pierre Neis]

Using velocity as a KPI is very complicated our source for never ending debates.

Purpose of velocity is to know when PBL should be empty.

Stable velocity: can be used to detect slowing team dynamic (ex. after 6 months your team can make Planning Poker estimates without cards)

Fixed velocity: if you believe in magic, then it's possible. Elsewhere, you should have quality issues.

Variable velocity: this is natural according to high tech debt risk coming from iteration increments. One of the complication in SLA and Change Request Contracts!

Regarding KPIs, Scott Downey had designed some nice slides on that http://rapidscrum.com/Resources/ (i.e Measuring Scrum)

Kind regards, cordialement, mit freundliche Grüsse,

Pierre E. Neis 
Scrum/Lean Coach - Senior Management Consultant



Agir Anticiper Durablement sarl
19 place Bleech |L-7610 Larochette | Luxembourg
M: +352 661 727 867

email:  pierr...@we-and-co.com
web:    http://wecompany.wordpress.com/
Meet with me: http://meetwith.me/pierreneis
 

Contact me: pierre.neis

Get a signature like this. CLICK HERE.  

[Kurt Häusler]

On Mon, May 13, 2013 at 5:48 AM, John Miller <agiles...@gmail.com> wrote:
> I would think so. I can chop up the size of PBI's to make it appear I increased velocity.

That doesn't sound too bad.

> I can expect increased velocity as a manager and change behavior to getting more done rather than the right thing done. What are your thoughts, Kurt?

Well I consider how the Kanban community talks about throughput, which
essentially velocity measured in items (or perhaps in money). It is
hard to game. It is hard to increase directly, but if our customer is
more interested in features in aggregate, or quantity of features
rather than speed to market if a single feature, optimizing throughput
might be a worthy goal. You can run experiments, and determine if they
are worthwhile or not by measuring increases in throughput.

If you have a backlog and you know that if you cannot deliver n
stories before the end of the year then the operation isn't viable,
otherwise you should shut up shop now. If you see throughput or
velocity as something that cannot or should not be optimized and you
know with your current velocity you won't reach it then what do you
do? If you assume it is hard but possible to change you might consider
the risks of e.g. hiring someone to add capacity. I think the same
thinking can be applied to teams using Scrum, to a certain extent,
with caution of course.

[Kurt Häusler]

In short I think we can reduce velocity (not story points but true
velocity in number of items or actual value) by reducing waste, using
improved techniques, (making items smaller is a pseudo-gamey way of
doing it that still brings advantages), adding capacity, investing in
learning etc.

On Mon, May 13, 2013 at 5:48 AM, John Miller <agiles...@gmail.com> wrote:

[Ron Jeffries]

Kurt,

On May 12, 2013, at 11:43 PM, Kurt Häusler <kurt.h...@gmail.com> wrote:

Does measuring velocity in terms of number of PBIs rather than number of Story Points also suffer from the same bad consequences?

Can you think of some reason why it wouldn't? What has been your experience when a team was pressured to take on more items?

Ron Jeffries

www.XProgramming.com Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana

[Ron Jeffries]

Hi Kurt,

On May 13, 2013, at 3:28 AM, Kurt Häusler <kurt.h...@gmail.com> wrote:

On Mon, May 13, 2013 at 5:48 AM, John Miller <agiles...@gmail.com> wrote:

I would think so. I can chop up the size of PBI's to make it appear I increased velocity.

That doesn't sound too bad.

Yes. We did two stories last time. This time we cut them in half and did FOUR! Twice as fast! We rock! :)

Ron Jeffries

www.XProgramming.com

If another does not intend offense, it is wrong for me to seek it;

if another does indeed intend offense, it is foolish for me to permit it.

  -- Kelly Easterley

[George Dinwiddie]

John,

On 5/12/13 11:48 PM, John Miller wrote:
> I would think so. I can chop up the size of PBI's to make it appear I
> increased velocity.

With this, at least you've got the advantage of small stories (assuming
they remain functional slices).

> I can expect increased velocity as a manager and
> change behavior to getting more done rather than the right thing
> done. What are your thoughts, Kurt?

Hmmm... I hadn't imagined doing the wrong things.

Any judgmental approach is likely to backfire, whether using "objective
numbers" to back it up or not. My advice is to seek understanding.

- George

>
> Thank You,
> John
> Sent from my iPhone. It likes to sabotage my grammar.
>
>
> On May 12, 2013, at 8:43 PM, Kurt Häusler <kurt.h...@gmail.com> wrote:
>
>> Does measuring velocity in terms of number of PBIs rather than number of Story Points also suffer from the same bad consequences?
>>
>>
>> On 13 May 2013, at 01:39, John Miller <agiles...@gmail.com> wrote:
>>
>>> Can someone explain how increased velocity is metric we should actually consider for team performance? I keep hearing this and can not but forsee anything but bad consequences from it.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
>> To post to this group, send email to scruma...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>

[Dan Rawsthorne]

Just so. Velocity is a result, not a goal. You'd like to know your team's velocity so you can do adequate predictions, but you can't set a goal of a given velocity in order to get the predictions you want.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of Exploring Scrum: the Fundamentals

[Amitai Schlair]

On Sun, May 12, 2013 at 8:10 PM, George Dinwiddie
<li...@idiacomputing.com> wrote:

> Velocity can go up, in my experience. But it goes up by focusing
> on quality and self-improvement. Clean code allows you to extend
> it more easily. Learning to work better, both individually and as
> a team, can pay dividends in going faster. I've not seen this happen,
> though, when there is an emphasis on velocity.

This is a case of the old adage "Be careful what you measure, because
you'll get it." Whether we want them to or not, metrics encourage
people to maximize them. It's a rare metric that encourages its own
maximization in the ways you'd want. Velocity isn't one of those, it's
just a really useful indicator, so we have to live with it until a
better one comes along, and in the meantime try our best to prevent
people from doing wrong things with it.

Like Ron and George are saying, if we confuse the map for the
territory, we won't get somewhere real any faster.

[John Miller]

Hi Kurt,

I agree with smaller than larger PBI's.
Not so sure about throughput being harder to game or a better metric than velocity. CFD's just makes it look more scientific.

The reason I asked the question in the first place is I keep hearing not only practitioners state the need to measure and increase velocity, but articles staring how coaches helped increase velocity, as well as hearing practitioners stating how a coach or trainer suggested it as an improvement metric. I have always thought it was dangerous, but open to changing my mind if I heard a good argument for it.

Thank You,
John
Sent from my iPhone. It likes to sabotage my grammar.

[George Dinwiddie]

John,

On 5/13/13 11:57 AM, John Miller wrote:
> Hi Kurt,
>
> I agree with smaller than larger PBI's.
> Not so sure about throughput being harder to game or a better metric
> than velocity. CFD's just makes it look more scientific.
>
> The reason I asked the question in the first place is I keep hearing
> not only practitioners state the need to measure and increase
> velocity, but articles staring how coaches helped increase velocity,
> as well as hearing practitioners stating how a coach or trainer
> suggested it as an improvement metric. I have always thought it was
> dangerous, but open to changing my mind if I heard a good argument
> for it.

Calling someone a coach doesn't make them one.

- George

[Mark Levison]

John - there is one good argument. If a coach talks about increasing a teams velocity in the way you described they're not a good agile coach.

Cheers

Mark

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@googlegroups.com.

To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
Cheers
Mark Levison
Agile Pain Relief Consulting | Writing
Proud Sponsor of Agile Tour Gatineau Ottawa Nov 28, Toronto 26 and Montreal 24

[Alan Dayley]

I re-found this page today from Tim Ottinger's blog: http://agileotter.blogspot.com/2012/09/14-weird-observations-about-agile-team.html

Alan

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.

[Michael Vizdos]

Just. Deliver.

The conversation changes.

This velocity one seems academic and a shiny object for managers to justify some false metric.

Really.

Am thinking you knew I'd say that though.

Mike Vizdos
Implementingscrum.com

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.