A number of months ago I wrote an article for IASA on Velocity for the ITaBoK. You can find the article here. It really got me thinking about what velocity really is. A high velocity is certainly a desirable outcome in any organization, and a good IT-architecture should facilitate velocity.
So how do we measure velocity? I notice that in many organizations using agile practices, that velocity is measure by the rate at which you get things done. However, this only measures the speed at which the team can work, essentially measuring throughput.
“Speed is the time rate at which an object is moving along a path, while velocity is the rate and direction of an object’s movement.”, Britannica, What’s the difference between speed and velocity?
The significant factor with velocity is that it is both rate and direction. In terms of software development, velocity becomes a much more interesting measurement if we consider the travel towards value delivery as the direction.
A problem with measuring speed, or the rate at which you get things done, is that there is no guarantee that the work which is being completed adds any value. For example, if we run several sprints with lots of refactoring, re-design or bug fixes, this can give the impression that the team is working really well doing a lot of work, but in fact there is little value being delivered.
If we instead measure only the outcome of completed work which adds value, and we can see the rate of value delivered from the team. This can help identify problems early before teams start speeding off fast in the wrong direction, for whatever reason, re-design issues, technical debt, major refactoring or architectural issues. This type of velocity gives a completely different perspective for the business.
Of course, the business has to define what it considers as value. Then it is possible to compare velocity with throughput, this will give an idea of how much work is non-value. This is not to say that the non-value work doesn’t need to be done, it is often required to recover from bad decisions, technical debt, design problems, etc… In fact, it may well be intentional, since in some cases technical debt is accepted in order to meet a deadline, in the understanding, that velocity will be sacrificed at a later date when the technical debt needs fixing. Using velocity in this context provides a great indicator of value delivery. This can help businesses identify potential problem areas, act early to fix problems and reduce waste.
Architecturality 