Topic: Mindset and culture
My colleague Ryan Hoegg pointed me to an interesting post on Tim Bray's blog that contains a quote I could relate to very well this morning:
Good-enough today beats complete next year · Gall’s Law: "A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system."
At our house, we have two coffee makers. One is a very simple stove-top contraption that makes two cups at a time and produces reasonably good coffee. It's made of heavy metal and consists of a lower chamber you fill with water and an upper chamber where the finished product is delivered. In between is a metal basket for the coffee grounds. When the water boils, it flows through the grounds and ends up in the upper chamber in the form of coffee. The technology is so simple, it's all but foolproof. The other is a fancier, more complex espresso machine that makes one cup at a time. It makes absolutely gorgeous coffee.
This morning I wanted an additional cup of coffee after breakfast. My wife suggested I use the espresso machine, since no one else wanted more and there was no need to waste coffee in the two-cup coffee maker. It sounded reasonable. There was a time constraint, however: I needed to get ready for work. The espresso machine makes much better-tasting coffee than the stove-top device, and when it works it takes far less time. Today, however, the espresso machine decided to clog, and I ended up with a mess.
Pressed for time (no pun intended), I decided to use the stove-top coffee maker instead of trying to debug the espresso machine. A perfect cup of espresso delivered too late for me to drink it would be as useless as a perfect software product delivered too late to meet a market window. The coffee from the stove-top coffee maker was good enough, and I had enough time to drink it.
Since I was shifting my brain into work mode at the time, it struck me that the complex espresso machine was like a complex software design, and the stove-top coffee maker was like a simple software design. Sure, the espresso machine makes better-tasting coffee, but if technical difficulties arise and you can't get any coffee in time to drink it, then what's the value? Who cares how good the coffee would have tasted if only one had gotten any? Similarly, it's quite often the case that the business value of a software product depends strongly on time-to-market. It may be more important to have a working solution now than a perfect solution later. If the company misses a market window, it will incur opportunity cost. In the worst case, the entire project may become moot.
One of my earliest agile projects involved delivering a simple version of a solution very quickly, so that the company could take advantage of the peak sales season in a particular market segment and enter that segment before our competitors. The first player in a market segment enjoys a significant competitive advantage. The IT department's bid for the same project, using traditional methods, would have missed that market window by several months. According to the customer's own calculations, this would have resulted in an opportunity cost due to lost sales opportunities of about $2 million per year, as well as placing our company in third position in the market segment behind our competitors, based on information our customer had regarding competitors' plans.
A couple of years after delivering the solution, I touched base with the customer to see how it was working out. She said it had been a success, and the business unit had established a good enough revenue stream that they were revisiting the product to make technical improvements. The simple version of the solution was supporting itself financially, and could afford to buy itself an upgrade. Had the original development team tried to build the perfect product the first time around, they would have missed the market window and the business unit would have been shut down before two years had passed.
A session presented by Koen van Exem and Walter Hesius at XP Days Benelux 2007 dealt with this very topic. Using what they call dimensional planning, a team defines potential solution implementations at different levels of quality. Each alternative implementation supports the business need, so any of them would enable the customer to go forward with the business operation the software was to support. They used a road-building metaphor: You could build a dirt road, a cobblestone road, an asphalt road, or a highway. Any will get the job done, although of course the better the road the more traffic it can carry. The point is, if you wait until the highway can be completed before you have any road at all, the goods you wanted to transport might already have rotted or gone out of style before you could take them anywhere.
In his book, Scaling Software Agility: Best Practices for Large Enterprises, Dean Leffingwell describes a requirements and design continuum that captures the same basic idea. He suggests that teams should plan to build up to four potential versions of the same feature, which he labels least imaginable, minimum credible, moderate, and best. You can see the similarity with the road-building metaphor.
According to Gall's Law, quoted in Tim's blog post, complex systems evolve from simple ones. Both dimensional planning and the requirements and design continuum take this concept to heart. In both cases, the recommendation is that the simpler versions of a given feature should be designed in a way that allows the next-better version to be built on top of it. A well-graded dirt road makes a fine foundation for a cobblestone road. Cobblestones can be removed and replaced with an asphalt top. An asphalt road can be widened and access ramps added to turn it into a highway. The successful agile project I mentioned took the same path. The solution we delivered initially was a minimum credible or cobblestone implementation. Because it enabled the business unit to proceed with its revenue-generating operation, it eventually became feasible to upgrade to a moderate or asphalt implementation which was more capable and easier to support. That level of quality represented the right balance of cost-of-ownership and revenue-generating potential for that particular business operation.
So, what's new about all this? Isn't it just common sense? Don't software development teams already think this way? Well, they don't. Many software professionals consider their work to be a craft, and on a certain level, they're right. Their primary concern is with the quality of the products they make. They don't necessarily think about matters like time-to-market and opportunity cost. They are certainly capable of understanding those issues, but most don't think that way automatically or habitually. They think like craftsmen. Since agile development in particular is explicitly focused on delivering customer-defined value as opposed to just following a defined process, the agile mode of work tends to pull software developers toward a more business-aware mindset. I think it's an important shift in thinking if we are to be successful with agile development. More often than not, we need to deliver something that works and deliver it quickly. It means that often our products will not be beautiful or elegant; at least, not Version 1.0. And that's okay.
