For people stepping into an agile organization or team for the first time, a lot will seem new and unfamiliar. People will throw buzzwords around like throughput, standup, and WIP. As you get more familiar you’ll need to start educating yourself on some fundamental decisions agile engineering teams face so you can craft an educated opinion.
Looking for background on what agile even is? Read more on the difference between agile and non agile methodologies.
I’ve worked as a Product Manager on agile teams using both scrum and kanban workflow methodologies. One of the big first questions that seems to come up frequently is:
What is the difference between Scrum and Kanban?
Scrum and Kanban are two agile methodologies that in the tech space, are used to organize software development teams to develop new software as fast and efficiently as possible.
They come from different backgrounds: Scrum: Was developed into a formal process by Jeff Sutherland and Ken Schwaber in 1993 with the focus of improving how software teams deliver value.
To learn more about scrum, hear about it from the creator himself and check out this document: Jeff Sutherland
Kanban: The origin story of Kanban was a lot different than Scrum. Kanban came about back in the 1940s, and was first created to optimize Toyota’s physical manufacturing process for both quality, a reduction in waste, and getting more value (or cars) delivered to the customer.
Talk about crazy, Scrum, coming to life in the last few decades, compared to Kanban, used for building cars back in the day!
But the goals are the same; deliver the most value to the customer as efficiently as possible.
Let’s talk about the differences between Scrum and Kanban:
1. Ceremonies:
While ceremonies used can differ by team, for the most part they are generally the same. Both Scrum and Kanban based teams generally have standup (a gathering during the day to review what was done and what needs doing), should have retrospectives on a regular basis, and should have grooming sessions (where the Product Manager presents upcoming tickets and works with the team to break the tickets into tasks the engineering team can work on).
One difference is that a ceremony called planning doesn't really happen in Kanban but is essential in Scrum. In Scrum, planning is necessary. Every sprint (or 1-2 week period), the team will sit in a room for an hour or more and think about what they want to get done within the next week or two weeks. By the end of planning, they have a list of tickets and features the team would like to get done during this time, and have laddered up those tickets or features to a sprint goal. A sprint goal, for example “This sprint is successful if XYZ happens” is generally phrased in a way that is customer oriented.
Kanban doesn’t have planning, but does prioritize things in a different way which I’ll get into now:
2. Focus:
Scrum and Kanban drive significantly different views of what to focus on for the engineering team.
In Kanban: Tickets and new work are first prioritized in the backlog in a stack ranked order. As engineers finish off tasks that they were working on, they go to the top ticket in the backlog and pick that up. There is no discussion in terms of prioritization or lack of clarity in terms of what should be picked up because the answer is always clear; the first ticket on the top of the pile.
In Scrum: Work is planned in sprints. Through a planning session, the scrum team and Product Manager collaboratively align on how much work can be pulled into the next sprint, and the priority of that work. Scrum teams can work off of 1 week sprints, or 2 week long sprints depending on preference. Along with aligning on how much work can be pulled into a sprint, the scrum team and Product Manager must also align on a sprint goal. In an ideal world, each sprint should have a goal that includes getting working and finalized functionality live to the customer and adding value. Once the scrum team starts the sprint, they work through the tickets prioritized in planning, all with the focus of building towards the sprint goal decided.
3. Limits:
In its simplest form, Scrum and Kanban are both ways of driving focus for engineering teams.
They do this in different ways through artificial limits set on the team: Scrum: In scrum, the limit is time. Focus is constrained by sprints; 2 week blocks of time that include outlining what the team aims to do during that time at the beginning, and a retrospective capping off the sprint and thinking about what could be improved for the future. Generally teams running scrum will have no other self imposed limits.
Kanban: In Kanban, the focus is a count of the number of total features or things the team is working on at one time. Kanban is a continuous process; teams don’t plan out in weeks, but instead just continuously plan. What the team is inhibited by is WIP limits. WIP stands for Work In progress. A team sets a WIP limit as a way of limiting how much work a team can take on at one time.
As a super basic example, let’s say you run a factory building cars. Each car needs one steering wheel, and four tires. You have two employees, Sally Steering, and Tony Tire. Both of them can make one of their respective products an hour. After the first 8 hour day, Sally has made 8 steering wheels, and Tony has made 8 tires for the car. That means that by the end of the day, only 2 total cars could be shipped off to a customer because there just are not enough tires to make up for the surplus of steering wheels Sally is cranking out. This also means after a month, the factory will be full to the brim with steering wheels that are not needed because Tony just can't make tires fast enough! Work has to be shut down while we clean out all of those excess steering wheels. HOW RIDICULOUS!
But instead let’s put a WIP limit. Sally will have a WIP limit of 1, and only make a steering wheel once there are 4 tires completed and ready to go. Well for the first 4 hours Sally gets to work each day, she can’t make a steering wheel because there are not enough tires ready to go, so she moves over to Tony’s station and helps him make a tire or two. With this slack in the system, the factory can almost double the amount of cars they produce and no one is drowning anymore in a sea of steering wheels.
While this is a very quick overview of the differences between Scrum and Kanban, I hope it gives you a glimpse into how these two methodologies can drive different results.
Want a different take? Here is a perfectly fine video that breaks down the difference in 5 minutes.
Which one is right for you?
The short, typical answer? It depends. Oftentimes you will be coming into a team already running one or the other. Of course things can always be improved, but you need to make sure you understand what is working for the team currently and what can be improved, then select optimizations to existing processes that improve that flow of work.
I have seen teams work flawlessly running full scrum. I’m working with a team at Nordstrom currently that runs Kanban and is doing incredible work. I’ve been on teams in the past that run Scrum-ban: A mix between both kanban and scrum. There the team ran off of 1 week sprints, but also wanted to drive focus for the team and decided to set WIP limits for themselves to better facilitate pair programming and the review of merge requests.
Whatever you decide, pick something, move fast, iterate, and if it doesn’t work, be ready to pivot into a new way of working.
About the author:
Ben Staples has over 7 years of product management and product marketing eCommerce experience. He is currently employed at Nordstrom as a Senior Product Manager responsible for their product pages on Nordstrom.com. Previously, Ben was a Senior Product Manager for Trunk Club responsible for their iOS and Android apps. Ben started his Product career as a Product Manager for Vistaprint where he was responsible for their cart and Checkout experiences. Before leaving Vistaprint, Ben founded the Vistaprint Product Management guild with over 40 members. Learn more at www.Ben-Staples.com
I do Product Management consulting! Interested in finding out more? Want to get notified when my next product article comes out? Interested in getting into Product Management but don't know how? Contact me!
Comments