use spikes to manage technical risk

At the AgileNorth meeting on Monday of this week we recapped an old discussion about technical risk. Some months ago Phran Ryder had raised the question of how to prioritise stories during release planning. I have always held out for business value as the only factor to consider. Phran however insisted that his project was different, and that technical risk was more important. The topic came up again this week, and this time Phran was able to provide a very succinct explication of how we resolved the issue.

The dilemma is this: In order to deliver maximum value under all possible outcomes, we should prioritise our stories solely on the basis of their value as perceived by the Customer. But what if we can’t assess that value, or estimate the stories, in advance? What if we need to bring some stories forward to the front of the schedule, so that by doing them we gain further information to help us create the remainder of the plan?

Here’s a quick attempt at a conflict cloud:


(I’m not too pleased with this – please help if you can think of a better formulation of the dilemma.)

We resolved the dilemma by attacking the necessary condition at bottom-right in the diagram: we reminded ourselves that implementing a story isn’t the best way to obtain information about when to implement it! That’s the job of a spike (a throw-away prototype). We should do just enough work to obtain the information we need about the story. Just enough to put us in a position to correctly prioritise or estimate it and get on with planning the release. (At this point we must also throw away the spike code. Because the odds are very good that the world will be a different place when the spiked story comes to the top of the pile. If we kept the spike, it would likely require learning and re-work to fit into the new and growing system at that time. Best to just ditch it now and start afresh when the customer really needs it.)

using the TOC thinking tools

I recently had a conversation with Jim Bowles, a Theory of Constraints (TOC) consultant who has been helping out on the TOCSoftware Yahoo group. He was helping me to understand the conflicts within the cost-accounting culture in a large organisation I’m working with. I’ll report more on that conversation in due course. For the moment, I was impressed by how he was able to focus my rambling misgivings by using the TOC thinking tools.

In particular he encouraged me to try expressing my issues in terms of evaporating clouds and current reality trees. I’ve written a fair amount here about the contradictions in the organisation I mentioned, so I’m going to update those entries with evaporating clouds, as I develop them. So far I’ve done i only want a pencil and give him what he wants. More to follow as I find the time…

i only want a pencil

My pencil is blunt. And I know there are no pencil-sharpeners in this office. But I do know there’s a stationery store upstairs where I can get a new pencil. (I already have 7 blunt pencils in my bag, all provided by this stationery store. For some reason I always forget to sharpen them when I get home. So I have to treat pencils as a use-once resource.) The stationery store has gone. I ask, and it turns out that the stationery department were ‘let go’ last month.

I’m told the project office may have a secret stash of stationery, if I ask nicely. I have a contact there, so I ask her. “Ah – no, we have none; try Julia.” So I call Julia’s mobile. From wherever she is in the world, she tells me I need to see Pat. I look Pat up in the site directory and go to her end of the building. Yes, she has pencils. If you’re gasping at this rigmarole wait, it’s not over yet.

“Are you authorised to take our stationery?” I use the secret handshake and she’s happy. “Can’t be too careful these days. Not everyone is allowed access to stationery.” She walks over to a wall safe and keys in the numeric combination. From the safe she takes a set of keys. We walk over to an anonymous door, which she unlocks. We go in, and I get a pencil. “Devils!” she exclaims, “someone’s taken 8 lab-books since Thursday!” She locks everything again on the way out.

Total elapsed time from running out of lead: 30 minutes. Number of staff involved: 5. Total staff time: 60 minutes. Total cost of the exercise: around £80, plus the phonecall, plus disruption to 5 people’s flow. How much do pencils cost?

Here’s an evaporating cloud showing the conflict within the organisation:


give him what he wants

This week I started on my first proper project here. I’m coming in just after the completion of the bid, which was accepted last week by the GoldOwner. My job is to set up the project and run it on behalf of the supplier organisation.

Interestingly, the said supplier organisation has quoted to run a classical waterfall project, but the GoldOwner wants it run “iteratively.” My bosses have told him that’s too risky, and that we’ll stick to falling water, thank-you-very-much. I, on the other hand, told him we’ll do it iteratively. I suspect my tenure here may be short-lived…

Here’s a conflict cloud expressing the issue I have here: