SMP study materials
SMP study resources

The Tech Lead Who Is Also the Scrum Master

SMP · Put your knowledge to work in context.

All case studies

The Tech Lead Who Is Also the Scrum Master

Meridian Health has a nine-person Scrum Team building a patient-scheduling service. Priya is Scrum Master for 50 percent of her time and the team's tech lead for the other 50 percent. She assigns work item by item at the Daily Scrum, reviews every pull request, and is the only person with production deployment rights. The Product Owner is a sales manager who forwards feature requests from hospital clients and is unavailable most weeks; a business analyst fills the gap by writing detailed specifications. In the last five sprints the team met its Sprint Goal once. Developers say they cannot start anything until Priya has approved the design, and two senior engineers have asked to transfer. Average cycle time is nineteen days against a three-day target.

1. Which Scrum accountabilities is Meridian conflating, and what does the conflation cost? Ground your answer in the purpose of each accountability rather than in role definitions.

Read the worked answer

Scrum Master. The accountability is to cause the team to become effective at Scrum: teaching, coaching, facilitating, and removing impediments. Technical direction is not part of it. When the same person approves designs and owns deployment, the SM becomes the team's gatekeeper and loses the neutrality needed to coach the team on its own delivery system, because she is that system.

Product Owner. Accountability for maximizing value through ordering sits with one person who is available to the team. Here the sales manager forwards requests and the analyst writes specs, so a proxy is effectively ordering the backlog by arrival. The team has no one to negotiate value with.

Developers. Self-managing and cross-functional. Priya's item-by-item assignment removes the planning that makes them accountable.

The cost is visible in the numbers. Nineteen-day cycle time against a three-day target is roughly six days of waiting per three days of work. Every request queues behind one approver. Sprint Goal attainment collapses because nobody owns an objective that could compete with the queue. A dual role is not forbidden in itself, but this configuration puts the coaching accountability and the bottleneck in the same head.

2. You are brought in as an external coach for eight weeks. Lay out your first three interventions, in order, and the evidence you would use to know each is working.

Read the worked answer

1. Make the constraint visible without blame (weeks 1-2). Instrument where items wait: pull request review queue age, design-approval wait, deploy window frequency. Show the data to Priya and her manager as a system property, not a performance issue. Evidence: a cycle-time breakdown where the largest bucket is named and quantified; queue length trending flat or down.

2. Renegotiate the role structurally (weeks 2-4). Contract with Priya and her manager on a timeboxed SM allocation that is actually protected, move deployment rights to a rotating pair, and replace design approval with a lightweight decision record reviewed by peers. Evidence: at least three people deploying, at least two reviewers per change, and Priya's calendar showing protected coaching time.

3. Shift authority into the events (weeks 4-8). Coach the team to run the Daily Scrum as replanning around the Sprint Goal; use the Retrospective to surface the waiting the team cannot control; coach the PO conversation upward so a real Product Owner with ordering authority is named. Evidence: Sprint Goal attainment, and a Retrospective that produces one owned experiment per sprint rather than re-estimation.

Order matters. Coaching people to be self-managing while the structural constraint remains invites them to be accountable for something they cannot control, which deepens the cynicism already present.

3. Leadership proposes hiring a junior developer instead of a full-time Scrum Master, arguing the team already has a lead. What is your response?

Read the worked answer

Argue from the constraint, not from role purity.

At nineteen days against a three-day target, the team is delay-bound, not capacity-bound. An additional developer adds roughly 10-15 percent throughput and places one more item in the queue behind a single reviewer and a single deployer. Throughput does not shorten a queue whose server is an approval step; it lengthens it.

The cheaper experiments are: distribute review and deployment rights (cost: a day of pairing and some tooling), protect a genuine SM timebox (cost: some tech-lead hours), and appoint a Product Owner with ordering authority (cost: a decision, not a hire).

If leadership still wants the hire, propose a two-sprint test with pre-agreed measures: cycle time, deploy frequency, Sprint Goal attainment, and voluntary attrition risk on the two engineers who asked to transfer. Review the data together and decide. Name the real risk explicitly: the exit of two senior engineers costs more than either option under discussion.

Finally, state what you are not saying. A part-time Scrum Master can work. It does not work here, because the other half of the role is the team's bottleneck and its quality gate.