Is Scrumban Really Scrum 2.0?

Is Scrumban Really Scrum 2.0?

Have you ever tried to fix something and found your efforts didn’t do any good at all? Maybe you tried to remove a stain from a carpet, but it only made it worse, or fixed a cupboard in your home, only to have your kids break it again the next day.

Sometimes we don’t fix problems because we’re too fixated on them. Identifying the root cause entails panning out and using some lateral thinking.

The agile methodologies that emerged in the 90s sought to remedy systemic flaws in project management by taking a completely new approach. They wanted to improve processes so that chronic problems didn’t happen over and over (and over) again.

And the methods did provide real solutions. The scrum framework boasts of faster production times, more motivated teams and happier clients. And kanban and lean improves processes and creates a more efficient workflow.

But one principle of agile is ongoing reflection and improvement. As developers have worked with the scrum, kanban and lean methods, they’ve identified flaws, and sought to improve them.

One of these solutions is the fusion of these three agile systems, known as “scrumban.” Although agile hybrids come with their share of controversy, scrumban certainly has its advocates.

Let’s look into the anatomy of scrumban and discuss its pros and “kans.” Then, we’ll look into how a team modifies its scrum framework to implement scrumban.

What is Scrumban?

Have you ever been to one of those food carts that serves food fusion? Maybe it was Korean tacos or Thai burgers.

Scrumban is the same idea, just using agile methodologies. Simply from its name, it’s easy to guess that “scrumban” is a fusion of “scrum” and “kanban.” What you can’t tell from the name, however, is that scrumban also incorporates some concepts from lean.

The term “scrumban” was first coined by Cory Ladas in a 2008 article. He later fleshed out these ideas in his book, Scrumban: Essays on Kanban Systems for Lean Software Development.

Ladas sought to remedy what he saw as errors in the scrum framework, in part by combining it with the kanban workflow system, which is closely related to the theory of constraints.

Scrumban aims to integrate each agile method into a team’s work process, while maintaining the integrity of each.

In order to understand scrumban, let’s first look at the essence of scrum, kanban, and lean individually. Then, we’ll see how they’re combined to form scrumban.

Scrum

Scrum is an agile framework developed by Jeff Sutherland and Ken Schwaber in the 90s. It’s a project management or product development system that aimed to remedy the flaws they saw in waterfall.

Scrum is an iterative approach to project management. The team produces work in small batches and then looks at what they’ve done before planning more work. Scrum has distinct roles, ceremonies and artifacts. The roles include the scrum master, the product owner, and the development team.

Many teams have found the scrum framework helps enormously. It keeps a team continually focused on adding value to the client, and it emphasizes self-management, which keeps teams motivated and creative.

However, others have struggled with scrum’s system for assigning and organizing work. In scrum, just one person, the product owner, prioritizes and selects work for the team. At the beginning of a sprint, from among all the work in the product backlog, the product owner identifies those tasks that will add the most value to the project goal. Although this is a collaborative effort, scrum assigns accountability and decision making to the product owner.

Scrum doesn’t set a limit on the number of tasks in the product backlog, and what often happens is that various stakeholders ask the product owner to add more and more requirements, causing the backlog to overflow. The scrum system does nothing to fix this; rather the product owner simply continues to select the most important items, and the team goes and does them.

The lead time between when something is added to the backlog and when it’s produced, however, inevitably starts to increase, and the stakeholders become increasingly frustrated with the system. Sometimes the position of product owner is then assigned to an entire team (a big no-no according to scrum rules), or else the stakeholders simply ignore the product owner and go straight to the team to request work.

These are some problems that Ladas sought to fix when he introduced scrumban. The remedy he provided came from concepts in kanban and lean.

Kanban

Kanban is an agile method that isn’t so much an approach to project management as it is a method for examining and improving current processes within an organization. It seeks to look at how things really are done, not how the organization plans or aspires to do them.

