Kanban in a networked process -- Visualise the network!
It seems that the idea of a work-network instead of work-flow is catching on and I'd like to throw a bit more fuel in that fire!
Knowledge work is not linear! This we have learned from the experiences with failed Waterfall projects. There are things we do over and over again, and there are things we do only once in a project. None of those can easily be predicted. Scrum and Kanban are examples of our quest to distill what we do to the bare essential. Only then can we understand and manage our work.
Scrum does this by strictly limiting the work in progress through the concept of time boxes. The idea is: do something that fits a (reasonably) short timebox, and nothing else. Get that done and released before you go on to the next thing.
Kanban does this by strictly obeying Work In Progress (WIP) limits and establishing a Pull system (instead of push as much content as you can into an iteration). Both have pros and cons which I will not discuss here. http://www.blogger.com/img/blank.gif
But most interestingly, both tackle the flow of our work in a linear fashion. Both Scrum and Kanban assume that some work can "flow" orderly to completion. However that is not the case! In knowledge work we have many loops and re-loops in the process that are hard to visualize and follow. Without visualizing those loops we cannot effectively manage our work!
Jurgen Appelo and Allan Shalloway had (what looks like was) an interesting discussion on the non-linearity of work and consequently on the non-linearity of Kanban boards. Check out Jurgen's and Allan's posts on the subject.
Since I've been experimenting with Personal Kanban for 3 months now I'd like to share some of my own experiences.
The picture below depicts my process boards as they evolved (click for larger images). The initial one was simple and linear, and it did not disclose enough information for me.
The second one was much better in highlighting some of the bottlenecks in my process (waiting for my action, waiting for others action, waiting for meeting), but was still too linear to reflect the work in a way that was useful to visualize.
The final Kanban board is actually what I use now and is a slight modification of the second one. As you can see it depicts the networked nature of my work and therefore also helps me set my WIP limits appropriately (for example why not have many things waiting for meetings?).
A conclusion of mine from the above boards is that it is not possible to set WIP limits without understanding the work (for example what "wait" states do you have in your process). On the other hand, trying to follow the WIP limits you have set will help you visualize those "wait" states as a consequence of the search for sustainable WIP limits
How about you? What are your experiences in using Kanban boards or other visualization techniques to uncover the networked nature of our work? Leave a comment below with a link to your post!
Photo credit: sjcockell @ flickr
Labels: board, complexity, kanban, less2010, less2011, network, visual, visualization
RSS link
6 Comments:
Interesting blog... I have tried to avoid such a complex visualisation on the basis that it becomes tricky to operate and manage. I have only very limited experience so far though, I'm just applying intuition. I'm seeing teams, even in their embryonic stage, start to evolve to a similar complex network immediately and I tend to advise them away from it. What concerns me is that by consciously evolving to a complex network, we are effectively doing good old state-transition diagrams… those were fine for software design modelling to a point, but handling multiple parallel states proved to be a limitation. Similar complexity could seriously impair the simple pull nature and visualisation of a Kanban system? Or, put another way, how do you avoid that same problem?
By
@NickClare1, at November 07, 2011 6:40 PM
@NickClare1
The network you see in the post *evolved* from a very simple board.
Each step in the evolution (there was actually one more step described here) was led by a need to adapt and see the flow better.
My main idea was that I could not be working on more than one task at a time, therefore the "in progress" tasks were not really in progress. So as a way to visualize the different wait states I finally ended up with that board.
But the point of the post is not the complexity of the board, but the non-linearity (network) nature of the board. Our work is not linear, we may sometimes be able to linearize it, but that is quite often not the case -- we just ignore the networked nature of work...
By
Unknown, at November 08, 2011 3:31 PM
I don't believe in this network concept. The trick of Kanban is pull. You have to have pressure on your output. If you are waiting for a meeting, you have to sit together and discuss about solutions for this waiting time. If you limit the wip, you get more pressure en thats what it is about. Waitingtime is waste and should be eliminated not accomodated. the reason it works, is because it is simple.
By
Klaas, at December 19, 2011 10:58 AM
@Klaas
"I don't believe" is a statement that does not help me understand why you don't believe.
that "things should stay simple" is not a reason to follow a linear process either.
I tried to express the advantages and the process to get to this networked board. I actually use it and benefit from that, so I *believe* it works.
I have the reason/rationale for these different states.
Sure, trying to limit the WIP beyond this level would definitely cause interesting discussions, but I have to be able to prioritize my work and do not have power over how other people prioritze their work, hence the "waiting for others" column.
Also, meetings *do* happen, and sometimes I have to wait for that before an issue can progress. That's why there's a "waiting for meeting" column.
Right now I have the best possible WIP for me: 1 in progress (others are in wait states), and I am slowly reducing the WIP in the "wait" columns (just like you suggest).
That is a process of constantly changing and adapting the process in order to get a better flow. Which is what Kanban is about, right? ;)
By
Unknown, at December 19, 2011 4:01 PM
I dont believe in it because i am doing this for a long time now and i know from my experience that it is very risky to accomodate waste. Of course i understand why you do it and thats ok for the short term. for the long term you have to stay focused on LEANiminate these wai tingtimes. If i understood you right, then you alone cant solve them, you have to do it together.
good luck!
By
Klaas, at December 19, 2011 5:26 PM
@Klaas Your premise is wrong! I am not accommodating waste with the networked board, I am reflecting the *actual* process (and existing waste). That is what many within the community are suggesting we should start so I know I am not alone here :)
Also, the waste would not be visible at all without the networked board, you would just see a bunch of "in progress" items without understanding what is keeping them there. I know that most of the items I have pending are in the "waiting for others". Now I can work on that (although the influence I have on others is limited, obviously).
The last part of your comment is right on the money. The "buffer" that the "waiting for others" state represents exists -- I have to deal with it. The only way to deal with buffers is to slowly tackle the reasons for their existence. And that is the key of any JIT/Kanban system: 1) uncover the states, 2) reduce the inventory, 3) goto 1) ;)
So, in effect, a networked kanban board in knowledge work is the *default* state. if you have a linear kanban board in a knowledge work environemnt you are *not* visualizing your process.
BTW: I have also been doing "this" for a long time -- but you probably know that if you are reading this blog ;)
By
Unknown, at December 20, 2011 10:29 AM
Post a Comment
<< Home