Scrum for agencies: what adapts to client work and what does not

The statement of work was signed in March. Twelve weeks, fixed price, three milestone payments, and a scope annex with forty-one bullet points in it. Everybody signed happily, because the annex looked like certainty.

In week two a developer picks up the bullet that reads "integrate with the client's CRM" and finds out that the CRM is an on-premise install from 2014, the only integration surface is a SOAP endpoint, and nobody currently working at the client has the credentials for it. The estimate behind that bullet was three days.

It is not three days.

So now comes the conversation, and the conversation is the actual job. Somebody on your side has to get on a call and explain that a line in a signed contract was wrong, without it landing as either a confession or a shakedown. The client has a budget approved against that number and a boss who approved it. Your team has forty other bullets to get through. And the framework you are running, all the refinement and the sprints and the reviews, has absolutely nothing to say about any of it.

That is scrum for agencies in one scene. The framework itself adapts to client work almost completely. It is the client relationship that does not adapt, and treating those as one problem is why so much agency scrum turns into a costume.

What actually breaks, and what survives fine

Go through the parts one at a time and most of them survive an agency without a scratch.

Sprints work. Refinement works, arguably better than in-house, because a client project has a natural forcing function for keeping the top of the backlog clear. Estimation works. A review at the end of every sprint works extremely well in client work, because you were going to have to show them something anyway, and now the showing has a schedule. Retrospectives work, provided nobody writes down anything they would not say in front of the client, which is a real cost worth naming. Even the definition of done survives, and gets sharper, because in client work "done" eventually has to mean "we are willing to invoice for this."

One thing does not survive, and it is not really a scrum thing at all.

Open the 2020 Scrum Guide and search it. The word "contract" appears zero times. So do "client", "vendor", "budget" and "price". The entire commercial relationship that agency work is made of goes unmentioned in the document that defines the framework. "Project" shows up exactly once, in the line "Each Sprint may be considered a short project."

That absence is a scope decision rather than an oversight, and it tells you precisely where the seam runs. Scrum assumes the person deciding what to build can change their mind cheaply. A fixed-price contract exists specifically to make changing your mind expensive. That is the collision. Nearly every complaint agencies have about running agile for client work is downstream of that single sentence: the borrowed product owner, the change requests, the awkward Tuesday status call, the sprint that quietly turns into a milestone checklist. All of it comes from the same place.

Which means the useful question is not "how do we do scrum properly with clients." It is "which of these two things do we bend."

Can a client be the product owner?

No, not by default. Take a position on this early, because leaving it ambiguous is worse than getting it wrong.

The product owner accountability is not a title, it is a job with a response time. Somebody has to order the backlog and reorder it as things are learned, decide between two options while a developer is waiting, and accept or reject work. That is a daily granularity, sometimes hourly. A client contact who has a full-time job elsewhere, sits in a different company, and joins a call on Thursday cannot do it, not because they are unwilling but because the calendar physically does not allow it.

The deeper problem is authority. A product owner's main instrument is reordering: pull that forward, drop this, swap the two. Under a fixed-price statement of work, that instrument is precisely the one the contract disabled. You cannot own a backlog you are contractually forbidden from changing. Hand a client the product owner role on a fixed-price project and you have given them a steering wheel that is bolted to the floor. They will notice, and it will feel to them like process for its own sake, which is a fair reading.

The Scrum Guide has exactly one line about what a product owner needs from everyone around them: "For Product Owners to succeed, the entire organization must respect their decisions." Try reading that across an agency boundary and it stops parsing, because there are two organizations. The one whose decisions have to be respected is the client's, and it does not employ, pay, schedule or manage a single person on the delivery team. The one that does employ them has its own commercial interest in what order the work happens in. Most writing on this frames client-as-product-owner as a calendar problem, that the client is simply too busy. The calendar is the smaller half of it.

Now the concession, because people who have thought about this for longer land somewhere else.

Mike Cohn's position is close to the opposite of the one above. Writing about outsourced development, he notes that the vendor typically appoints a product owner from inside its own organization, and then says plainly: "The client is, of course, the true product owner." He is right about the part that matters most, which is acceptance. Whoever holds the title on your board, the client decides what counts as finished, and they can overturn your internal product owner's approval at the review without breaking a single rule. Any arrangement that forgets this is going to be corrected, eventually, in a meeting nobody enjoys.

The instinct in most agencies is to always keep the product owner role in-house and hand the client a stakeholder badge. That is the safe answer and it fails in a specific, recognisable way. Your in-house proxy has all the context and none of the authority, and the client has all the authority and none of the context, so every real decision bounces between two people who each need the other to answer. The proxy becomes a message broker with a job title. That is worse than a slow client product owner, because at least a slow product owner is one person.

