“Gemba” is a Japanese word that means “go see by yourself” and is used in Kaizen. According to Investopedia, Kaizen is a Japanese business philosophy regarding the processes that continuously improve operations and involve all employees. Kaizen is used to implement Lean Manufacturing and was highly popularized in Japan by Toyota and its continuous improvement model. Gemba is one of the principles that are used to implement this methodology. But what does the term Gemba mean exactly? The translation from Japanese, which is “go see for yourself,” doesn’t explain very well the true meaning of this word. I think the best way to describe it is by using clear examples.
The Malayan Invasion
One of my favorite and more dramatic examples would be the Malayan British Peninsula take-over in December of 1941 by the Japanese Army using bicycles. Colonel Masanobu Tsuji was in charge of planning this invasion. It is worth mentioning that the Japanese already had plenty of spies in the peninsula that informed the Japanese command of every movement and resource of the British Army. However, Coronel Tsuji decided to look by himself the terrain, so in October of 1941, he made a recognizance trip. He observed that the Malayan roads were well pavemented; there were also many bridges along the invasion pathway. This last fact made vehicles a problem because they could not have been moved if the British Army destroyed the bridges as they retreated. The disembarking site was quite far away from the target, which meant they needed to move fast to avoid a rapid response.
Tsuji also observed something else, the abundance of bicycles in the area, which prompted the idea of using this type of transportation during the invasion. The roads were well suited for the bicycles. If the bridges were destroyed, the soldiers could easily transport the bikes on their shoulders. Finally, they didn’t need to take the bicycles all the way from Japan because they were already there. The soldiers just needed to steal the bicycles from the Malayans. Needless to say, the invasion was a complete success. When Churchill received the news, he stated,
“It was the worst disaster and the largest capitulation in British history… In all the war, I never received a more direct shock.”
And that is how a dramatic story ends. But then a question arises from this tale: “What would have happened if Tsuji had not seen with his own eyes the enemy’s territory?”
Genba at work
How this story relates to our intended purpose of gathering information for software requirements? In the business of gathering information, the main problem is to deliver the feature as needed. There is always a gap between what the user needs and what the software development team delivers. Here is where Agile helps by allowing us to talk directly with our stakeholders to inquire and resolve any question. However, the gathering of information goes beyond asking for the feature from our target user or stakeholder. There is a high probability of making a wrong interpretation between our understanding of the problem and our end-users reality. One of my first bosses used to ask me before I started any feature development: “Did you see it for yourself?” This question is exactly what Colonel Tsuji had in his mind when he went to visit the Malayan Peninsula. He needed to see the terrain, the bridges, the bicycles, the problems, and the possible solutions in his case. In my case, the question meant that if I were going to create a report for the poultry inventory to load trucks, I should go to the warehouse and actually see the people loading the trucks with my own eyes. The trucks were loaded in the delivery order, starting from the back with the last orders to be delivered and finishing with the front with the first orders. The report had to be printed in exactly this order using the clients’ addresses as reference. Problems and solutions may arise from visits to the actual site, but this knowledge must be assessed from a closer look at the terrain, just like Tsuji did.
I learned two lessons from these experiences. The first one: The processes may differ from what you imagine and what they actually are when you see them in action. The second: Never use nice shoes when researching your features in a production plant because the floor may be flooded with water and poultry blood. It might not be nearly as dramatic as the British army defeat, but I still remember the passing of my favorite shoes with some pain.
Here We go Again
Over the years, these kinds of experiences have happened to me several times. I became highly aware of the necessity of researching directly from the people who were using the features. The instructions that were followed for everybody on the teams that I worked with were to research the feature as if you were the person to execute the function when this person was going on vacation. If you can do it as this person does it, you can define the feature. Some people would say that this kind of research takes a lot of time; however, the cost of not doing it may be much higher. If Colonel Tsuji wouldn’t have visited the site, what would have happened with the invasion? We can speculate many theories; however, the bicycle solution wouldn´t have been a solution, which was cost-effective and indeed logistically very clever. In our case, the development of a feature from their concept to the final delivery is costly, and delivering a function that does not do the job is a complete loss, not only of money but also of credibility. When the stakeholders lose credibility, the whole process becomes endangered. Thus, “go see by yourself” –Gemba, it is really the safest way to go.
This concept is widely used in lean management, not only in lean manufacturing. I’ve seen, with my own eyes, three companies that implemented this concept to train their executives. A month or so training consisted of visiting all the company areas, even the delivery process, which meant that the trainee had to see how the trucks were loaded; how the product was delivered; they talked with clients; the asked for orders; from there they went all the way back to the warehouse. Once the new-minted executives learned and saw what the company meant for every employee, for every client, for every middle manager, then they were ready to apply their knowledge and implement successful policies and make wise decisions.
The last time I actually made software from scratch to implement a meaningful feature was for a physical inventory process using barcodes. Before I started designing the features, I did the inventory with the audit department. I asked to be in the process not as an observer but as an active participant, and I was given a small part of the store to count. The result from the exercise was nothing of what I had pictured in my mind. I realized that the size of the products mattered; I saw the products, and for me, all looked the same, but no, they were different by half an inch or so, labeling was critical; another problem was products on transit: the warehouses may have delivered product that was on the way to other stores. This product would take a day or so to go into the warehouses to be counted.
By doing this exercise, I became aware of many details that I would have not otherwise realized: people would not have told me, not on purpose, of course. When people perform a task repeatedly, some details become common knowledge, so when someone else asks these details, they just get hidden somewhere behind people’s brains along with what they had for breakfast a week ago.
To Sum Up
But going and seeing with your own eyes does not solve the problem by itself. The functionality and the applications can be overwhelmingly huge; the person that is doing the research is not the one that is creating the apps. Here is where good user stories come into play: a good user story is the one that clearly states the definition of done and the one that clearly defines the type of test that should be performed over the features. Product owners and their teams become the cornerstone to a good application. This person will define the epics, the stories, and tests that can be implemented to have a minimum viable product. Thus, it starts with good research and follows with a good definition of user stories. The path to success continues, these are just the first two steps, but that is another chapter in the Agile way of life’s book. It is important to mention that Colonel Tsuji did not execute the plan for the Malayan Peninsula invasion. General Tomoyuki Yamashita invaded and created the final strategy using the intelligence and ideas proposed by Tsuji and some more from his own assessments. Here we have a perfect example of what teamwork means between a good product owner and scrum master, and here is where our story ends and with the following quote.
“Reality Wins” –by Dan Rawsthorn, as he wrote on my copy of his book “Exploring Scrum: The Fundamentals”