Scrum and Kanban are currently two of the most popular ways to implement Agile practices within software development teams. Scrum has prescribed roles and ceremonies and focuses on delivering small batches of potentially releasable work in short time-boxes. Kanban focuses on visualizing work, flow, and limiting work in progress. Both place an emphasis on continuous improvement. Both have been shown to be effective, but the question many teams face when starting to adopt Agile is: which one should we use? Teams often get hung up on deciding and in many cases select a framework which may not suit their team or environment. Or even worse, they will switch when the framework they chose isn’t working as well as they had hoped, without giving any thought to the underlying cause of their problems. Taking the following factors into consideration when deciding which one will be best for a particular team will help to ensure that the team is set up for success.
1. Level of Maturity in Agile or Continuous Improvement
Does the team or organization have an existing culture of continuous improvement? In Scrum, Sprint Planning (4-8 hours) and Sprint Retrospective (2-4 hours) meetings take place at the beginning and end of every sprint. For teams that are new to Agile and the concept of continuous improvement, holding these meetings on a regular cadence will help them get in the habit of thinking about the work they will be doing in upcoming sprints and how they can improve from sprint to sprint. For more mature teams that have experience with continuous improvement, having these meetings regularly may prove to be a waste of time, especially as a project advances. Experienced teams will have the discipline to conduct planning and retrospective meetings as needed, and understand the importance of doing so.
2. Level of Expected Change
What sort of change will the team be expecting during the project? Will there be a predictable level of work that can be batched up into enough work for a two week sprint? Or will it be more of an irregular ebb and flow of work? Also, what priority does the organization place on responding to changes from their customers or the market?
Kanban has become very popular with maintenance and support teams due the unpredictable amount of work that will come in at any given time. Sometimes they will have a high volume of high priority issues and sometimes there will be none. With this changing level of demand it is very difficult to conduct any sort of sprint planning. It is also very difficult to develop any sort of consistent velocity that can be used to estimate for future sprints. In addition, when high priority items come in, many times they cannot wait to be handled in the next sprint, so the team has to take on that work and it will adversely affect their velocity and ability to accurately predict how much work they can handle the next sprint. It is easy to see why Kanban is a better fit in this situation, but is this the only time teams should use it?
In addition to support and maintenance work, Kanban can be used very effectively for new software projects as well with an experienced team. Because the team will focus on flow and limiting WIP and may be able to reduce the amount of planning and retrospective meetings that they have to conduct they may be able to produce work even faster than Scrum teams that essentially stop work for extended periods every sprint to conduct their ceremonies. In addition, work moving through a Kanban system should still be vertical slices of potentially releasable software, making it a great fit for an organization that is able to leverage continuous delivery. Instead of waiting to release new features at the end of a two or three week sprint, these features can be released as soon as they make their way through the board.
If however, the team is not at this level of maturity and the expected change in requirements during the sprints is low, Scrum may be a better fit for the team. If this is the case, there is a strong effort within the organization on accurate prioritization and respecting the sprint backlog as to allow the team to devote their focus on completing the work they have committed to during their sprint planning.
3. Effectiveness of Existing Process
How is the team’s process currently working? Is the team working efficiently? Are they and their partners satisfied with the amount of work that is produced? Are they satisfied with the level of quality? If so, teams may be reluctant to take on the big changes that would likely come with adopting Scrum. Kanban on the other hand focuses on incremental process improvement and can be applied to pretty much any existing process. The team can model their workflow visually, develop agreements on work-in-progress (WIP) limits with upstream and downstream partners and build trust. Slowly the team can start to make changes and take advantage of more advanced Kanban concepts(statistical process control, ad hoc queue replenishment sessions, smaller buffers, stricter WIP limits, etc.) to make their process even better.
4. Rigidity of Project Deadlines and Level of Required Planning
For organizations moving from a rigid waterfall style where everything is planned up front and there are deadlines for each specific phase of the software development lifecycle, it can be difficult to adopt the more loosely defined and flexible timelines or scope that is common in Agile projects. For those that have never worked in an Agile environment before, having to work together with team members and upstream and downstream partners to coordinate when planning, demos, releases, retrospectives, etc., can be a lot to handle. For this reason, for projects that have a stricter deadline or require a little more upfront planning can benefit from the structure that Scrum offers. When Scrum projects begin there will be a sprint 0 (sometimes this will even be a little longer than the time-box for subsequent sprints) where the Scrum team will meet and begin to break down work from the backlog, understand dependencies, and come up with a release plan that will give a rough idea of what work will be released within a set amount of time (this will vary, but 3-6 months is not uncommon). At the end of every sprint, the team will present the work they have completed and make adjustments to the release plan as necessary. Having this level of structure and short feedback loops for new teams can be very helpful in helping them to manage tighter deadlines.
5. Capacity for Organizational Change
Is your team or organization ready to make big changes to the way they work? Moving to Scrum will require assigning people to Scrum Master and Product Owner roles. Training sessions will need to be conducted to go through the different ceremonies and roles and the physical work area may need to be changed to be more open to enable easier collaboration. In addition, both the team and management will need to become comfortable with the idea of the team being self directed. These are big changes and not every team is ready to make this commitment.
If the team is unable or unwilling to make the changes to adopt Scrum, Kanban can offer some help as it requires less change to the way a team is currently working. To start with Kanban, teams can immediately start visually managing their work and see areas where they are getting blocked or areas where there may be waste. Teams should also start to implement work in progress (WIP) limits and these should get stricter over time as the team matures. Although beginner teams will not be able to take full advantage of the flow, continuous delivery, continuous improvement elements enabled by Kanban, the barriers to starting are lower since there are no prescribed roles or ceremonies.
6. Experience Sizing and Estimating Work
Both Scrum and Kanban benefit from the ability of teams to break work down into manageable chunks that can either fit into a fixed timebox (2-4 weeks) or move across a Kanban board within a reasonable cycle time. For teams newer to working in an Agile environment or teams that have never worked together before and don’t really have an idea of how to accurately estimate their ability to do work, Scrum may be the easier route. Because there are set ceremonies where estimating, grooming, inspecting, and adapting will take place, teams will be forced to analyze their sizing and estimating every sprint. If work is not getting completed within the their agreed upon time box they will have to discuss why at the end of every sprint. The teams can then use this feedback and their lessons learned during the next sprint planning to break work down into smaller increments or make more realistic estimates. Kanban will also have planning and retrospective sessions, but as they are not prescribed teams that are less mature may have a tendency to let too much time pass in between retrospectives or they may skip them altogether. In addition, they may not plan effectively and end up with work that is too big and will end up getting blocked on the Kanban board on a regular basis.
Although we have discussed six factors that should be considered when deciding whether teams should use Scrum or Kanban, most of these things fall into one of two categories: 1) the team’s maturity and 2) the expected level of change within a project. What this means is that if your team is relatively new to Agile or the work that is expected during a project is relatively stable or predictable, it may be easier for the team to adopt Scrum. If the team will be expecting high levels of change (such as those seen in support/maintenance teams) or if the team is at a high enough maturity that they can optimize flow and take full advantage of continuous delivery, Kanban may be a better fit.