Kanban vs. Sprints
Is one better than the other?
I recently realized that I haven’t managed a product using the traditional 2-week sprint cycle in over a year and a half. Instead, I have been releasing and managing products with the Kanban methodology. While I don’t miss sprint planning, it made me think, is one method better than the other?
First, what is a sprint cycle?
Agile sprints are repeatable set periods of time, typically between 1–4 weeks, with the goal of delivering a specific outcome. Prior to the sprint (ie. 2 weeks), the team would discuss the outcome, plan the work, and assign the stories to the development team. The work is then scoped out for the next 2 weeks via sprint planning and after the sprint is complete, the team can release on a set schedule.
OK, then what is Kanban?
Kanban, which means sign in Japanese, is most famous for its implementation at Toyota for just-in-time manufacturing. The key is that it’s a visual representation to track production and order new inventory. So what does that mean in terms of software development? The Kanban board visually shows the work to be accomplished, always listed in priority order. The development team works on the next most important story in the “To Do” column and there are no set timeframes or release schedules. Priorities frequently change, roles and responsibilities are less defined and the team releases based on customer/stakeholder requirements.
So, should I use Sprint or Kanban?
It’s not a question of which is better but rather, when should you use each methodology? Early on in the product life cycle, Kanban is a better fit. During the product development stage, the team is researching, iterating and building a product based on assumptions. Requirements and scope are rapidly changing and having the ability to adjust on the fly is better supported by the “next up” Kanban style rather than a predefined sprint. Since the development of a product can take several weeks or months, working in 2 week increments can also be very demoralizing for the team since it’s hard to measure your overall progress in such small time blocks. Also, planning in sprint increments requires a lot of planning overhead for the team which can slow down the overall development process.
Once the product is launched, it enters into the product growth stage. The goal of this stage is to gain market adoption. This stage is analogous to the wild wild west because you need to continue to iterate and develop rapidly while also supporting a live product with real customer demands. Early on, there are a few key lighthouse customers that will drive product growth and since they are paying customers, you need to be in the best position to respond to their product demands. These requests can drastically change your team’s priorities which is why Kanban is a better fit. Also, no matter how amazing your QA process is, you will have bugs. Fixing critical bugs can not wait for the next scheduled release cycle created by sprint cycles.
Assuming your product has found product market fit, it enters a stage called product management. In this stage, sprint cycles make a lot of sense because the product is much more stable as the product vision and roadmap are more defined. The Product Manager will spend the majority of his/her time evaluating and prioritizing the backlog of new feature requests and bugs. Planning work in 2–3 week cycles allows for incremental progress in a structured framework that is easy to communicate to the development team, stakeholders and customers. If you are a PM at a large company, you will most likely be working in this phase of the life cycle.
All good things eventually come to an end and when that happens, the product enters the sunset phase. The product manager is responsible for transitioning active customers to the replacement solution. In the case of physical products, the PM is accountable for reducing inventory on hand. Very new features are released at this point and the work is primarily focused on cleaning up remaining bugs and preparing both the customer and the company for transition. Established work cycles tied to key milestone dates are closely aligned.
Symbiosis, Kanban & Sprints
As I reflected on the past year and a half of product experiences, it became clear that Kanban was the primary method not because it was superior, but rather because I was working on early stage product solutions. As the product moves through the life cycle, the team needs to support it in different ways. Early on when the product is rapidly changing, the Kanban method better positions your team to be adaptive and responsive. The team will work on the next most important topic as Kanban eliminates planning overhead, structured time-blocks and predetermined release schedules. However, as the product matures, the stability and structure created by sprint cycles is critical for managing the product and communicating the roadmap. One method is not better than the other but rather an indication of the life stages of your product.
