Gemba walk

What it is

Gemba walks come from the Toyota Production System. Taiichi Ohno — the architect of TPS — codified the practice with the injunction to “go see, ask why, show respect.” Masaaki Imai adapted the technique for Western audiences in Gemba Kaizen (McGraw-Hill, 1997), which remains the canonical English-language reference. The underlying claim is simple: managers and improvement teams tend to work from abstractions — reports, dashboards, sprint metrics — and the abstractions always lag reality. Going to the gemba closes the gap.

For a software team, the gemba is wherever a unit of work is actually being produced, moved, deployed, tested or supported. A facilitator preparing for a workshop does a gemba walk to collect seed observations — things the team has normalized but a fresh observer immediately notices. An architect validating a design does a gemba walk to watch the current system being operated, not just described in docs. A product owner investigating customer feedback does a gemba walk to sit with support staff for a day and hear what customers actually say.

The practice has three rules, which are all about discipline rather than technique:

1. Go see the work — don’t rely on a report.
2. Ask why — not to interrogate, but to understand the reasons behind what you observe.
3. Show respect — the gemba belongs to the people doing the work. You are a guest, not an auditor.

The output of a gemba walk is observations, questions and hotspots — not conclusions. Conclusions come later, in whatever structured session follows.

When to use it

Reach for a gemba walk when:

• You’re preparing to facilitate a workshop and want fresh seed material. A facilitator who has just spent an hour watching a real deploy will have observations the team doesn’t yet see. The automation workshop explicitly calls for a pre-workshop gemba walk.
• The team is stuck on a problem they’ve been describing to you and the descriptions don’t quite add up. Go watch the problem happen.
• You’re new to a team or product and need to calibrate your mental model against reality. A half-day gemba walk is more effective than a week of doc-reading.
• A reported metric seems wrong (too high, too low, or moving in an unexpected direction). The dashboard might be right; it might be the metric definition that’s wrong. Gemba is how you check.
• A design or process change landed recently and you want to see whether it’s being used as intended. Adoption is where good ideas go to die quietly.

Don’t reach for a gemba walk when:

• The problem is already well-characterized and the work is to fix it, not to understand it. Move to 5 Whys, fishbone or a direct technical intervention.
• You’re unable to observe respectfully — the team is in crunch, a postmortem is still raw, or trust with the team isn’t established. Wait. A gemba walk that feels like surveillance destroys the trust required for the next one to produce honest data.
• The work is genuinely private (customer data, confidential decisions, sensitive HR conversations). Gemba is about observing the work, not everything that happens in the vicinity of the work.

How to run it

Total time: 1–3 hours. Less than an hour and you’ll only catch the surface; more than three and you exceed most observers’ useful attention budget.

Decide what you’re going to observe (10 min). A gemba walk has one subject. “Watch the deploy pipeline” is fine. “Watch everything the team does” is not. Pick one unit of work, one system, one shift, one customer-support session. Write it down. Share it with whoever you’re shadowing.

Prep the person or team you’re observing (5 min). Explain the practice. “I’m not here to evaluate. I’m here to watch the work so I can understand it. I’ll ask questions when I don’t understand something. Pretend I’m not here except when I ask.” Most developers and operators accept this readily once they understand it isn’t an audit.

Watch and take notes (60–120 min). Notes should be concrete — what actually happened, in what order, with what tools, involving what people, waiting for what. Not “the build was slow.” Rather: “The build started at 14:02. At 14:11 it paused for 3 minutes waiting on the test suite. The developer switched to Slack during the wait. At 14:21 it failed because the lint step required an import change; the developer fixed it and re-ran at 14:26.” The specificity is the point.

Organize notes under three headings:

• Observations — what actually happened. Neutral language, no judgments.
• Questions — things you didn’t understand, asked and heard answered, or didn’t get to ask.
• Hotspots — moments where something felt off (a wait, a manual step, a workaround, a confusion). These are the candidates for follow-up in the structured session that follows.

