Acceleration, schmeleration. Scott Ambler misses the point...

Through this post on InfoQ I learned that Scott Ambler is writing about productivity in Agile and how to measure it. He comes up with an interesting concept, that of acceleration.

Anyone familiar with statistical process control knows that a process does not have "acceleration" by itself. A process is either under statistic process control (ie churning out about the same amount of output per unit of time, within an acceptable variation) or it is not (ie the output is not reliable).

If a process's output is changing outside the control limits (ie not in statistical process control that actually means that the process is not under statistic process control. When that happens it is due to either one of two:

• Common cause - This is a cause that is known and happens repeatedly (e.g. accumulated technical debt in a way that can be anticipated).
  
• Special cause - Something totally out of left field that cannot be predicted.

If the velocity of the team is decreasing constantly (to the point that you can measure acceleration as Scott proposes) then you are in the presence of a common cause (ie predictable cause that impacts velocity). If that is the case you know that it's not the team that is to blame, it is the system in which the team is working that is causing the decreased velocity.

Scott misses the point completely, when it comes to processes, if you can "predict" the acceleration in velocity then you can do something about it. However, you do have to work at it, you need to investigate the systemic causes for the velocity to decrease and identify the root cause that, being solved, can change the system's behavior. This is not necessarily easy or quick...

In practice this means that every single team out there can improve their productivity (and should) by looking at their velocity, seeing if it is within the statistic control limits and acting on it. If the velocity is in control (as in statistic control) you can improve it by changing the process (the whole process, not just the team's sprint-process). If your velocity is not in control then you need to eliminate the "special causes".

What does this all mean? It means that instead of selling the idea of
"pricing" velocity increases for an Agile team (or any other team) Scott should be trying to tell people about the consequences of actually knowing whether your velocity is increasing/decreasing or it is stable.


Here's what really matters:

• If your velocity is stable (in control) the only way to improve it is to change the process (do a proper retrospective, identify root causes and then act -- the old PDCA). Remember that the "whole" process influences the team's velocity, not just what you do within a sprint (requirements, production, etc. should be looked at also).
  
• If your velocity is not stable (not in control) then you should start by analyzing the reasons for it's oscillation and start solving those. These tend to be random events that happen in an unpredictable fashion (e.g. a developer forgot to submit one change to the VCS before testing started).