It is Kanban time!

Hello all!

This weeks topic is Kanban!
This is my interpretation of Kanban, and how I implemented it during my projects.
It is by no means, a set of “rules on stone” or a guideline on how you should implemented, just my experience with it.
To start, here is a little history recap:
It was invented by Toyota to reduce cost, mostly on storage.
Parts for cars were only ordered when there was a need for them, keeping only a few on stock to maintain the supply chain working.
On Agile Development are many tools and methods, and Kanban is just one more of them
The first time I got presented to Kanban was in Barcelona during my internship at Xperience Consulting. One of the UX consultants, Jordi Galobart was the “kanban guy” and he was in control of it, making sure everyone was following the rules.
At the beginning it look only like a small scrum to me, but after a couple of weeks, a day that I had nothing to do and got told to “look at the board and select something” i understood why they were working with this.
Work here at Snitker Group is more “personal” but we do need to interact with each other and at some point work together on different projects, and in such situations when having a well organized kanban will come handy.
About “my” version of kanban:
Since there are so many ways to implement it, and it will change from team to team, I will like to show you what is the method that I used and that I think could be implemented at the office.
It will be nice to give it a test run and then correct/improve the way it was implemented
But why Kanban? what does it make it a good option?
Well, there are 5 main characteristics of Kanban:
  1. Visualize the workflow: A quick way to know were all the different projects stand
  2. Limit WIP: Limiting the amount of work done in every step requires a “pull system”. The work will only start once there is place in the next step to receive the task
  3. All should be report, measure and reported: keeping the flow constant and giving feedback to correct problems on the early stages will increase productivity
  4. Policies should be explicit: setting the rules of the game from the beginning .
  5. Improve collaboratively: everyone is part of the process.
First of all, there is the board. This one can be a physical board, or a virtual one on a server.
The board will be divided in different steps and tracks
Steps are the different parts of the development process, or stages of the project.
Tracks are the projects.
The steps could look like this: (and again, this is only my personal preference)
1 – Backlog: Here are all the tasks that will need to be done to finish the project.
It is important to divide the project into manageable tasks and nominate them properly. There is a blog that needs to be written every week? well, for this problem, i called the task “Blog week 7, instead of just “writing blog” By adding the number of the week, i am making it more specific and easy to differentiate from other blogs that i might need to write in the future.
2 – Inbox (or selected): Here is were the work starts. Depending on the team is necessary to establish how many tasks will be done at the same time. If it is a project done simultaneously by different members of the group, having a  3 or 4 tasks per step. If its a project done by only one person, limiting the number to max. 2 will be a better approach.
3- In-Progress: The name says it all. The task once they have been selected from the backlog and place on the inbox, will be passed to this step, to be develop.
4- Feedback: Once the task has been completed, it is moved to the “Feedback” step. Now, another task from the inbox can be moved to the feedback.
As with the other steps, there can be only a limited number of task at any given time. If for some reason there is a task that has not been given feedback, instead of just taking another one and develop it, the person in charge of that will work on this step to clear the way for the next task.
5- Done: After been reviewed the task will be place in this step, meaning that it is done.
The Tracks
Each Project can be divided into different tracks. For example, let’s think of a simple user test that will include an user research and to be published:
Track One: User research
Track Two: User Test
Track Three: Publishing
Each track can be develop simultaneously depending on the tasks.
To follow the example, for the user research track this could be some of the tasks: Cultural Probe, Survey, .
For User Test: set up lab; find users; select the method; Develop Personas; results
For Publishing: format; editing; proof reading;
Obviously there is nothing that can be proof read at the beginning go the project, but the format and style of the report can be decided early on the process. Same as the method selected. Will it be a RUT, or a think aloud?
Working on the personas could be done only after the survey is finish and the results are available.
In this case, it looks a lot like SCRUM, but instead of having clear cut iterations, the process is a continues flow done by small increments.
Well, this is the basics of “my” kanban. Comments are welcome!
Here are a set of links (including a free eBook) that will get anyone interested a good start!
An excellent eBook from Henrik Kniberg and Mattias Skaring.
This book has been my “go to reference to understand how Kanban works. It is divided in two parts, the theoretical and the case studies.
A good article by Karl Scotland, full of great insights
From Agile Journal, a good comparison between Kanban and Scrum.

Leave a Reply

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

5 + = ten

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>