It started with Twitter discussion. Then I followed with a post on standard Kanban board designs. Dominica DeGrandis added her perspective as well. By the way, there’s one lesson I have to take from Dominica and from discussion on Twitter – we need to show people different Kanban board designs so they don’t get fixated on a standard and just stick with it.
In the meantime I was selling Kanban to my wife, as we both believed it may help her in coordinating projects, which is what she does at her workplace. An interesting part is that she works in land surveying industry – something completely different than our everyday reality in software development business.
And after the discussion she comes back home and tells me that she has to show me something. It appears that it is a picture of her very first Kanban board. Out of curiosity I’m asking her about meaning of different artifacts on her board and it strikes me that she’s done exactly what we want people adopting Kanban to do: she’s used Kanban board examples I drew as, well, just examples. And then she’s come up with her original design reflecting her own constraints, which are pretty different than in typical software projects.
First, the board.
Now, that you ask, no, it doesn’t seem like a “standard Kanban board” whatsoever. Where is the process? Where are the limits? If these questions are your first thoughts than you are fixated at least a bit.
You should rather ask how the process looks like. It’s a bit tricky as for each big task there are a few stages. There are these which have to go one after another, but there also are those which can be done in parallel. In short: process isn’t linear.
What more, depending on a task process can be built out of different stages. Imagine that for one task you do the whole production, from idea definition to deployment, for other you do only development, and for another only testing and deployment. OK, now you have an idea how it looks like. In short: process isn’t homogenous.
So the basic idea is that process is defined per task. It can be safely assumed that project manager, or whoever coordinates the work, knows how to cope with each task. What is the role of columns then? Priorities! The old idea of classes of service. The closer the task is to the left side of the board the more important, or urgent, it is to deal with the task.
Different colors of index cards are used to mark different clients as it is somehow important.
Then, we have a trick, which I like the most. As process depends on a task it is defined on the fly for each task separately and represented by small stickies attached to index cards.
Stickies show stages, subtasks, you-name-it which have to be done to complete a task. Green one means the subtask is completed, yellow marks ongoing one, while red color is used for blocked work (which is sort of typical situation). Labels on stickies say what kind of stage/subtask it refers to. In other words they define the process.
Instead of defining complex graph of all possible states with dedicated Kanban board for each state we just add needed stages as we go. Isn’t that agile?
Another nice thing about this board is how limiting work in progress can be handled here. We neither have old-school homogenous process where we limit number of tasks per stage nor dedicated boards assigned to different people where limiting WIP is done per board. However we can easily say which tasks/subtasks are ongoing: yellow stickies tell us that!
We can limit WIP by limiting the number of yellow stickies which are on the board. In a given situation it is actually something which comes very handy, as a number of people involved in doing work is changing pretty rapidly and limits can be adjusted on the fly depending on the current situation.
What I really like about this Kanban board design is that is addresses all the specifics of the situation in a neat way, yet it is perfectly aligned with all the Kanban principles.
And this is why I love to work on Kanban with people from outside of IT industry. Since their constraints are so different than ours they come up with fresh Kanban board designs as our standard solutions just don’t work for them.
Advertisement: Want to have such nice Kanban boards in your presentations or blog posts as well? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
8 comments… add one
hi Pawel,
Nice one.
There is one thing I don’t understand.
You say a different colour for tasks that are blocked.
Does this mean she will replace tasks with a different colour post it when thing get blocked or unblocked?
y
@Yves – Yes, when a task gets blocked yellow sticky note is replaced with a red one and the other way around – when it gets unblocked yellow goes back to the board and red is removed.
I would say that a weak spot of this model is that there isn’t clear what exactly happens when a task is unblocked. Is a red sticky automatically substituted with a yellow one? It would mean that we push task even if there is no capacity to handle it. If not there is no signal, which tells us whether a task is still blocked or a blocker has been removed.
Either way the issue can be fixed this way or another but I don’t want to enforce any specific design. We’ll see how it evolves. It’s going to be an interesting experience for me to see how different issues are tackled with such Kanban board.
seems a lot of paper waste. I prefer to reuse a “blocked” sticky
to put on top of the story
@Yves – Not that much of paper waste I’d say. We waste much more printing docs we don’t really need or writing something down on a stickies which we’ll throw out in a matter of minutes. But you’re right that with this solution you don’t reuse “blocked” token.
Anyway, even though I could think of different way of signalling blockers I like simplicity and intuitiveness of using red/yellow/green stickies to show task status.
And even then, bear in mind that it is the very first version of the board. It will change.
Love the example Pawel. The concept you tried to convey came across loud and clear; there is no one correct way to set up your visualization with Kanban — and we shouldn’t feel constrained by conventional boards.
Yesterday I bought me a two sided whiteboard. One side for regular software development kanban.
The other side to experiment with this idea on ‘non homogenous’ processes ;)
Hey Pawel, the perspective shift is really insightful. The thing I wonder is how easy it is to spot waste or flow bottlenecks with such representation. Left-to-right flow visualization seems natural for most cultures and having different people or activities slicing flow vertically would clearly pinpoint the problem area: whether it is lack of people in a function or some troubled dependency, whatever. Here however with introducing agility on tasks level for each MMFs (correct me if this is wrong analogy) we make it harder to spot why and where problems happen, don’t we? This alternative board may be well suited for particular business area where it is more important to flexibly define number of tasks for MMF and just see status, than understand bottlenecks and eliminate them. But from your other post I understood that for software dev you have kept tailored traditional representation (skipping steps etc.), which works better, right?
@Andrey – This environment was very specific: non-linear flow, often customized to a specific item on the board and process steps that can vary significantly in terms of effort needed to complete them. A typical linear flow simply wouldn’t work in this case. On the top of that the team was changing very rapidly and was anything but fixed.
You are right that with such an approach long queues are not instantly visible, which makes bottlenecks way less obvious. On the other hand, there were just few active items at any given moment which makes understanding where the process is ineffective easier than in a common situation where you have lots of work items flowing through the board.
When I work with software development teams we usually end up with more classic approach, although I’m far from assuming it will happen or pursuing this direction. I usually start with listening how the team works to learn what scenarios they’re dealing with before jumping into board design.