Scrum, Kanban, Scrumban, Shape Up! Which is the Best Fit For You?

Clarifying the differences between common Agile frameworks

Which is the best framework for you to use with your teams? You may wonder whether you should work with Scrum, Kanban, Scrumban, Shape Up, or something else. I imagine you want to increase the odds of thriving but don’t know which option will help you the most. I often struggle with the same question.

The options can be overwhelming, and the noise can be distracting. Knowing which will help you with your particular challenges is hard, and it’s a choice you have to make. Nobody else can make it for you. Yet, you must understand the implications behind your choice.

Let me help you understand the differences between common Agile frameworks. By the end of this post, you should understand the essence of each option and be able to choose what fits you best.

Overview

Scrum, Kanban, Scrumban, and Shape Up are the most common Agile frameworks. You’d still find alternatives like eXtreme Programming, LeSS, Spotify Model, etc., but they are less common.

You may read this and wonder where the so-called Scaled Agile Framework, SAFe, is. The reason is simple; I don’t consider SAFe an Agile framework because of its high prescriptiveness and complexity. That’s why I left it out, and I’d encourage you to do the same unless you want to miss the chances to become Agile.

What’s the current trend of Agile frameworks? I posted a poll on my LinkedIn page to understand what people use to create value faster. You can see the result in the following image:

I didn’t aim to prove anything with this poll; I only wanted to know which frameworks people in my network use. I was quite surprised by seeing Scrum with such a vast difference because I currently see many people complaining that it isn’t helpful and is too rigid for them. I expected to see Kanban or Scrumban coming even closer, but that wasn’t what the poll showed.

One of the biggest challenges I see is understanding the implications of each option and how to play the game. Almost everyone has a particular interpretation of each framework. Unsurprisingly, implementations differ from company to company. I’ve never seen a purist application of any Agile framework, which is fine, but one must understand what’s part of the framework and what’s not. 

Let me try to shed some light on it. The following table summarizes the key differences between Scrum, Kanban, Scrumban, and ShapeUp:

You may look at this table and ask, “So? Which one should I choose?” Before you make the call, you need to understand your scenario and how the framework will fit you best. Stick with me, and I will try to help you understand each option better.

Scrum

Undoubtedly, Scrum is by far the most used Agile framework in the world. For most companies, it’s the first thing that comes to mind; the unquestionable choice. But is it a mindful choice or just a mass effect? 

Scrum has transformed itself into a highly profitable business. Scrum.org and Scrum Alliance have certified millions of professionals worldwide. With such an abundance of practitioners, it’s only natural that Scrum is the top Agile framework in the world. But is it the right choice for you?

I’ve worked with Scrum for over a decade and perceive it as a great framework. But it’s very easy to fall into several traps:

• Process Orientation: Scrum is rigid with events. You have Sprints, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Although the objective is to make room for the required exchanges, teams often fall prey to process orientation and forget the meaning of each event.
• Vicious Circle: Scrum runs in cycles of one to four weeks. The cycles are unstoppable; Scrum teams will not have any pause between Sprints. Once one Sprint finishes, the other immediately starts. It can be overwhelming if teams don’t learn how to manage it properly., and many developers hate the cycles as they perceive them as counterproductive for their work. You’d find arguments for both sides of the same coin.
• Feature Factory: The soul of Scrum doesn’t lie with its process but with the mindset behind it. Two essential parts determine how empowered teams can be: Product Goals and Sprint Goals. The problem is that many Scrum teams struggle to pursue goals and fall into a feature factory mode. The only goal is to deliver features by the end of each Sprint.

My take on Scrum: It’s simple to implement, and teams understand it easily. The challenges go beyond the framework itself. It’s complex to transform how organizations work, and most Scrum implementations touch only the delivery aspect of products, which will be suboptimal and ensure poor results.

To thrive with Scrum, It’s crucial to understand that the framework is incomplete by design, and teams must add aspects to ensure they create value. For example, Scrum doesn’t mention product management practices, yet, no team working with digital products can succeed without them. 

Scrum isn’t limited to delivery, as many people think. It’s a framework to create value from end to end.

Kanban

Initially, Kanban emerged as a scheduling system for lean manufacturing, originating from the Toyota Production System (TPS). In the late 1940s, Toyota introduced “Just in Time” to its production. Unlike the standard push practice of producing goods and pushing them to the market, Toyota introduced a pull system based on customer demand. That was the birth of Kanban.

What’s Kanban?

Technically, Kanban isn’t an Agile framework. It’s a lean method to help people improve how they collaborate by making their workflow visible and transparent.

I frequently hear the debate of whether Kanban is a framework or not. Honestly, this discussion is pointless. The fact is simple: Many teams opt to use Kanban as their working method. So what does working with Kanban mean?

Unlike Scrum, Kanban isn’t a process framework with everything predefined. Kanban has a set of characteristics and rules to follow. Beyond that, the team must figure it out independently. Here’s what’s part of Kanban:

• Visual Workflow: A board with swimlanes representing the workflow of the team. This board should be visible and accessible to everyone on the team. It clarifies the steps required for a task to get done.
• Work In Progress: Kanban limits the work in progress (WIP) per swimlane. This forces the team to address problems when they get stuck. Team members are not allowed to go beyond the WIP limits.
• Cards: Each card represents a task that the team needs to execute. The card will go through the entire workflow until it gets done.
• Principles: Start with what you do now, pursue incremental improvements and encourage acts of leadership at all levels.

Kanban doesn’t define roles or events; it’s up to teams to determine what would fit them. I’ve noticed that experienced teams can work pretty well with Kanban, while less experienced ones get confused with such flexibility and tend to waste their time with activities like curating their board, solving impediments, etc.