David Anderson is a software developer who studied Eli Goldratt’s theory of constraints in the early 2000s, and applied it to software development. While working at Microsoft and Incorbis, he implemented a system called kanban, which uses the theory of constraints but limits work to small batches. He has identified four key steps to implementing kanban:

1. Look at what the team is doing now.

This means documenting actual processes, not just what ideally happens day-to- day.

2. Understand the current processes.

This step is quite involved. Oftentimes it entails visualizing the workflow, and identifying the exact steps a product goes through before its release. This can include writing code, testing, and peer review.

3. Set work in process limits.

This is the real hallmark of kanban. Setting work in process (WIP) limits is a quick and easy way to identify bottlenecks within the workflow.

An example is helpful here. Have you ever been to a coffee shop on a busy morning? Oftentimes the cashier may take 5-6 orders in the same time that it takes for a barista to make just one coffee, and so a line of cups start to stack up beside the espresso machine.

Kanban limits the amount of cups allowed to stack up. Once they reach a certain number (say, 7) then everything else needs to stop. The cashier stops taking orders, and the team focuses on pushing the coffees through the workflow. If this bottleneck becomes chronic, then the owner purchases a second espresso machine to fix it.

This is where kanban is similar to the theory of constraints, which is about identifying where a company’s process is the slowest, and developing its workflow around it.

4. Establish a pull system through the work chain.

The kanban pull system means only producing enough capacity as the next step in the process can handle. So at a coffee shop, the cashier only takes orders as the barista is able to make coffees. This keeps bottlenecks from occurring in the workflow, and allows everyone to work at a steady pace.

Lean

As the name suggests, the lean agile system is about trimming all the fat off a work system. A lean workflow only spends time doing something that adds value to the final product. It carefully maps out a value-stream in the work process, ensuring that every step is useful and no actions are wasted energy.

All Three Methods Combined

Scrumban first and foremost is scrum. If scrumban were a cupcake, then scrum would be the cake, kanban the icing, and lean the sprinkles on top.

Here are three things that scrum picks up from kanban and lean in order to form scrumban:

1. Kanban Board

Scrumban emphasizes visualizing the workflow, and utilizes a kanban board for plotting every step of the work process. With a kanban board, work tickets are moved along each stage of the work process.

2. WIP Limits

Scrumban establishes WIP limits at every stage of the workflow, which allows the team to identify bottlenecks.

3. Push, Not Pull

Much of the scrum framework is push: the team plans sprints, and stories oftentimes are assigned to specific users. However, scrumban turns this around to create a pull system. Work is produced only as the next step is ready for it.

When scrum fuses with both kanban and lean, it creates a more transparent process for the project stakeholders, and allows the team to have a continuous workflow. It also solves the problem of the flummoxed product owner. With WIP limits, the product backlog simply cannot get too full.

The Pros and Cons of Scrumban

To some, mixing agile systems is an anathema. And to others, scrumban has achieved agile perfection. Most fall somewhere in between. Let’s discuss common advantages and disadvantages of scrumban.

Advantages of Scrumban

• Identifies Bottlenecks

  The biggest strength of scrumban is that it utilizes all the benefits of scrum, and it identifies bottlenecks to boot!

  By setting limits to the product backlog and each stage along the workflow, it’s easy to quickly identify where work tickets stack up and an area is overburdened.

  It forces people to work at a moderate, sustainable pace and keeps stakeholders from making too many requests at once.

• Decreases Lead Time

  Once the bottlenecks are identified, the next step is to fix the process. Initially, the team swarms to get the work done at the bottleneck, so it can progress onto the next stage.

  It also looks to identify the cause of the bottleneck and fix it. Maybe a testing team takes too long because it doesn’t have enough people, or a manager has too many things to sign off on.

  The result of fixing bottlenecks is that lead times go down. Whereas a stakeholder might have waited several months for a deliverable, now it only takes several weeks.

• Increases Visibility for Stakeholders

  Kanban is a visual system. Each stage of the work process is visible not only to the development team, but to all of the stakeholders as well.

  This is different from scrum, where a team goes into a bit of a time box during a sprint, and only engages directly with the stakeholders during the sprint review.

  When stakeholders get to see how the sausage is made, it increases cooperation and understanding within the team.

