In lean manufacturing, there's a concept referred to as Gemba Walks. This is essentially where someone who's not directly involved in the day-to-day labor on the manufacturing lines walks the floor to identify waste, observe how the work is actually being performed, build relationships, observe working conditions, and many other things. In manufacturing, it has quite a few benefits and companies that practice it often speak highly of the value it brings.
As it relates to software engineering, what would you consider to be a Gemba Walk? How have you seen others or how do you effectively observe working conditions and gained the other benefits that Gemba Walks can bring? If you're not sure you've seen it done, how would you apply Gemba Walks to software engineering? Maybe you are in the "front lines," so to speak, but this could also be applied to staying in-sync with other engineers or other parts of the system. How do you accomplish that?
(This isn't to say I don't have ideas on this, but I really want to hear your ideas on it.)
Latest comments (2)
Oooh I love this concept.
I think sitting in on wholly technical meetings for non-tech folks is a good place to start. I have no idea why we have so much seclusion. Exposure to different peoples' work is great in every way. The same goes in the other direction, asking tech folks to take part in the other meetings from time to time—just as a walk. Not because they are specifically needed.
Basically, no-pressure ways to observe and gently take part in someone else's day-to-day can only be a good thing.
I like it. I hadn't really thought of it going the other way as well, but it's a good idea especially to give people a taste of something they might want in their career down the road. Thanks for sharing!