For a while now we’ve been using scrum, an agile software development method, on some of our projects. That is, we’ve used what is commonly called “scrum-but”. When we started out, we stuck very closely to the principles and procedures of scrum, but quickly – just weeks or months after starting – we found we had to tailor the method to fit the needs of the different projects. Along the way, we tweaked and changed things (sometimes even coming close to using a waterfall model, which is antithesis to agile development).
After more than a year, few things remained of our initial Scrum ideals. We were still using a task board, daily stand-up meetings and retrospectives; but we weren’t time-boxing, doing story estimates, calculating velocity, having the customer prioritize work on a task-by-task basis. We didn’t really know what to call it anymore, but it worked pretty well for us.
Then we started looking into Kanban. Some of it felt very familiar, since we were already doing the same things out of necessity – such as kaizen, the regular improvement of the work process. Other things we’d been doing, but not consistently – such as visualizing workflow. Most importantly, the method gives you permission to modify and change things until they work; it’s about taking your existing process and improving it.
Right now we’re in the middle of transferring one major project to Kanban, and looking at two more. It’s an interesting experience, and so far the team is very enthusiastic about it. We ask a lot of questions, try to work out how we want this thing to work, and try to find the best tools for the job. Right now, it looks like we might have to find a new tool for our online kanban board (the old one, JIRA/Greenhopper, is not built for the type of flexibility Kanban requires). We’ve looked at our work flow, visualized it, and made a few minor improvements; but we’re taking care not to try to change everything at once.
Small steps, gradual change, and the ability to track progress.