Here's something every experienced practitioner knows but rarely says out loud: you cannot create a high-performing team. High performance is an emergent property. It develops naturally when the conditions are right.
But we are extraordinarily good at preventing those conditions from forming.
I've worked inside teams — not just observing from the outside, but writing code, participating in standups, struggling with technical debt, feeling the frustration when process gets in the way. I've also worked alongside some of the people who shaped how we think about teams in software: Jim Coplien, whose Organizational Patterns book remains one of the clearest maps we have for how high-performing teams actually work.
This list comes from firsthand experience. I've only included patterns I've personally observed in multiple organisations. Many of them are more the norm than the exception.
The 13 anti-patterns
Anti-pattern 01
Status Theater
The Jira Status Report Standup
"Let's filter Jira by person and go through the three questions."
When the daily standup becomes a sequence of individual status reports delivered upward rather than team coordination, it has failed. The team's ability to self-organise around shared problems disappears. The Scrum Guide removed the three questions precisely because they turn a developer meeting into a management reporting ritual.
The standup belongs to the team. It's their meeting, for their coordination, about their shared work. The moment it becomes a status performance, it has stopped being a standup.
Anti-pattern 02
The Assignment Machine
Distributing the Whole Sprint Before It Begins
"Let's assign all the stories upfront so we can balance the load."
Pre-assigning work turns a team into a collection of individual contributors running parallel tracks. High-performing teams focus collectively on the most important problem right now — they swarm, they help each other, they make real-time decisions about who does what. The moment all work is pre-allocated, that collective intelligence evaporates.
Who does what, when, and with whom — decided in real time by the people doing the work — is not overhead. It's where team intelligence happens.
Anti-pattern 03
Invisible Micromanagement
The Helpful Suggestion That Kills Autonomy
"Sarah should probably take that story — she knows the frontend."
Each "helpful" suggestion about who should do what is a small withdrawal from the team's autonomy account. Over time, the team stops making these decisions themselves — not because they can't, but because they've learned not to. The interference rarely feels like micromanagement to the person doing it. It feels helpful. That's what makes it so persistent and so hard to name.
High-performing teams need the freedom to figure out the best approach together. That capability atrophies without use.
Anti-pattern 04
Individual Assignment
Tracking That Makes Collaboration Invisible
"We need individual story assignments in Jira so we can track who's working on what."
Jira assigns tasks to one person. Management wants hour reporting. Together, they create a model of software development that simply doesn't match how good teams actually work. Swarming doesn't fit the data model. Pair programming produces no individual record. Velocity is a team metric — but reporting is individual, so individuals optimise for what the reporting captures: looking personally productive.
Developers know that individual hour tracking is largely meaningless — the work happens collectively, dynamically, across people and conversations that no ticket represents. Managers get a spreadsheet that gives them a sense of control. Neither gets what they actually need: an honest picture of what the team is achieving together.
Anti-pattern 05
Interrupt-Driven Development
The Responsiveness Culture That Prevents Focus
"Let's take a look at this now — it shouldn't take long."
When someone from outside brings a request, they want to hear the team will look at it immediately. Not "we'll add it to the queue." That feels unresponsive. Unhelpful. This creates a culture where starting new work is always more visible than finishing current work — and where the team learns to accommodate interruptions as the norm.
It bleeds into standups. Reporting many ongoing tasks sounds responsive and busy. Reporting one focused thing you're completing sounds unambitious. The team has been conditioned to reward starts, not finishes. Work in progress grows without limit — not because anyone planned it that way, but because saying no to the next request feels like the wrong answer.
Anti-pattern 06
Craft Neglect
Shipping Without Quality
"We don't have time for refactoring — just deliver the feature."
When only functionality gets rewarded and engineering craft is treated as optional, teams slow down. Quietly, steadily, invisibly — until the codebase that was your competitive advantage becomes the thing making every new feature slower and more expensive than the last. The team that skipped quality to go fast eventually can't afford to move.
Quality isn't in opposition to speed. It's what makes speed sustainable over time.
Anti-pattern 07
Deferred Quality
Log It and Fix It Later
"Let's create a ticket for that bug and get to it next sprint."
Not stopping to fix quality problems when they're found ensures they accumulate. Teams spend progressively more time managing known defects rather than building. The discipline of stopping the line — fixing problems immediately when found — is one of the most powerful practices in high-performing teams, and one of the first sacrificed under schedule pressure.
If you find it broken, stop and fix it now.
Anti-pattern 08
Permanent Coaching
The Facilitator Who Won't Let Go
"I'll run all the ceremonies to make sure they happen correctly."
When a scrum master or coach owns and runs all the team's ceremonies, the team never develops ownership of its own process. The facilitator becomes a dependency rather than a temporary scaffold. The team waits for the coach to organise the retrospective, run the planning, facilitate the standup — rather than doing these things themselves.
The ultimate goal of good coaching is to make coaching unnecessary. A team that can't run its own processes hasn't been coached to independence. It's been kept dependent.
Anti-pattern 09
The Safe Room
Retrospectives Without Teeth
"Let's keep the retro focused on things within the team's control."
Limiting retrospectives to things the team can fix themselves ensures that systemic problems never get surfaced. The most significant impediments to team performance almost always live outside the team — in how the organisation is structured, how decisions are made, how priorities get set.
What should happen is the opposite. Management should be asking upward: what's blocking you? How can we help? There should be a clear path for surfacing impediments the team cannot resolve themselves — and people actively responsible for escalating them. Ultimately, it's the CEO who owns the organisational impediments that nobody below them has the authority to remove.
Constraining retrospectives to "what the team can control" doesn't make them safe. It makes them useless.
Anti-pattern 10
The Technical Bystander
Non-Technical Ownership of Technical Quality
"Let the product owner decide which tech debt to prioritise."
Product owners understand what users need. Engineers understand what the codebase can sustain. Both perspectives must inform technical priorities — and engineers must have genuine authority over decisions that determine the long-term health of what they're building. When that authority sits entirely with someone who doesn't work in the code, quality degrades systematically.
You cannot build a high-performing engineering team on a foundation of accumulating technical debt.
Anti-pattern 11
Ivory Tower Architecture
Architects Who Don't Implement
"Our architects focus on design — developers handle implementation."
When architecture decisions are made by people who don't implement them, you get solutions elegant in diagrams and difficult in practice. Architects not close to the code cannot see where their designs break down — the edge cases, the performance implications, the maintenance burden imposed on the people living inside the system.
The Organizational Patterns say it clearly: Architects Also Implement. It's a pattern because it works. And because it's consistently ignored.
Anti-pattern 12
The Nomadic Team
No Dedicated Space
"We use hot-desking — people can work from anywhere."
Teams without a dedicated space — physical or virtual — lose the spontaneous conversations that drive effective collaboration. The quick question. The impromptu whiteboard. The five-minute discussion that prevents an hour of rework. These depend on shared context and proximity. When teams only communicate in scheduled meetings, they've been reduced to workgroups.
High-performing teams need instant, high-bandwidth communication between people who share a goal.
Anti-pattern 13
The Fragmented Mission
Teams Formed for Organisational Convenience
"We put this team together based on who was available."
Teams built around what's convenient for the organisation — available scrum masters, balanced headcounts, shared services across products — cannot build the depth of shared understanding that high performance requires. They juggle multiple priorities, serve multiple masters, have no sprint goal that means anything. High-performing teams are defined by what they exist to do. Teams formed for convenience rarely know what that is.
"Every single pattern was introduced to solve a real problem."
The uncomfortable truth
Most organisations are doing several of these things right now. What makes this genuinely uncomfortable is that every single pattern was introduced to solve a real problem.
We track individual work to improve visibility. We pre-assign stories to balance workload. We limit retrospectives to keep them actionable. We create architect roles to handle system complexity.
Each decision made sense in isolation. Together, they systematically destroy the conditions that make high performance possible. This isn't about bad intentions — it's about the difference between local optimisation and systemic thinking. When you optimise each part of a system without considering the whole, you get these results. Every time.
What this points to
These thirteen anti-patterns are symptoms of the same underlying problem: organisations structured around functions, roles, and processes rather than around the goal of building great products.
The teams closest to the work usually see this clearly. The developers who raise concerns loudest in retrospectives are often the ones who understand most precisely what's broken.
What they rarely have is the organisational authority to fix the system that's generating the symptoms.
That's a leadership problem — which is why leadership is where it has to be solved.