Scrum vs Kanban vs Scrumban and other bullshit teams say

In the world of Agile, there are several methodologies and frameworks teams can choose from. Two of the most popular approaches are Scrum and Kanban, with Scrumban emerging as a hybrid of the two. However, many teams often use these frameworks as an excuse for not doing Scrum well or for not addressing the root causes of their team’s issues.

Let’s delve into Scrum vs Kanban and why sticking to Scrum and implementing it correctly is far more effective than resorting to alternative methods that might not fit the team’s needs.

Using Scrum Properly

Scrum is a simple framework: 3-5-3-5. It’s 3 Roles, 5 Events, 3 Artifacts, and (though these are often forgotten) 5 Values. That’s it. Too often teams implementing Scrum add a ton of additional things which, while many can be helpful to a lot of teams, they don’t really have anything to do with Scrum. Things like, estimation using the Fibonacci sequence, Burndown Charts, Pairing, and even Backlog Refinement.

While these practices are frequently helpful, they aren’t actually required for Scrum. Worse, some things which are essential to actually doing Scrum are frequently forgotten.

In my experience, it is the SPRINT more than any other part of the Scrum framework that most frequently causes frustration for many teams. The Sprint is an artificial deadline meant to help the team focus on getting work done in small chunks. When used correctly, the Sprint helps with effective story writing and splitting, collective goal setting, maintaining team focus, and understanding the team’s general pace of work (often called Velocity – a term, which one should note, NEVER appears in the Scrum Guide at all).

Some of the challenges we often see include:

• teams having difficulty with splitting stories into useful pieces that can be completed in a short time period.
• teams aren’t working in a way that makes collective goals useful.
• teams are working in a very fluid environment where planning out a Sprint of work in advance is challenging because new work is constantly arriving and has to be quickly addressed.

The answer to these challenges isn’t to choose between Scrum vs Kanban or even the hybrid Scrumban. The team needs to appropriately address the root causes of these challenges.

Here are three Scrum Patterns which, when used by a team running their Scrum well, make the challenges of working in a Sprint more constructive and useful than an outright swap to another methodology.

• Yesterday’s Weather: This pattern involves using the team’s previous performance as a predictor for future capacity. This helps the team to set realistic expectations and adapt based on past experiences.
• Illegitimus non Interruptus (The Interrupt Buffer): With this pattern, a team creates a buffer to handle unexpected interruptions that have the potential to derail the team’s progress. This helps in maintaining focus and productivity.
• Teams that Finish Early Accelerate Faster: By completing work items ahead of schedule, the team can accelerate their learning and improvement process. This not only increases efficiency but also helps the team tackle unforeseen challenges with ease.

The Misuse of Kanban

Don’t get me wrong. It’s not that Kanban is a bad fit for teams who could be using Scrum. Kanban is incredibly useful for teams who are constantly fielding interruptions. HOWEVER, 90% of the teams I meet running “Kanban” are actually running a loosely-organized, process-light version which tends to leave out some of the most important elements of the feedback loop needed for continuous improvement.

Kanban takes the training wheels off Scrum. A Kanban team requires a degree of rigor and attention to process which is often critically lacking, leaving teams no means to understand how they’re doing and ultimately, no way to improve.

A well-functioning Kanban team should:

• Constantly monitor lead time and cycle time to ensure tasks are being completed efficiently.
• Maintain strict Work-In-Progress (WIP) limits to avoid overloading team members and ensure tasks are completed in a timely manner; and
• Meet regularly to clarify upcoming backlog items, demonstrate finished work, and identify opportunities for improvement.

Sound familiar? These practices are quite similar to Scrum, but also highlight how the key to success lies in implementing the chosen framework diligently rather than just adopting a new one.

Scrumban – A Hybrid Approach with a Specific Purpose:

Scrumban originated in 2008 when Corey Ladas published the book, Scrumban: Essays on Kanban Systems for Lean Software Development. It was designed twofold: as a transition model to help a team shift from Scrum to Kanban gradually or as a way to find a balance between the two methodologies that best fit a team’s specific context and needs. Scrumban combines the iterative nature and roles of Scrum with the flow-based, visual aspects of Kanban to provide more flexible and adaptive solutions for teams.

However, it is essential to note that Ladas never intended Scrumban to be a standalone methodology. Some teams misuse it as a buzzword to escape the effort needed for improvement, often avoiding an understanding of its original purpose as an evolutionary process that adapts to a team’s needs.

Now What?

It is crucial for teams to acknowledge the real issue lies not in the argument between Scrum vs Kanban frameworks, but in a team’s unwillingness to address poor practices and invest in the effort needed for improvement. By implementing Scrum effectively and using proven patterns, teams can achieve far better results than by abandoning Scrum in favor of frameworks like Scrumban – especially when the odds are they are not even implementing it correctly. Ultimately, the key to success is to focus on continuous improvement, effective communication, and a commitment to do things right.

Visit our website to learn more about CAVU’s Scrum training opportunities!