How to Use Scrum in Mid-Large Scale Organizations

December 3, 2017 — Posted by Al Shalloway

This page was moved to here as part of our FLEX (FLow for Enterprise Transformation) site.


There is no question that Scrum has changed the software world by leading the leading adopted framework in the Agile space.  However, the Agile world has changed in the, now, almost 2 decades of its availability.  This change has been threefold (at least):

  1. Late adopters are now moving into Agile
  2. Many of these are in large organizations
  3. Much more is known now about process, particularly in how to use Lean principles in software, than was known 20 years ago
  4. Some of Agile has moved from a focus on teams to include the entire organization

The Scope of Current Methods

There are several popular methods: Scrum, XP, Kanban, Kanban Method (LKU Kanban), SAFe, LeSS, and DAD

The scope of these methods vary. Scrum and XP are centered around the team.  Kanban directly encompasses the product backlog through deployment, but many Kanban thought leaders consider Kanban to include the entire value stream.  The Kanban Method is mostly focused on after it has been decided what to work on.  SAFe, LeSS and DAD include the entire value stream but take different approaches to it.  While FLEX is not popular (yet) it also includes the entire value stream.

No One-Size Fits-All and What That Means

It is pretty much agreed that no one-size fits-all.  But if we believe that, then we must ask the question – where do our methods fit?  Those that are based on practices or scope will clearly have limitations on where they apply.  Specific situations require specific practices.  But there are several principles that apply most everywhere.  There are even laws of software development that apply everywhere. 

It therefore behooves us to see if our frameworks/methods are suggesting practices that don’t always apply or if they leave out useful principles / laws that do.

As Don Reinertsen pointed out, waterfall is not evil, it just doesn’t apply in the real world.  We need to see where things work and where they don’t.  The fact that things work differently and have different contexts in which they work is not bad.  For example, I have two cars – a Mini-Cooper and a Lexus.  They are different.  The Mini-Cooper is great around town.  It’s small, gets great gas mileage, is fun to drive and easy to park.  But it’s not so good on highways (not a smooth ride above 60).  My Lexus is way better for going 70 or more.  Smooth, quiet, nice.  But doesn’t get great gas mileage and is harder to find parking spaces for.  One is not better than the other, they are only better than each other in different situations.

FLEX, while definitely not designed as a one-size fits-all, attends to providing pertinent practices for common situations & thinking on how to solve the rare ones. In this way it creates an umbrella for making specific recommendations for where people are.

Why Systems-Thinking Is So Important

Systems thinking is critical because it attends to how different aspects of our systems interrelate with each other.  Transformations are fraught with examples of attending to one aspect of an organization only to adversely affect another.  See If Russ Ackoff had given a TED Talk for why this is true.  An example of not attending to the systems when doing pilots is discussed in this short video - Successful Pilots Can Hurt an Organization.  In this example, successful pilots created effective Scrum teams but at the expense of making the rest of the organization.  We must be careful we don’t solve the wrong problem.

How One Uses Scrum to Improve

Scrum provides specific practices to follow, including:

  1. Cross-functional teams
  2. Planned sprints of a consistent length
  3. A product owner, Scrum Master and a team
  4. Daily standups
  5. A sprint backlog
  6. A product backlog
  7. Having work finished at the end of a sprint
  8. Retrospections at the end of a sprint

It then lets the team figure out how to do it.  Self-organization is the key here.  When you can’t achieve these (most notably, cross-functional teams, not being interrupted during a sprint, planning for the sprint).  Scrum goes further, however, and suggests that when you can’t achieve these practices that the way to improve your system is to remove these impediments.  This provides a set of practices that people without a lot of understanding can follow. 

However, there are a few problems with this.  If no one-size fits-all then these practices will not always apply.  While the intents are good, the practices are often either not generally applicable (the intention of sprints can be achieved in other ways) or the overly expensive to achieve (cross-functional teams is a way of avoiding handoffs, but not the only way when certain capabilities are scarce).  There are several others which are currently being written up in our Team-Agility section.

The real danger to this approach, however, is that people new to scrum tend to think these practices are sacrosanct and, given Scrum provides no guidance on how to get past them, tend to become dogmatic. Another danger is that the focus on the team can have Scrum adoptions work more with intra-team issues when the real issues are inter-team or product management issues. See Successful Pilots Can Hurt an Organization.

The Need for Double-Loop Learning

Systems-thinking tells us that we must attend to the system we are in when we make local decisions.  This means we must often transcend any method we’re using.  Double Loop Learning is a way to challenge if what we are trying to do is, in fact, the right thing to be striving for.

Impediments to Scrum that May Be Reduced by Looking Outside of Scrum

One of the common impediments to Scrum is the lack of trust between business stakeholders and the team.  It may be possible to lower the trust required if you can get alignment on what and why the business is investing in.  Besides this positive benefit, it avoids the risk of teams evolving into siloes.

Why Including Scrum as an Aspect of Systems-Thinking Is Important

When a team undertakes improving their methods and select Scrum, it is important to understand the bigger goal – realizing value quickly – and the role they play in it.  Scrum’s roots is in The New New Product Development Game which was about how to make a single team building a product more effective.  By focusing on the team, Scrum may cause a focus on local-optimization.  When a single team is involved, local optimization may be global optimization.  But in our modern world, it typically isn’t.

In many cases having 2 or more teams working together will result in business value achieved both quicker and with more efficiency that a single team working by itself.  Teams working together properly in a systems thinking approach may result in greater results than teams working by themselves.

Why Understanding Key Principles Before Undertaking Scrum or Adding them Quickly Is So Important

Most new teams learning Scrum make the same mistakes.  These include:

  • Opening up too many stories at the beginning of a sprint
  • Not having enough agreement on how they should work together
  • Not have good definitions of ready and/or definitions of done
  • Not understanding effective ways to deal with interruptions

After a few sprints they’ve figured this out.  However, basic Lean-principles could avoid them having to figure this out for themselves.  In any event, practices such as explicit work-flow, managing Work-In-Process (WIP) and attending to root cause are core Lean practices that all Scrum teams should be using.

Better Ways of Revealing Issues

One of the key intentions of Scrum is to frame the work to reveal issues.  Following Scrum’s core practices are key to this.  But there are other ways to reveal issues.   The Value Steam Impedance (VSI) Metric is one way of quantifying what people know intuitively about the impediments they face.

Learning More

FLEX includes its own team-level approach – Team-Agility.  We are in the process of integrating some articles on it now, but here are two sources for more information on it:

  1. FLEX and Team-Agility
  2. Team-Agility

Please check out the FLEX site and let me know what you think.  We're trying to discover what works - not create a static brand.

Al Shalloway





























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