Be agile about agile
The proliferation of agile management techniques is broadly to be welcomed. Yet keep an eye on the conflicts and consequences of adopting agile and be open-minded about mixing and matching old and new.
The rise of agile
The reasons for companies embracing agile ways of working are familiar – to speed up innovation and accelerate change in the fast-moving, volatile world we inhabit.
Techniques that originated in the software industry and start-up space have gone mainstream, with organisations of all sizes and shapes seeking to add a bit of agile - sometimes just a dash and sometimes a big dollop.
There are many denominations to choose from. You can become an acolyte of Atlassian, a servant of Scrum Alliance, a member of McKinsey or adherent of Accenture Agile Transformation. Each bring their own twist to the underlying ideology and rituals of agile, sometimes defining competitive points of difference in a way that would make the Judean Peoples’ Front blush (see ministry of Monty Python).
At April, we’re less interested in ideological and methodological hair-splitting and more interested in the practical impact and application of agile.
We spoke to a number of c-suite leaders who have introduced agile techniques in large, mature organisations. We found emerging themes about steering clear of dogma and how to be a bit more agile about agile.
The primacy of mindset
Let’s define mindset as the prevailing attitudes and behaviours in an organisation. In other words, the culture that defines ‘how we do things around here’.
What Drucker meant when he talked about culture eating strategy for breakfast was that the actions and decisions of an organisation (ie what actually happens) are much more strongly influenced by prevailing culture than any statements of strategic intent. And if culture eats strategy for breakfast, it will devour agile for lunch.
No amount of communication or exhortation to follow agile behaviours will overcome an entrenched culture and mindset that values process over people, perfection over learning and contract over collaboration.
To activate a mindset shift, a number of parallel steps need to be taken:
involvement of leadership in designing and implementing agile ways of working
demonstration of ‘what good looks like’
making it easy for people to ‘give it a try’ in a safe, low risk environment
hard wiring of KPIs and performance management that rewards behaviours you want to encourage. For example, think about optimising ‘our resource’, not ‘my resource’ or rewarding performance of the overall keyboard, not the fastest key on the board.
When silos meet agile
Organisational silos are there for a reason. They provide centres of expertise for essential functions and a clear hierarchy for people development. They provide a point of control and accountability for budgets. We need silos!
Yet the multi-disciplinary, self-organising teams of agile break all the rules of silos. If you move from a silo to an agile team, you may ask yourself:
how does this contribute to my professional development and what does my development pathway look like?
how do decisions get made and who has the right to decide or veto?
who owns and controls budgets?
Unless agile projects are governed within an overall enterprise framework, these questions will prove impossible to answer. Rather than seeing it as a competition between silos and transversal projects, see it as a collaborative challenge for a team to solve in pursuit of common goals.
When waterfalls meet agile
It’s something of a cliché in modern corporate life that traditional, waterfall methods of project management are deemed bad, while agile methods are good.
We would argue that both have their place - the real trick is to blend the two. Within a traditional governance and programme management, seek to identify the challenges that would most benefit from an agile approach. Typically, these will be those projects where the destination is uncertain and the complexity of the challenge is high.
There is also a watch-out for hardcore agile, where the methodological discipline can create new rigidities. If teams are deployed and focused around sprints and quarterly cycles, it can be hard to remobilise within that period, even when it’s obvious that you need to.
Fail like a scientist
Taking risks and learning from failure is an essential tenet of the growth mindset (as articulated as part of the original Agile Manifesto). However, if you are a regular corporate citizen who has got to where you are today through the mastery and perfection of your chosen discipline, the very concept of failure is a turn-off, even if it’s fast!
Taken further, the notion of celebrating failure sounds risible, and certainly not the smartest way to get ahead. The savvy political operator will know that it’s better to dissemble and deflect failure rather than own it and seek to celebrate it.
Perhaps we need to borrow more from the world of science and less from politics? When confronted with new information, the scientist treats it as a positive learning opportunity whereas the politician worries about being wrong or the consequences of being seen as indecisive.
Servant or servile leadership?
In the context of agile, leaders are there to set targets and direction and then get out of the way, clearing obstacles and securing resources to empower their organisations.
Servant leadership is less about a traditional, ego-led, command-and-control approach and more about a service ethos and mission-command approach.
But it can be hard to gauge where positive, informed delegation stops and passive, half-sighted abdication starts. Agility can morph into anarchy unless leaders have good information and the ability to steer and prioritise activities.
This can be where the truly effective servant leader will seek feedback from teams – to help clarify the role they are playing and what the team wants from them to deliver maximum value.
Relearning change management
Many of the success conditions for implementing agile are no different to those for any strategic transformation exercise that will involve significant structural and behavioural shift before a benefit is apparent, ie pain before gain.
Make the case for change, whether it’s a burning fear (of potential future loss) or a burning pain (that’s being experienced now) and ensure there is genuine leadership commitment. Ironically, agile cannot itself be positioned as an ‘experiment’ where the option exists to abandon. It must be seen as an essential response to an existential threat, otherwise take-up will be half-hearted.
Spend more time than you think up front in the design of the approach and the engagement of those who will be involved, especially leadership, and recognise it will take longer than you think to implement.
Adopt a campaign-based approach, co-creating the vision, actively communicating early successes and learning from failure, giving people the support and resource to support change.
Remember that you will be navigating the peaks and troughs of change with an inevitable early productivity dip, the excitement of quick wins, the premature declaration of victory, the relaunch and the gradual normalisation of new ways of doing things.
To get the best out of agile, stay away from the dogma. Mix and match to create an approach tailored to your context and organisation and constantly test and learn with the overall approach. Be agile about agile!