|The stupid question is the question not asked|
"Bah! Scrumbug!" (Lessons from the scrap-bin)by sundialsvc4 (Abbot)
|on Dec 14, 2010 at 18:33 UTC||Need Help??|
One thing about being a data-processing consultant: it gets you an inside look at a lot of interesting businesses. One of the most interesting was a precision, exotic-metals machine shop. (They make jet-engine mounts for Boeing ... and ... other things.)
Although the operation is pretty-much all CNC-driven, for obvious reasons, I still noticed that there was a wooden bin next to each machine, labeled: Scrap. Along with a sign that said, “Please do not have to put anything in here.”
With all the “scrum” talk around here lately, well, that got me thinking ...
The project that I had done for that shop was scrap-accounting. Every part, every piece of metal, was uniquely identified, and every operation applied to it was tracked, with every minute of both machine-time and labor-time scrupulously recorded. All of that time was billable to the client ... until and unless the part wound up in that bin.
At that point, all financial hell broke loose.
The impact of “scrap” was absolutely huge, because it not only meant that the entire value of the part or component was lost, but that a specified number of operations would have to be re-done ... and the schedule for delivery would necessarily slip. Some of these metals are considerably more expensive than 24 karat gold. The neatly penciled admonition at the bottom of the sign was hardly an idle entreaty.
In our work, where is there any accounting for all of the “pure scrap” that we produce? The false starts. The consequences of “don’t just stand there... do something!” can be huge.
Perhaps the “scrap rate” is the actual metric that we should be infatuating about. And we might be able to obtain such a metric right from our version-control system logs. Look at the total “surface area” of a source-file that gets changed over time. Particularly observe when a large chunk of code is first added, then either replaced or extensively modified a short time later. If there is a defect-tracking system, try to correlate this “source-code volatility metric” with those defects. Do the same thing with the activity that is being generated by the “scrums.”
If it turns out that the work-product of “all that frenetic activity, decided upon in 15-minute-exactly meetings,” actually sticks, then we can pat ourselves on the back as being successful. But if the source-code volatility is high and remains high, we have a problem... “one step forward, two steps back.”
(I do not mean to suggest that this metric can “just be mechanically obtained.” If it could be so easily metered, the meter would have been invented years ago ... by a millionaire.)
I am, as you undoubtedly have guessed, deeply suspicious of “silver bullets,” because, even though all of them are (of course) laden with success-stories, I have never yet encountered a single one that worked. But I have done a lot of post-mortem evaluations of projects that, sure enough, were being led by teams that had earnestly pledged fealty to the latest bullet-bearer. There is a problem here, and, if I may suggest, I may even have an inkling of what that problem is.
“Silver bullet” strategies measure what is easy to measure: the chip log of the project. That is, “miles run over the sea.” But do they measure “miles to destination?” Generally not. Why? Because they (more or less...) insist that one does not yet know where the destination actually is; nor (and here is the fatal flaw) that it is necessary to know this in advance. (“Just set sail. We’ll figure it out as we go.”) (Blink...)
A measurement of source-code volatility, taken directly from the daily commits to the source-code control system, of course will not tell you how close to the target the team actually is, but it will give you a practical measure of just how confident the goal is. If the team knows where it’s going, and is actually moving steadily in that appointed direction, then you will see it. If large chunks of software are being put in and then taken out, then put in and taken out, then you will also see that.
As with the exotic-metals machine shop, the things that really devastate a project are the things that wind up in the scrap bin. You will never here anyone in such an outfit say, “we’ll meet for exactly fifteen minutes, then we’re going to spend the rest of the day cutting metal, because cutting metal is what we do!” But ... how often do we hear exactly that from whatever industry-pundit has caught management’s attention this year? ...
Scrap. It’s supposed to be a reprehensible word. It’s supposed to be a word that conjures-up pictures of a flush-toilet with gold coins being dumped into it, never to be seen again. And in the software development industries, we happen to produce huge amounts of it, apparently with no accounting at all. Maybe that is part of our problem.