Over a million developers have joined DZone.

New to agile? Learn how to fail well

DZone's Guide to

New to agile? Learn how to fail well

· Agile Zone ·
Free Resource

Is success or failure really a choice?  I don’t think it is at all.  Pretty much no one chooses to fail.  Unfortunately, we can’t just choose to be successful either.  What we CAN choose is to try to make a success out of a failure!  The old saying “Make lemonade out of lemons” really is a good way of looking at things, especially for agile teams.

Agile teams will have times when they “fail.”  I know a lot of people dislike using the words “fail” and “failure” when talking about team results.  I’m actually pretty tired of that argument because I don’t think it helps anyone.  I’d rather call a “poor result” a “failure” and acknowledge we can and will strive to do better next time.  As I say during workshops I facilitate, “I am blunt and reality based. Sometimes that means I will say things which you won’t like to hear.”  I don’t call teams “failures” or anything like that.  That would be namecalling and that is never appropriate.  However, calling results a failure is correct and leaves no room for interpretation.  I find being blunt in those situations to be more useful because teams then must face the reality and not try to sugar coat it as “not being all that bad…”

What comes out of failure is what I care about.  I don’t care so much how it happened, why it happened, who supposedly caused it to happen, or that it wasn’t all that bad really.  What I care about is acknowledging there is a problem that needs to be solved.  In my experience I find it easier to digest and solve if failures can be limited to happening only if 3 conditions can be met:

Conditions for acceptable failure

  1. Fail FAST!
  2. Learn from it.
  3. Don’t do it the same way again.

Teams which keep these three simple conditions in mind when dealing with risk they often find themselves making better decisions and reacting more appropriately to the results of those decisions.  The areas of highest risk are where we are most likely to encounter failure, so how will we limit the timeframe to failure?  If we fail, what will we learn from it?  If we fail, how will we avoid failing in the same way again?  This is the heart of improvement.  Be open and honest about the result (failure).  Limit the damange (fail fast).  Examine the failure closely (learn from it).  Try a new way to solve the problem (don’t do it the same way again).

I see too many teams accepting failure time after time after time.  It is very frustrating to the organization and sometimes the team doesn’t even acknowledge there is a problem.  They keep saying they can’t do anything about it or it is an “acceptable failure.”  What does that even mean?  Acceptable to who?  Last time I checked, none of my clients were particularly pleased about failures.  This is where it gets dangerous to call a failing result anything but failure.  Calling it something else makes it somehow more palatable and easier to ignore.  Getting past difficult failures is the time of greatest learning and improvement for teams.  It changes regular teams into high performing teams, and high performing teams can become hyper-productive teams.

Don’t blow failures out of proportion (it really isn’t the end of the world), but at the same time don’t ignore them either.  Teams must deal with failures and turn them into successes downstream.  If they don’t do this then the failures will continue to cascade and cause a loss of morale, loss of urgency and ultimately a project or organizational failure.  Not dealing with failure is leaving a fuse lit on a ticking time bomb – I hope you defuse it in time!

Until next time I’ll be Making Agile a Reality® with my clients by continuing to make sure they all understand the 3 conditions necessary for failure to turn into eventual success.

Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}