Fail fast

… and fail small.

No, I’m not a big proponent of the “Fail Fast, Fail Often” mantra. I’d prefer to succeed. Fast and often. But failure is a reality, and how we manage it is critical.

Small projects fail in small ways

…and can usually be rescued.

Big projects fail in big ways

…and usually can’t.

Picture this: You’re leading a team of software developers. You have a project on the go that your team estimated would take three short Sprints of effort to complete. Halfway through the first Sprint, it becomes obvious you’re not going to make it. This is not (usually) a train-smash. You have some options here:

• De-scope a feature. At least that way you’ll still release on time, and can ship an update later.
• Add a Sprint. You’ll deliver with all promised features, a bit later than you’d hoped.
• Cancel the project. This can happen! Maybe your team came across a barrier that just wasn’t cost-effective to climb over, and the business decides to scrap it and do something else instead.

By the way, the first two are “iron triangle” cases. Scope, work-capacity and duration absolutely limit things here. The additional unplanned work has effectively increased the scope, so something has to adjust accordingly – either a traded-off item gets de-scoped, or the duration leg has to grow. There is a complementary third option of course – add more people – but that’s often not an immediate or practical solution.

However distasteful these options are, they’re usually not fatal. Because you caught it early (you failed fast), the cost to the business isn’t huge. Expectations can be managed and plans can be adjusted. You can mitigate.

But if the same thing happens halfway into a two-year project, it’s a completely different picture. That is a train-smash.

This is the power of iterative development. Make everything a small project. You can very effectively oversee a short single-Sprint effort, right? So everything is a short single-Sprint effort. Keep an eye on it day by day, inspect and adjust after every Sprint, then move on to the next short-Sprint effort.

One of the biggest mistakes you can make when progress isn’t as good as you thought it would be, is to keep quiet and pray that you can catch up. This generates a false sense of hope. We can’t hope a project down the road to success. Hope is not a valid project management methodology! Be brutally honest about project progress, and lead your team to behave the same way. To be truly agile, you need to be truly transparent. Nothing is hidden, including – in fact, especially – the bad news.

Hope is not a valid project management methodology!

Of course, nothing is quite that simple. That two-year project will still take two years. Probably longer, in fact, ‘coz that’s what happens. I’m assuming that your early Sprints are focused on team & tool selection, architecture and high-level design, and any other major dependencies. The roadblock-level impediments need to be discovered early, so that they can either be cleared, steered around, or accepted into the plan. The earlier in the project these things are identified, the more positive the ultimate outcome is likely to be.

As a leader, you will need a longer view. Your development team is necessarily focused on what’s in front of them for the current Sprint, with perhaps some background thinking (and short refinement sessions) about what’s coming up next, but they shouldn’t be obsessing over The Big Picture. That’s your job. The other part of your job is to make sure they’ve got everything they need to get the job done, then get out of the way. Everything they need includes clear focus on what they should be concerned with. Worrying about how the entire project gets delivered should absolutely not feature for them (that would be getting in the way). They need to spend their energy and attention on this Sprint, and looking forward to a glitzy show & tell Review session at the end of it.

But I digress (sorry). The value that Agile practices bring is in keeping things small. Nobody can visualise the end of a two-year project. Everybody can keep two weeks in their sights. Having the end in sight, always, is the major power of Agile. So if things are going to fail (as if they ever don’t), fail fast. And fail small.

The postings on this site don’t necessarily represent the views or opinions of my employer, professional organisations, political party, family, car manufacturer or anybody at all, really. I don’t know where they come from. It scares me sometimes.