Do We Really Reward Noble Failures?

Both Agile and Lean have an ethos that, at least on paper, acknowledges the noble failure. "Fail fast" is part of the Agile credo. Although it sounds as though it contradicts the "fail fast" approach, Lean's admonition to delay decisions for as long as possible is actually very complementary. The first draft of anything, from automotive design to software architecture to student papers, always contains elements that could be improved or that are just flat-out wrong. Practices that sit beneath the banner of Agile or Lean, such as set-based development, provide further ways to make mistakes and overcome them.

To a large extent, these practices deal with the easier varieties of failure. Prototyping a feature quickly, so that you can invite feedback when you actually have enough time to respond to it, is an extremely valuable technique for lowering the risk that you build something the wrong way. You need a different approach to identifying the features that you should not build, period.

At the Silicon Valley Product Camp a couple of weekends ago, Nils Davis of Accept Software gave one of the best presentations of the day, covering his company's experience with innovation jams. (Here's a link to the slides.) It's exactly the sort of exercise that gives people the opportunity to explore ideas that a team is still considering or identify ideas that they might have missed. After collecting ideas from around the company, a panel of Accept's executives selected ideas that looked both cool and profitable. On a Saturday, several teams worked feverishly to build prototypes that could test these concepts and suggest how the final implementation might look. The executive committee then selected the best of these ideas and gave prizes to the winning teams.

That type of innovation jam is a great idea, all around. Even an Agile team like the Accept development organization needs to step outside the assumptions of daily work and give people a chance to participate in ways they don't ordinarily get. The executive review step reminds everyone about the bigger business picture into which everyone's work must fit. (Not every idea that might be attractive to customers will have the same value for the ISV.) The day of fast-paced development gets the blood going. Heck, after hearing Nils' description, I wished I'd been part of their innovation jam.

However, it's important to note that this exercise, as laudable as it was, rewarded success. The awards went to the projects most likely to be added to the product road map. There was no special recognition or consolation prize for the idea that, after the most energetic, creative, and skilled efforts possible, proved to be far less brilliant than it seemed at first.

But that's hardly unusual. In fact, it's extremely difficult to find anyone who, in truth, rewards failure. While we often hear people talk about how they encourage risk-taking, practically no one rewards people for the downside of taking risks.

Rewarding noble failures runs against some of our deepest instincts about application development and delivery. No one prefers to be on the "noble failure" team, given the opportunity to be on the First Prize team instead. While we might have enjoyed the original Rocky movie, in which he loses the big fight, Hollywood felt compelled to release a sequel in which he wins. (And if that didn't drive home the point enough, United Artists produced more Rocky films, in which he wins yet again.)

While our brains might have a hard time embracing noble failures, the organizations in which we work make it even harder. Executives and managers are rewarded for delivering value, not avoiding duds. These same executives and managers are usually uncomfortable with techniques like set-based development, which depends on parallel design and development tracks that seem wasteful, even if the point is to avoid waste further down the road. Bad ideas don't flutter down into the room on their own from some intellectual stratosphere; instead, they're often the brainchildren of influential people within a team, who might not welcome other team members shooting down these ideas.

To overcome the natural tendency of organizations to frown on even the noblest of failures, leadership within a team, or a level or two above in the org chart, is required. Other kinds of changes, like continuous integration, might proceed apace without executive sponsorship. Not so with rewarding noble failures.

Sometimes, team leaders I've met at Intuit, Informatica, and other companies avoid focusing exclusively on the results of investigating ideas, giving conspicuous praise to people who are faithful to the process of investigation. Other teams go out of their way to give out recognition for team members who took a risk on an idea and then proved how bad it was. (Jared Spool is especially good at describing how that technique works in practice.)

Rewarding noble failures is hard, so very, very few teams really do it. It requires leadership that's willing to do more than just show up for the photo op at the end of a development cycle. App dev teams need the kind of leaders that encourage risks, acknowledge noble failures, and help teams learn from their mistakes.

Categories:

Comments

As always, it is the human aspect ...

Tom, great post!

As always it is not the methodology or the technology that counts but the people. The kind of people a business hires and how it motivates and empowers them defines the culture. As you say, it is not enough to pronounce the willingness to reward failure but to live a faillure culture, meaning that one does not shoot the messenger of bad news. Bad news must travel faster than anything else and must be rewarded.

Therefore it is necessary to empower people to collaborate in a very open and adaptive environment. Top-Dpwn and Bottom-Up transparency is essential. Projects must not be rigid but go with the flow of little successes and failures as otherwise any small failure puts the whole project in jeopardy through the rigid dependencies. The dynamics of 'adaptive' projects requires however so-called sentiment scoring that queries people on their perspective of the 'adaptive' process, project or program. (Yes, I see them as the same structure just on different time-scales.)

As long as people are aligned in their sentiment things are good. Once they start to differ wildly the projects are in trouble. The leading thinker in sentiment scoring is Michael Krigsman of Asuret who I also collaborate with to bring this concept into project management. More on http://asuret.com/index.html

Regards, Max

The fallacy of "noble failures"

Thanks for an thought provoking post.

In my experience studying failures, over the course of many years, it is hard to imagine someone's career being advanced by failure. You correctly point this out.

Fast failure implies small failure. By experimenting on situations or ideas that are small, and therefore inherently less risky, we can avoid catastrophic problems such as those often seen on large IT projects. In this cast, failing fast lets us gain rapid information about the environment, so we can make more frequent course corrections than would otherwise be possible.

This notion of failing fast therefore links to Max Pucher's comment about adaptive project management. By gathering right kinds of data, we can take smaller steps, learn as we go, and thus decrease the likelihood of large failures.

This adaptive approach is surely a great way to ensure success.

You may be interested in my blog, which is called IT Project Failures: http://www.zdnet.com/blog/projectfailures