Scaling Agile

Over the past year I’ve been working with a large global corporate that is rolling out agile ways of working at scale through the organisation. The ‘a’ word is becoming somewhat overused and it can often be misunderstood or misappropriated, and yet as I argue in my book the application of agile structures and practice has the potential to be the fundamental enabler to the transformation that so many organisations are seeking to implement right now.

Small, empowered, multidisciplinary teams working iteratively in a supportive environment can drive transformational levels of change, particularly when these practices are scaled more widely across the business. And there are now a number of notable examples of businesses (including ING, Bosch, USAA, Netflix, Amazon, Spotify, The Guardian) that have structured an operating model that involves a scaled application of these principles. Scale brings challenges however. As soon as you start to get past a limited application involving a few small teams, you begin to run into alignment and interdependency issues.

A popular approach to scaling agile (but not the only one of-course) is to apply learning from Spotify’s model of Squads, Chapters and Tribes.

Squads:- these are your small, multidisciplinary ‘two-pizza’ teams (no more than 10 people). Co-located. Working iteratively in sprints. Focused on a specific customer problem or goal. Comprised of all the skillsets/functions needed to achieve the desired outputs and no more. Sometimes self-organising but always given higher levels of autonomy to decide how best to achieve their goal.

Tribes:- Squads are grouped together by business area. No more than 150 people in a Tribe. Environments that support intra-squad contact and regular gatherings for show and tell, shared learning. The Tribe leader is responsible for co-ordination across the different squads and with other Tribes, managing resourcing, budgets and inter-dependencies, establishing priorities.

Chapters:- groups of functional experts who do similar work (like UX for example) within a Tribe. The Chapter lead is a Squad member but is likely to be the line manager for other functional experts in that Tribe, and is responsible for performance review and people development, functional meet-ups to support learning.

One of the most widely scaled applications of this approach in a large legacy organisation is of-course ING who have effectively re-organised their business around this idea in response to the need to be more adaptive and responsive as an organisation. I wrote up a case study of ING’s agile transformation here.

Image source

In ING’s case, they’ve applied this idea pretty comprehensively, creating a more fluid and responsive organisational structure. Squads (comprised of specialists in marketing, data and analytics, design, UX, product, tech) were focused on end-to-end ownership of a customer journey and Tribes (13 of them) grouped around business and customer proposition areas.

But it’s important to recognise I think, that there is no one-size-fits-all solution to what good looks like. There are however, some common pitfalls and also some general fundamental principles that are useful to consider — here are some of my basics:

Start small, to scale fast:- change management is itself changing. Rigid, linear, top-down, big-bang transformation programmes do not work well in environments that are constantly and rapidly changing. There needs to be a compelling vision of the company that you want to be of-course, and commitment and enablement from the very top towards making that happen, but far better to start small by focusing on a number of critical business challenges or customer problems and scale fast and use continuous learning to adapt along the way. This enables the business to change in a way that is far closer to shifting contexts, and be adaptive enough with the operating model to flex into a fit-for-purpose structure. Most of the agile transformations that I’ve seen or come into contact with have started with a few teams focused on key problems, then expanded to a larger number of teams as progress is made and more nuanced or detailed customer problems are identified.

Balancing a dual operating system:- one of the key challenges (and realities) of change in a large organisation is the need to manage business as usual and short-term priorities and targets whilst also creating space for the new ways of working. Space is necessary to enable the new practices to grow without being stifled by corporate culture and entrenched processes, but there needs to be a good connection back to business as usual so that the wider organisation can learn. Balancing this dual operating system is key to making real change stick but again, every company has unique contexts and so needs to find it’s own balance between traditional hierarchical structures and the areas of the business that are structured in less hierarchical, more networked, Squads and Tribes. That balance will also need to flex as needed. The only solution is be iterative and adaptive with the process itself. In other words the process of scaling agile should itself be agile.

Doing Agile and being agile:- in a dual operating system there will be the teams or Squads that are doing Agile (i.e. are working iteratively in small, cross functional teams), but there is the need for everyone in the business to at least be agile — that is to appreciate the values and behaviours that can support this way of working. If this doesn’t happen you get tensions that can potentially derail the whole thing. Horizontal functions like HR, compliance, legal or procurement may not be working in the Squads but they will be needed at key points, and the business will need to adopt more agile approaches to governance, procurement, budgeting, performance review etc. You have to set the Squads up for success — there might for example be an operations team that gives the Squads the infrastructure and support they need to release code themselves. There might also be regular reviews of dependencies to reorganise work and prevent progress being slowed. Those who are being agile are no less important than those who are doing it.

Context is key:- I’m a fan of Simon Wardley’s championing of the need for businesses to develop a better understanding of situational context — there needs to be more awareness of these kinds of contexts within businesses IMHO. But it’s also important to stress that whilst agile ways of working are in general undervalued and under-optimised, this does not mean that agile is the default process in the business. Appropriate processes should map to specific contexts and jobs to be done. Businesses need to take a nuanced approach to the application of different methodologies.

There is no one methodology:- Some advocates are passionate about adhering to particular methodologies which may be fine for technology teams but in my experience when agile practice starts to scale more widely across the organisation it’s actually better for the company to find it’s own way and adopt practices which are suited to the unique contexts of that business. This may involve combining tools and techniques associated with different methodologies and even giving teams a degree of freedom in the selection of specifics. The bigger challenge is not which agile process is best, more the shift from years of entrenched linear and waterfall thinking. So it’s important that there isn’t a half-hearted adoption of the principles, or a drift back to old ways of working. There needs to be a good level of consistency and common approaches and processes — but don’t make it completely rigid or prescriptive.

Autonomy and ownership are key:- Squads (or cells or pods or whatever you want to call them) should have end-to-end responsibility for achieving a client-related objective (in one agile transformation that I was involved with for example, there was a mix of objective with some teams focused on optimising / innovating an end-to-end customer customer journey and others focused on innovating new customer propositions to solve customer problems). But the Squads should always be enabled by a high level of autonomy if they are to move fast. Close, top-down control simply does not work in this scenario. Leadership should frame the problem to solve and then leave the team to identify the best ways to solve it. Resourcing in the team may flex as the tasks that the team needs to complete change over time. The team may disband entirely and resource be reallocated if the objective is fulfilled and task completed.

An enhanced role for Product:- Product owners are usually members of the Squad and take responsibility for managing the backlog and the priority setting and so helping to coordinate the Squad activities but they don’t tell the other Squad members what to do. More generally, Product functions and disciplines in many organisations need to take on a more significant role in working with senior stakeholders to align business strategy with product strategy, and ensure that the objectives and outputs of the Squads focus on delivering not only what the customer needs but also what the business needs.

There’s a ton of other stuff that sits around this, but these are some of the fundamentals that in my experience can really make a difference.

For more like this, order your copy of Building the Agile Business Through Digital Transformation, or you can join our community to access exclusive content related to the book.


Originally published by Neil Perkin at Only Dead Fish