«

»

Feb 25

The Agile Mindset – Perceptions around Failure

If I used the word failure to you – what does it bring up for you?  What sort of feelings, images or thoughts does it conjure up?  Failure is an evocative word that sends shivers down the spines of the most macho of males.  It is a dirty word in many organisations with a traditional or fixed mindset as failure perceived as “bad”, or “wrong” or “negative”.

An Agile mindset, however, regards failure differently. In the Agile community we have an expression:  Fail often; fail early.

There is no failure; only feedback

Failure is a necessary step in the process of learning.  One method through which behaviour change happens is by carrying out behavioural experiments.  Not all experiments “succeed”, but they all give us results.  This is why I personally like the expression which I learned on my NLP Master-practitioner training which embrace  this learning perspective “there is no failure; only feedback”.  However this viewpoint is often scorned and shouted down by managers and leaders who have little tolerance for failure and see it as a “cop-out” by “losers”.  These prehistoric managers and leaders are all about the “bottom-line” or the impossible schedules that they inflict upon people. I often hear the expressions “failure is not an option”, or “we don’t do failure” from these type of people who see little value in learning, let alone gaining any learning from mistakes.

But let’s put aside for one moment those managers and leaders who choose not to change or who are so defended against any criticism, because for these type of managers Agile is seen as a way of doing more with less or getting more out of their people than they are already giving.  This in my opinion is not the true purpose of meaning of Agile and I suspect that type of manager had already quit reading this article two paragraphs ago.

An Agile mindset reframes the experience of failure

So Agile embraces the notion of failure. Well, let’s be clear on this.  It’s not like we are saying that failure is “good” and that we shouldn’t care about our results or outcomes.   The Agile mindset, however, perceives failure differently.  Traditional perspectives of failure are strongly associated with the notion of losing; if we fail we lose.  We may perceive that we lose face or that others will lose faith in us as a result of our failure.  The Agile mindset reframes failure; failure is a result, not a verb.  We as individuals don’t fail and we are not failures if we fail more than we succeed, but our experiments might not give the results we desired or expected.  Thomas Edison was interviewed after his success with the invention of the incandescent light; “So Mr Edison, how did it feel to fail 10,000 times?” He replied with “I didn’t fail – I found 9999 ways that didn’t work”.  This is a healthier attitude towards failure don’t you think, otherwise we might still be sitting around in candle or gas light waiting for the light bulb to be invented.

An Agile mantra: fail often; fail early

From an Agile perspective we do embrace spotting and acting on our failures sooner rather than later.  Take for example the business case.  This document is written in part as a means of keeping checks and balances on a project to ensure that business benefit will accrue at some point once the solution has been deployed.  But how many project managers or business leaders continually check progress against the business case to ensure they are still on target.  From my experience not many! Circumstances may have more than likely changed from the first day the business case was accepted and signed off.  If may well be that shortly after starting the project that it may not deliver on business need, so maybe the sensible thing to do is to abort the project.  But what happens when people have checked and discover that the business benefits of delivering the project will never be realised? All too often people are more concerned with the personal and group psychology surrounding sunk costs and/or  saving face.  Is this because they will be perceived as having failed or worse yet be failures?  In this instance how could it even be considered that someone has failed as a result of the business context or environment changing, but yet that’s how Agile thinking or an Agile mindset gets sabotaged; through flawed and unchecked subconscious thinking processes and the repetition of self-defeating behaviour.  It takes great discipline and courage but often it is wise to cut our losses, fail early and learn from the experience.

Failure as an inevitable part of learning

