Breaking the world record

June 22, 2009

My younger daughter has her last swim meet of the season tonight. I am excited (and still a bit affected by Father’s Day yesterday).

When I talk about Agile & Scrum & Lean, I often refer to the Michael Phelps’ attitude. Not his attitude in South Carolina, whatever you may think of that. (Not that I begrudge him some relaxation.)

I refer to his attitude about swimming. He broke the world record before the Olympics, he broke it in the first heat, again in the second heat and he intends to break it again in the finals. He is relentless.

We ordinary humans must take the same attitude.

Just about now, your colleagues would be encouraged by seeing your team break its own ‘personal best’ record.

So, what do we mean practically?

Well, first, we mean sustainable pace. We mean that we will break records in our new product development work, not by working harder (longer hours), but by working more creatively. By creating knowledge — faster, better, with more certainty and more Business Value.

Second, we will admit that half of what we know is wrong. (Cf Taiichi Ohno in “Workplace Management.”)

Third, we will double the team’s velocity. In 6 months or less.

Doubling velocity (story points done-done in each Sprint) usually means we must improve several things:

  • A clearer definition of done (or “done, done” if you prefer): Usually we let this be too vague. It may vary for some stories, but for most software development stories it must be very clear and consistent. And, in my opinion, it must mean “no [known] bugs escape the Sprint.” Also, testing must include at least functional testing.
  • We must measure velocity: I still can’t believe how many teams I find that they don’t have some measure of velocity. More on this next time. For now, “Velocity: Don’t leave home without it.”
  • We must prioritize the impediments, and keep removing or reducing the top one until velocity is doubled. Hint: We might want to prioritize the impediments by how much the removal/reduction will increase velocity — 25% here, 30% there — pretty soon you’re talking a real increase in velocity.

Note: Improving quality and reducing technical debt are almost always important keys to seriously increased velocity. Not the only keys, but very important.

Who is going to feel better when the team doubles velocity (with sustainable pace)? Yes, the team, perhaps first and most importantly. And customers. And managers. And the widows and orphans who own the company.

Is velocity the only metric in town? Good question: No. But explanation for another day. Increase velocity now, show yourself you can do that professionally and then we talk.

“But, things are so good around here, we can’t possibly double velocity.”

My first thought is that your biggest impediment is that people are hiding from the truth. Every place I look, we are using such a small percentage of the potential of people, that doubling the velocity is a task any team can accomplish. Look again and take the Michael Phelps’ attitude.

If you really think you can’t get any better, declare yourselves the best team in the world, write-up your success and challenge other teams, anywhere, to beat you. You might just learn a thing or two, and have some serious fun.

 

 

« « What is Business Value Engineering? || Recommended Reading – June 2009 » »

Posted in: Better Agile, Teams
Tagged:

