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

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.

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.

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)

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.