With a team I work with (the inspiration for starting KanbanWP, in fact) we adopted a Kanban board for project management. We were only a team of four, so anything else was overkill. But alternately “nothing” wasn’t an option, as other people wanted to see what we were working on.

For a week we used a board at face value with no rules, assuming the flow would be self evident, or at least work itself out. But questions came up pretty quickly – if a task makes it to QA and doesn’t pass, should it be reassigned? Moved backwards? That sort of thing. So we locked ourselves in a room for a couple hours.

A room full of developers can be a good thing or a bad thing. Developers love rules, so we quickly came up with a process of a dozen steps or more. Developers also love exceptions, so the dozen steps expanded into two dozen, with contingency plans, logic loops, and panic buttons.

After living with that for another week, it became clear that it was good to have contingencies, but a few rules worked most of the time (80/20 rule). I won’t list the rules here because they were specific to our flow. And that’s kind of my point.

A Kanban board is a tool, and a physical (or at least visual) part of a bigger process, much of which is not tangible, and might be fluid. I hadn’t realized, but a Kanban board can be used in nearly infinite ways. To use the Kanban board required us to have one big conversation, and then a lot of little conversations, to figure out how best it worked for us. And then we kept talking about it.

So if you’re going to introduce a Kanban board to your team, or try to use it with a client or contractor, just setting it up won’t be enough. Define what you each want to get out of it, actually write down some rules, and *then* get started. And then revisit those rules as you go along. It doesn’t have to be time consuming, but I think it’s really important to stay aware.