What is a Gemba Walk?

Gemba - 現場, or Genba, means an “Actual place” in Japanese. Practitioners of Lean methods use Gemba walks to drive strategic objectives. Unlike typical western management models, where leaders are removed from the workers in their ivory offices, Lean encourages managers to go on Gemba to observe, learn, connect with the teams, and offer help. But what does one do on a Gemba walk, and how can Kanban practitioners benefit from this tool, besides getting some physical exercise?

How to do a Gemba walk?

Observe the facts, then ask why things happen the way they do. The Gemba walk is rooted in facts. What is happening at the place of work? How many people are overloaded, and how many are standing idle?

Step 1: Notify the team of what you’ll do ahead of time

We recommend letting the team know that a Gemba walk will be taking place. Not to put extra stress on them or cause any atypical, forced behavior, but so that they understand that the purpose of Gemba is the observation of how the process works on an everyday basis. Let the team know you’re open to a conversation!

Step 2: Be prepared

It’s a good idea to plan what aspects of the process you’ll be paying attention to, what questions you’d like to ask the team, what information you want. Although it will not always be possible to know the answer to these questions, their goal is to stop you from walking around aimlessly through the factory or office floor!

The best place to start when drawing a plan for your Gemba is to focus on the value stream. Follow the value stream in its actual steps across the floor to find improvement opportunities, and if you have not yet mapped it out, Gemba can help in doing so. Look at what happens at the process steps that bring value to your customer, and learn from the team members themselves, how their work could be made lighter and more effective.

Step 3: Go where work happens and observe it

The crucial thing to do here: go to the place where work happens and observe to get a better grasp of the process by seeing it for yourself. Though it’s the fundamental step here, as shown - it shouldn’t necessarily be the first thing you do, if you’re keeping the best possible outcomes in mind.

Step 4: Respect the team. Don’t judge

An important thing not to do is to go and judge or check up on workers. Gemba walk is not an excuse to spy on employees sleeping on the job, although that is a no-no. A leader on a Gemba walk would ask themselves why are people sleeping on the job, are they overworked, or have they no assignments? Respecting the people working with or for you is just one of the points where Gemba and Agile align perfectly. The Gemba walk should give you further insight into what you already saw on your Kanban board. If there are bottlenecks on your board, you should also come across them in practice.

Step 5: Knowledge work - where is Gemba?

There is value in visiting, e.g. a software development team’s office to see what they’re up to and ask them for thoughts on how the process works. It will often tell a lot about if the process is working or not. But in many cases, you will get more information by looking at that team’s Kanban board. That’s because a Kanban board will often become the representation of an actual place of work - Gemba - for knowledge-based processes.

In creative and intangible use case scenarios, such as software development, content creation, or much of academic research, while people are, of course, usually sitting at their designated workplaces, the actual work process happens in their heads, not on their desks. That is where a visual Kanban board comes to help, presenting their entire process in steps, letting you peek into the value stream. It shows you what stage they’re at, which parts are causing the most difficulty, where they may need help, etc.

Step 6: Conclude and make changes

If you were to omit this final step, your Gemba would only be an intrusion of the team’s workspace. Once you’ve learned how they work, what obstacles they meet, and what impedes the value stream, create an action plan to change that. Make it as detailed as you can for the changes to be possible to implement. Don’t stop by stating: you need to pay more attention to how you test your code. Be specific, set concrete goals, and follow up on whether the team meets them.

Therefore, it makes sense to limit your Gemba to one aspect of work per session - otherwise, the action plan will become too big to handle, and no changes will happen. Better an incremental change creep than a revolution that damages morale, production, and profit all at once.

What to look out for?

While there is no silver bullet to doing a Gemba walk right, here are a few key points, paying attention to which can help:

• Is work carried out in a standardized fashion, or are people just picking up random tasks?
• How clean is the work environment, how free of clutter is it, and how often are workers bumping into items that shouldn’t be there? That is true of both physical and virtual environments - do employees have to wade through a lot of irrelevant information to find the item they need?
• Is the work environment safe, or are there any potentially dangerous accidents waiting to happen? Do junior developers have access to your production code, are private data documents held in unlocked cabinets, etc.
• Is there a lot of motion happening without much results produced? Look out for unnecessary traveling, walking, meetings, or reporting.
• Talk to workers, be interested. Why do they do what they do? What problems do they experience, which may not be apparent to an onlooker? Yes, sometimes you just need to ask!
• Is there a lot of idle time in the process? How much time are people spending just waiting for things to happen, for the previous process step to complete, for a task to be authorized, etc.?
• Are workers waiting on machines, or are machines waiting for workers? While the latter is acceptable, the former never should be. Giving the team access to fast, robust tools is not only a talking point aimed at attracting new workers to the company - they are necessary for them to keep your process efficient and frustration-free.
• Are designated areas marked, or - in a knowledge-based scenario - is access to information readily available for workers? Do they know where to go for information on what or whom to ask for assistance?

Whatever you do, do not send your subordinate to go and observe for you. You, the leader, should be looking at what exactly is happening where your product is made. You will probably save a lot of money with the improvements it will help you bring, and you might get to know your team a little better. Happy walking!