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.

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

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!