Agile, Scrum and Kanban for teams that do not write software

Agile began as a way to build software, but most of its ideas are about how a small group handles work that keeps changing. Marketing teams, operations teams, HR, finance and consulting projects all have that problem. A campaign brief shifts after the first results come in. A hiring plan changes when a budget is cut. A client changes the question halfway through a project.

This guide covers what the Agile Manifesto says, how Scrum and Kanban turn it into a working routine, how to adapt both when your output is a campaign or a report rather than code, and when a plain sequential plan is still the better choice.

What the Agile Manifesto says

The Manifesto for Agile Software Development was published in 2001 by seventeen software practitioners, among them Kent Beck, Martin Fowler, Ken Schwaber and Jeff Sutherland. It rests on four value statements:

• “Individuals and interactions over processes and tools”
• “Working software over comprehensive documentation”
• “Customer collaboration over contract negotiation”
• “Responding to change over following a plan”

The authors are careful to say the items on the right still have value. They simply value the items on the left more. Twelve principles sit behind the values, and several transfer directly to non-software work. Deliver “frequently, from a couple of weeks to a couple of months”, with a preference for the shorter timescale. Have the people who want the work and the people doing it work together daily. Treat simplicity, “the art of maximizing the amount of work not done”, as essential. At regular intervals, reflect on how to become more effective and adjust.

To read the manifesto as a non-software team, replace “working software” with whatever you ship: a live landing page, an approved policy, a finished month-end pack. Progress means finished, usable output. A detailed plan for a campaign that has not launched tells you very little.

Scrum in brief

Scrum is defined by the Scrum Guide, written by Ken Schwaber and Jeff Sutherland and last revised in November 2020. It is deliberately short and leaves most practices to the team. Its core is a small team, typically 10 or fewer people, with three accountabilities:

• Product Owner: decides what matters most and keeps the Product Backlog (the ordered list of work) in order.
• Scrum Master: helps the team use Scrum well and removes obstacles to its progress.
• Developers: the people who do the work in each Sprint. In a non-software team that means writers, designers, analysts or recruiters.

Work runs in Sprints, fixed-length cycles of one month or less. The Guide sets maximum lengths for the other events based on a one-month Sprint, and says they are usually shorter for shorter Sprints.

There are three artefacts, each with a commitment attached. The Product Backlog serves a Product Goal. The Sprint Backlog serves a single Sprint Goal. The Increment, the usable output, must meet a Definition of Done. Underneath all of it are three pillars: transparency, inspection and adaptation.

Kanban in brief

Kanban has older roots. Atlassian’s Kanban guide notes that it originated at Toyota, modelled on supermarkets restocking shelves based on what customers take. The current Kanban Guide (version 2025.5, May 2025) defines it as “a strategy for optimizing the flow of value through a process” and describes three practices:

1. Define and visualise the workflow, usually on a board with a column for each state.
2. Actively manage the items in the workflow, which includes controlling work in progress (WIP) and unblocking stuck items.
3. Improve the workflow continuously, rather than waiting for a scheduled review.

The Guide names four flow measures. WIP is the number of items started but not finished. Throughput is the number finished per unit of time. Work item age is how long an unfinished item has been in progress. Cycle time is how long a finished item took from start to finish. Kanban has no Sprints and no prescribed roles, which makes it easier to lay over an existing team.

Adapting both for teams that do not write software

The frameworks assume very little about the type of work. The adjustments are mostly about language and about defining what “done” means.

• Name the unit of work. A published article, a signed-off supplier, a closed vacancy. Each card on the board should be one of these, small enough to finish in days rather than weeks.
• Write a Definition of Done. For a blog post it might be: edited, legally checked, images licensed, scheduled. Without it, “done” drifts.
• Give priority to one person. The Product Owner role exists so that a single person settles what comes next. In a marketing team this is usually the marketing lead, not a committee.
• Match the cycle to feedback. If stakeholders can only review monthly, two-week Sprints add ceremony without learning.
• Pick Kanban for interrupt-driven work. Support queues, legal requests, recruitment and finance operations rarely fit a fixed plan for two weeks.

An example (illustration only)

A four-person marketing team at a small skincare brand handles a steady stream of requests: product pages, emails, social posts and retailer assets. Priorities change weekly, so they use Kanban with these columns and WIP limits:

When Review is full, writers stop drafting and help clear approvals. Each Friday they check work item age and discuss anything that has sat in one column for more than a week. Once a month they hold a short retrospective. For a product launch with a fixed date, the same team switches to two Sprints with one goal: launch page, email sequence and retailer pack live on launch day. After the launch they return to the board.

When waterfall is still the right choice

Waterfall runs stages in sequence and finishes each before starting the next. The Scottish Government’s service manual says it can suit work where requirements are clearly defined, the environment is stable, and deadlines and resource constraints are already known. It also says its project office does not recommend one approach over the other, and that a hybrid often fits.

In practice, a sequential plan suits an office move with a fixed lease end date, a regulatory filing with set content, or an event booked at a venue. The scope is known, changing it late is expensive, and there is little to learn from showing half the work early. Many teams combine the two: a sequential plan for the fixed milestones, with Kanban or short Sprints for the uncertain parts inside them.

Common mistakes

• Stand-ups as status reports. The Daily Scrum is for the people doing the work to adjust their plan, not for a manager to collect updates.
• A board with no WIP limits. Without limits a Kanban board is a to-do list, and everything stays half-finished.
• A Sprint Goal that is a task list. “Write five posts” is a list. “Get the new range page live and indexed” gives the team room to decide how.
• Skipping the retrospective. It is the event that makes the team better over time, and it is the first to be cancelled when work is busy.
• Relabelling a fixed plan as agile. Adding fortnightly check-ins to a plan nobody is allowed to change keeps the meetings and loses the benefit.

How to start this week

1. List everything your team is working on, one item per card, and count it. That count is your current WIP.
2. Draw your real workflow as four to six columns and place every card in its column.
3. Set a WIP limit for the busiest column at slightly below today’s count.
4. Agree who orders the Ready column and when.
5. Book a 30-minute retrospective for two weeks from now, and decide then whether you need Sprints or the board is enough.