See With Your Own Eyes – Lean Concepts for Scrum

“Domo agriato, Mr. Roboto.”

So what does a 1983 song by the Styx have to do with Scrum?  Not much, but they both have a bit of Japanese in them and I figured this would be a good time to offer a deeper explanation of some powerful concepts from Lean Thinking you can apply in your Scrum Teams.  While Lean Thinking applies to everyone on a Scrum Team, Product Owners and ScrumMasters have a special responsibility to apply Lean Thinking in their day-to-day work and encourage Team members to use Lean Thinking as much as possible.  For those who are unfamiliar with Lean Thinking, this Lean Primer will give a good overview of the main concepts you need to understand.  In addition, in 2013 I wrote a short article on the seven wastes of software development that many people find useful since one of the main goals of Lean Thinking is the elimination of waste.

Before we start on this series of three articles, I would like to share that mastery of the concepts behind these funny sounding words is an excellent way to bridge the vocabulary of upper management to the work that is happening within the Scrum Teams.  In my experience, Lean Thinking is language many executives and senior leaders use because they have a focus on the end-to-end picture and rapid delivery of value toward the customer.  Lean Thinking provides them tools to do this and shapes their perspectives.  They don’t care about Scrum, Kanban or XP, but they do care about eliminating waste and meeting the customer’s needs quickly.  If you can help your senior leaders and decision makers make a connection between Lean Thinking and Scrum, they will be better able to support you and see software teams are part of their solution.  Finally, if your management is clueless when you discuss this concepts (they might not know the Japanese words, so give them a pass in this regard), then your  f@kc#d!  Your management team is seriously deficient and you are better off finding an organization that knows something about how to manage a business in the 21st century.

GEMBA – “real place”

In Lean Thinking, gemba refers to the place where value is created.  Gemba is any site where workers provide value to the customers or the customers use the product.  In manufacturing, the gemba refers to the factory floor.  In a service industry like retail banking, gemba is the actual bank where customers meet with tellers.  For a team that produces software that runs on an ATM, gemba is anyplace the ATM machine would be installed – a bank, a supermarket, an airport or the street.  Since gemba is where the customer resides, i.e. value, it is advantageous to visit gemba regularly.

In the context of Scrum, gemba is any place where the Team works and interacts with one another and the customer – cubicles, desk, meeting rooms, phone calls, etc.  For a ScrumMaster, gemba is specifically any place the Team, Product Owner or customer works.  For the Team and Product Owner, gemba is where the customer works and lives and where the users will use the product.

GENCHI GENBUTSU – “go and see”

Taiichi Ohno, creator of the Toyota Production System, is credited with taking new engineers to the factory floor so they could “go and see” what is occurring at the factory for themselves.  During these visits he would draw a chalk circle on the floor and new engineers would be told to stand in the circle, observe and note down what they saw.  If any did not “see” enough, he would have them remain in the circle until they had a long list of observations.  In Ohno’s mind, the factory floor was the gemba where value was added and only there could waste be observed.  If the problem exists on the factory floor, then the engineers need to be on the factory floor to understand and solve the problem.  Genchi genbutsu is therefore a key approach to problem solving and finding waste in your system – you must go to gemba in order to find out what is really happening.  You have to see it with your own eyes and hear from the customer directly, rather they rely on reports or indirect metrics.

In the context of Scrum, the ScrumMaster should almost never be away from their Team.  Just like Ohno’s engineers at Toyota, a ScrumMaster should sit close to their Team, participate in their conversations and facilitate their decisions so they can observe and note anything of interest.  Each day a ScrumMaster should take time to merely observe what is going on in and around the office.  I find having a small journal helps me remember to take notes.  At the end of the week, I recommend reviewing your notes and typing up a three to five page summary or list of key bullet points.  In addition to making their own observations, a ScrumMaster needs to be a strong advocate for genchi genbutsu for the Product Owner and Team members.  They need emphasis over-and-over again the need for Product Owners and Team members to leave the building and go and see for themselves how the product is being used.

For Product Owners, they need step away from their desk, leave the building and speak with real customers and users often.  They must see and hear for themselves how the product is actually being used in the context it was designed for.  The world of Lean Startup offers a great many good ideas on how to validate product assumptions through testing.  At a minimum, Product Owners should be using Innovation Games to help them understand user and customer needs – Me and My Shadow is a great excuse to visit the customer and users where they work and watch them use the product.  Sadly, in my opinion, Me and My Shadow is an Innovation Game that is not used often enough.

Finally, for Team members they also need to step away from the computer from time-to-time and observe how their software is being used.  I suggest Team members assist the Product Owner with customer and user interviews and participate in Innovation Game sessions as observers.  Programmers, testers, business analysts and documentation specialists need to go to trade shows with marketing staff, visit customers when sales people make calls or speak directly with support personal.  The idea is we want the developers to have direct, unfiltered access to the users so they can see how well their product design matches their needs.