I was introduced to Kanban by Brad Taylor from Rails Machine when we were talking about agile and how to do it in an ops environment where there’s a lot of reacting that’s hard to plan for. Since I come from the product dev world, where releases are easier to plan, Scrum works pretty well.
What’s Kanban? The best introduction I’ve read so far is Kanban Developmnt Oversimplified. I also attended a great introduction to Kanban by David Laribee at BizConf, so some of my thoughts came out of that intro and not the article.
In my own words, Kanban is an agile approach to development where you take away most of the structure found in Scrum and replace it with visual queues for progress. You basically have buckets for things: Planning, Defined (ready for development), Being Developed, Testing and Ready. You place limits on how many things can be in those buckets, which keeps you from working on too many things at once. The visual queues are displayed on a board with columns for each bucket. That allows you, in a small team, to see where your bottlenecks are and where you have availability. I think it’s a great approach for a team of equals, where you don’t really need the metrics you get from Scrum (team velocity, estimates vs. actuals, etc), or a small centrally located team. The physical Kanban board becomes useless when you’ve got remove people, since they can’t act on their own cards or see the board all the time.
If I was running a 3 person shop where we all worked on the same product, I’d do Kanban instead of Scrum. I also think the visual representation of the board – what’s being worked on right now – is a great tool for seeing your team’s current status. We’re trying out Wallsome as our Kanban board (we can’t do the physical board because we have folks in Spain). I chose it because it uses our existing Basecamp data, which makes the adoption cost relatively low for us. I checked out a bunch of other web-based Kanban tools and they all required me to re-enter everything, which I just don’t have time to do.
But, I’m running a team where I need to help people improve. So, having the data I get out of Scrum is extremely important – and Scrum just works for us. We know what we’re working on, when the next release to production is, and can easily communicate that to whoever needs to know. Switching to Kanban would only take things away without improving efficiency (OK, it might, but I’m not seeing how right now). We are going to use Wallsome for a while and see if it helps us keep better track of the flow of tasks during a sprint, but I don’t see us switching to Kanban completely anytime soon.
So, I think Kanban’s great for teams where you spend a lot of time reacting to events outside of your control, small centrally located teams or teams where they’re just starting to get into Agile and don’t have a lot of different projects. But, our team has been doing Scrum for two years, and it works for us. We’re already Agile and have a well-established process (and more importantly, a change management process for those things we just have to “react” to on short notice) with Scrum that works for us. The switching costs at this point are higher than I’m willing to bear.
I agree with this. I have been switching between Scrum and Kanban mode with my team. I use Kanban when we are doing something new that is hard to estimate and when the work we are doing isn’t releasable in increments. After we get into a flow and can define tasks, we switch back to scrum.
We seem to be more productive when we are in scrum mode. Scrum gives us a goal and deadline to focus on. But honestly, Kanban is easier for team leader/manager. Our weekly sprints with Scrum have become a real grind for me. I am constantly falling behind on lining up work so the team can make it successfully through the sprint planning.
How much of the sprint planning to you take on your self vs. your team? I’m also curious about what metrics are helping your team members improve. Accuracy in estimating tasks is about all I have found useful.