Over a million developers have joined DZone.

Improvements on using a simple kanban for effective meetings

DZone's Guide to

Improvements on using a simple kanban for effective meetings

· Agile Zone ·
Free Resource

[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.

Since I posted last week about using a simple kanban to structure workshops, I’ve used the technique with several other clients and have made some subtle but useful improvements.

Here are the key improvements:

  • Making time constraints explicit. Ask everyone at the start of the meeting “are there any time constraints you have?”. Write a post-it for anyone that is coming late or will be leaving at a different time than the others. Use a “time constraints” column between the “to do” column and the “doing” column, where the post-it notes are queued in time order.  Placing the column here allows people to see what time constraints need to be considered when choosing the next most important topic.   If there are known breaks such as morning tea or lunch time then put these in the queue as well. As the time constraint is reached, then pull it into the “done” column (this means the done column can be read from top to bottom as a hi story of the meeting).
  • Defining key questions on the “to do” column. I’ve been writing the key questions to ask when focussing on the “to do” column. The benefit of making them explicit is that it has been easy to ask someone else to “run the board” and facilitate the meeting. This has been useful in giving clients the ability to practice running for themselves, which is more powerful than me demonstrating it to them. The key questions are:
    • Is there anything else to add?
    • Is there value in re-ordering the backlog (to do queue)?
    • What’s the next most important item to start
  • Adding an “any actions?” exit criteria to the “to do” column. Once the agreed time limit is reached, or earlier if anyone feels the current topic has finished being discussed, ask “are we done? would anyone like longer on this current topic?” if there’s no agreement about adding more time, then ask a second question “Are there any actions we need to record?”. If any actions are needed then these are added to the “actions” column.
  • Add an “actions” column to the right of “done”.  I’ve added an “actions” column to the right of “done” where any actions agreed in the discussion can be put.

photo (5)

Having run four or five workshops like this in the last week, it is critical is to be strict on not allowing discussion to continue once the timer has gone off (I use the marimba noise from my iPhone’s timer and deliberately let it ring several times if people are talking past the time). I stress that it’s OK to propose to take more time and to see if there’s consensus (by asking ‘Does anyone have a concern if we continue for X more minutes?’), but allowing people to keep talking makes it too easy to continue talking too long.

Some other observations and things I’m experimenting with:

  • Estimating times. In a few situations I’ve tried asking people to estimate how long they think a topic will take. This can be revised before the task is started. Once it is started the time can be updated by adding “+5” for example, when five extra minutes are added. I’m just experimenting with this at the moment. It has been useful at highlighting that a group has been underestimating each topic, which made people add more realistic times to future topics.
  • Inviting people to write the post-it notes, re-arrange or track actions themselves. Several times I’ve found myself doing the work for the clients, by writing the post-it notes, re-arranging them or tracking actions. I believe that the effectiveness of this approach can be enhanced if the participants have the experience of doing the work for themselves. Also, it reduces the possibility of error by writing the wrong thing.
  • Add a section for “policy changes” under the “actions” column. I’ve also been experimenting with “policy” changes for agreements around how the team might be working. I use the format “It’s OK to …” An example from a client this morning was “It’s OK for tasks to move tasks back into ‘to do’” or another one “It’s OK to split a larger task into smaller ones at any time”
  • Keeping a cumulative flow chart. This morning I was working with a client who wanted to try using a cumulative flow chart to record what occurred on their team kanban board. In order to illustrate, I got them to hand-draw the chart (see last week’s post on using three forks on a hand-drawn cumulative flow chart as an example) by counting the number of post-it notes in the columns (we ignored actions as these were by-products of discussing topics, rather than topics themselves). The client reaction was great, with the manager saying “I completely get what the chart is about now” and the result was we only need to spend two minutes actually talking about it (to help others in the team check their understanding).  Here’s the chart they produced:

photo (6)

Client Response
The response from clients has been really positive to this approach. The client this morning said they were amazed how much they achieved in a short workshop. They also said they felt more energized from that meeting than they had when we’d done a longer meeting without using this kanban format!  I’ve also used it with little or no introduction in meetings and it’s been very successful.

I’d welcome hearing further about your experiences, or your views on what I’ve mentioned, in the comments.

[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}