Which do you prefer for product development, Kanban or Scrum?
Why do we keep putting these agile frameworks in opposition to each other? It isn’t necessary, many people choose to combine them because that is a great fit for their team and application.
I’m not talking specifically about the Kanban method, but the use of kanban boards in product development environments. What is often described as good, old-fashioned signalling.
Visualization of the work and making the flow of work transparent and visible.
Scrum
Scrum is a time-based approach to planning and product development.
Kanban
A workflow-based approach to planning and product development.
Rather than think of these as a best way forward or best practice, understand that they are tools. Each of them has their own unique strengths and weaknesses, and each of them are a great fit given a specific problem you are trying to solve or a constraint you need to work around.
Application
If you have a big list of stuff that needs doing, scrum might be the best approach because it is great at converting a volume of stuff into a working product that customers want.
If the work turns up in a more ad-hoc, volatile nature with requirements constantly shifting, then Kanban may be a better tool to employ, because Scrum asks you to commit to a specific, fixed time frame within which the work is performed and delivered.
The sprint goal is the team’s commitment, and that generally lasts between two weeks and four weeks, so if your work changes on a daily or hourly basis, you are going to be better served using a kanban framework for that work.
Product development in motion.
In my experience as a scrum master, agile coach, and agile consultant, I tend to find that newer teams tend to struggle with kanban.
It isn’t because it’s hard or difficult to use, but instead because the timeboxes of scrum make it easier for people to acquire and develop specific skills necessary to complete the work. A focus on achieving a set of objectives that lends itself well to a scrum-only approach.
- How do we plan?
- How do we design work?
- How do we build?
- How do we test?
- How do we achieve all of this in a short time frame?
Scrum lends itself incredibly well to that and helps teams evolve and improve through practise.
Scrum also insists that you learn, it requires it if you are going to deliver working products or solve complex problems within a two-week or four-week timebox. Kanban is pull-based work, and although it may have priorities, it doesn’t exert the same kind of pressure on a team to learn and evolve.
A sprint review also reinforces the need for a scrum team to get work done because a customer or product stakeholder is going to be present in that sprint review and EXPECT that something has been built, tested, and deployed effectively.
Kanban can be perceived to be more relaxed because you’re starting where you are, and evolving from there based on capacity and how effectively work flows through the system. If a specific item isn’t selected because the team aren’t ready to perform the work, it stays where it is and doesn’t flow through the system until much later down the line.
In experienced hands, kanban can be incredibly powerful and tends to lead toward teams evolving consistently and significantly, but in a new team, they tend to miss the more powerful elements of kanban and fail to achieve the same kind of results as they would in a scrum environment.
They don’t have to present work to stakeholders and customers in two weeks and so they don’t reach as high or work as hard as a newbie scrum team would in the same circumstances.
So, in my experience it takes a while to get a new kanban team started whereas a scrum team is in delivery mode right away. For this reason, I would start a new product development team with scrum and allow them to evolve and grow, as well as embed behaviours and practices, before looking to explore something like kanban.
What you need to do when deciding between scrum and kanban is:
- Who is in the team?
- What are their skills?
- What is their level of maturity?
- How experienced are they?
- How volatile or steady is the work flow?
- What market are you serving?
- What are the current market conditions?
And so forth.
Really think about all the variables that may impact the team’s performance and choose wisely.
About John McFadyen
If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.
For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster