Agile fables

Do you really need to celebrate failure to improve continuously?

Last century I learned about something called TQM which was all about empowering teams and improving processes. Now I am learning about agile and design thinking concepts.

These are great approaches and we have learned many things over the years, but some things have not changed.

For example, one thing common to all of these approaches is the concept that failure is good.

Failure is learning, so it is better to “fail fast” or “learn and pivot” than to avoid doing anything until you are sure it is safe.

But to be honest, when I fly from city to city I would prefer that the pilot does not fail often. In fact I hope he or she has flown the same plane a lot with other less important people, before taking me up and away from the safe ground I was on.

So, should be happy when we fail?

(warning – this is a very long read for a blog, but I thought I would send it out and fail to interest you rather than stop to think it through properly)


I guess we all know of people who failed a lot before they became awesome and most of them say they could not have been successful without taking risks.

Some risks don’t pay off, so clearly they would not be great unless they failed a lot along the way.

Sports teams practice and practise to make sure they are at their best in the real games, when it counts. Success in sports comes from practizing until you fail in training so you wont fail in the big game. But failing in the big game still happens. It sucks and the fans rarely celebrate your losing.

Even at the amateur “schoolyard” level of sport I played as a kid, team captains rarely went out of their way to pick the kids who were good at losing.  I certainly never expected to be the first pick when some of the natural athletes were available, even if I was a good sport and a keen contributor.

Along the same lines – I am grateful that the car I travel in is a lot safer than the original cars that went on the road.  It is their constant crashing and clunking and breaking down that provided the lessons needed to make better cars.

But I would not thank someone who sold me a lemon of a car, so that it could fail when I was driving and thereby help future generations to learn from my suffering.

Agile projects focus on making failure less painful by failing on a small scale so you have time to learn before you inflict bad things on real customers.

Design thinking probably goes further,  We claim that neither you nor your customers really know how good your product might before you test it. And you can’t test it inside your labs – people have to experience it in their own world to know if it is really relevant to their lives.

This leads to the idea that you need to experiment with ever evolving prototypes and “tests” that are only worth doing if you are not sure about how they will turn out. You start gentle and then keep testing more assumptions all the way up to, and well beyond, the day you go live.

This in turn means that each prototype is just as useful to your learning, whether it succeeded or failed to deliver the expected outcome. And by extension customer feedback is great even if they are telling you that you suck.

That is all very well – but there does seem to be a contradiction between “put the customer first – exceed their expectations – only build what is of value to the customer” on the one hand and  “learn by delivering bad things so you can improve on them” on the other.

Let’s explore this “creative tension” with a long story about a mythical team who did not satisfy the customer with their first, much anticipated release.

This story is based on some third hand information I heard over coffee and some photos I managed to take on the way back to my hotel.  There is enough truth in it to illustrate my point and enough fiction to assure you that it is entirely made up and not based on any real projects.

In my story …

There was a wonderful town called Pivot On High, where life was good.  Every year the people of the city grew more prosperous and the city expanded with more and more people coming to live there.

But as the city of Pivot grew, the local council started to notice that not everything was going well.

The people in the city were getting a little fatter each year. So the local council wanted to have a “get off your seat and do some exercise” project to tackle this issue.

Traffic in the city was getting worse by the day and the public transport system was creaking and shivering, trying to keep people moving around Pivot.  The councilors wanted to do what they could here, but had limited budgets and seemingly limitless needs for improvement.

These problems were never far from the councilors minds as they wrestled with ways to keep the citizens of the city happy and prosperous. One day Bill Mee, one of the councilors, came up with a great sounding solution.

“Let’s buy some bikes and put them in convenient locations.  Then people can take a bike – ride to the next location – and leave it there for the next person, ” Bill declared in a council meeting.

There was great rejoicing in the council.  They had found a cheap and effective solution to a number of different, hard to solve problems.

It was hard to find the money to fund their new idea, but they looked long and hard for a way forward.

After a quick fact finding tour to Europe (where the Councillors went to see a city that had implemented a similar solution), the funding committee scraped together enough money to proceed. They built a number of  “bike parking spots” and purchased quite a few bicycles.

Release one was implemented and looked something like this

A bike in the city with no helmet
A bike in the city with no helmet

Once they went live though, they discovered a major problem. Technically it was illegal to ride a bike in the fine city of Pivot unless you were wearing a helmet.

And when I say technically I mean “in fact yes – it is literally illegal to ride without a helmet”.  A number of years ago, the council had passed a law requiring citizens to wear helmets when they were riding a bike.

They did this when they learned that many of the fine citizens of their fine city had been seriously injured when they fell on their heads while riding.  Clearly wearing a helmet was a better idea than falling on your head and being seriously hurt.

