Two years ago, we posted an article about the “fuss” around Scaling Agile or Scrum. The fascination hasn’t diminished at all, in fact, there are more organizations than ever rushing to “scale” Scrum. The reality is most of these organizations are simply not ready to scale Agile or Scrum. How can these organizations scale something that they can’t even define?

How can you scale something that you can’t execute?

Dictionary.com defines scaling as a verb:

·       To remove the scales or scale from: to scale a fish

·       To remove in scales or thin layers

·       To shed scales

·       To come off in scales

Yet many organizations think that “scaling” Agile and Scrum means preservation of scales.  Preservation of top-down hierarchies with layers of management and oversight. Nothing could be further from the truth. Agility is about “turning on a dime for a dime” which means shedding layers. The Agile Manifesto is about empowering teams of people doing the work, not maintaining hierarchies. Scrum focuses on rapid value delivery by teams organized around features instead of silos. 

How can you scale something that you can’t execute at its basic element?

In our original article, we posed even more questions for organizations to ponder regarding scaling Agile and Scrum:

·       Do you mean Scaling Agile or Scrum across a large Product?

·       Do you mean Scaling Agile or Scrum across an entire organization?

·       Do you mean Scaling Agile or Scrum across distributed geographies?

·       Do you mean all of the above? (Yikes!)

The reality of adopting any Agile framework, Scrum in particular, means change. Approaching the problem to be solved, the product being developed, or the work being done in a completely different way. A lot of Agile and Scrum vocabulary layered over your old way of working doesn’t make sense and won’t deliver value any faster. If a company delights customers and accomplishes their goals, why would they want to change their approach to doing work?

If an organization isn’t ready for Agile or Scrum at “small” scale, challenges await in the rush to take that adoption bigger.

Here are three questions to determine if the scaling conversation makes sense for the organization:

·       Is the organization willing to dedicate teams (no time-slicing)?

·       Is the organization willing to order the work?  Everything can’t be #1 priority - you will have to say "No" at regular intervals. 

·       Is the organization willing to change the way teams of people are currently structured?

Answer no to any of these questions and the organization may need further education and discussion on what it hopes to accomplish with Agile or Scrum.

Questions?  Ideas to improve this challenge?  Please leave us a comment below.