As I’m lagging a bit with my reader I read recent Jurgen Appelo’s article on networked Kanban yesterday. An interesting reading, especially that it ignited a few thoughts (and a great discussion on Twitter with Jabe Bloom, Jim Benson and a few others).
First, Jurgen’s experiments with Kanban boards are perfectly coherent with Kanban principles. We are told to visualize workflow, not to use a specific Kanban board design.
Second, value stream mapping, which is used as one of the basic techniques by many Kanban proponents, is limiting and it brings you back to a standard Kanban board design. David Anderson avoided using the term in his writings and it wasn’t without a reason.
Third, we use examples of typical board designs as it is so hard to explain the whole thing without showing these examples, yet it makes people fixated on typical boards and eventually their board designs are suboptimal.
Finally, I sometimes feel we actively harm people showing them standard Kanban board designs. We prompt them to use one of our well-done solutions instead of looking for the one which is adjusted to their context and reflects their process well.
Now, this is tricky, we’d like people to start with a clean whiteboard and totally open mind and to come up with something which reflects the way they work, presents important information in accessible and understandable way. It is pretty open-ended task, isn’t it? Unfortunately also the one which may make people totally confused.
I’m not sure if I’d even be on the Kanban land now if I was starting with such task. I was more than happy to use the most common board design as a starting point. Now I don’t have problems using uncommon designs (just wait to see my portfolio level Kanban boards) but yes, it took some time to get here.
Either way, my message is: no matter whether you’re just starting with Kanban or are rather advanced don’t stick to standard Kanban board designs. If you have no better idea, use them – that’s what they are for. But please, please, please, don’t treat them as the one and the only way to visualize workflow.
On a side note: I find it amusing working on visualization with people from industries different than software development. They aren’t constrained with the good old process of building things, which was being hammered into our heads for years, namely: analyze, design, build, test, deploy. And they often come up with uncommon designs on the very first approach. Quite a lesson for us I would say.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
13 comments… add one
Hi Pawel,
I’d love to retweet more of your great blog posts, but there’s no (re) tweet button here?
Cheers
Bob
@Bob – Done. It seems you influence me in a good way, as I planned to do it for some time already, but somehow I needed this kick in the butt ;)
When talking about Kanban, I want to change this line: visualise the workflow, to this: visualise the work
Workflow seems to get people thinking about modeling exactly what they are doing, and then there is all this confusion about what if a card has to go back in the flow, and linear and non-linear flow etc.
To me Kanban is more about visualising the work & identifying patterns. Some teams have a column for team members names. or column with a date on it for placing scheduled work. This is purely visualisation, not related to any workflow step.
@Siddharta,
> When talking about Kanban, I want to change this line: visualise
> the workflow, to this: visualise the work
Yes, or “Make work visible”, which I have written on the back of my business cards. In recent presentations David has used just “Visualise”.
There’s another phrase I use: “The work knows”. Rather than talk about workflow in the abstract, I like to start with actual work items. They “know” what what state they’re in, where they’ve been and where they’re likely to go next. The rest kinda follows.
Mike
It would be really interesting to see some of those “uncommon” designs from other industries if you are able to share them or point to them
@Siddharta, @Mike – You’re right. Talking about workflow can result in people being fixated on workflow and not the work itself and how they handle it.
I personally like to use the term “the way the team works.” It may mean value stream mapping, value creation network, process of knowledge discovery or something completely different. Much depends on the context: how much the team knows and understands. I can throw value creation network at my a team of tech writers and they may be a bit confused.
At the same time, everyone understands “the way I work” and “the way my team works.” It may be totally vague but we still somehow manage to get things done so, at least to some point, it is working.
Anyway, you’re right that we should set focus on work and not on a specific mechanism we apply to organize it, namely workflow.
Hi Pawel,
great blog post. I want to bring up another perspective on the whole thing of linear/non-linear/complex.
So, lets assume you come up with a quite non-linear board design in the way that Jurgen pointed out. Several boards with various flows between them. I would see it as a perfectly acceptable starting condition. This is just accommodating the current status quo.
In the sense of Toyota Kata, what we want to come up with are new target conditions all of the time. One after the other. During this process, I would challenge if the non-linearity of the process is a given fact or simply ‘convenience’. What they do at Toyota is that they come up with ever more restrictions on the process, getting actually rid of flexibility, which seems counter intuitive. But it is meant as the trigger for always making visible new problems, solving them and flexing the ‘Kaizen’ muscle. So, restrictions are on purpose!
The restrictions should surface problems, then to be solved. Discussing the problems, it might turn out that the loops and options in the process leading to ‘non-linearity’ are simply convenience rather than value creation. Don’t get me wrong – I do not doubt there might be complicated work flows.
Cheers
Markus
@Ben – I will definitely publish them in future posts, so please stick with me.
However, for the time being I can recommend Siddharta’s webinar on advanced board designs. You can find there a bunch of good ideas.
@Markus – The approach you describe can be/should be brought not only when discussing (non-)linearity or complexity of the process, but pretty much anytime when you want to improve.
This is one of the most important roles of limiting WIP by the way. Not only does it help us to produce more efficiently but limits are also constraints which make us changing the way we work. Constraints foster improvements.
The same way as we remove flexibility in choosing the next task by adding limits to the board, we can decide to remove flexibility from the process itself. In both cases we should face some, well, let’s say inconveniences. We are supposed to act differently than we would otherwise.
Now, I wouldn’t be so quick to call all of them “problems” but they definitely should be a subject to discussion. We may end up having handful of new issues to solve or with realization that we pushed our constraints a bit too far. Either way we learn something.
Hi Pawel,
agree. I like to name it problems. I want to discover problems – not non problems. I don’t stick to the business lingo of calling problems challenges or issues ;)
I want problems to surface. I love it ;)
Cheers
Markus
@Markus – Um, my point wasn’t about the business lingo. It was rather about going to the extreme. For example having one piece flow which may generate new problems (non-existent before the change) instead of just surfacing existing (but hidden) ones.
Although, it may still be a good idea to try it and see how it works. Even if you decide to rollback to the previous approach.
Notes from the birds of a feather that kicked this off
http://www.netobjectives.com/blogs/LESS2011-birds-of-a-feather
Great post Pawel, it inspired me to read Jurgen’s post and respond with my own post here:
http://www.kanbanschool.com/10/kanban-and-multiple-value-streams/