When failure takes too long

In a digital world, new ways of working are becoming increasingly common. One of these is Agile, which broadly refers to how we deliver solutions in an iterative and incremental manner, through collaboration between self-organising, cross-functional teams.

This can seem very exciting – an opportunity for rapid development, co-creation and evolving requirements, as the business adapts to learning's and change.

With Agile fast becoming mainstream, this may not be new for those of us already on-board. Nonetheless, where businesses tend to struggle with the introduction of this new way of working is the cultural change that it needs to represent as well.

Now, when I talk about culture here, I’m referring to our fear of failure. In a society that celebrates success, it’s human nature for us to not want to fail.  Failure suggests we didn’t plan, didn’t consider the options and ultimately let down our colleagues, managers, customers or even family.

Consider for a moment the last time you failed, what did that feel like? How much were you willing to share that failure with others? Announce it to the world?

Some brave souls would have stood up straight away and said, “Well got that one wrong, let’s have another go!” Now, think about the idea of failing on a regular basis. No – I don’t mean every day, but how you may have to keep changing directions while working on a project, as you become more knowledgeable on the pertinent challenges, to meet a projects objectives. How long would it take before your manager or even other senior leaders start to question what you’re doing, and wonder whether you’re the right person to be leading the project?

I’ve had some spectacular failures in my career as we sought to try new ways of working, introducing new capabilities or launching new offerings into the market place. However, I’ve also been fortunate enough to have some amazing support from my managers as I sought to pivot, recover or simply stop what we were trying to do and take a different approach (You know who you are and thank you for your belief!).

The biggest thing I have learned from these failures is simply to find my courage and highlight the risk or failure early, however uncomfortable this is, and no matter what the consequence might be. Unfortunately, not everyone has been as fortunate as I have in having some amazing managers – who understand that in the pursuit of some exciting goals, sometimes we get it completely right and other times spectacularly wrong!

It’s not uncommon that when a risk emerges within the business, an early view may be to classify it as “Amber” or even “Green” on the wishful basis that it will probably sort itself out before it becomes an issue. Unfortunately, it’s equally likely that with the passage of time, that initiative may not recover and in fact results in the risk becoming compounded due to collateral impacts.

These compounded risks can reach the point that they start to jeopardise the entire project. Given people’s natural tendency to want to show a project is performing well in its early stage, flagging this as an issue can make many folks nervous. Then one of two things will happen: either they will call out the bigger risk and wait for the bombshell of a response, with everything put on hold while a post-mortem takes place; or break down the main risk into smaller components, with the goal to resolve them individually and show that it is being managed.

I’m sure many managers who read this will say that they’re always supportive of their teams – and that all the team needs to do is raise the concern for the manager to help them solve it.

Now put yourself in your team’s shoe: when you wanted to be successful and prove that you could solve things on your own, how willing were you to call out issues on a regular basis without being seen as incapable of delivering on the outcomes?

At this point, I can anticipate the question many will be asking: what in the world does this have to do with Agile ways of working? Simply put, failure is a core aspect of Agile. In fact, you will meet many Agile coaches who say that the Agile methodology cannot be truly successful without failure.

Agile methodologies can let you achieve outcomes faster, by breaking deliverables down to their smallest component or feature you’re looking to develop. The Agile way of working requires teams to be empowered to define what they should prioritise to build first, to realise new and exciting outcomes without being encumbered by a fear of failure.

Two words leap off the page for me now – empower and failure.  Both are important and intrinsically linked to each other. What level of decision making would you be prepared to cede to someone in your team, who is leading a development project? How often would you insist on them checking in with you?

Insisting that failure is necessary for Agile to work doesn’t mean we simply sit back and watch teams continuously fail. Sometimes, intervention or a change of team member is required. Even as we empower our teams, it’s equally important that they know the standards expected of them –  whether it’s the performance of individuals or the overall team.

In setting the expectations and standards while providing the right coaching, we enable the teams to grow in the direction the business needs. I like to refer to these as the guardrails – giving people the reassurance and sense of security they need in the early days of Agile, that early failure is acceptable in the development of new capabilities. As those teams mature, these guardrails become less necessary as the team knows what is expected, and more importantly start to set their own expectations of the business as well.

To be clear though, giving greater flexibility and autonomy to teams doesn’t mean development paths look more like a bowl of spaghetti, with new capabilities created all over the place. Development teams still work to a roadmap and continue to have a prioritised view of what the sequence should be in the development of features. This lets them achieve an end goal, whether it is a new offer to market, a new system deployment or even customer deployments.

In a nutshell, Agile can be an exciting path for businesses to embark on, but it is merely a set of instructions for business leaders to follow. Simply following the said instructions doesn’t always translate to the desired business changes or accelerated outcome. For this way of working to thrive, it is imperative for business leaders to change their culture by providing the bandwidth for teams to learn, iterate and grow, without the fear of failure.

We need to recognise that without taking on the responsibility ourselves in driving this change in business culture, we will be left with teams that have been asked to embrace a new way of working that will ultimately lead to failure. This comes about when teams try to manage every risk scenario themselves, avoid the “bad news” conversation and try to be all things to all stakeholders. The result?  A workplace fixated on risk avoidance, which eventually leads to demotivated teams, increased cost of change and missed objectives – all because failure took too long.