Agile Beyond Software: Boards for Marketing, HR and Ops

A marketing manager sits through her first "agile transformation" workshop and hears that her campaign work will now involve sprints, story points, a scrum master, and something called a burndown. She nods politely and goes back to running campaigns out of a spreadsheet — correctly sensing that most of what she just heard was software ceremony, not help.

Here is what that workshop should have said: agile, stripped of its software costume, is four habits. Make all work visible on a shared board. Work in priority order from one queue. Finish things before starting things. Meet briefly and regularly to inspect and adjust. Those habits transfer to any team that has more requests than capacity — which is every marketing, HR, and ops team ever assembled. The jargon does not transfer, and forcing it is why most non-software agile rollouts die of eye-rolling.

This guide skips the transformation theater and gives you the concrete version: exactly what board to build for a marketing team, an HR team, and an ops team — columns, card fields, cadences, rituals, and the failure modes specific to each — plus a translation table for the vocabulary and honest notes on which agile practices to leave behind with the software teams.

The translation table

Before the board setups, fix the language. Every term below has a software-flavored version that will alienate your team and a plain version that won't:

Software term	Plain version	What it actually means
Sprint	Cycle, or just "the two weeks"	A fixed period with a committed set of work
Backlog	The queue	Everything requested but not started, in priority order
Standup	Daily check-in (10 min or async)	Brief sync on progress, plans, and stuck items
Retrospective	Monthly review / "what's working"	A recurring look at the process, not the work
Story points	(Usually: skip)	Relative effort sizing — most non-dev teams do better with T-shirt sizes or nothing
Velocity	Throughput	How many items the team finishes per cycle
Product owner	Queue owner	The one person who orders the queue
WIP limit	"Max in progress"	A cap on simultaneous active work
Definition of done	The done checklist	The checks every item passes before it's finished

Use the right-hand column exclusively. This is not dumbing down — "queue owner" is a clearer term than "product owner" for a team that has no product. The vocabulary swap alone removes half the resistance.

Two software practices deserve explicit warning labels before you export them:

• Story points and velocity charts: mostly skip. Estimation ceremony earns its cost when work items are large, novel, and interdependent. A blog post, an offer letter, and a vendor renewal are none of those. Count items finished per cycle (throughput) and track it for planning; skip the poker. If sizing genuinely varies wildly, use S/M/L and move on.
• The scrum master role: skip. A dedicated process facilitator makes sense at software scale and looks like bureaucracy at marketing scale. The team lead facilitates; the ritual overhead should be under an hour a week total.

The universal skeleton

All three setups below share a spine. Build this first, then apply the team-specific tuning:

1. One board per team, containing all the team's work — projects, requests, recurring tasks, favors. The board is only trustworthy if it is complete; the moment "real work" lives somewhere else, the board becomes decoration. Rule of thumb: anything over 30 minutes of work gets a card.
2. An intake column that is not the queue. New requests land in Intake, and a human (the queue owner) triages them — accept, decline, or clarify — before they enter the ranked queue. This one column is where most of the value lives, because it converts ambient requests ("hey, can you quickly...") into visible, prioritizable, declinable work.
3. A "max in progress" cap of roughly 1.5 items per person, enforced from day one. Non-software teams are, if anything, more WIP-poisoned than dev teams, because their requests arrive from every direction with social pressure attached. The full argument and the math are in the WIP limits guide; the short version is that finishing beats starting, measurably.
4. A done checklist per work type. "Done" for a campaign includes UTM links checked and results dashboard created; "done" for onboarding includes equipment confirmed and 30-day check scheduled. Checklists on card templates make quality a property of the system instead of a property of whoever was careful that day.
5. Two rituals, total: a 10-minute check-in (daily or thrice-weekly, sync or async — walk the board oldest-first, discuss only stuck items) and a monthly 45-minute review of the process ("what should we start/stop/continue about how we work?" — the retrospective guide has formats when the plain version goes stale).

Now the specifics, because a campaign, a hire, and a vendor renewal do not flow the same way.

The marketing board

Marketing work is deadline-driven, multi-stage, and heavy on review loops. It fits a Kanban-style board with stage columns better than almost any other business function.

Columns:

Intake → Queued → Briefing → Producing → Review → Scheduled → Live → Wrap-up → Done

Notes on the non-obvious ones: Briefing exists because the most common marketing failure is production starting from a vague ask — a card cannot leave Briefing without an owner-approved brief (audience, message, channel, deadline, success metric — five lines, not five pages). Scheduled separates "approved" from "published," which matters because approved-but-unpublished work needs zero attention and pollutes the Review column otherwise. Wrap-up forces the results check — the column where "did the campaign work?" actually gets answered — and it is the column every marketing team skips until it is on the board staring at them.

Card fields: channel (email/social/blog/paid/event), campaign it belongs to, due date, requesting stakeholder, done checklist for the type. In Openbook you would build this in a Kanban room with card templates per content type — or, for teams whose work is more calendar-shaped than flow-shaped, a Table Board using the content-calendar template with status, people, date, and tags columns; both live happily in the same space, and the Marketing space template provisions the pair in one click.