• Creates a Continuous Workflow

  Setting WIP limits means that people aren’t deluged with work anymore. If any stage reaches its limit, the team swarms to get the work done and the work process can keep flowing.

  In sum, scrumban really improves a project development cycle. Overall it increases visibility and makes the workflow more fluid, allowing teams to work at a steady pace.

Disadvantages of Scrumban

Blending agile methodologies, generally speaking, is not considered a good thing. According to the Scrum Dictionary, “hybridized agile may induce paradigm induced blindness.” This means that people become so overwhelmed with the variety of systems that they simply follow rules without thinking about them.

And scrumban would certainly fall under the umbrella of hybridized agile. Let’s look specifically at a few disadvantages to utilizing scrumban.

• Scrum Purists Object

  According to Jeff Sutherland, the creator of scrum, if you tamper with scrum, or change the processes in any way, you risk losing all benefits the method provides. In his words: “Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefit of Scrum, potentially even rendering it useless.”

  As he sees it, his system needs to stand alone. Scrum is about exposing impediments and blockers in the team’s work process. Making big changes and tweaks to the scrum roles, ceremonies and artifacts may only serve to push these problems back under the rug.

• Managers Won’t Fix Bottlenecks

  Identifying bottlenecks is only half the battle of improving a work process. Fixing them is the other half.

  However, when a manager is identified as the problem (e.g. they spend too much time approving a deliverable), they may simply deny it. They want problems to be relegated to the development team. This lack of cooperation, to use Sutherland’s words, renders scrumban useless.

• The Team Loses Velocity

  One aspect of implementing scrumban (which we’ll cover more extensively later on) is that the team stops assigning story points to user stories. It’s seen as an inefficiency, per the principles of lean.

  This means the team can’t measure sprints with velocity, and so cannot project how long a project might take. The burndown chart, which measures a project along its timeline using story points, wouldn’t be applicable with scrumban.

  In sum, scrumban certainly does have its drawbacks. It’s up to individual teams to determine if the disadvantages outweigh the advantages.

How to Implement Scrumban

If your team experiences bottlenecks and you think scrumban is just the thing to fix it, in spite of people who warn against hybrid agile, then here are the basic steps to go about implementing scrumban. As previously stated, scrumban starts with the scrum framework, and weaves elements of kanban and lean into it.

• Make Work Visual

  Maybe your scrum team is using a scrum board, but if not, then certainly create a kanban board that includes a column for each step in the product’s workflow.

  

• Assign WIP Limits

  Once each step in the workflow is identified, the next task is assigning WIP limits to each column. This includes the product backlog; no more saying “yes” to every single stakeholder request. Once any column reaches its maximum, something needs to progress into the next stage before anything else is added.

• Eliminate Work that Doesn’t Add Value

  Scrumban incorporates the lean principle of eliminating tasks that don’t add value to the final product. This includes story point estimation sessions. Although estimating the complexity of product backlog items is integral to scrum, in scrumban it’s determined to be “excess fat” that must be trimmed from the work process. So no more planning poker for the scrum team!

• Establish a Pull System

  And finally, when implementing scrumban into your scrum team, create a workflow that’s “pull” rather than “push.”

  Much of the scrum framework actually is push, so this means a lot needs to be switched around. For example, the sprint planning pushes work into the workflow, and adding names to user stories also pushes these tasks onto certain individuals.

  One way to reverse the push system is to no longer assign tasks to individual members. Rather, prioritize work in the backlog, and whoever is available chooses the most pressing item. Another way is to eliminate routine sprint planning sessions and instead have a WIP limit in the sprint backlog. This triggers a team to plan a sprint when the backlog goes below this WIP amount.

  These are a few key changes to make when implementing scrumban into your scrum team. Much of the scrum framework remains intact, including sprint reviews, daily standups and retrospectives. This adjusted system allows for more development time because it eliminates story estimating sessions and routine sprint planning.