The question that keeps popping up in your mind is whether you should choose Kanban or Scrum. Should you choose Scrum, the well established manager - friendly way of doing things or Kanban, the new kid on the block?
Let’s say you’ve decided to use an agile development methodology to build your product. So, you’ve set up your board, organized a meeting with your team and are now ready to discuss with them how to work for your next project. After a quick Google search, the question that keeps popping up in your mind is whether you should choose Kanban or Scrum. Should you choose Scrum, the well-established manager-friendly way of doing things or Kanban, the new kid on the block? What are their similarities and differences? And, most importantly, what is best for your project?
Both Scrum and Kanban are agile methodologies that, given the proper ground, can work miracles. If, however, they are practiced the wrong way, then your project may easily fall to pieces. Although agile development means that you can be super-flexible when designing and developing your project, that doesn’t mean you can bend all rules of software project management. With that in mind, let’s first focus on the similarities of the two methods.
Both Scrum and Kanban operate on what we call a project board. A board includes columns that indicate the different states of the task. Although there are several different column configurations, most of them span from the simple 3-column model, where you add new tasks in a ‘to do’ column, move them to ‘in progress’ when working on them, and finally move them to ‘done’ when completed. Of course you could add further steps in the process (e.g. using a column for designing tasks before adding them to the ‘to do’ column), however the main principles are the same. The goal is to move tasks throughout your board by implementing the indicated features.
The differences between Kanban and Scrum are easy to spot if we consider the goal of each methodology. The goal of Kanban can be summed up to three points: (a) visualizing your workflow (using a Kanban board), (b) limiting the amount of Work in Progress (WiP), and (c) measuring the Cycle/Lead time required for the tasks to move from idea to completion (you can read more about Kanban in our previous post. Note that Kanban itself does not set any restriction on the release time of individual features; as long as the aforementioned metrics are kept intact, the product can be in continuous delivery mode.
Scrum, on the other hand, splits the work into time intervals called sprints. Each sprint includes a set of features that have to be implemented and integrated into the next version of the product within a specified interval (e.g. 2 weeks). The main purpose of this methodology is to keep communication channels open with the stakeholders and, at the same time, give sufficient time to the team in order to design and prioritize the tasks of the next sprint. The methodology itself is stricter, as new tasks are not allowed after a sprint has started; all task estimations and prioritization must be defined beforehand by the product owner.
Possibly the most important difference between the two models is not what each of them offers but what are their limiting factors. In that aspect, Scrum limits the amount of work performed in each sprint, whereas Kanban limits the number of concurrent tasks at any time (Work in Progress) to avoid producing overhead for the team.
Sadly, no single model can be said to outweigh the other in all cases. Scrum is usually preferable if you need to have a stricter process with specified roles (product owner, scrum master) and well-defined tasks. So, it’s usually a good choice for experienced teams who have a rather clear view of what they want to develop. Kanban, on the other hand, is super flexible and allows faster adaptation to stakeholder feedback. Due to its simplicity, it is usually preferred in maintenance scenarios or when the product has to ship really fast to the market.
The good news, however, is that you don’t need to stick to any of these models! Most practitioners nowadays use a combination of both, and some even go as far as to name it “Scrumban”. I know what you’re thinking… this seems wrong on too many levels. If, however, this combination is practiced correctly, it can lead to very effective outcomes. Imagine the visual benefits of Kanban combined with carefully planned Scrum sprints. With two limits in place (Work in Progress limit and Sprint Capacity limit), the members of your team are always safe from breakdowns. If, moreover, these limits are set correctly, there is usually some room to fit Just-in-time tasks.
As with most things, the key here is to find the golden mean, the solution that will make your team more productive without undermining the quality of your product. And, to do so, you need to work out what works for you and at the same time keep track of the relevant metrics.
If you are curious to find out more about this golden mean for developing your product and managing your team, make sure to subscribe to our newsletter.
If you want to test the two methodologies or to start today, consider checking out our product that offers a ready-to-use Kanban board with helpful automations and metrics that span from Scrum to Kanban.
Till next time folks!