PART X: Using FLEX to Both Enhance and Simplify Scrum ToC Part XI: Using FLEX to both enhance and simplify SAFe
Note: This page was written before the acquisition of FLEX by the PMI. Now, we’d recommend learning Disciplined Agile Delivery which includes the useful concepts and practices of both Scrum and Kanban. However, this page is still useful for those who want to improve their Scrum adoptions.
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.
All three approaches are partial implementations of Lean and flow thinking. Each approach is closer or further than the others in different ways as represented in Figure 1.
The differences between Scrum and Kanban
Figure 1 illustrates the similarities and differences of each of the Agile practices. In this figure, each practice has a prefix of “Lean-“. This emphasizes that, for the purpose of this article, we are thinking of the practice with Lean-Thinking as its foundation. This views each practice as a means to achieve more effective teams and not an end in themselves.
Usually, it is thought that the difference between practices is whether they are sprint-based or flow-based, but that is just one of the ways in which they differ. They differ in 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. 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.
Note: Figure 1 does not imply that XP should not be included in Team-Agility; instead, it says that Team-Agility is not a requirement for XP.
Here are some of the differences this article mentions.
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.
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.
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 where 0 means it doesn’t fit your situation well and 5 means it does fit your situation well. Finally, sum the results.
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 they might need more coaching than usual.