In the last chapter: A small team was built and they tried to set up a methodology for building their projects. After establishing a set of techniques and trying them against first couple of projects they faced a list of issues. They realized they needed something more. How would they deal with the problem? What would be their choice?
When I read Henrik Kniberg’s article Kanban vs Scrum it was first time when I thought I get the whole idea. I even thought it might work for our team but if you know me a bit you know I’m very reluctant to drop anything we’re currently doing just to try out this new cool idea I’ve read about yesterday. This is by the way the most important reasons why a few engineers with great potential I know will never fulfill this potential. They just can’t hold their horses whenever they read about new jazzy technology. And it doesn’t really matter whether it does any sense to implement it.
Anyway I finally decided to give Kanban a try since I believed it would solve both of our main problems. First Kanban limits work in progress (WIP) by design. Second having open backlog where I could put any incoming idea should help me with dealing with all different threads happening around our group and at the same time I should be able keep modifying priorities pretty easily.
What more, Kanban shouldn’t put on us much of constraints which would be invited by most of other methodologies. As lightweight as possible, as little bureaucracy as possible. Kanban suited well.
I checked team’s opinion about starting something new which would help us. When I described Kanban and prompted for feedback I got green light although I can’t say they were enthusiastic whatsoever.
A decision was made.
Read the whole Kanban Story.