|XP is just a number|
/me nods ...
“You’re over-thinking this thing,” he muttered, thinking about the book, Cheaper By The Dozen. (A hilarious book by the daughter of an early process-management consultant ...)
Fundamentally, the writing of computer software has to do only with the success or the failure of the computer software to fulfill the purpose for which it was written. Infrequently, the cause is programmer incompetence. Usually, it’s because people are not-working together on a project that has never been completely specified in the first place. And they’re not continually testing what they have done, to know if it actually works and keeps working. In other words, yellow-stickies or not, it’s hopeless. Whether or not you are measuring “progress,” the project’s taking one step forward and two steps back. You measure time that is being profoundly wasted.
The best idea I ever had, a couple decades ago now, was to base things on a contractually binding task-order and change-order system ... and to make task-order #1 (and beyond) consist of building the remaining task breakdown. Charging the same money to do that, or more, than for building code. It’s modeled after the construction trades, and it works. If you systematically embrace all of the best-practices that are involved (start to finish ...) in constructing a building or a roadway, and apply these to software ... it works like nothing else does. (A project to repair the potholes in 100 feet of bad-condition street might consist of more than 250 line-items and accumulate the data points of more than 1,000 tests. They leave zero, nada, nothing, zilch to chance or “creativity.”)
The usual practice ... and Agile encourages it ... is for people to be “lone wolves, in a pack.” They forget that they are building a machine, that will work entirely without human intervention.(*) The process they use is the same one they used in school ... at 11:30 PM the night before the assignment was due. They’re frankly entirely accustomed to “pantsing it,” with only a token nod to planning, and no more of a nod to communication than will fit on a 2" x 4" yellow piece of paper. Almost invariably, one person will be tasked with devising and writing the code for some feature, and for telling the rest of the “team” what s/he did after the fact. I don’t know why this is so, but I’ve seen it in far too many teams to think of it as accidental.
So, what you really need isn’t “metrics” at all, in the sense of lines-of-code, hours-worked and what-not ... except possibly for cost accounting. You don’t need to measure what your programmers are doing. Instead, you need to be checking-off their progress along a meticulously-prepared punch list, cleanly separating the process of “deciding what to do and when to do it” from “what the source-code writers are doing.” It doesn’t matter if folks are standing up or sitting down. If the plan is good and complete, the work will go according to plan. (And, yes, that plan should called for staged delivery and for overlapping threads of progress.) If the work has been spelled out sufficiently, the writing and testing of the corresponding source code is ... perfunctory. And the resulting code will be damned near bulletproof. If you measure anything at all, it should be the on- or off-schedule progress of the machine that is being constructed day-by-day.
(*) The best book that spells out that idea very completely, from a project-management point of view, is a little Kindle-only book called Managing the Mechanism, by Vincent North, which is available [only ...] on Amazon. Find it, read it.