How can an organisation go about Scaling Scrum? On reading the literature about Scrum, one would think that all that is needed is between 7 to 10 people to produce amazing Development results in a timeframe that is beyond legendary. While this might hold true for a small Development producing a basic Product, a lot of IT projects require more hearts and minds to deliver the completed Product. While the inputs, processes and outputs apply to large Projects just as they do for a small Project, there are some additional Roles, processes, Artefacts and Meetings that are suggested for Projects with multiple Scrum Teams (Scrum Master, Product Owner, Development Team).

Scaling Scrum: The Scrum of Scrums

The collective noun for Scrums is “Scrum”, which leads to the expression “Scrum of Scrums”. This can be applied to a Project with 3 or 4 Scrum Teams Working to deliver the required Product. It can also be used when looking at Scrum Teams through the lens of the Program Manager. If a further level is required, for instance, the Portfolio level, this is known as the “Scrum of Scrums of Scrums”. Unfortunately, coining names for a bunch of Scrums is one thing, aligning the Teams and the Work they do is quite another.

The Chief Objectives of Scaling Scrum

When one is handling a large Project or a Program, there will be a several Scrum Teams Working towards one or more common Goals. Each Scrum Works Collaboratively and as a Team. They are also a subset of the Project or Program as a whole. Lines of Communication are require to be developed to make sure that the total Effort is coordinated.

The main goals can be defined as:-.

• The establishment of transparent Communications between Teams in order to provide a valuable Product.
• The coordination of the Scrum Teams within a Project or Program in order to better Manage any interdependencies.
• The Management of a Prioritised Product Backlog at the required level (i.e. Project or Program) that is the sum of all Product Backlogs.
• The oversight of Risk and Change at the macro-level, and the protection of the Scrum Teams from interference.
• Release and Sprint Planning for the Product Release and retrospection for the Project as a whole.

The Roles of Scale.

‘Chief Product Owner’ – In the case of a Scrum Project with several Teams, there is a requirement for a Chief Product Owner. This Roleplayer is responsible for the overall Prioritized Product Backlog. From this overall backlog all the Backlogs of each Sprint are derived as well as the complete Product Deliverable. The Chief Product Owner is supported by the Product Owner of each Sprint and plays a coordinaing Role. They also make the decisions regarding which Change demands are to be prioritized at a Project level.

Chief Scrum Master – This is a coordinating and Facilitating Role where there are several Sprints. The Chief Scrum Master assembles the “Scrum of Scrums” Meeting (SoS), which has resemblances to the daily Stand-Up Meeting. The Chief Scrum Master questions each Sprint agent (usually the Scrum Master for that Sprint). These questions are:

• What has actually been accomplished since the last SoS Meeting?
• What is to be accomplished before the next Meeting?
• What obstructions require clearing?
• What dependencies the Team is creating that will impact other Teams?

Please keep in mind that this is not a hierarchical reporting structure, all Scrum Masters are considered to be on the exact same level.

Program Management Roles – The same structure exists in Program Management Roles. There is a Program Scrum Master and a Program Product Owner. The Roles are essentially the same as those for the Chief Product Owner and Chief Scrum Master, but are conducted at Program level. This includes the Management of the Program Product Backlog.

Portfolio Management also has a Portfolio Scrum Master and Portfolio Product Owner for applying Agile practice at a Portfolio level. The Portfolio Product Owner Manages the Portfolio Product Backlog.

The Scrum Guidance Body – the Scrum Guidance Body provides oversight and the diligence expected of any Board.

The Scalability Artefacts.

There are several Artefacts that are required for large Projects that are outside the ambit of smaller sized Efforts. The Artefacts are:-.

The Portfolio and Program Product Backlogs. These are Managed and Prioritised in precisely the same way as the Project Product Backlog. Nevertheless, they consist of all the content of all secondary Product Backlogs.

We found these books great for finding out more information on Agile Scrum:

The Communication Plan – There are various Iterations of the Communication Plan depending at what level the interaction is happening. Just as in conventional Project Management, this Plan ensures that nothing drops between the cracks and that there is visible and transparent Communication across the Project, Program or Portfolio.

The Release Readiness Plan. It is suggested that complex Projects might need a special Sprint prior to launching the Product, making sure that the Product is all set for Release. This Artefact reports on the activities required to ensure a smooth and trouble-free Release.

The Scalability Processes.

The key points are at inception, during Development and prior to Release. In addition, the Retrospective is used to embrace learning’s from the Projects at both a tactical and strategic level in the Enterprise. Space precludes any thorough description of these processes.

Scaling Scrum: At Program Level:-.

Create Large Project Components – This is a process governing the Initiation of big Projects, which includes multiple Product Owners, Scrum Masters and Scrum Teams. It sets the ground guidelines for cross Team Collaboration and Communication and the Management of interdependency.

Conduct and Coordinate Sprints – This is where the Scrum of Scrum Meetings are utilized to continue the Collaboration and transparency envisaged at the start of the Project.

Prepare Large Project Release – Where Development of the Product has occurred across Teams, there are bound to be some issues when attempting to bring everything together. It is recommended that this is Managed through an dedicated pre-Release Sprint.

We found these books great for finding out more information on Agile Scrum:

Scaling Scrum: At Portfolio Level:-.

Create Program or Portfolio Components – This is a general Planning session at Enterprise or strategic level (depending on the number of Programs and Portfolios that are held in the Company). At this level there is an extra human capital element, as essential resources are required for oversight.

Sprint Review and Update Scrum Guidance Body – This is the equivalent of the Management of a Board or any other body entrusted with overall governance and guidance.

Create and Prioritise Program or Portfolio Backlog – The strategic Management level of the overall Backlog at Enterprise, divisional or other executive level.

Coordinate Program or Portfolio Components – This is the oversight to be used by the Program or Portfolio Owner during the life of the Project.

Retrospection Program or Portfolio Releases – On Project conclusion, Lessons Learnt are absorbed and their effect on the Enterprise are gauged. Where they bring enhancements in Quality and shipment, they must be embraced immediately.