Most Agile methodologies I have tried, read about, etc... include the concept of Velocity. Velocity essentially is a historical measurement of the rate at which a software team produces value. I am currently reading Agile Management for Software Engineering by David Anderson. I believe the term he uses to describe the philosophy of using velocity to predict future output is Empirical Process Control. I haven't finished the book yet, but as I was thinking about empirical process control and velocity in the context of Lean and the Theory of Constraints I had the thought that I have been looking at velocity all wrong.
The teams I have been a part of have generally looked at velocity in one of two ways, either it was the measure of how many work items went from Resolved to Closed (meaning that QA successfully completed testing them) or it was how many went from Active to Resolved (meaning that Dev finished coding and unit testing and was ready for the feature to be run through QA). When reexamining that strategy in the light of Lean and Theory of Constraints we actually should have been measuring velocity for both of those functions (QA and Dev). Theory of Constraints is all about identifying the bottleneck and managing your input into the system to make sure you 1. Feed the Constraint as effectively as possible (don't let it run dry) and 2. Manage inventory so you don't overload the pipeline with excess inventory.
Before diving into how and why you would measure velocity at different points perhaps a little aside into the dangers of excess inventory is in order. Say for example Developer Tom finishes Story A and marks it as Resolved so that it moves into Tester Tim's queue to QA Tom's work. Tim is currently the constraint in the system so work is piling up in front of him. He isn't able to QA Tom's work for a week. Tom of course doesn't sit around for that week and he moves on to a new story. A week later Tim discovers that something isn't working right with the feature Tom completed and reactivates it. Now several bad things happen as a result of the delay - the work Tom did on Story A is no longer fresh on his mind and so he has to spend time spinning up on it again. The work he started on the new story gets interrupted and he will have to take some time to reacquaint himself with it when he finishes the rework on Story A. Additionally we measured velocity by how how much the Devs marked as Resolved and so the previous week we reported X number of story points completed when due to the rework on Story A it was only X minus the number of Story Points for A. We have a mess on our hands.
Now you can't eliminate rework in the system no matter how hard you try. QA will identify issues with the code Dev delivers and Devs will find issues with the story details delivered to them by the Analysts or Customers, etc... By reducing the excess inventory in the system and managing to the constraint you can reduce the cost of the context switch that the rework incurs. In our situation Tim is the bottleneck and we shouldn't keep piling up inventory on his doorstep. We need to slow the cadence of the development line to match his production. With the excess time in other queues you look how you can leverage them in the meantime perhaps developers use it for training or if excessive enough leverage them on a different project.
In order to manage all this we need to measure the velocity at each queue in the process (a queue being Dev, Test, Requirements Generation and Development, etc...). When we do that we can then look at the software process, identify the constraint, and then work the constraint to improve it if improving the constraint makes business sense. If for example development is the constraint, at some point you hit the Law of Diminishing Returns where adding more devs or improving their productivity is more costly than the resultant throughput improvement. Measuring throughput at the different queue levels is critical if you want to be able to accurate assess the health of your development efforts.
I think of Agile Management as Active Management or perhaps even better Proactive Management. An Agile Project Manager is actively engaged in analyzing the system and determining where improvement is needed. In so doing he is much more effective than the project manager that runs around checking with everyone if they are still on track with what the Gantt Chart says.
Metrics are certainly an important part of the Agile Management process. The metrics considered important by Agile/Lean are certainly differently than the ones historically used by standard methodologies, but still critical to guiding projects successfully.
