Kanban, as any other methodology, isn’t a silver bullet. There are situations and teams when it shows its full potential but there are others where its impact will be limited. Where Kanban suits best then?
Micro-sized teams
It is said Scrum works best with teams of 7 or close to this size. Sometimes we deal with smaller groups. 3 people working on a project isn’t something very uncommon. For such micro-sized teams Scrum is often too formalized. You can limit a number of rules you follow and still keep good quality. And you have a bit more time to do the real work.
Frequent priority changes
“Walking on water and developing software from specifications are easy if both are frozen.” Unfortunately we deal with a lot of changes as we build software. There are new features; importance of tasks changes, new top priority bugs requires instant attention. Our response is moving to more flexible approaches. We try to avoid BDUF projects. We switch to agile methods employing short iterations. We even make iterations shorter and shorter. It allows us to change priorities frequently. Once every couple of weeks if we take typical Scrum implementation.
The problem is when priorities happen to change even more frequently. Once every few days. Or even every single day. And yes, there are such projects. Kanban is a great answer for them. Feel free to change priorities every day. As long as it is well-grounded it shouldn’t ruin your project.
Maintenance projects
A typical maintenance project routine looks like this:
- Whenever high-priority bug is submitted fix it as soon as possible
- Low-priority bugs becomes high-priority ones when resolution deadline approaches; then see above
- Whenever a client orders change request (CR) and there’s no high-priority bugs – try to do it as soon as possible
- If there are more than single concurrent CR ask project manager about priorities
- If there are no bugs or CRs do some refactoring or other improvement job
Sounds like ideal Kanban playground, doesn’t it? That’s typical case of event-driven development (not event-driven programming) where you don’t actually have a roadmap or something but you do whatever new day brings. After all you don’t expect to have a bug submitted tomorrow, or do you?
Multiple small projects
Working on several rather small projects or sub-projects with the same team at the same time is pretty difficult. Resources (what a nice name for your people) are usually insufficient since it is harder to synchronize stream of small orders to keep it at the same level all the time and bringing more people just-in-case isn’t the best business strategy around. This ends up with (surprise, surprise) a lot of priority changes and trade-off games. “We can complete this additional project on time but we’d fail to meet a deadline here or there.”
With standard structured project management approaches coordinating different threads with ever-changing priorities becomes pretty much a hell. What Kanban does is it organizes workflow so the main, well almost the only, thing you should care about is setting priorities at the beginning of workflow.
Common part
The common part for all of environments above is they don’t require many constraints to work. Few simple rules which come with Kanban should be enough to get things done. Another common thing is mid- and long-term planning is hard or even close to impossible, which is another problem hardly resolvable with more structured approaches. These two things are the most specific for environments where Kanban shows its full potential.
This isn’t really a post which is a part of the Kanban Story but if you found it interesting you should like the story as well.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
9 comments… add one
We found the same … I made some similar observations a year ago — http://www.onesandthrees.com/2009/05/kanban-for-a-small-team/
I can definitely attest to the “frequent priority changes” benefits of Kanban. The ability to have the product owners fight within their ranks over what is the most important thing next given a fixed resourced dev team with clear visual representation of the “cost” of shifting priorities is exceedingly valuable.
Thanks for link to the article, Andy. I had very similar experience with one of micro-sized teams.
John,
I always found “client knows better” rule as a valuable one. And in terms of software development team client is often impersonated by some product owner/project manager/salesman/other priority setter. That’s why I’m a strong proponent of giving these people tools to steer software development in a way they wish. The only issue is to make them aware of the cost of using these tools, i.e. very frequent priority changes result in suboptimal performance, adding a lot of stuff heavily impacts schedules etc.
As long as you have a reasonable person as a priority setter it usually works well. And it isn’t really about Kanban. Kanban just incorporates this kind of process which keeps everyone on the same page.
Nice article. I agree completely. Maintenance projects are a great fit for Kanban. I put together the bigger picture on Scrum and Kanban here: http://www.agilitrix.com/2010/05/scrum-or-kanban-yes/
My experience is a bit different though I agree that maintenance / operations is excellent place to apply Kanban.
Here is what we’ve done:
http://huitale.blogspot.com/2010/03/huitale-way-our-value-stream-map.html and http://huitale.blogspot.com/2009/10/huitale-way-is-it-scrum-or-is-it-kanban.html
If you’d like to share some thought about that please contact me on twitter or comment the blog: @markotaipale :o)
Nice posts on Kanban, thank you :)
Out of interest, if you have small teams tackling multiple projects, do you have one board per project?
We have a few small teams (2-4 people) doing 1-3 projects each. Each project is typically 20 man days effort, scheduled over a 30-60 day schedule.
We also have small amounts of maintenance work.
Some projects are also 2-3 day research projects with 1-2 people.
We’re not doing Kanban, but are looking for practices that will let us not drop the ball when dealing with these projects.
Tobin,
We have one main projects and a couple of small side projects right now (it seems to be changing though). However I’ve worked in environment similar to what you describe in my previous job. Although we didn’t have Kanban back then, and I wish I knew Kanban few years ago, it was exactly the kind of organization where Kanban should suit well.
In that organization I’d start with a single board for all projects with multiple colors of sticky notes, one for each project. The reasoning behind this design would be that people were changing projects pretty often and depending on how many folks were working at the project at any given moment we’d need to change limits for the project frequently. On the other hand if we had limits set per whole team they should be fairly stable, no matter how many project we deal with at the moment.
That is what I’d start with. The rest would be experimenting like crazy since this is the only way you can get closer to more optimal design of the board.
One more thought: we didn’t have people formally spread among small teams, so you may say there was a team of like 20 developers and another team of tester etc. If your teams are rather separated from each other and they don’t work with other teams often having one board per team may work for you even better.
Does it help you? Feel free to catch me on email if you need more advice.
Hi Pawel
Many thanks for the detailed reply.
I really like the idea of coloured cards for each project.
Like the idea of experimenting, we’re engineroomapps.com V1.3 right now and continually review & improve our processes, it’s fun :)
Thanks for sharing your email, if we have questions I’d love to pick your brains.
T