Kanban v/s Scrum – Which is one better?

Kanban and Scrum are project management methodologies that complete project tasks in small increments and emphasize continuous improvement. But the processes they use to achieve those ends are different. While Kanban is centered on visualizing tasks and continuous flow, Scrum is more about implementing timelines for each delivery cycle and assigning set roles. Both Kanban and Scrum borrow from Agile and Lean approaches, though Scrum is often more heavily associated with Agile. That means Kanban and Scrum are both adaptive, and transparent, and reduce inefficiencies in the project process. When choosing between Kanban or Scrum, the individual distinction doesn’t always have to be made because Kanban and Scrum can go hand-in-hand. Here’s more on Kanban vs. Scrum and their similarities and differences. Many Scrum teams also use Kanban as a visual process and project management tool. While some teams prefer to use only Scrum because of its prescriptive nature (there is less ambiguity), many Scrum teams have adopted select principles of Kanban that are useful in adding an extra layer of visibility to their projects.

Scrum and Kanban are two terms that are often (incorrectly) used interchangeably or thought to be two sides of the same coin. In reality, there are significant differences between these two Agile methodologies. Understanding these differences is key to choosing the path that will work best for your environment. In a nutshell, what is Scrum? Without getting too detailed, Scrum is a tool used to organize work into small, manageable pieces that can be completed by a cross-functional team within a prescribed time period (called a sprint, generally 2-4 weeks long). To plan, organize, administer, and optimize this process, Scrum relies on at least three prescribed roles: the Product Owner (responsible for initial planning, prioritizing, and communication with the rest of the company), the Scrum Master (responsible for overseeing the process during each sprint), and the Team Members (responsible to carry out the purpose of each sprint, such as producing software code.) Another common tool used by scrum teams is the Scrum Board – a visual representation of the work flow, broken down into manageable chunks called “stories”, with each story moved along the board from the “backlog” (the to-do list), into work-in-progress (WIP), and on to completion.

What is Kanban?

Kanban is a highly visual way of executing Agile. It’s practically synonymous with its eponymous artifact, the Kanban Board, which has taken on a life beyond Agile product development. In fact, “Kanban” in Japanese means “billboard” or “signboard.” It was developed by Toyota to support its just-in-time manufacturing process, leading to the Lean approach. It emphasizes demand-driven development, which minimizes waste. What separates Kanban from some other processes is that it doesn’t require you to blow everything up and start over. It can be superimposed on top of what’s happening now and visualizing things, slowly introducing incremental changes to make development more efficient. While this may eventually lead to substantial shifts in how organizations function, it’s not disruptive and doesn’t force staff to make any uncomfortable changes.

The Kanban Board puts every project, initiative, and feature into one of the columns. The most straightforward boards have three columns:

·         Requested/To Do

·         In Progress

·         Done

With this minimal sorting of work, everyone knows the status of every item under consideration. When something exits the “In Progress” column, another item can take its place. It avoids having too many items in progress, which might overload development resources. Add additional columns to the Kanban Board to add more granularity to each of those fundamental phases. For example, within “In Progress”, there could be sub-categories such as “Design,” “Development,” and “Testing.” But the fundamentals remain, limiting how many are in each stage.

What is Scrum?

Scrum is an Agile methodology designed for complex projects where it is frequently necessary to adapt to change. Professional Scrum Master is based on short development cycles called sprints, which generally last from one to four weeks. A Scrum team is self-organized, small (typically no more than nine people), and includes one Scrum Master and one product owner. The rest of the team is called the development team. As typical of Agile frameworks, Scrum uses an iterative approach to completing projects. Instead of delivering a project all at once, teams complete and deliver tasks in stages. This makes it easier to adapt to changes and evolving priorities.

Scrum is built on three pillars:

·         Adaptation: Scrum is adaptive, meaning it embraces change. Scrum can easily accommodate a project changing tactical directions.

·         Transparency: Transparency ensures everybody on the team knows what is going on and why. 

·         Inspection: Team members and stakeholders inspect projects consistently. This encourages a culture of improvement.

Scrum also has five core values: courage, focus, commitment, respect, and openness. These values emphasize the importance of clear and honest communication, as well as a sense of ownership by each member of the team.

Kanban vs. Scrum: Which should I choose?

Kanban and Scrum each have their separate strengths. But pitting Kanban against Scrum is a false dilemma; you can easily use both in your work to maximize the benefits.

When to use Kanban?

Kanban has been shown to improve visibility, foster a culture of continuous improvement, and increase productivity  Kanban can fit in with processes that already exist—including Scrum. If you don’t want to overhaul your entire work process but are hoping to gain the benefits that an Agile process can bring, Kanban can be a good way to start.

When to use Scrum?

Scrum has been linked to higher productivity, faster delivery, lower costs, and higher quality. Many project managers also see Scrum as an effective method to tackle complex projects, or projects that might see frequent change.Scrum can make sense to use if you’re in an industry that sees frequent change, or if your project might need space to adapt to feedback. This might include industries that have frequent technology updates, or projects creating new products.

Kanban and Scrum vary significantly from each other in certain respects, although they’re not completely incompatible—there’s even a Scrumban framework that takes the best of each and merges them. But many of the attributes of these two philosophies stand in stark contrast with one another.

