Team-Level Green, Program-Level Red
Northline Retail's e-commerce program has six teams and 48 people building a shared checkout capability. Each team runs two-week iterations, has its own definition of done, and passes its own tests. Yet release 4 leaked 41 defects into system test, 29 of them in seams between teams; the shared integration environment is available three days a week and is double-booked; about 30% of stories carry a cross-team dependency, discovered mid-iteration. The program manager runs a weekly status meeting where team leads report green, but the release date has slipped twice. Teams say they are 'doing DA' because they run retrospectives and have product owners. The CIO wants a new dependency-tracking tool. You are brought in as coach.
1. Teams say they are 'doing DA.' Why are team-level retrospectives and product owners insufficient here, and what should the coach say?
Read the worked answer
DA is not a team-only method; it explicitly includes program and enterprise process blades. The symptoms are systemic: 29 of 41 defects sit in seams between teams, 30% of stories have late-discovered dependencies, and the integration environment is double-booked. No amount of team retrospectives fixes a shared environment booking policy or a missing program-level definition of done. The coach should reframe: the teams are doing some team-level practices, but the program lacks the coordinating practices that make those practices add up.
Say it with the data: team-level green status coexists with release-level slippage because each team's definition of done stops at its boundary. The first move is not a tool; it is a program-level retrospective and a dependency and integration design session. A tool would automate a broken process and hide the seams.
2. Propose the first three program-level changes, in order, and explain why that order.
Read the worked answer
First, make integration visible and continuous: publish an environment booking policy with named owners and run an automated cross-team build at least daily. This addresses the largest defect source and the double-booking immediately. Second, establish a program-level definition of done that requires cross-team integration tests and a demo of the end-to-end checkout flow before a story counts as done. Third, create a dependency board reviewed twice weekly, with each dependency having an owner and a date; do not accept 'discovered mid-iteration' as normal.
The order matters because a dependency board without integration capacity just documents waiting, and a program definition of done without an integration environment cannot be verified. Use guided continuous improvement: pick one change, run it for two iterations, measure defect leakage and dependency discovery timing, then keep or adjust. The CIO's tool request should wait until the process owner and policies exist.
3. The program manager wants a dashboard for the CIO. What should it show, and what should it not show?
Read the worked answer
Show flow and outcomes at the program level: end-to-end cycle time for a checkout change, percentage of dependencies discovered before iteration start, integration build pass rate, defect leakage into system test, and release predictability against committed dates. Show trend lines, not team rankings. Do not show individual team story points or green/red status by team lead report; those reinforce local optimization and hide seams. Add a short narrative of the top three systemic impediments and the experiment underway.
This aligns with DA's principle of transparency and optimizing the whole, not the parts. If the CIO wants a single number, offer release predictability plus defect leakage as a pair; a single number invites gaming, as story-point rankings do elsewhere. Review the dashboard monthly with the teams, not only with executives, so it drives improvement rather than reporting theater.