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.
