How to run a team health check

Different scope and different audience. Tenhaw installs both the retrospective and the monthly health check alongside client teams, as part of the operating model an Agentic Design Team designs at £35k to £55k a month. The retrospective runs fortnightly, belongs to the team, and works on the last two weeks, asking what happened and what to try next. The health check is monthly, scored, and read by management as well as the team, and it works on the system the team sits inside: line of sight, tech debt, defects, safety, pace. Run both. Fold the health check into the retro and the structural problems get traded away for the nearest process tweak, while management never sees the card.

Private until the reveal, not anonymous after it. Anonymous scores kill the only question worth asking, which is what did you specifically see that made you score it that way. Collect scores individually so nobody anchors, reveal them together, then discuss them attributed. If people will not put a red on the board with their name against it, that is your safety card answering itself, and it is a bigger finding than anything else in the session.

Assume a measurement problem before you assume a healthy team. Check three things: whether a manager scored or spoke first, whether the data agrees (forecast against actual, bug budget burn, epics bouncing out of Ready for Dev), and whether the wording is soft enough that agreeing costs nothing. A card everyone can agree with in a bad month is a badly worded card. Fix it at the annual re-word, not mid-year, and mark the break on the chart.

The delivery lead owns and facilitates it, one team at a time: engineers, testers, designers, the product manager, and any contractor who has been there more than two weeks. Tenhaw supplies that facilitator on client teams at its published senior practitioner day rate of £1,250 excluding VAT, and hands the ritual to a client delivery lead before the engagement ends. Line managers of the people in the room do not attend, and no score is taken from anyone outside the team. If the delivery lead also line-manages half the room, borrow a facilitator from another team and have the lead abstain from scoring, because a score from the person who writes your review is not a score.

Ten fixed statements covering line of sight to the outcome, value confidence, predictability, flow, work arriving ready, tech debt, defects, tooling, safety and pace. Word each as a statement a person can agree or disagree with, like "I know which outcome my current work rolls up to and what it is worth" or "I can change this codebase without fear". Then freeze the wording, because month three only means something if it is answering exactly the same question as month one. Ten cards, no additions, re-worded at most once a year with the break marked on the chart so nobody compares across it.

Monthly, per team, in the same week every month, and alongside the fortnightly retrospective rather than instead of it. Tenhaw keeps that monthly beat with the client teams it works alongside. The session itself is forty-five minutes; the whole ritual costs about two hours a month once you include pulling the delivery data and publishing the card. Run an extra one as a baseline in your first fortnight with a new team, and again when a team changes how it delivers, treating the month after as a fresh start. Any single month is noise. Monthly matters because the instrument reads trends, and the signal only appears when the same cards line up across a quarter.

Two marks per card, a colour for the current state and an arrow for direction. Green, amber and red are recorded as 2, 1 and 0, and the arrow comes from the team median against last month's median, which the team can overturn out loud with a reason. Everyone scores privately before any discussion, then everything is revealed at once, because if a senior person scores first every other number drifts towards theirs. The pair tells you more than either half alone, since amber-improving is a team already fixing something and green-worsening is the card worth an hour while it still looks fine.

One page of the month's delivery data, circulated the day before so nobody meets it for the first time in the room: throughput, what the forecast said against what actually landed, bugs raised against the bug budget and closed, tech debt burn, how many pieces of work bounced back for missing approvals, and the validation result for every live outcome. The scores stay subjective and should, but half the cards have evidence in the tracker, and without it predictability and quality get scored on how last Tuesday felt. A team that missed its forecast by three epics can still score itself green in a week that happened to go well.

On the trend, not the month. One red month is noise: somebody had a bad sprint, a release went sideways, half the team was on leave. The rule worth writing down is three consecutive months red or worsening, at which point the card stops being a retro item and becomes structural, with an owner at management level and a named change in the next quarter's roadmap. Not reacting early takes the same discipline. A reorg, a new process and a working group landing the month a score would have recovered on its own is the overreaction to resist, and holding that line when a director wants visible action is most of the work.

