Why we switched from Scrum to Kanban?
he IT industry has experienced an exponential growth in the last decade. In software development, there has been an increased demand for efficient, just in time (JIT) delivery.
Twenty years ago a software development process could take several months, even a year prior making the first delivery. Today this is beyond unacceptable.
Today, clients have a continuous change in priorities which affects the dynamics of the team and requires a frequent adaptation. The pressure for flexibility is immense.
But, how flexible can you be with a process so structured like software development?
The new agile approaches aim to address the challenges that have emerged in a such fast-paced environment. There are different methods that you can apply depending on the product you are working on and the team’s dynamics.
Our Sportsbook team has recently shifted from Scrum to Kanban development approach. Although, both are agile methodologies, there are slight differences that make the one more appropriate than the other for our team and the product they are working on.
The problem with the Scrum methodology
Scrum offers much higher efficiency than the traditional waterfall development process. With the Scrum approach, there is a continuous delivery with each sprint where the same lasts from of 2–4 weeks.
Then what is Scrum’s biggest flaw?
I can not say it is a flaw of the methodology, but sometimes even a scope of 2–4 weeks is a long period. For example, when you have a product that requires a continuous operational maintenance parallel with a high demand for innovation. This is the case of our Sportsbook product. — Dejan Dimitrovski, Sportsbook Product Owner
Namely, the strategy does not change so frequently and can be planned for the following couple of weeks or months. However, maintaining the product while innovating can produce an unexpected bug that emerges as a priority regardless of the strategy. You can not ignore it and wait for the next Sprint, especially if it is a critical bug.
For that reason you always plan ahead for an unexpected urgent issue that might interrupt the sprint. But, estimating the time you will need to resolve this issue is the biggest challenge.
Running out of time can seriously hurt the Scrum process. The retrospective session aims to tackle the reasons why such thing happened and how to avoid it for the following Sprint.
How does Kanban address these challenges?
In comparison, the Kanban approach offers more flexibility. With the Kanban approach , the planning is simplified using the Kanban Dashboard. The process is very straightforward: we have a list of issues in our Backlog (just like in the Scrum approach), but instead of scoping and planning a sprint for the following 2–4 weeks the question is:
What is my priority for the day?
The priorities get in the first column of the dashboard: The “To-Do” list 🙂 When the team arrives at the office takes one issue at a time and moves it in the “In progress” list. The longer an issue stays on the board triggers an urgency with the responsible team lead or the PM.
The priorities can change daily because today we are equipped with new knowledge from the work we have completed yesterday. — Dejan, Product Owner.
With the Kanban approach the planning happens contentiously which makes it even more agile. What is even more important, the change in priorities is very expected and the team develops a more flexible mind-set. In contrast, if a bug interrupts the Sprint in Scrum, the team feels agitated, while in Kanban, a fix is just another daily priority in the “To-Do” list.
The Golden Rule: Never overwhelm the board with a great number of tasks. Keep it realistic and feasible.
The benefits for the client
The Kanban methodology improves communication flows in software teams, enables iterative workflow, reduction of waste and what is most important focus on quality. The client will also experience the change and will benefit from:
- Continuous delivery
- Continuous improvement
- Frequent shipping
- Faster feedback
- Proactive addressing of issues
The main idea of Kanban is just in time delivery. But, this can sometimes be a two-edged sword.
With Kanban you have to be very careful with your development. Each release must be tested before delivery, you can not be fast at the expense of quality. For that reason we have automated our testing process to make sure that the acceptance criteria of the software are always met. So, even if a defect shows up after the delivery we know it will not be critical.
In conclusion, the Kanban methodology is not a silver bullet for everything. It has its risks. However, when working on complex software where maintenance and innovation are equally important Kanban is your friend 😉.
