Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re: Nobody Expects the Agile Imposition (Part VII): Metrics

by sundialsvc4 (Abbot)
on Jul 15, 2014 at 15:00 UTC ( #1093723=note: print w/replies, xml ) Need Help??

in reply to Nobody Expects the Agile Imposition (Part VII): Metrics

A key problem with these metrics is that they come from the world of manufacturing.   In those lines of business, you are performing a repetitive process, with one iteration (and outcome) being independent of all the others, and the process is basically deterministic.   You can trace defects either to the worker, to the materials, or to the line.   Measurements of performance are meaningful and useful; incentives and bonuses might work.   However, none of this is true with software, and for a variety of reasons.

First and foremost, software systems are, as the book puts it, chock-full of “interlocking interdependencies.”   Everything is connected to everything else.   The flap of a butterfly’s wings over here does cause a hurricane over there.   (One of the key take-aways from test-driven development, and therefore one of the reasons to be using it even on your own solo projects, is to see just how easy it is to cause a seemingly-unrelated set of tests to start failing.   You won’t believe it, at first.)

Second, and as the book also mentions, the thing is a machine, which will operate entirely without human intervention and beyond human control.   No one will know or care whether the team that built it was standing up or sitting down, but they damm well will care if it does not work ... perfectly.   It is entirely possible, and frequently the case, that a large block of carefully-measured (and expensive) time will be a 100% sunk-cost.   It is also entirely possible that it will be impossible to predict “how long it will take” to solve a problem, since the part of the problem-iceberg that pokes its head above the water is only a minuscule portion of the actual thing which might be broken or defective ... or inadequately or incompletely designed.

Finally, there is the natural human tendency to want to say, “Naming it will Solve it.™”   Although some of the names we come up with are perfectly nonsensical ... (“Scrum PLOP?”   Really??   What sort of sh*t is that?) ... giving them names or TLA’s (Three-Letter Acronyms) implies that we actually know what we are talking about.   This quickly creates a gigantic credibility-gap.   (“Fool me twice == you’re fired.”)

Another excellent book on this subject is Hollywood Secrets of Project Management Success, by James Persse.   Dr. Persse, who by the way is an excellent and engaging author, was given the seriously-cool opportunity to get behind the scenes in the motion-picture business, which, as he points out, does have a demonstrated track-record of bringing multi-million dollar long-running projects to completion.   Their project management practices have nothing to do with things like “Agile” (although they do employ overlapping, staged delivery).   They seem to be quite inflexible, set in stone, although they aren’t.   It is a scrupulously-repeated multi-stage project life cycle that has been honed to perfection, because it works.   You can “bet a hundred million dollars” on a movie project and be certain that you will get a piece of celluloid, on time, to show for it ... which is a lot more than we can say for software.   (And, don’t say that the two types of projects are incomparable, because, being a software technologist himself, he quite convincingly demonstrates that they are.   There is a lot that we all can learn from this book, as well as from Mechanism.)

Quite honestly, my biggest beef with the Agile loudmouths (ahem ...) is that, while they certainly “talk a good camp,” they can’t show that their processes actually work.   (Which may be one reason why they talk so loud ...)   Yes, there are very good reasons to favor staged-delivery and iterative work cycles, when appropriate, but the actual process of creating “software Mechanisms” is vastly more intricate than their theorizing would allow, and the “fabled outcomes” simply don’t materialize.   Their premises, while filled with some pretty good ideas, are also insufficient.

  • Comment on Re: Nobody Expects the Agile Imposition (Part VII): Metrics

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1093723]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (3)
As of 2021-10-28 03:52 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (95 votes). Check out past polls.