Skip to main content

Scrum with Kanban - building bridges not walls

February 26, 2018

Scrum with Kanban Today we announced a new class, Professional Scrum with KanbanFor many people reading this blog, it might appear to be strange for Scrum.org, The Home of Scrum to announce. After all, some might say that “ Scrum and Kanban are rival approaches to delivering software”, but it doesn't have to be Scrum vs. Kanban, they can work together.

But, we haven’t done this alone.  We have worked with Daniel Vancanti, who in 2007 helped to develop the Kanban Method for knowledge work and managed the world’s first project implementation of Kanban that year.  Daniel has been conducting Kanban training, coaching, and consulting ever since. Another key developer of the materials is Mr. Kanban Israel Yuval Yeret who is both a Kanban practitioner and a Professional Scrum Trainer. And, as always with Scrum.org materials we worked with our Professional Scrum Trainer PST community, many of who have vast Kanban experience to complement their Scrum experience as well as the larger Kanban / Scrum practicing community to build this class.  Why did we do it?

  1. Many Scrum Teams are using the practices of Kanban to help them better visualize work and deliver more value to their customers. BUT, there is much confusion how you can make it work without breaking Scrum or Kanban. It is very important for us to deliver a class that does not break Scrum or Kanban and shows in very practical ways how the practices of Kanban can make Scrum Teams even better.
  2. A divided community where everyone has a camp does not help us deliver on the Scrum.org mission of “improving the profession of software delivery”. This was driven home to me recently when at a conference someone asked where I worked and when I said Scrum.org they said, “oh we do Kanban” and walked off. I am quite sure that if we had talked, we both would have learned something. Our world is already polarized, the last thing I want to do is add software delivery to the list of polarizing items.  
  3. Scrum requires the adoption of practices to make it work. Scrum is not a methodology, but instead a framework that teams instantiate with the practices that their complex situation requires. Our classes already include many practices from other “groups”,  such as Extreme Programming and Lean Startup. By adding a formal class that demonstrates how Scrum can work together with Kanban, we are helping experienced Scrum Team members explore another set of practices. In the context of Scrum.

Over the last 6 months, many people inside and outside of our community have worked on this material and explored how Kanban and Scrum align. During this process, there have been moments when this alignment has re-enforced the fundamental ideas of Scrum and Kanban. Here are just a few that you might find interesting.

  • The Sprint Goal is a crucial mechanism for driving work and is manifested in the Increment. It is easy to lose track of the focus of the Sprint when the team is knocking off tasks and delivering on the PBI’s that were forecast. And many teams focus on the work they are doing in the Sprint rather than the Goal of that Sprint. Kanban makes work visible but in the context of the Sprint Goal. This both re-enforces efficiency but also purpose. A great reminder for teams.
  • The purpose of the Daily Scrum is not to review progress, but to allow the team to inspect and adapt to ensure they are moving in the right direction and make changes to the process if they are not. In Rugby, a Scrum occurs when the game stops. When the ball stops legally moving. That is the same for a Scrum Team, but without a ball, it is hard to determine what is happening. Kanban is all about visualization and provides the team with the “virtual ball position” of the work. By improving the visualization of work the Scrum Team can better focus on how to get better or “move the ball more”.
  • Self-organizing, cross-functional teams are a corner-stone of Scrum, but we often fall into bad practices of “skill camps” and “comfort zones” when determining who does what. By making those “skill camps” visible and highlighting the waste that specialism encourages, it is much easier for the teams to challenge the status quo and make progress.
  • Empiricism requires data to be effective. A great example of data on the increment is when software is delivered into production and real usage data is garnered from users.  Looking at how the team works is another important opportunity for capturing empirical data and using it for improvement. By applying flow metrics and visual indicators from Kanban, teams can improve their Retrospectives and make better decisions about process improvement.

And… These are just four of the many things I took from Scrum with Kanban. I am sure you will all take many others. I am very excited to add this class to the Scrum.org curriculum. And excited about what learning it will drive into our community. I also love the resulting change that I have seen from people who have taken the class already in preparation for this launch. Instead of saying “Yes, but Scrum or Kanban says…” they now say “Yes, and…”. Time to build bridges and improve our profession.

To class details can be found here:- Professional Scrum With Kanban 


What did you think about this post?