Leading agile at scale

This blog was first published as a guest blog on 11FS. If you find this blog interesting, you can follow me on Twitter @rhb_davies

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, as when I first came across agile it hugely appealed to my core sense of how things should be done, but I have seen first hand the challenges in scaling this in established enterprises. I believe it is 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 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 FS 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, as otherwise there is 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 4 keys to success. These may sound easy, but creating these can be extremely hard, particularly in a large organisation that is seeking to move from a traditional organisational set-up:

1. The right mindset & talent
2. Creating a culture of learning
3. Having the enabling architecture and infrastructure
4. Achieving the balance between autonomy and alignment

Lets dive into these:

The right mindset & 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 3500 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 is not sufficiently powerful, and there is not 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 have worked in their career to date. 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 is 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.

2. Creating a culture of learning

On the topic of culture, this goes hand in hand with mindset and talent. And it is here that leaders’ role modelling is most critical.

Continuous Learning

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 must not be fear of failure – learning what is most valuable to customers always takes iteration. Traditionally organisations picked a specific project on a detailed 5 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 a 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 describe 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 sub set 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 – here if this goes wrong it can have all sorts of regulatory, risk, reputational, and commercial dangers.

3. 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 3 critical ingredients:

1. 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)
2. 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
3. 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 see 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. But 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 is efficient in maximising empowerment speed.

4. Achieving the balance between autonomy and alignment

All this may leave someone in a leadership position wondering exactly what they do do, and how any degree of strategy or consistency is achieved in a scaled agile model!

Alignment and empowerment

Its important to emphasise scaled agile is not a free for all of start-ups 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 is 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.

Quarterly reviews

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 3 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 program or portfolio board. Clearly the plan can and will change as the weeks progress, but there is an outline that is being aimed for which allows different teams to know how what they are 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 exercise – it is critical that those doing the work know the context around them both for motivation and 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 on 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.

Conclusion

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:

1. 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 is 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.
2. 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, and therefore I believe give the best overall environment for sustainable success (and equally important fun!).
3. Success is not 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 & executives is so important. They need to set up 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 FS, this is not 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 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…