Agile can work well in agencies, but only when it is adapted to client approvals, shared specialists, and the constant pressure of competing priorities. In this article I look at how agile changes project management inside an agency, when a hybrid model is the safer choice, and how to build a delivery rhythm that people outside the team can trust. I also cover the metrics, cadence, and mistakes that separate a neat board from a genuinely better operating model.
The practical shift agile brings to agency project management
- Agile improves flow when it reduces waiting, rework, and surprise, not when it simply adds meetings.
- Most agencies need a hybrid of Kanban and sprint-based delivery, especially when work arrives in bursts or depends on external sign-off.
- A pilot should start with one team, one type of work, and a clear definition of done.
- Cycle time, work in progress, and approval delays are more useful than vanity metrics like busyness.
- In the UK public sector, the method has to sit comfortably alongside governance, procurement, and accountability.
What agile changes in agency project management
The biggest shift is that the unit of management changes. Instead of treating work as a long list of tasks hidden inside a Gantt chart, you manage flow: what enters, what is in progress, what is blocked, and what is finished. A backlog is simply an ordered list of work, and a sprint is a short delivery window, usually one or two weeks, where the team focuses on a small set of priorities.
In an agency, that matters because work is rarely linear. A policy brief, campaign, or digital service can stall at review, legal check, stakeholder input, or client sign-off. Agile makes those delays visible early, which is often more valuable than speed on paper. I find that this visibility also reduces the manager’s temptation to chase every person separately for updates.
APM describes agile project management as iterative and incremental delivery, and that is the useful lens here. Agencies rarely benefit from a fully rigid plan; they benefit from a system that can absorb change without losing control. Once you see work as flow, the next question is whether every project should use the same cadence.
Where agile fits and where a hybrid model is safer
Pure agile is appealing in theory, but agency work often includes fixed deadlines, external approvals, and shared resources. That is why I usually recommend choosing the method by the shape of the work, not by fashion. In the UK public sector, that caution matters even more because governance, procurement, and accountability cannot be treated as afterthoughts. GOV.UK’s service manual is useful here because it treats agile delivery as a way of building and running services, not as a decorative team ritual.
| Approach | Best fit | Strength | Weak point | My view for agencies |
|---|---|---|---|---|
| Waterfall | Fixed scope, heavy approval, low change | Clear milestones and sign-off points | Slow to adapt when the brief moves | Useful for regulated work, but brittle if the client changes direction |
| Agile | Evolving scope, fast feedback, small teams | Visibility, adaptability, early learning | Can feel unstable under constant interruption | Works best when the client can engage often and decide quickly |
| Hybrid | Mixed work, multiple stakeholders, public-sector or agency portfolios | Balances control with flexibility | Needs discipline, or it becomes vague | Usually the best default for real agency environments |
My rule of thumb is simple. Use more agile practices when the brief is uncertain, when feedback will materially improve the output, or when the team needs to learn as it goes. Use a hybrid model when the deadline is fixed, the approval chain is long, or one bad assumption will create expensive rework. The next step is rolling it out without making clients feel that the process has suddenly become less dependable.
How to roll it out without breaking client confidence
I would not launch agile across every account at once. A better move is to pilot it in one team, on one work type, where the rules are visible and the client relationship can absorb a few weeks of adjustment. The goal is not to prove that the team can hold more meetings; the goal is to make delivery clearer, faster, and less fragile.
- Map the work into clear classes such as retainers, fixed-scope projects, urgent requests, and internal improvement. The point is to separate predictable flow from interrupt-driven work.
- Pick one pilot team with enough volume to show patterns, but not so much pressure that everything is already in crisis.
- Set a cadence that people can keep: a 2-week sprint, a 10- to 15-minute daily stand-up, a 60- to 90-minute planning session, a 30- to 60-minute review, and a 45- to 60-minute retrospective.
- Define the board states and the definition of done. If a task needs legal approval, accessibility review, or client sign-off, that belongs in the process, not in someone’s memory.
- Agree response windows with the client side. If approvals arrive in the same hour every time, the team can plan around them. If not, the project manager needs an escalation path.
- Review after 6 to 8 weeks. That is long enough to see whether flow improved, but short enough to change the model before people lose patience.
The first rollout should feel calm, not dramatic. If people cannot explain the process in one minute, it is probably too complex. Once the pilot is running, the real work is keeping priorities stable enough for the team to finish what it starts.
The daily rhythm that keeps work moving
Most agency teams do better with a visible weekly rhythm than with a rigid promise to every brief. I usually recommend a single prioritised backlog, a strict limit on active work, and one named decision-maker on the client side. That combination sounds basic, but it solves a surprising amount of chaos.
- Keep the backlog ordered by value, risk, and deadline, not by who shouted loudest.
- Limit work in progress to what the team can genuinely finish. If more than 5 to 7 items are active at once, context switching usually starts to slow everyone down.
- Reserve 15% to 20% of capacity for urgent work in client-facing teams. If you run at 100% planned utilisation, even small changes will knock the system off balance.
- Use acceptance criteria so nobody argues about what “done” means after the work is finished. Acceptance criteria are the conditions that must be met before a piece of work is accepted.
- Treat client review as part of delivery, not as an optional extra at the end.
Definition of done matters just as much. For a policy document or public-facing digital service, it may include copy approval, accessibility checks, legal review, and publishing sign-off. Without that clarity, teams only think they are close to finishing. In practice, they are still waiting.
That is why cadence is more than scheduling. It is the operating system for decision-making, and it only works if the team uses it consistently. Once the rhythm is in place, the next question is whether the numbers on the dashboard are telling the truth.
The metrics that tell you whether it is working
Agency teams often track the wrong things. Velocity can help inside one team, but across agencies it is easy to game and hard to compare. I would rather see a small set of flow metrics that tell me whether work is moving cleanly through the system or getting trapped in approvals and rework.
| Metric | What it tells you | What to watch for |
|---|---|---|
| Cycle time | How long work takes from start to finish | If it falls, flow is improving; if it rises, something is slowing delivery |
| Plan reliability | How much of the planned work actually gets completed | If it stays below about 80%, intake or estimation is unstable |
| Work in progress | How many items are active at the same time | High WIP usually means too much context switching and too little finishing |
| Approval delay | How long work waits for client or governance sign-off | Often the real bottleneck, especially in public-sector environments |
| Rework rate | How often items are reopened or heavily changed after review | High rework usually means the brief or feedback loop is weak |
I also pay attention to utilisation, but I do not worship it. A team that is booked above about 85% to 90% of its capacity has very little slack for reviews, interruptions, or urgent client changes. The result is usually not efficiency; it is a backlog that looks manageable until it suddenly is not. Good metrics should help a team make decisions, not turn it into a machine that is always busy and rarely effective.
The mistakes that quietly undo the benefits
What I see most often is not a failure of agile itself, but a failure to change the management habits around it. The team gets a board, a few ceremonies, and a lot of new language, but the underlying behaviour stays the same.
- Using agile as theatre - stand-ups and boards without real decision rights only create the appearance of control.
- Changing priorities mid-sprint without rules - every interruption feels urgent until the team cannot finish anything properly.
- Optimising for individual utilisation - keeping everyone at maximum booking usually harms the flow of the whole team.
- Separating delivery from client feedback - when feedback arrives late, rework becomes expensive and morale drops.
- Applying the same process to every job - a support request, a policy document, and a large programme do not need identical treatment.
- Ignoring the account or stakeholder layer - if the people who negotiate scope and approvals are not part of the system, the system will keep breaking at the edges.
The fix is rarely more ceremony. It is clearer prioritisation, better escalation rules, and a management team willing to protect focus. Once those habits are in place, the benefits become much easier to see.
What better agency agility looks like after the first few cycles
After a few cycles, the signs are usually obvious: fewer hidden blockers, cleaner priority decisions, shorter approval loops, and less time spent reconciling status across email, chat, and meetings. The board stops being decoration and becomes the place where trade-offs are made.
For UK public-sector agencies, that is the real test. Agile should make delivery clearer and more accountable, not looser. If the method helps the team protect focus, surface risk early, and keep stakeholders involved without turning every change into a crisis, then it is doing its job.
