BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Go, See & Do. A Guide to Running a Gemba Sprint

Go, See & Do. A Guide to Running a Gemba Sprint

Bookmarks

Key Takeaways

  • A Gemba sprint is one where teams, leadership, and management work together for a sprint with the ultimate goal of coming together as an organization
  • There are guidelines for organizing a Gemba sprint in your organization
  • Gemba sprints engage people across the organisation hierarchy and build empathy and common understanding
  • Managers and leaders need to learn and be prepared before going to Gemba
  • There are clear do’s and don’ts for running a Gemba sprint

Introduction

If teams are self-managing, why do you need managers?

This was the question that Google’s Larry page and Sergey Brin debated in 2001.

Ultimately, they decided that that management was unnecessary and initiated what they called a "Disorg" and fired all managers.

A year later, there was an intellectual battle between them and their coach Bill Campbell regarding the value of managers until they finally agreed that they should just go ask the Engineers themselves.

To their surprise, the Engineers wanted managers to return.

"These engineers liked being managed, as long as their manager was someone from whom they could learn something and someone who helped make decisions." - Eric Schmidt, Jonathan Rosenberg, Alan Eagle, "Trillion Dollar Coach: The Leadership Playbook of Silicon Valley's Bill Campbell"

A year later management was returned.

The lean & agile movement has been effective at making the concept of self-managing teams ubiquitous, in a sense creating systemic industry-wide "Disorg". The result of this is that many managers remain in management purgatory, weaponizing them against the change.

Like the experiment at Google taught, the right managers are critical. In my experience the right managers hold the key between successful and failed organizational transformation.

Tayloristic, command & control managers have been rendered obsolete but many behaviors remain and are ingrained. Konosuke Matsushita said of western companies:

"Your firms are built on the Taylor model. Even worse, so are your heads. With your bosses doing the thinking while workers wield the screwdrivers, you’re convinced deep down that it is the right way to run a business. The essence of management is getting ideas out of the heads of the bosses and into the heads of labor. We are beyond your mindset. Business, we know, is now so complex and difficult, the survival of firms so hazardous in an environment increasingly unpredictable, competitive and fraught with danger, that their continued existence depends on the day-to-day mobilization of every ounce of intelligence."

The challenge is how do we create the necessary environment to enable the behavior change of leadership and management:

  • Where teams spend the majority of their time producing value for the customer
  • Where managers help the teams deliver faster by removing waste rather than "pushing" them
  • Where managers coach and teach
  • Where product owners and organizational leaders provide vision and understand what is happening at Gemba by going to Gemba
  • Where empathy and compassion are prevailing values

This was the very challenge I was faced with when working with a large product company that was in a dire situation The list of problems was seemingly insurmountable: low morale, angry clients threatening to leave, a burning platform, attrition, etc. I was asked by the CIO of the parent company to travel to India and spend some time with the teams to solve some of the issues. In other words, sprinkle some of that "agile magic".

"Why don't we try a Gemba Sprint?" It was an experiment I designed on paper to create the necessary conditions for managers and teams to come together.

There were numerous obstacles standing in my way. The greatest of all was Microsoft Outlook. Organizational leaders and managers have packed diaries two meetings deep. My hypothesis was that if the CIO cleared his calendar, the rest would as well. Arguably the busiest of them all, if he cleared his diary for a week it will signal to the managers below the importance of going to Gemba. So I pitched the idea to him.

"But in order for this to work, you have to lead, you need to clear your schedule and join the teams for a week, then everyone will follow," I said to him. That is exactly what he did and the rest followed.

Weeks later, leaders from across the globe flew to India to spend a week delivering software with teams. The experiment was set in motion.

What follows is a guide on how you can implement a Gemba sprint in your organization.

From walking to sprinting

"Go see, ask why, show respect" - Toyota Chairman Fujio Cho

Key Differences Between Gemba Walk, MBWA and Gemba Sprint

The Gemba walk was popularized in the mid-to-late ’90s by the Toyota Production System[2]. The Gemba walk is a 6-step process to observe the reality of what is going on. A manager focuses on a specific process step and seeks to understand what the reality is by employing open-ended questions to learn the reality of the process.
 
Management By Walking Around (MBWA) is a management approach that encourages  physically visiting the "actual place" regularly. Sam Walton, the founder of Walmart, constantly visited his stores and expected his managers to do the same[3]. Despite running a multi-billion-dollar company, Howard Schultz, the CEO of Starbucks, makes it a point to visit 25 stores every week in order to "witness the customer experience personally."[4]
 
