Why Agile Coaches Need To Know Both Scrum and Kanban

This article is an excerpt from my upcoming online book Going Beyond Lean and Agile: Introducing FLEX – FLow for Enterprise Transformation (online book). FLEX is Net Objectives' Lean-Agile approach to helping organizations improve at all levels.

The most popular Agile practices today are Scrum and Kanban, with eXtreme Programming (mostly identified by pair-programming, test-first and other technical practices) being an (unfortunately) distant third. Scrum and Kanban are the two most popular Agile team level methods available.

We prefer to think about all three approaches as being partial implementations of Lean and flow thinking – each approach being closer or further than the others in different aspects. We represent this in the following figure. Note, we preface “Lean-” to the approaches name to emphasize that for the purposes of this discussion I’m not discussing the classic (typically certified) approach, but rather when the approach is used with Lean-Thinking as their foundation. This views them as a means to achieve more effective teams and not an end in themselves.

Figure 1: Scrum, Kanban and XP contrasted in one picture

The above figure is not meant to imply XP practices should not be included in Team-Agility, but rather they are not a requirement for it. They are highly recommended. When viewed this way we see both their similarities and differences.

The Differences Between Scrum and Kanban

Figure 1 emphasizes each approaches practices. While the difference between them is mostly thought to be sprint based or flow based that is just one aspect of how they differ. More significantly, they differ in how to start, how to improve and how people should be organized. They are also based on different theories of how to manage software development work and whether you need to change your roles. The differences between Scrum and Kanban in these areas is very significant and creates other differences as a result. These include the amount of discipline to use them and in which cultures they fit well.

We’ll go through these differences as they pertain to the following:

• Roles
• Organization of the team
• How to start
• Practices
• Culture
• Level of discipline required
• How to improve
• Theory based on

Roles in Scrum and Kanban

Scrum has predefined roles – the product owner, the Scrum Master and the development team. Kanban can work with whatever roles already are present. If your folks are attached to their roles, requiring new roles or even names for the roles may cause resistance.

Organization of the team

The heart of Scrum is a cross-functional team. Kanban can work however the teams are organized. Cross-functional teams are good, of course, but if they are either not viable or it takes time to create them, Kanban may be a better choice. One can, of course, come as close to Scrum as possible using a combination of Scrum for those that can be on the team and manage those split across teams with Kanban.

How to start

Scrum requires a start by shifting into its predefined roles and team structure. Kanban can start where you are. Sometimes a big shift is a good thing, sometimes it’s not.

Practices

The biggest differences is that Scrum uses time-boxing (sprints) while Kanban uses a flow model with cadence. That means that things are done in small batches of work while checking in with each other on a regular basis to prepare backlogs, do demos and reflect.

Culture

Scrum and Kanban have different approaches to change – Scrum being a “jump to it” and Kanban being about a sequence of small changes. Scrum also is based on set practices (e.g., time-boxing) while Kanban is focused more on the work directly. These differences in approach should be considered when choosing between them.

Different degrees of structure

Scrum is considerably more structured than Kanban, focusing on practices and ceremonies. Kanban is more focused on the outcomes on a daily basis. Kanban therefore requires more discipline to use than Scrum.

How to improve

Scrum’s focus is on doing the Scrum events, following its rules while creating its artifacts with its roles. Anything that impedes you from doing this is presumed to be an impediment from achieving Agile. Kanban’s focus is on the actual work being done. It creates explicit visibility of both the work and agreements between people on and off the team. This is perhaps the biggest different between the two: Scrum focusing on its practices, rules & artifacts which presumably make the work go better and Kanban focusing directly on the work and workflow.

Theory They Are based On.

From the Scrum Guide: Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.

Kanban is based on Theory of Constraints incorporating principles of Lean flow. Kanban is not fully based on Lean since it does not attend to organizational structure which is a central Lean tenet.

The net difference here is that Scrum works towards improving outcomes by doing regular inspect and adapt reviews to see how to improve the teams practices. Kanban, on the other hand, looks at the flow of the work and sees how it can be improved.

