Forget Velocity ??!!!
OK, this article here (J. B. Rainsberger, Forget Velocity) is at least thought provoking.
Forget Velocity?! What an apocalypse if that is true!
Are we all bothering ourselves years now with useless measurements and artifacts?
Well, this guy here builds a case against velocity as a tool on the grounds that past and future estimation data are of no real value compared to retrospective analysis of actual work time. He also uses as proof to his theory an analogy to a personal finance story of his, and the way that past actual expense analysis helped him to overcome his financial problems, compared to any planned estimation approach which would not have the same results.
Interestingly enough, my previous post implies quite the opposite. I say “Forget Actuals” and “Use Velocity” in the statistical way I thing it should be used.
For more than one reasons I think that I am standing on the right side (of course I would suffer from Schizophrenia if I didn’t).
IMHO there is no analogy between SD and personal finance that one can use to get to any useful conclusion. So, I think it’s quite irrelevant and a wrong ground to base such an important theory.
First of all, it’s a matter of target. Eliminating wasted time (in analogy with eliminating wasted money) should not be a real problem in an agile team, as the process itself (continuous reprioritizing and interaction between the product and iteration logs) should have taken care of that.
In my mind, velocity is process tool, not a financial index (and it’s unfair to judge based on the accuracy such an index should have).
Summarizing, if and when the target is:
- having a metric that could help you forecast in the mid-long term
- having a tool to quickly visualize development pace add help your team commit to a steady one (I strongly believe that steady development pace is one of the most important goals every team should struggle to achieve)
then velocity is a critically valuable tool which should be praised, not forgotten.
Stavros, you write, “Eliminating wasted time (in analogy with eliminating wasted money) should not be a real problem in an agile team, as the process itself (continuous reprioritizing and interaction between the product and iteration logs) should have taken care of that.”
I still haven’t worked with a single team that behaves this way. They all expend tremendous energy (time, money, effort) arguing about these things:
1. “I want to count story X as a done so we can score the points; we’ve done our part.”
2. “You guys can do 23 points this iteration, right? We really need you.”
3. “Why hasn’t your velocity increased over the last four iterations. This agile thing is supposed to make you go faster, right?”
I can list more, but that will do for the moment. This is what I see happening out there, everywhere I go. These teams paralyze themselves trying to use velocity to plan, when they’re so messed up that they waste energy arguing over velocity issues that they could use to deliver more features.
That’s why I want them to forget velocity. It gets in their way. The analogy is simply a way to explain it, and it’s apt precisely because most teams don’t already know how to avoid wasteful work (wasteful spending). Budgets work when you don’t spend wastefully, but most people waste their money. Velocity might work for teams that don’t waste their energy, but most teams waste a lot of it.
@J. B. Rainsberger
OK, I get your point now.
And I think you are right, given the circumstances in the teams you describe.
On the other hand, if the team and/or the organization have not clarified the difference between estimation and commitment or fail to understand that the agile methodology has nothing to do with the classic performance measurement approach, then there is a major misconception that takes place.
If, moreover, there is a general failure in prioritizing that keeps low value things get done and high value ones stay constantly behind, then the problem is even bigger.
Given this context, there is no doubt that applying tools and techniques like velocity could bring the opposite results. But one should keep in mind that this failure is the symptom and not the cause of the real problem.
With this perspective, I think the essence lies in the four words “for the time being” you use in the last paragraph of your article. So it’s more like “put aside” than “forget” from my point of view. Put it aside, if it does you harm rather than good, work on your team maturity (agile-wise) and its interaction with the entire organization, and use it when you know you will benefit from the power of its simplicity.