Kanban and Scrum are two different ways of managing Agile projects. We often see the terms confused and it’s important to understand the differences, especially if you are hiring for or applying for a role in an Agile organization!
Kanban and Scrum don’t simply mean ‘Agile’. They are separate approaches. Scrum has a set of processes that emphasizes what work can be done in a particular period of time. There’s a focus on the schedule and how to break down the end result into smaller pieces that can be completed to deliver a cohesive whole over time, while making sure each release delivers something of value.
The process centers around sprints, where the work is completed. At the end of each sprint the team holds a retrospective to discuss what can be improved next time, and then more work is picked from the backlog and the developments start again.
Kanban: A Quick Refresher
Kanban is another Agile approach that’s distinct from Scrum. Again, the team always has half an eye on what could be done better so there’s the same culture of continuous improvement as Scrum. It also relies on breaking down the work just like Scrum, so teams only work on small pieces at a time.
However, there are some fundamental differences. The idea of timeboxing work doesn’t exist in Kanban. It’s iterative, but the team is expected to self-organize and keep the flow of work coming in a prioritized and productive way. You may not have a cross-skilled team because the Kanban approach can be used by many teams, including specialists.
Which Approach Is Right For You?
I wish there was an easy answer to that! Ultimately, either approach is a good way to deliver projects and teams around the world use both. Some teams have a preference to one or the other, some will flex between the two depending on the needs of the project and the people involved.
There are, however, a few considerations that will make it easier to come to the conclusion about which approach is best for your team.
Consider Scrum if:
The team struggles to break the work into smaller chunks. Ideally, tasks should be no longer than a week. Both Scrum and Kanban rely on teams being able to break their work down into smaller activities but it’s often easier to switch into that mindset in a Scrum environment. That’s because you’ve got the timeboxing that help you identify what didn’t get completed within the window. Retrospectives allow the team to focus on what they could do differently next time to hit the deadline (by breaking the work down even further).
It’s a large project where predictable outcomes matter. Scrum is suited to larger environments where productivity over time is important to track and maintain. The focus on velocity – how quickly work gets done – allows Scrum teams to track their outcomes and their productivity easily. Scrum also has more to say about planning releases so newly Agile teams might benefit from that additional focus on how to ship.
Consider Kanban if:
You need to be really responsive to your customer. Both approaches have a strong customer focus, but Kanban lends itself more easily to focusing on cycle time. If you can get more out the door faster, you’ll be seen as being responsive to your customer’s requirements. Additionally, you can save more time by not estimating as Kanban “allows” you to ditch estimating and instead track cycle time for deliverables that are broadly similar in size.
The project is going to change a lot or there are no fixed priorities. Kanban doesn’t have fixed timeboxes so you aren’t committing the team to specific features. While it’s not ideal to work in a fluid environment where the priorities change every day, Kanban will allow you to adapt to that if necessary. It’s a better approach for maintaining total flexibility on the scope of the work which can be important if you are developing something that has never been done before and that you know will evolve rapidly.
Let the Team Have the Final Say
Talk to your team about the two approaches and find out what thoughts they have about which one will be the best to use for this project. Their experiences, preferences, and knowledge of what’s to come should help shape the discussion. Play to their strengths wherever possible and work together to choose the right approach. Plus, it’s always nicer to work in an environment where you have had some say over how the work is to be done!
There is no straightforward answer to which is the best approach for your team because it depends so much on the team members and your work environment. Why not try both, get familiar with the processes and approaches of each and then you’ll be making the decision each time from a position of experience and knowledge. And you get to develop and empower your team on the journey!
What’s right for you today might not be right for you on the next project, so keep an open mind and think about the skills you need in the team to best serve your customers, whichever approach you use.
Whether you are looking to hire experienced staff or for your next move in your Agile career, Triumph Strategic Consulting can help you play to your strengths and succeed. Get in touch today to find out how we can support you and your teams.
Leave a Reply