I’m convinced that Kanban works very well for service desks and other response-based teams. For these teams, planning two weeks’ work up front just doesn’t make sense. Similarly, I can see why people might think that Scrum works best for projects: iterations give great visibility and regular milestones at which to measure progress.
But Kanban does work for projects too. How many projects have you worked on where the scope doesn’t change? Where additional features are realised? Where a story isn’t dropped when you see that it isn’t really going to add value? Kanban still works for projects because it has increased flexibility. It’s still focused on delivering as soon as possible. It could be argued that it has even more focus on delivering value.
The biggest factor in deciding whether to move to Kanban or stick with Scrum is the team. If the team doesn’t want to embrace change and work through it as a team, then you’re in for a tough ride. If you hear statements like, “well, let’s try using Kanban for one iteration” then there are two things you should consider:
- The team doesn’t understand Kanban: there’ll be no iterations for a start
- The team is unrealistically expecting results in a matter of weeks … and they’re probably looking for YOU or someone else to deliver them on a plate.
If you encounter this, my advice would be to get as many of the team to read David Anderson’s book, get some Kanban training, then discuss the benefits of what you want Kanban to deliver. If the team changes their tune and gets on board, make sure they also understand the basics of Kanban before you kick off. Then just get on with it. You won’t get it spot on to start with and you’ll be making small alterations as you go along. This is why you need the team’s buy-in: you want them to be coming up with the changes.
However, don’t be afraid to go backwards too. Not every change you make will be beneficial. Just revert and re-evaluate. The beauty of Kanban is that you can make your processes into whatever is best for your team. However, in my mind (and I know I’m not alone), you can use Scrum and still change certain elements: Scrum is a framework, not a methodology. If someone ever says “but that’s not Scrum”, just remind them about the 12th agile principle:
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”
Nowhere does it say “Follow [insert your favourite Scrum author’s name here]’s book without adapting it to your own situation.” Call it Scrum if you want. Call it Tomato for all I care. The most important thing is that it works for you.