I often say that you can implement Kanban in your team in a single afternoon. That’s how we did that after all. So when Andy Brandt asked me to do Kanban Basics webinar I expected that preparing it would be pretty simple. How long can you talk about few-hour-long task?
Well, it wasn’t as simple as I expected.
Kanban itself is very simple. But telling people they should visualize workflow, limit work in progress and measure the flow isn’t really all the basic stuff they need to know. After a while it always ends up with questions how we do this and how we do that.
What limits should be set on board?
What happens when a bug is found during testing?
Should sticky notes be moved back on the board at all?
How cycle time is measured?
What happens when the limit is reached?
What to do when emergency task pops up?
How to cope with multiple projects?
Is feature-by-feature deployment mandatory?
How estimation is done?
That’s an interesting observation – I often deal with most of these questions at the end of my Kanban presentations, no matter if I cover basic or advanced material. After giving it some thought I decided this would be a good starting point to prepare Kanban Basics presentation.
What I ended up is presentation below. It covers a bunch of scenarios visualized with (surprise, surprise) Kanban board. Additionally I used Scrum as the reference to make a basic Kanban description easier to understand.
If you have some basic questions which seem to be omitted in the presentation, please leave a comment. I’d be happy to both answer the questions and update future versions of the presentation.
If you speak Polish feel free to watch the recording of the webinar.
Also, check The Kanban Story series as it reveals all the details of Kanban implementation in my current team.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
6 comments… add one
Kanban boards (just recently found out that that’s how those are called – we just have a whiteboard with post-its) is a great way to visualize the work. It has a great value when planning the next steps.
There are a couple of online solutions as well, as we started trying smartQ (http://www.getsmartQ.com) and we are LOVING it!
Could you come up with best case studies of using Kanban board across very different projects. Examples on internet are about software development mostly.
Thanks for sharing with us, Paweł! I still have to take a look at the webinar, but I’ve already seen the presentation. Great work putting the matter in simple terms.
I must have missed it or you probably mention about it in the webinar, but I’m curious about practical cases of dealing with consequent tasks (order). Is there any planning at all here?
Tina,
I can’t come up with examples from industry other than IT. Well I could share a couple of ideas from manufacturing but then it would be only what I’ve heard, not something I’ve experienced.
What more, Kanban adaptation to software development is pretty specific. Folks I know from manufacturing work with something different (yet they still call it Kanban), so I’m not so sure whether we can draw parallels between these two.
Regarding tools: as long as the team sits in one room, nothing beats simple whiteboard along with sticky notes. You should turn back to software only when you can’t go with hardware board, i.e. your team is dispersed.
Lech,
There are no rules in terms of setting the task order, but then prioritization is the first and most important thing to do for product owner/product manager/however you call them.
That’s a bit similar to what happens in Scrum – you have to prioritize the backlog. The difference is that in Scrum you expect it to be done on the beginning and you accept adjustments during planning sessions at the beginning of a sprint, while in Kanban you do prioritization all the time.
Basically every time there is free slot in todo queue product owner should decide what goes next, which means they should prioritize the backlog.
In real life you don’t prioritize whole backlog every time, but then my experience is the order of importance on Kanban board is changed more frequently than on Scrum task board. Probably the basic reason is that people are just allowed to do so.
And yes, I’ve mentioned it during the webinar.
Hi,
I have question on how we can have Kanban for Automated testing team.
we have automation testing team.we try to implement Kanban .i have confusion on how to organize the columns..bcz all the team members will do all the tasks in all columns..like requiremnt gathring,developement ,deployment ,and i am not sure how to limit the WIP.if we have 5 team members we can have Limitaion 5 on all the columns?
If you have can share some best practice .it would be very helpful..Thanks,
-MJ
@MJ – Your limits should depend more on how many tasks you want to have on each stage, than on a total number of team members. It is likely that, after some time, you will see that the team is dealing with one stage faster than with another, thus if you set the same WIP limit for both you will flood the latter. For example if development takes more time you will likely need just a couple of tasks which you analyze – just enough to have another task prepared when someone is ready to start development.
Considering everyone in the team can do anything you have more flexibility in terms of setting limits. Personally, I would probably go with more aggressive WIP limits than a number of people multiplied by a number of columns – it would mean that, in the worst case, every team member multitask on a few work items (as many as you have columns).
If your team is rarely blocked I would start with total WIP limit per whole flow rather close to 5 (5 plus some padding) and then spread the sum among the stages in a reasonable way. Then, when you see what happens you can adjust WIP limits accordingly.
In either case, don’t try to get WIP limits right on the first time. Start with whatever seems reasonably and then experiment adjusting them. By the way, if you want to have some meaningful outcomes of such experiment, remember to introduce simple measures, like cycle time or throughput.