MBWA and Gemba walks have visiting the "real place" in common. Gemba walks, however, go further to add a more specific purpose and a set of steps to discover the reality.
 
These differences led W. Edwards Deming to say about Management By Walking Around:

"Management by walking around’ is hardly ever effective. The reason is that someone in management, walking around in a non-structured way, has little idea about what questions to ask, and usually does not pause long enough at any spot to get the right answer."

Like the Gemba walk, the Gemba Sprint has specific goals and a process to achieve them. The Gemba Sprint, however, transcends the Gemba Walk in that it also includes organizational goals.

Gemba Sprint Goals & Anti-Goals

The goals of the Gemba Sprint can be divided into three: Organizational, Process, & Anti-goals.[5]

Managers see what is really happening

"Farming looks mighty easy when your plow is a pencil, and you're a thousand miles from the cornfield." -  Dwight D Eisenhower

Management by status-update is a reality of scaling to a large complex organization. Perfectly aligned boxes and unified fonts of a PowerPoint presentation can easily hide the realities of the ground. The real world is far more nuanced and complicated and lost when presented in a deck. In the words of retired four-star general Jim Mattis, "PowerPoint makes us stupid."[6]

A PowerPoint representation of a shantytown, while useful for some purposes, obscures the reality on the ground. Nothing can give a genuine appreciation of the reality of the shanty town than taking a walk through it.

Learning & Teaching

"Learning organizations are organizations where people continually expand their capacity to create the results they truly desire, where new and expansive patterns of thinking are nurtured, where collective aspiration is set free, and where people are continually learning to see the whole together." - Peter Senge

A primary objective of the Gemba Sprint is bidirectional education. Participants in the Gemba Sprint are expected to both learn and teach. Managers, by definition, have a better understanding of navigating the organizational system to get "things" done. Managers should take the Gemba Sprint as an opportunity to teach the system to the teams. Organizational leaders understand where the organization is going and can implant purpose and urgency into a team. The teams are the most aware of what is happening on the "ground".

Managers teach and not solve

"There are three kinds of leaders. Those that tell you what to do. Those that allow you to do what you want. And Lean leaders that come down to the work and help you figure it out." - John Shook   

Most managers are generally very busy. Between people issues, product issues and corporate issues, most calendars are so full that they need to schedule lunch.

When they are not on calls or in meetings, managers are usually solving problems. I often work with managers that have a steady stream of people walking into and out of their offices seeking help to get unstuck or untangled. This results in two issues: managers become a bottleneck & the quick fixes can often have dangerous consequences.
 
Quick fixes can be dangerous because they are often implemented as a result of incorrect systems thinking and incomplete information. As stated in the Weinberg-Brooks’ Law: More software projects have gone awry from management’s taking action based on incorrect system models than for all other causes combined. (Quality Software Management: Vol. 1 Systems Thinking p76)

Managers should seek to overcome what Senge calls learning disabilities through the discipline of systems thinking and going to Gemba. The combined disciplines of learning to see through systems thinking and going to the place where value is created results in a manager with organizational superpowers. They can see what most can't, hear what most are too busy to hear, and grasp what few can: the reality. Like not missing lunch, it all starts by prioritizing it in the calendar.

An organizational system is far more intricate and complicated than a mechanical system due to the non-deterministic nature of people. Those who understand the organizational system are often called "good politicians" or "political". While this loaded term is usually used to deride someone, I believe it’s a useful and necessary skill for success.

Managers make the mistake of spending too much time understanding and navigating the system. While the Gemba Sprint seeks to get the manager closer to Gemba, managers should also explain to the team’s member system dynamics so they themselves can avoid local optimization thinking.

Once they've developed the skills of seeing, the managers should teach teams to solve problems rather than solve the problems themselves. This will make the organization go faster by removing this blocker, but also free up the manager to consider higher-order issues.

Product Owner bring teams closer to the customer and teams bring the Product Owner closer to the code

Product management and Product Owners advocate on behalf of the paying customer or internal users of the system.  Technology management, however, is usually involved when there are problems, issues or when they need to provide high-level estimates. This disintermediation results in the team's loss of purpose and urgency. Purpose, as Daniel Pink postulates, is a necessary ingredient for intrinsic motivation or drive as he calls it. Without drive, management is forced to use extrinsic motivation which can stifle innovation. 

Product Owners at Gemba should embed purpose into the teams. It’s also important that the teams bring the product owner/management closer to the code by showing them the technical debt that resulted from short term thinking mistakes, local optimizations and time pressures imposed by management.

