When not to scale Scrum

Typically the first question I hear after a company decided that Scrum may be the way to go forward in their IT organization, the next question I hear: "But how do we scale it?"

As mentioned in a previous post, there are reasons why you shouldn't even try to scale. Aside from that, you may simply not be ready to scale.

Before you attempt to scale your Scrum, maybe you want to go through this non-exhaustive check list. It only exists to give you an idea of what to improve on before plunging into Scale.
Maybe you want to answer these on a scale of "Definitely not (1), Unlikely (2), Somehow (3), Usually (4), Definitely yes (5)" - then decide areas for improvement based on feasibility and value.

So, here is your checklist:

1 - Delivery

• We are able to deploy the last merge to Master to a productive system within less than 15 minutes.
• We can release partial work at any time, because we use Feature Toggles to disable unfinished features.
• There is no more work to do when we call a story "Done".

2 - Teams

• We have stable teams that have a routine of working together.
• Our teams autonomously get stories "Done". They do not depend on anything from anyone outside the team. This includes activities (such as testing or deployment) as well as sign off.
• Our teams have what they need to succeed. They do not require permission to use applicable tools to get their job done.

3 - Scrum Masters

• Scrum discipline within the team works without having the Scrum masters say or do anything.
• Scrum Masters act as mentors and supporters, not as managers.
• Scrum Masters are seasoned experts in Scrum. They have seen Scrum in multiple contexts and are aware of the difference between avoiding pain and healing the pain. They avoid going the easy, wrong way.

4 - Product Owners

• The "someone who calls the shots" is the Product Owner. Not other stakeholders.
• The PO is not a business analyst detailing features to become implementable, this can safely be left in the domain of the team.
• Product decisions are based on Net Present Value, Opportunity Cost, Customer Retention, Market Share etc. - as opposed to politics.

5 - Outside Organization

• Company priorities and objectives are aligned across all areas, including IT as well as Marketing, sales, finance. Conflict of interests is resolved on top management level.
• External stakeholders fully understand their responsibility in enabling successful delivery.
• Managers enable the team and do not require non-value adding activity, such as reports

6 - Continuous Improvement

• We know our 3 top pressing impediments
• The most pressing impediment is actively being resolved
• Minor changes which help increase productivity are readily implemented without further mention.

7 - Technical Debt

• It is widely accepted that technical debt must be controlled
• We measure and are aware of our technical debt
• We don't release any code with significant technical debt

 Summary

The model of Shu-Ha-Ri applies to Scaling more than anything.

An organization in the SHU stage of Scrum multiplies their problems, not their solutions, at scale. When you can't frequently and reliably deliver value with 1 team, you won't be doing that with 5 or more teams, either!
Successful scaling requires coaching by RI stage Scrum experts and an organization that is at least on the HA level.

As long as you don't have a working implementation of Scrum within individual teams, don't even think about scaling!