Yes, unedited and the same day. Management is half the card's audience, and the card exists to surface the obstacles the team cannot remove alone. Tenhaw does the same on client engagements, and reports a month that delivers no measurable value as a failed month. What makes that survivable is a protective rule, agreed in writing before the first session, that keeps the card out of an individual's performance review and out of a league table of teams, and stops anyone outside the team changing a number. Line managers do not sit in the session, but they see everything it produces, in full. The first time a red is quietly softened to amber on its way to a director, every score after it is decoration.

Stop trying to discuss all ten cards. Split the forty-five minutes: five on last month's actions, five on the reveal, thirty on six cards, five agreeing the new ones. Pick the six deliberately, taking the three with the widest spread across the team first, then the three that moved a step since last month. Five minutes a card, with the facilitator cutting it off, and everything else logged rather than debated. The cards you do not discuss still carry their colour and their arrow, so the chart stays complete and nothing is lost by leaving them alone this month.

The gap is the finding, and it usually means two groups are living in different parts of the system. That is why spread is the first thing you pick for discussion, ahead of the cards that simply look bad, because a card the whole team scores the same way is a shared view, while a split card is something one group can see and the other cannot. Ask what a person specifically saw that made them score it that way, rather than debating the number. In the worked example, product scored work arriving ready green and engineering scored it red, and the discussion surfaced that seven of eleven epics had left Ready for Dev with no approved story attached.

Because two actions that land beat ten that do not. Each of the two gets a named owner, a date inside the next month and a ticket in the normal tracker: tech debt goes on the quarter's Tech Debt epic, anything that changes the product becomes a story or an outcome ticket under a real epic, and anything the team cannot fix itself becomes a RAID entry owned by somebody outside the team. Nothing lives only in the health check document, because an action that is not in the tracker competes with committed epic work and loses. Open both at the start of the next session and mark them done or not done out loud.

Anyone who has been on the team less than two weeks abstains, and says so out loud rather than guessing at a system they have not seen yet. Several abstentions after a fortnight tell you something about onboarding before a single card is scored, so treat them as a finding in their own right. Everyone else doing the work scores, engineers, testers, designers and the product manager included, because they each hit different failure modes. With a genuinely new team, run a session in the first fortnight anyway and treat it as the baseline rather than a verdict, then read the real signal from the months that follow.

Better not to. Tenhaw reports the cards to client boards, not an index, inside Programme and Delivery Management at £18k to £35k a month. Averaging them into an organisation-wide health percentage destroys the two properties that make the instrument useful, per team and per card, and it quietly rewards generous scoring, so the team marking itself most honestly looks worst. Report the cards as cards. If the board wants one line, give it the list of cards that have been red or worsening for three consecutive months, because those are the ones that already carry an owner at management level and a named change in the next quarter's roadmap. It is a shorter list than a percentage and somebody can actually act on it.

Treat it as a line of sight failure and fix it at the epic rather than with a briefing. That card asks people to agree with a statement like "I know which outcome my current work rolls up to and what it is worth", and a red on it is common in a first month. In the worked example, four of nine people scored it zero and all four were developers. The product manager put the outcome name and its share of the currency target at the top of every epic, a small and structural action. The card came back amber and improving the next month, and green in month three.

The instrument stays the same and three cards change wording. Work arriving ready is scored on the outcome ticket instead of an attached story, because stories and chapters do not exist in that mode. Ask whether the ticket carries the outcome's currency share, the key user journeys and the test requirements, or whether you are filling the gaps by guessing. Swap the codebase-fear card for a verification card, "I can tell whether what the model produced works, not just that it ran", since that is where AI-native teams fail quietly. Predictability and value confidence stay exactly as written. When a team changes mode, re-word once, mark the break on the chart and treat the next month as a fresh baseline.