And when I say “fine city” it is interesting to note that the city’s parking inspectors took the “fine” part of their role very seriously.  In fact they aggressively fined anyone riding one of the new bikes without a helmet and, according to some fined citizens, they often waited near the newly installed bike stations so they could pounce on anyone who tried to use the new bikes.

Now the council was very sad.  Bill took the blame and offered to resign.

But then someone reminded Bill that his cousin, Wazen Mee, was an agile consultant.

“This is great news,” they said, “Agile teams fail all over the place, your cousin Wazen will know what to do.”

So they called in Wazen Mee to do a retrospective.  Unfortunately his findings were all too consistent with what agile teams often discover when they encounter “less agile” outsiders.

Wazen’s report was scathing.  “The problem is that you were not agile,” he said, “had you been agile you would have done a bunch of sprints and standing up meetings and you would never have failed.”

Next time, Wazen concluded, they should be agile.

So the councilors were sad.  They had hoped Wazen Mee would help them but all he did was say they should feel guilty instead of celebrating their failure.

Next they turned to Ian Derthall, the council’s old school IT Manager.

“Don’t worry,” Ian Derthall said, “those agile guys are idiots anyway.  They would have had you sprinting around all over the place but you would have failed anyway. Projects usually end badly”

But then he offered them a ray of hope – “Us IT guys have a lot of experience with delivering things people can’t use – so we know exactly what to do whenever that happens.”

Ian advised them to immediately implement a work-around, a time-tested IT solution to use when you fail to deliver something really useful.

They should simply tell people to buy a helmet and then sell helmets in the local newsagents.

It would be up to people to purchase a helmet before borrowing a bike.  If people did not do this then obviously they did not really want to ride a bike anyway.

So release 1.1 was implemented – the bikes were left in place and people were expected to purchase a helmet or risk paying a fine.  To help them some signs were erected, warning people of the importance of going away to buy a helmet before taking a bike.

This worked OK as the locals knew better than to use the bikes and sometimes tourists would unwittingly use a bike and then be forced to pay a fine, which contributed to the city’s coffers.

But the bikes still needed maintenance and they were not getting much use, so the councilors still felt unsatisfied.  Someone suggested that they place tolls on the roads, increase the cost of parking and then hike up the cost of public transport.  This would force people onto the bikes, thus making the project successful after all.

“That’s idiotic,” declared Red De’Per, the council’s accountant, “no city in the world could get away with that.”

Red told the councilors that he also had a lot of experience with projects like this.  “Don’t worry,” he said, “what we always do with IT projects is let them go live, remove the bits that annoy us and go back to what we used to do. It’s amazing what you can do with Excel.”

Red rambled on a bit about being able to build any IT system in Excel but people weren’t listening.  They had already heard what they needed to do.

So release 2 was rolled out as soon as practical. The official bikes were taken away and the bike stands remained, but with a slightly different look.

BYO Bikes
BYO Bikes

Now citizens could bring their own bikes and, if they also had a helmet, then they would benefit from the plentiful bike parking lots throughout the city.

This did not seem ideal, considering the expense of release one and the bad press they received along the way.  But at least they had delivered some value to their citizens.

The councilors reflected on this.

In some ways Ian Derthall had been spot on –  Wazen Me and his retrospective were not much use since all he did was claim that agile was good and the councilors were silly.  This neither celebrated the learning they had paid for, nor helped them improve on what they had delivered so far.

But Ian Derthall had also been wrong – the council had not won any friends with the approach of dumping a workaround on their customers and then hoping that was the end of it.

Maybe Red had come up with the best approach – try something, dump what does not work and stick with what you find useful.

But that is not the end of the story.  Fortunately for the council, their very next meeting was another brave experiment and this one had unexpected benefits.

The council had launched a competition in their local schools as part of “council awareness week”.  Children from the winning school got to come to the council chambers and actually sit on the council for a week.

The idea was that school children could come and learn more about local politics, thus building an improved sense of civic duty and helping the children learn from the wise musings of the experienced councilors along the way.

But it didn’t turn out that way.  Instead the councilors had something to learn from the children.

It turns out the children had faced a similar bike problem with riding their own bikes to school.  They had been forced by their parents to wear helmets when riding but hated carrying their helmets around.

Some of the children just left their helmets with their bikes – but the helmets had been stolen. Others tried to ride really fast without a helmet so they would not be seen, but they always got caught and got into trouble.

Then one student came to school with a longer than usual bike chain that allowed her to lock her  helmet up with her bike. The other children copied her and soon her approach had been adopted across most of the schools in the area.

The council were astounded at how bright these naive children were.

“Aren’t they precious,” remarked one of the councilors, “reminds me of myself when I was that age.”

The children helped the council to implement release 3, but they thought release 3 sounded boring so they renamed the project “Cycle around Pivot”.  “If you don’t like where you are going,” their new publicist told people, “just go somewhere else.”

The result looked something like this:

Bike with helmet
Bike with helmet

