The Architect and the Twelve Developers
A logistics company runs one 'Scrum Team' of fourteen: a Product Owner, a Scrum Master and twelve Developers across two time zones. The Product Owner is also the line manager who approves leave and sets individual objectives. A senior Developer known as 'the architect' reviews and assigns every item in the Sprint Backlog before anyone starts work. Sprint Planning consists of the Product Owner reading a feature list while the architect estimates alone; the other Developers stay silent. The Scrum Master attends the Retrospective only when time allows. The Product Owner has begun joining the Daily Scrum to ask each person what they did yesterday, because 'the board is not moving fast enough'.
1. Identify the accountability problems in this setup and rank them by impact on the team's ability to deliver a usable Increment.
Read the worked answer
Highest impact - the Developers are not self-managing.
- The architect assigning all work removes the Developers' accountability for turning the Product Backlog into an Increment and for adapting the plan daily toward the Sprint Goal. The Sprint Backlog becomes someone else's plan imposed on them.
- Silent Planning means the people doing the work never commit to the how. Estimation by one person is also a single point of failure.
High impact - the Product Owner's dual role.
- The Product Owner is accountable for maximising value from the Product Backlog. Approving leave and setting individual objectives gives them people-management power over the Developers, which distorts every backlog conversation into a performance conversation.
High impact - team size.
- Twelve Developers exceeds the 'typically 10 or fewer' guidance for a Scrum Team. Coordination cost, not skill, is the constraint.
Moderate - the Scrum Master's absence from the Retrospective is a direct failure of the accountability for the team's effectiveness.
Lower but real - the Product Owner attending the Daily Scrum to check progress. The Daily Scrum is for the Developers; the Product Owner's legitimate route to progress is the Sprint Review and direct conversation, not a daily interrogation.
Ranking matters: fixing the architect's assignment behaviour and splitting the team unlocks more than banning the Product Owner from the Daily Scrum, which is merely a symptom.
2. The organisation says headcount cannot change and 'Scrum Master, just make it work'. What is your response, and what are you actually accountable for here?
Read the worked answer
The Scrum Master is accountable for establishing Scrum as defined and for the team's effectiveness - not for absorbing structural problems silently.
What I would do:
- Propose the structural fix, not a behavioural patch. Two Scrum Teams of six Developers each, sharing one Product Backlog, one Product Goal and one mutually defined Definition of Done if they work on the same product. That is Scrum-compatible; a fourteen-person team is not.
- Make the cost visible in evidence, not opinion: cycle time, how long work sits between 'started' and 'Done', defects found after the Review, Retrospective actions that never complete. Numbers from this team beat a lecture on the Scrum Guide.
- Coach the Product Owner on the separation of accountabilities - the Product Owner orders the backlog and maximises value; they do not manage people's leave or objectives. If the dual role cannot be removed, at minimum it must not appear in Sprint Planning or the Retrospective.
- Work with the architect directly. Frame it as an accountability shift rather than a demotion: the architect's value is in technical guidance during refinement and in the Definition of Done, not in task assignment.
I have no authority to restructure the org chart. I do have an obligation to refuse to describe the current state as Scrum, and to keep surfacing the impediment to whoever can act on it.
3. The Product Owner asks you: 'Can't I just tell the architect to stop assigning work?' What is the correct answer within Scrum?
Read the worked answer
Not quite - and the distinction is worth being precise about.
The Product Owner does not manage the Developers. Their lever is the content and order of the Product Backlog, plus the value conversation at the Sprint Review. Telling the architect to stop assigning tasks would be one accountability directing another, which is exactly the pattern causing the problem.
The Developers are accountable for the Sprint Backlog collectively, including how work is organised and who does what. So the correction has to come from the Developers, not from above.
Practical sequence:
- The Scrum Master raises the pattern in the Retrospective, framed as 'how do we self-manage the Sprint Backlog?' rather than 'the architect is a control freak'.
- The Developers agree how they will pull work. If they genuinely want a technical reviewer for design decisions, that is a legitimate choice - self-management includes choosing to consult. What is not legitimate is one person assigning every item before anyone starts.
- The Product Owner can express the consequence they care about - forecast reliability - and let the team own the how.
If the Product Owner escalates over the team's head to enforce a way of working, that is a fresh impediment for the Scrum Master to address with management, not a legitimate exercise of Product Owner authority.