Agile team dysfunction case study exercise

The scenario

A company scaled from 15 to 80 people in 18 months, and something about how the team works has stopped functioning, though nobody has said exactly what. You joined two weeks ago as the product manager. You have not been handed a diagnosis. You have only sat in meetings and taken notes.

An engineering lead says the team just ships what it can in a sprint, some things take longer than estimated, and that is not a big deal because velocity looks fine. A head of sales says he went around the process and asked an engineer directly for a small change before a big client call, because going through the proper channel would have taken two weeks he did not have. A QA lead says she keeps seeing stories marked done in the tracker that clearly are not, has flagged it in three separate retros, and now just assumes she has to re-test everything regardless of what the board says. A senior engineer says he has started building before a ticket is even fully written, because waiting for refinement takes longer than just figuring it out as he goes, and refinement sessions do not seem to change anything anyway. The chief product officer says the team feels slow to her, but she cannot point to why. All the pieces of a normal agile setup, standups, retros, a backlog, appear to be there.

Nobody has told you what to fix. That is the job.

What you are asked to do

The exercise moves through five connected steps:

• Read the four quotes and name the patterns you see, without treating them as a fixed checklist, tying each pattern to specific language in the quotes and to what is actually broken underneath, not just what people said out loud.
• Classify each pattern as a process problem, a role clarity problem, a ritual design problem, or a culture problem, naming the primary category when a pattern spans more than one.
• Pick exactly one pattern you can start addressing in week two, under your own authority, with no exec mandate, and define what changes on day one, who owns it by name, and how you would know within 30 days that it is working.
• Write direct, two-paragraph responses to two pieces of pushback: a CTO who says the team already tried adding process once and it did not stick, and a head of sales who says he will keep bypassing the process unless given a faster legitimate path.
• Sequence the remaining patterns as start now, start quietly, or defer, ahead of briefing an incoming CPO who has limited patience for anything that is not already showing results.

What a strong answer covers

The exercise's own objectives are the standard a strong submission has to meet:

• Do the named patterns come from the actual quotes, with each one tied to specific language, rather than a generic list of agile anti-patterns applied without evidence?
• Are the classifications defensible, distinguishing a broken process from a role nobody agreed on from a ritual that exists but does no work?
• Is the chosen first fix something a new PM could actually start without an exec mandate, with a named owner and a concrete 30 day signal, rather than a broad initiative disguised as a small one?
• Do the responses to the CTO and the head of sales engage with the actual objection, rather than restating a policy at someone who has already heard it?
• Does the sequencing plan account for limited political capital and a new CPO's attention, rather than treating every fix as equally urgent?

Skills this exercise practises

Reading indirect, sometimes contradictory evidence for the pattern underneath it, instead of waiting to be handed a labeled problem. Separating what is broken by design from what is broken by habit. Choosing a fix that is small enough to actually start without permission, and defending it against real pushback from people who have already tried and failed once before. These map onto the bootcamp's own curriculum on outcome-driven planning, team topology, and healthy rituals. If you want the same kind of week-by-week decision sequencing at a more senior level, the product leadership week exercise from Head of Product runs a comparable structure. For the underlying prioritization skill, see the RICE prioritization framework and, on where the PM and PO roles actually diverge in a scaling team, product owner vs product manager.

Which bootcamp this comes from

This exercise is the practical challenge from Beyond Agile, a one week, two live session bootcamp on Builders Camp covering outcome-driven planning, discovery and delivery balance, team topology, roadmap governance, and continuous improvement. Completing the practical challenge counts toward the bootcamp's completion requirement and its certificate, alongside the certification quiz.

Builders Camp runs this bootcamp both live and self-paced, included with the Builders Camp Membership alongside every other bootcamp, track, and masterclass. If diagnosing team dysfunction like this is part of a step up you are aiming for, how to get promoted to senior product manager covers the broader case.