When we had just started doing Kanban I wrote about our daily Kanban meeting. What I didn’t realize at that moment was that our daily meeting was based on the following underlying assumptions, which are both false.
- We’re most interested in what has changed on the board (=what people have been working on)
- We can plan everything on-demand
I think the first assumption came from the three questions in Scrum daily. After a while we started having items on the board that simply weren’t moving anywhere. And we weren’t paying attention to them in the daily meeting since they hadn’t moved. We realized that, actually, we should be most interested in the items that are not moving.
The second assumption probably stemmed from my idealism. The idea was that we’ll do planning (=breaking work items into tasks) on demand when the WIP-limits allow an item to be pulled. However, in practice, the quality of the planning was poor.
A developer would finish an item, look for new work and notice that he needs to plan another item. Others are busy working on other stuff so he would plan the item by himself. And so, items were misunderstood, decisions were being made with very little information and planning would lack healthy second opinions. We were also missing out on all the knowledge sharing benefits of planning.
When we realized what was happening, we changed our Kanban daily. Here’s the agenda we switched to.
- Expedite items
- Status of build
- Walkthrough of items from right to left
- Planning needed? (min. 3 devs, tester, domain specialist)
- Notifications
First two steps remained the same. A brief look at the expedites and decisions on whether we need to make adjustments to be able to respond to them. Then, someone reports the status of the build and we pick a shepherd if necessary.
Previously, in the third step, we would only look at the items that had moved. When people moved items on the board they would attach a small piece of red tape on the items and during the daily we would walk through all those with red tape on them. In the new agenda, we started going through all the items on the board.
In the fourth step, which is a new step, we figure out whether we need to do planning. If there’s a slot available we might want to plan. We also sometimes decide to organize a planning session when developers say there will be a slot available very shortly. We’ve agreed that the planning sessions must have at least three developers, one tester and one domain specialist present to avoid the issues mentioned above.
During the daily meeting, if we decide to organize a planning session, we ask people to volunteer for it. We write down the names on a post-it note and put the post-it note on top of the work item to be planned. The people who volunteered will agree on a time and place for the session after the daily meeting.
The fifth step in the agenda remains the same. It’s a slot for notifications. It’s not for sharing knowledge or having discussions. It’s for notifications. If someone wants to have a discussion on a topic he would say “I will host a discussion on topic X at 11 in the coffee room”.
When introducing the changes we were slightly worried that the daily meetings would grow longer. They didn’t. We have a facilitator running the meeting and we always manage to get through it in 15 minutes or less. We have around 25-30 people present in the daily meeting.
Email notification of new posts?
Once a week. Topics such as knowledge work, leadership, software development, productivity, systems thinking and coaching. Thought-provoking and useful. Absolutely no spam. Unsubscribe at any time.
Alternatively, you can subscribe to the RSS feed or follow me on Twitter.
About author
My name is Sami Honkonen. I work as a consultant at Reaktor in Helsinki, Finland. I have a developer background, but lately I've steered more towards systems thinking and coaching. I sing in a death metal band called Embreach.
More about author on the About-page.
November 14th, 2011 at 11:52 am
Interesting point in your post and meetings agenda is a focus on tickets which do not move. I think this is a a part of pure Kanban approach.
I started highlighting those stuck tickets with special stickers. It easily allows to identify that something is wrong with a particular task and this is a place to act!
November 14th, 2011 at 2:44 pm
That requires a single person to go through the board and identify the tickets that are stuck. This is not a problem in your context?
November 15th, 2011 at 4:54 pm
Luckily our project has quite small board, so it is easy to identify those tickets. It can be done before meeting or it emerges during daily meeting in front of the board.
I also plan to introduce such automated “alerts” for electronic tracking tool.