Kanban isn’t against Scrum. Most aspects could be combined and even beneficial. You know where I’m going—let’s talk about Scrumban.

Scrumban

Many people think Scrumban is a hybrid of Scrum and Kanban. That may even be what happens in practice, but it wasn’t the initial idea of Corey Ladas, creator of Scrumban. His original objective was to use Scrumban to transition from Scrum to Kanban. 

Curiously, if you work Scrum, you may already be in a kind of Scrumban without knowing.

A team working with Scrum would need seven steps to apply Scrumban:

1. Visualize the Work: Create a visual Kanban board with your workflow. Ensure that every team member has access to it.
2. Step Early Binding: Do not assign tasks to team members. Let them pick the tasks once they become available.
3. Impose WIP Limits: Define limits for each step of your workflow, this aims to ensure collaboration when team members get stuck. No one in the team can go beyond the limit.
4. Swap Push and Pull: Create lanes between steps to clarify the process. For example, a traditional flow contains the following steps: To Do, In Progress, Testing, Done. When it gets to testing, you might end up with no one doing the actual testing—even if you think someone is. A push and pull would imply a step in between, for example, Test Ready. This would give the team full transparency of reality.
5. Start Ordering: Sort the items according to priority. It’s a sequence; nobody can pick what’s down the lane. Team members can only pick what’s on top. Up until this step, Scrumban is fully compatible with Scrum, but steps 6 and 7 will take them in different directions.
6. Stop Estimating: Scrumban teams do not estimate any work. It’s perceived as wasteful, and they simply don’t do it. This would be against Scrum as it determines Product Backlog Items need to be sized.
7. Trigger Planning: Scrumban doesn’t have an event for planning—planning happens on demand. Once the To Do lane reaches a set low, it’s time for planning. This isn’t similar to Sprint Planning; the team would pick the Product Backlog, refine items and bring just enough to the board. Unlike Sprint Planning, Scrumban planning doesn’t require setting a goal.

For me, Scrumban is a hybrid of Scrum and Kanban, even though that wasn’t the initial intention. I have to be honest; I’ve never worked with it exclusively. I generally remain skeptical about steps six and seven. My take is that it requires seniority to skip estimating and planning. I imagine it working well when the team is empowered, trusted, and senior enough to self-manage.

The downside I see with Scrumban is the lack of goals. I see an extreme focus on getting things done while it lacks the direction on why that matters in the first place. In most places I’ve worked, I’d imagine stakeholders loving this framework as they could push their wishes, and teams would execute them. As I said, it would require seniority and expertise to know what to put on the board and what to keep out.

Shape Up

Basecamp is a successful company with a particular way of working. They don’t call their style Agile or relate to any other framework. Three years ago, Ryan Singer published a book revealing how Basecamp works. The book is rather long (160 pages) but gives solid examples of why they do what they do and how it works for them.

Shape Up is for product development teams who struggle to ship

Shape Up, Stop Running in Circles And Ship Work that Matters

Shape Up is relatively new to the Agile game. The book was published in 2019, though Basecamp has worked this way for over a decade. After making Shape Up available to the public, some companies became curious about it and started adopting this way of working. There are some things I find quite interesting about Shape Up:

• No Product Backlog: Shape Up has no Product Backlog. They have ideas and shape them to a level teams can implement. This approach forces teams to remain alert to current problems and work on what matters most; unselected ideas to build during the next cycle are discarded.
• Shapers and Builders: The roles clearly segment discovery and delivery. Shapers work on understanding problems and defining high-level solutions while reducing implementation of risks. Builders implement predefined solutions. They don’t challenge whether the problem is worth solving but focus on building the solution right.
• Small Teams: Once an idea makes it to the next cycle, a team of two or three people will implement it. No team would have more than three people, and teams are dynamically defined per idea. This means people often change the teams they work with.
• Strict Cycle: Each cycle lasts precisely six weeks—no more, no less. A cycle can have either one idea of six weeks appetite (effort investment term) or three ideas of two weeks appetite. The team has this time to get things live. If they don’t manage, they won’t continue working on it unless the idea makes it to another cycle.
• Cool Down: After each cycle, the team has a two-week cooldown. Unlike Scrum, teams would have complete flexibility during this time. The team may use it to address tech debt, fix bugs, or do whatever they want. This is when shapers will bring ideas to the betting table and agree on what will make for the upcoming cycle.

Basecamp is a small successful company. It’s hard to believe what they achieved. I think a lot has to do with how they work: Their product has millions of users worldwide and a staff of around fifty people, so I can only imagine Shape Up works incredibly well for them. Yet, I’m curious as to how this would play out in bigger organizations.

Summary

I’ve just shared common frameworks with you. Now, you may wonder, which one do I pick? What best fits my scenario? You still need to answer that on your own, but I can give you some hints to make it easier to reflect:

Final Thoughts

I must be honest with you. I don’t believe you’ll find a perfect choice for your scenario. Whatever your choice, to benefit from agility you need to be ready to embrace a learning journey. 

No framework will get you far without a value-driven mindset.

I encourage teams to take one step after the other. Look at your scenario and ask, “What could we do now to increase our chances of creating value sooner?” Take one action at a time, and you’ll be surprised by the results. Do that as often as possible. Consistency and courage will put you on the right track.

My last recommendation is to avoid dogmatism. You can mix practices from different frameworks. Your goal should never be to master Scrum, Kanban, or whatever you choose. Your goal should be to find better ways of collaborating and creating value sooner. That’s what Agile is about. 

It’s never about mastering a framework. It’s all about improving collaboration and creating value sooner.