Lately I’ve been busy with a brand new assignment. A new solution is being tested from the feasibility point of view; a prototype of the system has to be created by the middle/end of next month. Team setup is not very complicated: two guys are doing server side thing, two guys are working on GUI, one guy is taking care for test automation and automatic testing.
Not very agile, though. Prototyping in my opinion rarely is. In this case, too, we, server-side guys don’t touch GUI and vice-versa. So, everyone is busy with their part. No cross-functionality so far, which is not a bad thing right now. Decisions (about technologies, frameworks etc.) have to be made quickly, so the prototype has to evolve quickly.
The other day, an idea came up that we should work and behave like a Kanban team. Hm. Let’s see why I don’t think this is a very good idea. For this, let’s see the five core principles of kanban:
Visualize the workflow
The prototype is a one task at a time project. Server side always has one task, GUI one task, Tests one task. Would a Kanban board make sense with only two columns (doing, done)? Well, putting a task from doing to done is not really workflow. Not taking into account that a new task always comes in when the old one is finished. So even a queue column would be a waste of space.
One task at any given time. That would mean a WIP of three above the doing column. Why would I impose a limit over a column that is ‘guaranteed’ to be containing three tasks each and every time? Any lower limit would mean one part of the prototype is stuck, any higher would be a waste. So no WIP limit really needed.
Which would mean ‘help others if they’re stuck’. But as I described above, everyone is doing their own tasks only. So server guys cannot expect help from GUI experts and the same applies the other way around.
Make Process Policies Explicit
Like for example definition of done. But since this is a prototype, the only definition of done is “it works”.
As it will only last for one more month, after which there will be a major restructuring of teams, there’s no space and time to experiment with the process. Any new idea would take longer to kick in than the time we have left.
So, after all, all the kanban principles are more or less useless or violated. We are a victim of what I call ‘find a method and use it ever after’. Sometimes we value a known process so much that we tend to use it even in cases when we shouldn’t. So in this case, I guess, we can do just fine without implementing a violated-kanban. Which is, of course, not the case once the prototype is finished .