Hyper-Gemba
Gemba is Japanese term meaning the place where the truth can be found. It is only at the gemba that you learn “unknown unknowns”.
In quality management, gemba means the manufacturing floor and the idea is that if a problem occurs, the engineers must go there to understand the full impact of the problem using all their senses to gather and process data. Unlike focus groups and surveys, gemba visits are not scripted or bound by what we want to ask.
From the entry Gemba in Wikipedia
A few weeks ago I got familiar with the term Gemba. Another simple common-sense idea, which (in the words of Voltaire) is not so common. At least not when you consider management in software development organizations.
I don’t have any statistics, but my impression is that decisions made by management are rarely the result of managers going to the place where things really happen in order to understand the real problems. Some of these decisions prove to be great. Others prove to be a disaster. And of course there are a great number of decisions that fall between these two ends of the spectrum. The point is, that the result of making decisions without sensing the real problem is accidental. This is just like betting: sometimes you win, but there’s a greater chance you’ll lose.
In order to make the best possible decision you have to sense what’s really going on. How can you decide whether to hire more people or not without getting a sense of the workload people are under? How can you decide to sign more contracts without realizing how this will affect your workers? How can you say that “things are running just fine” without spending any time with the people who actually do the work?
The answer is simple: you can’t!
So, as a corrective action, I came up with the idea of Hyper-Gemba. Don’t bother to ask me if I saw it being implemented anywhere. I didn’t. But I still have hope.
If Gemba is the place where things happen, Hyper-Gemba is the mental place where things happen. When you go to the Hyper-Gemba, you are not just using your senses to gather and process data about the problem as an observer. In Hyper-Gemba you experience the problem.
A Hyper-Gemba visit is not really a visit. It’s more like switching roles. Role playing is a well-known technique in psychology, conflict resolution, and learning. It can be a very interesting experience. Taking the actual role of a person and really experiencing “his side of the story” is even more enlightening.
I might be naïve, but I believe many managers out there don’t really know what it’s like to be a developer, a tester, or an architect. Many of them don’t know what it’s like to juggle projects, to work with contradicting requirements, to struggle with poor-quality code or to spend days on fixing bugs which could have been prevented. Many managers don’t know how much time is being wasted when you don’t have time to do things right. Maybe they did know once, but it’s easy to forget. If only they could experience it for one week, they would not be able to stay indifferent.
Of course, other considerations and constraints, such as budget, market forces, and others, will always exist. But currently, important pieces of information are missing in many decision-making processes: what really happens on the floor beneath you, and what are your workers experiencing.
You can read about it in books and articles. You can invite a consultant to tell you all about it. But without experiencing it yourself, you will never get a real sense of it.
Join a development team for one week. Work with them. Be one of them. Then, go back to your office and make the right decision.
June 2nd, 2006 at 8:39 pm
But how many executives have you met who really could actually code a full-on, working system?
June 3rd, 2006 at 8:07 am
Good question John. I guess the answer is not too many.
But for the purpose of experiencing the problem I guess they don’t really have to be capable of that. I would settle for pairing with a developer, a tester or any other professional for a week, following him around, working with him, joining the meeting he attends, listening to the phone calls he get, and experiencing the problem through him. This is much like what you would do with a trainee. Only the purpose is slightly different.
This is still better than just examining the problem as an “objective” observer. I want executives to see the problems through the eyes of their employees as much as possible.
Lidor