The Gemba Walk for Designing Software

The Gemba Walk is a common lean practice for understanding a current process as-is before taking any action to improve that process. Traditionally, you'd see this in lean manufacturing, where you'd walk through a process, in-person, to understand the purpose, process, and people involved in creating some sort of value or product.

For whatever reason, the "Gemba Walk" is dismissed more or less from lean software engineering as a means of walking the value chain of the software development process. I'm dubious about this - with all new clients, I walk the value chain from concept to cash.

But that's not the walk what I'm referring to. Not walking the software delivery process, but walking the process for whom the software we're building.

Traditional Gemba Walk

Gemba (or genba) is a term that refers to the place where work is done. The idea behind a Gemba Walk is to literally go to where the work is done, inspect, and understand the actual physical process happening in order to make any sort of process improvements.

Rather than discussing how to improve a shipment packing process in a sterile conference room on a whiteboard, you first do a Gemba Walk. The walk consists of three parts:

1. Go See
2. Ask Why
3. Show Respect

The goal is not to put blame on any one person for why the process is bad, but to fully understand (with respect) the people, process, and purpose. During the walk, we don't talk about any future improvements or anything of the like. Just focus on understanding.

You'll often do two Gemba Walks, where the first just to generate the value stream map, and the second to understand how well the value stream performs (see Value Stream Mapping for more).

There's way more to this practice, but let's look at how a Gemba Walk applies to software development.

Gemba Walks for Designing Software

During a Gemba Walk, I'm faced with many different "truths" to a process:

1. What managements believes/wants the process to be
2. What the process is documented to be
3. What we aspire for the process to be
4. What the process actually is

We build software for a purpose. And to fully achieve that purpose, we need to have a deep understanding of the problem we're trying to solve. We can help this understanding by having a product owner or subject matter expert or domain expert, but in my experience, those people only really give us the information for #1-#3 above. We don't see what the existing process actually is.

Seeing, especially with outside eyes, and removing inattentional blindness is absolutely critical to building software that actually solves the underlying problem. It's not enough to just ask the 5 whys. We have to see the process we're trying to improve. We'll completely miss the deeper level of understanding that's so critical to building software that can truly transform an organization.

Inattentional blindness is one of the leading factors for bad requirements and rework, in my experience. Someone inside of a process all day doesn't notice that that simple 3-step process is actually 10 steps. Or they might describe the process only in terms of the exceptional cases, instead of the typical case. Or skip over all of the manual steps they perform and only describe their process in terms of interfacing with their existing legacy system. Or the process is not in any one person's head, but in everyone's. I've been on multiple Gemba Walks where the client itself argues amongst themselves about the process and they learn what their process actually is.

You can't do a Gemba Walk without the 3rd pillar - Show Respect. The Gemba Walk is not about me "not believing" or "not trusting" the domain expert, and it's important that they understand this as well. It's not a judgement on their ability to explain. Some things just can't be verbally explained, and having many eyes on a process results in the greatest understanding.

Gemba Walk in Practice

My Gemba Walks are the very first thing I do on a new project. Kickoffs aren't just about meet and greets, I need to see and understand the problem at hand to provide the appropriate context for what I'm about to build. It's so important that we at Headspring insist on doing these walks, at the start of a project and at the start of any new area of software we're building.

Besides just understanding the process, the second part (looking for improvements), is focused on how the software we're building can improve that process. I'm also looking at ways to improve the process without software as well, because any software I don't write is software I don't have to maintain.

In the second walk, I'm focusing on process improvements, specifically:

• How long does it take you to perform this step?
• How often do you do this?
• How after you're done until the next step?
• Do you do one-at-a-time, or do you batch up work?
• What are the exceptional cases?
• Look for the Lean wastes
• What is the value (monetary/time/etc) of the work?

I carry a little notepad to write down the steps and answers to these (and more) questions as we walk. I can't keep everything in my head, so after the walk we'll go back and review to make sure our collective understanding was the same, capturing the results in a more permanent format.

When trying to show the value of your software, it's great to have that empirical data to show improvements (lead time for acquisitions went from 90 days to 7, etc.) and the Gemba Walk provides the means for doing so. I'm looking at lead time, cycle time, and throughput. It doesn't have to be 100% accurate, but it can give us that extra set of information for management to fully understand the potential and realized value of their software.

So, as software developers, we have to get out of our chairs and go to the work being done if we want to build applications and systems that can truly transform an organization. Without a Gemba Walk, we're merely guessing.