I’ve been skimming Where Good Ideas Come From: The Natural History of Innovation by Steven Johnson. It’s fairly dense reading so I’ve been skimming through to sections that catch my interest.
This section about innovative environments from page 148 was striking:
Innovative environments thrive on useful mistakes, and suffer when the demands of quality control overwhelm them. Big organizations like to follow perfectionist regimes like Six Sigma and Total Quality Management, entire systems devoted to eliminating error from the conference room or the assembly line, but it’s no accident that one of the mantras of the Web startup world is fail faster. It’s not that mistakes are the goal–they’re still mistakes after all, which is why you want to get through them quickly. But those mistakes are an inevitable step on the path to true innovation.
This reminds me why I’m totally loving working on OpenShift–the rapid development model and the explicit desire to innovate. This is contrasted by other projects I’m close to that are either waterfall or attempting to be a combination of agile and waterfall. My initial impression is that tying to do both is actually worse than picking one or the other.
Recently I’ve begun to wonder if the waterfall method of development is more about managing fear and the illusion that “if you have a detailed plan you will have a corresponding level of success.” This isn’t to say I didn’t once believe this. I’ve been through enough projects now to realize that detailed plans are only good for the short term and that something unexpected usually happens requiring you to adjust.
Honestly–the last project you worked on, that one with the “One to Three Year Roadmap”–how much of it came true? Chances are, the project got canceled, re-directed, or turned into something else after nine months. All that time planning and predicting the future–was it really worth the time invested?
Detailed project plans and requirement documents are often obsoleted a month or two after they are created–because once you get into the implementation details or you actually release something, you learn something you didn’t know before. And based on that information, the smartest thing to do is make adjustments. If you’ve planned with a high degree of complexity, making those adjustments is painful.
This is the benefit I’m seeing with agile development–take the weeks and months you would normally spend planning and writing fancy Product Requirement Documents (PRDs) and Marketing Requirement Documents (MRDs), having meetings, and getting feedback from the whole world, and use that time writing some high level requirements and user stories.
Then, start your first sprint, before you are ready, even if the first few sprints are a complete failure. At least you will have gotten that part over with. And then, most importantly, ship or release what you’ve created, after each sprint, to a larger audience so they can start using it and give you feedback.
I’m sure there is still a place for waterfall approaches–things like tactical operations or situations where you only have one chance to succeed. Maybe there are places you can iterate on airplane design and yet the outcome of crashing a plane is much different than a sprint that “crashed and burned.” Context is important. Here I’m mostly thinking about online product offerings and web properties, though I think there are probably wider applications.
The book links above are affiliate links to Amazon.
August 25, 2011 at 2:37 pm
I believe managing fear is a good part of the reason for waterfall and other production models.
1) People are horrible for calculating risks and focus on less likely events even when more likely ones can occur.
2) As group size grows, people are less likely to accept failures in others. I am guessing there is an evolutionary aspect here.
3) Success seems to breed more of a “we have only once chance to succeed” mentality. A string of failures seems to get people to continue on trying, but a string of successes get people to worrying about when the failure will occur.