Ask why, gently, in-context (ongoing). The Toyota discipline is to ask why five times — not interrogatively, but to trace a surface observation down to its reason. The gemba-walk version of this is softer: when you see something notable, ask the person doing it “why is it that way?” Don’t argue with the answer. Accept it, write it down, and if it’s unsatisfying, ask again later or with a different operator.

Close the observation cleanly (5 min). Thank the person or team. Don’t deliver conclusions on the spot — your observations need time to settle. Promise to share what you do with them if it turns into action.

Consolidate within 24 hours (30 min). Write up the observations, questions and hotspots. Share them with the observed person or team first — a gemba walk that produces secret observations is an audit. They may have corrections; accept them. Then bring the consolidated material into whatever structured session comes next — a workshop, a design review, a retrospective, a 1:1.

Worked example

A facilitator is preparing to run an automation workshop for a six-person platform team. The readout shows heavy manual work in the release path but the team, when asked, can’t really articulate where the hours go. The facilitator schedules a 90-minute gemba walk the day before the workshop: sit next to the on-call engineer during the next scheduled release.

The notes afterward:

Total: 71 minutes of the engineer’s time, of which roughly 15 were actually “turning the wrench” (kicking off scripts and fixing the config). The other 56 minutes were waiting, looking things up, running manual checks, or recovering from a predictable config drift.

The facilitator arrives at the workshop the next morning with a list of concrete, specific, non-hypothetical candidates:

• The runbook being out of date
• The interactive prompt in the deploy script
• The config-flag wiki lookup
• The manual smoke-test checklist (6 items, twice per release)
• The “wait for QA go-ahead” handoff via Slack
• The staging-vs-prod config drift that caused the rerun

None of these would have been surfaced by asking the team in the abstract. The engineer had normalized every one of them. The workshop’s sticky-generation phase now has real seed material, which changes the whole tone of the session — from “what do we automate?” to “here are six things we saw yesterday, which one is highest ROI?”

Common failure modes

• Observing for too short. Thirty minutes catches the theater — the parts of the work the operator performs consciously. The normalized waste only shows up after forty-five minutes when the observer has stopped being interesting. Give the walk at least an hour.
• Asking leading questions. “Why do you still do this by hand?” puts the operator on the defensive. Better: “Can you walk me through what’s happening here?” The Toyota discipline is “ask why” but with genuine curiosity, not prosecutorial intent.
• Writing conclusions during the walk. The note that says “this is clearly broken” is a judgment, not an observation. Write what happened. Conclusions come later, with the full context.
• Skipping the consolidation and share-back. The observations never reach the people who could act on them, or the observed team finds out their work was discussed behind their backs. Either way, the next gemba walk is harder because trust is lower. Always share the consolidated notes with the observed team first.
• Running a gemba walk as substitute for a workshop. The walk produces observations; it doesn’t produce commitments. A gemba walk without a structured follow-up is anthropology. The walk is input into a workshop, retrospective, design session or 1:1 — not a replacement.
• Observing the wrong gemba. Watching the deploy script when the problem is actually in how stories enter the sprint produces irrelevant data. Match the gemba to the question you’re trying to answer.

References

In the playbook

• Automation workshop — explicitly uses a pre-workshop gemba walk to gather seed observations.
• 5 Whys — the follow-up technique when a gemba observation needs to trace down to root cause.
• Value stream mapping — pairs with a gemba walk so the map’s numbers match observed reality, not remembered reality.
• Journey mapping — the customer-experience complement to the internal gemba walk.

External references

• Masaaki Imai, Gemba Kaizen: A Commonsense Approach to a Continuous Improvement Strategy (McGraw-Hill, 2nd ed. 2012) — the canonical English-language reference.
• Jim Womack, Gemba Walks (Lean Enterprise Institute, 2nd ed. 2013) — a practitioner collection of short essays on the practice.
• Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988, translated 1988) — the origin text. Dense but foundational.
• Lean Enterprise Institute, Gemba walk — concise definitional reference.