agile, top down

In Agile, Top Down Ron Jeffries has written a compelling article describing how he would introduce agile methods into an organisation, starting from the top.

“There’s a recent thread on the Scrum list about how an executive or highly-placed manager could get Agile going. I’ve been one of those guys, and I know a bit about Agile, and here’s how I’d proceed. First, focus management attention on cyclic delivery of running tested software. Second, provide the resources to learn how to do that.”

Ron’s advice centres on measuring the development department by running tested software – that is, by measuring throughput. I very much like Ron’s advice and approach. But I do see some hurdles…

First, if you’re in a position to dictate that the only measure is throughput, that’s great. But if you’re not, the experience of the TOC and Lean guys is that you’re going to have a really hard time convincing the bean counters – and other senior management, for that matter – that throughput is the right measure. Common sense notwithstanding, this is a cost-accounting world. The only saving grace here is that most software development organisations are too chaotic to count anything, so they likely won’t be already counting the wrong things. (An obvious exception being those departments that are or have been in the grip of Accenture-like consulting practices. But then we’re not likely to try introducing agile top down in one of those places, I guess.)

And second, I would expect that the department’s throughput of software will initially (first three to four months) dip until the running and tested parts of the equation are working effectively. Because testing everything, and fixing all of the defects before they go out the door, costs. The investment will eventually be repaid many times over in terms of predictability, trust and speed, but it is an investment nonetheless.

I still think Ron has it right – just don’t expect an easy time of it for the first few months.

Update, 1 aug 05
Discussion with Jason (in the comments on this post) leads me to understand that the choice of metric is critical. In the article, Ron was explicitly and implicitly referring to his own metric, running tested features.

the taxi business

I just had a project cancelled, because the business features it would have introduced are not sufficiently high priority right now. I’m fine with that approach. (It may be re-awakened in 6-12 months, if there’s enough money and interest.) Fortunately it was still in its infancy, so not much money has been spent on the wrong thing. Apparently. But as with everything else in this very strange organisation, when taken with the prevailing cost-accounting culture this decision may prove to be short-sighted. Let me explain…

Every project here is costed separately, and each is also judged separately for its revenue-earning ability. So infrastructure projects rarely occur; instead, the first project that needs to change the prevailing infrastructure / architecture gets to pay for that change. As one of the designers on my project put it: “The first person who needs to go somewhere buys a taxi; everyone else then gets a free ride.”

Now my project was going to be putting in place a whole raft of new infrastructure. In many respects it was seen by the techies as heralding a new dawn. And now it’s gone. And so has the taxi for all of those passengers who had planned to hitch a free ride in the next 12 months. Now they have to develop that infrastructure themselves. And pay for it. And instead of being co-ordinated by one team of designers, it will now be done in disjoint chunks, probably leading to overlap and conflict. So their costs will go up and their timescales will lengthen. The overall cost increase may well be greater than it would have cost me to buy the taxi.

So yet again, localised measures prove to be very expensive and wasteful when compared against more global measures; there has to be a better way… What would a lean manufacturing organisation do? Suppose we have a factory in which various products share the facilities; would each product carry its own production costs? What if a machine needed to be upgraded – would we charge that to the first product that needed the upgraded machine? I’m sure the Theory of Constraints muct have something to say here…

business automation gone wrong

To my mind, software exists in order to automate (parts of) the business process. But that simple idea seems to have been forgotten by some of the designers here…

I’ve temporarily joined a project whose purpose is to remove a manual step in a data transfer process, thus ensuring that the relevant users always have correct and complete data to hand when they need it. The new design does indeed achieve that goal. But somewhere during the design phase (yes, I know) two groups of people somehow failed to communicate clearly. And the resulting design therefore includes a manual step that’s harder to perform than the one they’ve eliminated!

What’s really funny is that this design will be measured as a success by the business. Because although the staff costs associated with running the affected business process are unchanged, the new design allows an old database to be de-commissioned. So several tens of thousands of pounds have been spent, in order to save a few thousand in annual maintenance costs, in support of a delivered value that hasn’t increased.

Am I becoming a ‘throughput’ maven…?

cost accounting

I’ve said it before, but I’ve seen it so many times in the last two weeks that I just have to get it off my chest again: measuring the benefits of a software project in terms of reduced staff costs or man-days is an error. As an accounting practice, it confuses the cost of a resource with the value of the things it produces.

This is one of the areas in which Taiichi Ohno and Eli Goldratt are in striking agreement. And yet in an organisation like the one where I’m currently working, cost accounting is deeply institutionalised, to the point that even the programmers have been infected. Unfortunately my projects are going to be measured in the same way…