As a QA engineer, I strongly believe that Gemba is a great opportunity for understanding your product. It helps to answer the question: “Am I doing bullshit or not?” Today I want to tell you more about its advantages and the insights that we got after visiting a pizzeria.
Gemba (Japanese 現場), Genchi Genbutsu (Japanese 現地現物) translates as “the real location, real thing” (meaning “the situation onsite”) denotes an approach specific to the Japanese kaizen management practice. According to it, it is necessary to come to Gemba — the place where the work process is performed, collect the facts, and make a decision directly on the spot in order to fully understand the situation.
I will start from the beginning to talk about why we need Gemba. Our product is the Dodo IS — information system, which unites all parts of our business:
· B2C (website and mobile apps);
· B2B (apps for shift control, point of sale management, warehouse balances, cash register interfaces, etc.)
It is quite difficult to create a high-quality product without knowing how it is used and who works with it. To assess the quality, we use 2 approaches:
· Eat your own dog food (for B2C) — a method of probing user experience when employees in a company use the products they produce. This approach is quite easy to use in real life. Like all customers, we order pizza when we are going by subway, walking in the rain, at -30C, or lying on the beach. Flaws, bugs, and bad UX are easy to feel.
· Gemba (for B2B) — a method of probing user experience when employees in a company use the products they develop. But in our case, it implies a deeper immersion into the product and the environment because you cannot go to work as a pizza maker at any time or become a manager in a pizzeria in order to understand how the system works.
No one has to, but everyone can. Going to Gemba is a right. No one forbids going to a pizzeria, coffee shop, or doner, but no one forces you either. Testers, developers, and product managers can go there. The main thing about it is the difference in focus.
· For products, this is one of the main activities. In a pizzeria, they find ideas, get insights, and can see the whole picture. Product managers use Gemba for hypothesis testing, in-depth interviews, customer development, customer journey mapping, and so on.
· Developers and QA engineers go to Gemba with the aim of “touching” the product they have made. A side effect of this is uncontrolled insights and ideas for product development. After returning from Gemba, not a single engineer said that it was a waste of time.
Going to Gemba is easy to implement. The developer goes to a pizzeria or coffee shop and uses the product. That’s all. This is easier than simulating a pizzeria or coffee shop in the office, inviting actual employees of the pizzeria, and fictitiously demonstrating their user experience in the conditions of a spherical cow in a vacuum.
There can be insights about business process automation. One of our Android developers went to Gemba and saw what the marking process was like. Employees were COUNTING IN HEAD and HANDWRITING labels with the expiry dates of the products. For each product, they count and write the start date of defrosting, the validity date, and the expiry date. Product labeling is a boring routine process in which careless mistakes constantly occur.
The developer realized that this was absolute bullshit. To automate this was “half an hour of a programmer’s work,” so he went ahead and automated it. This is how the mobile application for printing labels was born. The operation is reduced to the following: an employee selects a heading on the tablet, makes a tap, and a label with all the terms is printed, that’s it.
In Gemba, the defects of the product are more evident. Dodo IS has features for auditing. These features were developed for the tablet. During the audit, an employee can enter data directly into the tablet, but it is too cold in the freezer and refrigerator, the tablet refuses to work, sometimes the connection is lost, and the interface itself is not very convenient. That’s why the results of the audit are written down on paper, and entered into Dodo IS later. Double work!
Before rewriting the interface of the auditor, the development team went to night revisions in order to understand the process. They returned with ideas for improvement. For example, if the connection is lost, then the input of information must be made asynchronous, the data must be stored in local storage, and sent to the server when the connection is restored.
In a pizzeria, you can see the working conditions in which the applications are used. One of the development teams created Pizzeria Tracking. It's a set of six tablets displaying the pizza, the recipe with ingredients added or removed, and the location of the pizza in the kitchen at the moment.
The team turned on the new tracking in one of the pizzerias and went to see how it worked. In the pizzeria, the developers saw that pizza makers were in a hurry to tap on the tablet very quickly, and they were doing it with their hands dirty with sauce or cheese. As a result, it was not always possible to tap on the tablet the first time. The team was very surprised. Surely, in the office, we clicked on the tablet with clean hands and there was no hurry. After going to Gemba, the team got back and redesigned the tap method in such a way, so that users could mark products even when they were doing it very quickly and with dirty hands.
After going to a pizzeria, you offer the most suitable solutions. You know how the business works, how processes are set up in real life. When the business comes to you with a problem, having a broad view of the business and knowing how the system works inside, you can offer a simpler or more systematic solution to the problem.
You can see how the inaccessibility or complex interface of the product affects employees and customers. You are standing at the checkout, and it is getting slow, there is a queue, and some customers are getting nervous or leaving. Without this valuable knowledge, the developer might not have noticed the increase in response latency.
I have never been able to imagine any disadvantages of this approach except for one: our developers who go to Gemba are not financially justified. We receive a lot of feedback that we are doing expensive bullshit, we are paying a developer for spinning pizza, distracting him from work and his immediate tasks. My opinion is simple — we pay developers for their work, for their product. They just perform work in a pizzeria, look at the product with the eyes of a client and answer themselves in real-time to the question “Have we done bullshit or not?”.
At Dodo Brands, going to Gemba is a common thing. This is a cool experience, which helps us to check that we make a high-quality product.
I liked how one of our developers wrote: “For me, as a developer who has never gone to Gemba, a developer who went to Gemba looks like a bearer of secret knowledge. During a discussion at a general meeting, such a person may say: “The feature you propose will not work, because I was in a pizzeria and saw how it really was there. In general, you need to go to Gemba at least for this”.
Two most common questions about Gemba and IT people
Do you go to a pizzeria without a medical certificate? No way. You can’t go to Gemba without a medical certificate. We are normal people and strictly observe the standards of cleanliness. There can be no exceptions. Before you go to Gemba, you need to pass a medical examination and obtain the appropriate work permit.
Do developers need to clean the toilets? We go to pizzerias in order to understand how our product works in “combat” conditions. But when we come to a pizzeria, we become full-fledged trainees, so we can still be asked to clean up, and we will do it.