1. Why This Document Exists
Scrum names three roles and leaves everything else to the organization. That is a strength when the organization has thought about it and a liability when it has not. This program runs two teams, 28 people, and a set of reporting lines Scrum has no opinion about — so the useful document is not a restatement of the Scrum Guide but a statement of who actually decides what here.
2. The Shape of the Organization
The Product Owner's reporting line runs into the business, not into the program. D. Ashworth reports to M. Delacroix, VP Digital Health — who is also the program's Executive Sponsor, which is common where the exec who owns the product line also sponsors the delivery. What matters is the direction: the line is a solid business reporting line, and the connection to the program is dotted. A Product Owner who reports into delivery is a proxy Product Owner wearing a different title. Allocated about 50%. Everything below is the delivery organization: two delivery teams — Falcon (mobile-facing) and Anchor (backend and integration) — each with a Scrum Master, and engineering staff reporting to engineering managers rather than to the program. D. Whitfield holds Falcon's engineers, A. Singh holds Anchor's. That separation is deliberate and it is the main control on the conflict above: the person holding the Product Owner role cannot quietly reallocate an engineer, because he does not hold the engineers.
| Function | Who | Owns | Does not own |
|---|---|---|---|
| Product Owner | D. Ashworth (business-funded) | Backlog order, acceptance, and the value case for every item | How the work is done, or how much fits in a sprint |
| Agile Delivery Lead | C. Tyrrell | Cross-team dependencies, release coordination, external reporting, and the integrated view the sponsor sees | Backlog order, acceptance, or either team's internal process |
| Scrum Master, Falcon | J. Marsh | Team process, impediment removal, and the team's right to say what it can commit to | What is built, or in what order |
| Scrum Master, Anchor | R. Okafor | As above, for Anchor | As above |
| Engineering (Falcon) | D. Whitfield + 4 | Technical design, estimates, and the definition of done | Priority |
| Engineering (Anchor) | A. Singh + 4 | As above, plus the video SDK integration | Priority |
| Quality | E. Marchetti, N. Osei + 3 | Test strategy, automation, and the quality signal at each sprint review | Whether to release — that is the PO's, informed by them |
| Business Analysis | F. Delgado | Story elaboration, acceptance criteria, and the clinical-workflow detail | Backlog order |
| Clinical advisory | Dr. L. Nguyen, CMIO | Clinical safety judgment — see §5 | — |
3. Governance — Who Decides
Agile programs are often described as having no governance. This one has three decision points; they are simply faster and smaller than a stage-gate program's.
| Decision point | Who decides | Cadence |
|---|---|---|
| Backlog order within approved scope | Product Owner, alone | Continuous |
| Sprint commitment | The team, alone | Each sprint |
| Anything touching cost, release date, or a compliance-relevant timeline | Executive Sponsor (M. Delacroix) | On demand |
4. The Functions, One at a Time
The Product Owner owns order and acceptance, and — critically — owns them from the business side, with the standing to tell a stakeholder no. Not scope creep control — anything outside the approved envelope leaves the PO's authority entirely and goes to the sponsor. Not capacity. The most common misreading of the role is that a PO who wants more can get more by prioritizing harder.
The Scrum Masters hold the one thing neither the Product Owner nor the Delivery Lead may take: the team’s right to state its own capacity. J. Marsh and R. Okafor report to the Delivery Lead administratively, and on this single question they are expected to disagree with him in public if needed. A Scrum Master who never contradicts delivery pressure in front of the team is not doing the job.
Engineering owns the definition of done, which is a scope decision disguised as a technical one. If “done” quietly stops including accessibility checks in a squeezed sprint, scope has been cut without a decision being recorded anywhere.
Quality gives a signal, not a verdict. E. Marchetti and N. Osei report the state of the build at each sprint review; the release decision is the Product Owner's. ⚠ Two of the five QA staff are offshore (M. Chen, P. Kumar) and report to the onshore QA Lead, not to a vendor manager — that reporting line is what makes them part of the team rather than a supplier.
5. The Bodies the Program Cannot Instruct
The Chief Medical Information Officer (Dr. L. Nguyen) is external to the program, allocated about 10%, and connected by a dashed line for a reason. The program cannot overrule a clinical safety judgment. If the CMIO says a workflow creates a risk of a missed result, that is not an input to be balanced against velocity — it is a stop. The dashed line exists to make the absence of authority visible on the chart itself.
The team, on sprint commitment. Named again deliberately, because it is the boundary most at risk. It is the one decision no role above the team can take.
6. How This Differs From the Stage-Gate Programs in This Portfolio
Worth stating plainly, because the same person runs several of these suites and the roles do not transfer cleanly.
| Question | Here (Scrum) | Stage-gate (PM, Pharma, Lighthouse) |
|---|---|---|
| Who orders the work? | Product Owner, continuously | The plan, set at baseline and changed by CR |
| Who commits to how much? | The team, each sprint | The program, at baseline |
| Where does change get decided? | The sprint boundary | A change control board |
| What stops the work? | A clinical safety judgment | A gate decision |