Making technology teams work better
Making technology teams work better
The standups happen. The board receives a velocity chart. Sprint planning fills two hours on a Monday and retrospectives produce action items. None of this is the same as delivering predictably, and the distinction matters more than most organisations are willing to examine.
There is a particular kind of organisational problem that is difficult to name precisely because it looks, on the surface, like everything is working. The Scrum ceremonies are running. The rituals are being observed. Someone is facilitating the standup, updating the board, and scheduling the retrospective. From a distance, and sometimes from a leadership position, this looks like a functioning delivery system.
It is not. In most cases it is an organisation going through the motions of a framework without having the structural conditions that would allow the framework to produce the outcomes it promises. The ceremonies are real. The delivery confidence is not.
I have seen this pattern present itself consistently enough, in enough different organisations, that it deserves a name. Performative Scrum Syndrome is not a criticism of the people running the ceremonies. It is a description of what happens when a process designed for one set of conditions is applied to a fundamentally different set of conditions, and when the response to its failure is to do more of it, more carefully.
The ceremonies are not the problem. They are the visible layer of a structural condition that the ceremonies were never designed to fix.
Before diagnosing what goes wrong, it is worth being precise about what Scrum requires to function as designed. The Scrum Guide defines six overarching principles on which the entire framework depends. These are not aspirational values. They are operating conditions; each one presupposes something specific about the team's situation that must actually be true for the ceremonies to produce the outcomes they promise.
The team relies on transparency, inspection, and adaptation. They must be able to see what is actually happening, assess it honestly, and change course based on what they learn. This only works if the team has access to real information and real authority to act on it.
Scrum teams are empowered to manage their own work. The team decides how to achieve the sprint goal, not a manager or a plan. This requires both genuine authority to decide and genuine accountability for the outcome.
Work is done together across disciplines, not handed sequentially from one specialist to the next. Stakeholders engage with the team's output regularly, not only at project end. Cross-functional teamwork is the operating model, not the aspiration.
The most valuable work is done first. The product owner has the authority to determine what value means and to order the backlog accordingly. At the end of each sprint, the team has delivered the highest-value items available to them, not the next items on a plan.
Scrum events are fixed in duration and respected as such. The sprint does not extend when goals are missed. Time-boxing creates the discipline that makes planning predictable and the sprint commitment meaningful rather than aspirational.
Each sprint produces something real that can be inspected, used, and learned from. This requires that work can actually be broken into increments that are meaningful in isolation, not phases of a larger sequential plan that only becomes usable when all phases are complete.
Read together, these six principles describe a team that has clarity, authority, cross-functional capability, a genuine decision-maker on value, protected time, and work that can be delivered incrementally. That is a specific set of conditions. In the organisations where these conditions exist, Scrum works. In the organisations where they do not, the ceremonies run regardless, and the gap between the framework's assumptions and the organisation's reality is where Performative Scrum Syndrome takes hold.
The Self-Organisation principle in particular carries two structural implications that are most commonly absent in organisations running Scrum in name only. A team cannot genuinely self-organise if it does not have all the skills required to complete its work, because it will always be dependent on someone outside the team to proceed. And it cannot self-organise if its members are simultaneously committed to three or four other teams, because they cannot build the shared context, mutual accountability, or collective ownership that self-organisation requires. These are not optional refinements to the principle. They are the conditions without which the principle cannot operate.
The purpose is to avoid dependencies entirely. Dependencies carry communication overhead, require additional work to manage, and introduce delays that compound across sprint cycles. A team that can take work from idea to done without needing another team to unblock it is a team that can make and keep a meaningful sprint commitment.
Full dedication to one team's work makes planning more reliable; the team can project capacity without accounting for the fluctuating demands of other programmes of work. It also preserves cognitive bandwidth: staying inside one team's context means engineers can do deep work rather than constantly reloading a different problem space.
Neither of these membership conditions is easy to satisfy. Both require enough people with the right skills, structured into teams with boundaries that reflect the work. In practice, many organisations find themselves unable to satisfy both simultaneously, and the trade-off they make in response is where the trouble starts.
The most common response to resource constraints is to prioritise Team Membership Principle 1, keeping teams self-sufficient, at the cost of Team Membership Principle 2. Specialists are spread across multiple teams so that each team has the skills it needs. Dependencies are avoided. On paper, every team looks complete.
When a specialist is a member of four teams, all the strain of determining which competing priority should come first falls on that individual. They are not supported by a system designed to handle that complexity; they are simply left to navigate it. They must attend all the Scrum events for each of their teams. They experience significant cognitive load as they switch continually between contexts. The calendar fills with ceremonies. The afternoons, the time that sustained deep work requires, fragment into unusable pockets between meetings.
This is a structural decision with predictable human consequences, but it is rarely framed that way. Organisations treat it as a scheduling problem ("we need to stagger the standups") or a capacity problem ("we need to hire more specialists"). Neither treatment addresses the underlying cause: the organisation has placed an unsustainable cognitive and coordination burden on specific individuals by treating team membership as a resourcing mechanism rather than an organisational design decision.
When you satisfy Team Membership Principle 1 by violating Team Membership Principle 2, you have not avoided the coordination overhead. You have transferred it: from the system, to the person.
The trade-off plays out in predictable ways, and the signals are not in the sprint data. They are in what the room is being used for, and in what the room itself tells you about how the organisation believes work should flow.
Eighteen people in a standup. Business analysts, a product manager, architects, front-end engineers, back-end engineers, database engineers, and testers, all nominally one team, all working on the same system. Eighteen people produce 153 possible lines of communication; a self-organising team of five produces ten. The standup was never designed for a group this size, and it shows. Each person reports what they did yesterday and what they will do today, addressed to the product owner, who nods and makes notes. Each person looks up to speak, then drops their head when they have finished. Nobody listens to anyone else. Nobody needs to: the work is not interdependent in any meaningful near-term sense. Each discipline completes its phase and passes the work along. Nobody in that room is working with anyone else. The product owner is the only integrating mechanism the team contains, and the product owner is not a team.
The office layout makes the structural model visible. The BA and PM sit together at one bank of desks. Behind them, a row of testers. Behind them, the developers. People arranged by discipline, not by shared outcome; by the phase of work they own, not by the problem they jointly hold. It is a physical map of a departmental organisation that has been told to call itself agile. The seating plan did not change when Scrum was adopted. The reason it did not change is that the underlying structure did not change either. The teams were renamed. They were not reorganised. Mel Conway observed in 1967 that any organisation will inevitably produce a system design that mirrors its own communication structure. The reverse is equally true: a seating plan that mirrors a waterfall phase sequence will produce a system architecture that reflects it, and a team structure that cuts across that architecture will generate the dependencies and coordination overhead that make self-organisation structurally impossible.
When individuals are spread across multiple teams to satisfy the requirement that each team have every skill it needs, the cost of that decision lands not on the system but on the people. A team is a small group with shared ownership of a bounded problem, interdependent work, and mutual accountability for a collective outcome. The engineer in four teams is the organisational model made personal: the furthest possible structural position from that definition.
An individual contributor, carrying membership of four teams simultaneously; the direct consequence of an organisation that chose team self-sufficiency over single team membership, and placed the coordination cost on its most stretched people. Half of every working week consumed by ceremonies across those teams. Actual productive work compressed into whatever remained. The afternoons, the only time available for sustained concentration, broken into fragments by back-to-back events with no space between them. The retrospective action items for each team were sincere. The structural condition generating the overload was never on the agenda, because it existed above the level at which any individual team had authority to change it.
The commitment problem compounds this further, and it manifests in one of two ways. The first is that whichever team has sprint planning earliest in the week gets first call on the engineer's time. That team plans with a full allocation; the remaining teams plan around what is left, which is often unclear until the first team's sprint is already running. The second is that the engineer, knowing they cannot predict what the other teams will ask of them, avoids committing meaningfully to any of them. They attend planning, they offer estimates, but they hold capacity in reserve for work they know is coming but cannot yet see. Neither approach produces a reliable sprint plan for any of the teams involved. Both are rational responses to an irrational structural position.
The same problem presents acutely for senior engineers and architects who are expected to contribute hands-on work across multiple teams. Their involvement is often unplanned; they are pulled in when a team hits a problem they cannot solve alone, which means their capacity is unknowable at planning time. Every team that depends on them carries a hidden risk: the assumption that a senior resource will be available when needed, built into a plan that has no mechanism for guaranteeing it.
This is not an unusual edge case. The multi-team engineer is a recognisable archetype in organisations that have grown their team count without redesigning their ownership model. The people who are most capable tend to be pulled into the most gaps. And no retrospective format will surface the cause, because the cause is not inside any of the teams running the retrospective.
A third pattern sits at the governance layer rather than the team layer, but its consequences are just as visible in the ceremonies.
The person holding the product owner title creates tickets in Jira and assigns them to engineers. The tickets describe tasks, not outcomes. Scope decisions, priority calls, and any change to the plan are made by a senior stakeholder group that meets periodically and whose decisions filter down through the product owner as instructions. The product owner has no authority to accept or reject scope, no mandate to make trade-off decisions, and no ownership of the product outcome. Their actual job is to keep the Jira board current, ensure tasks are assigned, and report progress against the plan upward. The role is, in function if not in title, a traditional IT project manager: maintaining a plan that someone else authored, tracking execution of work that someone else defined, chasing completions against a schedule that someone else set.
Sprint planning in this context is not planning. It is task assignment. The backlog is a decomposed project plan, ordered by dependency. The sprint is the next slice of that plan. What the team is handed at the start of each sprint is not a goal; it is a list of tasks distributed among named individuals. Nobody asks what business value will be delivered at the end of the sprint, because that question was not part of how the work was designed. The sprint goal, where one exists at all, is written at the end of planning rather than the beginning: a sentence constructed to describe the tasks that have just been assigned, working backwards from the list to find a label for it. It is not a goal that shaped the work. It is a caption for work that was already decided. When the sprint ends short, the product owner updates the plan. The next sprint begins. The cycle repeats.
The people inside these patterns do not, in general, experience them as structural problems. The four-team engineer experiences the situation as a personal one: never enough time, always context-switching, ending every week with the feeling that nothing ever gets finished properly. The engineer in the 18-person standup experiences months of work with no visible outcome, ceremonies that feel like theatre, and a growing sense that the effort and the result have no connection to each other. The team whose product owner cannot make a decision spends its retrospectives debating scope that was never theirs to decide, and its planning sessions committing to work they know may be overridden before the sprint ends. These are not morale problems that better leadership can fix. They are the predictable human consequences of structural conditions that were never designed with the people inside them in mind.
These structural conditions do not only fragment the work. They shape what the people doing it believe about how work should be organised. When those beliefs are present, the team's behaviour tends to follow a recognisable pattern. Zuzana Šochová, in The Great ScrumMaster, includes a self-assessment exercise called The Self-Organized Team, in which team members select from a set of statements describing how they approach six aspects of working together: the relative importance of individual task completion versus collective help; individual efficiency versus team-level value; how the team responds to external obstacles; how it handles tasks that feel too hard; how it responds to a colleague's concern; and how it navigates disagreement. Each statement has three options, scored zero, one, or two, with a combined score of seven or above indicating genuine self-organisation.
What the exercise surfaces is not just behaviour but the beliefs underneath it. Applied as a diagnostic rather than a self-assessment, it reveals what the structural conditions the team has been working in have trained them to value. The six dimensions named here (Collaboration, Collective Outcome, Team Agency, Vulnerability, Care, and Healthy Conflict) are this author's interpretation of the six questions, used as a framework for coaching conversations about what the team's answers reveal.
Two patterns appear most consistently in teams operating inside poorly structured conditions. The first is individual-efficiency thinking: the belief that the most important contribution a team member can make is to complete their own tasks as efficiently as possible, because others depend on their output. The second is individual-delivery thinking: the belief that the primary professional obligation is to have one's own work ready by the promised time, regardless of whether the team as a whole is on track. Neither belief is unreasonable on its face. Both are the rational operating model of an individual who has never been part of a genuinely self-organising team: one where helping a colleague finish their work is more valuable than starting your own next task, and where the team's delivery record is the only record that counts.
Patrick Lencioni's The Five Dysfunctions of a Team provides the explanation for why these patterns persist. The absence of trust is the foundation of every other team dysfunction. Without it, teams cannot engage in productive conflict. Without productive conflict, genuine commitment is impossible. Without commitment, accountability is performative. Without accountability, collective results suffer. The individual-efficiency and individual-delivery patterns that this diagnostic lens surfaces are both expressions of trust's absence. In a group where trust has not developed, collective commitment feels too exposed. People commit to their own output and protect themselves from accountability for anything beyond it. The result is a group of individuals running individual sprints inside a collective ceremony.
Lencioni's companion framework, The Ideal Team Player, adds a diagnostic question that leaders in this situation frequently get wrong. The three qualities it describes (being humble enough to prioritise the team over personal recognition, hungry enough to seek collective progress rather than individual completion, and people-smart enough to engage with the relational dimensions of teamwork) characterise someone who can function as a genuine team member rather than as an individual contributor within a group. When a team appears to lack these qualities, the instinctive response is to identify the individuals who need coaching. The more useful question is whether the structure has ever given those individuals the conditions in which these qualities would be safe, rational, and rewarded. An engineer who appears to lack hunger for collective progress may simply be burned out from simultaneous membership of four teams. One who struggles with the relational dimensions of collaboration may never have been part of a team where those dimensions were modelled, expected, or structurally possible.
None of these frameworks is asking whether the team has the right people. All of them are asking what the structure has trained the right people to believe.
The belief patterns this diagnostic lens reveals are not character failures. They are the accumulated product of structural conditions that have repeatedly rewarded individual delivery and never created the safety or incentive for collective risk. Coaching those beliefs in the absence of structural change leaves the cause intact.
The ceremonies Scrum prescribes are coordination tools. They are designed to help a team that already has the right structural conditions organise its work, inspect its progress, and adapt its approach. That is the extent of their authority. They have no mechanism to create the conditions they depend on.
A standup cannot make an eighteen-person group into a team. It can only reveal, every morning, that the group is not one. A retrospective cannot change the governance structure above the team that is generating the impediments the team keeps raising. It can only document, every fortnight, that those impediments have not gone away. Sprint planning cannot protect a sprint from priorities set outside it. It can only record, every two weeks, that the commitment made on Monday did not survive contact with the organisation it was made in. The ceremonies have authority over how the team coordinates within its structure. They have no authority over the structure itself.
The retrospective paradox. In organisations where Performative Scrum Syndrome is present, retrospectives tend to surface the same impediments repeatedly. They are raised. They are given an owner. They appear as action items. They re-surface three sprints later. This is not a failure of retrospective discipline. It is the predictable consequence of a team being asked to resolve impediments that originate outside their boundary of influence.
The team experiencing cross-team dependency delays cannot resolve those delays in a retrospective. The four-team engineer cannot reduce their cognitive load by writing a better standup update. The team whose product owner has no authority cannot unlock that authority by running a more structured planning session. In each case, the cause sits above the team. The ceremony sits inside it. The distance between the two is exactly the distance the ceremony cannot cross.
When this becomes visible, when the ceremonies are clearly not producing the predictability they promise, the instinctive response is often to abandon the framework entirely and revert to what the organisation knew before: a structured waterfall plan, managed by a project manager, with phases and gates. This response is understandable. It is also wrong, for exactly the same reason. The structural conditions that prevented Scrum from working will prevent any delivery model from working until they are addressed. A waterfall plan in the same organisation, with the same team boundaries, the same governance, and the same multi-team membership, will produce the same results and make the problems harder to see. The framework is not the variable. The conditions are.
This is also why the Scrum Master cannot fix this alone. The Scrum Master role is explicitly designed to serve both the team and the organisation: coaching leadership, removing structural impediments, and driving the conditions that allow Scrum to function at the system level, not just facilitating ceremonies at the team level. Most organisations understand only the second half of that mandate. The Scrum Master is confined to the team, the structural conditions above the team go unaddressed, and when delivery does not improve, the conclusion is that Scrum has failed. It has not failed. It has been given half the conditions it requires. Those conditions are precisely what the next section addresses.
What keeps organisations in this pattern is a belief that is not unreasonable on its face: the process is fundamentally sound and the execution simply needs to improve. The belief takes a different form depending on which pattern is presenting. In the organisation whose project plan predates its team structure, it is that better estimation and smaller task breakdown will eventually close the gap between sprint goal and sprint outcome. In the multi-team organisation, it is that staggering the ceremonies more carefully, or hiring more specialists, will reduce the load on shared engineers. In the organisation with a proxy product owner, it is that the product owner simply needs to be more proactive, or more available, or more assertive with the stakeholders above them. In each case, the belief locates the problem in the execution of the framework rather than in the structural conditions the framework is operating in.
In the majority of cases where this pattern is present, this diagnosis is incorrect. The ceremonies are not failing because they are being run poorly. They are failing because the organisational system surrounding them does not have the properties that would allow them to succeed. Improving ceremony quality in that context is like tracking symptoms more carefully when the prescribed treatment is wrong. A more detailed record of how the patient feels does not change the fact that the underlying condition is being misdiagnosed. The record-keeping is not the issue.
The question worth asking is not how to run the ceremonies better. It is whether the system surrounding the ceremonies has the properties that would allow them to work at all.
The structural problems described in this article are not resolved by the same layer of the organisation that is experiencing them. Each of the three patterns has a different root cause, and each requires intervention at the level where that cause actually lives.
Where the underlying delivery model is sequential rather than iterative, the structural reset requires a different intervention: one that addresses how the work is decomposed and sequenced, not just how the team is organised. That pattern (the sprint used as a Gantt chart block, the backlog as a requirements document, the extend-the-sprint response) is the specific subject of the third article in this series, which examines what happens when the Iterative Development principle is adopted in name but not in structure.
Where the person holding the product owner title is functioning as a backlog manager and task assigner rather than as a genuine decision-maker, the reset is a governance one. The product owner must have real authority: to accept or reject scope, to reprioritise the backlog, to make trade-off decisions without escalating to a committee. If that authority cannot be granted to the individual in the role, the role is not a product owner and the team cannot commit to sprint goals in any meaningful sense. The reset is to either grant the authority or redesign the governance model so that whoever holds it is accessible and responsive to the team's planning cadence.
The most direct intervention here is to commit to Team Membership Principle 2 and accept what comes with it. Define core team membership explicitly. Each team has a set of people who attend every Scrum event for that team and who are committed to that team's work as their primary obligation. Specialists who contribute across teams do so as collaborators, not as members: attending a specific ceremony when their knowledge is needed, without carrying the full ceremonial overhead of multiple memberships. Senior engineers and architects whose involvement is reactive rather than planned must be treated as a shared dependency and managed explicitly (what Matthew Skelton and Manuel Pais describe in Team Topologies as an enabling or platform capability serving multiple stream-aligned teams), rather than having their availability silently assumed into multiple sprint plans.
The question of where team boundaries fall is not a resourcing decision. It is an architectural one. Conway's Law (Mel Conway's 1967 observation that organisations produce system designs that mirror their own communication structures) means that team boundaries and system architecture are not independent. They shape each other. A team whose boundary cuts across the architecture will generate structural dependencies on every sprint cycle, regardless of how well it is managed. A team whose boundary aligns with a coherent part of the architecture or a recognisable customer value stream can work within its boundary without constant external coordination.
This principle can be applied in three ways, depending on the organisation's starting point. The first is structural alignment: drawing team boundaries to match the architecture and customer areas that already exist in the system, so that each team owns a bounded, coherent piece of both. The second is the Reverse Conway Manoeuvre: deciding the architecture you want the system to have, then designing the teams to produce it, knowing that the team communication structure will shape the system over time, not the other way around. This is the active version of Conway's Law, used as a design tool rather than a diagnostic. The third is value stream alignment: structuring teams around customer outcomes rather than technical discipline, so that each team can trace a direct line between the work it does and the outcome it produces: customer acquisition, customer retention, or an internal business capability. Skelton and Pais formalise all three in Team Topologies, which is the most rigorous contemporary framework for applying this thinking in practice.
The team boundary determines what the team can own, what it must depend on others for, and therefore whether self-organisation is structurally possible or structurally prevented before the first standup takes place.
This means accepting that the organisation now has dependencies to manage explicitly. That is not a step backwards. It is an honest account of how the work actually flows. Dependencies managed through structured coordination between product owners are less costly than dependencies managed invisibly by individuals caught between competing sprint commitments.
One implication of clarifying membership is immediately actionable, even before the larger structural changes are complete. Ceremony scheduling becomes tractable. Three disciplines consistently improve the situation: keep individual ceremonies under an hour; leave a gap between back-to-back events so context can be recovered; and schedule Scrum events in the morning so the afternoon remains available as an unbroken block for work that requires sustained concentration. The productivity lost to fragmented afternoons is rarely visible on any dashboard. Its cost is carried silently by the engineers whose working day has been sliced into unusable pockets.
None of these resets are ceremony changes. All of them are structural ones. That distinction is the point.
The changes that follow from structural reset are visible quickly, and they tend to be felt first by the people doing the work rather than reflected in any dashboard. In the case of the eighteen-person team described earlier, the four newly formed teams began producing usable, independently testable output within weeks rather than months. The four separate morning standups replaced a single reporting exercise with four genuine planning conversations; each team deciding what they would achieve that day. The retrospectives began surfacing problems the teams actually had authority to resolve.
The same pattern holds more broadly. When team boundaries align with architecture rather than discipline, the sprint commitment becomes a realistic unit of planning rather than an aspiration that the week will compromise. When the product owner has genuine authority, the backlog reflects value rather than a pre-agreed project sequence. When engineers are members of one team rather than four, their afternoons become productive again.
When those conditions are in place, the retrospective surfaces real impediments at team level, because the structural impediments that dominated it have been resolved at the level where they originate. The sprint commitment holds, not because the team became better at estimation, but because the commitment was made in conditions where it was realistic.
Longer term, organisations that have stabilised their structural conditions often find they can reduce ceremony load further still, not by eliminating collaboration, but by discovering how much of it can happen asynchronously without the information loss they feared. These changes take time and coaching to embed, but they are available only to teams who are not already drowning in the overhead of their own structural design.
What becomes available when the structural conditions are right is not only better delivery metrics. It is a different kind of engineering organisation: one where engineers spend the majority of their time doing engineering, where teams make decisions within their own boundaries without waiting for a steering group, where the work compounds sprint on sprint rather than fragmenting across phases and dependencies. The ceremonies take their proper proportion of the working week: purposeful, brief, and easy to run. The people doing the work feel the difference before the dashboards reflect it.
Scrum works well in the conditions it was designed for. Most of the organisations struggling with it are not struggling with the framework. They are struggling with the mismatch between the framework's assumptions and their own structural reality, and they are trying to solve it at the wrong layer.
If the pattern described here is familiar, the starting point is not a process audit. It is a structural one. How many teams is each person a member of? Is there a distinction between core team members and occasional contributors, or is everyone nominally on everything? Where do team boundaries fall relative to the architecture? What proportion of sprint failures originate inside the team versus outside it? What does a standup actually look like when observed directly: is it a genuine planning conversation or a sequential reporting exercise addressed to a single person? And what is the product owner actually doing: setting direction and making trade-off decisions, or managing a plan and assigning tickets on behalf of people who hold the real authority elsewhere?
These questions have answers. The answers are usually legible to the people experiencing the problem. What they often lack is the language to frame what they are seeing as a structural condition rather than a process failure, and the confidence that the structural condition is diagnosable and addressable without dismantling everything and starting again.
It is diagnosable. And in most cases, it is addressable, though it does require a willingness to look at the system rather than the symptoms, and to act at the level where the cause actually lives. The structural questions tell you what the conditions are. This diagnostic lens tells you what those conditions have produced in the people living inside them. Both answers are needed before the reset begins.
Orchiture's System Diagnostic is a structured, evidence-led assessment of how work flows through your engineering organisation: where it slows, where it tangles, and what is causing it. It takes three weeks and produces a root-cause report your leadership team can act on.
Start a conversationShorter versions of each piece appear on LinkedIn first — the problem, in a post. If you find yourself nodding, the full article is here. Follow for the problem-first content that comes before this page.