Time-boxing or a flow model.

Time-boxing creates a great context within which the team can get its work done. With a flow model it is up to the team to ensure they are following what they’ve said they should be doing. Flow models require more discipline to ensure that work items remain small as there is no sprint they are required to fit into.

Figure 2 summaries these differences.

What These Differences Mean

Our experience is that different teams have different needs. They often need a blend of the Scrum and Kanban. The fact that both are defined to be used as a whole has more to do with their proponents trying to create approaches that work for everybody. But individual companies and the teams within them are different – and these differences should be accounted for.

However, the outcomes required by virtually all teams are the same – quick feedback, collaboration, validated code, building small increments, continuously improving, … The challenge here is that even though teams are supposed to self-organize, it doesn’t mean that they can just arbitrarily pick what they want to do. Doing so will certainly lead to holes in any approach they undertake. What is needed is a method for understanding the purpose (intent) of a role, rule, artifact or event and to ensure that if substituted, the new practice manifests what the one being substituted was attempting to do.

What coaches for Agile Teams Need to Know

When teams took on Agile in isolation knowing just Scrum was good enough. But now, virtually all organizations have teams where a blend of Scrum and Kanban are needed. Even when Scrum is to be used managing the capacity of critical people can be improved with Kanban. Agile coaches now need to know a blend of the two.

This is not difficult to provide. Unfortunately, most training provide only one side of the story.

Deciding on the Right Blend of Scrum and Kanban for Your Team(s)

While we have been contrasting Scrum and Kanban your choices are not limited to them. When you consider that both are partial implementations of Lean, you have the option of creating a blend of the two based on a fuller implementation of Lean. The following exercise is a way for you to get better clarity on this.

Fill out the following template by putting in a score on a scale of 0 to 5 for each aspect of Team-Agility. 0 means doesn't fit your situation well, 5 means it does fit your situation well. Then total things up.

For example, let’s say we have teams that are working on developing software, but they aren’t working well together. If the team is composed of people who might say something like “tell me what to do in a course” the filled in sheet might look like:

In this case Scrum might be a better choice. On the other hand, if the same team were doing maintenance, the sheet might look like:

In this case Kanban might be a better choice but I’d expect that they’d need more coaching than usual.

How Workshops for Coaches Need To Be Delivered

It takes time for people to become good coaches. Unfortunately, most coach training takes place in 2-4 days. Not only is not much retained, but when students have difficult in adopting what’s been learned, there’s often no one to help them. Real learning in a classroom is also difficult.

The ideal workshop needs to focus on learning effectiveness, real adoption of what’s been learned, cost and overall support. Ideally it will take place over a few months with 1-2 hours required each week. This both enables people to learn in small steps while taking little time away from their job. This can be accomplished by using online training with flipped-classroom style learning methods.

A support system should also be provided.

This is exactly what the Net Objectives Advanced Scrum Master / Kanban Online Workshop is. At $595 it is half the cost of the Certified Advanced Scrum Master course, but provides twice the content. Enrollments after the first are only $500 each. If you have embedded coaches you can get about 180 Scrum Masters go through our workshop for the cost of only one embedded coach.

How Is This Savings Possible?

Even though I've been working on how to lower the high cost of coaching for 5 years with advanced learning methods, this ratio of being able to grow 180 of your own coaches for the cost of one embedded coach seemed far-fetched. So here's an analysis of why it is possible:

• Coaches do not provide a support system for the people they are coaching. Most teams have the same types of challenges as others. 1 on 1 coaching is not needed to help with many of these. Solving them this way is expensive.
• The use of scaled learning methods greatly increases retention while lowering costs by 80%
• With the growth of Agile most coaches don’t have the requisite 10,000 hours to be truly expert.
• Coaches who only know Scrum well (putting a few Kanban practices into Scrum is far from knowing Kanban) precludes teams being provided solutions that require kanban. Poorer solutions require more effort to implement.
• Avoids dogma and the argument of which is better, Scrum or Kanban. Both are needed.

A 15 minute chat is all it’ll take for you to clearly see why.