Wazen Mee is still convinced that the council should have gone agile a long time ago.  In his opinion an agile council would have gotten to the same point before the big bang roll-out, with far less embarrassment and far less drama.

Me, I’m still not sure.

I agree that the team stuffed up when they rolled out bikes that were pretty much useless.  I agree that if the team had “rejoiced in failing” and granted themselves a council boat cruise after the first roll-out, the good citizens of Pivot would have pivoted the council out on their (part of their anatomy).

Avoiding failure before you roll out dumb ideas is clearly good.  But sometimes you have to actually fail publicly and when you do it doesn’t matter how you got there.

When this happens it is bad, not good.  But when it happens it is a great opportunity to learn, even if it is not a great time to celebrate.  And if your team can learn when times are tough, then I guess you could say that is worth celebrating.

Interestingly the council have recently spoken to a design thinker. He prefers people to call him “Cool 2B” – named after the only pencil that really caters for creative thinking, apparently.

I don’t get his strange ways but he has long hair tied back in a pony tail, he quotes Steve Jobs 3 times a day and he uses Apple products wherever possible. So his design thinking pedigree is pretty solid.

Cool 2B told that council that the problem is not so much that they were foolhardy to roll out the bikes with no helmets – it is that they were not daring enough to try a lot more variations at the same time.

Emboldened by his optimistic and confident demeanor, the councilors are feeling excited again and soon we will see the benefits of their innovative and fearless thinking.

One project in the pipelines is “Adverbikes” where local businesses can sponsor a bike. That way it is OK if the bike is parked somewhere prominent for days on end – and even better if someone is happy to ride the advertisement around the city

A bike with advertising
A bike with advertising
Another adverbike - coming to a street near you
Another adverbike – coming to a street near you

One councilor has even suggested that they should extend the idea to motor bikes and scooters.  He has generously started parking his motorbike on the pavement all over town to see if it will work. He even has some crazy idea you could do something similar with cars.

A motorbike on the sidewalk
A motorbike on the sidewalk

These small experiments are generating a lot of feedback.  Some positive and some not so good.

Maybe one of those initiatives has the potential to bring real innovation to the city of Pivot on High. But of course one or both of those initiatives could be destined to be a complete debacle.

This is exactly the kind of dilemma that design thinking is ideal for resolving.

After all, the council have tried the Wazen Mee approach to agile and the Ian Dethall approach of workarounds.  So maybe the Cool 2B design thinking approach will be the next logical step in their “Innovation Evolution”.

For me though, the real innovation was in the learning from the failure, rather than the failure itself or the different approaches to getting to the point where you might fail.

Failing is best done in small doses when you can learn a lot for very little pain.  But the real test comes when you fail with real people when failing is not actually great – it sucks.   And when it sucks you can learn from it or you can repeat the cycle of failing without learning.

So make it safe to fail: without making things suck for your customers.

And then if and when this “fail safely approach” does impact customers – I guess the idea is to seize the opportunity to learn and improve rather than “dump and run” or “forget and repeat”.

This thinking was part of the original version of continuous improvement that I learned many years ago and I guess it is still part of what we want to do today.

Advertisement

4 thoughts on “Do you really need to celebrate failure to improve continuously?

  1. I am sorry. It seems you got all concepts wrong the examples which you gave here had nothing to do with TQM, lean, and agile. Anyone who worked for any mans actuating company knows that TQM goes hand in hand with six sigma to improve quality and lessen defects ( 3.4 per million) as six sigma target the car and plane examples which you gave here aren’t good examples when comparing them with your example. Failing fast doesn’t mean you need to fail necessarily. It means if an idea would fail it was better to fail earlier in the piece. The mistake that councillor made here has nothing to do with agile concept. They didn’t tuned in to market problem and had inside out approach to resolve a problem. Surely they did fail not because of they didn’t use agile but because their approach. Sorry I don’t believe you fully understand agile and making this kind of judgemental calls doesn’t make any sense to me. Please don’t mislead people.

    Like

    1. I agree Ali, as I’m reading through this I was getting more and more convinced that the writer doesn’t actually understand or have any first hand experience with Agile, Lean or Six Sigma.
      It reads like a miss-guided rant or maybe he was aiming for a bit of comic relief without it being based on reality.

      Like

    1. Wow that looks comprehensive. I haven’t seen it before but I will read through it. I went off to be certified in business model canvas and I found that using a design thinking approach or a lean startup approach works well with agile.
      What I found though was that it is best to lead with the design thinking and have agile techniques file at a way of delivering rather than fitting the design into an agile framework. If you think of experiments and prototypes as creating value through learning and let this drive you then it all why tried pretty well. In fact if you read user story making by Jeff Patton, the story map provides a natural bridge to bring things together http://jpattonassociates.com/user-story-mapping/.
      Thanks for the link, I am reading through it tonight and it does look interesting

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.