I have a couple hundred cycles directly leading (as PM) a development team and a few thousand indirectly leading (as head of product). You use a tool a thousand times and you’ll start to see behind the glossy packaging. In particular, how Scrum and Kanban perform when used outside core engineering. Here are some observations with the hope it reduces your frustration time in finding a process that fits your team.
Does your development team feel like their process is working for them…or against them?
Acid test #1 for process mismatch is to step back and ask, “without process at all, what should this team be doing?” If the without-process doesn’t match the with-process, you have a problem.
Acid test #2 is to ask whether you could triple in scale and still remain confident. If the process is a good fit it will scale linearly. A poor process will have vulnerabilities at one team that become exacerbated and visible when replicated to additional teams.
The two most popular Agile procesess are Scrum and Kanban. Each has inherent strengths and weaknesses. The key is to choose the process appropriate for your team.
(Note, sometimes a team will run both: Scrum for sprints, and Kanban inside of a sprint as a “child” process. That’s different than using Kanban as the primary “parent” process, which is what I describe below. Using Kanban inside of a Scrum sprint is an excellent but lower-level organizing tactic.)
Scrum is a cyclic process. You run a cycle of Scrum, called a sprint, usually 1 or 2 or 4 weeks in length. There are a set of activities you do for each cycle, like estimation and a retrospective. You have a budget of development points for each cycle. When a cycle is complete, you plan and launch a new cycle.
Scrum is not a “light” process. The activities you do each cycle — estimation, retrospective, sprint demo — are meetings that consume time across the entire team. My estimate is that Scrum is at least a 20% overhead cost.
The benefit of this weight is a structure that provides visibility and control even under heavy repetition. Each cycle has with a planning stage that includes comparison to previous cycles. Each cycle has a conclusion in which the delivered work is presented and the progress towards a goal can be assessed. The cycle has a natural measurement cadence: a “heartbeat” for monitoring the development process.
In contrast, Kanban is a flow process. There is no cycle. In its most basic form, you have three stages: planned, in progress, and complete. The flow is governed by a cap on how much can be in progress at once. The flow runs continously so there is no finish and restart.
Kanban is a very lightweight process, barely a single constraint on top of no process at all. No planning cadence means that prioritization is free to change at any moment. Even work in progress can be backed out and replaced as long as the in-progress constraint is respected. Kanban’s strength is this flexibility to react immediately to changing development needs. In this way, Kanban is more agile (lowercase “a”!) than Scrum.
However because there is no cycle, Kanban also lacks a natural monitoring cadence. There is no block of effort from which the team can assess the work done and compare versus previous blocks. Over time, while it is clear that output is happening, the lack of cadence means that Kanban resists measurement or monitoring. This in turn makes can make it difficult to assess and improve, both for the development team and the teams they work with.
Selecting a Process
Given the above strengths and weaknesses, which process is appropriate for a given team?
The “contract” of Scrum is that the set of work planned for a sprint should not change once the sprint is started. The development team commits to deliver the work as long as the product manager commits not to change their mind during the sprint. If the product manager does change it, the sprint contract is “broken” and the team will attempt to do the new priority but without a committment to deliver. Teams should break sprint only rarely, otherwise there is no point in having a sprint cadence and a sprint commitment to begin with.
Thus, while the monitoring and assessment benefits of Scrum are attractive, they require a team to have enough forward visibility in their prioritization that redoing the priority once inside a cycle is a rare event. For example, if a team can maintain a four-quarter roadmap, planning the next two-week sprint should not be a problem. Conversely, if the team is at the whim of priorities changing day-by-day, a two-week committment will be impossible to maintain.
The most common failure of Scrum is a team being unable to react to changing priorities. The most common failure of Kanban is not knowing if the team is performing well.
In practice, what does this mean?
- Feature-development engineering teams act on aggregated customer need and long-term vision for the product. Both of these are relatively slow to change, thus prioritization will be visible to a horizon far beyond a short-term sprint cycle. It should be easy to avoid breaking sprint with unnecessary priority changes. Scrum is an excellent choice for feature-development teams which can then reap the benefit of increased assessment and self-improvement.
- Sales engineering and professional services teams work either pre-sales to help close deals or post-sales to configure a product. Unless the product has a very long sales cycle, priorities will change as deals escalate in urgency. More importantly, sales engineering teams “take orders” from outside the team and thus are susceptible to frequently breaking sprint if they attempt to run Scrum. Kanban is a safer choice for SalesEng and ProServ teams.
- Design teams often operate in two modes: long-term mode when researching UX, and short-term mode when creating UI or “styling up” output from engineering. For UI work, the temptation is to run Scrum in order to sync with the Scrum cycle of an associated engineering team. However in short-term UI mode, designers are reacting to work coming out of engineering. With Scrum they are forced to introduce an additional delay as UI work waits until it is added to the next sprint to start. Thus Kanban is a better choice for reactive Design work.
- SRE (systems & reliability engineering) teams, like design teams, often operate in two modes. In short-term mode they are reacting to system stability emergiencies and moving quickly to fix or patch. In long-term mode they are deploying changes that reduce the likelihood of future issues. While the long-term projects might lend themselves to Scrum, the need to react immediately to short-term emergencies means that most SRE teams are happiest using Kanban.
- Other business functions, like Marketing, often see Scrum used in engineering and attempt to implement it themselves for development of content and campaigns. However the prioritization horizon for Marketing is usually measured in weeks as opposed to the months on a feature-engineering team. Unless a business team has clear visibility forwards for mulitples of a sprint duration, that team would be better with the lower process overhead and fewer restrictions of Kanban.
Different Tools for Different Needs
Both Scrum and Kanban are good development processes. Both are agile, and Agile.
If you select the right process for your team, that process will improve your team’s ability to develop over not using a process at all. Conversely, choose poorly and the team will struggle against the process and be harmed versus using nothing at all.