There is some debating over there about which agile methodology is better and why. But really, who said that an agile team has to run either Scrum or Kanban exclusively? There are different situations, some of which would benefit from Scrum, while others could take advantage of Kanban.
Let’s have a closer look.
When Scrum is best
Scrum agile methodology works best when applied in the middle phase of a project life cycle.
The reason for that is that Scrum depends heavily on precise and predictable estimations. In order for a Scrum team to be able to estimate as efficiently as possible, the following criteria must be met:
- the project must be very familiar to the team
- requirements must be clear and realistic
- the team must have stable sprint velocity
- team members must know each other very well
Although not always true, but in most cases this criteria is met in the middle of a project.
Since predictability is the biggest advantage of a Scrum team, it totally makes sense to apply Scrum when it is possible to take maximum advantage of it — in the mid-time.
During this phase the sprints are quite predictable, team’s velocity is stable, team members are motivated, product owner is relaxed and stakeholders are happy.
Sounds like a Scrum heaven, so why would one ever want to change?
When to apply Kanban
Kanban methodology is better to be used in the beginning of a project, as well as when getting close to the deadline. Let me explain why.
Beginning of a project
The core concept of Kanban is to ensure the pipeline constraints. All results are roughly predicted, and even the project estimation is done using rough values such as T-Shirt sizes.
In the beginning of any project there is simply too much uncertainty. Project requirements are usually composed based on some idealistic vision, and are completely user oriented. Although a “customer voice” is actually a good thing when describing a feature or a bug within a certain context, the problem comes when there is no context yet. Therefore for Scrum team members it is difficult to estimate such tasks using story points. But not for Kanban teams who estimate using T-Shirt sizes.
Lack of certainty due to absence of experience with a new project makes it almost impossible for a team to commit to a certain backlog for a certain sprint.
Hence, Kanban comes to the rescue! With its continuous pipeline the “sprints” become less predictive, but the huge advantage here is that there is no commitment required to an uncertain backlog. The responsibility of projecting predictions is simply shifted to the product owner.
I would recommend to run Kanban during the first month of a project.
As a result, by the end of this “iteration” the team will have naturally clarified requirements, meaningful subtasks and properly broken-down stories.
End of a project
A proven way of approaching the end of a project is by switching the team to the Kanban mode. As opposed to the initial phase of the project, everything is pretty certain at this point in time. Most but not all.
During the project lifecycle and especially close to the deadline, the natural byproduct of a rapid development is created — bugs.
According to best agile practices, bugs should not be estimated due to their specific nature. Quite common way of handling bugs is to reserve some time-box during the sprint for fixing bugs. The problem happens when amount of bugs outweighs the available time-box, so the team is required to adjust it from 10% to 20% to 30% etc. This makes less sense with each adjustment.
Solution? You’re right, Kanban to the rescue again!
Performance-wise it is also better for the team members to switch to the more individual approach when selecting a next task to work on. It means that a common “pick from top” constraint should be removed from the Kanban backlog. The reason is simple — team members are more performant when working on tasks from the familiar domain or component or part of the application.
Use Kanban in the beginning of a project to quickly build momentum and iterate on the quality of requirements. Let team members learn each other and get experienced with the project or its particular domains or components. Running it for a month or so should be enough usually.
Switch to Scrum, start working with sprints and start doing proper estimations. Build predictability.
The closer you get to the end of a project (or to the deadline), consider switching to Kanban again. Think about benefits of streamlining bugs into the fast lane, spend less time on estimating and try to think more value-oriented.
Let’s burn those charts!
Also, if you’d like to receive new posts straight into your inbox — please, sign up for my mailing list.