I have been talking about Kanban a lot the last couple of years. Sometimes to the point where I think that I must have talked a hole in the head of the those closest to me. But from time to time you get great response, for example;
Anna (an Avega Group colleague) attended one of my Kanban introductions and became inspired. She started to implement parts of the practices I’ve suggested at her client and soon ran into some questions. She sent me an email and asked for my suggestions on how to act in certain situations.
I of course answered but also felt the questions was not only good, they were also common. So I thought that I’ll share my suggestions here. Bear in mind, as I also told Anna, that Kanban is really just a couple of simple rules – how you apply them in your context is very much up to you. This has led to a plethora of practices and ways to solve problems. These are the ones I have picked up in the great network I have surrounded myself with.
So important to note is that Kanban as methodology doesn’t answer any of these questions. It’s up to you.
How do you highlight new activities on the board?
Anna also said; we don’t want them to get mixed up with the ones we already have there. I suspect that she was talking about the work items that might get prioritized over already committed work.
Actually this is one of the benefits of using a flow approach such as Kanban. It’s gives you control and power to say Yes! Yes to change prioritization in the middle of the flow. Yes to add new stuff in your queue of items. I know that David J Andersson consider that as title for his Kanban book; Kanban – how to become a Yes man!
When you have control over a visualized flow it’s easy to see what can be added and what then need to be removed.
One way to handle that is to let the stakeholder have complete control over the Inbox. In my current assignment our project manager is allowed 6 items in our To-do-column. How he prioritizes them is up to him. We simply know that the top one is the first we should work on.
If you feel that, that would make your flow too unpredictable you could allow for a fixed number of items that they cannot change the order on. But what they do before your inbox is completely up to them.
Is it ok to add work items whenever – or only during daily standup?
In my opinion you should at least talk to some other person in the team when adding or changing the order your work items. It doesn’t have to be a formal meeting but could. I’ve experienced anything from big prioritization meetings with several participants (see below) to just letting the stakeholder add notes when the feel like.
One thing I’ve tried that force a communication to take place is that a note must be estimated in size before added to the board. That make the stakeholder talk and describe the item before adding it to the board.
When it comes to moving the board I encourage moving of the items when the state of the work changes. Not just at daily standups. There’s some people, mainly in the Scrum community, advocating moving of the work items only at the daily standup. I was one of them. But then I realized that the board should convey the status of the work – and it should be up to date all the time. So I suggest you move the sticky when the state of the work has changed. That’s also much easier to remember and gives instant feedback of the progress made on the item.
Do you have any suggestion for a simple, powerful agenda on a daily standup?
This one was actually easy. You simply “walk the board”, enumerating work from the right to the left. This will emphasize the pull-principle so that we see work have been pulled into new states, closer to the goal.
Instead of asking all members of the team what their status is we concentrate on the work being done.
If you are in a hurry or have a large team you can simply stop with any deviations from normal. Anything blocked? Anyone not respecting WIP-limits? Work items without attention? Missuse of the board? People sitting on more than one notes? Items having stayed for a long time in the same place?
Stuff that just flow as normal doesn’t need our attention right now. Keeping to just the deviations has led to really big team (40+ people) having daily standups in under 5 minutes.
Keep the meeting short (10 min max) and focus. Put off any discussion to after the daily standup. What I’ve found is that pretty soon will small groups gather after the daily standup and talk about the work. Or better – the process and how to improve it.
What’s a suitable range in size for work items?
It depends, said the consultant and sent his check… This is very hard to give a general answer to, of course.
For small tasks I would say that if it takes longer time to manage the sticky (creating it, adding it to the board and move it) than the work itself – don’t add it to the board. But make a note of work being accomplished. My good friend Joakim Sunden as written an excellent blog post on this matter. I suggest you check it out.
In the other end you have to consider what value you want from the
board. A board is should be an information radiator. If you have
work items sitting in the same state for several weeks it will not give
you any value. I usually have 1-2 week as maximum, estimated time
through the board.
Of course sometimes you have waiting stages (such as “Waiting for deployment”) and then you can batch up many items there.
Even though I suggest that you try to slice up big work in to smaller end-to-end slices of functionality and manage each separately, you could also: split them into tasks and move the task. Here I’ve read about people keeping a number series to keep track of when the main item can be moved.
Say you have a big work item entering development.
You give it a number (5 – Allow for credit card payment).
You then add tasks for that item;
- 5.1. Update database,
- 5.2 Create GUI
- 5.3 Create business layer,
- 5.4 Integration with PayPal.
- etc.
As the team start work on the sub items they move them over to Development done.
When the last item has move the whole work item can be moved (#5 that is)
This pattern will help you to keep track of the status of the work even for big items. Also by divide the work item into smaller tasks you have to think hard about what is needed to complete the task. That is a exercise well worth the time in itself. Hence I never allow for task bigger than 8 h (1 day).
How do you handle recurring activities, such as weekly meetings etc?
I usually don’t add these to the board. It’s not stuff that “make our customer happy”. But of course if you want to track the how much time is spent on meetings… then by all means add them.
In one team I’ve been in we had recurring activities (generating customer invoices) that needed to be done by certain dates in the month. So they created stickies that they reused for those activities and kept them in a corner of the board. With the next due date written above them. When that date approached we simply move the item to the top of the Inbox.
We have several stakeholders that supply us with work – how do you make them prioritize among themselves?
This sounds exactly like the situation where the first Kanban system was ever created in software development. It’s described in great detail in David J Anderssons Kanban book. Simplified they had a maintenance team (in India) that got their work from 4 different managers. Of course all of these wanted “their” items to be prioritized over the other work.
The manager of the team solved this by send them an email when the team had room for 3 new items. They then decided among each other what to prioritize now. Pretty soon the mail was automated. And also the stakeholders started to deal among each other (if I vote for your item this now can I count on your support later?).
The reason, I think, that this worked has to visibility and building trust by delivering value often. The stakeholders knew, roughly, how long it would take until the opportunity to add item. So if they missed out this time it wouldn’t be long until the next occasion. The didn’t have to wait so long until the next train, if you like.
It’s of course better to meet in person if you can. But invite all your stakeholders. Describe how your process works and how they can see work flow through the process. Show them how you will deliver faster (maybe even promise a max time?) if you can work with fewer items running at the same time.
Conclusion
I hope you could make sense of this even though the questions were out of context. I would love some comments on other ways to handle these situations.