Overview

Why these guides exist

The playbook’s chapters script the activities of delivery — the sequence a team follows from mobilization through production. But several of the moments that decide whether a team actually gets better can’t be scripted as chapter activities: the first day a team sits together, the session that maps a business end-to-end, the hard look at where an iteration’s effort really went and the weekly habit of testing what to build next. These guides cover those moments — forming the team, designing the domain, improving the work and learning what’s worth building.

The waste-walk trio is the featured case. A waste walk surfaces where effort is going — how much of the iteration was rework, how much was work a machine should have done, how much evaporated into meetings that didn’t produce anything. The readout is valuable on its own, but on its own it’s diagnosis without treatment. The rework, automation and planning workshops close that gap: each takes one category of waste, points you at the root cause and walks the team through to specific actions — named owners, measurable recovery.

The format for every workshop follows the pattern I described in My formula for running a successful workshop — goals, impact, audience, roles, pre-homework, agenda, exercises, action-item capture. That consistency matters. A facilitator who has run one of these will pick up the others without relearning the choreography. Continuous discovery is the deliberate exception: it’s a cadence rather than a session, and its guide reads accordingly.

The workshop suite

• Agile inception — the team’s first day together: Rasmusson’s ten questions turn a roster of names into a team with a shared picture of what they’re building and who for. Runs once, at the start, feeding Product vision and Product strategy. Guide under development.
• GembaKai readout — the gateway session a team runs at the close of an iteration of activity logging. Walk the readout deck, frame the productivity opportunity, separate what the team controls from what it influences, and pick the next workshop from the data. One-hour timebox.
• Rework workshop — for tracing rework hours back to their origin in the delivery pipeline. Four origin categories, 5 Whys or fishbone for root cause, A3 for systemic issues, event storming as a preventive follow-on.
• Automation workshop — for surfacing manual work the team has normalized. Five automation domains, cost × frequency × people, 2×2 ROI matrix with a Theory of Constraints overlay, scenario-list scoping of the first increment.
• Planning workshop — for finding meeting overhead, late decisions and external dependency friction. SWOT opener, meeting audit, strategic event storming on iteration decisions, Force Field Analysis on every committed action.
• Event storming workshop — for mapping a business process end-to-end with engineers, customers and subject-matter experts in the same room. The canonical Blueprinting-phase workshop; also the natural preventive follow-on when the rework workshop surfaces unclear business events as a root cause.

The standing practice

Continuous discovery is the one guide here that isn’t a workshop, and that’s the point. Workshops are sessions — they start, produce their outputs and end. Discovery is the weekly habit that keeps those outputs honest: the value map, the event map, the inception deck’s answers are all hypotheses, and hypotheses decay. The discovery guide covers the cadence — weekly customer touchpoints, a hypothesis log, the cheapest test that settles each question — that runs between every workshop on this page and decides what the next increment should be.

Picking the right workshop

Where you enter depends on where the team is. A team forming starts with the agile inception. A team opening a new domain or product increment starts with event storming. A team pursuing measurable improvement starts with the waste walk itself — an iteration of activity logging — because everything downstream is only as good as that data. And discovery runs weekly no matter which of these is in flight.

Within the improvement path, the GembaKai readout is the gateway: a one-hour session that walks the team through what the iteration’s logging actually showed and picks the follow-on workshop from the data, not from gut feel. The three waste-reduction workshops — rework, automation, planning — are its follow-ons, each targeting a category the readout surfaced.

If you’re responding to a waste-walk readout, run the workshop that matches the dominant category. If one category clearly dominates, run that workshop. If waste is spread evenly across the three, run them in sequence — usually rework first, because solving rework tends to eliminate the fix-meetings that were piling up inside the planning-waste number.

Here’s a rough heuristic:

• The team is meeting for the first time → run the agile inception. Alignment problems discovered in week six were almost always available for free on day one.
• You want measurable improvement but have no data yet → run a waste walk: an iteration of activity logging. The readout and every workshop downstream of it feed on this data — there’s no shortcut past collecting it.
• You just finished an iteration’s worth of activity logging → run the GembaKai readout. Don’t pick a workshop without the data backing it.
• Rework is the dominant color on the readout → run the rework workshop. It’s almost always the highest-leverage starting point because rework upstream turns into everything else downstream — manual validation, defensive meetings, blocked dependencies.
• Automation/manual hours dominate → run the automation workshop. Engineering time that should have been code but was clicks, copy-paste or manual deploys.
• Planning hours dominate → run the planning workshop. This is the hardest of the three waste-walk workshops because planning waste is diffuse — a hundred small things rather than one big one.
• All three are significant → rework first, then automation, then planning, at two-iteration intervals so each workshop has time to land real change before the next.
• You’re at the start of a new product increment (or a rework workshop traced back to unclear business events as the root cause) → run the event storming workshop. Not a waste-walk response; a design workshop that produces the shared event map the rest of the Blueprinting phase builds on.
• Every week, regardless of the above → continuous discovery isn’t picked; it runs. If the team is choosing between a workshop and this week’s customer touchpoint, something upstream is wrong — the touchpoint is not optional.

The process guide

The workshop guides call out specific techniques — SWOT, 5 Whys, fishbone, A3, pre-mortem, force-field analysis and others. Rather than redefine each one inside every workshop, the process guide collects them into a tool library with worked examples and authoritative references.

If you’re facilitating a workshop and hit a technique you’re not familiar with, click through from the workshop page — or start at the process guide and browse. If you’re already comfortable with the technique, the inline summary in the workshop is enough to keep moving.

How results land back in the readout

Every workshop produces an action-item list with owners, expected recovery, and a review date. That list doesn’t live in a meeting note somewhere — it tracks back to the same waste-walk data the workshop started with. Next iteration’s waste walk tells you whether the actions moved the number. If they did, the action closes and the team celebrates. If they didn’t, something was wrong with the root cause, the action, or the owner, and the next workshop has new material to work with.

Discovery runs the same loop on the what-to-build side: the hypothesis log tracks to increment selection, and the delivered increment’s outcomes tell you whether the evidence held. Same principle throughout — every guide’s output lands somewhere measurable, or it didn’t land.

The goal isn’t a perfect workshop. The goal is a team that gets measurably better at delivery, one cycle at a time.