See Part 1, in which we present a deep truth about velocity and story points. A's team has turned in two sprints, with velocity of 19 on the first and 23 on the second.
There is a primary truth being described here, and that is that velocity is not a knob that one can turn. I addressed that previously in another blog post, some time ago.
Velocity does not raise because people try harder. If that were so, it would be because people were (until now) withholding their productivity and waiting for you to ask for it. It's unlikely, but if it were so then one would have to wonder why they had been withholding; what system of work required them to make such an adaptation.
When raising the velocity is given as a task, a team will usually inflate the estimates to bring up the points, or award points for every activity in order to bring the number up.
This brings to mind the Hawthorne Effect, Goodhart's Law, Campbell's law, and (most upsettingly) the Cobra Effect.
It doesn't raise due to changing the unit of measurement to days, hours, minutes, points, lollypops, NUTs, etc.
About the same amount of energy is expended from week to week and from day to day, and things take however long they take. Needing more doesn't make the work any easier or faster.
However, notice the line I italicized, above. The people in the hypothetical conversation gloss over this line and don't return to it for a while, but it's there.
Here is something S.R. Covey said about making it easier to get work done:
I view it as effort provided over effort required.
If the fraction equals 1, then you were effective in getting the job done. But at what cost? If we have work that requires a lot of effort, then we can only accomplish it by putting a lot of force toward getting that thing done...
... wait. That's not true.
The other alternative is to reduce the amount of effort required by the work, and then we can complete it easily.
Increasing effort doesn't scale, and doesn't sustain. It is a great way to lose people.
Decreasing difficulty of work scales like crazy, sustains effortlessly.
So, if we want more work done we need to stop messing with the measurements and demanding more effort from our hard-working people and, instead, work on reducing the difficulty of getting work done.
Most software organizations have policies and practices and flows which seem purpose-built to slow and prevent the release of software. There are queues and wastes at every turn and most of them outside of software development. Easly 90% of most policies are preventative. Few provide acceleration or support.
So if we are focused only on raising the top number, we're likely to defeat ourselves.
Managers should take some time to read John Gall's The Systems Bible, which tells us two things of note:
See you in Part III.
A: Okay, but my next sprint needs to be 30 points.
B: What has changed to make a point be 1/30th of a sprint?
A: We just need it to be.
B: Then improve something significantly so it becomes possible.
A: Can we just try harder?
B: There is no evidence that works.
A: Then story points aren't useful.
B: We could have started with that agreement.
A: Let's use real hours then!
B: Not better.
There is a primary truth being described here, and that is that velocity is not a knob that one can turn. I addressed that previously in another blog post, some time ago.
Velocity does not raise because people try harder. If that were so, it would be because people were (until now) withholding their productivity and waiting for you to ask for it. It's unlikely, but if it were so then one would have to wonder why they had been withholding; what system of work required them to make such an adaptation.
When raising the velocity is given as a task, a team will usually inflate the estimates to bring up the points, or award points for every activity in order to bring the number up.
This brings to mind the Hawthorne Effect, Goodhart's Law, Campbell's law, and (most upsettingly) the Cobra Effect.
It doesn't raise due to changing the unit of measurement to days, hours, minutes, points, lollypops, NUTs, etc.
About the same amount of energy is expended from week to week and from day to day, and things take however long they take. Needing more doesn't make the work any easier or faster.
However, notice the line I italicized, above. The people in the hypothetical conversation gloss over this line and don't return to it for a while, but it's there.
Here is something S.R. Covey said about making it easier to get work done:
I view it as effort provided over effort required.
If the fraction equals 1, then you were effective in getting the job done. But at what cost? If we have work that requires a lot of effort, then we can only accomplish it by putting a lot of force toward getting that thing done...
... wait. That's not true.
The other alternative is to reduce the amount of effort required by the work, and then we can complete it easily.
Increasing effort doesn't scale, and doesn't sustain. It is a great way to lose people.
Decreasing difficulty of work scales like crazy, sustains effortlessly.
So, if we want more work done we need to stop messing with the measurements and demanding more effort from our hard-working people and, instead, work on reducing the difficulty of getting work done.
Most software organizations have policies and practices and flows which seem purpose-built to slow and prevent the release of software. There are queues and wastes at every turn and most of them outside of software development. Easly 90% of most policies are preventative. Few provide acceleration or support.
So if we are focused only on raising the top number, we're likely to defeat ourselves.
Managers should take some time to read John Gall's The Systems Bible, which tells us two things of note:
- Human systems run at around 5% efficiency
- Systems tend to oppose their own best function
See you in Part III.
No comments:
Post a Comment