Organisational Agility: More than just stand-ups and sprints
The benefits of introducing organisational agility are slowly but surely starting to crystallise in the minds of leaders. With research showing that the top 10 percent of financial performers are 30 percent more likely to display Agile characteristics, the case for transformative change has never been clearer – particularly as the world tries to navigate increased economic uncertainty.
However, when looking to embed enterprise-wide agility, leaders often fixate on the wrong things. They start to measure themselves against internal metrics – convinced that “becoming agile” is the ultimate goal. For example, whilst it may be a useful indicator that the team is adopting more agile ways of working, comparing stand-ups or numbers of outputs completed doesn’t truly articulate the impact organisational agility can have. Instead, leaders should look to the benefits agility can bring – such as becoming more customer-centric – and base their goals and subsequent measurement of those goals on these instead.
So how can leaders reframe how they position and assess organisational agility to reap more of its benefits?
Shifting from project to product to better focus on customers
When we work with a project-style mindset, we tend to fix the scope – listing out everything that must be done to call the project ‘finished’. Then, we estimate the time it will take, the number of people required, and the cost. And we are, invariably, wrong: projects take longer and cost more, often because we’re estimating when we have the least amount of information.
With a product-led mindset, we flip that on its head: fixing things like cost, people, resources, and even the quality we desire, and then move onto the features that we will deliver. For example: over the next quarter with a fixed team of 125 people, we intend to deliver one or two important features. Taking this approach will ensure that teams focus on completing the most valuable features first, not the complete wish-list of everything. This mindset shift will allow organisations to remain centred on their customer, rather than internal project plans.
We introduced this quarterly planning and prioritisation approach in a Global Tier 1 Bank, which helped them prioritise back-end improvements to their core banking platforms which enabled valuable updates to be made to customer-facing apps and online banking services, whilst also looking at the longer-term structures of teams and backlogs.
Shifting from big-bang releases to small batches to reduce risk
Big-bang releases increase risk to an organisation. The time between designing, building, and releasing changes and products can be long and complex – and customer needs may have changed in that time. Small, incremental batches and improvements reduces risk, by allowing us to pivot quickly.
Take, for example, the difference between mainline train journeys and the London Underground (or Subways and Metros in other cities). Mainline trains are often long and infrequent – there is huge potential for disruption and the risk of not making it to a destination in time is fairly high. However – when you think about the Underground network, trains are much smaller, more frequent, and there are plenty of options. If one is full, another will be along in a couple of minutes. If there’s a delay on one line, there is always another way. The risk of not getting to a destination is much lower with these smaller batches.
It’s the same at work. Small, frequent deliveries of value to customers reduces risk and gives us many more options if – and when – things go wrong. This mindset shift allows organisations to speed up time to value, putting customer experience at the forefront of all releases.
We’ve supported financial services organisations to use DevOps tools and automated testing, so that developers can work on much smaller batches of code, test them, and put them into live production with greater regularity. By using these tools, it also becomes much easier to roll back any errors, thereby reducing the risk of breaking systems with big-bang releases.
Shifting from ‘push’ to ‘pull’ to empower teams
In our work across many organisations, we have seen that leaders typically push work onto people – they start up new teams, create new environments, and set up working groups and committees with the expectation people will just juggle things. However, when you look at flipping this on its head – allowing employees to pull work towards them as and when they have the capacity – efficiency and delivery improves. This latter way of working is very common on production lines in the manufacturing space – in fact, it’s this very discovery that reduced the time taken to manufacture early Ford motor cars from over 90 hours per car to around 12 hours.
Trusting employees and allowing them to work in recognition of their capacity and strengths also has a positive impact on overall performance and job satisfaction, empowering people to show up as their very best selves. This might mean trusting product leaders to have the final say on top priority features, or allowing members of a development team to say ‘no’ when they’re already working on something , even protecting capacity for people to try out new ideas through hackathons, learning, and development.
We worked with a marketing team in a financial services organisation to introduce a pull-based production line-style system into their workflow. They immediately identified where the bottlenecks were in approval committees and sought to reduce them. They also put in a limit of three campaigns at any one time. By using a pull-based system, working on no more than three email campaigns at a time, they were able to reduce their lead time by 20 percent.
Making these shifts will help to accelerate organisational agility – and its benefits – to truly flourish. Moving away from measuring individual team behaviours, such as stand-ups and sprints, leaders will be able to better focus on their strategic reasons for adopting organisational agility – namely driving greater customer-centricity.