12 thoughts on “Breaking the world record”

  1. Kurt Häusler

    Hi,
    I am not so sure if doubling velocity makes much sense as a goal. Velocity is just a tool to aid in estimating how much work the team should take on each iteration. It is a fairly neutral indicator of the relative relationship between your particular team's story points and actual durations, rather than a concrete productivity metric.

    Ideally velocity should stabilize rather than increase, as the team becomes more accurate in estimating stories.

    As the team becomes more productive, their estimates should take that into account.

    Doubling velocity is easy to game anyway, just double your estimates.

    ↓
  2. Joe Little

    Hi Kurt,

    Thanks for your thoughtful comments. As Ohno might say, I could not disagree more.

    First, I agree on this: Delivering (more) Business Value is far more important than Velocity.

    So, by increasing velocity, I am assuming that, from a BV viewpoint, ceteris paribus, each story has equal BV. (A good enough assumption for this discussion.)

    If that assumption holds, then increasing velocity has huge benefits for society.

    Ideally velocity should never satbilize, but always be increasing. Yes, there probably is some physical limit beyond which Michael Phelps can not get faster. Similarly, there is perhaps some limit beyond which the team cannot get more creative. But, as this is knowledge creation, we have no idea what that limit is. Certainly we have not begun to approach it.

    What we can say with certainty is that lots of teams have used Scrum to jump to a so-called "hyperproductive" state. I put that in quotes because it is likely not really the case…what we are merely seeing is that waterfall was terribly and "agile" (as we currently know it) is just not obviously stupid.

    Estimation accuracy: Yes, we want that to get better. And the velocity feedback enables improvement. But remember that Story Points are relative. It is size/complexity, not effort. So, a 1 in Sprint 1 should still be a 1 in Sprint 20 (even after velocity has tripled). This means that all the stories that we estimated in initial Release Planning do not have to be refactored (for Story Points) later in the effort (assuming the stories are small). This saves some effort.

    Yes, teams can game the Story Points. There is no metric that cannot or will not be gamed under "normal" (bad) conditions. But in agile, we are asking everyone to just tell the truth. And the team is using velocity themselves. There seems less need to lie to one's self.

    Regards, Joe

    ↓
  3. Anonymous

    "Third, we will double the team's velocity. In 6 months or less."

    This comment makes me very uncomfortable. I hope you didnt mean that literally.

    ↓
    1. Joe Little Post author

      Hi Anon,
      Sorry for the very late reply.
      Yes, I did mean that literally.
      See Jeff Sutherland’s comment above.

      So, what can be wrong with that?

      One, is that the managers press and try to make the Team work more hours.
      Second, the Team interprets that as a request to reduce quality.
      I support neither of those options. And I expect you to explain successfully to the right people why these options are not good. (They are humans, so not always possible.)

      Next, some companies won’t allow useful change. In that case doubling will be very very hard.
      But I think often you (and the Team) can convince them to allow or support changes. By convincing them in their language, in management talk.

      And I really think that things are so screwed up and teams have used so little of their own potential that doubling velocity is easy. Truly, easy. Ok, lots of hard work in a way, but easy.

      So, more specifically, after I say that, why are you uncomfortable?
      Thanks, Joe

  4. Joe Little

    Hi Anon.,

    Please say who you are, or email me directly.

    Yes, I meant it literally. Sorry that you don't like it.

    Based on prior related conversations with others, let me say: doubling velocity does NOT mean breaking sustainable pace. It means getting cleverer, not working "harder".

    Is the Team always able to remove enough key impediments to double? No. But usually there are so many impediments (imperfections) that if they (and the managers!!) focus on removing just some of them (some of the top ones), over time, they can almost always easily double. Or so things appear in my part of the universe.

    And what does your Gemba look like? (If you recognize the lean term, Gemba.)

    Thanks, Joe

    ↓
  6. Jeff Sutherland

    All good teams triple there velocity with Scrum and the best teams do it in three sprints. If they continue to improve engineering practices they will stabilize at 5 times the velocity of a waterfall team. We see this consistently in case study after case study. And this is at less than 40 hours a week because if they work more they slow down.

    So why are teams uncomfortable with velocity? Some teams have dysfunctional management that will use it against them. So root case analysis will reveal that management is destroying the Scrum. Go work for another company!

    Some companies say they have stopped using the burndown chart because it depresses the developers as they fail all the time. Hire new developers!

    50% of the companies who say they are doing Scrum can't get working software at the end of a Sprint so their velocity is zero. So that might be a reason for not calculating velocity.

    Of the remaining 50%, over half of them can't pass the Nokia test so they would have very low velocity (if they knew it).

    At OpenView Partners we won't invest in teams that do not know their velocity and we not look at a plan presented by management who doesn't know the velocity of the teams as the plan is complete fiction. Sometimes we just replace the managers.

    Maybe there are other reasons people don't know their velocity?

    ↓
  7. Rob

    I am also very wary of anyone who suggests increasing velocity is a goal. *They are just estimates*. It is so easy to game. I've seen it happen both consciously and subconsciously with very undesirable effects.

    The only measure of increased productivity is completed work. Measuring this also has the desirable side effect of encouraging people to break work down into the smallest possible deliverable units.

    Measure the output not the input.

    On my team we find velocity very useful for controlling our capacity and giving stakeholders an idea of delivery schedules but it is certainly not something we strive to increase. As the first commenter said what you desire from velocity is stability.

    ↓
  8. Joe Little

    Hi Rob,

    In many ways I agree with what you said.

    So, velocity is about done, done work. A story is not done until it passes that team's definition of done. Ideally, the story is in production, but for most teams it may be closer to saying: "It is unit tested and functionality tested, and reviewed by the PO, and all problems have been fixed." Velocity by any other definition is just "pretend." So, as you say, it is about completed work.

    There is an expected velocity, definitely an estimate. And there is actual velocity, which I would call more an approximation. But based on done, done work. The expected velocity is always being adjusted based on "yesterday's weather" (the usual phrase for this pattern: using the known velocity from the prior sprint, other things equal).

    While I would say any metric can be gamed, if the Team really understands velocity in the full context, they won't want to game it. The PO and the SM and the Team just don't need to lie to themselves.

    I strongly agree with your comment about encouraging the team to write and complete smaller stories.

    Again, I agree on measuring output. And measuring input to some degree: in the use of velocity we are assuming a constant team size and sustainable pace (velocity helps us fight to maintain sustainable pace). If team size changes (not wanted, but it happens) then we must use common sense to interpret velocity.

    Not sure what you mean about stability. I think I would readily accept irregular, unpredictable improvements in velocity. And we certainly have to be honest and admit when "stuff happens" and the velocity sinks for a sprint or two. Still, on average, velocity should be increasing to some degree during most of the team's life. Yes, there is probably some theoretical maximum out there, but has your team or my team reached it? I doubt it.

    If you mean stability in these following two senses, I agree. Velocity is only calculated based upon done, done work. And, about 90% of the time, when the Team commits they finish all the stories they commit to (and sometimes a bit more).

    And I would agree that a team must get to a known and somewhat predictable velocity before making significant strides to improve it. (For many reasons, this sometimes takes a while…it shouldn't, but it often does.)

    I agree one of the uses of velocity is to derive a Release Plan (or Product Roadmap) for the customer and/or business partner.

    Still, the Team is always removing impediments (and asking management to). The effect of this is that velocity increases *and* the Team maintains sustainable pace (the Team does not work more hours per week). For the simple reason that the removed impediments are no longer slowing the Team down.

    See also Jeff Sutherland's comment above.

    Is this making more sense now?

    ↓
  9. Rob

    Hi Joe,

    If your definition of actual velocity is measured in units of work rather than, say, estimated story points then we agree.

    If you're suggesting that productivity can at all be measured based on estimates before the work is started then we don't 🙂

    If your definition is the former then this is confusing for many as the common use of "velocity" is the one from Scrum which is measured in story points.

    >If the Team really understands velocity in the full context, they won't want to game it.

    The problem is in many contexts this is not the case. Teams are often heavily influenced by external business pressures and "velocity" is so easily manipulated and gamed in these circumstances which is why measuring units of work completed is much more reliable.

    ↓
  10. Joe Little

    Hi Rob,

    Yes, my definition is based on story points.

    You are correct to imply that some teams can't estimate worth a damn. An impediment; it must be fixed. The estimates have to be decent professional estimates, which an equal probability of being high or low. ie, a Normal distribution. With reasonable variances. With a fair number of stories each Sprint. I would agree not all teams are ready to do this one Day 1.

    So, my standard is not perfect accuracy of estimates in advance. As the Romans said: To predict is difficult, particularly of the future. But my standard of prediction is good professional work: and yes, occasionally we get it totally wrong. Even as professionals.

    That does not need to stop the team from using Velocity in its many uses.

    You are right to say management is an impediment. Velocity is one way to get to sustainable pace (yes, in addition, it often feels like some courage is also required).

    I would not give up on Velocity because some people in management are impediments. I would fix management (I am not suggesting this is easy…I am suggesting it often can be done…enough).

    In the typical case, for a number of reasons, management will be more dysfunctional (vis-a-vis the Team) without Velocity than with it. But it takes a smart guy like you to explain it to them about 500 times. Then they will eventually "get it".

    And, of course, not all managers are dysfunctional in this way. (My hypothesis is that all of us are pretty stupid, so the good news is we all have a long way to improve. A long way in improving our velocity, for example.) Just like the rest of us, managers are never perfect either. That does not give us a reason not to use Velocity (well, maybe we don't use it temporarily in extreme cases…but we want to get to it immediately).

    ↓
  11. Bruno

    Hi all,

    By now our management and our client ask us to double velocity quickly on a Scrum project. And what I understand is to double productivity i.e. like Rob said, the number of units of work.

    I dont think either that velocity is a good indicator for productivity.

    In a previous XP project, we attained what we call sometimes hyperproductivity. We did not see velocity growing from, say 10 to 30 or 40. But we saw the units of work done in one iteration growing dramatically. A story that we would have evaluated 13 or 20 six month before, became 3 or 5 at the end of the project. Because of refactorings, debt reduction, continuous improvement, common vision, etc.

    But when you focus hard on improving velocity, you easily fall into the common pitfalls like hirering new resources, or leaving the technical debt, because it slowers the development of functional stories…

    The opposite of what agility is about, bring value to the client, on the long term.

    ↓

Leave a Reply