Wholesale vs. incremental change: No one “dips their toes” into Scrum; it’s a wholesale shift to an entirely new way of delivering projects. For organizations that feel “broken” or need a seismic shakeup, it could be just the thing to turn things around. But for companies that are generally happy with how things work, Kanban is an incremental, non-disruptive methodology.

Who does what: Rolling out Scrum requires significant organizational changes and likely the creation of new roles, which might even require hiring new people with relevant expertise. You need Scrum Masters and Product Owners for every development team, and an Agile Coach might be required to help stand things up and implement this new paradigm. On the other hand, Kanban doesn’t necessitate any changes in staffing, roles, or responsibilities other than deciding who “owns” the Kanban Board.

Prioritization: Neither Scrum nor Kanban dictate how organizations prioritize projects and initiatives. However, the Sprint nature of Scrum may impact how many items can be worked on simultaneously, given the short window of working time available. It could drive prioritization decisions, as it’s easier to crank out smaller projects in a single Sprint than tie a Scrum team up for multiple Sprints on a longer one. Kanban also limits how many things can be “In Progress” simultaneously, but these decisions aren’t based on development windows or Spring length.

Cadences: Both Kanban and Scrum are “pull-forward” frameworks; you don’t start something new until you finish something else. The big difference is things in Kanban are done when they’re done, while Scrum uses Sprints to break down the work, creating a much more predictable environment. Depending on the size of each project and the number of development resources, this might mean Kanban has more frequent or fewer releases than a Scrum organization with a set two-week cadence. It all comes down to bandwidth and scope. If projects only take a couple of days, in Kanban, it’s ready to go, while in Scrum, it might sit on a shelf until the rest of the Sprint is complete. If it’s a bigger project, it might be months between releases in Kanban, while Scrum will produce incremental work each Sprint. Scrum also requires very precise scoping and estimation to fit projects into Sprints. Kanban doesn’t necessitate this, as projects aren’t timeboxed.

Metrics: While product success metrics don’t vary with either approach, measuring how well product development is going differs. Both will care about customer satisfaction, defect rates, and the like, but other metrics are distinctive for each method. Scrum uses metrics such as velocity to determine how well things are moving through the process along with Sprint Goal Success (i.e., how much of what the team set out to do for the Sprint happened). Kanban doesn’t have rigid measures, but it uses the lead time to see how well the development team is cranking through the list of items waiting to be built. Cycle times (how long it takes a project to get through the entire process) is another common metric, as is throughput, which looks at how much total work is you’re producing in a given period.

Change philosophy: In Scrum, when the Sprint is locked, it’s locked. Nothing’s getting added; nothing’s getting dropped. Late-breaking developments must wait for the next Sprint to kick in.

There’s no such limitation for Kanban, so modifications to scope, requirements, etc., can occur while things are working actively on.

Pros and Cons of Kanban vs. Scrum

Neither methodology is going to fit perfectly, so it’s worthwhile to examine the pluses and minuses of both.

Kanban

Pros:

·         Alignment – Kanban boards keep everyone on the same page.

·         Exposing chokepoints and bottlenecks – When columns start getting too long, they indicate a disconnect between resources and demand.

·         No hard-and-fast rules – True flexibility regarding prioritization, decision-making, what processes are necessary to enter or exit each stage

·         Flexibility – The queue of work to be done can be rearranged and reprioritized based on new data and strategic inputs without impacting the rest of the product development workflow.

Cons

·         Timeless – Kanban boards have no dates. Additionally, there’s no way to know if an item is one day or three months away from exiting to the next column within a particular stage.

·         Potentially outdated – Like any artifact, if you don’t update the Kanban Board, it’s not accurately reflecting things.

Scrum

Pros

·         Understandable – Scrum has no shortage of firmly established and documented processes, nomenclatures, processes, and timelines.

·         Rapid feedback – Because Sprints are so short, and there’s ample opportunity to release things, get input, and incorporate it into a future Sprint. Plus, there’s flexibility regarding what the team will work on in the next Sprint right up until it begins.

·         Daily meetings – The ceremonies of Scrum (including daily standups) mean issues don’t fester for long as everyone’s interacting daily to discuss things.

Cons

·         Inflexible – True Scrum is very strict about how things happen and who can be involved.

·         Constant pressure – The short length and rapid frequency of Sprints can be exhausting and doesn’t allow time to “breathe.”

Roles and responsibilities

On scrum teams, there are at least three roles that must be assigned in order to effectively process the work: the Product Owner, Scrum Master, and Team Members. Each role has its own set of responsibilities, and they must work together to achieve an orderly and efficient balance. The scrum team itself also must be cross-functional, which is to say that one team must have all the resources necessary to complete the entire sprint’s work. Under Kanban, no set roles are prescribed. Practically speaking, it makes sense for someone to serve as a project manager or supervisor, especially for larger more complex Kanban projects, but the roles should theoretically evolve with the needs of the project and the organization. A Kanban team is not required to be cross-functional since the Kanban work flow is intended to be used by any and all teams involved in the project. Therefore, a team of specialists and a separate team of generalists may be working on different aspects of the same Kanban project from the same board, and that’s ok.