Life, Liberty, and the Pursuit of Agility

Written: May 26, 2011

NOTE: This article relates to the domain of software development.  Nothing else.  Also, the idea of failing early, fast, often, and better does not apply in all situations.  Use with caution.  However, it has been very useful for me in software development, and I can recommend that you try it out.  Otherwise, leave me alone, okay?

Failure and Mistakes are a Valuable Part of Software Development

We are going to make mistakes, misteps, and “failures”.  It’s part of the process.  We need to recognize failure as a valuable learning and steering opportunity.  Here are a couple of quotes on mistakes/failures:

“Mistakes themselves are often the best teachers of all.” – James Anthony Froude –

“I have not failed. I’ve just found 10,000 ways that won’t work.”  – Thomas Edison –

That is pretty clear, I think.  If we buy into the idea that failures can bring value, we might want to focus on ways to increase that value – it’s just another application of the concept of “Extreme Programming” – if something brings value, let’s figure out a way get the maximum value for the time and effort spent.  Make sense?

Fail Early

If we believe that we can learn from our failures then let’s start the learning.  The sooner we have a chance to fail, the sooner we get the benefit of the learning that comes with it.

How do we fail early?  Take action and make something small (but useful) right away, and immediately deliver it to the the customer (or user, or whoever) and get real and useful feedback.  Dig in, do something of value, see what works and what doesn’t, learn from it, adjust our course, and march on.

I have seen this quote of Napoleon about his basic military strategy: “On s’engage et puis on voit” which I am told means “I engage and then I see”.  This might not work in all cases but has worked very well for me in software development.  I shorten it to “Engage And See”.   [N.B.: Unlike Napoleon, please attempt in all cases to avoid a disastrous winter campaign in Russia.]

Fail Fast

We want to fail fast so we can learn in a matter of minutes, hours, or days rather than weeks and months (or never).  There are lots of ways to approach this in software development.  One great example which can give us “instant” results is TDD (Test Driven Development/Design).  Before we write any code, we write a failing (and very small) test.  Of course, there is more to it than that – but for my purpose in this article, the key is “VERY SMALL WITH INSTANT FEEDBACK”.  With TDD, the test fails immediately, which is about the shortest feedback loop as we can have.  Once the test is working, any time we work on our code we will run the tests and learn immediately when we have broken something that was previously working.  Instant feedbcak.

This instant feedback is great, but we can’t get instant feedback for everything.  However, what we CAN do is find a way to take very small steps that lead to useful feedback as quickly as possible for everything we do.  For example, the “business people” should work directly with the programmers and round-trip each step/task/feature continuously – let’s work to get this feedback in a few minutes rather than having a meeting every two weeks. You get the idea.  For every aspect of the process we want to minimize the time it takes to discover we have a mistake.

Fail Often

Once we are good at the failing/feedback/learning loop, we can ramp up the learning by failing a lot.  The more things we try, the more failures we might have, the more chances to learn and steer.  We are NOT after failure for failure’s sake.  We ARE after the good things we can learn by trying things that stretch our abilities and understanding.  Another benefit is that we waste less time working on the wrong thing.

I’ve often seen it that a little step towards what the user needs will lead to a change in direction to a better result for the next “chunk” of work.  Sometimes it can lead to a complete about-face where the customer all of a sudden realizes they want to go in a completely different direction, which is also very valuable.  And of course, they most often say “that is great!  it’s exactly what we wanted”.  Well…

Anyways – if one failure is good, lots of failures can be better.

Fail Better

So: early, rapid, and frequent opportunities to fail is good.  All that is left is to find ways to maximize the results of each learning opportunity.  Inspect and adapt.  Here are a couple of ideas:

Finding better ways to communicate feedback is one area worth improving.  For example, sitting side-by-side with the customer to do a hands-on walk-through of a new feature might be (and generally is) more productive than a “shared screen” online session, and is way better than traditional demos.  Being with a real user while they really use the project is the best.   Try it.

Another area we can explore is how to expose hidden requirements.  These are the things that in traditionally managed projects the “requirements gatherers” and customers have trouble capturnig in a document and eventually lead to BIG failure at the end of a long death march style effort. Fun! One approach we can follow is to “take a stab at it”.  If there are things we don’t understand we can often get clarity quickly by coding up what we currently understand and getting it into the hands of a user.  This will often result in something that is close to (but not quite) what is needed – and will allow us to discover the right path.  I am talking about doing real code that does real things for the purpose of showing us where we have a “failure to communicate” – clarity ensues.

Conclusion

Anyways – these are just a few thoughts that will hopefully lead to further thinking and improvement in our ability to make progess through failure.  That could be my new motto: “Progress Through Failure For A Brighter Tomorrow.”  Well, probably not – but… you get the idea.

One Last Quote:

“Agile doesn’t prevent us from making mistakes, it gives us a way to reduce the cost of those mistakes.” – Llewellyn Falco, paraphrased