I recall the following conversation between the product owner and one feature team during a Gemba Sprint in India.

"Why do you have to make the simple change in many places?'' asked one product owner to his teams in India.

"Remember that customer feature you said we had to get in by that date?" A member of the team replied.

"The only way we could actually do that was to create a copy of the code",

"Why would you do something like that?" The product owner was asking a perfectly valid question.

"Given the time constraints we had, we were worried about creating regression issues, we didn’t want to take the chance impacting other customers",

"You should have told me," he said. "This is a nightmare",

"We never spoke to you directly back then, our managers did"

Increase empathy

"Empathy begins with understanding life from another person's perspective. Nobody has an objective experience of reality. It's all through our own individual prisms." - Sterling K. Brown

Greater sense of empathy

By visiting Gemba and working with the teams, leadership, management, ScrumMaster  and Product Owner gain a greater sense of empathy of what the teams must deal with (e.g. context switching, slow build servers, environments, changing requirements).

Managers have a lot they must deal with: fire drills from above, getting yelled at by customers and internal clients, personnel issues and unending meetings. Product owners must deal with angry customers and business and commercial expectations. Scrum Masters focus most of their time on protecting their teams from all of the distractions that can result from all of the above.

Going to Gemba affords a great opportunity for management, the Scrum Master and Product Owner to understand what it feels like to be a member of the team and allows them to connect with them in a better way.

During a Gemba Sprint in India, a CTO was asking the teams why the build was taking so long, they said that the build server was antiquated and that their request for a new server was declined by infrastructure.

"What do you do while the system is building?"

"We go get some Chai"

A new server was ordered as well as dual monitors for every developer. The deeper insight that the CTO gained was the offshore development center was part of a cost reduction strategy. So the local lead was very sensitive to cost, hence one monitor.

What they will invariably see is that teams are trying to do the right thing, it is a system that has been created that makes doing a good job more difficult.

The empathy that is gained from this experience pays dividends.

In one case, the CIO of the organization was working with his team on an Oracle upgrade. It was time for lunch.

"Let's go have lunch," remarked the CIO.

"Your lunch is being prepared in the boardroom; we believe," replied the teams.

"Where do you eat lunch?"

"The canteen"

"Then that is where I will eat"

The CIO of the parent company sat in the canteen with developers in an offshore development center and shared their lunch eating with hands although he is unaccustomed to doing so.

Human moments such as the above of empathy bring the organization together in immeasurable ways.

The Gemba Sprint experiment  

Software product development is inherently complex, and its complexity is further multiplied by each organization’s particulars and nuances. As such, the Gemba experiment is a list of suggested things to try and avoid so that you can design the Gemba Sprint that is right for your organization.

An example of some activities to consider:

Before the Gemba Sprint

Asking managers to join a team is sometimes met with a lot of resistance from both managers and teams. There is an invisible wall of mistrust, fear & insecurity between management and those with "hands on keyboards"  that makes the traditional Gemba walk seemingly uncomfortable for both parties. This exercise is meant to create an environment for this type of activity but also leverage the fear and uncertainty to get people to learn new things and think in new ways. Whether or not manufacturing this type of experiment is a good or bad thing can be a matter of debate. I find leaving management "as is" while the teams "evolve" through the agile organization is unfair to all parties.

Find someone to own the idea

Find a volunteer who will own this idea rather than rent it.

The idea of owning an idea is where someone takes an idea and makes it their own. I am a runner and for many years I would not shut up about running. It was an idea that I passionately owned. A rented idea is that which you do not own but is borrowing for a purpose such as my wife is telling me I am not allowed to eat meat on Monday.

The Gemba Sprint is a difficult experiment to run and you want someone who genuinely believes in it, who will own the Gemba Sprint, modify it, rename it and make it their own. External coaches can advise, help and guide, but someone from within the organization should own this experiment. With one client I worked with, the Gemba Sprint was renamed Unicorn Sprint because they did not like the word Gemba. That was a great sign.

Over communicate

What can make or break this experience is communication.  It is very easy for this type of experiment to be misunderstood or misconstrued. Decades of behaviors as a result of theory X assumptions can create deep-rooted mistrust between management and "workers." You can't really solve that immediately, but you can soften the effects through lots of effective communication.

With everyone

Preparing everyone for the Gemba Sprint with explaining the "whys" of the exercise will reduce resistance and encourage participation. Start with an introduction in a town hall or other type of session where senior leader explains the Gemba Sprint and how the exercise is tied with an organizational goal. The leader should also open the forum up for feedback as well.

