Whether you're already committed to one of the two most popular agile frameworks or you're looking for the best one to answer your needs, explore the key differences between Scrum and Kanban and take the test to find out which one suits you best.
As a Product Manager (PM), I've encountered different situations and used both Scrum and Kanban. Sometimes, my team was used to its processes and rituals and was perfectly comfortable with them. Other times, when faced with delays or setbacks, it questioned its own organization. So how do you determine the relevance of a methodology for your team? Is there a right time to switch from Scrum to Kanban (or the other way around)?
🎡 Scrum, the consensus for all types of companies
I've found Scrum in the majority of contexts I've experienced, whether within large corporations, startups, or scale-ups. When working in a Scrum environment, days are filled with recurring meetings: dailies, sprint plannings, retrospectives, or refinements. Therefore, I can't work in a just-in-time manner and I always need to be ahead in my User Stories (US) to feed my team during the next sprint.
So, I have a very clear view of the work ahead, and I can estimate fairly accurately the release dates of my new features. The structure offered by Scrum allows me to clarify my sprint's objectives to my team. However, this means I must be prepared enough to anticipate my team's needs. If an urgent user story arises, it generally can only be taken on in the next sprint, unless it impacts the current one. However, it's preferable to avoid this as much as possible to respect the objectives set at the beginning of the sprint.
🌈 Kanban, the way towards more freedom?
I recently experienced Kanban during a project for a startup. My daily life is much lighter and flexible than it is with Scrum. My number of meetings decreases: no more dailies, sprint planning, or retrospectives, etc. With Kanban, I no longer have mandatory ceremonies imposing a rhythm on the team. Therefore, I’m not required to have all the US for the next fifteen days ready for a specific date: I can also choose to continuously feed the backlog, for instance if anticipating everything proves too challenging. I finally have the option to add an urgent US as the next task for developers, which you’ll probably agree is rather handy in case of sudden priority changes.
On the flip side, I don't have as strong visibility on the team's progress. It's difficult for me to determine a potential release date. My visibility essentially relies on the progress of tickets on the Kanban board, hence the importance for me to work with a team of developers who are sufficiently aware and rigorous to move their tickets across columns in real-time. I also have to take responsibility for identifying (even if my Tech lead can help) tickets that haven't left the "in progress" column for a few days, in order to discuss them with the developer in charge.
So, as you can see, both these frameworks have their own advantages and disadvantages for a PM.
✅ Take the test!
You’re wondering if you're operating within the most suitable product framework for your context? To help you out, here is a quick quiz to get the answer to this question in just 3 minutes. Remember, there's no absolute truth here!
Part 1: The Context
Q1: How much visibility does your management demand from me?
💧 I need to provide a lot of visibility to my management, which regularly asks about the progress of developments.
⭐️ I need to provide visibility to my management occasionally.
🔥 I don't particularly need to provide visibility to my management.
Q2: What stage of development/growth is my product in?
💧 Product development is accelerating (post-MVP).
⭐️ Product growth is slowing down: we've entered a quieter phase after strong development.
🔥 The product is being built (pre-MVP).
Q3: Are Product priorities changing?
💧 No, once the plan has been established, under no circumstances should it be changed.
⭐️ Yes, priorities change but it can be anticipated.
🔥 Yes, priorities are changing incessantly.
Q4: What is the level of Product/Agile maturity in my organization?
💧 My company is not Agile at all.
⭐️ My company is transitioning to agility, from a Waterfall methodology or from a domain initially distant from tech (no digital product originally, for example).
🔥 My company is Agile, mastering the agile mindset and knowing how to apply it without necessarily being "by the book".
Part 2: The team’s needs
Q5: What is the need for guidance within the team (process level)?
💧 Can’t live without processes! They're everywhere in my organization and it suits me well.
⭐️ We have a base of processes; sometimes we add some, sometimes we remove some.
🔥 It's "freestyle"!
Q6: How clear is what we need to build?
💧Very clear.
⭐️ Overall, it's clear.
🔥 Still vague.
Part 3: Team Dynamics
Q7: How does the team react to obstacles and unforeseen problems?
💧 The team seeks to solve problems in a structured manner using predefined methods.
⭐️ The team avoids obstacles as much as possible by rigorously following established processes.
🔥 The team is used to solving problems quickly without needing to formalize procedures.
Q8: What is the level of autonomy and responsibility of team members?
💧 Team members are encouraged to make decisions and manage their own work autonomously.
⭐️ Team members have defined roles and responsibilities but still need validation for certain actions.
🔥 Team members have a great deal of autonomy and few constraints in terms of defined responsibilities.
🔍 Your answers
Count your emojis:
You mostly got💧?
You operate in an environment requiring high management visibility, a structured framework, and well-established processes (possibly even a post-MVP growth stage for your product). In this context, Scrum offers the structured framework and necessary processes to meet these needs.
You mostly got 🔥?
Your work environment favors flexibility and responsiveness to constant changes, with less pronounced needs for strict visibility and rigid structures imposed by formal processes. Kanban, with its more fluid and adaptable approach, may be the perfect tool for managing your projects under these conditions.
You mostly got ⭐️?
Your situation is probably somewhere between Scrum and Kanban, benefiting from moderate structure while requiring some flexibility. You can switch between the two depending on your context. Therefore, it's important to consider the unique aspects of your team, your product, and your work environment to determine which framework or combination of frameworks might best suit you. If you're not convinced by Scrum or Kanban, don't panic! Other frameworks are available as well.
In conclusion, I'm convinced that there's no perfect methodology, but rather methodologies that can benefit a team in a given context, for a certain time. As the team's context evolves, a change in methodology may be relevant to adapt to new realities.
To conclude, here are 4 key points to remember:
- The chosen methodology must be tailored to my team and my needs.
- I must remain open to changes if the current approach no longer seems to work effectively, and keep in mind that the choice of methodology is never set in stone.
- Exploring different methodologies can help me find the one that best suits my needs (without blowing hot and cold).
- And if neither Scrum nor Kanban seems ideal to you, there are also other alternatives such as Scrumban, Shape Up, ...
Thanks to Julie Crépet and Naban Tuo for their valuable help during the writing of this article.
For more information: download our Product Management Toolkit
