I popped into John Stevenson “How to build a kanban board” session at skills matter last week. It was a packed session with good participation, it would have been great if it was a longer session.

My key takeaways:

  • Kanban can fix problems, but not straight away
  • The board will show you what your problems are, you can introduce changes and see if it improves.
  • Do what helps, not hinders.

I wanted to capture the steps that John went through in the class, so this is my take in what John covered and his facilitation approach.

Facilitation & Preparation

There was really good preparation, there was a visual representation of a dummy company to stimulate conversation, there was a retrospective board, and a meeting kanban board to visualise the agenda.

Here is a sample dummy company diagram , similar to the one that was used.

A.c.m.e company

This is a designed to represent a complex scenario, (feel free to drop me some comments to update it).

Lets create your board

If your going to do this exercise with a team, here are some suggested steps to take:

  1. Identify the business goals – Key for the product manager or owner to get his/her vision across.
  2. Create a shared product mission- to get the team on board, a useful tool is to create a product box. For the supplies,  you can pick them up at staples along with some pens and stickers. Get the team to break up into groups of four to six (this works best with cross-functional participation). The team creates their vision of what the product will look like, with the box, decorating the front and the back, a product name, a logo, a strap line,  some key bullet points to sell it, perhaps a user guide or user reviews on the back.
  3. Define the resources – How many people are available in each stage of the system ?
  4. Make the board -  you will need, pens (big ones are better, people write less and bigger ), tape and a big wall. Its important to note, there is no wrong board , there is no right number of stages. You can always add more or remove a stage if they are not working for you. Some guidance would be: to add some stages if your not seeing progress on a frequent basis, and if your updating the board to much, it might be time to simplify the board. The great thing about kanban, is that the trigger points , frequency and the time spent updating, are unique to you and your team, you get to define them.
    You can add swim lanes to signify groups, features or perhaps releases.
  5. Next value stream mapping – we did not get the opportunity to go into to much detail, but the quick version is identify how long an item of work takes, and how long that item of work stays in a stage. for more information check out the limited WIP Society.
  6. Review the flow -  Getting flow establish is a key point. You ideally want a nice balanced flow, aligned to your WIP limits. This is not a one time activity, you will need to set your WIP, and review to see if there is flow, or any slack or bottlenecks, it may take some tweaking and time to get there. One of the benefits of flow is that if you can manage to get the requirements to be similarly sized within reason, you no longer need estimation workshops, as your predictability will come from the throughput….we do X number of items per time slice. It is an advanced technique and will require a good sell to the business, depending on your agile attitude within the company.
  7. Identify the bottlenecks – Now that we have the system in front of you, have a go at identifying the bottlenecks. Does the work look evenly balanced between each stage given the numbers of resources available in each stage ?
  8. Get feedback, fast- Kaizen, continuous improvements. Have some brainstorming sessions to identify possible solutions. A good technique is the “yes,and” technique, that comes from improvisation. The premise is that if we say yes,and that ideas will flow more freely. You might find it useful to ask one person to scribe the session, and then let the rest do the talking.

Some discussion points during the session:

For me it depends what you want your developers to spend time on. If we can get the requirements or stories into the same sized groups, ie small medium and large, then we can track the throughput, for example, 5 smalls a week, or 3 mediums. This is not to say you cant use story points, and if your teams are comfortable doing that type of estimation, then there are probably bigger issues to solve.

Based in the conversations during the session, people found that standups got shorter, and in some cases stopped, and in most cases only really focused on discussing blocking issues. This is due to the board being updated JIT, so if you want to know the current state of things, look at the board. This is dependent on the team being more disciplined then in scrum.

Team reps
One of the other points made was about managing dependencies with other teams, eg what happens if you need team 2 to finish a story or fix an issues to enable you to proceed. In this case the team might nominate a representative to attend other team stand ups on behalf of the team and then report back to the team.

Bugs and defects
I like the strategy John came up with. If it’s a quick thing to fix, call it a bug. If it’s a big lump of time, call it a defect. Bugs should be fixed asap, the QA should have a chat with the dev and the dev should ideally fix it there and then. Given the limited wip, the dev will still have context. If its a defect, stick it on the backlog with the other work.

All in all, it was a great session, I look forward to more of his talks.

Tagged with →  
Share →

7 Responses to Building a kanban board – with John Stevenson

  1. Great example of how to build a kanban board with a client. Very great tips and insights! Thanks for sharing~

  2. [...] You can read more about Building your Kanban board here. [...]

  3. smartQ Team says:

    check the upcoming kanban tool – smartQ ( http://www.getsmartQ.com ) as an alternative to a physical board (for distributed teams).

    We already designed the security to allow custom roles that can move tickets to a certain stage and not beyond it (ex: developers can move till “testing”)

    The beta is coming out soon. We hope it will help more teams to embrace Kanban.

    P.S. We just ordered the “Kanban” book – how do you like it?

  4. Audrey says:

    Hi Cuan,

    You mentioned in earlier posts about Scrum/Kanban hybrids. You may not have seen this yet but it’s a hybrid of such suggested by Corey Ludas, namely Scrum-ban

    He’s also written a book on the methodology which I haven’t read yet but might give you some food for thought.


  5. [...] I had two good articles http://agilescout.com/kanban-is-great-for-beginning-agile-teams/ and http://www.cuanmulligan.com/2010/10/04/building-a-kanban-board-with-john-stevenson/ in my bookmarks to quickly help me in supporting a trial use of Kanban or Crystal Clear in a small [...]

  6. Liked the post very much.

    We did put an attempt to write on Kanban Board and visualization while ago

  7. Jacke says:

    This post was really helpful for me. Thank you so much. Speaking of tools… I have my favorites: smartQ (mentioned before), kanban pad (https://www.kanbanpad.com/) and kanban tool (http://kanbantool.com/).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop us a note so we can take care of it!

Now Reading

Planned books:

Current books:

  • Training from the Back of the Room!: 65 Ways to Step Aside and Let Them Learn

    Training from the Back of the Room!: 65 Ways to Step Aside and Let Them Learn by Sharon L. Bowman

Recent books:

View full Library