Recap the session with various forms of written communication or information radiators such as emails, newsletters, posters and other physical artifacts that can remind people of when the Gemba Sprint is and what their roles are in the Sprint.

With management

One-on-ones should be scheduled with everyone who is taking part in this exercise to explain what their roles are, and what is expected of them. This provides an opportunity to everyone to to offer suggestions, ask questions and express their concerns. Senior organization leadership should be in these meetings to reinforce the idea of job safety but not role safety.

Examples of common concerns to be addressed during communications:

Choose the worst time to maximize learning

There is no perfect time to do a Gemba Sprint. Rather than trying to find the "perfect" or "slow" week if such a week exists,  find an imperfect week. Before or directly after a production release is a great option and a great time to maximize learning.

Break the system

In order to accelerate the learning and highlight  bottlenecks, you can consider stress testing the system to maximize learning. This can be done by attempting to complete the same amount of work in a condensed time frame.

The idea behind this is to performance test the system to both expose the bottlenecks as well as maximize the learning, not an attempt to cram more work into a shorter time frame. The key difference in the shorter Sprint is that management and product teams are present in the "doing".

Other "break the system" activities could be releasing on demand, developers testing instead of coding, challenging an archaic process or status quo...whatever the activity, be sure to communicate, communicate, communicate the intent so that it is not misunderstood.

Learn how to learn at Gemba

"Learning is not compulsory... neither is survival." – W. Edwards Deming

Time leading up to the Gemba Sprint is a good opportunity for all involved to take classes and workshops to learn how to be an effective leader, communicator,  a coach, teacher and learn some technical skills.

Learn the 5 whys and other root-cause analysis patterns

The purpose of 5-whys is to discover and solve the underlying issues that cause a problem. 5-whys employs "counter-measures" rather than simple solutions. A countermeasure ensures that the problem does not arise again rather than just eliminating the symptoms.

Learn how to ask good questions

"If you do not know how to ask the right question, you discover nothing." - W. Edwards Deming

Learning to ask good questions is a learnable skill. Here are some concepts and methods:

  • Consider learning about cognitive biases and mental models to help you realize that your whole view of what is happening is incorrect at worst and incomplete at best.
  • Consider learning about the differences between dialogue and discussion to help you actively suspend your mental models to enable you to understand the system.
  • Consider learning how to system model with the teams to visualize the complexity of the organizational system. "For every complex problem, there is an answer that is clear, simple, and wrong." – H. L. Mencken
  • Consider learning Humble Inquiry: the art of asking authentic questions to a person to learn their perspective.
  • Try Clean Language as a template to ask better questions.

Learn how to read code

I’m not suggesting you learn to write code, I’m suggesting that you learn to read. There is a big difference between learning how to write great poetry and reading poetry.

Develop an eye for waste

"When you go out into the workplace, you should be looking for things that you can do for your people there. You’ve got no business in the workplace if you’re just there to be there. You’ve got to be looking for changes you can make for the benefit of the people who are working there." - Taiichi Ohno

Lean defines waste as any activity that does not add value to the paying customer. Therefore any activities that impede value creation are waste. When looking at the entire lead-time (the time the customer asks for something until it is delivered to them), highly observative and effective managers can uncover tremendous amounts of waste while some managers can also be the cause of generating waste and doing harm at Gemba.

The default is that many managers try to coerce teams to go faster, when in reality they can make the system move faster or increase the flow of value by removing waste. A manager should ask not what the team can do for them, they should ask what waste they can remove from the system.

During the Gemba Sprint

Start with an all-hands breakfast and level-setting

Kick off the day with an all-hands breakfast. Food is important and overall a nice gesture and eating together relaxes people.

During the all-hands, leadership should re-emphasize the reasons behind the Sprint as well as the rules of the Gemba. For example:

  1. Repeat the goals of the Gemba Sprint
  2. Repeat what the Gemba Sprint is and is not
  3. Repeat the rules:
    1. Only observed blockers should be collected. Teams and managers should refrain from putting their pet-peeves on the list
    2. Managers should refrain from doing their day job while at Gemba.
    3. Every day ends at 5pm to lesson the observer effect.
  4. Agree on the format of the waste observations. For example:

Joining teams

Joining teams can happen before the Gemba Sprint or during Sprint planning.

Those who are  joining teams should be free to join any team they wish for any reason they wish, but once they join, they must stay for the remainder  of the Gemba Sprint print and be committed to meeting the team’s Sprint objectives.  

Create a "Gemba" checklist for managers

"Employees don’t quit their jobs, they quit their managers."