All of us of us were children at one time and except for an unfortunate few, most of us learned how to walk.  I wonder how your parents treated you as you learned to walk.  Were they critical and abusive to you every time you stumbled and fell over?  Did they shout “get up you idiot, come on you loser – start walking!”  I hope not.  But this might seem amusing to think of somebody treating a mere baby in this way, but yet this is a strategy that many leaders and managers use to varying degrees on themselves and sometimes on their people.  They condition their people to “not fail” because if they do the consequences will be unpleasant, who wants to be bawled at in the middle of the office?  This attitude and accompanying behaviours are restrictive to the learning process and will limit the creativity that is so desperately required in many under-performing organisations.  (Notice I did not say failing organisations 🙂 .)  What many people have forgotten is that failure is an inevitable part of learning and that most often we fail our way to success.

If failure is learning; why does it feel so bad?

Failure is uncomfortable because of the meaning that we assign to it and the beliefs that we have about it.  I have provided some explorative questions below to help you reflect on failure and its meaning to you.  In many of the people that I have coached the root causes of failure are found in childhood where failure resulted in some punishment either in the form or verbal abuse or loss of love or acceptance in some way from our care-givers or people in authority.  Failure often translates into “I’m bad” or “I’m not worthy” or “I’m not good enough”. The ABC model used in cognitive behaviour therapy helps us to understand that it is not the activating event (the “A” in the ABC model) that causes us us stress, anxiety, frustration or whatever (the “C” in the ABC model); instead it is our beliefs, thinking, assumptions (the “B” in the ABC model) that causes our grief.  So by changing our thinking we can change our responses to ones that are more appropriate to learning from our failure rather than beating ourselves up or looking for people to blame for it.

Change your mind …

So to acquire more of an Agile mindset we need to change our minds about what failure means to us and I’m wondering what sort of reframes or re-decisions you can make about its meaning to you.  I would love to hear some of your thoughts so please post your replies below.  I’ll give you a few to get started:

Without failure there is no learning; There is no failure; only feedback

Explorations and Reflections

Here are some personal reflections that I encourage my clients to explore as we make the journey to acquiring a more Agile mindset.

  • What does failure mean to you?
  • What does it say about you if you were to fail?
  • How do you react when you fail? Do you accept responsibility or do you look for the scapegoat?
  • What about others who fail?  How do you perceive them?
  • What is your personal reflection on “there is no failure; only feedback”? Is there a truth in there?
  • What do you observe about how other people respond to failure?

If you would like more insight and support into changing your thinking …

If you would like to learn more about how you can take control of your thinking as a way of improving your performance or that of your team then take a look at the inner coach process.  It may be the last time you will ever need to use a coach! Click here to find out more.

0saves
If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

About the author

Mark Buchan

Mark is an Agile Consultant and Executive Coach who specialises in working with leadership teams when they are transforming their organisation to a more Agile way of delivery.

3 comments

  1. Jack

    I don’t consider failure final. I like your idea that failure is feedback. Like you, I seek to figure out what I can learn from failing a task or totally screwing up. Then I decide if it is worth fixing or if I take what I learned and move on. It’s important not to take failure personally. It doesn’t mean you are a failed person. It has nothing to do with you as a person. It is about a task.

    Personally, I believe that if you are not failing, that means you are not taking appropriate risks, getting outside your comfort zone. If a person is constantly staying safe, it means they are not growing. So, please, make sure you have some failures under your belt!

    1. Mark Buchan

      Thanks Jack. As ever your comments are spot on. I am reminded of Dwecks work in her book Self Theories. People who have a belief that intelligence is something that you are born with (and ultimately theres nothing you can do to improve it) are less likely to take risks or rise to challenges because they have a fear of looking stupid. They prefer to take on tasks that align their beliefs that they are intelligent and hence the task is easy. I think this is an amazing and very insightful area of research that helps us understand more about peoples motivations towards (or away from) the tasks they choose.

      Thanks again for your comments.
      Warm regards
      Mark

  2. Agile Software

    Hello,
    Nice article,
    If may well be that shortly after starting the project that it may not deliver on business need, so maybe the sensible thing to do is to abort the project.
    Thanks & Regards,

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site is protected by Comment SPAM Wiper.