Team Ember's Inspect & Adapt: One Chart, Four Problems, Three Hours
PI 6 has ended for Team Ember (six engineers). Of five PI objectives, four were fully met and one was 60% met. Planned business value was 40 and realized was 34. The System Demo is done, and Inspect & Adapt day allows three hours for six teams: 40 minutes of PI System Demo, 30 minutes of measurement, a 20-minute break, 45 minutes for problem solving, and 45 minutes for 'retros and next-PI action planning'. Four candidate problems surfaced: a vendor dependency blocked three stories for a combined 22 days; integration test environments were down 6 of the 10 days of Iteration 4; the PO was on leave two weeks and the backlog went stale; the team's stand-ups keep drifting to 30 minutes. The RTE asks Ember's SM to 'just show the velocity chart, five minutes max', to skip the team retrospective 'since we already do problem solving', and to approve running all six teams' retro notes through a generative AI tool that will auto-select the ART's top problem.
1. What does the SM bring to Inspect & Adapt, and how do you respond to 'just the velocity chart'?
Read the worked answer
Inspect & Adapt is for inspecting how the ART is working, not for a performance report on teams.
Velocity alone is the wrong artifact. It measures output in a unit that only has meaning inside one team - story points are not comparable across Ember and the other five teams, so a velocity chart invites exactly the cross-team comparison that is meaningless and demoralizing. It also says nothing about value, quality, or flow.
Bring instead:
- Value: the PI objectives with planned versus actual business value. Ember's predictability measure is 34/40 = 85%, which is a meaningful number and a fair one.
- Flow: blocked time (22 days on the vendor), environment downtime, WIP at iteration boundaries, carry-over by iteration.
- Quality: defects found versus escaped, and anything deferred into the IP iteration.
- Qualitative: what helped, what got in the way, in the team's own words.
On the request: put velocity on the slide as one input next to the value and flow data - not as the headline. And negotiate the time honestly: five minutes for six teams is a status roll-up, not an inspection. If the RTE wants inspection, the artifacts above need more than five minutes each. Say so in advance, not on the day.
2. Which of the four candidate problems should enter the problem-solving workshop, and how would you run 45 minutes?
Read the worked answer
Selection is not 'biggest number wins'. Criteria: the ART can actually act on it, there is data behind it, and an owner is in the room.
- Vendor dependency (22 days blocked): the largest, but much of the resolution sits with an external party. The actionable root cause may be 'we identified it on day 4, not day 1' - which the ART can own.
- Environment outages (6 of 10 days): directly within the ART's sphere of influence, data exists, and it compounds everything else - it likely contributed to Ember's 60% objective. This is my pick.
- PO on leave: real, and partly an ART-level planning failure (single point of failure, no proxy coverage). Good second workshop.
- 30-minute stand-ups: a team-level coaching issue, not an ART problem-solving item.
Running 45 minutes - and first flagging to the RTE that 45 minutes for ART-wide root cause is thin:
- 5 min: present the data, no opinions.
- 10 min: 5-Whys or fishbone on the chosen problem only.
- 15 min: agree one or two root causes, resist listing five.
- 15 min: SMART actions with a named owner and a date, entered into the ART backlog before people leave the room.
The failure mode of this workshop is a good conversation with no owners. One problem, one or two root causes, actions that are tracked - or do not run it.
3. The RTE wants to skip the team retrospective and to auto-select the ART's top problem with generative AI. How do you respond to both?
Read the worked answer
These are the same risk wearing two hats: removing the people who own the improvement from the act of choosing it.
Skipping the team retrospective. Problem solving and the retrospective are not substitutes. I&A addresses ART-level systemic issues; the team retrospective is where Ember owns its own improvement backlog - stand-ups, WIP, refinement habits - and where the psychological safety that makes candour possible actually lives. Ember is the team that surfaced four problems in a PI; that candour is the asset. Cancelling the retro saves 45 minutes and costs the mechanism. Keep a timeboxed team retro, even a 30-minute one, and take its results into next PI Planning.
The AI tool. Its real value is clustering: six teams' notes produce far more themes than 45 minutes can digest, and summarizing themes saves the ART time. That is legitimate. What is not legitimate is auto-selecting the problem, because selection requires ownership - whoever picks the problem must be able to act on it and live with the result.
Also: retro notes are among the most sensitive data a team produces. Feeding named, candid notes into an external tool without consent will change what people write next time, and the loss will never show up in a metric. Require anonymized or summarized input, confirm the data-handling policy, have a human group and validate the themes, and let the ART choose. The AI can propose; the ART must dispose.