Below is an excerpt from an email response I sent someone asking me about Kanban and Scrum and what they should do to determine which is more appropriate for their teams. This is just my personal opinion on this subject and I’m sure our trainers have MUCH better perspective to add!
Kanban for software is an interesting phenomenon that I’d like to explore a bit with you to hopefully answer how it might fit in with your software development practices. Kanban in Japanese simply means cards but can be loosely translated to “billboard” or “visual plan.” 看板. Merchants have used it for years as a means of restocking items, aligning the speed of production with the speed of consumption. Toyota adopted these methods to manage the restocking of parts to ensure they never ended up in a situation with 10,000 unusable extra parts for a discontinued or redesigned car. When a box of parts of out, workers take a card and put it in the “please order” bin.
Now we come to Kanban for software which is essentially a continuous single-piece flow. Requirements go up on into the queue and the team simply pulls one at a time, completes them, and moves on to the next item. This work occurs in a similar fashion to how we teach Scrum teams to work (within a sprint) on one backlog item at a time. We want the team to swarm on the first backlog item, get it totally done, and move on to the next one until they’re either done or the sprint is done and they’re out of time. What Kanban misses is the formal review of the product (review meeting) and the formal review of the process and people (retrospective meeting). When we miss those reviews, we miss out on opportunities to do the constant improvement of our teams and organizations that drives the ROI figures you hear about agile/Scrum. We also miss out on the psychological commitment teams make to finish a particular amount of work in a given sprint. We simply rely on a rate of continuous flow rather than time-boxing to do forward-looking metrics.
In real implementations, I’m afraid this system could also jeopardize the autonomy we give Scrum teams to both negotiate capacity and to have creative input on the product backlog. Without the planning, review and retrospective meetings, I also think it’s a possible excuse for product owners and business people to be even less involved and engaged with their technical teams. This engagement matters in the creative discipline of software development and probably matters less as we move into a more defined problem space like support. For software development teams who are doing highly creative work generally against release deadlines and feature commitments, I think I/O psychology studies support Scrum’s practices as being more supportive. However, for a support team that is doing demand-response work (picking up tickets, completing them and moving on to the next), Kanban might be helpful. I’m just not sure how different it is from a strictly-managed ticketing system where employees have to totally finish one ticket before picking up another one.
If you want a lean organization, it might be appropriate to have your software development teams doing Scrum and your support teams doing Kanban as your path towards realizing Lean principles.
Does that help at all? If you want to go in this direction, I really don’t think you need a Kanban expert separate from any other agile expert. I’d bring in a Scrum coach and an XP coach, and have them sort out where Kanban would be appropriate and most importantly, what method your teams and business people believe, together, will be the best path to realizing your goals!