Knowledge
Gemba Walks
You can't improve work you haven't observed. A Gemba Walk puts you in the room where work happens so you see reality instead of reports.
Overview
A Gemba walk is the practice of observing work where it happens. The concept comes from the Toyota Production System, where “gemba” (現場) means “the actual place.” Leaders go to the factory floor to see reality firsthand rather than relying on indirect hearsay.
In software development, this means joining team events—sprint planning, retrospectives, refinement sessions, or discovery collaborations—to see how work actually flows. The goal is to understand processes and identify opportunities for improvement, not to evaluate people.
This guide walks you through a simple four-step approach to conducting an effective Gemba Walk: Prepare → Observe → Behave → Debrief.
| Phase | Key Actions |
|---|---|
| Prepare | Pick one event, notify the team, and define 2-3 focus areas |
| Observe | Watch for participation, how work is framed, psychological safety |
| Behave | Stay quiet, take notes, save feedback for later |
| Debrief | Share observations, ask questions, explore improvements together |
1. PREPARE: How to get ready
Before the walk, clarify what you’re trying to learn.
Do this:
- Pick one event to observe (don’t try to cover everything at once)
- Let the team know you’ll be joining and why—frame it as process learning, not a performance review
- Prepare 2-3 focus areas or questions you want to explore
- Have a way to take notes (document, notepad, whatever works)
Example: You’re joining a sprint planning session. Your focus areas might be: How does the team discuss capacity? How are stories broken down? Who participates in estimation?
2. OBSERVE: What to Look For
Observe both healthy patterns and potential friction points. Here are key indicators:
Participation & Dynamics
| Healthy Signals | Warning Signs |
|---|---|
| Multiple voices contributing | Same 2-3 people carry the conversation |
| People build on each other’s ideas | Side conversations or disengagement |
| Respectful disagreement happens | Silence when asked for input |
| Questions are welcomed | People seem hesitant to speak up |
How Work Is Discussed
| Healthy Signals | Warning Signs |
|---|---|
| Conversations include “why” and “for whom” | Work described only in technical tasks |
| Outcomes and impact are mentioned | Focus is purely on output (“build X”) |
| Dependencies and risks surface naturally | Surprises and blockers aren’t anticipated |
| Stories reference user or business value | Acceptance criteria are vague or missing |
Psychological Safety
| Healthy Signals | Warning Signs |
|---|---|
| People admit when they don’t know something | Questions are deflected or dismissed |
| Mistakes are discussed openly | Blame or defensiveness when issues arise |
| Team members ask for help | People work in isolation |
| Leadership accepts accountability | Problems are pushed down |
Example: During the sprint planning session, you notice that estimation happens quickly with little discussion—two senior engineers call out numbers, and everyone agrees. You jot down: “Estimation felt rushed. Junior team members didn’t participate. Worth exploring if they feel comfortable challenging estimates.”
3. BEHAVE: Etiquette During a Gemba Walk
A good Gemba Walk requires restraint on the observer’s part. Remember, it’s your job to observe, not to participate or fix things in the moment.
Do this:
- Stay quiet and off to the side (camera off or in a corner for digital)
- Take notes on what you see, not judgments about it
- If you ask a question, keep it clarifying—don’t redirect the conversation
- Save suggestions and feedback for the debrief
Don’t do this:
- Offer opinions or solutions during the event
- Interrupt the flow to ask detailed questions
- Make facial expressions or reactions that influence the room
- Turn it into a coaching session mid-event
Example: You see the team skip over a story that seems unclear. You want to ask why, but instead you note: “Story #4532 moved to sprint without discussion—was it refined earlier or did the team assume clarity?” You’ll ask in the debrief.
4. Debrief
The debrief is where value gets created. Share your observations with the team and explore improvements together.
Timing: Schedule the debrief within a day or two of the observation, ideally, while it’s fresh.
Structure:
- Thank the team for letting you observe
- Share what you saw (observations, not conclusions)
- Ask questions to check your understanding
- Explore together what, if anything, the team wants to change
- Agree on next steps if any action is warranted
Keep it balanced: Share healthy patterns you observed, not just problems. Teams need to know what’s working.
Resist solutions mode: Your job is to surface observations, not prescribe fixes. Bringing problems to the team lets them exercise their creativity and agency in solving them—that’s the behavior you want to reinforce.
Example: In your debrief, you say: “I noticed estimation moved quickly and the senior folks did most of the calling out. I’m curious—do others feel like they have space to weigh in, or does the current approach work for everyone?” This opens a conversation without assigning blame.
Common Events to Observe
- Sprint Planning — How does the team commit to work? Who participates?
- Backlog Refinement — How are stories written and sized? Is value articulated?
- Retrospectives — Does the team surface real issues? Do actions get follow-through?
- Daily Standups — Are updates meaningful or rote? Are blockers addressed?
- Discovery/Design Sessions — How do product, design, and engineering collaborate?
Focus on processes, not people. Document what you see. Return often—patterns emerge over multiple observations.
Related
- SECI Model — Gemba Walks are a Socialization practice, transferring tacit knowledge through shared firsthand observation
- Experiential Learning Cycle — the walk-observe-debrief structure mirrors Kolb’s experience-reflect-conceptualize-experiment cycle