Everyone knows that agile is the way to organise and get things done. But beyond the hype, how many people really know how to use agile when it gets beyond the single team, and is desired to be applied in a large-scale, distributed organisation? And how many can adapt their governance and risk management framework to work with a scaled agile environment? Or are you stuck in the horrible world of ‘Wagile‘?
This is a really interesting topic for me, because when I first came across agile, it hugely appealed to my core sense of how things should be done, but I’ve seen first-hand the challenges in scaling this in established enterprises. I believe it’s one of the most critical topics for leaders today.
A quick overview of agile
Agile was originally a manifesto of principles, and other methodologies such as Scrum, Kanban and XP are generally now intermingled under the same banner. The base concept is that you have a small team (~8 people) that has all the functional disciplines needed to deliver the desired solution (e.g., product, design, development, testing). This team has an overall mission, and is empowered to decide the best way to deliver the customer’s needs. The team works in short bursts called ‘sprints’ (1-4 weeks), with the output of each sprint ‘shippable’ (though what this means has different interpretations!).
A ‘backlog’ of user-focused features (‘stories’) is maintained, with the top-priority items from this taken into the next sprint. After each sprint, the team reflects on how they can improve, and seek to implement this in the next sprint. Typically, agile gets mixed with lean, which in a design context advocates an approach of customer- and data-led design, developing a Minimum Viable Product that can be released asap to customers to understand demand and feedback in a live, data-driven manner as early as possible. Increasingly, agile is also interchanged with DevOps, which is the concept of having engineers in one team covering development, testing and production operations, rather than split into traditional functional verticals (as well as high levels of automation of testing, integration deployment, etc).
There is more beyond, well covered in seminal books by Jeff Sutherland, Eric Reis and others. But I’m sure most readers know much of this. The far more interesting topic is how you scale this to many (e.g., tens/hundreds) teams across a large-scale organisation.
How can you use agile at scale?
Spotify and Netflix have led the way here in publishing great open source public info on the topic. Into other industries, in financial services ING was one of the first movers, where it moved its Netherlands retail bank HQ functions to scaled agile in 2015, and recently ANZ announced it planned to do this across its business in 2018. Many organisations have partially adopted it, typically across the digital/IT areas, but not into the core organisation of the BAU HQ business functions (product, marketing, etc).
There is a Scaled Agile Framework (SAFe now on version 4.5), which seeks to formalise a set of foundations and tools for running scaled agile, though again is primarily change/IT-focused rather than fully across the organisation.
All business functions must use agile
In my view, the objective needs to be to operate all relevant business and IT functions in an agile manner, because otherwise there’s always friction at the joins, where those operating agile need to work with those following traditional methods (particularly when it comes to governance and approval processes).
The basic design of a fully scaled agile organisation was set out in Kniberg and Ivarsson’s white paper ‘Scaling Agile @Spotify’ from 2012:
The new order
The organisation is designed against customer-facing services, which are covered by ‘Tribes’, which in turn consist of a number of ‘Squads’ which are individual agile/scrum teams. A functional dimension (‘Chapter’) is present running across the Tribes/Squads covering a particular discipline (e.g., UX design) to provide best practice sharing, career and skill development, etc. ‘Guilds’ are also formed by individuals with a common interest in an area. The Squads are empowered to deliver continuously against their particular mission, and the desire is to minimise any handoffs between teams. Typically this structure is much flatter and involves less middle management and more people ‘doing’ than a classic organisation. The overall aim is to have ‘Minimum Viable Bureaucracy’.
Some of the terminology will sound pretty weird to a traditional organisation, but essentially this is about aligning cross-functional, empowered teams against specific customer services, and aligning those teams into wider groups covering broader customer value streams, with a matrix horizontal dimension to provide functional expertise. Which makes a lot of sense to me.
Four keys to success
With this context, I believe there are four keys to success. These may sound easy, but creating these can be extremely hard, particularly in a large organisation that’s seeking to move from a traditional organisational setup:
- The right mindset and talent
- Creating a culture of learning
- Having the enabling architecture and infrastructure
- Achieving the balance between autonomy and alignment.
Lets dive into these …
The right mindset and talent
Mindset is key to change, and needs to be led from the executives and spread across both leadership and staff. Operating in a fully agile environment is very different to traditional structures. Some leaders will miss the status and ego symbols of a hierarchical structure and associated perks. Some staff may feel uncomfortable being empowered rather than having decisions taken for them.
Have the right people
So having the people who want to be on the bus, and training those people in a common language/ways of working by providing agile coaching, is critical. ING in the Netherlands went for a very bold approach here, where 3,500 people had to apply for new jobs in the fully restructured organisation (with 30% reduction in roles), and assessed people entirely on mindset and cultural fit for the new roles. They then applied a cadre of agile coaches to help people succeed. This is a bold, turbulent and high-churn approach, though they seem to have achieved strong results coming out of it.
Strong vision leads to good motivation
Done well, scaled agile is very motivational for staff. But if the vision from the top isn’t sufficiently powerful, and there isn’t the critical mass of people with the right mindset, any scaled agile transformation will fail. People have to believe in it and unlearn much of how they’ve worked in their career so far. This is particularly true at the leadership level, as returning to old ways can so easily undermine the desired culture (e.g., micro managing rather than empowering).
Always Day 1
In terms of mindset, various people also talk about the need for a “constant (external) sense of danger” to underpin continuous customer-focused improvement. This is probably best espoused in Jeff Bezos’ latest letter to shareholders on why it’s always Day 1 at Amazon. This is a great read, calling out how people need to always be on their toes, making decisions fast, and thinking how to make things better for customers, or else they will be overtaken.
Creating a culture of learning
On the topic of culture, this goes hand in hand with mindset and talent. And it’s here that leaders’ role modelling is most critical.
Agile thrives off a culture of continuous learning. Staff want to improve and diversify their skills (so important in today’s fast-changing environment – there are no more jobs for life). Teams want to improve what they deliver to the customer, and their ways of working to maximise velocity and quality in delivery.
No fear of failure
And probably most critically, there mustn’t be fear of failure – learning what’s most valuable to customers always takes iteration. Traditionally, organisations picked a specific project on a detailed five-year business case, and judged success on whether it delivered the stated results in the stated timeframe. This rarely actually worked out, but has ‘fake comfort’ to it for leadership. The lean-agile approach advocates that leaders must create an environment where teams rapidly try what they think is best on an MVP basis, utilise live data to evaluate success, and share positive learnings from when this doesn’t work out.
Small releases, big learnings
Critical to underpinning this in my mind is what Spotify describes as ensuring the “blast radius” of failure is non-lethal … So if change is done on a ‘Canary Release’ basis – regular, small (rather than large/monolithic), and to a small subset of the customer base – and then found to not work (technically or user-wise), this is a limited blast radius from which positive learnings can be encouraged. The opposite, and more classic approach, is the big project delivering after 18 months to a wide selection of customers. If this goes wrong, it can have all sorts of regulatory, risk, reputational and commercial dangers.
Having the enabling architecture and infrastructure
One key element of enabling this culture of learning and ability to safely fail is the technology architecture and infrastructure. I believe this has three critical ingredients:
- A micro service rather than monolithic architecture, with services not interdependent. To limit the blast radius if one service is down, it must not take other services down with it, and changes should be simple to back out (rapid recovery).
- Automation tooling and techniques such as Continuous Integration and Continuous Deployment/Delivery, to underpin the cadence of sprints and deployable sprint output approach (NB deployment and release are decoupled) – though may not be easily achievable with legacy systems.
- Infrastructure to allow detailed A/B testing across the different dimensions of a product (well beyond websites!) in order to understand customer reaction, and ensure decision-making is driven on how the product is designed and backlog is prioritised.
As Spotify sees it, certain squads – whose clients are the other squads – should focus on making the infrastructure as enabling for the external customer-focused squads as possible.
Finally, the ways of working regarding architecture are also key in enabling speed. In the Spotify case, squads own particular elements of the architecture, yet other squads are allowed to change the code for another squad and then get it peer-reviewed for acceptance in order to minimise handoffs. This approach won’t appeal and may not be right for all (who may desire more architectural strategic intent), as it may lead to complexity over time, but it’s efficient in maximising empowerment speed.
Achieving the balance between autonomy and alignment
All of this may leave someone in a leadership position wondering exactly what they do, and how any degree of strategy or consistency is achieved in a scaled agile model!
Alignment and empowerment
It’s important to emphasise scaled agile isn’t a free-for-all of startups doing their own thing. All practitioners will talk about the importance of how you achieve the balance between alignment to a common strategy while still allowing the empowerment of teams to solve problems in the way they think is best.
The role of leaders
The role of the leadership is to provide a compelling vision, and to articulate the high-level missions for the tribes/squads. The role is also to help remove blockers that are impeding teams, and to encourage the culture of best practice sharing and learning across the firm. It’s definitely not to get involved in making lots of micro-level decisions.
Amazon is now a huge organisation with over 340,000 staff, but very much manages to achieve a powerful drive from Bezos’ executive team on long-term strategy that provides the roadmap for the organisation, yet with real speed of execution from the individual teams working on the ground; all with a huge focus on improving things for the customer.
One process a number of firms use to achieve this alignment-autonomy balance is the Quarterly Business Review (or a similar method called Program Increment Planning under SAFe). This involves getting a whole tribe together quarterly to sketch out the next three months’ objectives, and in particular to look at interdependencies and alignment between squads. A short output of this is produced for each tribe, and this feeds into a cross-tribe alignment and dependencies discussion. Summarised output can be visualised at tribe or enterprise level on a programme or portfolio board. Clearly, the plan can and will change as the weeks progress, but there’s an outline that’s being aimed for that allows different teams to know how what they’re doing can (or needs to) fit with what others are doing. Importantly, these exercises should be bottom-up via the people working within the teams, unlike traditional top-down planning exercises – it’s critical that those doing the work know the context around them for motivation purposes, and for dealing with dependencies.
Care on incentives
Overall autonomy under scaled agile seeks to move the authority to where the information is, and in general this makes a huge amount of sense. One area to take care of and be thoughtful about in this context is how you incentivise staff. Incentives have a long history of distorting how people act across a range of industries. So care in having incentives that are focused on sustainable growth, rather than skewed to any short-term area, is key in an empowered culture.
Hopefully this has been a thought-provoking canter through some key aspects of scaling agile. I wanted to provide a few final thoughts to bring things to a close:
- To those who peddle that scaled agile is a magic silver bullet to fix all ills … it’s not. As Ben Horowitz writes in The Hard Thing about Hard Things, there’s no perfect org design; you can optimise on certain dimensions but that always means compromise on others. In scaled agile, a good example is with regard to international vs local: If you have local operations organised on an agile basis, then you will get better local market design and speed, but at the potential cost of fragmentation of solutions and systems on an international basis.
- Folk working in product, design and development are knowledge workers, and knowledge workers thrive where there is purpose, autonomy and a chance to self-develop. So with the right leadership, scaled agile can underpin these attributes, therefore I believe give the best overall environment for sustainable success (and equally important, fun!).
- Success isn’t about having a specific function of the organisation work agile. The long-term key to success is about it being in the DNA of everyone (the same applies to digital). As such, the leadership of the CEO and executives is so important. They need to set up an environment for success, and role model the desired changes.
And finally, what about risk management, which I highlighted in the intro? The above has touched on some key elements – for example a limited blast radius by regular small change with appropriate IT architecture, continuous sharing of learnings across the organisation, aligning early on dependencies, and care on organisational incentives.
However, certainly in financial services, this isn’t sufficient for a regulatory, robust risk management framework, operating a “three lines of defence” model. Particularly so in the context of the senior manager’s regime, which puts specific accountability clearly against a small group of named individuals. Does this all conflict and make the scaled agile approach unworkable? What about when new trends are introduced, such as open ecosystems?
This will need to be a future blog, as this one is long enough! In the meantime, in the context of a high-risk environment and agile, consider this video …
AUTHOR: Richard Davies has held senior roles at Barclays, OakNorth and HSBC. This is a guest post for 11:FS. To find out more about 11:FS, visit the website.
– This article is reproduced with kind permission. Some minor changes may have been made to the text to reflect BankNXT style considerations. See more 11FS content here. Image by Kalalruthi, Shutterstock.com