It may seem obvious, but failure is another source of waste. Unfortunately, the only way to avoid failure entirely is to avoid doing anything worthwhile. That’s no way to excel. As [DeMarco & Lister 2003] said, “Projects with no real risks are losers. They are almost always devoid of benefit; that’s why they weren’t done years ago.”
Instead of trying to avoid failure, embrace it. Think, “If this project is sure to fail, I want to know that as soon as possible.” Look for ways to gather information that will tell you about the project’s likelihood of failure. Conduct experiments on risk-prone areas to see if they fail in practice. The sooner you can cancel a doomed project, the less time, effort, and money you’ll waste on it.
Failing fast applies to all aspects of your work, to examples as small as buying a bag of a new type of coffee bean rather than a crate. It frees you from worrying excessively about whether a decision is good or bad. If you’re not sure, structure your work so that you expose errors as soon as they occur. If it fails, let it fail quickly, rather than lingering in limbo. Either way, invest only as much time and as many resources as you need to be sure of your results.
With these principles guiding your decisions, you’ll fear failure less. If failure doesn’t hurt, then it’s OK to fail. You’ll be free to experiment and take risks. Capitalize on this freedom: if you have an idea, don’t speculate about whether it’s a good idea—try it! Create an experiment that will fail fast, and see what happens.
One of the challenges of adopting XP is that it tends to expose problems. For example, iterations, velocity, and the planning game shine the harsh light of fact on your schedule aspirations.
This is intentional: it’s one of the ways XP helps projects fail fast. If your desired schedule is unachievable, you should know that. If the project is still worthwhile, either reduce scope or change your schedule. Otherwise, cancel the project. This may seem harsh, but it’s really just a reflection of the “fail fast” philosophy.
This mindset can be foreign for organizations new to XP. It’s particularly troubling to organizations that habitually create unrealistic schedules. When XP fails fast in this sort of organization, blame—not credit—often falls on XP. Yet cancelling a project early isn’t a sign of failure in XP teams; it’s a success. The team prevented a doomed project from wasting hundreds of thousands of dollars! That’s worth celebrating.
I once led a development team on a project with an “aggressive schedule.” Seasoned developers recognize this phrase as a code for impending disaster. The schedule implicitly required the team to sacrifice their lives in a misguided attempt to achieve the unachievable.
I knew before I started that we had little chance of success. I accepted the job anyway, knowing that we could at least fail fast. This was a mistake. I shouldn’t have assumed.
Because there were clear danger signs for the project, our first task was to gather more information. We conducted three two-week iterations and created a release plan. Six weeks after starting the project, we had a reliable release date. It showed us coming in very late.
I thought this was good news—a textbook example of failing fast. We had performed an experiment that confirmed our fears, so now it was time to take action: change the scope of the project, change the date, or cancel the project. We had a golden opportunity to take a potential failure and turn it into a success, either by adjusting our plan or cutting our losses.
Unfortunately, I hadn’t done my homework. The organization wasn’t ready to accept the possibility of failure. Rather than address the problem, management tried to force the team to meet the original schedule. After realizing that management wouldn’t give us the support we needed to succeed, I eventually resigned.
Management pressured the remaining team members to work late nights and weekends—a typical death-march project—to no avail. The project delivered very late, within a few weeks of our velocity-based prediction, and the company lost the client. Because the organizational culture made it impossible to fail fast, the project was doomed to fail slowly.
How could the team have succeeded? In a sense, we couldn’t. There was no way for this project to achieve its original schedule, scope, and budget. (Unsurprisingly, that plan had no connection to the programmers’ estimates.) The best we could have done was to fail fast, then change the plan.
What could I have done differently? My mistake was taking on the project in the first place. I knew the existing schedule was unrealistic, and I assumed that objective proof of this would be enough to change everyone’s mind. I should have checked this assumption and—when it proved incorrect—declined the project.
What could the organization have done differently? Several things. It could have adopted an incremental delivery strategy, where we’d release the software after every iteration in the hope of delivering value more quickly. It could have cut the scope of the first milestone to a manageable set of features. Finally, it could have increased the available resources (up to a point) to allow us to increase our velocity.
Unfortunately, this organization couldn’t face failure, which prevented them from changing their plan. Organizations that can face failure are capable of embracing change in their projects. Paradoxically, facing failure gives them the ability to turn potential failures into successes.