On an adaptive team the people doing the work decide how it is done, and somebody who owns the value, such as a product owner, decides what is built and in what order. A project manager arriving on such a team from predictive work finds that two of their three traditional jobs have already been given away. Deciding what is worth building belongs to the value owner. Deciding how to build it, and in what order within a cycle, belongs to the team. What remains is everything that faces outward from the team, and that is a substantial job in its own right.
Candidates find this topic awkward because the popular accounts say the role disappears. The examination does not take that position. It assumes that somebody holds accountability for the project, asks what that person should do in a described situation and rewards the answer that respects the team's autonomy while still owning the outcome. The sections below set out where each responsibility goes, the two ways the role goes wrong and what a sponsor is still entitled to ask.
Where each responsibility goes
| Responsibility | Where it goes | Why |
|---|---|---|
| Ordering the work by value | Whoever owns the outcome and the budget | The order is a business decision, and splitting it from accountability for value produces an order nobody stands behind |
| Deciding how the work is done | The team | The people doing the work know the most about it, and instructions from outside are guesses with authority attached |
| Estimating and committing within a cycle | The team | An estimate made by somebody else is a target, and a commitment made on a team's behalf commits nobody |
| Removing organisational blockers | The project manager | Most blockers sit outside the team, and clearing them needs the standing and the relationships the role carries |
| Managing dependencies between teams | The project manager | Nobody inside a single team can see across them, and dependencies are where multi team delivery fails |
| Funding, contracts and procurement | The project manager | These are commitments made on behalf of the organisation, and they sit outside the delivery |
| Risk beyond the team's horizon | The project manager | A team manages the risks it can see. Regulatory, supplier and strategic risk arrive from outside it |
| Reporting to governance | The project manager | Somebody has to translate delivery into the terms the organisation funds and governs in |
The right hand column is the useful part. Each split follows from who holds the information or the authority, so an unfamiliar responsibility can be placed by asking the same question, without needing to recall a table.
The two ways the role goes wrong
Placing responsibilities is easier on paper than in a working week, and the role fails at either of two extremes. A project manager who runs an adaptive team as though it were a predictive one produces the familiar symptoms. Tasks are assigned, utilisation targets are set for each person, status is requested in meetings when it could be read from the board and a private plan is maintained that drifts away from what the team is doing. The team stops raising problems, because a person who raises a problem to somebody who will solve it for them soon loses the ability to solve it themselves.
Withdrawing entirely is the opposite failure, and it is discussed less. A team left alone still has dependencies it cannot resolve, a sponsor it cannot influence and a funding conversation it is not part of. A project manager who has decided that self management means staying out of the way leaves that work undone, and the team is then blocked by things it was never placed to clear.
The position between the two is that the team owns the work and the project manager owns the conditions the work happens in.
The acts that serve the team
Owning the conditions is what PMI calls servant leadership, and it is easy to agree with and hard to recognise in a scenario question, because every option sounds supportive. The acts that count are concrete.
Clearing a blocker means going to whoever controls the thing that is stuck and coming back with a decision or a date. Protecting focus means absorbing the requests that arrive in the middle of a cycle and holding them for the next planning conversation, so the team never sees them until then. Supplying context means making sure the team knows why the work matters and what happens if it is late, which is what lets the team make sensible tradeoffs without asking.
Each of these is an action with a visible result. In a question, the option where the project manager takes an action outside the team on the team's behalf is usually the better one, and the option where the project manager addresses the team about how it should work is usually the distractor.
How the role changes with more teams
With one team the role is light on coordination and heavy on the organisation around the team. With eight teams delivering one product, coordination becomes the larger half of the job.
Dependency management between teams, a shared view of the whole, integration and release coordination and consistency of standards where inconsistency would cost money all appear at that scale. None of that sits inside any one team's remit, and none of it is a reason to take back the decisions that belong to the teams. The common error at scale is to reinstate central planning under a different name, because coordination genuinely is needed and central control is the familiar way to produce it.
What the sponsor is entitled to
Whatever the scale, the sponsor who funds the work is entitled to know four things. What has been delivered, what it has cost, what is expected next and with what confidence, and what could stop it. Those questions can be answered from a release burnup, a spend figure and a risk register, and answering them is part of the role.
The answer that fails is a description of the process. A sponsor asking when a capability will be ready needs a range, the basis for it and what would narrow it. A description of two week cycles and continuous reprioritisation answers a question the sponsor did not ask.