When I hear it said that we should celebrate our failures or that we should “fail fast”, I fear that some people may mistake the intent behind it. The aim is not to fail, but instead to learn from failures. What we should really say is “learn fast” and “celebrate our discoveries”.
As a fan of many forms of motorsport, I was interested to read about a recent experiment with adding “mudguards” to a Formula One car. (The aim being to reduce the spray thrown up by cars travelling at high speed in wet conditions.) One article caught my eye because its headline declared “First F1 ‘mudguard’ test ‘a failure’ – report“. My immediate thought was that the test probably wasn’t a failure – far more likely was that the test didn’t show it to be 100% successful which, given it was the first test of a new concept, would have been unlikely. The report said that “there was still too much spray” but that “The test provided valuable CFD correlation data as well as good driver feedback.” (CFD in this instance means Computational Fluid Dynamics rather than a Cumulative Flow Diagram.)
My takeaway from the article was that data from the test will help them improve the design and their approach for the next iteration of the device. Is that a failure? It didn’t solve the problem (how often does Version 1 of anything do that?) but I would only call the test a failure if they came away from it with no new information.
Rather than call it a failure, why not say the test was successful in generating further insights? Probably because that’s too long for a headline, and “bad news sells”. But when we’re talking about running experiments, especially when we know status reports are summarised as they go up the food chain, why not say the test was successful or that we now know more than we did before the test? Mislabelling it as a failure could lead to unfavourable repercussions, including senior managers wanting to stop experiments because “we don’t have time for failure”.
I’m sure most people will be happy to see the end of 2021 but also trying not to build up too much expectation for 2022. There won’t be a sudden end to COVID – it’s going to take a continued effort from everyone. It won’t go away just because we’re all tired of dealing with it. Stay strong; hang in there; support each other; and keep safe, please.
The New Year is a time when many people set Resolutions – things they want to improve, e.g. eating better, getting more exercise. It’s a handy reminder to review how happy we are with various things, but is doing it once a year really enough? It often leads to huge goals because it’s going to be so long until the new review… and, of course, huge goals aren’t usually achievable. That’s why most resolutions are abandoned within a few weeks. It probably helps to have a vision of how you would like things to be in a few months (even a year), but set smaller goals – what are the steps that you think will take you towards that vision?
Hopefully that sounds familiar: regular retrospection, identifying where you want to improve, deciding on small steps to go in that direction; take a step, then go back to retrospection, rinse and repeat.
Engineers and product owners should be well practised in this – retrospectives to look at how we work, and experiments to probe what to build. So how do we convince HR that annual appraisals should be replaced with frequent feedback, and Finance that regular (e.g. monthly) planning trumps attempting to predict six or even twelve months ahead? That’s a challenge I’d like to add to my backlog for next year. Suggestions are welcome!
p.s.
2014: Didn’t jog
2015: Didn’t jog
2016: Didn’t jog
2017: Didn’t jog
2018: Didn’t jog
2019: Didn’t jog
2020: Didn’t jog
2021: Still haven’t jogged
This is a running joke! 🙂
One of the agile principles is that the team have a supportive environment; Modern Agile explicitly says “Make safety a prerequisite”. It’s essential that the team can say “no” when asked to take on extra work, for example, otherwise saying “yes” has no meaning. We expect the team to commit to a sprint plan but if they cannot decide that a story is not ready (e.g. too many unknowns) or that taking “just one more story” will mean they cannot deliver them all, then any apparent commitment is just lip service.
However, many of the questions posed during software development can’t be answered with a simple yes or no – many require investigation (more than just a Google search!) so how can we make that safe? If the product owner wants to know if moving the “buy now” button will increase sales, or the team wants to know if splitting stories smaller will help them finish epics sooner, then the best way to find out is to try it and see i.e. run an experiment.
I often hear people talk about “failed experiments” but that’s misleading: an experiment proves or disproves a hypothesis. (OK, if you have constructed or executed it incorrectly, then maybe that’s a “failed experiment”.)
If we want to encourage a learning environment, we should get used to saying that the experiment proved our hypothesis to be incorrect, and that is something from which we can learn. For example, if the experiment’s hypothesis was that moving the “buy now” button to the top of the screen would increase sales by 5-10%, then (after collecting data from multiple customers) we could compare the sales figures for the button’s new location to its old location. An increase in sales could support the hypothesis; a decrease doesn’t. If sales were zero then we probably broke something and maybe that could be deemed a failure.
How do we make it safe to experiment? We must change our language but also we should observe the experiments closely and be prepared to abort them if we notice something outside of the expected parameters, e.g. sales dropping to zero. As part of defining our experiment, we should define an expected range (e.g. sales go up or down by 10%) – if moving the “buy now” button causes a 50% increase in sales (i.e. well beyond expectations) then perhaps something has gone wrong and we should reset everything.
While we’re thinking about the language we use regarding “failure”, another common phrase that needs to be stopped is “we failed the sprint”. Usually, this refers to the work planned for a sprint not being completed. However, sprints are timeboxes which means they end whether you are ready or not. Sprints don’t fail, they end. If the committed work is not completed, then I would still think twice about calling that a failure – it feels like the lead into apportioning blame, which is far from creating a safe environment. Incidentally, if the root cause of not completing planned work was found to be the product owner or senior management I suspect it would not be called a failure.
p.s. I managed to not reference the scaled agile framework or the scene from Marathon Man, so I’m calling that a success 😉
Firstly I have to mention the inspiration for this post is a recent(ish) episode of The Agile Pubcast where Geoff Watts and Paul Goddard (both in the UK) were joined by Chris Williams from Canada, so this one matched many of my interests 🙂
Chris mentioned sporting events to see in Toronto but he missed that the Wolfpack has joined the North American Rugby League and (hopefully) we’ll get to see some rugby again soon.
I will give him kudos for recommending the Loose Moose – I’ve worked close to it for a few years and have enjoyed many of the beers they have on tap. I’m definitely in for a meetup if Paul & Geoff make it to Toronto! (Blanche de Chambly is fine but try adding orange juice to turn it into a beermosa!)
Their topic was “the concept of mastery as a discipline, and how failure is still a stigma”. Definitions of mastery include “full command or understanding of a subject”, “outstanding skill; expertise”, and “possession or display of great skill or technique”; in general it relates to knowing a subject thoroughly.
Personally I see it more as a journey than a destination – unless your chosen subject is quite tightly constrained then there’s probably always more to learn. In my experience, often when I think I’m close to reaching a peak I discover that it’s a false peak and the real peak is further, or sometimes that there are multiple peaks that I could strive for.
Whether it’s a journey or a destination, I believe mastery is essential. But does everyone need to master everything? No, of course not – for one thing, it’s not possible to master everything! Also, that’s part of the purpose of being a team – each team member brings their own strengths and interests. There used to be a popular concept of “T-shaped people”, meaning an individual with expertise in one aspect and a broad understanding of others, and then teams would be the sum of these Ts (and similar shapes).
Whenever I discuss mastery it’s a fairly safe bet that I will bring up one of my favourite films: Jiro Dreams of Sushi (2011). It focuses on 85-year-old sushi master Jiro Ono, his renowned Tokyo restaurant, and his relationship with his son and eventual heir, Yoshikazu.
I find it amazing to watch someone who has spent decades mastering his art and to hear him talk so profoundly about his approach: “You must dedicate your life to mastering your skill. That’s the secret of success and is the key to being regarded honourably.”
How do agilists and sushi chefs get better? Incrementally. 🙂 “I do the same thing over and over, improving bit by bit. There is always a yearning to achieve more. I’ll continue to climb, trying to reach the top, but no one knows where the top is.”
As a prog rock fan, one of the musicians I follow is Robert Fripp (of King Crimson) and despite being recognised as a great guitarist he still practices for multiple hours every day. (Here’s a recent video clip of him talking about practice.)
I believe it’s important to take pride in what you do, and that means not just wanting to be good but wanting to improve. Those improvements often don’t come easily, and that’s where the discipline comes in – no-one can make you better if you don’t want to improve, so start by identifying the area(s) you want to master.
Watching the F1 Grand Prix this morning was a reminder that being at the pinacle of motorsport requires lots of practice; repeatedly rehearsing for various situations (e.g. a pit stop) is how teams build mastery and resilience.
It’s also interesting to hear the drivers talk about learning from their experiences; they focus on finding something which can be improved for next time, not wallowing in how they failed. They study how a problem occurred, identify the root causes, decide what to change, and then implement it. With minimal testing time between races, F1 is like testing in production – a mistake can be expensive so you try to minimise the risk but when something goes wrong (because eventually it will!) you make sure to learn as much as you can.
When I see failure being stigmatised, it’s often down to a misunderstanding of how we work. We cannot be right 100% of the time, so we try to reduce the risk by working in teams (“two minds are better than one”) and making small experiments. The evaluation of an experiment should show the hypothesis is accepted or rejected – the experiment isn’t a failure.
For example, if an online retailer were to propose that changing the “buy now” button to red would result in more sales, then they could conduct an experiment. The result might be that it does show an increase in sales; alternatively, it may show no increase. That is not a failure – it is a new piece of information. If the “no increase” outcome is called a failure, then we will end up demotivating the team and killing creativity.
Here’s an experiment to try: if we refer to the outcome of experiments as “discoveries” rather than “failures” then we will see more enthusiasm for conducting experiments and that will lead to a better product and a happier team.
