" "

Primers

Gemba Symbolizer: Element #12 of the Kanban

In Lean the “Gemba” is where everything happens. It’s the crime scene, the shop floor, ground zero. In manufacturing, the Gemba is a physical location, filled with gear, that you can walk along and evaluate for operational productivity, efficiency, and effectiveness. This is called a “Gemba Walk.”The Gemba is also synonymous with the people who work there. So, if you are a manager and you notice something is amiss, you can “Go to the Gemba” and ask the people there what they think. The Gemba will then help you find a solution tempered with both management and line-worker sensibilities.In knowledge work, however, we have no Gemba. If I go do a Gemba Walk, I will walk around a bunch of cubes and everyone will look like Dilbert. By and large, in knowledge work, there is simply no physical representation of the work. I would, and management consultants often do, have to rely on asking everyone “What do you do, how do you to it, where are things good, where are things bad, etc.”And, everyone involved in the day to day work will tell me their views, which are all slightly or not-so-slightly different. Then I’d have to make sense of it all and then give the client some sort of report that is a mix of spot-on-brilliance derived through finding the common wisdom in what I heard and cumulative error by chasing threads of little value.And why was I hired? Because neither the managers nor the line-workers knew what was really going on in the first place. They all “knew” - meaning they believed their own interpretations - but no one seemed to realize that all the interpretations were different because they were all ill informed.So the kanban shows us all this. It shows us what the team is doing, the steps they take to do it, where things are breaking down, where people are working together, what options are coming up, and so on.By now, at Element 12, we know all this.The kanban, then, becomes a symbolic Gemba. It gives everyone a physical artifact, much like the assembly line, for everyone to go to, have conversations, and engage. We don’t fight over interpretations, we merely suggest new ones. And we suggest the new ones in context - standing in front of the board and saying things like, “This outsourcing partner seems to be slowing us down - can we get them more information up front that could help them process our work faster?” or “If we moved some of the graphic designers to the front of the project, we could work with better designs throughout product development.”We can do Gemba Walks of our teams and others by simply walking the board.This is #12 in a 13 part series on the elements of kanban. Read them all!

Work Flow Laboratory: Element #11 of the Kanban

The Personal Kanban shows us what is happening, how it is happening, by whom it is happening, and even why it is happening. Here we see a bottleneck between coding and QA. The cause of this is currently unknown. But we have some hypotheses.

  • There aren’t enough people in QA to handle the load

  • Something currently in testing is proving problematic

  • Coding has been unusually hyper productive

  • There are too many coders

  • etc.

  • One or more of these may be correct. We’re not sure which ones.So, we posit that coding has been hyper productive and that this is a temporary issue. We could move some people from coding into testing. So we give that a try.After two days, the board looks like this:Here we see that work has moved along, but that the bottleneck persists. We know that while work has moved along, the root cause has yet to be discovered.At this point, we can employ any number of visualization or problem solving techniques to delve into the root cause. A3, socratic method, 5 whys, positive deviance, or any number of gamestorming methods might help here. When we gather enough information, we can refine our hypothesis and try again.This time, we discover the issue really is that there’s some highly specialized testing necessary. So we bring in an outside consultant to help with that testing. In the meantime, we halt coding and put the coders to work on training. They watch a few hours of training videos by Uncle Bob, they read some books, they have some lean coffees, until the bottleneck is resolved.What we do not do is have the coders do anything that would require testing.Bottlenecks are not the only experiments you can run. If you believe work can happen faster, that a delay is too costly, that something can be more fun - figure out an experiment you can run and how the board can visualize that.Here we have a real live board from a team we work with. They are near a major release of a very large development effort. They felt that having information about the experiences of their early adopters would be helpful, so they created a swim lane specifically to address early adopter issues.These issues were not just bugs with the software, but all tasks relating to rolling out the product to new users. The programmers, testers, and designers are seeing the contracting, implementation, and operations issues and tasks.This experiment was based on the hypothesis that more information would be useful to everyone. There was also a chance that more information would have overloaded the board and hindered development. In this case, the board was used as a process laboratory to test possible good outcomes, as opposed to simply correcting something that was “broken”.

Collaborative Aid: Element #10 of the Kanban

collaboration kanban

“Hey Tonianne, I see you’ve pulled the ‘Strike sheet for Kaizen Camp’ ticket. I took some notes from our meeting the other day, they are in the ‘Kaizen Clean Up’ mind map. Just take a look at that, it should be almost everything you need.”“Thank you Jim, it is such a pleasure to work with a helpful, conscientious, and wickedly funny man as yourself.”We seldom work alone.Our best work is done through collaboration.The kanban’s strength here is unprecedented. Since the board is broadcasting in real-time, help also arrives in real-time.Of course, while it would be great if I were all those things the not-so-realistic reply from Tonianne states, we all naturally tend to provide simple assistance when it is easy to do so. The assistance I provided to Toni in the above exchange took me only seconds to provide - so it was very easy.However, the results are stunning. I leveraged my previous work, she saved a few hours of re-inventing the wheel. In the end, the ticket moved much faster.Only because I knew what she had pulled when she pulled it.When I talk about collaboration, people like to bring up the recent book “Quiet” which talks about how we should make room for introverts. A prominent point in the book is that society tends to focus on collaboration, while introverts like to work alone.After 25 years of working on projects of all sizes, I can safely say that introverts make the best collaborators.And here’s why.Collaboration does not mean working together as a group 100% of the time while talking non-stop and demanding constant feedback and decision making.Webster’s definition is simply this: to work jointly with others or together especially in an intellectual endeavorYou cannot work for a company and work alone. Everything we do in an organization is in concert with others. If we are doing something and someone else is doing something and we know about it and we put those pieces together later to make a whole - that is collaboration.I built my initial mind-map, Toni is writing a document, we had a very brief - but universally beneficial - exchange where I shared some information with her. We are collaborating.To be sure, there are more intense forms of collaboration. We can also see on the image above that Toni and I are both working on the AAR for a client. In that project, we are pair writing. We will both be in the document writing at the same time and talking or otherwise communicating while doing it.But for this post, I want to focus on that simple, human courtesy. I notice you have pulled work, I have helpful information, I give you that information, and we both move on.If a team understands in real-time what the other team members are doing, these exchanges become common, rapid, and even anticipated. The time savings is enormous.This is #10 in a 13 part series on the elements of kanban, read them all!

Conversation Starter / Conversation Avoider: Element #9 of the Kanban

“What’s wrong with this picture?”“What are you going to do to get that completed?”“Would you like help?”“Are you blocked?”“Why did this happen this way?”“I totally didn’t expect that, did you?”The kanban is a conversation starter. There are patterns that show up in normal working that create conversations that lead to action.When we work with others, our primary means of processing is conversation. It is true, we can waste our times with the wrong conversations, with conversations about things we should already know, or with conversations about trivia or politics. But ruling out conversations is simply foolish.Without a visual control, many of our conversations center around status. “Are you going to meet your deadline?” “What did you do yesterday?” “What are you doing today?” “What have you completed?” “Are you blocked?”If you have an active kanban, most of these status conversations can be avoided. The board already gives anyone who looks at it that information and more. Anyone who needs it can get pertinent information at a glance.Beyond that, we have our shared story (element one) which is broadcast by the information radiator (element two) which is impacted by the nature of the game (three) and impacted by real-time events (four) and so on through all the elements we’ve covered this far. With eight elements under our belts, we can see that there is tremendous context displayed on the kanban. That context is informing us, teaching us, and making us question our assumptions.When that happens, we need some conversations.Teams we work with are encouraged to have daily meetings called “stand up meetings.” These are 15 minute discussions where everyone stands up. We want the meeting to be somewhat uncomfortable so that it will be short and people can get to work. Before the advent of the kanban, the format was to have everyone ritualistically answer three questions, “What did you do yesterday?” “What are you going to do today?” and “Are you blocked or need help?”After the kanban, all three questions were redundant - the board already answered them. At that point, the stand up meetings became 15 minute strategy sessions about how to attack the day, parcel out upcoming work, or swarm on a problem. All of these conversations are informed by the kanban - it shows exceptions to daily operations (things out of the ordinary) and that sparks conversations.This is post #9 in a 13 post series on elements of kanban.

Metacognitive Tool: Element #8 of the Kanban

double loop learning

METACOGNITIVE TOOL is one nice chunk of jargon.Metacognition is “learning about learning.” When we have a tool for it, that tool teaches us about how we learn. When we have some understanding about that, we can start to look for new ways to use the tool to learn more effectively.This is where something called “double-loop learning” comes in.When we use the kanban in our daily work we are employing several real-time techniques and strategies to get work done. “I’m going to make my tasks so they’ll take less than a few hours to complete.” “Today I’m going to work entirely on the City of Pelentagagagua proposal.” “I will do the work for my lawyer after I get this thing out of the way for my boss.”But while we are working, we are basing those decisions on a variety of assumptions. The kanban shows us, in real-time, the impacts of our assumptions. If we begin with an assumption that our office work is more important than getting things done for the family, after a while we’ll end up with a lot of aging family tickets and a DONE column filled with work tasks.When we see this, we’ll see that there is a cost to that assumption. That cost is a lot of pent up work for the house and likely an angry spouse.Other assumptions we might be making is that one client is more important than another, that if we do large tasks first we’ll get more done, or that if we deliver product at two-week intervals we’ll have a more predictable delivery schedule.We can use the real results from the kanban to question these basic assumptions, then alter our assumptions and see the results of that.As we do this, we learn:

  • the results of our actions (single-loop);

  • the effects of our basic assumptions (double-loop); and

  • how that understanding impacts how we work, how we create experiments, and how we react to change (metacognition).

" "