Kanban vs. Scrum: When to use what

The question of whether to emphasize elements of Kanban or Scrum frequently lies with the nature of the work and the team’s desire for more or less structure in their process. Agile teams who want more structure and definition can benefit from the guidance Scrum provides. Agile teams who prefer more flexibility, experimentation, and analytics often benefit from a focus on Kanban.

Let’s dive into these two concepts to understand when to use what.

In his 2010 book, “Kanban: Successful Evolutionary Change for Your Technology Business”, David J. Anderson defined the six key practices that drive success with Kanban:

• Visualize the workflow: it ensures a team’s work is transparent to prompt the right conversations at the right time and proactively discuss improvements.
• Limiting work in progress (WIP): teams should explicitly limit the number of work items in progress, so new items are pulled only when capacity is available to work on them.
• Manage flow: it requires teams to work quickly to identify and resolve blockers while reducing old, in-progress items
• Make policies explicit: examples include WIP limits, definition of ready, and other rules to define the workflow.
• Implement feedback loops: make sure feedback loops are in place and in use.
• Improve collaboratively, evolve experimentally: ensure time for continuous and incremental improvement.

Many people think of a “kanban approach” as primarily for managing support teams who are constantly reprioritizing incoming tickets. However, Kanban can be highly-effective for mature digital product teams to accelerate development. The focus on flexibility, collaboration, and metrics are popular with and well-suited to low-code development.

Key elements of scrum include definitions for:

• Team roles: development team, product owner, and scrum master.
• Events: the sprint, sprint planning, daily scrums, sprint review, sprint retrospective.
• Artifacts: product backlog, sprint backlog, and (product) increment.

A key benefit of Scrum is that teams can quickly define their team structure, a consistent work cadence, and the product they will deliver using the Scrum framework.

Kanban vs. scrum: key differences

Kanban and Scrum share many similarities at the macro-level, but key differences exist. These differences can impact your choice of one or the other for your low-code project.

Agile teams, especially those working with low-code, should closely consider the characteristics of each approach in deciding which are best aligned with their goals. If your team is currently using Scrum, consider an action item to evaluate how to incorporate more Kanban, e.g. new metrics, etc., to accelerate your process.

What about Scrumban?

Scrumban describes an approach where teams use elements from both Scrum and Kanban to improve team performance and increase the value delivered to their customers. Agile teams using Scrum Events, Roles, and Artifacts together with a physical or virtual Kanban Board in JIRA or other tools, are already practicing Scrumban.

In addition, Agile teams frequently use Scrum techniques like sprint commitments to define the overall work in a sprint while managing the team’s work with the Kanban concept of limiting work in progress. Limiting work in progress can improve developer efficiency by reducing the cost of frequent context switching.

Scrumban can be an excellent choice for Agile teams who want to combine the structure and guidance about organizing the team from Scrum with Kanban techniques, which help define how to do the work.

How should you decide which approach is best?

First, whether you are starting up a new team or reevaluating your approach for an existing team, remember that there is no best approach for all teams. There is no single definition of Agile. Defining the best approach for you and your team is based on your specific team goals, culture, maturity, technical competence, and other factors. There is no end state; this is a process of continuous improvement and learning.

Nonetheless, teams should consider using a structured decision-making approach to evaluate whether Scrum, Kanban, or Scrumban is the way to go. Some key considerations when evaluating your approach include:

• Educate yourself about all three of these approaches. If you’re using Scrum, then take time to learn about Kanban. A huge amount of high-quality content is freely available online. Read blogs, take free assessments, sign-up for online or in-person courses.
• Understand your organization’s goals. Many teams take the wrong approach because they don’t know how their work fits into the overall goals of their organization. Is your work focused on speed to market, digital transformation, reducing application backlogs, or technical enablement on a new platform? Those goals can impact your approach.
• Ask for outside help. Sometimes it’s difficult to look at your own knowledge and performance objectively. Although they can be very helpful, outside help does not have to mean consultants or coaches. Consider getting input from people from other teams or from your professional network.
• Get feedback from your customers. The customers you’re serving, whether internal or external, can offer critical feedback on the value, clarity, and effectiveness that your current process delivers. Even if they are not experts in the process, customers know how it works and feels to them. We should listen and respond to their feedback and needs.
• Assess your process maturity. Does your team currently struggle to define a well-defined process? Does your team have a process that consistently delivers value to your customers? Do you need to focus on performing at a high-level with your current process before trying something significantly new?
• Assess your technical maturity. If your team is still increasing its proficiency with your technology stack, then an approach that provides structure and consistency may be the best strategy. As your team builds its expertise with the technology it’s using, you can consider moving to a framework with more fluidity and flexibility.
• Determine your team’s need for structure. Some teams simply prefer to have more structure in their process, whether they need it or not. Talk to your team members. Observe how they work. Listen to what they say. Do they feel better and perform better with more structure or less? Use this as a guide to selecting an approach.

Which approach should you use for your low-code project?

Whether you’re working with low-code, high-code, or a business-focused activity, there is never a single, static answer to which Agile approach you should use. That said, if you’ve analyzed your organizational and team needs using the questions in the previous paragraph, some characteristics, needs, and patterns should emerge, which help you determine the best approach.

Scrum or Scrumban

Teams who feel they perform better with greater structure and a regular cadence may find Scrum or Scrumban is the best choice. Scrum is the most popular Agile framework for a good reason; it is easy to understand and highly effective. Examples of situations where Scrum or Scrumban may be the best approach include the following:

• New teams. If you’re early in the journey through Tuckman’s Stages of Team Development, Scrum may be the best choice. The clearly defined roles in Scrum provide an excellent guide for team members to make sure they understand their role and contribution to the team.
• Blended teams. Blended teams may include a combination of on or off-shore teams, company employees and consultants, and, more likely today, citizen and professional developers. In these situations, team members often have different experiences and views on how to build digital products. Scrum provides the structure and definition of how to build your products. In particular, Scrum can help guide conversations across multi-cultural and cross-functional teams about how to structure and deliver a product backlog.
• Teams integrated in larger ecosystems. If you are part of a larger organization and responsible for delivering to or receiving from other development and business teams, Scrum may be the best choice. The fixed-length sprint cadence in Scrum can make it easier and more predictable to plan, thus making it easier to work with interdependent teams.
• Teams comfortable with Scrum. Let’s face it; some teams are just more comfortable with the predictability and definitions that come with Scrum. Scrum is popular because many people like it and succeed with it. If your Scrum team is stable, high-performing, and delivering value, look for ways to improve on the margin, rather than radically changing the approach.
• Scalability. Scalability is a critical consideration for any development framework. Product development teams increasingly large networks of interconnected teams. Scrum is very well-suited to quickly grow or shrink the number of teams required to build a product. Frameworks like Nexus or Scrum at Scale provide excellent models for scaling Scrum whether you are working with high-code or low-code development platforms.
• Scrum or Scrumban is the best approach in many situations. The best approach is often to define a starting point, try it, learn, and adjust.

Kanban

Low-code teams comfortable with less structure and more flexibility may find Kanban a better choice. Some people feel that Kanban is a natural evolution from Scrum or Scrumban, but that’s not necessarily the case. The best choice may be to jump right into Kanban, full-throttle from the start. Some examples where Kanban fits best include the following:

• Speed is the #1 priority. In situations where you have a mature team and speed to market is the most important factor (when isn’t it?), Kanban is usually the best choice. Kanban encourages self-organization and enables flexibility and delivery while minimizing formality and process overhead. Teams use quantitative metrics to drive efficiency and improvement.
• Mature technical teams. Teams with strong expertise in low-code development can benefit from the focus on efficiencies from limited work in process and flow through the system. With fewer basic technical questions to consider, teams can focus on increased real-time collaboration with product owners and end-users, for example.
• Mature agile teams. If your team demonstrates a deep understanding of Agile development and the ability to deliver value consistently, Kanban may enable them to accelerate further with low-code. For example, mature Agile teams can benefit from defining release dates based on the work to do rather than a timeboxed, fixed-length sprint. That can reduce planning and estimating overhead and deliver product-to-market faster.
• High-performing functional teams. Succeeding with Kanban requires maximum flexibility and responsiveness. Those characteristics need to extend to team members responsible for defining requirements. Kanban does not specify the Product Owner role, but in practice, someone must be able to describe the value for users and make decisions about what to build. In addition, without a deep backlog of high-quality user stories at the start and a process for defining new requirements at the same pace as low-code development, teams simply cannot maximize the speed of low-code.
• Flexibility to choose cadence and duration. It’s not always efficient or practical to develop products neatly in fixed-length sprints. You may have single or multiple teams building application components of varying sizes. Rather than breaking up parts to fit into regular, fixed-length sprints, it is more efficient to build them as releases of varying lengths. In cases where parallel teams, sometimes with varying levels of skill and maturity, are building product components of different sizes, using Kanban to manage these release cycles makes sense.
• Scalability. Kanban does not provide prescriptive guidance for scaling to multiple teams. Kanban does, however, give experienced, mature Agile teams the flexibility to define how they work together to maximize speed and efficiency. As a result, Kanban Teams can quickly and easily scale up quickly and right-size later as needed. A key consideration when defining how to scale Kanban is understanding and defining how interdependent teams will manage dependencies.

Overall, if your team has or can develop the skills and maturity to implement Kanban, it can enable you to accelerate development and improve team efficiency. By reducing some of the formality and overhead in your process, the team can focus more time on design, development, testing, and user feedback.

Keep learning

Whatever approach you choose for your low-code development team, your main focus should be continuous learning and improvement. Focus on challenging your team to ensure that your process aligns with and maximizes the speed and quality that come with low-code development.

Frequently asked questions