Organizations that widely implement Scrum often create Agile teams and Product Owners without giving up top-down management. They add backlogs, sprint goals, user stories, estimations, reviews, and reporting to the existing hierarchy. The result is often the same central control, with more roles and more meetings around it.
Teams are told they are empowered, yet they have little choice over what to work on, must obtain approvals, negotiate dependencies, escalate blocked work, and wait for decisions from elsewhere. Product Owners translate management priorities into backlogs, while teams remain responsible for execution, with little say in scope, demand, priorities, or the wider workflow.
The Agile frameworks organizations implement promote giving teams more freedom and autonomy, at least on the surface. Zoom out to the wider organization and that idea fades. Coordination problems emerge between teams, and they are impossible to predict and plan for in sufficient detail. Organizations respond in one of two ways: ignore the coordination issues, or add “agile bureaucracy” back into the system with layers of management, ceremonies, and reviews.
Neither response delivers the performance the organization hoped for. Work stalls in dependency queues while decisions crawl up and down the hierarchy. The most committed people quietly absorb the coordination work, becoming unofficial liaisons who hold delivery together. When commitments slip, teams get blamed for problems that live in the system around them. The transformation loses credibility, and the underlying problem survives every process change and reorganization.
Coordination can happen above the work or within it
Organizations can generally coordinate work in two ways. In the first, managers set priorities, allocate work, and resolve conflicts above the people doing the work. The people doing the work are treated as specialized parts. The system depends on formal roles and replaceable skills: when one person is unavailable, someone with a similar role can take over. It is clear who decides, but adaptation and ownership suffer.
The other way gives the people doing the work responsibility for coordinating it. A group does more than choose how to implement a feature. It helps set goals, manages its workflow, measures service performance, and improves how the work gets done. People have overlapping and broader skills, so the group can adapt without waiting for a central allocator. Management still establishes direction and negotiates constraints, but does not prescribe every detail.
In practice, that means the group can work with its partners to:
- resolve dependencies with other teams;
- coordinate decisions across product, design, and engineering;
- control incoming demand;
- negotiate shared priorities;
- change the surrounding workflow; and
- determine who owns an interface between teams.
This does not mean that every group decides everything independently. It means that the people who understand the work have both the authority and the responsibility to coordinate it with the wider system. They can negotiate with management and neighbouring teams rather than waiting for a decision to travel down through the hierarchy.
Frameworks weakened supervision without redesigning coordination
Agile challenged important parts of top-down control. It said that teams should be cross-functional, that people closest to the work should decide how to do it, and that feedback should come from working software rather than reports that predict and guess.
But many organizations do not remove their old management structure when they “go Agile.” They add Agile teams, Product Owners, Scrum Masters, backlogs, sprint commitments, and new reporting routines on top of it.
The result can be the same top-down management with more layers. A Product Owner serves as a proxy for senior management, translating strategic direction or departmental projects into a team backlog. The team is told it owns the solution, but management controls the backlog, the sprint goal, the release date, and the measures used to judge success. In Scrum implementations, the sprint can become a short-term delivery commitment that teams are scored on, rather than a useful planning boundary.
Scrum itself doesn’t cause these problems, but its roles and events are often used to make an existing hierarchy more efficient at directing teams. The team takes on more responsibility for execution, while decisions about purpose, priority, capacity, and dependencies remain above it.
A team may be allowed to decide how to implement a feature, while still being unable to:
- change how work enters the system;
- negotiate priorities with other groups;
- resolve dependencies;
- alter approval policies; or
- control the queue of incoming requests.
In the way Agile is typically implemented, the organization has not redesigned how coordination happens. It has repackaged some top-down control in Agile language and left the rest of the coordination work undefined.
Agile teams fall into unclear coordination or renewed bureaucracy
Most Agile teams are formed without designing the wider coordination system they need. They then fall into one of two traps.
In the first trap, management loosens its direct control and gives the team some discretion over implementation, but nobody takes responsibility for coordinating the team with the rest of the organization. The team is expected to be self-organizing, yet it cannot resolve dependencies, negotiate shared priorities, control incoming demand, or change the workflow around it. A stand-up can reveal a dependency and a retrospective can identify a bottleneck, but the team may still have no authority or mechanism for addressing either problem.
In the second trap, the organization responds to that coordination gap by adding bureaucracy back. A Product Owner becomes a proxy for management. A manager controls staffing and deadlines. A Scrum Master improves the ceremonies without being able to change the surrounding workflow. New roles, approval paths, planning layers, and reporting routines coordinate the work from above. The team is given responsibility for execution while the important decisions remain in the hierarchy.
These traps look different, but both avoid the same work: building a system in which capable groups coordinate their work with one another and with management. One leaves coordination unclear. The other recreates coordination through a new layer of control. Genuine self-management requires putting responsibility for coordination into the work system and giving the people doing the work the capability and authority to improve it.
Why Kanban is a practical answer to better coordination
Kanban does not begin with a team structure or prescribed delivery cycles. It begins with the current way work flows and reflects the existing system of policies surrounding it.
That changes the question from:
“Is this team following the Agile process correctly?”
To:
“What is preventing valuable work from flowing from idea to customer, and what has to change to resolve it?”
Kanban’s practices give teams a practical way to take control of problems Agile often leaves outside the team boundary:
- visualizing the workflow;
- making policies explicit;
- limiting work in progress;
- managing risk and classes of service;
- using feedback loops, flow metrics, and customer feedback.
Organize around the work
Kanban gives those coordination problems a visible place to be managed. A team Kanban board can coordinate work within a team. Coordination Kanban boards can make dependencies and shared work visible across teams. Portfolio Kanban boards can connect strategic priorities to the work moving through the organization. The organization coordinates around visible work instead of adding more managers.
The board becomes useful when the people responsible for the work can update the workflow, change policies, manage priorities, and come together to make decisions.
Use Kanban cadences to coordinate the work
Kanban cadences are regular conversations for decision-making and service improvement. They are not ceremonies added for their own sake. They give the people responsible for the work a place to negotiate as participants rather than passing requests up and down a hierarchy.
For a single service, useful cadences include:
- Service Delivery Review: Is the service meeting customer expectations?
- Stand-up Meeting: What did we do, what are we doing, and what is blocked?
- Delivery Planning Meeting: How should capacity be allocated for the next period?
- Replenishment Meeting: What new work should be pulled into the system?
Across services or at the business-unit level, useful cadences include:
- Strategy Review: Are strategy and capability aligned?
- Risk Review: What blocked, aging, or vulnerable work needs attention?
- Operations Review: How is delivery performance comparing with commitments?
The goal is deliberate, visible, shared coordination.
How Kanban supports self-management
Kanban does not create a self-managing culture simply by putting up boards. Its value is that it gives people practical ways to take responsibility for the whole flow of work, not just the tasks assigned to them.
These practices give self-management some substance. They connect authority with responsibility. The people doing the work can see how the system behaves, make decisions about it, and change the policies that shape it. Management still has an important role, but that role shifts from directing every activity to establishing purpose, negotiating constraints, and helping groups coordinate.
From autonomy to capability
You cannot create an empowered team merely by appointing a Product Owner, assigning it a Jira board, or declaring it self-organizing.
If the team cannot change its policies, manage its priorities, understand its dependencies, or improve its workflow, it has been given responsibility without the control to do so.
The practical test is simple: can the people doing the work coordinate with one another, with other groups, and with management? Can they change the conditions that keep work from flowing? If the answer is no, the organization has created local autonomy, not self-management.
Kanban does not solve every organizational problem. It does provide a way to make those problems visible and create the conversations, decisions, and feedback loops needed to address them. The goal is not to remove management. It is to replace personal direction with capable people coordinating around shared information, explicit policies, and negotiated goals.
