What Is Agile at Scale and the Different Approaches to Achieve It

April 12, 2018 — Posted by Al Shalloway

I am doing a webinar on Agile at Scale this Tuesday at 9am pacific. Thought I'd write out some of the ideas a couple of times a day.

  1. What is Agile at Scale?
  2. Why Agile at Scale?
  3. Adopt an Operating Model
  4. The Need for Agile Product Management
  5. Allocating Capacity to the Most Important Work In Order to Get Alignment 
  6. The Missing Ingredient for Portfolio Management


What is Agile at Scale?

We first need to be clear what we mean by Agile at scale. We hear it used somewhat interchangeably with Scaling Agile, which has three meanings:

  1. taking Agile at the team and scaling that to the enterprise-this could be considered scaling across.
  2. starting with Agile at the team & scaling upstream where what to work on is achieved
  3. taking existing projects & adding more people to them (scaling in place)

#1 is relatively easy to do but leaves people with portfolio management issues.

#2 requires agile product management & concepts beyond the common epics, features, story model frequently used at the team

#3 is often encountered in growing, successful companies who want to get their products out the door faster.

The webinar will start with a discussion of these three types of scalings and describe how each presents challenges that must be overcome for effectiveness at scale. 


Why Agile at Scale 

The purpose of Agile at scale should be to increase a company's business agility - the ability to quickly realize business value predictably, sustainable and with high quality.
We intentionally say "business" instead of "customer" because what we are going to work on is going to be based on the business' strategy. After that we can focus on the customer.
A business focus requires an understanding of the business' vision, strategy, and what it wants to invest in. Initiatives can be created from these. From these initiatives we create Minimum Business Increments (MBI) and from there features and stories. 
The key is to understand that the MBI created represents the smallest chunk of work that will realize value and details all of the people involved in delivering it. This helps create alignment as all of these people focus on the bigger picture (ironically called the MBI) instead of just their part.

Adopt an Operating Model 

Operating models are often thought of as complicated with lots of pieces. But the essential parts to an operating model are:
  1. a way to start. This can be the pre-defined method of the framework, a starting point tailored for the organization, or at the current “as is” state.
  2. a “to be” to provide guidance
  3. a method to determine if the operating model is achieving its intended result
  4. a support structure to help coaches navigate the challenges that are likely to occur
  5. a set of terminology
Using an operating model enables an organization to adopt an existing framework as needed & to control their pace of adoption. While organizations going Agile will need to change, being able to control the pace of change is important.
The above 5 components work together as a system to enable this. A lot of companies start as the framework they are adopting says to start figuring that after they are moving they can then adjust. This is often a good move - if a fixed start is required to get the organization to move at all. But adjusting the start in a clear manner across the organization can often make the start easier and more effective.

The Need for Agile Product Management

Agile Product Management begins at the portfolio level. It works within the context of the company's vision, strategy and what they are willing to invest in. APM spans the creation of initiatives through the definition and decomposition of what needs to be done. Symptoms of not doing APM well include:

  1. unclear priorities of initiatives
  2. starting with Epics as what to build
  3. teams being pulled in different directions without clarity on which is more important
  4. too much work because of a lack of focus on reducing the cost of delay
  5. work almost being completed but being held up by small things that could have been anticipated

While this may seem like a lot to put on APM's doorstep the reason is simple- working on the values of the organization is the best, perhaps only, thing to align on. If that's not clear, alignment is difficult if not impossible.

This part of the webinar will discuss the basic points of Agile Product Management. 

You can register for this tuesday's upcoming webinar What Is Agile at Scale and the Different Approaches to Achieve It here

You can get more in depth on APM at our free university course (only partly completed, but a few good videos are already done) here  (look for APM - just need to register, no credit card or commitment required)

Allocating Capacity to the Most Important Work In Order to Get Alignment

It is ubiquitous that people are working on too many things- a result of a budgeting process that encourages getting things started instead of getting value realized. There is also a focus on how the work is done instead of a focus of how work is allocated.

LeSS scales up from Scrum- use the intentions of team-Scrum to drive Scrum at scale.

SAFe creates a universal, overarching framework &then contextualizes it down.

But what is the work going into either system?

Going from initiatives to epics to features leaves a big gap. Initiatives are too broad as are epics. Features, while tangible, are not focused. Features in & of themselves usually don't provide value, but require a combination of them. Figuring out that part of the functionality that provides the greatest value requires portfolio management & something more than epics & features. While the MVP is starting to become in vogue, a start up at scale is an oxymoronic statement.

A 3rd approach (FLEX) drives from business value by focusing on what is the most important value to realize.

While the argument between LeSS & SAFe often has to do with which is more Agile, the real discussion needs to be about what to do create and who decides that?

The missing ingredient for Portfolio Management

'In surveying the Agile Product Management landscape, one sees: strategies, initiatives, epics, MVPs, features, stories & tasks. Yet something is missing here- what is the next, smallest, unit of business value (usually focused around customers) that can be realized quickly, predictably, sustainably &with high quality? Strategies & initiatives create the context for them & epics are still too large. MVPs have the right flavor, but if you are in IT you don't have products necessarily & if you are at scale you are  usually going beyond viability.

We believe in using a Minimum Business Increment (MBI)- the smallest piece of functionality that:

  • adds value for the customers of the business
  • provides valuable feedback that the right functionality is being built
  • provides valuable feedback that the functionality is being built the right way
  • provides functionality that can be verified as an increment that can be delivered
  • enhances the ability of the organization to deliver value in the future

MBIs can be used to do portfolio management & create the guidance for allocating the capacity needed for the most important work without falling into the start but not finish trap.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban