The Kanban Story: Implementation of Kanban

So you want a story about the most painless implementation of new software development/project management methodology in industry history? Here it goes.

There was nice afternoon, sun was shining and air-conditioning was silently humming. One of our engineers asked me what about this new methodology we were talking about a couple of weeks earlier. So I described them how it works in details telling basically nothing more than could be found in great Henrik Kniberg’s article on Kanban I mentioned earlier. It took definitely less than a half of hour, including Q&A.

Then we drew our Kanban Board discussing which stages we wanted to have. More about creating our Kanban Board in the next post.

The very next problem we have to solve was what exactly we want to move through out Board. We couldn’t decide on a color of sticky notes. I thought classic yellow would emphasize our respect for established rules of software craftsmanship while there were opinions that green would be better since it corresponds with stability of our software and flawless builds we get on our build server… OK, just joking here.

Actually the problem was what granularity we’d use on sticky notes. MMF (Minimal Marketable Feature) is a nice concept but sometimes too vague. Generally we try to use MMF whenever it makes sense but sometimes we use non-marketable features as well. Example? When we had screwed something in database structure we got “fixing up a database” post-it. Unless you freaking darn good marketer this isn’t “marketable” at all, but pulling flawed database with the product all along the way would be kind of a pain in the ass. Fixing it later would cost far more than doing it fast. This substitutes being marketable if you ask me.

To simplify things a bit we dropped using user stories. We decided using inside-out approach which in Tyner Blain article on agile prioritization is described as wrong one. The reason was most of the time splitting tasks in a way which was convenient for our development team created results which were identical with these achievable with outside-in approach (splitting tasks in a most convenient way for a customer). In these rare moments when it did not I could live with that and for me it maked development cycle more reasonable. Yes, I sure am biased with my past experiences as a developer or trying to play as someone like that.

Anyway we ended up rather with old-school features describing (hopefully) fine-enough-grained functionalities rather than scenarios describing how user would interact with the application.

Having this done we filled the Kanban Board with sticky notes showing what we were doing at that moment, what were planning to do and then we set up limits for each column. Again, more on this in another article about Kanban Board.

Basic setup of tools was completed. The rest was to follow few simple rules, limiting WIP (work in progress) being the most important one.

Basically Kanban was implemented and it wasn’t even a time of sunset, which we wouldn’t saw from our window anyway. We turned off air-conditioning and went home.

I know things start to look interesting barely now but feel free to check out the first few parts of The Kanban Story.