My friend Peter (@keksz_i on twitter) wrote another great post, and this time about the velocity.
Sensitive Velocity
The Scrum team velocity is an interesting thing. It is very hard to get a working velocity number, it takes a long time, lots of tries, lots of failed sprints. When the team finally get a stable velocity that always can deliver, than everybody is happy. The team is happy, the customer is happy so the management is happy as well. After a time this velocity will become convenient for the team and it might turn into the source of a problem, a bottleneck for performance improvement.
The team velocity is not really changing. It is very hard to change it and it changes very slowly. No one really dares touching it, the team is used to the velocity number which by now might become a convenient amount of work to do, and the customer is satisfied also with the constant and reliable delivery. Why to change it than? There is no really motivation and there is always a risk increasing the velocity even if the team feels they can handle more. Instead of creating more value, the team will spend the gained extra time (from more efficient work) on other unimportant things, they may work slower, they will become less effective. Increasing the velocity can be done only by forcing it, which can be painful. I know that Scrum is about predictability, but than what about the improvements?
In Kanban, as the team works more and more efficient, the team velocity increases as well automatically! They are not tied to iterations, the team continuously delivers items, not just at the end of the iterations. The Kanban team’s performance measurement is the lead time and cycle time, which comes weekly. These values are automatically increasing if the team produces more, but sure it can be decreasing as well. Why to bound the team with iterations? Let the team evolve by continuous development and feedback, do Kaizen.
comments powered by Disqus