Bo Frese
You can't create a high-performing team. High performance is an emergent property: it develops by itself when the conditions are right. What you can do is prevent it, and in my experience most organisations are very good at that, almost always with the best intentions.
I've worked inside teams as one of the developers, writing code, joining the standups, struggling with technical debt and feeling the frustration when process gets in the way. I've also worked with some of the people who shaped how we think about teams in software, like Jim Coplien, whose Organizational Patterns book is still one of the clearest maps we have of how high-performing teams work.
The list comes from my own experience. I've only included patterns I've seen myself in several organisations, and many of them are more the norm than the exception.
The 13 anti-patterns
Anti-pattern 01
Status Theatre
The Jira status report standup
"Let's filter Jira by person and go through the three questions."
When the daily standup turns into a row of individual status reports to whoever is running it, it has stopped working as team coordination, and the team loses its ability to organise itself around shared problems. The Scrum Guide dropped the three questions in 2020, and I think this is a good reason why: they turn a developers' meeting into a reporting ritual for management.
The standup belongs to the team. It's their meeting, for coordinating their shared work, and once it becomes a status performance it isn't a standup any more.
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 the work turns a team into individuals running parallel tracks. High-performing teams focus together on the most important problem right now. They swarm, help each other and decide in real time who does what. Once all the work is allocated up front, that shared intelligence disappears.
Deciding who does what, when and with whom, in the moment and by the people doing the work, isn't overhead. It's where the team does its best thinking.
Anti-pattern 03
Invisible Micromanagement
The helpful suggestion that kills autonomy
"Sarah should probably take that story, she knows the frontend."
Every helpful suggestion about who should do what takes a little autonomy away from the team. Over time the team stops making these decisions, not because they can't, but because they've learned not to. To the person making the suggestion it rarely feels like micromanagement. It feels like help, and that's why it's so persistent and so hard to name.
Teams need the freedom to work out the best approach together, and that ability fades when it isn't used.
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 a task to one person, and management wants hours reported per person. Together they create a model of software development that doesn't match how good teams work. Swarming doesn't fit the data model, and pair programming leaves no individual record. Velocity is a team metric, but the reporting is individual, so people optimise for what the reporting captures: looking personally productive.
Most developers know that individual hour tracking says very little, because the work happens across people and conversations that no ticket represents. Managers get a spreadsheet that gives them a sense of control, and neither side gets what it needs: 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 outside the team brings a request, they want to hear that the team will look at it right away. "We'll add it to the queue" sounds unhelpful. So the team learns to accept interruptions as normal, and starting new work becomes more visible than finishing current work.
It shows up in the standups too. Reporting many ongoing tasks sounds busy and responsive, while reporting one thing you're about to finish sounds unambitious. The team has learned that starts get rewarded and finishes don't. Work in progress grows without limit, not because anyone planned it, but because saying no to the next request feels like the wrong answer.
Anti-pattern 06
Craft Neglect
No time to keep the code healthy
"We don't have time for refactoring, just deliver the feature."
When only new functionality is rewarded and engineering craft is treated as optional, the code gets harder to work in with every change. It happens slowly and almost invisibly, until the codebase that used to be a competitive advantage makes every new feature slower and more expensive than the last. The team that skipped quality to go fast ends up unable to move at all.
Quality is what keeps speed sustainable.
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."
Where craft neglect is about the code you're writing, this is about the defects you've already found. Put them in a ticket instead of fixing them, and they pile up until the team spends more and more of its time managing known bugs instead of building. Stopping the line, fixing a problem the moment you find it, is one of the most powerful habits of high-performing teams, and one of the first to go 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."
I understand the instinct. When you're responsible for a team's process, running the ceremonies yourself feels like the safest way to make sure they happen. But when a Scrum Master or coach owns all the team's ceremonies, the team never takes ownership of its own process. The facilitator becomes a dependency instead of temporary scaffolding, and the team waits for the coach to organise the retrospective, run the planning and facilitate the standup.
The ultimate goal of agile coaching is to eliminate the need for agile coaching. A team that can't run its own process hasn't been coached to independence, it has 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."
Keeping the retrospective to things the team can fix itself makes sure the systemic problems never come up. And the biggest obstacles to team performance almost always live outside the team, in how the organisation is structured, how decisions are made and how priorities are set.
It should work the other way round. Management should be asking what's blocking the team and how they can help. There should be a clear path for raising the obstacles the team can't remove itself, and people who are responsible for taking them further. In the end, it's the CEO who owns the organisational obstacles that nobody below has the authority to remove.
Limiting the retrospective to what the team controls doesn't make it safe. It makes it 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, and engineers understand what the codebase can sustain. Both views have to shape the technical priorities, and the engineers need real authority over the decisions that decide the long-term health of what they build. When that authority sits entirely with someone who doesn't work in the code, quality degrades steadily, however good that person is at their own job.
You can't build a high-performing engineering team on top of growing technical debt.
Anti-pattern 11
Architecture at a Distance
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 that look elegant in diagrams and are hard to work with in practice. Architects who aren't close to the code can't see where their designs break down: the edge cases, the performance implications and the maintenance burden on the people living inside the system. Good architects end up here too, because the distance hides exactly what they would otherwise see.
Coplien's Organizational Patterns say it plainly: Architect Also Implements. It's a pattern because it works, and because it's so often 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 make collaboration work: the quick question, the impromptu whiteboard session, the five-minute discussion that saves an hour of rework. Those depend on shared context and being close to each other. When a team only talks in scheduled meetings, it has become a workgroup.
High-performing teams need fast, 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, like available Scrum Masters, balanced headcounts or services shared across products, can't build the shared understanding that high performance needs. They juggle several priorities, serve several masters and have no sprint goal that means anything. High-performing teams are defined by what they exist to do, and teams formed for convenience rarely know what that is.
The uncomfortable truth
Most organisations are doing several of these things right now. What makes it uncomfortable is that every one of them was introduced to solve a real problem.
We track individual work to get visibility. We pre-assign stories to balance the workload. We limit retrospectives to keep them actionable. We create architect roles to handle the complexity of the system.
Each decision makes sense on its own, and the people making them are doing their best with what they know. Together, though, these decisions destroy the conditions high performance needs. Optimise each part of a system in isolation, and this is the result you get.
What this points to
The thirteen anti-patterns are symptoms of the same underlying problem: organisations built around functions, roles and processes instead of around 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 authority to change the system that produces the symptoms. That authority sits with leadership, so that's where it has to be solved.
How many of the thirteen do you recognise, and who in your organisation has the authority to change what's producing them?