How does the Program Scrum Master help when scaling Scrum? Scrum is well Documented for a typical small Project, and it is relatively easy to introduce Scrum into a small-medium IT Business unit. Up to now, larger Companies have found it a bit of a challenge, especially Companies with an established Project Management Office (PMO).

Program Scrum Master: Working to Scale

When adopting Scrum as an Agile Framework, it is suggested that the Scrum Project has a Team of 5 to 9 resources. This gives the impression that Scrum is only appropriate for small Projects. This is not the case, Scrum can be utilized for bigger Projects. The trick is to have multiple Scrum Teams Working on sub-Projects. These Scrum Teams (Scrum Master, Product Owner and Development Team) are kept in synchronisation by routine Meetings. These meetings are referred to as the “Scrum of Scrums”. A new hierarchy is required to be introduced for this requiring a Chief Scrum Master and Chief Product Owner, who Facilitate and co-ordinate the overall Project.

Scrum Defined at Portfolio and Program Level

Many organisations practice Programme and Portfolio Management for comprehensive oversight of all their Projects. Within Scrum new Roles are required for Programmes and Portfolios. These roles are:-.

• Program Product Owner.
• Program Scrum Master.
• Portfolio Product Owner.
• Portfolio Scrum Master.

Program and Portfolio Management are essentially “Command and Control” functions. These are based on a hierarchical Organisational structure. This conflicts with the democratic nature of Scrum Teams at a Project level.

Portfolio Product Owner:

• Delivers Value for Portfolios.
• Creates Business Justification for Portfolios.
• Provides Value Guidance for Programs.
• Approves Business Justification for Programs.

Program Product Owner:

• Delivers Value for Programs.
• Creates Business Justification for Programs.
• Provides Value Guidance for Projects.
• Approves Business Justification for Projects.

Product Owner:

• Delivers Value for Projects.
• Creates Business Justification for Projects.
• Confirms Benefit Realization to Stakeholders.

Another distinction between the Product Owner and Scrum Master Roles in a Scrum are transient. The Product Owner in specific will go back to their regular Job once the Project is over. As the Program and Portfolio Product Owner oversee lots of Projects, these Roles are permanent.

Scrum Portfolio and Program Artefacts.

In order to adhere to the Principles of Agile, Scrum lines up the Roles and activities at Portfolio and Program level with what takes place within a Scrum at Project level. In order to Manage these oversight levels, 2 new Artefacts, which are consolidations of the Product Backlogs, have been specified, the Program and the Portfolio Backlogs. These 2 knowledge bases contain all the content of the secondary Project Product Backlogs. The Business rules for selecting if these User Stories are “Done” is the same. There is also a set of Acceptance Criteria that have to be satisfied before a Deliverable is accepted as complete.

Program Scrum Master: Risk at Program and Portfolio Level.

Program and Portfolio Management can be used as vehicles for Risk Management. The approach recommended is bottom-up, where individual Scrum Teams report on a Risk identified during the Daily Stand-Up Meeting. This Risk is passed up the reporting line. Risks can also be identified at Program and/or Portfolio level. These risks need to be cascaded downwards to Project level.

What is suggested for Risk Management in Risk-Mature Organisations is that Risk Management Responsibility is Managed at Program level. Risk Management Meetings are held at this level where Project Product Owners and the Portfolio Product Owner attend and contribute. The output from this Meeting would be an updated Portfolio and Program Risk Register. This includes a column that indicates which Projects are affected by the Risk. This would eliminate the redundancy of having each Project Team running their own Risk Management Meetings and keeping their own Risk Registers.

The Team member who raised the incident could also be invited to the Risk Management Meeting and can participate in the Assessment and Mitigation activities. This is based on the premise that someone who recognised a Risk is the most likely person to describe a Mitigation for it. The disadvantage to moving the Risk Management to Program level is that the Scrum Team do not get the exposure to managing Risk that they would get if each Team runs Risk Management Meetings. They would, however, have more time to Develop Product, which is their first priority.

Executing Scrum at Portfolio and Program level.

The choice to implement Scrum at these levels could take some time. There are 2 possible approaches:-.

• Create the new Scrum Roles and incorporate them into the existing Programme and Portfolio architecture, OR.
• Redesign the Programme and Portfolio Management Organisational structure, changing the existing Managers or transforming their Roles into their Scrum equivalents.

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

What is advised is that the new Scrum Roles do not replace the Traditional Program and Portfolio Manager Roles. However, they can Work in conjunction with the existing Managers. The Program and Portfolio processes are essentially those of monitoring and measuring performance across Projects. This can still be Managed by the Portfolio and Program Managers, and can be assisted by the Project Office. The Product Owners can Manage the Quality of the Products and the Scrum Masters can deal with resourcing and Scrum compliance issues.

Experienced Scrum Masters and Product Owners could fill these new Roles and transfer the knowledge and skills to the PMO and the other Role-Players in the Programme and Portfolio space. The Scrum Master will have the Responsibility of convening Sprint Planning Meetings, along with the other Scrum Meetings (i.e. Daily Stand-up, Sprint Review, and Sprint Retrospective) required at this level to fulfil the Requirements of Scrum.