I was just responding to a tweet and I couldn’t squeeze it all into 140 characters. @wiekatz asked on twitter: “Trying to figure out what the "best of both worlds" of Kanban and Scrum is. Does it even make sense?”
I think it makes sense. There is a degree to which one can claim they are totally different things and should not be compared, but I think they overlap quite a lot, in their goals, the spirit behind them, and they tools they use. You could say for example that Kanban is a change management tool that works by visualizing work and planning according to measured capacity. You could say that Scrum is a planning and scheduling tool with a strong organizational change component. But that leads to a long conversation that you can probably find repeated in many places on the internet.
Kanban however needs some existing process to be applied to. You can’t just start from scratch with a new team, on a new product, and decided to use Kanban without thinking about how the software is to be developed, and how the work will be planned and scheduled. Kanban doesn’t answer those questions, it will just provide some tools for visualizing what is happening, and making small improvements. In this case you could do a lot worse than Scrum. In fact, if you can successfully make a go of Scrum, with a true cross functional team, and deliver small increments of functionality in 30 days or less, you might not even need Kanban. The Scrum already has retrospectives, and the concept of inspect and adapt. Personally I would still make use of the advanced techniques provided by Kanban such as WIP limits, classes of service, explicit policies etc, but as long as the process is still Scrum Guide conform, it is still Scrum. You might call it Scrumban. I once tried to imagine if it would be possible to have a system that is both 100% Kanban and 100% Scrum at the same time, and I think it should be possible but not ideal.
I read Scrumban a while ago, and suspect it is also relevant to this “best of both worlds” discussion, but I would have to reread to be able to say anything interesting about that.
Also let us consider a waterfall organization that has started using Kanban to try and improve the system. After a month or so you are going to have a very flat, stagnant CFD. The cards on the wall will start to yellow with age, negating any use of color to indicate class of service. Anyone using post it notes will start to suffer back trouble after picking them up off the ground all the time. People are going to find answers for this in things like Scrum. Particularly cross functional teams, and well-groomed PBIs that are small enough to be “done” in 30 days or less. Scrum is exactly the medicine a waterfall+Kanban type organization needs.
Not only does combining Kanban and Scrum make sense, they almost seem made for each other in many cases.
Also, Personal Kanban is basically Scrum minus the team considering they both track general “tasks” through the “to-do”, “doing”, “done” sequence rather than tracking customer value through a standardized sequence of steps like normal Kanban. I haven’t read the Personal Kanban book yet, but it would be interesting to know what it borrows from normal Kanban.