Print

We ♥ Tools

19 Mar, 2008

Commentary on The Art of Agile Development's Informative Workspace practice.

We just love our tools, don't we?

figure

Risk-adjusted burn-up chart

One of the neat charts Shane and I invented* for The Art of Agile Development is the risk-adjusted burn-up chart (shown at right, and discussed on p.228 of the book). It's a very nice, information-rich display that shows you what you've accomplished and what you can likely achieve, and when. Exactly the kind of chart you want in your informative workspace.

*Based on Phil Goodwin's burn-up charts, which are in turn a variant of Scrum's burn-down charts. Nothing is truly original, is it?

I showed this chart to some people a few weeks ago, and the question kept coming up: "How do we create this chart?" I was a bit confused. I had just sketched out the chart and described how you update it each iteration, and my questioners were bright people who had clearly understood the explanation. At a loss, I offered what I thought were helpful tips. "Well, get a big yardstick and measure out a grid, then use the yardstick as a straightedge to draw the grid with a wet-erase marker on your whiteboard. Then you can use a dry-erase marker to draw the graph and the grid will stay even when you erase it. Then, every iteration..."

I later realized that I had misunderstood the question. They weren't asking, "How do we create this chart on the whiteboard?" That's obvious--a child knows how to use pen and paper. They were asking, "How do we create this chart on the computer?"

Well, there's the rub. You can't--at least, not easily. It's a brand-new way of visualizing the data, and no tool out there, at the time of this writing, knows how to create it.

* * *

We just love our tools.

But why? Computers are limiting. They make some things easy, sure. But only at the expense of making some things impossible... or at least, very difficult. How long would it take your team to reprogram Excel to support the risk-adjusted burn-up chart? You don't even have the source code. And even if it only took your team a day, that's more time than you're likely to spend in years of drawing these charts by hand. It takes one person about five minutes, once per week, to update this chart... and it only takes that long if he's dazed out on caffeine, has a broken wrist, and a small child is jumping up and down on his foot.

Even worse, we constrain our thinking to the limited capabilities our computers offer us. Changing the computers' workflow, or built-in diagramming tools, is so painful that we don't even consider it. The same programming that makes computers so efficient at automating the familiar makes the unfamiliar impossible for us to conceive.

I'll close with some quotes from Richard Semler's Maverick, the story of how he transformed Semco, a Brazilian manufacturing company. These quotes are from pages 111-116.

I remember a tour I took of the information system at the Ipiranga plant while I was working there... I spent three and a half hours with Wilmar. I saw how the stainless steel arm was ordered by computer, how raw material was set aside--if available--or reordered. How the ordering procedure required three different quotes. How the winning bid was decided by weighing statistical data on delivery, price point ratios, and payment terms. How inventory items were divided into categories by weight, cost, and the space they took up in a storeroom. How the nuts and washers that held the arm together were made from steel plates that were stocked in the yard and then moved by the computer through seven different areas of the factory and three production procedures--cutting, hole boring, and welding.

What a hard way to make money!

I'm sure the people who devised the system envisioned an automated, machine-managed plant where steel plates were gracefully eased through the rear door and elegantly crated dishwashers rolled out the front. Except it never happens that way. I've never been to a plant that doesn't have too many nuts for too few bolts, or shelves of some part for a product it no longer makes. Even in [machine-managed] plants that function tolerably well, workers become servants to the Production Dragon, which is fed tons of parts and spits out finished products. This Dragon only smiles when people don't mess with it, or for God's sake, try a new way of doing things.

I once visited a small unit of ours three days before the end of the month.

"What do you think this month's billings will be?" I innocently asked the resident computer wonk.

"We already know. We have the number here, in the terminal."

"How can you? There are still three days left in the month."

"Oh, no. We stop billing four working days before the end of the month."

I was shocked. It meant inventory was tied up longer than it had to be, increasing interest costs, and orders would sit for days before leaving the plant, increasing customer frustration. Just picture Federal Express stopping for a few days each month to feed paperwork to its computers.

[I asked,] "How did you do all this in the past?"

"Oh, that was very primitive. We would wait until the last minute, then type out the invoice. Sometimes we would be here in the middle of the night, getting invoicing out of the way, to make the month's sales larger."

"How many invoices did you issue then?"

"About 150."

"And now?"

"About 120."

Two days later the unit was off the computer and back on the primitive, manual system. And soon invoicing rose 15 percent, as employees got back to making last-minute shipments in all-out efforts to move finished products out the door. And within a month all the other computer terminals at our business units had been returned to headquarters, and our mainframe there was disconnected. We no longer have all those programmers or keypunch operators; we have dismantled our information systems department and thrown out our systems master plan. We gave all our techies an opportunity to make a living elsewhere and sighed as we sat back and relaxed. In typical Semco fashion, whoever decides he needs a computer goes out and buys one... It's every microprocessor for itself and to hell with the economies of scale.

Some things are well worth automating. We are in the software business, after all. But unless your process is standardized and predictable--and no software development process is, or can be--automation is premature. Stop being a slave to the software. Toss those tools, and unleash your creativity.