Complex Is Not Complicated: When Scrum Helps

Two teams in the same building, same month. The first is moving payroll onto a new set of tax tables: a known procedure, published rules, and nobody in the company disagrees about what correct looks like. The second is trying to cut repeat customer contacts by a third, and three senior people privately believe three different things about what is causing them.

Somebody is about to tell both teams to run Scrum. It will help exactly one of them.

That is not an opinion about Scrum. It is a statement about the work. Scrum was built for a specific kind of problem, and the reason so many adoptions feel like theater is that nobody checked whether the work in front of them was that kind of problem. I have spent thirty years in technology leadership, a good stretch of it as a CTO, and I have watched capable teams get handed a framework as an answer to a question nobody asked out loud.

The question is this: is this work complicated, or is it complex? Most people use those two words as if they were synonyms for hard. They are not synonyms, the difference is not difficulty, and getting it wrong is expensive in a way that stays hidden until the end.

Complicated work is hard. Complex work is unknowable.

A complicated problem is hard but knowable. With enough expertise and enough analysis, someone can work out the answer before the work starts. Rebuilding a car transmission is complicated. It takes years of training, it takes a manual, and it can absolutely be planned. Two good mechanics would do it roughly the same way and finish within an hour of each other.

A complex problem is one where the answer cannot be worked out in advance at any price, because it depends on things that have not happened yet. Take the same car with an intermittent electrical fault that appears only on cold mornings, sometimes. No manual has a procedure for that. No honest mechanic quotes you a fixed price. The only approach that works is to form a theory, test it, watch what actually happens, and revise.

Notice what complex work demands: short cycles, real evidence, and a willingness to be wrong in public. That list is not a philosophy. It is a description of Scrum's mechanics, and it is why the framework exists.

Here is the consequence, and it is sharp. Run a routine problem with heavy adaptive ceremony and you have wasted everyone's time inspecting a process that was never going to surprise you. Run a complex problem with a detailed predictive plan and something worse happens: the plan produces confidence that is not backed by knowledge, everyone commits to a date built on guesses, and the failure becomes visible only at the end, when it costs the most.

Incomplete requirements. Changing requirements. Unrealistic expectations. Those are the classic names given to failed projects, and they are usually filed as project management failures. They are not. They are the signature of complex work being managed as though it were complicated.

The Risk Universe sorts work by what you actually know

There is a model for this, and it is old enough and general enough that it was not invented to sell anybody a framework. It comes from Ralph Stacey's work on organizational dynamics, and it reached the Scrum world through Ken Schwaber and Mike Beedle. In the course I teach it as the Risk Universe, and it has two axes and four zones.

The vertical axis runs from certainty to uncertainty and describes the technology: the method, the tools, the technique. Do we know how to do this? The horizontal axis runs from agreement to disagreement and describes the requirements: the what and the why. Do the people who matter agree on what we are supposed to produce? Where the two answers cross, you land in one of four domains.

Simple. We know how, and we agree on what. Baking a loaf of banana bread from a recipe you have made forty times. Standardize it, document it, automate what you can, check it periodically. Adding ceremony here is pure cost.

Complicated. Real uncertainty in the technology or real disagreement about requirements, but not both and not much. Hard, expert work with a knowable answer. Plan it, bring in specialists, and a predictive approach earns its keep.

Complex. Meaningful uncertainty about how overlaps with meaningful disagreement about what. You cannot reason your way to the right answer from your desk, because the information you need does not exist yet. This is Scrum's home, and it is the only one of the four domains where it is.

Anarchy. High uncertainty about the technology and open, unresolved disagreement about requirements at the same time. A department in the middle of a surprise reorganization where two executives are publicly contradicting each other about the goal while the tooling is being replaced. The honest answer here is that no framework saves you.

In ordinary work: a payroll team running the monthly cycle it has run for nine years is Simple. A finance team implementing a new revenue recognition rule is Complicated — genuinely difficult, and a specialist can find the right answer. A customer service team trying to cut repeat contacts with no agreement on whether the cause is the product, the policy, or the script is Complex.

Place one real piece of work, in ten minutes

Do this with a specific item, never with a whole department. Departments do not have a domain. Pieces of work do.

Take one thing — a feature, a campaign, a policy change, a part — and ask two questions in order.

One, about technology. How confident are we that we know how to build this? Have we, or anyone we could call, done this exact thing before and would they do it the same way again?

Two, about requirements. How confident are we that the people who matter agree on what this should be and why? If you asked the three most senior stakeholders separately, would you get the same answer?

Be especially suspicious of false agreement, because it is the most common placement error by a wide margin. A room full of people nodding at a vague sentence is not agreement. It is a deferred argument. The test for real agreement is specific: could two of those people independently write down what done looks like and produce roughly the same description? If not, mark it as disagreement and push the item to the right.

Then match the approach to the domain rather than to your preference. Simple: write the procedure. Complicated: plan it with experts. Complex: work in short cycles, produce something real, inspect what actually happened, adapt. Anarchy: do not start a Sprint. Your first job is to get out of Anarchy, either by reducing the disagreement — get a decision from someone with the authority to make it — or by reducing the technical uncertainty with one small experiment. Once the work drops into Complex, an empirical approach can take over.

One more piece of technique that almost nobody uses. Items move. Work that starts Complex often becomes Complicated after three cycles, once you know the shape of it, and Simple once you have done it enough times to write the procedure down. That movement is a sign of health, and it is worth naming out loud when it happens, because a team still running full ceremony on work that has quietly become Simple is paying for insurance it no longer needs.

Scrum reveals problems. It does not fix them.

Here is the caveat I would want if I were reading this, and it is the part that gets left out of most adoption conversations.

Placing your work in the Complex domain and adopting Scrum does not solve anything by itself. What short cycles do is shorten the distance between a problem existing and a problem being visible. That is genuinely valuable, and it is also uncomfortable, because a framework that surfaces a dependency your organization has been quietly absorbing for two years has not created a new problem. It has taken the lid off an old one.

Teams that expect relief and get a clear list of impediments instead often conclude that Scrum did not work here. What actually happened is that Scrum worked exactly as designed and the organization did not want the answer.

There is also an honest limit on the other side. If the true blocker on your team is that reporting a real number can cost someone their job, then your first impediment is not a missing process, and starting Scrum without saying that out loud only adds events to a place where nobody can afford to tell the truth.

Sort the work first. The framework question comes second, and it is a much easier question once the first one has an answer.

Key takeaways

• Complicated work is hard but knowable in advance; complex work is not knowable at any price, because the information you need does not exist yet.
• Scrum is built for the Complex domain. In Simple work it is pure cost, and in Anarchy no framework survives.
• Place one piece of work at a time by answering two questions: do we know how, and do the people who matter agree on what.
• A room nodding at a vague goal is a deferred argument, not agreement — test it by asking two stakeholders to write down what done looks like.
• Scrum shortens the distance between a problem existing and a problem being visible. It does not fix the problem for you.

Frequently asked questions

What is the difference between complicated and complex work?

Complicated work is hard but knowable: with enough expertise and analysis, someone can determine the right answer before the work starts, like rebuilding a car transmission from a manual. Complex work cannot be worked out in advance at any price, because it depends on things that have not happened yet, such as how real customers react. The dividing line is knowability, not difficulty.

When should a team use Scrum, and when should it not?

Use Scrum for complex work: meaningful uncertainty about how to do it combined with real disagreement about what is wanted. For simple, routine work, write and automate the procedure instead, because the ceremony buys you nothing. For hard but knowable work, plan it with specialists. In outright chaos, resolve the disagreement or run one small experiment before starting any Sprint.

What is the Risk Universe in Scrum?

The Risk Universe is a two-axis model that sorts work into four domains: Simple, Complicated, Complex, and Anarchy. The vertical axis measures certainty about the technology — do we know how to do this? The horizontal axis measures agreement about requirements — do stakeholders agree on what is wanted? It comes from Ralph Stacey's work on organizational dynamics and entered Scrum through Ken Schwaber and Mike Beedle.

How can I tell mid-project whether my work is complex?

Count the genuine surprises per week, meaning discoveries that changed a decision. Complicated work produces a burst of surprises during planning and very few afterwards. Complex work keeps producing them at a steady rate right through delivery. If your team is still finding something that changes the plan in week six of an eight-week effort, the work has already answered the question.

Can one team have both simple and complex work?

Yes, and most do. Sort at the level of the item rather than the team. Routine items ride along inside a Sprint at almost no cost; you simply do not need to re-examine them every two weeks. What actually breaks teams is not routine work but arrival pattern — work that shows up unannounced and demands attention today. Reserve visible capacity for it instead of pretending it is free.

Where this goes next

Sorting work into a domain is the first hour of Module 3 in Scrum Essentials, beLithe's eight-module self-study class. The rest of the course builds on it: the trade Scrum actually makes, the three accountabilities, the Sprint, the events, and a Scrum Readiness Plan for one real team.

See Scrum Essentials