A way to optimise business and solve problems is to do a Gemba Walk and believe me, this is not a new dance, even if it sounds so.
According to Wikipedia, Genba is a Japanese term meaning “the actual place”. Japanese detectives call the crime scene Genba, and Japanese TV reporters may refer to themselves as reporting from Genba. In business, Genba refers to the place where value is created, so, in manufacturing, the Genba is the factory floor. So, a Gemba Walk is when you have a production problem and need to enter the factory floor to investigate what is going wrong.
But can we use Gemba if we do development work and not police work, TV reporting or manufacturing? We need to dig deeper into the Gemba Walk to answer this question. The walk consists typically of the following questions:
1) Start investigating what tasks the team is working on and ask about the process regarding the work. 2) Ask questions like: are there processes for this kind of work? Do you follow them? 2) Are the problems related to the existing processes?
3) Ask about the problem, how it materialises, and how it should be fixed. Investigate and dig deep into the root cause of the problem using some of the traditional known problem-solving root cause analysis tools like the fishbone diagram or 5 Whys.
4) And in the end, suggest a solution or a process that will end the problems.

In my opinion, in traditional waterfall projects, the Gemba walk can be an excellent tool for investigating the teams’ problems while executing the project. In most agile projects, the walk is built in the process like in scrum, where the retrospective meeting is held after closing the sprint, focusing on continuous improvement. Software development is not repeatable like factory work, and you must have this in mind before starting a Gemba walk in a software development project.