Agility and Fear of Failure

We’ve likely all heard the famous line from Gene Kranz of NASA:  “Failure is not an option” with respect to the Apollo 13 space mission, right?  Well, most of us aren’t in a position where we are needing to navigate 3 people in a tiny, crippled craft back to Earth from the moon.  Many of us are writing business software.  Totally different challenge. 

In an agile mindset, failure is an option.  In fact, we should embrace the fact that we will fail…and when we fail, we want to fail fast. 

However, it is human nature to fear failure.  We all fear failure, both in our professional and personal lives.  I know I do.  What it is important to work towards, especially when working within the boundaries of Scrum, is learning that without failure you remain stagnant and possibly regress.  Without taking risks or pushing yourself and the team to try something new and different, you aren’t getting better, and you aren’t being truly agile.  After all, true agility is, at its core, about continuing to change and refine the way we work to improve it on all fronts – and this means taking risks on occasion to experiment with new ways of working.  If we let the fear of failure keep us from taking risks to improve, we are missing out on what agile can bring to us and our customers. 

Advertisements

The value of small user stories

There are a lot of good reasons to try to break down user stories into smaller ones (think INVEST model!), but here is one really compelling one:  the smaller your stories are, the more likely you are to complete them!  Here’s an example on how to think about it:

Let’s say your team looks at the backlog and says they can complete 5 stories in a given sprint.  Let’s say those 5 stories are somewhat large.  We’ll visualize the stories like this:

The sprint starts, and let’s say disaster strikes and we are only able to complete half of every story.*  At the end of our sprint, our stories might look like this (with green indicating completed work):

At the end of our sprint, we delivered exactly no value – zero completed stories.

But what if we broke all these stories in half?  We’ll start with this:

Same amount of work to be done, but we’ve spilt our stories out a bit more to a finer grain of detail.

Let’s say we have the same situation – a sprint starts, then disaster strikes, and we only finish half our work.  Our stories might look like this:

In this scenario, we finished the exact same amount of work, but were able to get 5 of our stories to completely done – we actually added value.

*Granted, this example is slightly contrived – completing stories also largely depends on how many stories you get in progress at any given time – which should be a small number – but the point remains – smaller stories let you get to “done” quicker, and ensure that a sprint delivers value.