Agility: it's something that every organisation claims to value, and is often touted as one of the cornerstones of modern business success. And yet, it’s also something that many businesses seem to struggle with, as agile initiatives wither and die while employees fall back into old ways.
So why is it so hard to get agile to stick within larger organisations, and how can tech leaders set up agile projects for success and long-term adoption? In this month’s IT Pro Panel discussion, we spoke to some of our expert panellists to find out how they’ve tackled this delicate issue.
Defining agility
One thing that all of our panellists agreed upon was that building a truly agile business is about far more than using agile methodologies, drawing a distinction between agile development and business agility. They also highlighted that the true measure of agility is not the speed at which an organisation moves, but the speed at which it reacts.
“Agile for me is a cultural mindset,” says Moonpig CTO Peter Donlon. “I think it's too easy for leaders to see agile as a framework or terminology that's magically going to transform that organisation. The reality is, it's a different way of thinking that can feel uncomfortable to some at first. Within Moonpig, I see it as our ability to respond quickly to change in the market, our willingness to take risks and our ability to learn from those risks.”
According to TRX CTO Dan Jacobs, many organisations try to use pre-rolled agile frameworks as a shortcut to true agility, but they’re often implemented without the spirit of agile.
“Being agile means being able to respond quickly to change,” he says; “To change direction, radically if needed, in a short period of time. I see an agile methodology adopted in many places, but no agility - agile without being agile. The process can get in the way.”
Similarly, Just Eat CISO Kevin Fielder notes that using agile development without adopting the mindset more broadly does not equate to agility. “You can even be agile in your dev, but still slow,” he says. “With my security hat on, I also think you can be the reverse - you can be an agile security team delivering at pace and able to pivot, even in a non-agile organisation.”
Data is essential, says Jacobs, and you have to be willing to make course corrections based on what works and what doesn’t. A further consensus was that without firm and wholehearted buy-in from senior management, any agile efforts are doomed to failure.
“I completely agree with Dan and Kevin,” Studio Graphene co-founder Ritam Gandhi says. “Agile needs to be embedded within an organisation’s DNA for it to work and this has to come from the leadership team.”
How do we achieve agile?
Gandhi adds that an essential part of the agile mindset is allowing for failure and creating a culture in which failures are not punished, but used as an opportunity to learn and adapt. Using a hypothesis testing approach is also key, through which organisations can validate their assumptions and ensure they’re taking the most appropriate action.
“I think you can solve a lot of the blame and fear of failure problem through transparency and sharing early,” Donlon muses. “I think the more people are brought on the journey through the formation of a hypothesis, through the testing, to the outcome, the easier it is to avoid. The ‘ta-da’ moment isn't as good as it sounds!”
“Part of the challenge with agile that I've seen is that sometimes we set too many rules,” says Gandhi. “Every scenario is different. It's important to determine a length of time for each test cycle, but it should depend on the specific scenario. The question to ask is, how long will it take us to test this hypothesis to achieve a degree of certainty which is sufficient. It may be two weeks, it may be two months – it all depends on what you are testing.”
Jacobs is a firm advocate of ‘minimum viable product’ testing, which enables companies to test new ideas without going through a full development cycle. He says organisations should be aiming for shorter testing cycles, but the important thing is to ensure that cycles are long enough to provide meaningful results.
“I think the key thing there is ‘meaningful’,” Donlon offers. “I'm personally a big proponent of A/B testing where possible, and then the length of time required comes down to the ability to get to a statistically significant outcome. I think the key thing is then being pragmatic on your definition of statistical significance.”
“The key is to not be too prescriptive,” Gandhi explains. “It's impossible to define everything, otherwise you get stuck in the same bureaucratic red tape. Hence, it's something that has to be encouraged. The leadership has to encourage their mid-level management to take risks and if they believe in a hypothesis to test it (without always worrying about being disproven or failing).”
Unwrapping the red tape
All of these points are relatively easy to implement within a small organisation or team, but according to our panellists, they’re much harder to apply within a larger company.
“I think it's a really hard problem to solve in larger and especially older or more established organisations,” explains Donlon. “There are some semi-successful cases of businesses spinning off their ‘digital’ businesses into separate entities to enable agility without transforming the whole organisation, but eventually, you'll hit some process or governance wall.”
Jacob notes that areas like R&D and product development are generally the departments that most need to be agile. Focusing on making these divisions more agile, he says, can be a good way to introduce agility to a larger corporation more broadly. Donlon, however, argues that this approach comes with its own risks.
“The challenge comes in whether you can isolate those areas enough to avoid the agility being broken at some stage in the development cycle. Having lived this myself in a past life, you can be as agile as you want, but if you then hit the governance machine (usually towards the end of the process), it breaks it quite easily!”
“I totally agree,” Jacobs adds. “This is why it needs buy-in and embracing from the top, to create space for R&D to be properly agile. ‘Governance’ is often a code word for bureaucracy – and people wanting to get their sticky paws on things.”
In Donlon’s experience, financial cycles, processes and governance can make agility taxing in larger organisations. These cycles are often years if not decades old, he says, and breaking them can be difficult, requiring close collaboration between technology leaders and upper management.
“That's where it's been slow progress in older organisations where technology is only just making it to the board room table,” he says. “For a long time, I think agile was seen as an IT thing, but I definitely think that's changing. For teams to really embrace agility, I feel the organisation has to as well.”
One reason larger businesses struggle with agile is that it clashes directly with their need for predictability and their desire to plan as much as possible in advance. The nature of agile thinking means that, thanks to the rapid changes in strategy and approach that come with it, forward planning becomes a lot more difficult.
“With agile, you can have deadlines,” explains Jacobs, “but you can't predict what will be delivered on those deadlines. With a waterfall approach, the projects never work anyway - and they’re usually late and over budget. Agile gives you more control.”
“Exactly,” Gandhi adds, “it's a false prophecy. Everyone thinks waterfall gives more control, when in reality the lack of flexibility actually makes things not go according to plan. Yes, big companies need to set goals, targets, budgets et cetera. But how you get there needs to have an inherent amount of flexibility built-in.”
Planning for success
Another approach is to set up a mini-organisation within the business that can act in an autonomous, agile way – similar to how Centrica set up Hive as a self-contained company within British Gas. This approach is becoming more common as a way to both cut through red tape and minimise the wider company’s exposure to potential fallout from failure, Gandhi notes.
Fundamentally, getting the right approach to ensure sustainable adoption of agile is a tricky task, and the answer will look different for every business. For Studio Graphene, for example, the challenge has been balancing a desire for agile practises with clients’ demands for more traditional approaches.
“We are a services business and it's been a challenge because clients want ‘waterfall’ commitments,” Gandhi says. “We've essentially embedded a hybrid solution. We operate as an agile organisation internally, but we provide waterfall commercials to clients. This satisfies both needs. I still think we have a long way to go before we have embraced agile fully, but I would hope to think we have made more progress than many of our other counterparts and equally made more mistakes in our journey than others would have made too.”
For Moonpig, meanwhile, the process has involved giving teams more autonomy to choose their own processes, trusting that they will have enough maturity to do it properly.
“We've been on quite a journey at Moonpig,” Donlon explains. “As a very tech-focussed online-only business, it's probably been easier for us to improve our agility than maybe it is for some others. I think the learning along the way has been while the agile mindset needs to be throughout the whole organisation, agile methodologies and frameworks do not. We've had the entire company work in a squad-type model, which was maybe a step too far as it was enforcing a way of working on everyone. We took a step back and have found something that works well for all teams.”
“From a methodology point of view, we let our teams decide what works for them. Predominantly, our teams choose Kanban but we do use scrum as well. I think the key thing is being pragmatic about the use of frameworks and seeing them for what they are. As soon as you start being dogmatic, the system breaks and scrum can start to look a lot like waterfall!”
One thing that all our panellists agree upon is the fact that, whatever your approach, agile needs to be something that the whole business gets behind.
As Donlon says, “the minute you make it a ‘tech thing’ is the minute it’s doomed to fail."
If you're a senior IT decision-maker and you'd like to apply to be part of the IT Pro Panel, please email panel@itpro.co.uk.
