Scrum is a framework that helps a single team develop, deliver, and maintain complex products. It was designed for a team to be able to work at its optimal capacity and at a sustainable pace.

Scrum@Scale is a framework for scaling scrum, where networks of scrum teams operate according to the Scrum Guide. These teams can deliver products of great value, while managing complex adaptive problems. The Scrum@Scale framework coordinates these teams to optimize the overall strategy of an organization and achieve linear scalability.

How Does Scrum@Scale Work?

Scaled Scrum happens when many Scrum teams work on the same product or project. Scrum@Scale uses a scale-free architecture to manage this. Scale-free architectures allow organic growth based on the project's unique needs, at a sustainable pace acceptable to everyone.

There is no single approach to scaling Scrum. Do the following to scale Scrum successfully.

•         Introduce Scrum in your organization with a single team first.

•         Check if scaling is really needed.

•         Define your goals.

•         Experiment and develop your own scaling model in stages using practices suited to your circumstances.

•         Inspect the outcome of the process.

•         Repeat the process, if satisfactory.

•         Change, if needed.

Scrum@Scale Challenges

For many organizations and large projects, even the basic concepts in Scrum begin to break down when you try to scale them up. The following are some common challenges in scaling Scrum.

Team size too large or too small

According to the Scrum Guide, a Scrum teamshould consist of seven members, give or take two. If you have more than seven members in your teams, split them into smaller teams. If they have less, add a few well-chosen members.

Team members spread far and wide

When team members are spread worldwide, even basic communication becomes difficult. Provide them with the best communication facilities available.

A product owner and product backlog per team, not per product

Having a single Scrum product ownerand product backlog per product means quicker decision-making and well-aligned priorities. When multiple teams work on one product, but have a product owner per team, priority conflicts may build animosity among teams.

Keep a single product owner structure. Refine your product based on just one product backlog. During sprint planning, ensure that all teams have their sprintat the same time. Conduct only one sprint reviewbecause you're producing only one product increment.

Missing product owner

Although a product owner per product is optimal, many teams having questions on customer preferences at once might overwhelm him/her. If your organization or project is large, appoint a single product owner and several assistant product owners to cope with all questions.

Clueless Scrum master

If the Scrum masterhas to handle multiple Scrum teams, his/her job and consequently, team performances, will suffer. Ideally, there should be only one scrum master per team.

Focus on project, and not product

Many team members work on multiple projects aimed towards creating the same product. When the product is complete, they return to their functional groups and are reassigned to other projects. All this causes great confusion and instability.

To avoid this, ensure that all teams are product-focused and share knowledge and goals. Encourage the commitment to deliver one integrated increment that meets a single definition of done for the product.

External testing

Usually a backlog item is checked by conducting unit tests and then sending it for professional testing. It isn't considered complete until the external test results say so. Enlist at least one tester in each Scrum team so that you get immediate feedback on backlog items.

Scaling error

Scaling does not mean increasing capacity by adding more Scrum teams, product owners, Scrum masters, etc. This causes teams to focus on delivering components and not an integrated potentially shippable product.

Scale your Scrum organization along customer domains and Scrum values. Then the teams will be able to focus on one customer domain each, and all teams can together create an integrated product.

Scrum@Scale makes you capable of targeting your step-by-step change efforts in the areas you feel they are needed the most. You just have to ensure that you implement it diligently.

Credited to: Yann (yann@uiza.io)