So a client genuinely should be the product owner when three things are true at once. Their person is a product person rather than a procurement person. They hold enough budget authority to trade scope without escalating. And the engagement is time-and-materials, or capped time-and-materials, so that trading scope is a normal Tuesday rather than a contract amendment. That is roughly the shape of a long retainer, and in that shape a client product owner is not merely acceptable, it is better than anything you can staff internally, because the translation layer disappears.

If those three things are not true, keep the accountability on your side and be honest with the client about why. "You are the person who decides whether this is right, we are the people who decide what order it gets built in" is a sentence most clients accept immediately, because it describes what was already happening.

Where this gets uncomfortably concrete

In Scrumpy, roles are per team, and every new team is seeded with four of them: Product Owner, Developer, Tester and Stakeholder. Because they are per team rather than per account, the same person can be Product Owner on one client's board and Stakeholder on another, which is exactly the shape agency life takes.

The default development board also ships with a lane called Stakeholder, and that lane auto-assigns anything that lands in it to whoever holds the Product Owner role on that team. It is a small piece of plumbing and it turns out to be an excellent lie detector.

Give a client the Product Owner role and cards will start appearing in their name, automatically, as work reaches them. If that client is a free view-only member, they can read the card and they cannot move it, because view-only members are read-only once your trial ends. Which is a fairly precise mechanical description of what "the client is the product owner" usually means in practice: work formally assigned to someone with no ability to act on it, sitting in a lane, waiting.

If reading that made you wince slightly, the client is not your product owner. That is fine. Make them a Stakeholder, put the Product Owner role on whoever on your side genuinely answers for the order of the backlog, and let the lane assign to a person who can actually clear it.

Three projects, one team

The tooling half of this is easy and the human half is not, so it is worth separating them.

The easy half: one board per client. In Scrumpy that maps directly onto teams inside a single organization, and the separation is real rather than cosmetic. Each team carries its own status columns, its own roles, its own story prefix so references never collide, its own sprint length and its own story point scale. Non-admin members only see the teams they belong to, so a client can never wander into another client's backlog. Organization admins, which is to say you, see all of them.

The hard half: people. Scrum is unusually blunt here, for once. The Scrum Team is "a cohesive unit of professionals focused on one objective at a time", the product backlog is "the single source of work undertaken by the Scrum Team", and the sprint goal exists to encourage the team "to work together rather than on separate initiatives". A team serving three clients at once contradicts all three of those, and no amount of staggering the ceremonies changes it.

That does not mean you must never do it. Most agencies of this size have no realistic alternative. It means you should be honest that what you are running at that point is a set of scrum practices rather than scrum, and stop expecting the feedback loops to behave as advertised.

A developer split across three simultaneous sprints is not committed to three sprints, they are committed to none, and everybody involved knows it by Wednesday. Worse, your per-project velocity turns into noise the moment people start rotating, because the number was never measuring the project, it was measuring how much of that person the project happened to get that fortnight. Two sprints of clean data followed by a reshuffle gives you nothing to plan with.

The rule worth defending is one primary project per person per sprint, even when the boards outnumber the people. It costs you some theoretical utilisation and it buys you sprint commitments that mean something. If you truly cannot hold that line, at least stop reporting velocity per project and stop making sprint commitments you know are conditional on nobody else needing anything. An honest "we do not know yet" beats a commitment that dissolves.

Sprint length is worth a second thought here too. A twelve-week fixed-price project cut into two-week sprints gives you six chances to show progress and correct course, which is enough. Cut the same project into four-week sprints and you get three, and the first one is gone before you have learned anything. Client work rewards the shorter end of the range, and it is worth choosing a length deliberately rather than inheriting whatever your last project used.

The stakeholder who wants a status update on Tuesday

This is the part agencies waste the most hours on and the part that is easiest to actually fix.

The weekly status report exists for one reason: the client cannot see the work. Every hour spent assembling one is an hour spent manually re-typing information that already exists in your tool, into a format that is out of date by the time it is read. Give them the board instead. In Scrumpy that costs nothing, because view-only members are free and unlimited, and only editors count towards the bill. A client, their account manager and three of their stakeholders can all watch the backlog and the sprint update in real time without moving your invoice by a cent. That is the whole premise of building a scrum tool for agencies, and it is why we think charging for read-only access is a bad idea in general.

One practical wrinkle on the seats, since agency staffing moves mid-month. Promoting a viewer to editor applies immediately and is prorated. Demoting an editor back to a viewer is scheduled for your next renewal instead, so that seat stays paid until the period ends. When somebody rolls off one client and somebody else rolls onto another, reassigning the existing seat to the new person is the move: it takes effect immediately on both sides and the quantity never changes.

