June 27, 2007
UndesigningToday I'm back on the dice. (It's been a while.)
I just so happened to be having a beer with Mr Antony Gorman and Mr Antony Marcano on Friday night when a lively debate erupted - because that's what lively debates do, they erupt - about whether or not development teams need to know the business goals of their project.
Antony M was in the pro camp, whilst Antony G put the case for the opposition. I'd had 3 beers by this point in the proceedings, so my recollection is a little hazy, but I think the crux of the matter was that Antony M thought that it helped to point developers in the direction of business value, whilst Antony G argued that developers should focus on delivering what the customer asks for, and that the customer has ultimate responsibility for aligning software feature requests with business objectives.
It was at this juncture that I chipped in with my own tuppence-worth on this subject.
It went something like this:
You're on a project which has been very agressively time-boxed. The deadline cannot move. The customer has asked you to throw a 7 using your two sixe-sided dice. When you started, the customer gave you 10 throws to get that vital 7. After 8 throws, you still haven't satisfied the requirement.
Now remember that the deadline cannot move. What can you do? The chances of you getting a 7 with just 2 remaining throws are small - about 30% (give or take).
What I would do is go back to the customer and ask: "Why do you need us to throw a 7?"
And maybe the customer replies: "Because it's greater than 6".
"Aha!" you excalim. "So what you really need is for us to throw any number greater than 6?"
"Er, now that you put it like that, yes..." says the customer.
The odds of throwing a number greater than 6 with just 2 dice throws are about 80%. So by going back to the underlying objective - the real need behind the customer's specification - we can very significantly increase the range of potential solutions and therefore our chances of delivering something that addresses the business need.
In fancy terms, we should seek to have as wide a solution space as possible (i.e., make the hole bigger, to go back to the golfing analogy that I know you're all so very fond of.)
I like to call this process undesigning. It can be extremely powerful.
Posted 2 weeks, 2 days ago on June 27, 2007