Three Teams, One Component, Two Gantt Charts
Three teams totalling 24 people build one payments product. Sprint lengths are two, three, and two weeks. Team B owns a shared authentication service; teams A and C need changes to it every sprint and wait an average of eleven days. A delivery manager tracks 40 dependencies in a spreadsheet and runs a weekly Scrum of Scrums attended by three tech leads, which produces status but no decisions. Each team has its own Definition of Done; integration testing happens in a six-week phase before release. The PMO requires 90 percent adherence to a Gantt chart rebuilt each quarter and asks for percent-complete by team. Two of the three teams have never released independently.
1. Rank the problems by leverage. What single change would you make first and why?
Read the worked answer
Ranking by constraint, not by annoyance. The eleven-day wait on the shared service is the largest single loss of throughput and it is structural. Below it: the six-week integration phase, which is a consequence of three definitions of done that exclude integration. Below that: the Scrum of Scrums that produces status without decisions. The Gantt and percent-complete demands are real but they are reporting artefacts; fixing them changes no flow. Sprint length mismatch is a coordination friction, not the constraint.
First change. Turn the authentication service into a product rather than a dependency. Either publish a versioned interface with self-service configuration so A and C can change it without queuing behind B, or embed platform engineers from B into A and C with a stated response expectation. The choice depends on whether the requested changes are configuration or code, which the dependency spreadsheet should already reveal.
Why first. The current response manages the dependency: forty rows, a weekly meeting, three tech leads. Managing a dependency costs coordination and leaves lead time untouched. Removing it is the only move that reduces the wait itself. Measure dependency count and wait time; a standard change should drop from eleven days to under one.
2. The PMO wants percent-complete per team and Gantt adherence. How do you respond without becoming obstructive?
Read the worked answer
Assume the PMO's need is legitimate and name it: credible forecasts and early sight of risk. Then show that the requested instruments do not deliver that need. A Gantt rebuilt quarterly is out of date within weeks because the work is empirical, and percent-complete per team cannot be aggregated into a product forecast - sixty percent of each of three teams is not sixty percent of a release, especially when nothing is integrated.
Offer substitutes that meet the need better.
- A product-level roadmap of outcomes with confidence ranges, refreshed at each Sprint Review.
- A live dependency and risk board replacing the forty-row spreadsheet, showing each blocker, its owner, and expected resolution date.
- Throughput-based forecasts with ranges at product level, explicitly not per team.
- Progress expressed as what is demonstrably done against a unified definition of done, because a working increment is a fact while percent-complete is an opinion.
Invite them in. Ask the PMO to attend the Sprint Review; their need is then met by the artifact itself rather than by a report about it. Propose one quarter as an experiment with agreed decision criteria.
If the mandate holds. Be transparent that adherence measures conformity to a plan, not progress, and log it as an organizational impediment with data attached. The accountability is to remove it, which usually means escalation with evidence rather than refusal.
3. How would you decide whether to reorganize the teams around the shared service? What evidence would settle it?
Read the worked answer
Frame the decision as a handoff question. The right structure minimizes handoffs for the most common type of work. So first establish what the work is.
Evidence to gather. Of the 40 dependencies, how many cross the authentication boundary? What share of teams A and C's lead time is waiting on B, measured, not estimated? Are the requests configuration or code? Is B's work genuinely different in nature from feature work, or is it feature work wearing a platform label? How often do A and C need changes that could be self-service with a better interface?
The options, cheapest first. (1) Keep B, publish a versioned interface and self-service configuration. (2) Keep B, embed platform engineers in A and C. (3) Split B into an enabling team plus distributed ownership. (4) Re-cut all three teams around value streams so each owns its slice end to end, including the service.
Test before restructuring. Reorganizing 24 people is expensive, destabilizing, and takes a quarter to settle. Run option 1 or 2 as a two-sprint trial with one team and measure wait time and defect rate across the boundary. Only if the interface route fails to move the number is restructuring justified.
The goal is not to adopt a scaling framework. It is a shorter path from idea to validated increment, and the measurement should be stated before anyone moves desks.