An API delivery problem can look different in a process map than it does to the people doing the work. A gemba walk closes that gap by observing work at the “actual place” it happens. Use firsthand observation to establish current conditions before deciding what to change. section 2.4
To investigate a problem:
- Interview colleagues about roadblocks, then ask permission to watch them perform the task. Sit with them, use screen sharing, or request a recording when work is remote. section 2.4
- Record the tools and practices people use—and those they do not. Observe relevant meetings and examine defect tickets, incident tickets, and other records. section 2.4
- Ask why, when, who, what, and how. Take notes without suggesting improvements during the observation. Use verified facts to describe where the problem occurs, how long it lasts, and how often it happens. section 2.4
A stalled API design step
A Design & Auto-Check step has an LT of four days but a TT of three hours: work sits idle for much of the elapsed time. Observe the step to find out why and whether wasteful activities contribute. The resulting improvement might change how the team works or is structured rather than add automation; the aim is better process performance and customer value. section 2.11
