
Agile and Scrum: Understanding the Differences
Explore the differences between agile and scrum.
Many Agile practitioners are already using elements of both Kanban and Scrum today and don’t realize it. If you are running a daily stand-up (daily scrum) and using a virtual or physical board to track your work, you are using concepts from both Kanban and Scrum; some people call this Scrumban.
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.
Kanban has its roots in automotive manufacturing, but Kanban principles are widely used now in software development. However, Kanban is not a framework or methodology; it is a strategy for optimizing the flow of value through a process. Kanban does not define roles, events, and artifacts, leaving more decision-making to the experience and goals of the Agile team.
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:
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.
Scrum is a framework for developing and sustaining complex products. Scrum is one of the most popular frameworks for software development teams to manage their work.
Key elements of scrum include definitions for:
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. Because of its popularity, according to the 15th Annual State of Agile Survey, 66% of teams are using Scrum. Knowledge of how to implement Scrum is widely available in the software industry.
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.
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.
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:
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.
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:
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:
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.
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.