One thing that is really interesting and very enjoyable is to have long time contacts over social media (in my case Twitter mostly). Many of these people I have never met in reality and I still consider them friends. We know quite a lot about each other and have learned a lot from each other.
Kristof Claes was the guy that introduced me to NancyFx and SimpleData in 2011. From an excellent blog series about a photo blog (couldn’t find a link…) he thought me a lot. He has now got an opportunity to use Kanban at work and asked me a question about that.
I asked him if I could blog the question and my answer and he agreed. Here you go:
First Kristof’s question:
I have a very very limited knowledge of kanban and I think kanban can help us with a situation at work, but I’m not sure. I will briefly describe the situation and hopefully you will be able to tell me “Yes, kanban would help you, learn more about it!” or “Hmm, I don’t think kanban will help you there” :-)
I work at a small company that makes websites and web applications for other companies. We have 4 developers (including me), 1 designer, 2 sales people and 1 SEA person. I am kind of changing roles towards a more project management / tech lead / coaching role. One of my new responsibilities is taking care of the planning of the developers.
Most of our projects are pretty small (a few days to a few weeks) with the occasional project that takes a few months. Every developer typically works on a quite a few different projects during a week. A developer might have two “main projects” and when he is waiting for input from a customer for Project A, he is working on Project B. In between there is also support (fixing bugs) and urgent modifications (“We are going to a congress next week, we really really need an extra page added to our website by tomorrow!”).
So we basically have a big list or queue of tasks with a certain priority/urgency and 4 developers to take care of these tasks.
Management has asked me to take care of this and to make sure that there is a visual representation of work waiting in the queue and work being done. I immediately thought “Kanban!” but I’m not sure. All the examples I’ve read about kanban are in the context of a team all working on the same big project within a certain flow (eg. waiting -\analysis -\program -\check -\deploy -\done). Here we have multiple smaller projects (divided in smaller tasks) and each project is only worked on by one person.
I thought about having a prioritised “Waiting” lane and then one lane per developer but I’m not really sure if this would work.
What do you think?
Kind regards and thanks for your time,
Kristof
And now my answer:
Hello Kristof!
I was happy and interested when I started to read your mail, taking on leadership responsibilities is always rewarding and will develop you in more areas than you first will understand. And thank you for making this an easy question to answer: Yes, kanban will help you! :)
Well, I return your favour and answer it a bit more elaborated than that.
First of all: Kanban or not is not that important. What is important (i think) is to see what you are doing (and problems/opportunities you’re facing), strive to complete work fast and help the workflow to work better. This could be summarised in:
- Visualize
- Limit work in process
- Help the work to flow
And these three principles has been bunched together into something that we call kanban. But in reality they are just guiding principles that opens up the door to a lot of other practices and can help you to build a mindset of continuous improvements in your company.
Secondly, more specific to your situation maybe, I think what you are suggesting is a great start. In fact, I would suggest that you use that as the first version. Try to make the kanban-board reflect reality as closely as possible, rather than a on-the-paper-process that you wished you had. If you visualised workflow reflects reality you will see the REAL problems too.
When you draw it - make sure it’s made for changing. The only thing that is certain is that it’s not correct. I usually draw my boards quickly (sloppy?) and on a whiteboard to indicate that this is just “best so far”.
Then you should start to think about what kind of behaviour you want to see. You wrote that each developer is working on his separate projects. Do you want to move away from that? Or is that what you want to see in the future as well?
In Lean we focus on shortening lead-times (time from order to delivery, the whole process). Or put differently; if you put yourself in the the shoes of the customer; what do you want then? Would the customers need be address with higher quality, and faster if you started to work together?
All of this is just questions that I thought of when I imagined your visualized board in front of me. I’m quite sure that you will come up with many more, and better ideas once you get going.
Two final ideas and suggestions; pretty soon after you have got the visualised workflow up, you should think about limiting the work in process (WIP), i.e. the number of items going on. Per lane, in your initial setup. Not limiting WIP is a very common mistake and that is like saying that we’re stretching the iteration indefinitely, if you’re using iteration based projects. Without WIP limits there’s nothing that will push us to be better. In our book we have devoted a whole chapter on setting WIP limits. There’s some ideas in there for you.
One thing that I found useful is to change the WIP limits in a structured and regular way in the beginning of a team usage of kanban. This is one way of doing this; count the number of items each person have going on and then set a WIP limit above that number for the first week. Marcus has 3 items - we allow for 5. This will make it very easy for Marcus to get going. Now decide that you will lower the WIP limit with 20% each week, until it starts to hurt. So when Marcus hits 2 for WIP he might up in a situation where he’s waiting for both his project. Now what should he do? What can you do to solve this? What should you change in your process to allow for this quicker flow? These are questions that will help you improve. The strive for quicker flow will guide you to a better process. The board/process will start to ‘speak’ to you, if you like.
Make sure you meet regularly and reflect and change the board. In my current, very newbie-team, we meet once a week. And the meeting typically takes 20 min or less. But we change something(s) every time. Just to try to do better. The only catch is; you need to know what “better” means… this ties back to what I wrote above. Ask your managers about this to.
I hope you can make use of these advices. thanks for asking me. A lot of more details and suggestions in our book, of course.
Happy kanban-ing!