What are the processes and artefacts that are involved within Scrum Scalability? On reading the literature about Scrum, one would believe that all that is needed is between 7 to 10 individuals to produce incredible Development leads to a time-frame that is beyond legendary. While this may hold true for a small Development producing a basic Product, the majority of IT projects need more hearts and minds to deliver the completed and viable Product. While the inputs, processes and outputs apply to big Projects simply as they provide for a small Project, there are some extra Roles, processes, Artefacts and Meetings that are advised for Projects with many Scrum Teams.

Scrum Scalability: The Scrum of Scrums

The collective noun for Scrums is “Scrum”, which causes 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 an additional level is needed at the Portfolio level, this is called the “Scrum of Scrums of Scrums”. Regrettably, coining names for a bunch of Scrums is the easy bit. Lining up the Teams and the Work they do is quite another task.

The Chief Objectives of Scrum Scalability

When dealing with a large Project or a Program, several Scrum Teams will be Working towards common Goals. While each Scrum Works Collaboratively and as a Team, they are a subset of the Project/Program as a whole. Lines of Communication need to be developed to ensure that the overall Effort is co-ordinated.

The primary objectives can be defined as:-.

• the establishment of transparent Communications between Teams in order to deliver a coherent Product.
• The co-ordinating of the Scrum Teams within a Project/Program in order to better Manage any inter-dependencies.
• The Management of a Prioritised Product Backlog at the required level (i.e. Project or Program) that is the total of all Product Backlogs contributing to the Project and/or Program.
• The oversight of Risk and Change at the macro-level, and the protection of the Scrum Teams from interference.
• Planning for the major Product Release and retrospection for the Project as a whole.

Scrum Scalability: The Roles.

‘Chief Product Owner’ :- In the case of a Scrum Project with several Teams, a Chief Product Owner is required. The Chief Product Owner is supported by the Product Owner (Voice of the Customer). They makes the decision as to which Change requests are to be prioritized at a Project level.

Chief Scrum Master:- This is a coordinating and Facilitating Role where there are numerous Sprints. The Chief Scrum Master assembles the “Scrum of Scrums” Meeting (SoS). This meeting resembles the Daily Stand-Up Meeting. The Chief Scrum Master questions each Sprint representative (typically the Scrum Master for that Sprint) on.

• What has actually been accomplished since the last SoS Meeting.
• What is to be achieved before the next Meeting.
• The impediments that require clearing.
• What dependencies the Team is creating that will affect other Teams.

Please note that this is not a hierarchical reporting structure. All Scrum Masters are considered as being 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 the same as those for the Chief Product Owner and Chief Scrum Master. These roles however are carried out at Program level. This includes the Management of the Program Product Backlog.

Portfolio Management 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 essentially supply oversight and the diligence expected of any Board.

The Scrum Scalability Artefacts.

There are many Artefacts that are needed 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 very same way as the most basic Product Backlog. They consist of all the content of all secondary Product Backlogs.

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

The Release Readiness Plan. It is suggested that complex Projects might require a special Sprint prior to releasing the Product. This ensures that the Product is ready for Release. This Artefact reports on the activities required to ensure a smooth and hassle-free Release.

The Scalability Processes.

The key points are at inception, during Development and prior to Release. In addition, the Sprint Retrospective is augmented to embrace learnings from the Projects. This is achieved at both a tactical and strategic level in the Enterprise. Space precludes any in-depth description of these processes, which are:-

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

At Program and big Project level:-.

Develop Large Project Components :- This is a process governing the Initiation of large Projects. It involves multiple Product Owners, Scrum Masters and Scrum Teams. It sets the ground guidelines for cross Team Collaboration and Communication and the Management of inter-dependencies.

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

Prepare Large Project Release :- Where Development of the Product has taken place accross Teams. There are bound to be some problems when trying to bring everything together. It is suggested that this is Managed via a special pre-Release Sprint.

At Portfolio Level:-.

Produce Program or Portfolio Components :- This is an overall Planning session at Enterprise or tactical level (depending on how numerous Programs and Portfolios are held in the Company). At this level there is an additional human capital component, as key resources are needed for oversight.

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

Review and Update Scrum Guidance Body :- This is the equivalent of the Management of a Board or any other body entrusted with general governance and guidance.

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

Coordinate Program or Portfolio Components :- This is the oversight to be applied by the Program or Portfolio Owner throughout the life of the Scrum Project.

Retrospect Program or Portfolio Releases :- On Project completion, Lessons Learnt are discussed and their impact on the Enterprise are determined. Where they bring improvements in Quality and delivery, they should be adopted immediately.