Nine Scrum Masters, One Certificate Ladder
The agile practice lead at a telecom asks you to design a 12-month development plan for nine Scrum Masters. The data she gives you: seven hold PSM I and three hold PSM II; all nine can recite the Scrum Guide accurately; none has ever coached a Product Owner on value or backlog management; Retrospective actions are recorded but 80% are abandoned within two Sprints; the organisation still runs a quarterly stage-gate requiring each team to commit to a fixed scope; and the Scrum Masters spend about 60% of their time administering Jira and producing status reports for the PMO. Two of the nine are also line managers of their own team members. The lead's plan is "one course per quarter, one certification per half-year", and she wants you to price it and start in three weeks.
1. How would you use the Professional Scrum Competencies to restructure the plan, and which focus areas would you prioritise for this group?
Read the worked answer
The Professional Scrum Competencies describe focus areas - Understanding and Applying the Scrum Framework, Developing People and Teams, Managing Products with Agility, Developing and Delivering Products Professionally, and Evolving the Agile Organization - each with proficiency levels running from Professional through Experienced Professional to Advanced Professional. The model's value here is that it separates "knows the framework" from "can change a system".
Diagnose against it. These nine are plausibly at Professional level on framework understanding; accurate recitation is consistent with that, but recitation is not evidence of application, so that level needs testing in context rather than assuming.
The leverage points are Developing People and Teams - coaching, facilitation, teaching; nobody is coaching the Product Owner - and Evolving the Agile Organization, where the stage-gate and PMO reporting are organisational impediments no one is working. Managing Products with Agility matters because the Product Owner relationship is currently unmanaged.
Restructure around evidence, not events. Each Scrum Master adopts one real problem - the stage-gate criteria, the Product Owner's ordering, Retrospective follow-through - and works it for a quarter with your coaching and peer review. Courses then support a problem someone actually has, instead of being a quarterly ritual. That also frames the Jira problem honestly: 60% administration is a role-design issue, and no course fixes it.
2. What evidence would distinguish "Professional" from "Experienced Professional" for these nine, and why is certification count the wrong planning metric?
Read the worked answer
Evidence should be behaviour in this organisation, observed by someone other than the person claiming it. Examples: a Retrospective that produces an action the team still honours at the next Retrospective; a Product Owner who can now order the backlog and decline a request; a Daily Scrum the developers run with the Scrum Master out of the room; a stage-gate conversation where the Scrum Master changed the criteria rather than complaining about them; a stakeholder who now attends the Review voluntarily.
Triangulate. Use your own observation, the team's view, and the Product Owner's view, because self-report is the weakest evidence and single-source evidence is easy to game.
Certification count is the wrong metric for three reasons. It measures knowledge against a standard at a point in time, not behaviour in this organisation. PSM II is a genuine step up in difficulty and worth having, but passing it does not mean anyone's Retrospective now changes anything. And as a headline plan metric it invites the wrong behaviour - people optimise for the certificate because it is the easiest item on the list. Use certification as one milestone inside a development plan, not as the plan. The number to move is the 80% of abandoned Retrospective actions.
3. Two of the nine are line managers of their own team members. Is that a Scrum Guide violation, and what do you recommend?
Read the worked answer
It is not a Scrum Guide violation - the Guide does not allocate line management - but it is a real role conflict, and you should say so.
The Scrum Master serves the team and the organisation: removing impediments, coaching self-management, and creating the safety in which a Retrospective can be honest. A line manager holds performance reviews, pay, and career consequences. When both sit in one person, the Retrospective becomes a place where people manage risk, and the abandoned action items are consistent with that. Teams may also be slower to raise impediments that reflect badly on their manager's area.
Recommendations, in order of preference. Separate the roles where the organisation can. Where it cannot, define the boundary explicitly: the manager recuses from any Retrospective topic that could affect an individual's review, personnel matters are handled in a separate forum, and the team agrees what never leaves the room. Then test whether the boundary holds - ask the team, do not assume.
Name it as a design tension, not a personal failing. The practice lead can act on a structural problem; she cannot act on "these two are bad Scrum Masters", and framing it that way guarantees defensiveness rather than change.