Get certified - Transform your world of work today


A Brief Talk About Scaling

10 February 2017

Volodymyr Trush

A company often begins scaling Agile when the current organizational structure cannot handle new market challenges (with tons of tasks in the backlog to prove it), and the company is losing its hold in the marketplace. Sometimes scaling is also applied to make a monolithic organizational structure more flexible and goal oriented by reducing waste.

Regardless of when you start to scale, the best way to scale is down, not up. Instead of hiring more people, improve your velocity.

Common problems while scaling

Scaling properly is no more easy than following Scrum itself properly. Here are some common mistakes:
  • The traditional structure is followed without changing the framework and approach. Adding a few Scrum teams will not make the difference; you might as well try to fix a car by changing a tire when the engine is what needs repair.
  • No one understands why the team is going trying to scale.
  • A scaling problem is often assumed when the reality is that the team has never learned to work together.
  • The stand-up is considered a reporting exercise — or a simply a boring meeting. It is not seen properly as a problem-solving tool.
  • Management does not give the ScrumMaster the responsibility or the right to help the team continuously improve.
  • No one is in charge of approving the backlog, so at the end of the sprint, the product is not potentially shippable.
Problems will always exist. The organization must not look for a scapegoat if in fact it is not scaling properly.

Considerations for scaling

Agile efforts can be destroyed quickly, and it takes time to recover and rebuild the Agile framework across the organization. Strong leadership is necessary. There are several factors to take into account before beginning:
  • If you cannot get one Scrum team to work well, the problem is only magnified during scaling, when you will have severe problems with multiple teams.
  • Ensure that at least one person in a group can influence decisions about architectural changes.
  • Distributed teams can work together, but care is required. Give each team a colocated product owner (PO). If that is impossible, then appoint a proxy PO who is colocated.
  • The main goal is to reduce the communication path, for ease and efficiency.
  • Check the frequency of your releases. Use Lean to help.

Approaches to scaling

The main tool to understand when scaling is the Scrum of Scrums, or a version of it, so that teams across the organization can work together effectively. SAFe is one particular approach to scaling, and the company Spotify developed its own version that has been widely discussed.

At Spotify, every team has a PO and an Agile coach. Development teams and operations teams are colocated "squads." Ideally, each squad is fully autonomous, like a mini-startup. A "tribe" is a collection of squads that work in related areas, such as a back-end infrastructure. The size of a tribe is typically not more than 100 people. Knowledge can be shared in "guilds" composed of people from squads and tribes who join to improve skills, based on need or interest. Finally, the "chapter" is a small family of individuals who have similar skills and work within the same general competency area, within the same tribe. Each chapter meets regularly to discuss its area of expertise and its specific challenges. For example, there can be a testing chapter, a Web development chapter, and so on.

Pioneered by Dean Leffingwell, the Scaled Agile Framework (SAFe) describes three levels in the organization: the portfolio, program, and team. Each business or architectural epic becomes an Agile program with its own "Agile Release Train." Several Agile teams work together on each program within the organization. Each team has its own backlog, derived from the program backlog.

These are just a couple of examples, in thumbnail versions, of how scaling can work; there are others. Organizations must take into account their own needs and goals in order to decide how best to scale, and they must put in thought and dedication to make it work.


Jeff Sutherland. "Scrum at Scale."

H. Kniberg and A. Ivarsson. "Scaling Agile @Spotify."

Additional reading

S. Guckenheimer and N. Loje. Agile Software Engineering with Visual Studio: From Concept to Continuous Feedback, 2nd ed. Addison-Wesley Professional, 2011.

J. A. Whittaker, J. Arbon, and J. Carollo. How Google Tests Software. Addison-Wesley Professional, 2012.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.7 (3 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up