Want to be Agile? Learn to Fail!
- The Story of the Never-Ending Project
- How Do You Know You're Failing?
- The Virtues of Failing Fast
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Let's face it: No matter how many times you read about "embracing failure" in a business article, you probably think that's good advice for someone else. On balance, people would rather win than lose. To fail, in the mind of most people, is to lose. I don't care how many books you read on the virtues of personal failure; nobody is really going to come home, open a glass of champagne, and celebrate personal failure.
Rest assured, this article isn't about the personal benefits of failure—as abundant as I believe those are. This article is about Agile software development. It's about how failure—recognizing it and doing something about it—is a critical element of any Agile initiative. It's about how you can save your company hundreds of millions of dollars by killing doomed projects early, before they become "too big to fail."
The Story of the Never-Ending Project
When IT makes headlines, it's usually because some big project has gone horribly wrong, to the tune of hundreds of millions of dollars. Some very public, spectacular failures are detailed in the very excellent article IEEE Spectrum article "Why Software Fails." And these are just the failures that hit the news. Many other failures are swept under the rug and fail to make headlines, but have similar impact on the bottom line.
Why do these disasters happen? Why doesn't it occur to these people that if you are $100M USD into a project and you haven't seen any software yet, you should probably cancel the project? Part of the reason is the "sunk cost" fallacy. After investing so much capital—financial, political, and so on—into a project, the people involved are loath to let it fail.
Why is failure hard to admit? Reputations must be considered—especially those of project leaders. Canceling projects can cause jobs to be lost, especially that of the person who initially funded the project, if failure is seen as a fate to be avoided at all costs. Even if you don't really risk job loss, it's simply difficult to admit that whatever you've been working on for the last year may be the wrong thing. People tend to want to keep a project going—against all odds—on nothing else but the basis of personal pride and ego.
Excessive pride and ego can have catastrophic costs on the bottom line. Large projects tend to be accounted for using the capital expense budget, which allows you to write off the cost of the project a little each year, over a 10-year period or longer. However, if a project fails, the "sunk cost" is written off as a one-time operational expense, taking losses that would have been realized in the future, and front-loading them to the present. The net result tends to be that projects, once they get to be a certain size, literally become "too big to fail." This fact makes it all the more important that we learn how to recognize failure as early as possible, so we don't let a doomed project reach escape velocity.