Extreme Enthusiasm

Two months ago I re-started a freelance career. Now I have a new coaching engagement that I’m very happy about. One interesting thing that I learned in the past few weeks is that I had a fundamental misconception about the idea of velocity. I think that this misconception is common, so I will tell you about it.

You know what velocity is: it’s a very important number that measures how much a team has accomplished in the past iterations. When an iteration is finished, you add up the estimates of all the user stories that are done-done. That is your velocity.

There is a common misconception about velocity, that it can be used to compare teams or to reward/punish the team. This is a well-known and well-documented error, because doing so will push the team to game the metric and destroy its usefulness.

But it is not that error I want to talk about; it’s a more subtle one. You know, ever since I learned about XP, I always thought that the goal of an XP team is to maximize velocity. That is, to deliver as much as possible, while keeping the system clean and well tested and so on.

This is an error. You don’t want to maximize velocity. Your goal is to stabilize velocity. What you want is to deliver about the same velocity in each iteration; and the way to obtain this is to add slack; make sure that if the estimates are correct, you will end the iteration with ample extra time. The team will *not* use the extra time to deliver one more story; they will use it to reduce technical debt, to clean the system, to improve the tests, to study, to perform technical improvements, and so on.

This is a very counter-intuitive thing, yet I now understand that if you don’t use slack to keep the velocity stable, it’s very difficult to achieve the goal of keeping the cost of change down. Thanks to James Shore for the video of his presentation We Deliver Business Value at the NDC2011 conference. The concept is also well explained in Shore and Warden’s book.

Another quote:

The Product Owners look at slack as a way to evaluate whether the team is overloaded–and seek to reduce velocity until we hit slack consistently. Otherwise, we fear we’ll be paying for code debt, bug fixes, and reduced innovation that the team can’t really see until they come up for air.
André Dhondt

Also, a fundamental principle in Lean is that before you try to optimize you should stabilize: reduce variation in the output.

Now you know it!

I read this in Mark Seemann’s blog:

Most of the classic design patterns are based upon the idea of programming to an interface instead of a concrete class. In OOD, it’s necessary to point this out as a piece of explicit advice because the default in OOD is to program against a concrete class.

That’s not the case in FP because functions can be composed as long as their signatures are compatible. Loose coupling is, so to speak, baked into the paradigm.

This is nonsense. The fact that functions can be composed as long as their signatures are compatible does not imply that the functions you compose are loosely coupled. In FP you can easily write functions that depend on the concrete way that information is represented. Changes in how a function returns data may break other functions down the road. I would say that in fact the opposite is true: the main danger of FP is that concrete representations are passed around all the time. At least this much can be said about OO, that OO pushes towards encapsulation of data representations. This is “baked into” the OO paradigm.

Look, I fully agree that FP is great. But how much of this new enthusiasm for FP is due to FP being a new thing (at least to these new converts?) People trying FP now did not have the time to write spectacularly bad systems with FP. Yet. Then what? We’ll be praising Logic Programming over FP? Me, I’d rather spend my time learning to use one paradigm *well*.