Scrum and Kanban are the two most popular Agile team-level methods available. While the difference between them is mostly thought to be sprint-based or flow-based, that is just one way in which they differ. Other significant differences include how to start, how to improve, and how people should be organized. They are based on different theories of how to manage software development work and whether you need to change your roles. And this creates other differences such include the amount of discipline to use them and the cultures in which they fit.
The differences between Scrum and Kanban
Let’s look at this in more detail.
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 already present. If people are attached to their roles, Scrum may cause problems.
Organization of the team. The heart of Scrum is the cross-functional team. Kanban can work with however the teams are organized. Of course, cross-functional teams are good, but if they are either not viable or it will take some time to create them, Kanban may be a better choice.
How to start. Scrum starts 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 difference in practice 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 works best in a culture where people are looking for something to tell them what to do and where the team needs protection from outside the team. Kanban is more self-generating and is based on visibility.
Level of discipline required. Scrum requires less discipline than Kanban since the rules and events of Scrum are more concrete and specific than Kanban.
How to improve. The focus of Scrum is on doing the Scrum events, following its rules, while creating its artifacts, and using its roles. Anything that impedes the team from doing this is presumed to be an impediment to achieving Agile. The focus of Kanban is on the actual work being done. It creates explicit visibility of both the work and the agreements between people on and off the team.
This is perhaps the biggest different between the two. Scrum focuses on practices, rules, and artifacts which presumably makes the work go better while Kanban focuses directly on the work and workflow.
Theoretical basis. The Scrum Guide says that 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 the Theory of Constraints and incorporates 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 difference is that Scrum works toward 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 1 below summaries these differences.
What these differences mean
In our experience, 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 organizations and the teams within them are different. And these differences should be accounted for.
That said, the outcomes required by virtually all teams are the same such as quick feedback, collaboration, validated code, building small increments, and continuously improvement. The challenge 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 take up Agile in isolation, it is enough just to know Scrum. But that is not enough. Agile goaches need to know how to create the proper blend of Scrum and Kanban. This is not difficult to provide. Unfortunately, most training provide only one side of the story.
How workshops for coaches need to be delivered
It takes time for people to become good coaches. Unfortunately, most coach training takes place in two to four 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 five 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 how 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 will take for you to clearly see why.
This is Al Shalloway. Talk with me at firstname.lastname@example.org