September 8, 2026 · 7 min read
TL;DR: Self-organisation appears in thirteen options in this bank and is keyed five times. Every wrong placement is an overcorrection in one of two directions. Some hand the team authority the project manager still has to hold, and the bank names commercial, contractual and governance decisions as the ones that stay put. Others invoke self-organisation as a reason to withdraw, delegating a decision that the team needed made with them rather than for them. The keyed answers sit in the middle: the team decides how the work gets done and who does it, and the project manager clears obstacles and protects capacity.
The term does most of the damage on its own. Once an option contains the phrase self-organisation, it acquires a kind of agile immunity, and candidates stop reading what the option actually proposes.
At the boundary the project manager remains accountable for.
The bank states it in a record about a project manager who wants the team to hold genuine decision-making authority rather than routing every choice back through them. Four options. Transfer all decision-making authority to the team, since self-organisation is an agile value. Keep the decisions with the project manager so they stay consistent. Make no formal allocation, so nobody is exposed to a decision they get wrong. Or assign decision-making authority according to team members' strengths and expertise.
Keyed is the last. The explanation dismisses the first three in a sentence each, and the one about total transfer is the one worth memorising: handing over all authority is the opposite error, because even a self-organising team does not own every decision, since commercial, contractual and governance matters remain with the project manager, who stays accountable for the project's outcome.
That gives you a clean test. When an option hands something to the team, ask whether the thing being handed over is how the work gets done, or whether it is a commitment to someone outside the team. The first belongs to the team. The second does not.
Task assignment.
A project manager with a history of predictive, plan-driven projects is assigned to an adaptive project with a self-organising team, and notices they are still assigning tasks to individuals the way they always have. Keyed is stopping individual task assignment and letting the team pull and distribute work themselves, with the project manager's role focused on removing obstacles and protecting the team's capacity.
The explanation is precise about what is wrong with the near misses, and they are near. Continuing to assign tasks but asking the team for input first still leaves the authority where it was. Assigning only the highest-priority items and letting the team self-organise around the rest concedes the principle and keeps the practice. Doing nothing as long as the team agrees with the assignments confuses consent with ownership.
The same authority test appears in the estimation records. When a scrum master notices the product owner sizing the user stories, keyed is explaining that agile teams self-organise, so the team should be estimating. And having the product owner seek the team's buy-in after estimating is offered and rejected, because buy-in after the fact still leaves the product owner making the estimate.
Wherever the phrase is used to justify a move it does not actually support.
| Scenario in the bank | Self-organisation option offered | What is actually keyed |
|---|---|---|
| PM wants the team to hold real decision authority | Transfer all authority; self-organisation is a value | Assign authority by strengths and expertise |
| PM still assigning tasks on an adaptive project | Assign top priorities, self-organise around the rest | Stop assigning; clear obstacles, protect capacity |
| Engineer proposes a root cause analysis | Have a senior engineer own it so the team self-organises | Discuss the proposal and decide together |
| Members each know a different agile method | Let the team choose a method for itself | Train them in the principles under all agile methods |
| Product owner is sizing the user stories | Product owner estimates, then seeks buy-in | The team should be estimating |
| Team wants continuous flow, not fixed iterations | Encourage self-organisation and team decision-making | Adopt Kanban to optimise flow and surface bottlenecks |
The last row is a good illustration of a distractor that is true but irrelevant. A project manager wants the team to work as continuous flow rather than in fixed iteration cycles. Encouraging self-organisation and team decision-making is a perfectly reasonable thing to do and answers a different question entirely. Keyed is adopting Kanban, which supports continuous flow by pulling new work only when the team has capacity and makes bottlenecks visible. The stem asked for a mechanism, and self-organisation is a culture.
Common trap: using self-organisation as a reason to step back from a decision the team needed you in. The bank's production incident record is built on exactly this. After a wave of incidents pushes back the release date, an engineer proposes a root cause analysis, and one option is to have a senior engineer own the analysis so the team learns to self-organise. Keyed is collaborating with the team to discuss the proposal and decide the next step together. The explanation says this does two things at once: it gets the technical judgement of the people who know the incidents, and it produces a decision the team owns, which matters because the follow-up work will be theirs. Delegating and collaborating are not the same move, and the bank flags the difference by name rather than only marking the choice wrong.
When it has no shared foundation to organise around.
An organisation that has always worked predictively hires an agile coach to lead its transition. The coach finds that team members between them know several different agile methods, but no two people share the same one. One option is to let the team choose a method for itself, since self-organisation is an agile principle.
Keyed is training the team in the principles that underlie all agile methods. The explanation gives the reasoning: a team whose method knowledge is scattered needs the common foundation first, because that is what lets them then choose a framework together and understand why. Asking a team in this state to choose invites each member to campaign for whichever method they already know.
This is not a contradiction of self-organisation. It is a statement about its precondition. A team can only organise itself around something it shares, and when the coach arrives, this team shares nothing. The principle is not suspended, it is being made possible.
The same reasoning explains a related record where a project manager leading a diverse, distributed team wants to build unity. Keyed is encouraging open communication and showing confidence in the team's abilities and contributions. The explanation notes that no misunderstanding has occurred and nothing has been misread, so this is a question about how the team is led rather than about repairing a diagnosed fault. Trust extended visibly is what makes self-organisation safe to attempt.
Does a self-organising team make every decision on the project? No. The bank keys assigning decision-making authority according to team members' strengths and expertise, and rules out transferring all authority to the team with an explicit reason: even a self-organising team does not own every decision, since commercial, contractual and governance matters remain with the project manager, who stays accountable for the project's outcome.
What should a project manager stop doing on a self-organising team? Assigning individual tasks. The bank keys letting the team pull and distribute work themselves while the project manager focuses on removing obstacles and protecting the team's capacity. Continuing to assign tasks but asking for input first is named as the near miss, because the authority still sits in the wrong place.
Is letting the team choose its own method always right? No, and the bank tests the exception. When an organisation's members each know a different agile method and no two share one, the keyed answer is training the team in the principles underlying all agile methods, because asking a team in that state to choose invites each member to campaign for whichever method they already know.
Should the project manager delegate a root cause analysis to a senior engineer so the team learns to self-organise? The bank names that option and does not key it. The keyed answer is collaborating with the team to discuss the proposal and decide the next step together, which gets the technical judgement of the people who know the incidents and produces a decision the team owns, since the follow-up work will be theirs.
PMP Practice's 2,141 questions are re-certified against PMBOK 8 and the July 2026 Exam Content Outline, and every wrong answer is explained, not just marked wrong, which is what stops a plausible agile phrase from carrying an option you should have rejected. Start the free 20-question sample — no card, no signup required to try it.
Does a self-organising team make every decision on the project?
No. The bank keys assigning decision-making authority according to team members' strengths and expertise, and rules out transferring all authority to the team with an explicit reason: even a self-organising team does not own every decision, since commercial, contractual and governance matters remain with the project manager, who stays accountable for the project's outcome.
What should a project manager stop doing on a self-organising team?
Assigning individual tasks. The bank keys letting the team pull and distribute work themselves while the project manager focuses on removing obstacles and protecting the team's capacity. Continuing to assign tasks but asking for input first is named as the near miss, because the authority still sits in the wrong place.
Is letting the team choose its own method always right?
No, and the bank tests the exception. When an organisation's members each know a different agile method and no two share one, the keyed answer is training the team in the principles underlying all agile methods, because asking a team in that state to choose invites each member to campaign for whichever method they already know.
Should the project manager delegate a root cause analysis to a senior engineer so the team learns to self-organise?
The bank names that option and does not key it. The keyed answer is collaborating with the team to discuss the proposal and decide the next step together, which gets the technical judgement of the people who know the incidents and produces a decision the team owns, since the follow-up work will be theirs.