An interesting post and a pretty wild set of comments regarding failure at http://andrewchenblog.com/2009/07/13/built-to-fail-how-companies-like-google-ideo-and-37signals-build-failure-tolerant-systems-for-anything/.
I haven’t yet done a good job of describing the fail fast model with my thoughts on agile software development in this blog. Blogs feel more like streams-of-consciousness than articulated, structured documents. While I get my arms around how best to tell the fail fast story as I have experienced it through time, I thought it would be helpful to provide a bit more background on the topic by posting a copy of my Agile 2008 whitepaper, “The Big Projects Always Fail: Taking an Enterprise Agile.” You can now read it here; I would love to hear your thoughts and comments.
I think Mike Monteiro has it right. Click to buy from one of my favorite sites, 20×200.
Nice video on the power of failure from Honda.
Check out other “dreams” videos here.
I guess it has been eight years since the Agile Manifesto was originally published. It certainly doesn’t seem that long ago, but, then again, even that recently, agile was still considered relatively avant garde. It was something that you would likely have to convince your teams and customers of rather than one of the mature methological choices available for software development. Thanks to a recent Chet Hendrickson post to the Michigan Agile Enthusiasts group, I just learned of a newer software craftsmanship manifesto. Check it out.
Wired ran an interview of Freeman Dyson in which he had the following exchange with Stuart Brand:
Brand: So you’re saying just go ahead and try stuff and you’ll sort out the right way.
Dyson: That’s what nature did. And it’s almost always true in technology. That’s why computers never really took off until they built them small.
Brand: Why is small good?
Dyson: Because it’s cheaper and faster, and you can make many more. Speed is the most important thing — to be able to try something out on a small scale quickly.
Brand: Fail fast.
Dyson: Yes. These big projects are guaranteed to fail because you never have time to fix everything.
“Fail fast” has been a mantra of mine ever since. Actually, it has been more of an obsession, as anyone who has worked with me for more than a few weeks can confirm. I’ve decided to extend this infatuation to a blog so I can share with you the many references I’ve seen — and my friends and colleagues have shared with me — to document the concept, its many flavors, and its considerable benefits.