“Go to the Gemba” for practitioners

At the first ever Kanban conference (UK Lean Conference 2009), Kenji Hiranabe showed a documentary in Japanese. He translated for us real time. To this day, it is one of the most inspiring and important sessions I’ve seen at a conference. The documentary(1) followed one of Taiichi Ohno’s pupils, now a master in his own right, as he introduced the Toyota Production System into a factory making widgets (phones?). Taiichi Ohno’s pupil explained to the senior management team that a key piece of expensive equipment needed to go. He then told them that they personally needed to move the equipment, otherwise he would leave as they were not ready. The senior management team went to the factory floor, removed their jackets and deconstructed the machine in front of the watching work force.

More important than the work itself was the message that this symbolic act sent to the work force. “We are now working in a different way. The management team are fully committed to the new way of working.”

This is what I refer to as “Go to the Gemba”. Leadership showing the organisation the way forward. Supporting the workers, creating a strong message about change, and removing obstacles whether they are physical or cultural.

Don Reintertsen has written(2) this excellent piece on “Going to the Gemba” that points out that the actual practice is not appropriate for knowledge work. I agree with Don. The way that I use the term is different to the way Don describes it. Although the Agile Community does not have a precise definition for “Going to the Gemba”, I have never heard anyone mention chalk. Don’s article hints at the fact that leaders should be technically competent in order to command the respect of “ruthless and impolite” engineers. The idea that managers should somehow better understand the engineering than the engineers. We live in a post “Turn the ship around” world. We no longer expect our leaders to have a better understanding of the work than the worker. The Leader-Follower ( Parent-Child in Eric Berne’s Transaction Analysis ) model where the manager retains responsibility for the work has been replaced by the Leader-Leader ( Berne’s Adult-Adult ) where the worker is responsible for their work and the leader has their own responsibilities. The leader is responsible for the system, and that is why their presence at the Gemba is needed to signal change. Not only do they need to be present, they need to be seen actively changing the system.

Last year a few of us met to hear Jabe Bloom talk about levels of responsibility. Scaling Agile is less about making Agile work with larger and larger groups of people. Scaling Agile is about making Agile work further into the future. Its about understanding the time frame of responsibility which is correlated by not directly related to the number of people who report to you. To illustrate this, consider the time frame of responsibility for the following:

• A scrum team/pod/squad typically focuses on the current sprint. i.e. up to two weeks into the future.
• A product owner focuses on the next sprint or two.
• A project manager may be focused on the deliveries in the current quarter.
• The portfolio owners may be looking at the outcomes in the next quarter.
• The engineering leads may be looking at the capabilities required for the year.
• The CTO may be looking at the capabilities required from the end of the current year to five years out.
• The CEO may be focused on the strategic direction of the company from six month out to the company’s horizon.

Obviously the size of organisation impacts the time scales. For a startup, the horizon might be three months. For a multi-national energy company, the horizon might be fifty years as they try to anticipate technology (oil/solar/battery), influence politics and laws (pipelines/drilling), secure scarce resources (mineral rights) and invent new technologies (batteries/solar tiles).

The time frame is correlated to the number of people impacted. The CEO makes decisions that impacts everyone in the organisation, and as a result everyone reports to the CEO. The CTO however has a time frame that impacts many people but the people impacted report to managers who are aligned with business divisions.

In order to manage a further out time frame, the shorter dated time frames need to work effectively and provide the appropriate transparency.

At one of my client’s we provided transparency on about twenty teams to the delivery lead. All of the teams had unstable delivery over time with red representing story points and blue representing the number of stories delivered.

Rather than blame the teams for their lack of stability, the leader spoke to the teams about it. The leader asked me, the coach, to work with the teams to see what could be done to improve the stability. This was a systemic issue rather than idiosyncratic to an individual team or subset of teams. This meant the teams were unlikely to be able to solve the problem on their own.

The teams all complained of “drive by” analysis. The business analysts worked on projects that needed teams from several systems to deliver. They would write the stories that the multiple teams need in order to deliver their project. As a result, the business analysts would work with different teams for each project. Furthermore, the teams would work with several business analysts. Each business analyst had their own style. This meant that the stories the teams were working on were inconsistent in terms of size, format and content. Scrum works because the development team and product owner (business analyst) refine the story format to optimise the communication. The solution was for each business analyst to have two responsibilities. They retained the  existing responsibility to deliver projects. The new responsibility was to work with a single team to ensure that the stories the team worked on were a consistent size, format and content for that team. This enabled each teams to work with a product owner (business analyst) to improve their individual process, something that had not been possible when they worked with many business analysts. This change required all the business analysts to change the way they worked and take on new responsibilities. It was facilitated by the BA Chapter Lead and the Delivery lead. It was not a change that the teams could have made on their own.

The delivery leads and project managers need the teams to deliver a stable number of stories from sprint to sprint so that they could ensure they had enough capacity to deliver all of the organisation’s commitments in the future. i.e. They needed to be able to produce an agile gantt chart.

Leaders need to have transparency into aspects of the teams behaviour so that they can go to the Gemba. They “go to the Gemba”, not to be the expert but rather to help the team understand the importance of the transparency they need (give the team context) but also to facilitate improvement if the team is not able to do it for themselves.

(1) This is my memory of the session. Sadly it was not recorded for Infoq.

(2) Thank you to Daniel Dorian for pointing it out to me.