Software teams: jelling, toxicity and structure

A jelled team is a claim about output, not about mood

DeMarco and Lister named the phenomenon: a jelled team is a group so strongly knit that the whole is greater than the sum of the parts. The claim is empirical, not sentimental — members of jelled teams are measurably more productive and more motivated than average, they share a goal and a culture, and they do not need to be managed in the traditional way because they have momentum. Notice what the term is not. It is not a synonym for people liking each other, and it is not something a manager can decree. There is no reliable procedure for producing a jelled team; there are only conditions that make it likely and conditions that make it impossible.

The four senses an effective team establishes

Four attributes show up in effective software teams. A sense of purpose: everyone can say what the team exists to achieve. A sense of involvement: every member feels their skills are actually used. A sense of trust: engineers trust the competence of their peers and their managers, which is what lets them delegate and stop checking. A sense of improvement: the team periodically reflects on how it works and changes it — the instinct the Scrum retrospective institutionalises. Effective teams are also diverse in skill: a team of five people with identical strengths has five copies of the same blind spot.

Team toxicity: five factors, sometimes counted as four

The opposite condition has a name too. Team toxicity is the set of environmental conditions that make jelling impossible. Jackman names five: (1) a frenzied work atmosphere, where people are pulled between goals that keep moving; (2) high frustration that turns into friction between team members; (3) a fragmented or poorly coordinated software process, felt as burdensome tasks and work products nobody reads; (4) an unclear definition of roles, so accountability is ambiguous; and (5) continuous and repeated exposure to failure, which teaches a team that effort does not pay. Pressman's own chapter summary merges the first two into one heading, which is why you will meet the list quoted as four. Say five, note that the frenzy and the frustration are often grouped, and you are correct against either version.

The reason toxicity is worth a definition question is that it locates the fault in the environment, not in the people. Each toxin has a structural antidote. Frenzy is answered by giving the team access to all the information it needs and by not moving major goals once they are set. Frustration is answered by pushing decision-making authority down to the team. An inappropriate process is answered by letting the team choose its own process model, having understood the product and the people. Unclear roles are answered by the team establishing its own accountability mechanisms — technical reviews are the standard one — and defining in advance what happens when someone does not deliver. Exposure to failure is answered by team-based feedback and problem-solving so that a failure produces a change rather than a search for a culprit.

Structure follows the project, not the org chart

There is no best team structure. The right one depends on the difficulty of the problem, the size of the resulting program, how long the team will stay together, how far the problem can be modularised, the required quality and reliability, the rigidity of the delivery date, and how much communication the work demands. Those seven factors are the ones to name if you are asked to justify a structure. Agile teams answer the question differently: they are self-organising and do not commit to one structure at all, changing shape as the problem changes, and they often carry a customer representative as a member. The underlying finding is worth quoting in an exam because it cuts both ways — good people can work within almost any process, and weak performers struggle regardless, but even good people are hampered by an ill-defined process and poor support. People trump process; process still matters.

Those seven factors decide the shape, and the shapes themselves have names. Four organisational paradigms cover the ground:

• A closed paradigm team is a traditional hierarchy of authority. It produces software much as such teams have always produced it, and it works well when the job resembles work the organisation has done before. Its weakness is innovation: the hierarchy that makes it predictable also filters out the ideas that would have made it better.
• A random paradigm team is structured loosely and depends on the individual initiative of its members. It excels when innovation or a technical breakthrough is what the project needs, and it struggles the moment orderly performance is required instead.
• An open paradigm team tries to hold both at once: hierarchical control of a kind, but with heavy collaboration, consensus decision-making and communication that runs sideways as well as up. It suits complex problems where the answer is not known in advance, and it pays for that with the time consensus costs.
• A synchronous paradigm team partitions the problem first and then organises around the partition, so each sub-team works on its own piece with little active communication between the groups. It is the right answer when the problem genuinely decomposes, and the wrong one when the interfaces turn out to be where the difficulty lives.

The examinable move is to pick a paradigm from the seven factors rather than from taste — a rigid delivery date on a well-understood problem argues for closed, an unmapped technical risk argues for random or open, and a cleanly modularisable problem with a large team argues for synchronous.

Worked example — the BorrowBox team goes toxic in sprint 9

The BorrowBox team is five engineers plus a depot-manager representative as product owner. In sprint 9 the symptoms arrive together. The launch date has been moved forward twice by a marketing commitment nobody on the team was consulted about (frenzy: goals moving, information arriving late). Two engineers are quietly re-testing each other's locker-firmware changes because a bad build strands members on a public street, and neither will say so out loud (frustration, and a trust failure). Nobody can say whether the firmware belongs to the app team or to the hardware vendor's integration engineer, so a jammed-door defect sits untouched for nine days (unclear roles). And the last three sprint reviews rejected the increment (repeated exposure to failure).

The wrong response is a talk about communication. The right response is structural, one antidote per toxin: the delivery date is fixed for two sprints and the team is present when it is next discussed; the team is given authority to choose its own definition of done; ownership of the firmware boundary is written down and one named engineer holds it; and code review becomes the accountability mechanism so that trust is expressed as a process rather than as a private double-check. None of that is about being nicer to each other, and that is the point — toxicity is a property of the conditions, so the fix is to change the conditions.