What is scaling agile?

This article covers what I think about when I think of scaling Agile, what it really means, why is it so hard and how to make it easier.

Who am I?

My name is Simon Powers, I am the founder of Adventures with Agile¹, the global community of practice for scaling agile and organisational change. I am an organisational process designer, Agile coach and Software Architect. I run clinics for companies to overcome specific problems, I run public courses on Scaling Agile that cover how to overcome the common problems that teams and organisations have.

I am a certified Scaled Agile Framework Practitioner (SPC), a certified Large Scale Scrum Practitioner (LeSS), certified to green belt level in Disciplined Agile Framework (DA) and certified by the Scrum Alliance.

What does Scaling Agile really mean?

There is some controversy about the use of the word Agile when it comes to organisational change that effects more than one team and whether it is actually still Agile or something else. This begs the simpler question ‘What is Agile?’

What does Agile really mean?

Agile originally came about from the talks that produced the Agile Manifesto and combined a number of lightweight iterative empirical processes together under the heading of Agile.

According to the history of the Manifesto², the original lightweight processes were:

Extreme Programming
Scrum
DSDM
Adaptive Software Development
Crystal
Feature Driven Development
Pragmatic Programming

None of these processes deals with Organisational change, they deal only with changes to the software team. The fact that it was purely software focused is further highlighted in the manifesto

We are uncovering better ways of developing software …³

Therefore in its earliest form, at its point of creation, the term Agile refers to a set of processes that are used in single software teams.

The manifesto pulls out and makes clear the common principles and gives us a sliding scale of values that we can use to make decisions upon. These were defined for the team, but we can extrapolate them further, with varying degrees of success, beyond the team.

What good stuff at the team level do we get?

This set of processes have some things in common that are very different from the waterfall or traditional processes that preceded them. These can be summed up by:

Iterative empirical process
Fixed time and cost but variable feature scope
Quality built into the process
Feedback cycles
Human beings are part of the system you are building and the process you use to build it

It quickly becomes apparent that Agile is not just a set of practices that can be followed and out the other side comes the desires outcome. I like to represent Agile as a set of concentric ellipses with the area representing the importance of each Agile property.

Source: Darren and Chris from Radtac – www.radtac.co.uk

The effect of these properties and their underlying values, principles and practices means that you get the following outcomes:

More visibility throughout the entire creation process
Less delivery and business risk
Higher value earlier
You build the right thing
You get a quality product

Source

If this is what we ‘should’ get at a team level, can we scale these outcomes to get them for the whole organisation?

Does Agile Scale?

So scaling Agile then, for our discussion, is getting the same outcomes at an organisational level that we get (or are promised) at the team level.

Before we can answer whether Agile can scale or not, we need to ask yet another question first.

What do we mean by scaling?

Scrum of Scrums is a myth – it doesn’t work – Dan North⁴

We are not going to deal with anything so trivial and meaningless as Scrum of Scrums – Craig Larman⁵

Scott Ambler, co-creator of the Disciplined Agile (DA) Framework⁶ gives us a number of factors that help us to define the organisational landscape and why we need to overcome scaling at all.

These are:

Geographical distribution
Team size
Regulatory compliance
Domain complexity
Organisational distribution
Organisational complexity
Enterprise awareness

These factors describe the environment in which scaling is apparent. Not what you need to do to scale Agile.

Craig Larman co-creator of Large Scale Scrum (LeSS) strongly recommends realigning the organisation to remove or reduce these issues⁵.

Dean Leffingwell creator of the Scaled Agile Framework addresses this in the big picture⁷ through alignment, temporary colocation and a prescribed common process covering all levels of the organisation.

However the organisation approaches trying to achieve the outcomes defined above, it is clear that the organisational size, structure, process and culture all have significant impact and changing these factors are the key to achieving agility.

The problems we get when we try to scale team level Agile

As defined above, Agile (so far) simply doesn’t mention organisational process design. The team level processes are optimised around the team (no surprises there), and these team optimisations simply don’t add up to organisational optimisation.

In addition, the Agile processes are iterative and based upon delivering thin slices of value in an empirical way. If an organisation is not set up to do the same, the team will clash with the organisation and the team will lose and not be able to continue with the process.

Many of the organisations I come across did not realise the enormous scope of what they were undertaking when they decided at the top to ‘go Agile’. They have been unprepared and have experienced significant pain on their journey. Mainly because they didn’t understand that team level Agile is not organisational change and doing Agile properly means very deep and broad organisational change.

Even when organisations decide to follow one of the scaling frameworks closely, it quickly becomes apparent that is not that easy. Contextual problems and people make things complicated. You can’t empower staff and then expect them to just follow what management tell them to do (top down adoption) and you can’t expect an organisation to function if it is optimised locally for every team (bottom up adoption). If you follow both approaches trying to optimise the organisation but guide from above but you miss out middle management (mid level adoption), then you have a whole host of other problems such as no clear lines of escalation for Scrum Masters, no servant leadership, lack of consistent process and fear amongst managers for their positions.

All three approaches must be done together within a contextual framework.

Here is a list of contextual problems that I come across in the organisations that I work for and I hear about from colleagues and fellow coaches. It is not exhaustive but is indicative of the scale of the problem organisations face.

Lack of understanding of what Agile is
Lack of experience of staff in working in an Agile way
Staff over-utilised as organisations are optimised for keeping people busy
No formal change initiative or accountable team
No clear role for management or lack of engagement from management
No organisational view or framework to make agility work
No clear lines of value or product – lack of understanding what a product is
Organisational structure is not aligned or optimised for agility
Traditional mind sets dominate decision making
Engaging with teams is hard because not all teams share a common Agile process
Third parties are engaged using contracts that restrict agility
Resource allocation is not aligned to value or long lived teams
Individuals are highly specialised, making team or organisational optimisation very hard
Governance models are still based on traditional models causing large upfront documentation
Architecture is still based on traditional models causing large upfront documentation and architectural decisions that reduce agility by large vendor lock-ins, big balls of mud or structures that do not allow in-expensive changes
No consistent tooling making it harder to co-ordinate across teams and provide automated environments
Silo teams sub-optimise the organisation and reduce agility. (E.g. test, architecture, dev-ops, component teams etc.)

So if Agile in its team level form, does not provide an opinion or solution for these problems and is clearly localised at the team level at the expense of organisation optimisation, then we need something else.

How do we achieve organisational agility?

If we are going to succeed in making an organisation have a higher level of agility, we clearly need to overcome these problems.

Is it still Agile?

I will address this problem very quickly by saying that I don’t care what we call it. There are two very strong opinions on whether organisational agility is still Agile or whether it is something else. My opinion is that it is still Agile, and Agile has evolved. However, this is not the opinion of all.

Adoption plan

Once we realise that the scope of Scaling Agile is actually organisational redesign, we need to plan and have people accountable for the change. The change needs to happen in an Agile way. We do not adopt Agile using large up front organisational redesign documents mirroring waterfall approaches.

The best adoptions I have seen come from having a vision and an adoption backlog, with an adoption ‘Product Owner’ who balances priorities amongst relevant stakeholders.

The types of items on this prioritised backlog are the epics and stories that must be done by the whole organisation on their journey towards achieving the outcomes defined in the vision.

These types of changes usually include some or all of the following:

Cultural changes

The organisational iceberg
The role of management
Building around motivated individuals

A contextual organisational framework which may or may not be based upon the following:

DA – Disciplined Agile
LeSS – Large Scale Scrum
SAFe – Scaled Agile Framework
Kanban

Lean and Systems thinking

T Shaped people
Local versus System optimisations
Theory of Constraints

Other tools and concepts

Metrics
People liquidity not fungibility
Real Options
Innovative Gaming

Alignment on the concept and realisation of the product and value

Vision to Epic to Feature to Story to Task
Value Stream Mapping

Putting it all together

Actually implementing this type of organisational change can be daunting and very risky, not to mention expensive. However, the outcomes can be phenomenal and help change a flagging company into a market leader.

The steps to making the adoption as painless as possible are clear. It must start at the top and the CEO must empower an adoption team to do what is required to change process and mind-sets and build a vision, backlog and common framework the organisation can align around.

IT is not separate than ‘the business’.

There must be training and coaching for managers in what it means to lead and be servant leaders and empower their reports to be the best they can be.

There must be training and experienced team members (Scrum Masters and Product Owners) to run the team level Agile processes. Clear lines of escalation must be provided for impediments back to the change team.

Ancillary processes such as HR, Legal, Dev-Ops, Outsourcing, Architecture, Regulatory Compliance and Governance must be altered to empower the level of Agile ambition for the organisation.

As well as coaching and designing organisational process, I and my colleagues run focused clinics to help organisations start on the right track and stay there. The main clinics we have been asked to do cover these topics.

Identifying the products, epics, features and stories
Alignment, co-ordination and dependencies
Training and Coaching
Testing and Quality
Tooling
Starting sprinting
Shortening the feedback cycle

Clinics usually involve identifying clear goals, an alignment session, training, mentoring and coaching key practices and then measuring success against goals.

These interventions or kick-start sessions are usually key to creating progress and getting the organisation going.

The journey is not a short one. Expect teams to start producing value after 6 months, be well on their way by 18 months. True organisational change can take years.

What is Scaling Agile?