Should You Scale Agile? First, What Do You Mean by That?

I was recently asked the question: “what should I look for to see if we should scale Agile?”

I often get asked by people if they should scale Agile. I ask them what they mean by this as three different meanings come to my mind:

1. We’re doing Agile at a few teams and want to ‘scale it to the organization.’
2. We’re doing Agile for some projects and want to ‘scale the size of the projects.’
3. We’re doing Agile for a part of our value stream and want to ‘scale it to the entire value stream.’

These are quite different meanings and which you mean will get you different answers. Let’s look at all three of these.

1. Scaling Agile Across the Organization

Many companies start Agile by selecting a few pilot projects for Scrum. If the intent is “how to get teams working effectively” this is not a bad way to start. But if the intent is to learn how to get a development group more effective and you start with just a few teams, you are likely going down the wrong path. What many people starting with Agile ignore is that Scrum is a team level framework. It is a very good one, and can greatly improve the quality of the work at the team level. However, it is not particularly good at solving the impediments at the program level. This requires a more holistic view.

Common impediments at the program level include too many projects in play, people working on too many things, people required on too many projects, projects contending for capacity and/or resources and more. Unfortunately, the way most organizations that require a program level solution implement Scrum is to select people to create a cross-functional team and start doing Scrum. This will almost certainly succeed. Unfortunately, it provides little insights into how to do Agile across teams. The mechanism of Scrum, such as Scrum of Scrums, does not work particularly well here[1]. However, since Scrum worked so well, and many Scrum experts contend Scrum can scale we often see new Scrum teams pop up without addressing the across the program level challenges. Scaling this way is problematic and often causes real challenges because what is needed to make development work at the team level is quite different from what it takes to work across an organization. Read the blog How Successful Pilots Often Actually Hurt an Organization.

This has often not been recognized because many Agile practitioners take a team centric view (see Agile Manifesto: Incredible Success and Time to Move On). Most ‘Scaling Agile’ approaches still reflect this and are based on team-to-team approaches without providing the holistic view needed.

2. Scaling the Size of the Projects

Scaling can mean making larger. However, smaller projects are typically better. They provide faster feedback and development can be quicker, thereby realizing business value sooner. When a project starts it is fine to allocate all of the people to the project that can efficiently work on it so as to get it completed sooner. But making large projects is almost never a good idea. In fact, we view Lean-Agile as a method of splitting large projects up into smaller ones. This can be done both by the using of Minimum Business Increments (MBIs) – chunks of business value that can be realized independently of each. It can also be done by splitting project teams up into pseudo-independent groups. This is why we talk about ‘Agile at scale’ not ‘scaling Agile.’ We want it to be clear we do not think it wise to make things bigger.

3. Scale Agile to the Entire Value Stream

This is virtually always a good idea and has, unfortunately, been lost on much of the Agile community. The Agile Manifesto’s focus on team Agility has blinded many to the fact that the real intention is to maximize the realization of business value, not development cycles. Business value includes customer value, compliance issues, operations cost, risk and more. A good first step is to get alignment across the organization as to what truly constitutes business value for the organization.

This requires a holistic, Lean-Thinking point of view. It is insufficient to scale by merely having teams work together via Scrum-of-Scrums. Ironically, most companies take longer deciding to do a project than in actually implementing it. Improving the implementation by doing Agile at the team doesn’t necessarily improve the inception part of the value stream. Merely having teams work better together doesn’t solve the real challenge of what to work on and how to prioritize work across an organization. The focus is on maximizing business value realization and that requires working on those items that provide the greatest value. Teams (collectively or not) may contribute to this but can’t figure it out themselves.

When considering trying to achieve Agile at Scale, one should make sure their approach not only includes the entire value stream, but also focuses on what gets into the value stream – how do projects start. Also, since most large organizations have services that are shared (UX, business intelligence, ops) it is important that all work (even across portfolios) be sequenced so that these shared, and typically constraining, services can work on the most important business value. “Scaling” Agile by spreading it across the value stream to include business stakeholders, product managers, etc., is almost always a necessary step to effectiveness.

In Summary

On analysis we’ve seen that there are three types of ‘scaling Agile’:

1. Scaling team Agility across the organization – not a good idea if the problem is not with the teams but at the program level
2. Scaling the size of the projects – almost never a good idea
3. Scale Agile to the Entire Value stream – the right thing to do

As always, if you are struggling with these questions, please drop me a line, or ask a question on the forums in our portal. 

Al Shalloway

CEO, Net Objectives

SPCT

[1] The new variant of “Scrum-of-Scrums” I now see that involves have product owners get together is actually a Lean technique Alan Chedalawada, Guy Beaver and myself created a decade ago that was documented in our Lean-Agile Software Development book. This is a major improvement but won’t solve the entire set of program level challenges.