So, here is your checklist:
- 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".
- 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.
- 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.
- 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.
- 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
- 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.
- 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
SummaryThe model of Shu-Ha-Ri applies to Scaling more than anything.
An organization in the SHU stage of Scrum fails at scale. Unless you frequently and reliably deliver value with 1 team, you won't do 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!