Scrumban is an Agile management methodology describing hybrids of Scrum and Kanban and was originally designed as a way to transition from Scrum to Kanban.
Before going into definitions of Scrum, then Kanban, and ultimately Scrumban itself, first we should consider the Agile movement behind them.
Want to learn about Scrum: Scrum study guide.
Agile is not a methodology; it is a philosophy. Although ideas coming from Agile project management are being used in more and more industries, its origin is the software industry. As mentioned earlier, APM is not specific to this industry though. However, it is important to understand the context and origin behind the Agile approach.
Because it is not a methodology, you cannot learn ?Agile? and apply it to your daily job. Agile is a philosophy described in a very short Agile Manifesto. In it, the group believes self-organizing teams are the best solution to achieve agility. It also believes in technical excellence and continuous improvements for the team, learning and improving its own processes.
Agility also means the ability to sustain a constant pace of production indefinitely. And of course, almost above all, Agile is about satisfying customers, including welcoming changing requirements even late in the process -in order to satisfy and give customers a competitive advantage.
This philosophy is in sharp contrast to how projects were managed before. In the past, a deep hierarchy would organize projects, with several levels of managers. You would study requirements, possibly for months or years. Once started, projects would have little flexibility in scope or delivery time.
A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Scrum is:
Lightweight
Simple to understand
Difficult to master
Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum?s success and usage.
The rules of Scrum bind together the roles, events, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout the body of this document.
Kanban is a visual production management system. It helps deliver orders on a continuous basis with the most efficient use of resources (time, people, money). It uses typically simple white boards and paper cards or post-it notes. Nowadays it is possible to use Kanban on virtual boards, with software on PCs and tablets.
Origin
Kanban (signboard or billboard in Japanese) is a scheduling system for lean production and just-in-time production [JIT]. Taiichi Ohno, an industrial engineer at Toyota, developed kanban to improve manufacturing efficiency.
This system, among others, helped Toyota become the largest auto manufacturer in the world.
In the early 2000s, after the start of the Agile movement, some started to use the Kanban methodology for knowledge workers. Specifically, a variation of Kanban started to rise with the use of Scrum.
Goals
Kanban?s goal is to enable a continuous flow of work, while Scrum focuses on predefined fixed length sprints (e.g. 2 weeks).
Kanban is a continuous delivery system; it delivers outputs any day, as they become ready. Scrum, instead delivers only at the end of each sprint.
Kanban has no required roles within the team; everyone is equally responsible. Scrum has product owners, scrum masters, and comes with many ceremonies and meetings.
With Kanban, change can happen at any time. In Scrum nothing should change once a sprint starts.
In summary, these are the reasons why it is more appropriate and effective to use Kanban for projects in marketing, professional services and other knowledge work beside IT.
Scrum is really a software engineering management methodology. When it comes to Agile and its principles, the vast majority of followers use Scrum. Unfortunately, because of Scrum?s prevalence in IT, most modern businesses will try to implement it, even outside the IT industry.
This is unfortunate because Scrum is far from perfect and very difficult to implement successfully ?in IT or any other industry. The authors themselves acknowledge how difficult it is to master Scrum. You could find dozens of horror stories with failed implementations and disasters for companies and startups using Scrum.
From these challenges rose Scrumban.
Scrumban is really an hybrid of Scrum and Kanban. As mentioned earlier, Scrumban is sometimes a way to move a Scrum team to Kanban only.
This is why a good way to understand Scrumban is to look at it as Kanban with a few Scrum processes added.
In Scrumban there are no sprint. I repeat. No sprint.
Instead, the goal is to maintain a continuous flow of work within the organization. This continuous flow focuses on creating value for customers.
There is a backlog, like in Scrum. Since there is no prescribed role, it means each organization is free to decide how to manage this backlog. Product managers, the entire team, or even project managers may control what makes it into the backlog.
It is even possible to have multiple projects in parallel under Scrumban, for the same team. And the team might be very small or very large, unlike Scrum.
How do you decide when to move from backlog to production?
Since there is no sprint, the trigger is very different. When the level of "to-do items" in the Kanban drops below a pre-agreed level, this triggers a planning meeting.
This is one of the rare meetings in Scrumban. Some organizations might even bypass this, simply picking what is next in the backlog, and adding tasks to the "to-do" until it reaches its pre-agreed maximum capacity.
If a planning meeting is used, it is a great opportunity to review all priorities, for all projects. This way, what is pulled into the production Kanban is the best decision.
There is a chance for the team to make sure they prioritize tasks with the big picture in mind, which would not happen by itself when using Kanban alone.
The WIP limit is also very important, as they are in plain Kanban. By limiting work, you focus the team. This increases efficiency by reducing task switching, potential bottlenecks and tasks interdependence.
Within Scrumban, the team can visualize its entire workflow thanks to Kanban boards. The focus is on the cycle time, moving tasks within the workflow. Even though there is a concept of iteration in Scrumban, the idea is to get away from sprints entirely. You only use iteration planning to decide what tasks are ready to work on, regardless of a specific named sprint with a fixed duration. The methodology expects continuous work, and continuous delivery of products.
Scrumban is really a great combination. It transforms Kanban into a real project management methodology, which it is not otherwise. This research shows the impact of Scrumban on distributed teams as an example.
With a focus on flow and a lot less ceremony than Scrum, fewer artifacts and meetings, Scrumban is a lot more time efficient. For many industries, it is very worthwhile to consider Scrumban instead of Scrum. It is a lot easier to implement thanks to its visual interface.
Another alternative is Kinalta?s Agile Scrumban Management framework. It is a small variation on Scrumban. It uses multiple Kanban boards to manage projects and workflow, with a simple set of rules.
Kinalta is a Scrumban for Lean Project Management
Use Kinalta to follow up and monitor multiple fast paced projects.