6.2.4: Team Performance Pitfalls

The Tuckman Model

The Tuckman model describes five stages of team development: forming, storming, norming, performing, and adjourning. It's a useful lens for understanding why a struggling new team isn't necessarily a broken one.

Forming is the early stage, where team members are polite, uncertain, and still learning what's expected of them. They tend to depend heavily on the leader for direction during this period, simply because the shared norms that will later guide them haven't formed yet. In this stage, Agile leaders should focus on clarifying goals, roles, working agreements, and basic practices, giving the team something solid to stand on before asking it to self-organize fully.

Storming is the stage where disagreement and tension start to surface. Team members may challenge roles, priorities, estimates, or established ways of working, and this stage can feel genuinely uncomfortable to be inside of. That discomfort isn't automatically a bad sign, though. Storming often means real issues are finally surfacing after being suppressed during the politer forming stage. Agile leaders should facilitate the resulting conflict rather than shutting it down, build safety so people feel able to speak honestly, and keep the team anchored to its shared goals throughout.

Norming is the stage where the team begins forming genuine shared habits. People start to understand how to work together in practice rather than in theory. Working agreements stop being a document and start being how the team actually behaves. Trust improves steadily, and the team begins solving problems more effectively as a unit rather than as scattered individuals.

Performing is the stage where the team operates with real trust, focus, and shared ownership. Team members collaborate naturally without needing to be told to, raise risks early before they become crises, and improve continuously as a matter of habit rather than obligation. Leaders still support the team at this stage, but the team needs far less direct guidance than it once did.

Adjourning happens when the team completes its work, changes membership, or transitions into a new structure entirely. Agile leaders should help capture whatever the team learned along the way, recognize individual contributions honestly, and support people through the transition rather than letting it happen without acknowledgment.

The PMI-ACP exam may specifically test the storming stage, since it's the one most often misread. A weak answer treats storming as failure and tries to suppress the disagreement driving it. A stronger answer helps the team work through that conflict constructively, treating it as a sign of progress rather than a symptom of dysfunction.

Shu-Ha-Ri

Shu-Ha-Ri is a model of learning and mastery that maps well onto how Agile teams grow into their practices over time. Shu means follow the rule: a beginner learns the basics by following established practices closely, and a new Scrum team may genuinely need to follow Scrum's events, roles, artifacts, and timeboxes carefully before it has earned the understanding to adapt them thoughtfully. Ha means break or adapt the rule, the stage where the team starts to grasp the principles underneath the practices and can begin adjusting them with real intention rather than guesswork. Ri means transcend the rule entirely, the stage where the team has deep enough understanding to apply the underlying principles fluidly, shaped to whatever context it's actually working in.

This model matters because Agile teams sometimes tailor their practices far too early in their development. A new team might announce "we don't need retrospectives" or "we don't need a Product Owner" before it has actually understood why those practices exist in the first place, and that kind of premature customization tends to be genuinely risky rather than a sign of maturity. A mature team can tailor its practices responsibly precisely because it understands the principle sitting behind each one. A beginner team is usually better served learning the discipline first, before it starts deciding which parts of that discipline it can safely set aside.

Sustainable Pace

Agile teams should work at a sustainable pace, meaning the team can keep delivering value indefinitely without burnout, constant overtime, or a slow collapse in quality. Working harder is not always the answer to a delivery problem, however tempting it feels in the moment. An overloaded team tends to create more defects, take more shortcuts, hide more risks, and lose morale steadily, and all of that quietly slows delivery down over time even as it might look like speed in the short term.

A team working at a genuinely sustainable pace can think clearly under pressure, improve quality consistently, collaborate more openly, and maintain the trust that everything else depends on. Sustainable pace doesn't mean low standards or reduced ambition. It means long-term performance is being actively protected rather than spent down for a short-term win.

Performance Is More Than Velocity

Velocity is frequently misunderstood in exactly the way earlier chapters warned about. It can genuinely help a team forecast its own future work based on its own history, but it should never be used to compare teams against each other or to punish individuals for a number moving the wrong direction.

If a team's velocity climbs while defects increase and morale quietly collapses underneath it, performance hasn't actually improved at all. The system has simply found a way to hide its true cost behind a single rising number, which is exactly the trap a broader lens like this one is meant to catch.

Continuous Improvement

Agile teams improve through repeated, structured learning rather than through occasional big transformations. A simple improvement loop looks like this: notice the problem, discuss it safely as a team, choose one improvement to try, actually try it, inspect the result honestly, and adjust based on what was learned.

This loop is simple, but it's genuinely powerful precisely because of that simplicity. The key is making each improvement small enough to actually try within a Sprint or two, and visible enough that the team can honestly inspect whether it worked. A team doesn't need a sweeping transformation every Sprint to keep improving. It needs a steady habit of learning, applied consistently over a long enough period that small improvements compound into real change.

PMI-ACP Exam Connection

PMI-ACP questions often test team maturity and performance together, and the pattern tends to repeat across different scenarios. Strong answers usually support coaching, honest reflection, sustainable pace, and system-level improvement. Weak answers tend to punish the team for low velocity, compare teams against each other unfairly, ignore signs of burnout, treat retrospectives as optional when convenient, or read healthy conflict as a sign of failure.

If a team is genuinely struggling, the right instinct is rarely to assume more pressure is the answer. The better question is almost always what the team actually needs in order to improve, since pressure applied to an already strained system tends to produce exactly the defects, shortcuts, and hidden risk that sustainable pace is meant to prevent in the first place.

This closing distinction ties the whole chapter together. Whether the topic is Tuckman's stages, Shu-Ha-Ri, sustainable pace, or performance measurement, the same underlying idea keeps showing up: real team growth comes from removing friction and building trust, not from asking people to push harder against a system that was never designed to support them.