Two honest caveats, though, because "just give them the board" is where this advice usually gets oversold.

A live board does not remove the status conversation. It changes what the client asks. They stop asking "how is it going" and start asking why that card has been sitting in Code review for nine days. That is a better conversation and a more uncomfortable one, and you should decide you want it before you hand out the link.

And do not confuse a raw board with transparency. If your card titles read "fix the thing" and "PO feedback", a client watching them will not become informed, they will become anxious, and you will spend more time on reassurance than the status email ever cost. A board is only shareable if the work is legible from the outside, which is the practical case for readable titles, a definition of done you would read out loud, and a top-of-backlog that has actually been refined rather than accumulated. Switching on client access takes about a minute. Earning it takes a standard you hold your own card titles to.

The contract, bent slightly

If the collision is between fixed scope and adaptive planning, something has to give, and the honest options are narrower than the agile literature usually suggests.

The arrangement that reliably fails is fixing budget, deadline and scope simultaneously and then running sprints inside it. That is a waterfall project wearing a board. The sprint boundaries become milestone checkpoints where nothing can be reordered, because everything has already been promised. Teams in this position often conclude scrum does not work for agencies. What is not working is the contract.

The version that does work is fixing two and floating one, and for client work the two worth fixing are usually budget and deadline, because those are the two the client actually needs for their own planning. Scope becomes the variable: the total size stays capped, but which items fill it stays orderable, so when week two turns up a SOAP endpoint from 2014, the conversation is "which item of similar size comes out" rather than "who pays for this." That conversation is survivable. It is also a conversation the client can only have if they have been watching the backlog all along, which is the second reason the live board matters.

This is older and more solved than most agency discussions of it suggest, and it is worth knowing that before you reinvent it in a meeting. Jeff Sutherland published two clauses for exactly this problem in 2008. Change for Free lets the customer swap scope in and out at sprint boundaries at no extra cost, so long as the total contracted scope does not grow. Money for Nothing lets them end the contract at the end of any sprint by paying twenty percent of the remaining value, once they have got what they actually needed.

The detail that gets dropped almost every time these are repeated is the condition attached to both. They apply only if the customer "maintains Participation in Scrum Team during the entire project", and Sutherland spells out what participation means: prioritise by business value, agree the estimates, attend planning, co-write the conditions of satisfaction, come to the review and give feedback in time to matter. If the client stops doing that, the clause lapses and the contract reverts to time and materials.

Which reframes the whole arrangement. Read properly, that is a participation agreement that happens to have a price on it. Flexible scope is what the client gets paid in, and attention is what they pay with. Every agency complaining that its client will not engage is, more often than not, describing a contract that never asked them to.

It also makes the shared board considerably less of a nicety. If the client's half of the bargain is attention, the most useful thing you can do is make paying attention cost them thirty seconds rather than a scheduled meeting.

None of that removes the March problem. Something was estimated at three days that was not three days, and somebody is absorbing it. The point of keeping scope orderable is that the absorption is a decision made together in week two, rather than a dispute discovered in week eleven.

The retainer board is not a project board

One more shape that agencies almost always get wrong: forcing support and retainer work into sprints because the project teams use them.

Support work does not have a sprint boundary. It has a queue, an age, and a client who is waiting. In Scrumpy you can switch sprints off entirely for a given team, which turns that board into a simple flow with New, In progress, Waiting and Resolved lanes instead of a development pipeline, and hides story points and the dev-oriented type field that were never useful on a support ticket. Priority stays, because urgency is the only real ordering on a support queue. Your project teams keep their sprints. The retainer team stops pretending.

That team is also the one where an API key earns its keep, because keys are scoped to a single team. The client's own support form can raise stories straight onto their support board and nowhere else, which means the intake step where somebody copies an email into a card just disappears.

Worth being clear about the limits while we are here: the flow board is a simple queue, not a full kanban system, and there are no work-in-progress column limits. If you need enforced WIP limits on your support lane, that is a genuine gap and you should know it before you move.

Where to start

The contract is going to keep being the hard part. No tool has ever fixed a scope annex, and any vendor telling you their board resolves a fixed-price disagreement is selling you something. What software can do is remove the busywork that grew up around the relationship: the status report that re-types what the board already knows, the seat you had to buy so a client could look at their own project, the shared board where one client can see another one's work.

If you want to try the shape, pick your worst-behaved client project rather than your best one. Give it its own board, put the client on it as a free viewer, decide out loud who holds the product owner accountability, and see whether the Tuesday conversation gets better or just louder. The well-run project was never the test.