Article content
The standup takes twelve minutes. Five people, each reciting their update while staring at some vague point on the screen. Nobody comments on what anyone else says, because there’s no reason to: everyone is working on their own feature, in a different corner of the codebase. The standup ends, everyone goes back to doing exactly what they would have done without it. Then the retro. Three sticky notes come out of it: “improve communication,” same as last month. And sprint planning, which is really just individual task assignment with a two-week timer.
If this sounds familiar, you’re not alone. The 17th State of Agile Report by Digital.ai (2024) found that only 11% of practitioners report being “very satisfied” with Agile practices in their organization. The frustration runs deep enough that two original signatories of the Agile Manifesto have publicly turned against what Agile has become: Ron Jeffries, co-creator of Extreme Programming, wrote that developers should abandon Agile, or at least the version organizations have made of it. Dave Thomas, another signatory, declared that Agile is dead, hollowed out by marketing and mass certification.
The most common diagnosis is that Agile has become bureaucracy: too many rituals, too much process, not enough code. It makes sense. Who hasn’t thought that at least once, walking out of yet another endless planning session?
But there’s another possibility. One that has nothing to do with Agile itself, but with something more fundamental: the structure you’re applying it to.
J. Richard Hackman spent 40 years studying real teams: flight crews, orchestras, intelligence teams, surgical teams. His research, condensed in Leading Teams (2002) and Collaborative Intelligence (2011), arrives at a distinction that almost nobody in software makes: the distinction between a team and a working group. They are different things. They work differently. And they require different tools.
Agile practices are designed for teams. Apply them to a working group and you get exactly the frustration you’re feeling. The problem isn’t the method. It’s a structural mismatch.
The most overused word in software
In software, “team” is the default word for any group of people working on the same project. Five developers sharing a Jira board? Team. Two backend engineers, a frontend dev, and a designer reporting to the same manager? Team. Eight people across three time zones who meet at the 9 AM standup? Team.
Hackman would disagree. In Leading Teams he defines a “real team” through three minimum properties, all required.
The first is clear boundaries: everyone knows who is on the team and who is not. Sounds obvious, but in software practice it isn’t. The designer “shared” across three teams — in or out? The developer “on loan” for two sprints — a member? If you can’t make the list without hesitating, the boundaries aren’t clear.
The second is stable composition. People stay the same long enough to develop shared ways of working. Hackman studied flight crews: NASA data, which he reports in Leading Teams, showed that newly formed crews made more errors than those who had been flying together for a while, even when the newer crews had more experienced pilots. In software, quarterly rotation of people between teams destroys this effect. Every time, you start from zero.
The third, and most underrated, is real interdependence. The team’s output depends on collaboration between members — it’s not the sum of individual contributions. This is where most software “teams” fall apart. Five developers working on five independent features, with five cross-reviews done as a formality, are not interdependent. One person’s work doesn’t change another’s. If you removed all the meetings and put them in separate rooms, the result would be the same.
The test is brutal in its simplicity: if you eliminated standups, retros, and planning tomorrow, and everyone worked on their own, would the final product suffer? If the answer is no — if the result would be identical, maybe even faster without the interruptions — then what you have is not a team. It’s a group of individuals with a shared manager.
That’s not an insult. It’s a diagnosis. And the diagnosis is the first step toward stopping the use of the wrong tools.
Structural conditions: the 60/30/10
Hackman didn’t stop at the definition. He studied what makes a team effective, and the answer is less intuitive than you’d think.
Research by Hackman and his collaborator Ruth Wageman identifies five conditions that enable team performance: being a real team, having a compelling direction, an enabling structure, a supportive organizational context, and competent coaching. I won’t go deep on all of them here — each deserves its own article. The relevant point is different: how much do these conditions matter compared to what a leader does day to day?
Hackman’s answer, laid out in Collaborative Intelligence (2011), is the 60/30/10: 60% of a team’s effectiveness depends on design — the structural conditions put in place before the team starts working. 30% depends on launch — how the team is kicked off, the first days, the initial norms. The remaining 10% on ongoing coaching.
A clarification: Hackman presents this split as a “best estimate,” not as the result of a single study yielding those exact percentages. It’s a heuristic that synthesizes decades of research. Not a precise data point.
But the order of magnitude has solid empirical grounding. The Team Diagnostic Survey (TDS), developed by Wageman, Hackman, and Lehman and published in 2005, was administered to 2,474 people across 321 teams. The finding: structural conditions explain up to 80% of the variance in team effectiveness (Wageman, Hackman & Lehman, 2005). Not 20%. Not 50%. Eighty percent.
An earlier study by Wageman (2001) on 43 self-managing teams at Xerox had already shown the same pattern: a leader’s design activities influenced team performance. Day-to-day coaching activities did not.
The implication for software is direct. When a team isn’t working, the instinctive reaction is to work on dynamics: facilitate retros better, improve communication, do team building. Hackman’s framework suggests the most powerful lever is upstream. Who is on the team? What is the mandate? How is the work designed? Does the organizational context support it? If these conditions aren’t there, no amount of facilitation will compensate.
But the first of those five conditions — “being a real team” — opens a question that almost nobody in software asks.
Team or working group: the distinction that changes everything
A point Hackman makes often, and that gets misunderstood just as often: the distinction between team and working group is not a value judgment. It’s not “team = good, working group = bad.” They are two different organizational modes, each with its own strengths.
A working group is a set of people reporting to the same manager who may coordinate, but whose output is primarily individual. Everyone has their own goals, responsibilities, deliverables. The manager coordinates, assigns, removes obstacles. Deep interdependence is not required.
A team produces collective output. The result cannot be decomposed into the sum of individual contributions: it requires continuous collaboration, shared decisions, mutual adjustment. The cost is higher — you need stable boundaries, shared norms, time to develop ways of working together. But for certain kinds of problems, it’s the only configuration that works.
The damage comes from confusing the two.
A working group managed as a team generates overhead without benefit. Coordination meetings exist, but there’s nothing substantial to coordinate. Retrospectives don’t produce actions because there’s no shared process to improve: everyone has their own workflow, priorities, blockers. The Agile ceremony becomes a fixed cost on work that doesn’t require it.
The damage goes both ways, though. A real team managed as a working group is equally dysfunctional. If you have people who need to collaborate on a complex problem and treat them as individual contributors — assigning separate tasks, evaluating them individually, without protecting time for joint work — you’re undermining the one thing that makes that team effective: interdependence.
I’ve seen both scenarios. The first is more common in software, because the default organization tends to be the working group (developers assigned to individual features), while the process infrastructure is almost always that of a team (Scrum, Kanban with standups, retros, planning).
The operational question isn’t “how do I improve my team?” It’s more fundamental: is what I’m leading a team or a working group? The answer changes everything that follows.
The Agile mismatch: right tools, wrong structure
Back to the frustration we started with. Agile practices — Scrum in particular — didn’t emerge in a vacuum. They’re designed around a specific assumption: that a small group of people works interdependently toward a shared goal, iterating together. The sprint assumes a common goal. The standup assumes that knowing what others are doing changes your work. The retro assumes a shared process to inspect. Planning assumes collective prioritization decisions.
These are all tools that assume interdependence. Without it, they lose their point.
Now look at the typical “team” setup in many software organizations. People are assigned — often rotated — to a “team” that is really an organizational container. Everyone works on their own user story, with interactions limited to code review and the occasional Slack question. The “sprint goal” is the sum of individual stories. Interdependence is minimal or absent.
Apply team tools to this structure and the result is predictable. The standup becomes a round of updates nobody listens to. The retro produces generic complaints. Planning becomes bureaucracy. Not because Scrum is bureaucracy — but because you’re using it on a structure it wasn’t designed for.
The Manifesto signatories say as much, in different words. Jeffries talks about “Dark Scrum” — organizations using Agile rituals as control mechanisms, draining them of collaboration. Thomas says “Agile” was turned into a commercial noun when it was meant to be an adjective describing a way of working. Their critique is legitimate. But the diagnosis they offer — “organizations have corrupted Agile” — is incomplete. Hackman’s framework provides a more structural one: many organizations haven’t corrupted Agile. They’ve applied it to structures that aren’t teams.
I bring this up because I’ve seen it happen more times than I’d like to admit, including in contexts with competent people and good intentions. The standard response to the malaise was always the same: change the facilitator, try a different retro format, add a ceremony. Hackman’s framework gave me the vocabulary for what I felt but couldn’t articulate: the problem wasn’t the execution. It was the premise.
This changes the diagnosis and the solutions. If the problem is “Agile has become bureaucracy,” the answer is less process, fewer rituals, more autonomy. Sometimes that’s right. But if the problem is a structural mismatch, the answer is different: either transform the structure into a real team — with the costs that entails — or accept that you have a working group and adopt tools consistent with that reality. Both options are legitimate. What doesn’t work is staying in the middle.
Back to the twelve-minute standup we started with. Five people, five updates, no interaction. The obvious diagnosis is that the standup is poorly facilitated, or that Scrum doesn’t work, or that the team needs to “work on communication.” These are all responses that address the symptom.
Hackman’s question is different, and it comes first: do those five people need to talk to each other every morning to do their work? If each person’s work doesn’t depend on the others’, the standup isn’t poorly facilitated. It’s useless by design. The retro doesn’t produce actions because there’s no shared process to improve. Planning is bureaucracy because there are no collective decisions to make.
It’s not a question of execution. It’s a question of structure.
Next time you think “Agile doesn’t work,” try reframing. Don’t ask how to improve the process. Ask whether what you’re leading is a team or a working group. The answer isn’t a judgment. It’s a diagnosis. And from the diagnosis, everything else follows.
Sources
- Hackman, J.R. (2002). Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press.
- Hackman, J.R. (2011). Collaborative Intelligence: Using Teams to Solve Hard Problems. Berrett-Koehler.
- Wageman, R. (2001). How Leaders Foster Self-Managing Team Effectiveness: Design Choices Versus Hands-on Coaching. Organization Science, 12(5), 559-577.
- Wageman, R., Hackman, J.R. & Lehman, E.V. (2005). Team Diagnostic Survey: Development of an Instrument. Journal of Applied Behavioral Science, 41(4), 373-398.
- Digital.ai (2024). 17th State of Agile Report.
- Jeffries, R. (2018). Developers Should Abandon Agile.
- Thomas, D. (2014). Agile is Dead (Long Live Agility).
