" "

Kaizen Camp: Personal Kanban Conversations Happening Worldwide

Kaizen Camp

The Kaizen Camp in Seattle was such a success that people around the world and sponsors have requested more and more.So, we've launched Kaizen Camp as its own entity.We now have them scheduled for New York, Los Angeles, and Boulder. Tel Aviv, Sydney, Melbourne, and Saigon are in the works.We're excited to talk about continuous improvement, Personal Kanban, and Lean with a global audience. Come join us!If you don't see your city and want to bring Kaizen Camp to you, please visit the site and let us know. We're building out a 2013 schedule!

Kaizen Camp: Seattle–What We Did at Camp

Kaizencamp2012Seattle01

Kaizencamp2012Seattle02

This year’s Seattle Kaizen Camp was awesome.I loved the range and diversity of the attendees, with people from health care, education, government, software development, and a host of other occupations. We had attendees from college students to C-Level management. We were once again very close to gender parity. And we had people from across the US, as well as Europe and Asia.All this to discuss our experiences with continuous improvement, Personal Kanban, and lean.The weather co-operated, so most of our 75+ sessions were held outdoors in the beautiful Seattle summer. Just warm enough to be comfortable.Sessions included:

  • Kanban at Home

  • Failing Well

  • Lean Contracts

  • The Cynefin Framework

  • Accelerating Innovation

  • Metaphors to Convince Others of Lean Principles

  • Resilience with Kanban

  • Extreme Self-Organization

  • Personal Kanban Experiences

and more .. about 70 more.What was most important for Tonianne and me as organizers was the speed at which people created topics and the depth of conversations.All the topics and conversations were conceived of, led, and participated in by the attendees themselves. There were no official speakers, no lengthy powerpoint presentations, no middle-of-the-day sugar crashes in dark rooms. Kaizen Camp: Seattle was people practicing Lean, Personal Kanban, and Continuous Improvement talking about what they did and how they did it.We are looking forward to Seattle’s event next year, but in the interim we have several planning across the US.Coming up later this year (announcements for each will be made soon):

  • Kaizen Camp: Boulder

  • Kaizen Camp: SoCal

  • Kaizen Camp: NYC

Please come to one near you!   Several of the Photos and notes have been posted here.

Customer Alert System: Element #13 of the Kanban

In 2006, my first kanban based project involved setting up a Personal Kanban for a team of 12 developers. Since we were just starting out with kanban, we had no idea what to expect. I did know a few key things though.1. I wanted the customer to have real-time information about what was going on2. I wanted no more status meetings3. I wanted no impedance whatsoever between my development team and the customerSo, we did the following:We set up a kanban in Groove 2.0 (a collaborative platform developed by Ray Ozzie) and shared that with our client. This meant that our client could see our kanban any time they wanted.I gave my client full access to all my developers. In other words, anyone from their side could contact anyone from my side any time they wanted. They were on our chat rooms, they had our Skype addresses, they had our phone numbers. Any time the client wanted access to anyone or anything at Gray Hill Solutions, they could have it.I allowed the clients to come to our daily stand-up meetings and fully participate. They directly participated in the selection of work, the phasing, and its constitution.The upshot of this was that the customer has, through the kanban, a real-time warning system that we may be doing something that required discussion. The fear - of both my developers and the client - was that this would create endless discussions and nothing would get done.The opposite happened.The client understood where we were and what we were doing. They could look at the product any time they wanted. They could see the kanban. They attended the 15 minute meetings so they knew of any challenges we were facing.Additional conversations were rarely necessary - because everyone already knew.The kanban itself gave the client and the team such a high fidelity of information, all we ever needed to talk about was real changes in the backlog or design decisions. In other words, all we had to talk about was value.

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”.

" "