The Real Relationship Between Scrum & Kanban

(Image: Cover image of the book Essential Kanban Condensed by David J. Anderson and Andy Carmichael.)

Many people I interact with seem to believe that Kanban is another Agile methodology for helping Agile teams manage their work. The aim of this post is to help people see how Kanban can be so much more.

I am aware that there are some who believe that a high performing, self-organizing, cross-functional Agile team is as good as it gets and that it is the job of Leadership to change the organization such that this kind of team becomes a reality. This is a belief that I also held for many years, during which time I actively advised my clients to pursue this lofty goal and I invested a great deal of time and effort towards helping them achieve it. I understand this belief. It is very powerful, so powerful that it shapes identity. Therefore, it was a big part of my own professional identity and this was not easy for me to change. I empathize with those who struggle in similar ways as I have.

I could go on with my personal story, but I’ll get back to my opening statement. Kanban is so much more than just another Agile methodology. So what does this mean? How can it be so?

In my own experience helping businesses improve for over a decade and from the many stories I’ve listened to of the people I’ve met in my consulting engagements, training classes, conferences and meetups, the ideal of fully cross-functional teams is not a reality, not even a feasible possibility for their organizations and this reality is causing them pain and harm.

Let’s be clear about what we mean by cross-functional teams: According to the Scrum Guide (paraphrasing), a cross-functional team is a team that possesses all the skills required for starting and delivering potentially releasable product increments in a Sprint. A Sprint is a complete project that must be completed in one month or less. Many organizations add to this the idea of establishing stable teams (membership does not change) and Sprints of 1-2 weeks in duration. For many organizations, integrating all of the above is simply not realistic.

Most people I meet who are working with Agile teams (mostly Scrum teams) have already done everything they can to create the conditions for their teams to realize this ideal. Teams are already as “Agile” as they can be under the current constraints. Leaders have already done everything in their power to remove the constraints.

Some would describe this as a “failed Agile transformation”. But it need not be so. Rather, I have begun to see it as a natural stage in some organizations’ maturation process. Perhaps at an organizational level it is analogous to the “Storming” stage of the Tuchman maturity model: “Forming”, “Storming”, “Norming” and “Performing”. Regardless of the best analogy, the important point is that an apparent failed transformation does not have to be a bad thing. It also doesn’t mean you need to start all over again (with another re-org) in the hopes that you will “get it right” the next time. Rather, it is a natural stage of organizational maturation and the frustration, pain and conflict you are experiencing are telling you that your organization has an opportunity to evolve.

Kanban helps organizations move beyond this difficult stage. The Kanban principles of service orientation and evolutionary change help organizations focus on improving survivability of the business and the sustainability of the work. All of the Kanban practices are evolutionary stimulants for whole-organization improvements and they all scale naturally to all levels of an organization.

Kanban can help Scrum teams. Kanban can help with project, program and product management. Kanban can help with portfolio and enterprise services planning and management. Finding ways to implement the practices, little by little, at all levels of your organization will enable your organization to become fitter for the purposes of your customers, fitter for survival.

The Kanban Method, as opposed to other approaches, has built in double loop learning feedback loops. This makes it always contextually appropriate to help any organization. -Martin Aziz

The Kanban Principles:

Change Management Principles:

• Start with what you do now;
• Agree to pursue evolutionary change;
• Encourage acts of leadership at all levels;

Service Delivery Principles:

• Understand and focus on customer needs and expectations;
• Manage the work, let people self-organize around it;
• Evolve policies to improve outcomes.

The Kanban Practices:

• Visualize the work;
• Limit work in progress;
• Manage the flow of work;
• Make policies explicit;
• Implement system feedback loops;
• Improve & evolve with data, models and the scientific method.