Why we are trying for 0 velocity

OK, the title of this post is a bit misleading. What I will be trying to show in this article is that our velocity actually is 0 and we are simply trying to bring attention to that.

I have a feeling we are going to ruffle some feathers with this one, so I am writing this blog post to try to explain our motivations for doing this.

One of Scrum’s most important concepts is that of ”Done”. The idea of things being truly shippable, or shipped, when they are done is central to the success of Scrum teams.

The is because all work we do is an investment, but only ”Done” things deliver value. In most companies value is delivered when things reach the end user, when someone is actually willing to pay for our product. Everything that happens before that point is an investment in the hopes of receiving that value.

full_flow(In this example each part of the process takes 2 hours to do)

This is less of a problem in teams that are responsible for their work all the way to the customer, as in the example snapshot of a Kanban board above. The team can easily follow the flow of items and know that the thing furthest down the line is where the most time has been invested, and therefore the most worth spending the remaining effort.

The problem appears when teams hand over to other teams. They consider their work done, but there is still work remaining before the value can be realised. And the problems increase, if, for example, an acceptance test for an item is longer than development or testing. See the example snapshot below.

broken_flow

(In this example acceptance testing take 3 hours to do)

In this case, things start to pile up for the ops team, because the other teams continue to invest in other things. Since no one is responsible for anything but their piece of the puzzle, we have no incentive to improve the slower part of the process, only our own part. This actually results in the creation of more and more un-done work, more investment with no value realised. But we keep thinking we are doing a great job because we are getting faster and faster, but really the best use of our efforts would be to improve the acceptance testing, so we can realise more value (earn more money).

To make the most of our investment, every piece of the process needs to flow smoothly, not just our piece. This goes for all types of work –  idea generation, sales, development, testing, deployment, etc…

It doesn’t matter how many deals we can make, if we can’t deliver them. It doesn’t matter how much software we can build if we can’t sell it.

Velocity is a measure of our ability to deliver value, not time invested. By agreeing that we don’t ”get points” until things are in production we are hoping to bring more visibility to this. It may feel bad for a while, as our managers will see we have a velocity of 0, but really we had that all along – we were just hiding the problem.

And it’s the best thing to do for the company as a whole!

P.S: There are a whole bunch of other negative effects as well, like un-done work not actually being a linear growth, but I wanted to keep this example simple.