Team members dissatisfied with Scrum sometimes say that they will “just switch to Scrumban“, because in Scrumban, you don’t need to plan.
This is a common belief. Scrumban will somehow keep all the benefits of Scrum, but it will save us from the tedium of estimating the size of user stories and planning Sprints.
The next question to the concordant is, of course, what Scrumban is. There are as many answers to this question as there are interlocutors.
This does not in any way mean that the interlocutors are wrong. There are many sources that confidently describe Scrumban and its “principles”. They often contradict each other, add their own Lean interpretations, inject their own ideas, and generally try to be as serious as possible. It seems that everyone (and their aunt) has their own Scrumban.
After wondering how we got into this situation, I stepped back from the problem and asked myself four fundamental questions about the legitimacy of Scrumban as an agile/lean framework:
- Is there a single definition of Scrumban?
- Is there a Scrumban stewardship organisation?
- Is there Scrumban reference material?
- Are there any widely recognised Scrumban certifications?
Let’s find the answers. At the end of this article, I will also briefly summarise the ideas that really make up the Scrumban approach. They are not many, but they are interesting.
1.) SCRUMBAN DEFINITION
There is no official Scrumban definition. The closest we can come to it, is the author of the term himself, Corey Ladas, in his original (2008) book with the abbreviated title Scrumban.
In the book, Corey states that Scrumban system COULD (he really says could!) be A Kanban pull system within an iterative timebox. Interestingly, the term Scrumban is used only four times in this book (not counting the titles).
Another interesting thing is, that somewhere in the middle of the book, author abandons timeboxing in favour of continuous flow.
2.) A STEWARDSHIP ORGANISATION
There is no such thing as a stewardship organisation to ensure the unity of the Scrumban approach, to update it in line with new trends and to serve as a reference for practitioners.
Corey Ladas himself says that Scrumban is based on “themoral foundations of free inquiry“.
FRom this, I conclude that there will never be a similar organisation.
3.) REFERENCE MATERIAL
The basis from which the Scrumban trend emerged is the aforementioned book with the full title Scrumban – Essays on Kanban Systems for Lean Software Development: And Other Essays on Kanban Systems for Lean Software Development, published in 2008 by Corey Ladas.
The book is a collection of essays, i.e. Ladas’ reflections on Lean practices in the context of software development.
Interestingly, the book was published two years before David J. Anderson published his landmark book Kanban, which laid the formal foundations for the Lean approach in software development, established the term Kanban system and positioned it as a competitor to Scrum.
Apart from this book, there is no other reference literature for Scrumban. Some authors and organisations have tried to monetise this trend, but the results are rather disappointing due to the lack of a Scrumban framework.
In addition to the original Scrumban book, the more publicised are:
- The Scrumban [R]evolutionwhich brings nothing new to the world of Agile and Lean. The book is a long-winded (380 pages) rehash of Kanban ideas and is accordingly poorly received by readers. In my list of literature it is ranked just below the 1988 Slovenian telephone directory.
- Scrumban A Complete Guide – 2021 Edition It costs EUR 103 and is so bad that Amazon reviews are turned off for all editions. It mostly asks questions (including a self-assessment test) which you are supposed to answer and which are supposed to gradually lead you to the seventh Scrumban maturity level. Of course, the authors have neatly made up these levels.
It can be summarised that Scrumban does not have a reference literature in terms of PMBOK (Project Management Body Of Knowledge), Scrum Guide or SAFe 5.0 Distilled.
As a result, even popular tools such as Jira or monday.com do not offer Scrumban templates. A Kanban interface is sufficient.
4.) CERTIFICATION
There is no official certification body for Scrumban. However, some organisations are trying to dip their fingers into that jam jar too.
One of the more advertised organisations offering Scrumban certifications is IBQMI. Despite the WEB page, which tries to be very convincing (or maybe that’s why), I had my doubts about the organisation. Google Earth reveals that all three of their locations are more or less generic in nature. At best, mailboxes. A search of the Wyoming Secretary of State database reveals that the company is registered in the USA through Mass Registrar. Personally, I have my doubts. Maybe out of curiosity I’ll decide to take their “Certified Scrumban Practitioner” certification. Just to form an opinion – which I will, of course, write something about it.
WHAT IS THE SCRUMBAN APPROACH?
Let’s do a summary of the book that started it all (Corey Ladas: Scrumban).
Imagine an ideal flow of functionality through a Kanban system. A use case is a unit of functionality that delivers some business value to the end user.
The CFD in an ideal flow process would look like this:
Remember that we are talking about an ideal flow, where “use cases” are created with the same frequency as the capacity of the development team to take them into development. Since there are no queues, the time from initiation to production (lead time) is the same as the time of actual development of the functionality.
It is advisable to break down larger functionalities into smaller ones until they become independent and still have some business value (work item). I will call them cards, because that is how they are presented on the kanban board. In this way we reduce the variation in the size of the use cases we take into development.
In such an ideal system, the Kanban Done buffers are zero. As soon as a particular development phase finishes working on a card, the next phase pulls it to itself (because it has just gained free capacity by passing its card to the next phase). This happens without waiting in the buffer column only if the work items are approximately the same size, which is of course practically impossible to achieve. This Lean ideal is called one-piece-flow. In it, all cards move to the next development phase at the same time.
The figure shows this process for one “flow”.
One-piece-flow can also be imagined this way:
Through a series of mental iterations, the book leads us to some final ideas, which I can summarise in a few points:
- WIP limits for development phases in a process should be kept as low as possible and cover both the “In progress” and “Done” sub-columns of each phase – one number for both columns.
- Variations in the size of the cards in the process and the consequent waiting for the previous phase to complete its work on the card are compensated for by multidisciplinary experts (architect/programmer or programmer/tester) who, instead of waiting for the previous phase to complete its work on the card, actively assist in its realisation (swarming).
- Classes of service (swimlanes) should have their own WIP limits that are enforced at the same time as the vertical WIP limits.
- Bottlenecks revealed in this way are to be actively addressed.
- There are no Scrum elements in the Scrumban ideal of one-piece-flow.
This is Scrumban. A collection of essays that add a deeper understanding of good Lean practices. Essays themselves don’t bring anything to the table that the more recent Kanban literature doesn’t.
The book is an interesting read in the sense of “Lean brain exercise”. The examples are explained in a simple and understandable way and encourage us to reflect on current practices.
If you are pressed for time, the book is positioned below Kanban by David J. Anderson.
A few examples of the Lean process approach presented in the Scrumban book are also presented in the Agile & Lean for Developers course.
