56312Re: [scrumdevelopment] Re: How to increase velocity
- Dec 1, 2012Good 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.-------
From: Cass Dalton <cassdalton73@...>
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.
--- In firstname.lastname@example.org, 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:* email@example.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?
- << Previous post in topic Next post in topic >>