Someone in your organisation has decided you are going agile. A consultant has been in. There have been workshops. There is a new board on the wall and someone is now called a Product Owner.
And yet nothing feels different.
The sprints happen. The stand-ups happen. The Retrospectives happen. But the work still takes as long as it did. The approvals still back up. The deliverables still land late.
Here is the question nobody asked before all of this started: is Scrum actually the right framework for your team?
It might not be. And knowing the difference will save you months of frustration.
The One Question That Matters Most
Scrum was built for complex work. Work where you cannot know the answer in advance. Work where you learn by doing, and what you learn changes what you do next.
It was not built for complicated work. Complicated work has a right answer. Experts know the process. They follow it reliably. Think statutory reporting, contract administration, audit cycles, or compliance reviews. That work is hard. It requires skill. But it is not complex in the sense that Scrum was designed to handle.
If your team's work is complicated, Scrum will feel like friction. You are applying an empirical framework to a domain where best practice already exists. The sprints will not help you learn anything new. They will just add ceremony to work that was already well understood.
The framework you almost certainly need for that kind of work is Kanban. Not because Kanban is easier, but because it is designed for flow. It manages demand and capacity across a continuous stream of varied requests. It makes your constraints visible. It does not pretend you are building something new when you are actually executing something known.
But Kanban is not an escape hatch. A Kanban board without WIP limits, flow metrics, and a clear sense of what value looks like is just a to-do list with sticky notes. Choosing Kanban means committing to flow discipline, not avoiding accountability.
The Trap Most Organisations Fall Into
Let us say your work really is complex. You are building something new. You are exploring, experimenting, and learning. Scrum could be exactly right.
But then the organisation makes a structural mistake that kills it before it starts.
They take each department and turn it into a Scrum team. The marketing team runs sprints. The finance team runs sprints. The HR team runs sprints. Each one has a backlog, a Scrum Master, and a Product Owner.
And almost none of them can deliver a usable increment on their own.
Here is why that matters. The Scrum Guide is clear on this point: a Scrum team must have all the skills needed to create value each sprint. If a marketing team needs design approval from another team, budget sign-off from finance, and a product decision from someone in a different department, it cannot deliver independently. It has sprints. It does not have Scrum.
The work still stops at the same bottlenecks. The dependencies are still there. They are just harder to see because they are buried inside sprint planning conversations.
What a Cross-Functional Team Actually Looks Like
The right question is not "how do we run Scrum in marketing?" or "how do we run Scrum in HR?"
The right question is: what is the product we are trying to deliver, and who needs to be in the team to deliver it?
Take a new customer service. To deliver that, you probably need someone with product ownership skills, someone from operations, a subject matter expert, a person who understands the customer, and yes, someone who can think about cost and someone who can shape the communications. Marketing, finance, and HR do not disappear. They become competencies inside a team that can actually deliver value end to end.
That team can produce a real increment every sprint. A working slice of the service in the hands of real customers. Something someone can use today, even if the full service is months away.
That is the model. Not marketing running its own sprints in isolation. Not finance producing quarterly outputs and calling them increments. A cross-functional team with a shared Product Goal, working together toward something a real person can use.
What "Usable" Actually Means
The most common reason non-software teams reject Scrum is this: "We cannot finalise a policy in two weeks." Or: "We cannot launch a full campaign in a sprint."
They are right. They do not have to.
A sprint does not need to deliver the finished product. It needs to deliver a usable slice of it. The test is not "is it finished?" The test is "can someone act on this today?"
For a policy team, a usable sprint increment might be a synthesis of ten stakeholder interviews, ready to shape the next draft. That is not the policy. But it is something real. A decision-maker can read it, challenge it, and act on it. The next sprint builds on what was learned.
For a marketing team, it might be a single tested landing page with real visitor data coming in. Not the campaign. A slice of it. Evidence about what works, before the full spend is committed.
For a learning and development team, it might be one module completed by five pilot learners, rated and reviewed. Not the programme. One piece of it, validated by real people.
This is what agile practitioners call slicing. It is the skill of breaking large outcomes into small, genuinely useful pieces. It is also where most non-software teams need the most coaching.
One warning about slicing, because it has a trap inside it.
A team that spends Sprint 1 on research, Sprint 2 on drafting, and Sprint 3 waiting for approvals has not sliced anything. They have run a waterfall project inside a sprint cadence. Each sprint delivers a completed phase, not a usable increment. The research sits unused until the draft is done. The draft sits unused until approval arrives. Nothing is in the hands of a real person until the end of the whole sequence.
The test is not "did we complete work this sprint?" It is "could someone use what we produced this sprint, right now, without waiting for the next sprint?" If the answer is no, the team has not sliced. They have relabelled their phases as sprints. A good coach will spot this pattern quickly. It is one of the most common failure modes for non-software teams adopting agile.
How to Tell if You Have the Right Setup
Before you write a single Sprint Goal or agree a Definition of Done, ask your team three questions.
First: is our work complex? Do we genuinely not know the answer upfront, and do we learn something meaningful from each sprint that changes what we do next?
Second: can we deliver something usable on our own, every sprint, without waiting for sign-off or input from outside the team?
Third: can we describe what a usable increment looks like for us? Not a draft. Not a deck for review. Something a real person can use or act on right now.
If the answer to all three is yes, Scrum is likely a good fit and the practices around Definition of Done and Sprint Goals will accelerate your team considerably.
If the answer to any of them is no, the problem is not your Scrum practice. It is the team design or the work type. In most cases, fixing that first is the right advice.
Some coaches argue the opposite: start running sprints, fail visibly, and use the failure to expose the dysfunction. There is something to this. Scrum is designed to be a mirror. It surfaces organisational problems that were always there but easy to ignore. Running a sprint and failing to deliver because an approval gate took three weeks is a powerful conversation starter at a Retrospective.
But this approach depends on one thing above all: psychological safety. If the team and the organisation can look at failure honestly, name what went wrong, and act on it without blame, then starting before everything is in place can work. The dysfunction becomes visible and fixable.
If psychological safety is low, the same failure produces a different outcome. The framework gets blamed. The team disengages. Leadership concludes that agile does not work here. The real problem, a legacy approval structure or a misaligned team design, goes unaddressed and the organisation becomes more resistant to change, not less.
Know your environment before you decide which approach to take.
A Note on the "Agile Transformation" That Is Not
One more pattern worth naming.
Many organisations adopt Scrum events: the planning sessions, the daily stand-ups, the reviews, the retrospectives. They use the language. They have the boards. But underneath the new vocabulary, the mindset is unchanged. Work is still handed over in batches. Decisions still require sign-off from above. The Product Owner is a project manager with a new job title.
This is Scrum in name only. It produces all the overhead of the framework with none of the benefits. Teams become cynical. The framework gets blamed. The real problem, a legacy command-and-control structure wearing agile clothing, goes unaddressed.
No framework rescues unclear purpose. If you cannot name your product, your customer, and what a usable increment looks like, that conversation needs to happen before anything else.
What to Do Next
If this has raised more questions than it has answered, that is probably a good sign. The right questions are the ones about team design, about what value looks like in your context, and about whether the work you do is genuinely complex or expertly complicated.
We have produced a free cheatsheet to go with this post: a one-page diagnostic guide you can use with your team to work through the questions above.
Download fileAlun Davies-Baker is the founder of Altogether Agile, a London-based agile training and consultancy practice. He works across pharmaceuticals, finance, education, and the public sector, helping teams find the approach that fits the work they actually do.