The Scrum Master Who Signs the Appraisals
At Vantage Insurance the Scrum Master of the Policy Servicing team is also the Engineering Manager for five of the team's eight Developers. She runs their one-to-ones, signs off annual ratings and bonus, and approves training and leave. Sprints are two weeks and the team mostly meets its commitments. In the last four Retrospectives the team produced the same two actions - 'improve test data' and 'communicate more' - and nothing has changed. The flaky build server fails roughly one in three integration runs and adds about two days of rework per Sprint, but nobody has named it in a Retrospective. In confidential conversations two Developers say they will not raise it because 'it looks like we cannot do our jobs', and ratings are due in six weeks. Sprint Review attendance is good and the Product Owner is satisfied with delivery.
1. What is the most likely reason the Retrospectives keep producing the same two actions, and how does this connect to the Scrum values?
Read the worked answer
The Retrospective is technically happening but is not safe, and the Scrum Master is structurally part of the reason.
Evidence chain:
- Four identical action items with no change is the signature of a Retrospective that is not reaching the real impediment. Repeated action items are usually vague enough to be unactionable: 'communicate more' has no owner, no date and no test of completion.
- The most expensive known problem - a build server failing one run in three, costing roughly two days per two-week Sprint - has never been raised. That is not an oversight. It is a rational calculation by people whose ratings are signed by the person who would have to own the fix.
- The Scrum values at stake are openness and courage. Courage is not a personality trait; it is what people display when the cost of speaking is lower than the cost of silence. Here the cost of speaking includes a performance rating.
The Scrum Master is accountable for removing impediments and for the team's effectiveness. If she is the reason the largest impediment stays invisible, the Retrospective cannot succeed regardless of facilitation technique. Note that the guide does not forbid holding both roles; the issue is the conflict of interest it creates in practice, and that conflict must be addressed explicitly rather than managed by good intentions.
2. Assuming she cannot hand over line management immediately, what should she do, in what order?
Read the worked answer
Sequence from cheapest and fastest to structural.
- Make the problem explicit rather than secret. Say plainly to the team that she recognises the conflict: she is asking them to raise impediments that touch the systems she is accountable for, and she signs their ratings. Naming it removes the sense that everyone is pretending.
- Quantify the impediment and take it off the team's shoulders. Two days per Sprint on a team of eight is roughly 5% of capacity, every Sprint, plus the uncertainty it creates in forecasts. Present that to engineering leadership as a business case for build-server investment. The team does not need courage to raise it if she has already raised it.
- Separate the feedback channel that carries the most risk. In the next Retrospective, use an external facilitator or written, anonymised input, and explicitly exclude rating-relevant discussion. Better still, arrange for another manager to own ratings for the next cycle for these five people.
- Fix the Retrospective output. One improvement per Sprint, with an owner, a date and a way to tell whether it worked. Abandon 'communicate more' as an action item.
- Escalate the structural conflict. Propose splitting the roles, or at minimum that the Scrum Master has no rating authority over team members. This is an organisational design decision, so it needs a named owner and a date, not a vague aspiration.
Order matters because step 1 builds the credibility needed for step 5, and step 2 converts a delicate conversation into an investment decision.
3. What does servant leadership require of her here, and what would be a wrong reading of 'serving the team'?
Read the worked answer
Servant leadership means removing what blocks the team and changing the system, not shielding the team from consequence.
What it requires in this case:
- Taking ownership of the build server as an impediment, with numbers, rather than waiting for a Developer to be brave.
- Giving up a source of personal authority - rating power over team members - because it suppresses the transparency the role depends on.
- Coaching rather than rescuing: helping the team frame and prioritise its own improvements so that the Retrospective produces change they own.
- Being willing to be unpopular with management by naming the conflict of interest and the investment need.
Wrong readings to avoid:
- 'Serving means protecting.' If she suppresses the flaky-build problem from leadership to keep the team looking good, she has replaced transparency with loyalty, and the two-day-per-Sprint cost continues.
- 'Serving means deciding for them.' Choosing the Retrospective action herself, however sensible, keeps the team passive and will produce a fifth identical Retrospective.
- 'Serving means being liked.' Avoiding the awkward conversation about ratings for six weeks is the comfortable choice, not the servant one.
The test is whether the team's ability to inspect and improve its own work increases. Here, her current arrangement makes it decrease.