To some point you’re right. It is really hard to compare XP with RUP. It’s a bit easier in XP versus Scrum as a couple of concepts are similar, e.g. timeboxing, but they still mostly deal with different areas.

I don’t agree however with one point: Kanban is the least of “way of working” out of every mentioned methods. In fact Kanban doesn’t tell you how you should work at all. You can perfectly apply Kanban to pretty much any process, even the most chaotic one and it should work. To some point at least.

So the way I understand it is Kanban isn’t “the way of doing things.” It is more a set general practices which somehow make teams improve. As David Anderson points in the foreword:

“Many of results of Kanban are counterintuitive. What appears to be very mechanical approach – limit WIP and pull work – actually has profound effects on people and how they interact with one another.”

I have a question thow what you, or others think about the following.
You said in one of the chapters that you really understood Kanban when reading the Kanban vs Scrum (http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf) and I agree, it is a good document.

But what do you think about the comparision of RUP, XP, Scrum and Kanban they make in that document? Don’t you think they are wrong to compare all of those?

Wouldn’t it be better to compare Scrum to RUP, that I can fully understand, but leave out XP and Kanban?
I see XP and Kanban much more as ‘ways of working’ then the framework RUP and Scrum try to provide.
Or am I completely wrong?

Of course, the next title in the document is: Don’t limit yourself to one tool… but I wonder what your opinion on this is.

I think it’s reasonable to start with swim-lanes, to divide teams that don’t cooperate at all, but have shared product owner and shared sys admin, and then to experiment with multiple boards.

Thanks for reply,
Valerii

As a rule of thumb I’d go with one board whenever it is possible and does make sense. Splitting the work of a single team among a couple (or more) boards requires significant effort to synchronize all those boards. It’s much easier to reflect specifics of work being done on a single board.

If we discuss different projects you can go with different sticky notes colors. If we discuss projects which are separated technology-wise you can use swim-lanes (example can be found in Kanban Basics presentation).

But then if we discuss completely separated teams (with exceptions of product owner and sys admin) it likely falls into “single board doesn’t make sense anymore” category.

As long as production teams have no interchanging work I’d probably opt for separate board. I don’t consider shared product owner as a big issue, as long as they have enough time to support all teams. The bigger problem is probably shared sys admin. However it may be a wise trade-off to allow sys admin synchronize their task between a couple of boards than to put everything on a single board.

Everything depends on the context. Think which thing is more painful for you. Making all projects (and teams) affecting work of each other or adding one person some synchronization and prioritization work. If teams interact on a daily basis anyway you probably want to go with a single board, but if they don’t you may prefer multiple boards.

Thank you for this Kanban story.
It’s interesting about making tools working for you, in your environment, and not getting stuck with prerequisites/rules.
On Agileee’10 there was a lot of discussions about Sergey Andrzejevski speach “Management of offshore agile projects”, and his practice seems to be similar, in terms of altering tools to make them working in your environment.

I’ve noticed, that on the start of story there was only one project on your Kanban board, however then few new projects appear and you divided them by different sticky notes colors. I’m trying to imagine this in case of smaller teams (different technologies) working on different projects, but one product owner and one system/administrator QA. Do you imagine it as one board for each small team (2-3 developers on same technology), or as one board for all teams?

Thanks,
valerii

In our case this is pretty simple. Since the product is led/managed by a single person (me) it is his (my) responsibility to deal with all dependencies between features/tasks.

Technically I just keep relations between tasks in my head and push prerequisites earlier into the stream.

Actually Kanban does not allow you to skip the proper work breakdown structure. If your tasks/features are planned poorly you won’t get decent results this (or any other) way.

How do you handle dependencies among MMFs in your backlog? Or the face that some MMFs just naturally go together? Do you just group them together in space on the board?

thanks

Comparison of different web tools supporting Kanban is a very good idea but I guess nothing would trump good old hardware whiteboard if you ask me.

If I could give only one advice to any Kanban team it would be: gather in one room and put big whiteboard in a place where everyone sees it.