The Agile Manifesto prescribes no roles, ceremonies or estimation technique — so how do you decide how much process a team needs?
answer
- Count what the document actually names
- The silence about method is deliberate
- Every practice should name its principle
- Measure the latency a practice adds
basics
~20 sDecide from constraints, not a catalogue. Every practice should name the principle it serves, be the cheapest thing that serves it, and stay removable by the team using it. The Manifesto supplies values and principles only; the method is a local decision.
solid answer
~50 sThe document names four values, twelve principles and nothing else — no roles, no meetings, no artefacts, no unit of size, no team size, no tooling. That silence is deliberate, and it makes the method a local design decision somebody has to own. I start from constraints: how long feedback takes to arrive, how coupled the work is, what evidence the domain is obliged to produce, and how experienced the team is. Then every practice earns its place by naming the principle it serves, being the cheapest thing that serves it, and remaining removable by the team. Size each one by the **latency** it adds, not the minutes it costs. The two failure modes are opposite and equally common: importing a named framework whole because it is recognised, and 'we are agile, so we need no process', which reads a ranking as a ban.
go deeper
Know that the Manifesto is values and principles only — it names no meetings, roles, artefacts or unit of size. Anything beyond that came from a framework built on top of it, not from the Manifesto itself.
Be able to explain why the silence matters: any practice you follow is a choice somebody made, so you may ask which principle it serves and what it costs. Bring one example of a practice your team changed or dropped.
Show how you would size process for a real team: the constraints you read first, the practice you would add or remove, and the signal that would tell you the change worked. Talk about latency, not just effort.
Own the design and its politics. Be ready to defend a deliberately light process to a governance function, to separate the evidence the organisation needs from the ritual attached to it, and to keep removal authority with the team.
## What the document actually contains Four values, twelve principles, and a closing qualifier. That is the whole of it. It is worth listing what it therefore does **not** contain: - no roles or accountabilities, and no team size - no meetings, no cadence and no timebox lengths - no artefacts, no wall layout, no charts - no estimation technique and no unit of size - no tooling, no branching model, no engineering practice named - no test for when a team may call itself agile Every one of those arrived later, from frameworks and communities built on top of the values. Confusing the two is the most common factual error on this subject, and it matters practically: if a practice came from a framework rather than the Manifesto, it is a choice somebody made, and choices can be examined. ## Why the silence is load-bearing A document that prescribed a method would have to prescribe it for a two-person team maintaining a routing service, for a regulated system that must evidence every decision, and for a group split across a nine-hour timezone gap. It would be wrong somewhere immediately, and the wrongness would be blamed on the values. By stopping at values and principles, the Manifesto pushes the method down to the people who can see the constraints — which is itself the content of two of its principles: teams that organise their own work, and teams that tune their behaviour at regular intervals. The consequence for a lead is uncomfortable but clarifying: **there is no authority to appeal to.** Nothing settles how much process is right for your team, and a framework's popularity is not evidence about your constraints. ## Sizing process from constraints A workable order of operations: 1. **Read the feedback latency.** How long between building something and learning whether it was right? The longer that is, the more the process must compensate with review and written reasoning — and the more valuable any change that shortens it. 2. **Read the coupling.** Work that touches several owners needs more explicit agreement than work one team can finish alone. 3. **Read the evidence obligations.** Regulated or safety-relevant domains must produce records. That is real, and the values exempt nobody from it; they only ask for the cheapest artefact that satisfies the obligation. 4. **Read the team.** A group with no shared habits needs more scaffolding than one with strong habits, and needs to be told plainly that the scaffolding is temporary. 5. **Add the smallest practice that serves a named principle**, and write down in advance what would show that it has stopped paying. ## Every practice pays rent The test I apply to any inherited practice has three parts. Which principle does it serve? Is it the cheapest thing that serves that principle? And who is permitted to remove it? A practice that fails the third part is not process — it is governance wearing process clothing. Size a practice by the **latency** it adds, not the minutes it costs. Across a quarter of 118 items, a six-field intake form costing about two and a half minutes an item comes to roughly five hours: cheap, and quite possibly worth it. A three-stage approval that adds nine days of waiting per change consumes almost nobody's working time and is enormously expensive, because the waiting attacks responding to change directly. Teams routinely wave through the second and argue about the first, because minutes appear on a calendar and latency does not. ## The two symmetric failures | Failure | What it looks like | Why it misreads the Manifesto | | --- | --- | --- | | Importing a named framework whole | practices adopted unchanged because the framework is recognised | treats a method as though the values mandated it; they mandate nothing | | 'We are agile, so no process' | no explicit agreements and nothing inspectable | reads a ranking as a ban; the right-hand item still has value | Both end in the same place: a way of working nobody actually chose. The first was chosen by an author who never saw your constraints, the second by default. ## The pressure case The reliable trigger for process inflation is distance. When a second team in another timezone starts contributing to the same product, a question that used to cost a minute now costs a day, and the reflex is to write everything down and add gates. Part of that reflex is right: this is exactly the collision where the right-hand item can honestly win, and choosing comprehensive documentation here applies the values rather than abandoning them. The discipline is to pick the cheapest artefact that genuinely transfers understanding, keep the decision with the people paying for it, and revisit it once the distance stops hurting — instead of installing permanent apparatus because a temporary constraint appeared. ## What a lead owns Owning process means owning its removal too. Schedule an explicit review of the working agreements, keep removal authority inside the team, and when a governance function mandates something, separate the evidence it genuinely needs from the ritual attached to that evidence, then offer a cheaper route to the same record. That negotiation is the principal-level skill this question is really probing.
- How do you stop a team removing practices it merely finds uncomfortable?Make removal a measured experiment rather than a vote. State what the practice was protecting, agree the signal that would show the protection is gone, drop it for a bounded period, then look. Most practices die honestly under that test, and the few that were load-bearing come back with a reason attached — which holds far better than the original mandate ever did.
- When is adopting a named framework wholesale the right call?When a team has no shared vocabulary and no working habits, a coherent off-the-shelf method is faster than designing one from scratch, and the cost of being slightly wrong is low. The condition is that it is declared a starting point: the team must be told which parts it is expected to change once it can see its own constraints.
- How do you handle a governance function mandating a process the team did not choose?Separate the evidence the organisation genuinely needs from the ritual attached to it. Mandates usually exist to produce a record — of a decision, a change review, a deployment. Offer to produce that record by a cheaper route and agree what counts as proof, rather than arguing the mandate away. The values rank processes below people; they do not cancel the organisation's obligations.
saying these in an interview costs you the question
- Assumes the Manifesto mandates specific meetings, roles or artefacts
- Adopts a named framework unchanged and calls the decision made
- Argues that being agile means having no process at all
- Sizes a practice by its meeting minutes, ignoring the latency added
- Cannot say who is permitted to remove a practice