Scrum and Kanban are 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.
While both have been shown to be effective, 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. What is even worse, they switch to another framework 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. The following six factors can be taken into consideration when deciding which model is best suited for your team to ensure you’re 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 basis can help them get into 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. However, experienced teams do 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 the team expects 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 required for their customers or the market?
Kanban has become very popular with maintenance and support teams due the unpredictable amount of work that comes to them at any given time. Sometimes, the volume of high priority issues is high sometimes there is 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 future sprints. In addition, when high priority items come in, many times the teams cannot wait to handle them in the next sprint. In such cases, the team must take on the work even though it adversely affects their velocity and ability to accurately predict how much work they can handle in 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 being worked upon by an experienced team. Because the team focuses on flow and limiting work-in-progress (WIP) and may be able to reduce the amount of time spent in planning and retrospective meetings, they may be able to produce work even faster than Scrum teams. Scrum teams essentially stop work for extended periods after every sprint in order to conduct their ceremonies..
In the case of the Kanban system, work moves in 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.
However, if 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 emphasis within the organization on accurate prioritization and respecting the sprint backlog to allow the team to focus on completing the work they have committed 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 stakeholders satisfied with the amount of work that is produced? Are they satisfied with the quality level of the work? 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 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 are 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, 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 is a sprint 0 (sometimes this is even a little longer than the time-box for subsequent sprints) where the Scrum team meets and begins to develop a product backlog, understands dependencies, and comes up with a release plan. The release plan gives a rough idea of the work to be released within a set amount of time (this could vary but 3-6 months is not uncommon). At the end of every sprint, the team presents the work they have completed and adjusts the release plan as necessary. Having this level of structure and short feedback loops for new teams can be very helpful for managing 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 requires assigning people to Scrum Master and Product Owner roles. Training sessions need to be conducted to go through the different ceremonies and roles. The physical work area may need to be changed as well to enable easier collaboration. In addition, both the team and management would 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 need to start implementing WIP limits and these should get stricter over time as the team matures. Although beginner teams may not be able to take full advantage of the flow, continuous delivery, and continuous improvement elements enabled by Kanban, the barriers to starting are lower since there are no prescribed roles or ceremonies.
6. Experience Sizing and Work Estimation
Both Scrum and Kanban benefit from the ability of teams to break work down into manageable chunks that can either fit into a fixed time box (2-4 weeks) or move across a Kanban board within a reasonable cycle time. For teams that are new 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 work, Scrum may be the easier route. In scrum, there are set ceremonies where estimating, grooming, inspecting, and adapting take place because of which teams are forced to analyze their sizing including estimating every sprint.
If work is not being completed within the agreed upon time box, the team needs to discuss the “why” at the end of every sprint. The teams can then use this feedback and lessons learned, during the next sprint planning, to break work down into smaller increments or make more realistic estimates. Kanban also has planning and retrospective sessions, but as they are not prescribed, teams that are less mature may tend to let too much time pass in between retrospectives or may skip them altogether. In addition, they may not plan effectively and end up with work that is too big and 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:
What this means, is 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. On the other hand, if the team is expecting high levels of change (such as those seen in support/maintenance teams) or if the team is at a high level of maturity and can optimize flow and take full advantage of continuous delivery, Kanban may be a better fit.
For more information, write to us at firstname.lastname@example.org.