Scaling Agile and Scrum


Is it just me or has the word “scaling” become a buzz word in the Agile community in the last 5 years? Thinking back to the mid-2000s, I don’t recall this being talked about at User Groups, Conferences, in Certified ScrumMaster courses, etc.

Today scaling frameworks appear overnight and promise a one-size-fits-all solution to using Agile approaches “at a larger scale”. Let’s look at the first challenge with that:

What do you mean by “scaling”? 

When someone talks about Scaling Agile or Scaling Scrum, I ask them what they mean more specifically as there are a lot of loaded terms in that phrase.

  • Do you mean Scaling Agile or Scrum across a large Product?
  • Do you mean Scaling Agile or Scrum across an enter organization?
  • Do you mean Scaling Agile or Scrum across distributed geographies?
  • Do you mean all of the above? (Yikes!)

In my experience, many of these organizations cannot answer what is meant by “Agile”. Some mean using the Scrum framework, yet others mean eXtreme Programming or just adhering to the values and principles in the Agile Manifesto. Many also cannot answer what they hope to gain by adopting Agile to do work versus the status quo. So how are these organizations going to know that they have achieved their goals? Firstly if they do not understand what the goal is. Secondly, if they do not agree on what is meant by “Agile” or do not have this working successfully (whatever that definition for them is) at small scale. What do they plan to do? Scale something that has not been proven to work at small scale and hope that it somehow delivers better results?

One Size Fits All

Some scaling approaches offer a prescriptive solution regardless of the size of the company or the type of work being done. Many assume the work is technology based so a number of information technology specific references exist that may not universally apply in every organization.

Some may read this and think “well, isn’t Scrum or Agile one size fits all”? This gets to the heart of the misunderstanding. They are not intended to be “methodologies”. They are frameworks. The Scrum framework asks anyone adopting it to identify who the Customer is and what the Product that will be built for that Customer is. The framework offers a set of “guidelines” to keep the people building the Product for the Customer accountable and adaptive to the Customer’s feedback. By definition the Development Team, the Product Owner, the ScrumMaster and the Organization are meant to do what makes sense for their company, industry etc. The values and guidelines are there to help.

Other Agile approaches, such as eXtreme Programming, assume a technology Product so are slightly more prescriptive in the technology practices but still start by asking “who is the Customer?” A Customer view is adopted as opposed to a System-only view.

If companies have not worked through these questions, chances are the rush to Scale Scrum, or other Agile approaches, may slightly optimize the status quo, but will not achieve the full benefits from using Scrum or Agile at scale.