Scrumban is for Scrum teams that need to respond to change more quickly but wish to stick with the fundamentals of the Scrum framework rather than ditching it entirely for Kanban (which is great for service related tasks) or another model. Scrumban is a hybrid model, combining elements of both Scrum and Kanban to build a model that is fit for purpose. Scrumban is therefore an evolution of Scrum rather than throwing out the bathwater with the bathtub scenario. Constantly changing priorities is often cited as the key reason why Scrum users switch to Scrumban. This typically occurs when switching to a period of intense change such as bug fixing and support for example. Key problems that arise include not being able to predict the amount of support necessary or predict the size of the support tasks coming in, thus making it very difficult to fix in place sprints.
What’s the problem with Scrum?
Although Scrum is referred to as a lightweight Agile framework, it is the earliest version of what Agile should be, i.e. not that Agile at all but rather prescriptive and well defined, so much so that it might be called beauracatic and inflexible (inflexible agile anyone?). This is not perhaps all that surprising when you consider that when Scrum when first released was done so as a Project Management Framework and only later considered an Agile Framework. Being Agile is all about being adaptable to change, however being the least Agile of Agile Frameworks in the room makes Scrum the Agile training wheels on a bike, a framework for agile learners. So therefore Scumban is an upgrade for the more experienced Scrum Teams, those that can work without the rigid structure and deadlines of Scrum and still be productive. This is also why Scrumban is considered better for distributed teams, the name alone implies less oversight and more independent working. Most ALM software solutions now include the digital Kanban Board as a key feature, so if you are using Scrum Methodology and the Kanban board of ALM software one could argue you are already using a Scrum hybrid model.
Why not switch straight from Scrum to Kanban?
The critics of Kanban are the polar opposites to those levelled at Scrum, principally that it lacks structure, and this is precisely why Agilists prefer it. However, those who are used to Scrum, accustomed to the meetings and constant deadlines, the concept of Kanban is a step too far outside of their comfort zone. There are also very good reasons for keeping the Scrum Framework, since for the majority of projects Scrum is the most consistently productive framework available. So it makes sense to only use Kanban in certain situations such as production support.
By combining the strengths of both models, Scrumban provides a middle way between Scrum and Kanban, with all the strengths and none of the weaknesses of Scrum and Kanban individually. Since Scrum is the most popular of Agile frameworks, Scrumban provides an important transitionary point for the masses, from less Agile to more Agile as well as less experienced to more experienced.
Is your Development team ready for Scrumban?