Why Limit Your WIP: A PK Info Series

Throughout the last year, I have been surprised by the Swiss army knife that is limiting your work-in-progress.  When I tell people:

You can’t do more work than you can handle.

Everyone gets that. C Level execs, economists, bankers, nurses, middle managers, soccer moms – everyone gets the truth in that statement.But what it’s taken me some time to realize is that, the statement doesn’t compel people to action.  It should, but it needs a little oomph.So this series, which will be followed by a series of “How To Limit Your WIP,” will also be turned into a Mememachine book. At the end of this year, I will release all four of the 2012 Mememachines (Why Plans Fail, 15 Elements of Kanban, and these two on limiting your WIP) as physical books, to provide one quick document with all this vital information.But, for now, we are focusing on Why Limit Your WIP.In the end, it all comes back to the sentence: You can’t do more work than you can handle. But why? Why can’t we do more work than we can handle? What happens when we exceed our WIP?Intuitively it makes sense, but we all live in a world that provides constant interruptions, overloads us with information and expectations, and we all – each and every one of us – want to help others. We place ourselves in situations where saying “no” makes sense to no one – not even ourselves. We place others in positions where they need to complete things for us, when we have no understanding of what their workload is.As bosses, we see people's time as finite and easily dividable. We believe our estimates and we believe that work only happens within the Gantt chart.There are at least 10 very good reasons to limit your work-in-progress. Over the next 10 installments, we’ll discuss them in depth. Again, I’m certain there are more. If you come up with others, contact me or Toni for a guest blog, we’d love to have them on the PK site.What are those 1o you might ask? They include how Limiting Work in Progress help:

• Processing and Memory

• Completion

• Multi-tasking

• Context Switching

• Creating an Economy

• Healthy Constraints

• Focus

• Awareness

• Communications

• Visualization

Done! Please check these out - they are currently in the editing and extending mill and will become another Modus MemeMachine Book.

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!