The team was in trouble! We’d been managing the project for the previous four months using Scrum. Then, with four weeks to deadline, it turns out we had a stealtholder, ie someone who had the authority to radically change our release plan.
OK, we have a number of new features and a new product owner. What to do?
I’d been reading about Kanban for some time and it seemed to fit the bill. It’s less perscritive than Scrum and could fit into our new workflow.
What is Kanban ?
Kanban (Japanese for card board) is one part of the Toyota production system .
Adapted for software, it boils down to three practices:
- Visualise your workflow
- Limit your work in progress
- Calculate your cycle time
The idea is to track a piece of work from its inception to monetisation. In our case from an idea from the marketing department to measured ROI based on metrics and customer feedback.
Very much like Alistair Cockburn’s information radiator , the Kanban board should be:
- large and easily visible to the casual, interested observer
- understood at a glance
- changes periodically, so that it is worth visiting
- easily kept up to date
We took a poster and drew vertical columns for each of our workflow states: Backlog => Next => Development => Code reviewed => Biz acceptance => Done . Very similar to Henrik Kniberg’s example board:
Limit work in progress
We placed a limits on each workflow state to
- ensure that defective work was passed upstream
- enable the team to pull work from the previous state
The pull system really is the key to the process in my opionion. How it works in practice is, eg if there is are no work in the backlog or next, a developer should go and fill the queue with work from the product owner, marketing department whoever. It is this culture of self organisation and responsibilty that I like most about Kanban.
Calculate cycle time
This one is both really easy and really hard. Keeping track of how long it takes to do a piece of work should be straightforward – right? Wrong! All pieces of work are not the same; some require the whole team, some require copy from the marketing team. We resolved these problems using story points and velocity.
Story points are estimates of a stories complexity or size. We used a scale of 1 – 5; 1 being easy & straightforward, 5 begin a serious piece of archictecture.
To calculate the team velocity, I simply totalled the story points for all of the stories complete that week. I then updated our burndown graph.
Kanban is easily my favourite software development process, lightweight and powerful. Needless to say we used a grab bag of tools from XP and Scrum, such as:
- Code reviews
- Daily stand up
- Unit testing
- Burndown graphs
- Product Backlog & release plan.
One more thing: the more visuslasation you can put on your Kanban board, the better. South park avatars of your dev team, screen shots of the app, colorised cards, burndown graphs to name a few make a huge difference to the team dynamic. And oh yeah – have FUN with it!