Coding at Gemba

It’s not necessary that managers/leaders/product owners/Scrum Masters do engineering work, although it’s possible. Some of those people were former developers in a past life and while their coding skills may be rusty, the idea is that they pair with as many team members as possible to maximize the learning and develop and eye for waste. Everyone should be empowered to help do work where possible.

Consider mob programming (or other methods)

Mob programming is a technique that has been around for a long time but has gained some popularity in recent years. The basic idea is that a team of individuals work on a single problem together, at the same time. This is a good experiment to try for two reasons:

  1. Mob programming exposes a lot to the new team member in a compressed period of time.
  2. Mob programming can also illustrate that their intuition is not always correct, that a team of people working on a problem is not a waste of resources, but it can be a force multiplier.

Think of some other methods that will push teams beyond their comfort zone to try something new.

Hold a daily retrospective

Memory is imperfect and the rush to get work in the last days of the Sprint may eclipse much of the important learning. Have a daily "light-weight" retrospective instead of waiting until the last day of the Sprint.

It should be fun and well-facilitated!

Three important  reasons for the daily retro:

  1. Signals the end of the day and a stoppage of work. This is to ensure that teams do not put in extra hours due to the phenomenon called the "observer effect" that states that the mere observation and measurement of an activity will alter its results.
  2. Discuss the day’s data and any missing observations.
    • Take this opportunity to prioritize the list of waste
  3. A chance to reflect on the day. How did today go and how can we improve tomorrow?

After the Gemba Sprint

Radiate information

Within a couple of days of the end of the Gemba Sprint, the output of the Gemba Sprint should be communicated.

Be sure to include the waste collected, waste removed and any new experiments or items that will be attempted.

Create and keep the central "waste management board" alive with what has been removed and what material impact has been measured or observed. Theoretically, the more waste is removed, the more value the customer should receive.

Retrospect on the Gemba Sprint

Reflect on the Gemba Sprint itself. Schedule a lunch away from the office and retrospect on how the Gemba could be improved the next time. Ask the manager, coach or Scrum Master to keep a list of "do’s", "don’t" and "keep doings".

Have a Waste Management Workshop

After the retrospective on the Gemba, the teams should return to the centralized waste board to discuss the observations of the Gemba and what actions to take to address them.

Conduct an anonymous survey

The intention of the survey or other feedback form  is to gather what was unsaid. There may be pressure to declare the Gemba Sprint a success and those with constructive criticism may feel the need to be silenced. The objective is to gather constructive criticism while minimizing toxicity.

Some potential questions:

  • Should we do this again?
  • How would you improve the next Gemba Sprint?
  • What did you find valuable about this experiment?
  • What did you learn from this experiment?

Celebrate!

"The prevailing system of management has crushed fun out of the workplace". - W. Edwards Deming

Congratulations on finishing your Gemba sprint! Don’t forget to celebrate this significant milestone on the path to continuous improvement! Conducting a Gemba experiment can push people beyond their comfort zone which always deserves a celebration.

Final thought

Like any experiment, a single Gemba sprint will not solve all your issues. It is meant to be a huge first step in a long journey of repairing years of management antipatterns[1] and creating a new set of behaviors. I recommend scheduling the next one until the behaviors become the norm. Eventually, every sprint should be a Gemba sprint:

  • Where teams spend the majority of their time producing value for the customer
  • Where managers help the teams deliver faster by removing waste rather than "pushing" them
  • Where managers coach and teach
  • Where product owners and organizational leaders provide mission & vision and understand what is happening at Gemba by going to Gemba
  • Where empathy and compassion are prevailing values

Acknowledgments:

I would like to thank all the people that reviewed this and provided valuable feedback: Bas Vodde, Michael James, Victor Grgic, Tim Born, Paul Shepheard, Gene Gendel, Deb Wren, Lee Nicholls, Andrea Ceccolini & Mark Zod.

References

[1]An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. – Wikipedia
[2]What is the origin of Gemba?
[3]Definition of 'Management By Walking Around'
[4]Leading On Your Feet
[5]What are Anti-Goals?
[6]General Mattis, save the U.S. military. Ban PowerPoint.
[7]Code smell

About the Author

Ahmad Fahmy specializes in large-scale product development & organizational design. He has helped multiple investment banks and product companies successfully transition to lean and agile ways of working. With over 20 years of banking technology experience, his financial product knowledge and technology background makes him well suited to help organizations transform. His experience and empathy have made him a sought after consultant, trainer, and speaker on the subject of organizational design. You can find more here.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT