Kanban Boards
Kanban Boards
This presentation will show how to adapt Kanban in your development project.
There are quite a lot of slides and quite little text on each slide and the whole idea is that you should go through the slides
quickly and a little animation effect will take place.
About us
• Avega Group
One of the good things of Kanban is that it’s a evolution, not a revolution. You can adapt Kanban step by step.
Start from your current Scrum board and enchance it to reflect your process.
Actually - it will be many slides down before we will doing something that not fit inside Scrum.
måndag den 19 juli 2010 (v.)
So a good starting point could be to visualize your workflow. If you are working with Scrum you are doing that already.
But maybe it could be a little more crisp than Todo, Doing and Done
måndag den 19 juli 2010 (v.)
Often you start by analyzing a story, so lets a put a column to represent that work.
- what’s included
- how should it be solved
- break down into task
- etc.
måndag den 19 juli 2010 (v.)
And then we’ll add a column for the development of the story
måndag den 19 juli 2010 (v.)
And finally we need to verify and test the feature so that we are sure that the quality is good enough for our team to release.
måndag den 19 juli 2010 (v.)
One way of handling handoffs between specialists is to introduce queues so that work is buffered. In this way the next step can
see when things are ready to be pulled from the Done-queue of the previous step.
It doesn’t have to be hard specilization - even if it’s roughly the same people doing the work this can be useful to visualize the
flow. So that we can where blockage, uneveness and other problems occur.
måndag den 19 juli 2010 (v.)
Let’s add a done-queue for development, to give a signal to Test when new work is ready to pull.
In this case we added the Done-queue in the Development-step. You could also argue that it should be in the Test-step and be
called “Ready for test” or something.
måndag den 19 juli 2010 (v.)
We now have our (simplified) work flow setup. Now it’s time to decided how to limit how much work we will allow to be in
progress at one time - to Limit our WIP.
There are some different approaches to come up with the total number for that:
- 2 per person, so that you don’t get blocked. A bit less maybe. We don’t want everyone to be blocked
- Equal to the number of persons in the team
- The number of persons divided by 2 for experienced agile teams
- Start from the bottleneck, the number of tester for example
We have limit Work in progress for Analyze to 2, Development to 3 and Test to 2 features at the same time.
We have no limit for our backlog, Todo - but you very well could, to limit the flow into the system.
Kanban-board
A normal flow
Work is pulled from the backlog into the Analyze column as the WIP-limit allow.
måndag den 19 juli 2010 (v.)
You could wonder what Dev and Test is doing in these early stages of the flow...
Well, the start will get a bit bumpy since no work are ready to be pulled. But this is for the very first time only, since a Kanban
board never will be reset. In Scrum, for example, this situation is likely to occur in each sprint.
måndag den 19 juli 2010 (v.)
Follow the WIP limits and only pull new work to your capacity
måndag den 19 juli 2010 (v.)
måndag den 19 juli 2010 (v.)
måndag den 19 juli 2010 (v.)
As we can see...
måndag den 19 juli 2010 (v.)
... each step is only pulling work when it’s done ...
måndag den 19 juli 2010 (v.)
Now the development of the last feature is done and we’re ready to do the last bit of testing
måndag den 19 juli 2010 (v.)
The testers are working along to bring our goodness to the customers.
måndag den 19 juli 2010 (v.)
That wasn’t to educating since everything went well. It was good - but not educating...
How do we handle problems? Let’s reset the board to a problem situation and find out.
måndag den 19 juli 2010 (v.)
Here all columns are fully loaded. Test is up to their limit and Development is finishing off the last story.
måndag den 19 juli 2010 (v.)
Actually, the Development team want to pull some new work. They are sitting idle...
måndag den 19 juli 2010 (v.)
But we cannot allow that - that would break their Work in progress limit off 3, now wouldn’t it?
måndag den 19 juli 2010 (v.)
So here we have a bottleneck in the Test-step. We want to move things along, but since Test are up to their WIP-limit we cannot.
What’s good is that queues like this doesn’t happen instantly. You can see it build up and you can react to prevent it. The queue
is a “leading indicator”. Compare that with burndown in Scrum which is an example of an trailing indicator that gives you the
figures on how thing went.
The analyze don’t have anything done and Development is idle with no more work to pull.
måndag den 19 juli 2010 (v.)
This of course not good either but is another leading indicator. You can see when it’s about to happen and maybe react early,
rather than face the figures afterwards.
Kanban-board
How do I draw new work?
But how do I draw new work? What are the strategies and rule I need to adhere to?
måndag den 19 juli 2010 (v.)
Here is Joakim - the tester - ready to complete the feature is testing right now.
måndag den 19 juli 2010 (v.)
Since there are work in progress in his column - the testing Marcus is doing - he should first and foremost see if he can help to
finnish the work that is in progress.
What now? Both Joakim and Marcus is ready for some more work. Nothing to finnish in their column.
måndag den 19 juli 2010 (v.)
But there are new work to be pulled from the Done-queue of the Development team.
måndag den 19 juli 2010 (v.)
Here is a case where Marcus, the tester is left with no work in his column AND no new work to draw.
Mikaela apparently wants some help, to get the item she’s working on ready for test...
måndag den 19 juli 2010 (v.)
But... we have a bottleneck in Analyze. They are fully loaded and no new work is flowing from them.
Both Joakim and Black-And-White-Marcus is working. Could Full-Color-Marcus possibly help over there?
måndag den 19 juli 2010 (v.)
In this way they can resolve the bottleneck and move it to ready for development.
måndag den 19 juli 2010 (v.)
But, if he couldn’t have done that either? What should Marcus had done then?
Well - find other interesting work maybe. Prepare that automation of tests or get that pesky build server to run faster. Something
to help the team.
Strive to not draw new work. You could, and break your WIP limits - but remember that then all work to come will suffer and take
longer time to complete.
Kanban-board
Inspect and adapt
We will now take a look on how your Kanban board can and should evolve over time.
Say for example that you want your product owner to accept all items before shipping them.
And since the product owner is what is called a Non instant availability constraint we add a queue for things that is ready to
accept.
måndag den 19 juli 2010 (v.)
The product owner cannot be with us all the time, but when she’s here she can accept many items at once. It doesn’t take to
long.
and as you see all items are quickly accepted when she had the time to sit down with and do it.
Kanban-board
New member in the team
Here is a situation where it’s not possible to share work and all Developers are busy on one feature each.
måndag den 19 juli 2010 (v.)
And suddenly a new Developer is added to the team. Mikaela is newly employed.
This could also be a indicator that the WIP limit was to low to start with.
Kanban-board
Work Item Types
With different work item types you can visualize how different kind of work should be treated in different ways. To enable the
team to easier be self managed.
måndag den 19 juli 2010 (v.)
Up to now all the items on our board looks and are treated the same.
måndag den 19 juli 2010 (v.)
Now it’s more visual to us what we are working on. If the board goes all read with bugs we know that we’re having a quality issue
for example.
To remind us and others the colors meaning we could add a legend or key for the different items.
Kanban-board
What is on a card?
The cards we’re moving around could also communicate a lot of information.
måndag den 19 juli 2010 (v.)
First and foremost it should describe the feature. In this case in the form of a user story.
måndag den 19 juli 2010 (v.)
It could also be used to limit work in progress since you only can put your avatar on one card.
måndag den 19 juli 2010 (v.)
Here is a hard deadline added to the card - so everyone knows how we are doing against it.
måndag den 19 juli 2010 (v.)
If an electronic system exists with more information you could add the id of the item.
måndag den 19 juli 2010 (v.)
“Stamp” the date of each stage to get data for lead- and cycletimes that can be used to create cumulative flow diagram for
example.
... which makes room for another avatar, for when you pair program for example.
It also forces us use ladders to move the items around on the whiteboard that holds these big cards :)
Kanban-board
Classes of Service
If we want our team to be self organized, we need to help them to know which feature to next.
With classes of service we get a prioritization and policy approach that can help team members to chose their next
work item.
måndag den 19 juli 2010 (v.)
A common situation is to introduce an expedite/urgent/silver bullet for things that is need to be prioritized over
other work.
måndag den 19 juli 2010 (v.)
A common policy for urgent features is that it should be prioritized over all other work. Just let go and start to work
on the urgent feature to move it quickly through the whole process.
måndag den 19 juli 2010 (v.)
Phew - the developers were quick. The item is drawn by the tester and get going on it immediately.
måndag den 19 juli 2010 (v.)
So here we should strive to have 50% features, 12,5 % (1) technical stories, 12,5% maintenance and the rest bugs.
måndag den 19 juli 2010 (v.)
And with that policy in place Marcus, the tester, can easily see what the system should be filled with.
A maintenance features since there are no maintenance features left in the system now that he finished one.
måndag den 19 juli 2010 (v.)
Test-Marcus is ready to draw new work. There are two items ready to be pulled.
Which should he chose?
måndag den 19 juli 2010 (v.)
The maintenance features (light green) has certainly been in the queue long, but we have a policy in place that tells us to always
prioritize features (yellow) above maintenance.
måndag den 19 juli 2010 (v.)
We all know the ceremony during a Scrum Daily Stand up. But is there a difference now that we’re doing Kanban?
Notice that we’re still within the limits of Scrum - everything we have done so far can still be referred to as “doing Scrum”. It’s a
bit advanced but still.
The major difference in Kanban standup is that the meeting facilitator enumerates work, not people.
The board shows the status of the current work, queues and bottlenecks.
When enumerating the work it is useful to traverse the board from right to left (downstream to upstream) in order to emphasise
pull.
Kanban-board
Managing defects
This is one of the most common questions we get when doing this presentation. Here is some different strategies for handling
defects.
måndag den 19 juli 2010 (v.)
3. And place it in ready for development. Or maybe in Todo since it probably needs to be check by the designers and analytics
team before development.
måndag den 19 juli 2010 (v.)
4. Work on something else in the meantime. Given that Test-Marcus cannot resolve the issue himself.
måndag den 19 juli 2010 (v.)
2. and call for help. The whole team is “swarming” on the issue and work together to resolve it.
Kanban-board
Exit criterias
You could further help the team in running the process with exit criterias for each column
EXIT
CRITERIA
måndag den 19 juli 2010 (v.)
By defining exit criteria for what is needed to move items into the Done column, we can reach a standardized work
Kanban-board
Order point
We have now reach the point where you cannot call it Scrum anymore. We will start skip sprint planning and timeboxes and start
doing our planning just-in-time
måndag den 19 juli 2010 (v.)
Start by filling the Todo-column or backlog with as many as the team usually comits to for a sprint.
måndag den 19 juli 2010 (v.)
Release the planning from the release and retrospective cycle and start planning just in time.
måndag den 19 juli 2010 (v.)
Maybe once every week or when event driven with an order point when new items should be added.
måndag den 19 juli 2010 (v.)
When all the items above the order point is moved the rest is moved up.
Note the instruction card that tells you to call to a meeting to get new items in the backlog from the product owner. That is
referred to in the industry as a Kanban card
måndag den 19 juli 2010 (v.)
After a while you can use your data and the different work item types to predict how long before an item is release
måndag den 19 juli 2010 (v.)
This is referred to as Disneyland wait times, from the queues at Disneyland that tells you that you only have to wait 30 more
minutes before 1,5 minutes of rollercoaster joy is yours.
måndag den 19 juli 2010 (v.)
Here we can see that the item on top only have 14 days to go before it’s in production
Kanban-board
Other visualizations
... and here is the same team member but sick, in the swineflu it seems but also some stomach disorder
måndag den 19 juli 2010 (v.)
... and here is the same team member but sick, in the swineflu it seems but also some stomach disorder