Cadence: a weekly 30-minute cycle planning ("what ships in the next two weeks, and does it fit our capacity of ~N items?") beats two-week locked sprints for most marketing teams, because inbound requests ("the CEO is speaking Thursday, we need a post") arrive faster than a locked sprint tolerates. Lock only the big rocks — launches, events — and let the small items flow around them with the WIP cap as the regulator.

Marketing-specific failure modes: review loops that bounce forever (fix: max two review rounds on the checklist, then a live 15-minute markup session); stakeholder requests bypassing Intake via DM (fix: the polite redirect, verbatim — "Adding this to our intake so it gets a real slot — you'll see its status here"); and the board splitting into per-channel silos that hide the tradeoff between the blog and the webinar (fix: one board, channel as a field, not as a board).

The HR board

HR work differs from marketing in two structural ways: much of it is confidential, and much of it is process-instance work — the same pipeline run many times (candidates, new hires, reviews) rather than unique projects. That changes the setup.

Split the work into three surfaces, not one:

1. The team board (visible to HR + leadership): projects and initiatives — policy rollout, comp review, engagement survey, benefits renewal. Columns: Intake → Queued → In progress → Waiting on others → Review → Done. The Waiting on others column deserves emphasis: HR work is uniquely blocked-on-other-people (legal review, exec signoff, employee responses), and making the wait visible converts "HR is slow" into "this has been waiting on legal for 9 days," which is a different and more fixable conversation.
2. Pipeline boards for repeating processes, one per process: a recruiting board where each card is a candidate (Applied → Screen → Interviews → Debrief → Offer → Closed), an onboarding board where each card is a new hire moving through a 30-60-90 flow with a checklist template per role. Pipelines and projects flow at different speeds with different privacy needs; merging them onto one board makes both unreadable.
3. Confidential work stays off shared boards entirely — ER cases, performance situations, comp details. Represent it, if at all, as a capacity placeholder ("2 confidential cases, ~30% of Dana") so planning stays honest without leaking anything. A board that quietly omits a third of the team's real load will produce overcommitment every single cycle. Per-room visibility controls are the mechanism here — a private case-tracking board visible only to the HR team, alongside the shared boards, in the same workspace.

Cadence: HR suits a weekly rhythm more than a daily one — a Monday 15-minute board walk on the team board, pipelines reviewed in their own existing rituals (debriefs, onboarding check-ins), and the monthly process review. An async Friday check-in ("what moved, what's stuck, what needs escalation next week") replaces the daily standup entirely; async check-in tooling with mood tracking doubles nicely here since HR teams tend to actually act on it.

HR-specific failure modes: the checklist-less onboarding where every new hire's first week depends on someone's memory (fix: card templates — the checklist is the process documentation); recurring annual work like open enrollment rediscovered from scratch each year (fix below, under ops, applies equally); and treating the board as a surveillance risk (fix: the board tracks work items, never people-metrics — say so explicitly at rollout, and mean it).

The ops board

Operations teams — office ops, IT ops, finance ops, revops — carry the most mixed workload of the three: a request queue with implicit SLAs, plus recurring cadenced work (month-end close, renewals, audits), plus improvement projects that perpetually lose to the other two. The board must hold all three or the projects die silently.

Columns:

Intake → Triaged (ranked) → In progress → Waiting → Done plus two horizontal swimlanes cutting across: Urgent (cap: 2) and Recurring

The swimlane structure is the load-bearing choice. Urgent with a hard cap of two does for ops what an expedite lane does for a dev team: it acknowledges that genuine fires exist while making "everything is urgent" structurally impossible — when a third urgent item arrives, the requester is shown the lane and asked which of the two current fires theirs outranks. That conversation, repeated for a month, retrains an entire company's definition of urgent.

Recurring holds the cadenced work as auto-recreated template cards — month-end close spawns on the 25th with its 14-step checklist, the quarterly access review spawns with its runbook linked. Two design rules: recurring cards carry checklists (the checklist is the SOP, versioned by editing the template), and recurring work is counted in capacity. An ops team that plans as if close week were free capacity will miss every project commitment in months that contain a close week, which is all of them. If more than half your board is recurring, your real topic is operational cadence design, which is deep enough to have its own guide: Managing Recurring Work: Ops Boards Beyond Projects.

Protecting improvement work — the automation, the vendor consolidation, the runbook writing — takes an explicit allocation, because queues always eat projects: reserve roughly 20% of capacity per cycle for improvement items, treat that reservation like a meeting with the CFO, and track it in the monthly review ("did improvement work actually get its 20% this month, or did the queue eat it?"). Teams that skip this stay busy forever and better never.

Cadence: ops benefits from the daily 10-minute check-in more than marketing or HR — queue work goes stale by the hour, and the daily walk of the Waiting and Urgent lanes is where escalations get unstuck. Keep the monthly process review sacred and give it one permanent agenda item: "what showed up in the queue three times this month that we should automate or document out of existence?"

