Since Scrum is a way to organize people in an agile way, and Kanban is a way to monitor work in an agile way, together they create a truly robust framework for getting work done. This merger of frameworks has been dubbed Scrumban. I take somewhat of a contrarian view when it comes to Scrumban because I have seen it used as an excuse to abolish the very rules of Scrum that drive excellence and predictability, when it is pitches as an additive way of increasing transparency. In this article we are going to look at the ideal concept of Scrumban and address some of the antipatterns that makes it susceptible to inefficiency.
What is Scrumban actually
To understand Scrumban you first need to understand its parent frameworks which you can read about here:
The first thing I want to point out is that Scrumban should be thought about as a more robust version of Scrum, not a more robust version of Kanban. The reason is because Scrum actually already includes basic Kanban principles such as the use of a basic Kanban board for visualizing work. Kanban however does not adhere to Scrum practices and lends itself to processes that seek constant flow vs fixed intervals planning. By thinking of Scrumban as Scrum you start of understanding that implementing the ceremonies and roles of Scrum are crucial in a successful Scrumban team. At a high level these Scrum specific ceremonies are:
- Sprint Planning
- Sprint Review
- Sprint Retrospective
The Scrum Roles are
- Product Owner
- Scrum Master
- Development/Implementation Team
A true Scrumban team will have these roles and plan out sprints just as a normal Scrum team would. The Product Owner will still develop stories that the team rates with story points, and at the end of each sprint the team will still be expected to produce a potentially shippable product. A Scrumban team is differentiated from a Scrum team in the way they track work during each sprint. Scrum teaches teams to have a Kanban board with columns for todo, doing, and done to track the status of each ticket. A Scrumban team will often have a more detailed board to both track and enforce consistent flow across the multiple steps of implementation that each story must go through during a sprint.
An example of this in a software development team may be a board with the following columns.
- Review
- Research
- Present Approach
- Develop
- Write tests
- QA
- Document
- Deploy
A good Scrumban team may even divide each column in half with a dotted line to differentiate the items in progress at each step from those already completed, waiting to be pulled into the next step.
One of the biggest advantages to a well run Scrumban team is the implementation of WIP limits on some or all columns during a sprint. WIP stands for Work In Process and describes how many stories or tasks are allowed in a specific column at a given time. This is a powerful forcing function that creates flow and builds teamwork. In Scrum, teams often develop the habit of dividing up the work amongst each team member during sprint planning and everyone is responsible for their own work. This is functional for sure, but not ideal. The concept of a team is that everyone, rather than an individual, is responsible for moving the work through the process. In Scrum as long as everyone is getting there work done there is no consequence for spitting up work and avoiding collaboration. By setting WIP limits on a step you are forcing people to stop working on their own tasks to go help clear out work in another column before they are allowed to move their tasks forward.
Here is an example. Say you have a Kanban board with the above listed columns and there is a WIP limit of 3 on the Develop step. If you have a cross functional team like Scrum teaches, and three stories are in active development, the other team members will be forced to jump in and help if all other stories are currently waiting in the Present Approach phase. The question is, where should they jump in and help? This is the power of WIP limits. It’s left up to the team to figure out how to fix this bottleneck. If the next step of Writing Tests also has a WIP limit of 3 and is currently full, then to clear up the Development WIP you need extra effort in Writing Tests. Let’s say instead, that Develop already has the three best people working on the three stories and there is not a bottleneck in the Write Tests stage, then maybe it would be the most help for the others on the team to spend more time on Research or on the Present Approach stage to better prepare the next stories to go through Development even faster.
The point is that with WIP limits you force the team to get creative and work as a team, rather than allowing them to fall into the habit of letting team members or developers retreat to their desk for a sprint and reemerging at the end with a completed story. If your sprint burndown chart resembles a downfacing hockey stick where it looks like little to nothing was done during the first 90% of the sprint, then Scrumban may be a viable option for you to try.
Scrumban Antipattern
Eliminate Sprint Commitments
One of the most common antipattern I have seen teams fall into when claiming to do Scrumban is using Kanban’s philosophy of consistent flow to eliminate the need for Sprint Commitments. Pure Kanban is great for situations like a service desk where tickets come in consistently and need to be moved through a process to be resolved, it is not the best for project based teams that are working toward an end goal. The reason is summed up in Parkinson’s Law:
“Work expands so as to fill the time available for its completion”
When you have a project without a deadline and without interactive commitments, it will take significantly longer to be completed. This is the beauty of Scrum, by having the team define their own commitments each sprint, the company leverages both the Planning Fallacy and the Consistency Principle which forces the team to focus on the most valuable portion of work as defined by the Pareto Principle, making judgment calls to leave out work that does not justify its own effort. Let me explain that further.
The Planning Fallacy according to Wikipedia:
“Is a phenomenon in which predictions about how much time will be needed to complete a future task display an optimism bias and underestimate the time needed”
The Consistency Principle according to Wikipedia:
“The consistency principle states that people are motivated toward cognitive consistency and will change their attitudes, beliefs, perceptions and actions to achieve it.”
The Pareto Principle (also known as the 80/20 rule) according to Wikipedia:
“For many events, roughly 80% of the effects come from 20% of the causes.”
Put all of these proven ideas together and you get the magic of Scrum. By defining set iterations you are addressing Parkinson’s Law, by asking the team to make the commitment you are invoking the Planning Fallacy, by asking the team to meet their commitment you are leveraging the Consistency Principle, and because of the time crunch, commitment, and desire to be consistent the team is forced to focus on work as defined by the Pareto Principle.
If you remove sprint commitments from Scrumban, you are in effect removing the main forcing function that makes Scrum work. If this is the case, you are effectively using Kanban, and if your team is working on a long lived project, you can expect it to take longer and cost more than anticipated.
Forget about potentially shippable products
Closely related to the first antipattern is the goal of producing a potentially shippable product after each sprint in Scrum. When a team moves away from this they are again negating one of the most powerful forcing functions available in the framework. By requiring that something be potentially shippable, the team must finish cleaning up their work and tying up loose ends before the sprint is completed.
This antipattern is the idea of adopting Kanban’s continuous flow as an excuse not to wrap up one sprints work completely before moving into the next sprint. This allows for laziness with the promise of looping back around later to clean up or fix things and it leads to elongated lead times and sloppy cleanup efforts held off till the end where they are often cut short by new priorities. Can someone say Tech debt?
Devalue Sprint Ceremonies
There is a tendency even in Scrum to rush through standups, reviews and retro’s. Especially when you are working with a bunch of introverts that don’t like to speak up in a group setting. An antipattern of Scrumban is the tendency of eliminating ceremonies with the excuse that Kanban does not have them in its framework. I again go back to the fact that Scrumban is an additive approach where the practices are added together rather than a subtractive approach where the practices of one replacing the practices of the other.
Sprint ceremonies are the main collaboration mechanism of a team and are a minimum required interaction point that is crucial for the Scrum Master to be able to do their job. Scrumban should increase the level of collaboration rather than decreasing it and thus the ceremonies must remain part of the normal sprint cadence.
Leveraging the additional transparency for control
The other antipatterns I have described are focused on eliminating key advantages of Scrum when a team adopts Scrumban. This one however is an antipattern seen in organizations or groups where management is trying to revert to the more familiar command and control style of management. In these cases the manager or sometimes even the Product Owner will use the Kanban board as a miniature Waterfall Project plan, defining when each story should be moving through each phase and holding the team accountable to the flow of work rather than the delivery of the sprint commitment.
The more detailed Kanban board is meant to facilitate team collaboration. Anyone outside of the team, including the Product Owner, Managers, and other Stakeholders should not speak into, or read into the state of work on the Kanban board. They must trust the team and allow them to operate with anonymity trusting them to deliver what they promised regardless of the state of work at any given point during the sprint. This of course changes if the team begins to miss sprint commitments, in these cases the Scrum Master should be paired with a more senior counterpart to help diagnose the issue and craft a remediation strategy.
Summary
Scrumban is an awesome way of leveraging the strengths of two separate frameworks that are both built to support the 12 principles of Agile. You must be vigilant though that this is used as a way to increase collaboration rather than an excuse to have less structure. The litmus test for this, is whether your implementation of Scrumban has increased structure, collaboration, and speed of results, or decreased them. Increasing speed of results by itself should be enough, but without structure you will find the results hard to replicate, and without improved collaboration you will find that the added complexity of using two frameworks together may not make sense.
Leave A Comment