Uncharted Waters

Nov 9 2015   12:31PM GMT

Don’t Fail Fast

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Fail fast

Some agile and lean people like to use the phrase ‘fail fast’. That slogan is usually a call to be brave and try new things that might not work out. Looking a little deeper, there is an encouragement to find what doesn’t work early rather than later when the stakes might be higher. I’ve never been a fan of the saying. Failing isn’t my idea of a good time whether is happens now, or later. And aside from that, I think it encourages the types of behavior that slow a company down instead of drive it forward.

Let’s take a closer look on what it means to fail.

A while ago I was working for a company building a healthcare documentation product. We were doing scrum to some degree, at least we had a daily standup where we talked about how the work was going. No one was keeping a close track on the work in progress though. At the start of every sprint there was a queue of work, and developers would take something from the top of the stack and start working on it. If they finished before a release day, they took the next thing they thought could be finished in time. We didn’t really have a concept of the exact things that would be done every two weeks.

Some people at the executive level were shuffled, and along with them a board member or two. The new leadership of course wanted to exert their influence, so we got something the company had never had before, an actual development manager. Our new manager saw that we were doing bits and pieces of scrum and some stuff that could be vaguely identified as agile and went whole hog. Books started showing up, there were meetings to talk about the new way, and sprints were heavily planned.


Each sprint we would practice the battle of will that is estimation, and each sprint we would end up with too much work. Surprises would come up — support needing some attention, or an unanticipated part of a feature getting more complicated — and something would end up not done or completely unaddressed at the end of 2 weeks.

Our manager would walk us through what got done and what didn’t, and then point to the burn down chart that was flatter than it should have been and tell us we had failed. We failed like that every two weeks for a while till the natives (the development team) got restless and angry.

The truth is that we didn’t fail. Every two weeks we sent off some new software to people that wanted it. There were of course occasional bugs that would shake out, but for the most part we were doing all right.

I’m pretty sure people that use the phrase ‘fail fast’ don’t actually want their teams to fail ever. And I also think that most of the people doing the work don’t feel like an occasional missed date or bug is a failure. Not to be overly politically correct here, but I prefer to think of these as learning experiences. Experiences that can immediately be taken, learned from, and put to use.

In school, failure has big consequences. Failing a test can create a chain of events that makes the rest of the year more difficult. Software isn’t school and no one wants to fail everyday, or even every two weeks.

My co-blogger, Matt Heusser,  here on Uncharted Waters said “…fail implies judgement according to some standard. My standard: if I live and learn, it ain’t failure.”. I tend to agree.

One side note: Facebook abandoned their slogan of “Move Fast, Break Things” Sometime in 2014. As it turns out, no one likes broken things.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: