Leaders often wonder why their Scrum teams still act like groups of individuals.
The answer is sometimes uncomfortable: the organization is making real teamwork hard.
A Scrum team may be told to own the sprint goal, collaborate across specialties, and deliver a valuable increment together. But the same team may also be staffed part-time, measured individually, interrupted constantly, and pulled back into functional silos whenever priorities shift.
When that happens, people adapt. They protect their own tasks. They focus on what their manager will notice. They avoid helping too much outside their specialty because they are already overcommitted. They attend the Scrum events, but inside the sprint they still behave like individuals.
That is frustrating for leaders, Scrum Masters, product owners, and team members. But it is rarely solved by telling people to collaborate more.
Teams work like individuals when the system around them rewards individual behavior.
Each of these problems has a leadership move that can make teamwork more likely.
Part-Time People Create Part-Time Teams
A team cannot build much shared ownership when half its members are assigned somewhere else.
Many organizations staff Scrum teams by spreading specialists across several teams. A database expert is 25% on one team, 25% on another, and available “as needed” to everyone else. A UX designer supports three teams. A tester is shared across a product area. A product owner is responsible for multiple teams and spends much of the sprint in meetings away from the people doing the work.
The organization may see this as efficient. It keeps scarce skills busy. It avoids hiring before demand is clear. It gives each team access to the people it needs.
But the cost shows up inside the sprint.
Work ends up waiting on whoever has the specific skill. Questions don’t get answered right away. Decisions happen without the right people in the room. The team plans like everyone is fully available, then runs into the reality that no one really is. People also start to avoid taking on anything outside their lane because their time is already stretched across too many commitments.
Part-time assignment creates part-time ownership.
A Scrum team does not need every specialist full time in every situation. But when key skills are routinely split across too many teams, the team learns to manage around scarcity instead of working together. The result looks less like teamwork and more like reservation scheduling.
What Leaders Can Change
Leaders do not have to make every specialist full time on every team. But they should make shared assignment visible and intentional.
If a database expert or UX designer is supporting three teams, the team should plan with that constraint in mind instead of pretending the person is fully available. Better still, reduce the number of teams each person supports so real teamwork has a chance to form.
Part-time assignment should be a conscious tradeoff, not the default staffing model.
Individual Utilization Undermines Team Delivery
Many leaders want teams to finish valuable work, but still manage as if the goal is to keep every individual fully utilized.
That changes how people behave.
If everyone is expected to stay busy all the time, people will start more work. If people are judged by the tasks they complete, they will protect their tasks. If specialists are rewarded for throughput inside their specialty, they will optimize their specialty even when the team needs something else.
This is how a team ends up with five people busy and six product backlog items nearly done.
A developer finishes coding and starts something new because the tester is not ready. The tester eventually catches up and finds issues, but the developer is now deep into another item. The product owner gets questions late, when the team has fewer options. By the end of the sprint, everyone has worked hard, but too little is actually done.
The problem is not effort. The problem is what the organization has optimized.
Scrum teams need room to help each other finish. That may mean a developer reviews tests, a tester joins a story discussion earlier, or a programmer helps clarify an acceptance criterion instead of starting another item. On a utilization chart, that may look less efficient. In delivery, it is often exactly what the team needs.
I first noticed this dynamic at 16 while working at a fast food restaurant. On a typical night shift, Nikki ran the register, Mark handled the grill, and I moved between roles wherever I was needed.
If the line got long, I helped Nikki. If burgers backed up, I helped Mark. No one cared whether I stayed in my assigned role. We cared whether customers got their food.
Scrum teams need more of that same thinking. The goal is not to keep every person busy in their specialty. The goal is to finish valuable work.
What Leaders Can Change
Leaders who want real Scrum teams need to care less about whether every person appears busy and more about whether the team is finishing valuable work.
Notice when someone helps another specialty, joins a discussion early, reviews work before being asked, or helps finish one important item instead of starting another. Those behaviors may not look as efficient on an individual utilization report, but they are often what makes team delivery possible.
Functional Reporting Can Pull People Away from Team Ownership
Functional departments are not automatically a problem. Specialists need mentoring, standards, career paths, and peers who understand their discipline.
But functional reporting can undermine Scrum teams when people receive stronger signals from their department than from their team.
A tester may be told the team owns quality, but evaluated by a QA manager on testing-specific output like the number of defects logged. A UX designer may be assigned to a Scrum team, but judged by design deliverables created before the sprint starts. A developer may be encouraged to help the team finish, but rewarded for completing assigned programming tasks.
Those signals shape behavior.
People naturally pay attention to the people who influence their reviews, raises, promotions, and reputation. If the team says, “Help us finish this,” but the functional manager says, “Why are your design deliverables late?” the functional manager wins.
Functional leadership should strengthen the Scrum team, not pull people away from it.
What Leaders Can Change
Leaders do not need to eliminate functional expertise. They do need to align it with team outcomes.
Functional managers can still protect professional standards, mentor specialists, and build capability. They just need to reward those skills when they help the Scrum team deliver, not only when they produce functional deliverables.
A manager of testers can still care deeply about testing skill while encouraging testers to collaborate earlier. A UX leader can still protect good design practice while helping designers work more closely with product owners and developers. An engineering manager can still mentor programmers while rewarding behavior that helps the whole team deliver.
Interruptions Make Sprint Goals Optional
A sprint goal is supposed to help a Scrum team focus.
It gives the team a reason to make tradeoffs. It helps the team decide what matters most when surprises happen. It gives the daily scrum something more useful to inspect than a list of individual tasks.
But leaders can accidentally teach teams that sprint goals are optional.
They do it by inserting urgent work mid-sprint. They do it by asking for “just a quick favor.” They do it by escalating around the product owner. They do it by treating sprint plans as flexible whenever the request comes from someone senior enough.
The team learns quickly.
If outside work can appear at any moment, the sprint goal becomes less meaningful. If priorities change whenever a leader asks, the team stops treating sprint planning as a real plan. If people are pulled away from the sprint often enough, they protect themselves by thinking in terms of personal tasks rather than team outcomes.
Interruptions are sometimes necessary. Production issues happen. Customers need help. Leaders learn new information. Scrum does not require pretending the world is stable for a full sprint.
A sprint goal cannot guide behavior if leadership treats it as a suggestion.
What Leaders Can Change
Make interruptions visible and intentional.
When urgent work appears, involve the product owner. Talk about the effect on the sprint goal. Make the tradeoff clear. Do not pretend the team can absorb every interruption without cost.
Leaders should also recognize that interrupting one person often interrupts the team’s ability to finish. Pulling a tester, developer, designer, or product owner away may look like a small request from the outside. Inside the sprint, it can leave important work waiting.
Focusing Only on Individual Assignments Limits Teamwork
Some leaders unintentionally keep Scrum teams working like individuals by asking individual-assignment questions:
- Who owns this?
- Who is assigned to that?
- What is everyone working on?
Those questions are sometimes useful. Work needs clarity. People need to know who is taking the next step. A team without any ownership can drift.
But assignment thinking becomes a problem when it dominates the way leaders talk about work.
The team begins to think in terms of personal ownership instead of shared delivery. A product backlog item becomes a collection of assigned tasks. Each person tries to finish their part. If the item gets stuck after that, it becomes someone else’s problem.
The better leadership question is often:
“What is the team trying to finish next?”
That question changes the conversation. It points people toward flow, risk, and shared responsibility. It makes it easier for the team to notice that three people are busy starting new work while one important item is waiting for help.
Leaders shape team behavior through the questions they ask. Asking only about individual assignments reinforces individual work.
What Leaders Can Change
Leaders can still ask who is taking the next step. But they should also ask what the team is trying to finish, where work is waiting, and what is putting the sprint goal at risk.
Those questions keep the focus on team delivery instead of individual activity. They also help the team see when starting more work would be less useful than finishing something already underway.
Frequent Reshuffling Prevents Real Teams from Forming
Scrum teams need time together to become good at working together.
They need to learn each other’s habits, strengths, preferences, and blind spots. They need to discover how to split work, coordinate in the daily scrum, involve the product owner, and help one another finish. They need a few sprints together to improve.
Frequent reshuffling resets that learning.
Some organizations treat teams as temporary staffing pools. People are moved from one initiative to another whenever a new priority appears. A team starts to gel, then loses a developer. A product owner finally gets aligned with the team, then is assigned to a higher-priority effort. A tester is moved because another team is behind.
Each move may make sense locally. Together, those moves prevent teamwork from forming.
A stable team will still change over time. People leave. Products shift. Skills need to move. But leaders should recognize the cost of churn. Every change forces the team to relearn how to work together.
When leaders want teamwork but keep changing the team, they are asking for maturity without giving the team time to mature.
What Leaders Can Change
Treat team changes as real costs.
Sometimes moving people is necessary. But it should be a conscious tradeoff, not an administrative convenience. Before moving someone, leaders should ask what learning, trust, domain knowledge, and coordination ability the team will lose.
Stable teams are not guaranteed to become great teams. But unstable teams rarely get the chance.
Reward Systems Tell the Truth
Culture is often clearest in the reward system.
A leader may say teamwork matters. But if recognition goes to individual heroics, people notice. If promotions favor the person who saves the sprint at the last minute, people notice. If managers praise starting more work but ignore helping behavior, people notice.
Teams pay attention to what gets rewarded.
This is especially dangerous when the rewarded behavior looks useful in the moment. The person who works late to fix a problem may deserve thanks. The specialist who jumps across three teams to unblock everyone may be genuinely helpful. The manager who reassigns people quickly may appear decisive.
But if those patterns become normal, the organization rewards heroics over sustainable teamwork.
Real Scrum teams should not depend on a few people saving the day. They should make work visible early, reduce handoffs, limit work in progress, and collaborate before problems become emergencies.
What Leaders Can Change
Leaders can reinforce teamwork by noticing different behavior:
- Who helped finish an item that was at risk?
- Who raised a problem early?
- Who simplified the work instead of expanding it?
- Who helped another specialty without taking over?
- Who protected the team’s focus?
Those are the behaviors that create stronger Scrum teams.
A useful test for leaders is this: Are we asking teams to behave as teams while staffing, measuring, interrupting, and rewarding them as individuals?
Scrum Teams Need Leadership Support
A Scrum team can improve many things on its own. It can run a better daily scrum. It can swarm on risky work. It can limit work in progress. It can involve the product owner earlier. It can inspect handoffs in the sprint retrospective.
But some obstacles sit outside the team’s control.
A team cannot make itself stable if leaders keep moving people. It cannot fully own the sprint goal if leaders interrupt the sprint without tradeoffs. It cannot optimize for team delivery if managers keep rewarding individual utilization. It cannot collaborate across specialties if functional silos remain stronger than team ownership.
That is why leaders matter.
The goal is not to blame leaders for every team problem. The goal is to make the system visible. When Scrum teams continue working like individuals, leaders should ask what the organization is doing to make that behavior reasonable.
Sometimes the team needs training.
Sometimes the leader needs to remove a constraint.
Often, both are true.
Working on a Scrum Team helps the whole Scrum team, and the leaders who support it, build a shared understanding of how Scrum is supposed to work in practice. That shared understanding matters because real teamwork is created by the team and protected by the organization around it.
Agile Teams And Collaboration
FeaturedUse this guide to diagnose handoffs, individual task ownership, fragmented staffing, and the leadership conditions that make teamwork possible.
Working on a Scrum Team
FeaturedHelp the whole Scrum team align on roles, sprint goals, collaboration, and finishing valuable work together.
Self-Organizing Teams, their Benefits, and a Leader’s Role
FeaturedExplore self-managing teams, including the role of leaders and outcomes of effective teamwork.
When Should Agile Leaders Step In
Learn when agile leaders should step in to help teams—and when stepping back will better support team ownership, learning, and self-management.
Cross Functional Agile Teams
Learn what cross-functional agile teams are, why they reduce handoffs, and how specialists collaborate without everyone needing every skill.
A Leader’s Guide to Agile
Get Mike Cohn’s free 91-page guide to the ten things agile teams most need their leaders to know.