In 2008, Corey Ladas wrote an essay on Scrumban. For Corey, this concept described how a Scrum team:
- Might introduce Lean practices and its tool, Kanban.
- Can use Kanban to augment Scrum.
- Can start a journey toward pull or prioritisation on demand.
- Could evolve using Lean, which if taken far enough, could replace some or all of Scrum’s practices.
Ladas even suggests that:
- Scrum practices, such as the Daily Scrum and burn-down charts could become irrelevant when pull practices are used properly.
- Estimation is a form of waste and could largely be eliminated.
Where is Scrumban today?
There is no single definition of Scrumban because (like the ‘Spotify model’) it’s not an official framework. For many teams over the 13 years since the paper was written, Scrumban is often implemented as Scrum without the Sprint timebox. All other events, values, and roles are utilised but the teams use a Kanban Board and don’t use the Sprint Timebox.
Mostly, however, Scrumban is used when people want to “pick and choose” what they want and how they want it. Largely, it results in Scrumbut.
What is Scrumbut?
Scrumbut is when a teams can’t take full advantage of Scrum to solve their problems and realise the full benefits of agile product development with Scrum.
Every Scrum role, event, and timebox is designed to provide transparency that enables action to improve, adapt or address delivery, risk and engagement problems. Scrumbut typically results when Scrum has exposed a dysfunction, but the team feels:
- The problem it is too hard to fix.
- The team has a preference for existing ways of working and doesn’t want to change.
Choosing Scrumbut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.
When Scrumbut is in place, many of the outcomes of hyperproductivity, faster ability to pivot to change, radical transparency, improved throughput, are not able to be realised.
What actually is Kanban?
Kanban is a tool that was popularised by Toyota as part of the Toyota Production System, but the underlying ideas predate that by years. It’s designed to support just-in-time manufacturing by being a visual indicator of stock, ensuring producers have a signal when new stock is needed so they can produce it. It helps to enable a continuous flow.
The Kanban Method that was popularised by David J. Anderson. This is a set of principles and practices, not unlike Scrum, that describe an approach for implementing a lean product development process. There are a few books written by Anderson that detail his philosophy and approach.
Then, there’s Scrum with Kanban. Defined by Scrum.org in collaboration with Daniel Vacanti and Yuval Yeret, their paper and training coursework leverages:
- Vacanti’s work developing the Kanban Method for knowledge work and managing the world’s first project implementation of Kanban in 2007.
- Yeret’s Kanban work in several enterprise product developments in Israel and worldwide as well as his book the “Holy Land Kanban”.
It’s noteworthy that Yeret is a recipient of the Lean Kanban community Brickell Key Award.
Scrum.org’s Kanban Guide for Scrum Teams by Vacanti and Yeret is available to download from the Scrum.org website.
Why Scrum with Kanban?
The flow-based perspective of Kanban can enhance and complement the Scrum framework and its implementation. Teams can add complementary Kanban practices whether they are just starting to use Scrum or have been using it all along.
The Kanban Guide for Scrum Teams is the result of a collaboration between members of the Scrum.org community and leaders of the Kanban community. Together, they stand behind The Kanban Guide for Scrum Teams. It is their shared belief that professional product development practitioners can benefit from the application of Kanban together with Scrum.
Scrumban originally was conceived as an essay written by an agile practitioner in 2008. Today, the concept has evolved but still lacks a consistent definition in the agile community. The closest we get to an understanding of Scrumban Lada’s work is his book published in 2011 based on those original essays from 2008.
When the symbols of agile are the easiest to adopt, and the rigours demanded by Scrum are hard, teams often turn to Kanban but then only adopt visual management. Scrumbut and cargo cult agile is the result.
If you want to improve flow and introduce Lean concepts to your teams, Scrum with Kanban is the answer.