SCRUM BASICS
Scrum vs Kanban
Scrum and Kanban. Friends, Enemies, or maybe Frenemies?
Let’s start with what Scrum and Kanban are. What similarities they have and how they differ. Which one is better in which context? And lastly, how to do Scrumban?
From my experience, there is a lot of confusion amongst the teams especially when it comes to Kanban.
Kanban Method, as described in Essential Kanban Condensed, is typically confused with the Kanban board.
The Japanese word Kanban means a “sign” or a “large visual board” that we use to visualize our work. This way you can have a Kanban even in Scrum. And it is just a part of the Kanban Method that’s far more complex and based on Lean methods.
Just to make it clear Kanban method is not just a board, it’s not a Scrum without sprints. Kanban is like chess — it has a set of rules that are easy to learn, but the game is difficult to master.
What Kanban and Scrum have in common?
Well, of course, the Agile State of Mind. To put it simply, Scrum and Kanban are both a set of principles that help us organize our work. The goal of both is to deliver more value for the business faster and at a stable pace.
They share Agile values and they are lightweight frameworks that will help you build better products and provide better service. To be a framework means to provide some minimum game rules, just like in sports.
In sports, all the players follow the same sport rules. Yet every game, every match is different. Each team is unique and has different dynamics.
In Scrum and Kanban, it’s very similar. Although the teams follow the same values and principles. Every Sprint or delivery cycle is different from the previous one. Each team is unique and finds its way of collaboration within the framework.
What’s the difference between Scrum and Kanban?
The most obvious difference when switching from one framework to another is that in Scrum we run a Sprint and in Kanban, we go with the flow.
Sprints vs Flow
What I mean is that in Scrum we have timeboxed iterations called Sprints that can last up to one month. One Sprint ends and the next one starts immediately afterward. Their duration is consistent.
In Kanban Method, we don’t divide the work into periods, we have a continuous delivery flow system and limit the work in progress, to achieve higher speed and better focus.
The goal of both is to deliver more value for the business in the quickest way possible
To achieve that, Scrum teams focus on defining a piece of functionality and make a plan to deliver it in a Sprint. There shouldn’t be much variability to the work planned within a Sprint so the teams can work undistracted.
The focus of Kanban is to maximize the efficiency of the flow of work through the system which means finding an optimal way of getting things done, while the priorities can change to some extend.
Perscriptiveness vs adaptiveness
Scrum is more prescriptive, defines the Scrum Team roles: the Product Owner, the Scrum Master, and the Development Team. If possible, the Development Team should consist of three to nine people to optimize the complexity and productivity. Moreover, Scrum defines the meetings that are called “Scrum Events” like Daily Scrum or Retrospective, and the items called “Scrum Artifacts” like the Product Backlog.
Kanban is about an evolutionary change, it doesn’t require you to change anything from day one. Unlike Scrum, it doesn’t require any role changes, nor prescribes team sizes. You can easily be a one proud Kanban-team-member. It’s also more flexible about the meetings.
Scrum provides a more defined process
Specifies the timeboxed iterations. Defines roles of the Scrum Team and provides checkpoints in the form of Scrum events to facilitate learning loops to quickly gather feedback, both from customers about the product and from the team about their collaboration and processes.
But, as great as I think Scrum is, I don’t think it suits every team in every situation. I used to work in a company in which the IT department decided to work partly in Scrum and partly in Kanban (read more about Scrumban below). When I had a problem with the administration of JIRA, I created a ticket for them. The response said: “We got your request, we might be able to start working on it in our next sprint in 1.5 weeks!” Results that the JIRA inquiries were managed within Scrum and so-called helpdesk ones in Kanban. To me, it just felt like poor Client Service. So how would I solve this? I would put all client requests in Kanban mode and only some interior projects in Scrum.
Who should choose Scrum?
I think it’s good to experiment with both but if I were to speak from my experience with the teams, I’d say that Scrum is great for any team that can work on incremental delivery of something: a product, a service, software, hardware, etc. Especially for teams that have little knowledge of Agile, because Scrum would guide them in their first steps of understanding what an incremental delivery is and how to learn from their own experience.
Kanban gives more freedom at the start
It emphasizes the visualization of any policies the team follows and makes them explicit, like work in progress limit which helps the team focus and enhances cross-functionality. It provides more metrics to optimize the system but they require advanced use of the method.
Who should choose Kanban?
I would just advice to start experimenting with Kanban in the first place in the three following cases:
- Kanban is for Changing priorities. It might result in a better option for any type of work that gets a constant influx of petitions: eg. IT support, client service, etc. Unlike the Scrum team, the Kanban team can be more flexible to respond to emergencies or changing priorities without needing to renegotiate commitments in a Sprint.
- Kanban is for Companies where change is very painful. Kanban philosophy says: “start with what you do now and use continuous improvement to achieve evolutionary change.” It doesn’t require any changes to roles or meetings when first getting started, which makes it easier to adopt by an organization. One of its values is “respect” as all the practices a company has, exist there for some reason and we respect that, so we will be trying to improve them step by step but not change them all from day one. Any change will come in an evolutionary way.
- On the team level, Kanban is for mature teams. For product teams, I would recommend getting good and predictable in Scrum before moving to Kanban. Kanban lets you go with the flow but to get good at it you need to constantly optimize it. Kanban method is far more sophisticated than a simple tool for visualization, it is built for speed but requires a lot of proactivity and commitment to learning from the team. If you’ve ever tried to implement the work in progress (WIP) limits and respect them, you know what I mean!
Open your mind to Agile and experiment with both.
Maybe in the environment of “Company A” Scrum will work fabulously but in “Company B” Kanban will be a way to go. Maybe even within one company some parts or departments would work in Kanban, see Lean Portfolio Management and the software development teams would perform best in Scrum.
And last but not least, what is Scrumban?
Corey Ladas wrote a paper called “ScrumBan” you might want to read it. Yet to me, Scrumban is a mix of both: you can add elements of Kanban to Scrum and vice versa. Ultimately it’s all about helping the teams on their way to high performance.
What I like to do is to use the prescriptive nature of Scrum and the flow improvement of Kanban to help the teams progress through their Sprints.
I love Kanban’s way of thinking to stop starting and start finishing. That’s truly an Agile state of mind. It can help teams that are doing Scrum to get better at accomplishing their Sprint forecast. You can introduce a better visualization of the issues on the board and then start introducing WIP limits or at least to be mindful of the number of issues in each state of the process. It fosters team collaboration and helps bring issues to the surface.
In the same way, it might help some Kanban teams to get a role of a Product Owner from Scrum, so the backlog gets reviewed and organized, and you might want to introduce a cadence of 2 weeks to have a retro and analyze your metrics.
Agile is all about experimentation. Scrum and Kanban aren’t competitors, they aren’t enemies or frenemies. They can be experiments every team should run to find their best fit.