Ops-specific failure modes: SLAs that exist in heads but not on cards (fix: a due/needed-by field set at triage, and sort the queue by it); the Waiting column as a graveyard (fix: every Waiting card names who it waits on and when it will be chased); and heroics culture, where the person who absorbs untracked favors fastest wins social credit while the board lies (fix: leadership asks "is it on the board?" before saying thank you).

The objections you will hear, with answers

Every non-software rollout meets the same four objections. Have the answers ready before the kickoff, because improvising them live goes badly.

"My work is too creative/unpredictable for a board." The board does not standardize the work; it standardizes the visibility of the work. A brand campaign and a password reset both benefit from being visible, ranked, and finished before the next thing starts. Creative work arguably benefits more — it is the work most likely to be interrupted into mediocrity by untracked requests. The board is what protects the creative time, not what threatens it.

"We already have a spreadsheet." A spreadsheet is a board without flow. It shows what exists but not what stage anything is in, who is overloaded, or what is stuck waiting on whom — the three questions that actually run a week. Offer a trade rather than a fight: "Two weeks on the board. If it tells us less than the spreadsheet did, we go back." Nobody has ever gone back.

"This feels like surveillance." Take this one seriously, because it is sometimes true — boards have been abused as activity monitors. The counter is a public commitment with teeth: the board tracks work items, never person-level productivity; nobody's card count appears in any review; the metrics the team keeps (throughput, cycle time) belong to the team and are used by the team to argue for capacity, not against individuals. Then honor it. One violation — one "I noticed Jordan only closed three cards" in a 1:1 — and the board dies, correctly.

"Leadership will never respect the intake process." True by default, false by design. Leadership respects intake when intake gives them something better than the DM did: a visible slot, a realistic date, and a queue they can reorder. The line that wins the meeting: "You can have anything moved to the top — the board just shows you what moves down when you do." Executives do not actually want to bypass prioritization; they want to control it, and the ranked queue is the first tool that has ever genuinely offered them that.

What week three actually looks like

A composite from real rollouts, so you can recognize health when you see it. Monday, the marketing lead walks the board in nine minutes: two cards in Review are older than everything else, so the team agrees to a markup session at 2 p.m. instead of another async round-trip. A sales director's Tuesday DM — "quick one-pager for a prospect?" — gets the polite redirect into Intake, where it is triaged Wednesday as small-but-real and queued fourth. Thursday, the WIP cap binds: the designer finishing the webinar assets has nothing to pull, so she picks up the copy review that was gating the oldest card rather than starting the fifth-ranked item. Friday's tally: seven items done against last month's average of four, and — the part people mention later — nobody worked the weekend. Nothing in that week required a certification, a consultant, or a single piece of software vocabulary.

Rolling it out without an eye-roll

The transformation-workshop approach fails because it front-loads vocabulary and back-loads value. Invert it. A rollout that works, over six weeks:

Weeks 1–2: Just the board. Build the team's board with the columns above, migrate everything from the spreadsheets and inboxes, and run only the intake rule ("new requests land in Intake") and the 30-minute weekly walk. No caps, no new vocabulary, no rituals beyond that. Let the team feel the first effect: everyone can finally see the workload, and "we have 61 open items for 5 people" becomes a fact leadership can be shown instead of a feeling.

Weeks 3–4: The cap and the checklists. Introduce max-in-progress at current-WIP-minus-20% and the done checklists for the two most common work types. This is when the speedup becomes noticeable — items start finishing in days instead of weeks — and the team's skepticism usually flips somewhere in here, because the mechanism is felt rather than argued.

Weeks 5–6: The rituals and the numbers. Add the check-in cadence and hold the first monthly process review. Start counting throughput (items finished per week) and cycle time (started → done), and put both on a simple dashboard the team owns — two numbers, not twelve. Now the team can run its own experiments: "we tightened the cap to 7 — cycle time dropped two days."

Then stop adding process. The strongest version of agile-beyond-software is the smallest one that produces flow: a complete board, a triaged queue, a cap, two rituals, two numbers. Anything further — estimation ceremonies, formal sprints, roles with capital letters — should be pulled in only when a felt problem demands it, and most non-software teams never need to. (If your team is curious about the deeper flow toolkit behind these choices — pull systems, flow metrics, board anti-patterns — the complete Kanban guide is written for exactly that next step.)

One honest note on tooling: none of the above requires particular software — a wall of stickies runs this system fine until the team is remote, the requests arrive digitally, and the recurring cards need to spawn themselves. If you are assembling the digital version, Openbook covers all three setups in one space — Kanban rooms for flow-shaped work, Table Boards with ~40 templates for pipeline- and calendar-shaped work, per-room visibility for the confidential HR surfaces, and one-click Marketing, HR, and Ops space templates that provision sensible starting rooms in about a minute. Start free at openbook.work.

The workshop pitch to give your own team is three sentences, no jargon required: everything we're asked to do goes on one board; we finish things before we start things; once a month we spend 45 minutes making the system better. That is agile — the part of it that was always going to outlive the software costume.