The most popular agile practices today are scrum, kanban, and extreme programming (XP). All three approaches are partial implementations of lean and flow thinking. There is no one best solution. It is why Disciplined Agile is agnostic about methods. Here are important DA principles that coaches must know.
Context counts. Every person, every team, every organization is unique. We face unique situations that evolve over time. The implication is that we must choose our way of working (WoW) to reflect the context that we face, and then evolve our WoW as the situation evolves.
Be pragmatic. Our aim isn't to be agile, it's to be as effective as we can be and to improve from there. To do this we need to be pragmatic and adopt agile, lean, or even traditional strategies when they make the most sense for our context. In the past, we called this principle “Pragmatism.”
Choice is good. To choose our WoW in a context-driven, pragmatic manner we need to select the best-fit technique given our situation. Having choices, and knowing the trade-offs associated with those choices, is critical to choosing our WoW that is the best fit for our context.
When it comes to choosing among scrum, kanban, and XP, we should be asking, “in our context, what works?” and then choose what is most effective in the given situation.
This article offers some general thoughts to help compare the approaches.
Comparing the Approaches
Figure 1 illustrates the similarities and differences of each of the agile practices. For the purpose of this article, we are thinking of the practice and how it helps to implement lean thinking, which includes:
Removing delays in workflow and feedback
A commitment to quality
Figure 1: Scrum, Kanban and XP contrasted in one picture.
The differences between the approaches are not simply whether they are incremental or flow-based. 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. There are differences in the amount of discipline required to use them and in which cultures they fit well.
We will focus on scrum and kanban because they are the two most popular approaches.
Here are some of the factors this article mentions.
Roles in scrum and kanban
Organization of the team
How to start
Degrees of structure and discipline required
Approach to improvement
Theoretical basis, why it works and what it leaves out
Roles in Scrum and Kanban
Scrum has predefined roles: The product owner, the team lead (scrum master), and the development team. Kanban can work with whatever roles already are present. If people are attached to their roles, requiring new roles, or even changing names for the roles may cause resistance.
Disciplined Agile Delivery includes a robust set of roles for agile solution delivery. Scrum and kanban can tend to be more limited.
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 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 can create unnecessary resistance.
Scrum uses time-boxing (sprints) while kanban uses a flow model with cadence. This 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.
Degrees of Structure and Discipline Required
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.
Approach to Improvement
Scrum and Kanban are not merely different sets of practices, they are based on different models of transformation. Scrum and kanban have different approaches to change. Scrum often urges making big changes, adopting scrum straightaway while kanban involves a sequence of small changes. Scrum is based on a set of practices while Kanban is focused more on the work directly.
Scrum focuses on a set of practices that will help to expose the impediments that teams face in efficient product development. Anything that impedes the team from doing the practices is presumed to be an impediment from achieving agile.
Scrum usually involves abrupt change that can be disruptive to the culture. For it to work, the core practices and roles must be followed. While scrum’s framework is flexible, you are expected to follow the practices (such as “you must do sprints”) and use the roles. Learning is supposed to take place by creating great teams and having the team figure things out.
Kanban focuses the actual work being done. It creates explicit visibility of both the work and agreements between people on and off the team. It seeks to create an understanding of what work you are doing and following principles of flow. It is based on evolutionary change. Its focus on workflow can ignore the value of cross-functional teams.
Scrum works towards improving outcomes by doing regular inspect-and-adapt reviews to see how to improve the team’s practices. Kanban looks at the flow of the work and sees how it can be improved. While both work in many situations, they are somewhat extreme in their classic forms.
Scrum is founded on the idea 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 although it ignores the central tenet of lean to attend to organizational structure.
Why Scrum Works
The essence of scrum is to have colocated, cross-functional teams that complete work in sprints of one to four weeks. These practices work to reduce delays in workflow because the people needed to get something done are always present in the team. Teams get the answers they need right when they need them. They also reduce delays in feedback because stories can be completed in a matter of days and product owners can provide feedback during the sprint or at least no later than at its end.
What Scrum Leaves Out
Scrum is great. But it is missing some key elements. Scrum does not take a systems-thinking point of view. It takes a bottom-up approach. Mostly, teams work individually and then try to coordinate with a scheme such as a Scrum-of-Scrums and then finally attend to the business needs across the organization. This bottom-up approach focuses on only part of the value stream. Scrum also does not embrace explicit workflow within the team. Scrum does not explicitly manage work-in-process. Systems-thinking across the value stream and explicitly managing workflow virtually always improve collaboration and efficiency.
Why Kanban Works
Kanban is based on three basic principles:
Visualize and make explicit how you do your work.
Limit the amount of work-in-process (WIP).
Kanban is known as a pull method. It has two mantras, “Flow when you can, pull when you must” and “Stop starting and start finishing.” Kanban’s focus on flow and managing WIP reduces delays both in feedback and workflow. Visualization and explicit policies of the workflow also improve collaboration, even when colocated teams cannot be used. Kanban is sensitive to culture and context and shows respect for current roles, responsibilities, and job titles.
What Kanban Leaves Out
Because of its sensitivity to culture and context, kanban emphasizes starting where you are and evolving a solution. While attending to context is essential, there are often practices and structures that are known to offer immediate improvements and that set the stage for better learning that everyone can agree to. By ignoring these opportunities improvements can be slower in coming than the teams expect.