Scrum and Kanban are two popular frameworks that some of the software development teams out there use. Scrum is currently used quite a bit more than Kanban in software development but that does not necessarily mean that Scrum is inherently better than Kanban. There are some scenarios in which Scrum is the better fit for a development team and some scenarios in which Kanban is the better fit for the development team. In this blog post we will cover which scenarios I feel Scrum makes more sense and which scenarios I feel that Kanban makes more sense.
Scrum has this concept of timeboxing (sprints) and optimizing the product for getting feedback at the end of the sprint. Kanban tends to focus more on releases. So when determining which framework to use, the most important question to ask is
would our team deliver more value if we optimize our product for getting feedback at demos in fixed 2-4 week intervals?
Sometimes the answer will be yes. Other times the answer will be no. Keep in mind that when you optimize the product for getting feedback at demos, you need to make sacrifices. You end up coming up with a plan for what to work on for the sprint and try to avoid making changes. You might all of a sudden realize that there is another story that could be done that might deliver more value but you will have to stick with what you planned since you already planned the sprint and the demo is near. Now let’s take a look at what will influence our answer to this question quoted above.
The amount of feedback a team typically gets at their demos is the number one indicator of whether or not the team should use Scrum or Kanban.
If your team is a feature team, then your team is able to complete a portion of a feature (if not all of it) at the end of a sprint. The feature team can then demo the work it has completed at the end of the sprint and potentially get a lot of feedback. If real users of the software are included in demos, then the team will get even more feedback. If a team excludes real users in their demos and only demos to internal stakeholders, they may not get near as much feedback. Teams should aim to include real users in their software for real feedback. If a feature team can get a lot of feedback in their demos, then it most likely makes sense to use Scrum. If not, then Kanban is probably a better approach.
If your team is a component team, then your team will complete a portion of a component at the end of each sprint. This work might be done for a specific feature in mind or it could be that the team is just working on a re-usable asset that is not tied to a particular feature but might be helpful to many other teams out there. Because component teams aren’t responsible for delivering features, they typically don’t produce something that would receive much feedback in a demo very frequently. Most component teams are only back-end teams where the code they write wouldn’t be something you can see. As a result, component teams are very poor candidates for Scrum and I strongly prefer Kanban for them.
I would consider the unpredictability of a team’s work to be the second biggest factor in determining whether to use Scrum or Kanban. Any remaining factors that would help determine whether to use Scrum or Kanban would be pretty minor and thus won’t be mentioned in this blog post.
Scrum discourages changes to the sprint. This doesn’t mean that we can’t make changes. It just means we should think long and hard before we consider changes. Scrum does the sprint planning at the start of the sprint. If we need to keep making changes, then that devalues some of the effort spent in doing sprint planning. When we need to change our plans with Kanban, we can put something on the top of the product backlog and get to it as soon as someone finishes their current task.
Suppose that your team is a dedicated support team. Your team only does support. If you do Scrum, you would plan which defects you want to work on for the sprint. The most obvious problem is that there can be issues reported in production at any time that are going to be more important than the defects you are currently working on. So we could spend time doing sprint planning but it is less likely that our sprint plans would hold up since issues could pop up in the middle of the sprint that we would need to pull into sprint. This results in a higher percentage of failed sprint goals. So for support teams, I strongly prefer Kanban.
Suppose instead you are on a team that does both enhancements and defects. Maybe your team has very few defects in production. In this case, you can do your sprint planning and it is less likely that the plans you came up with are going to get interrupted by issues going on in production. This team would be a strong candidate for Scrum as long as they are able to get valuable feedback at the demos. If this team instead has many defects in production and frequent interruptions to deal with these incoming defects, then Scrum probably wouldn’t make sense anymore. In that scenario, I’d go with Kanban.
Releasing is the only thing that delivers value to the customer which might make it look like Scrum is worse than Kanban since Scrum optimizes around sprints which may or may not include a release. However, it could be the case that optimizing around getting feedback at the demo does happen to make the releases as valuable as possible because demos can be a valuable opportunity to keep the product going in the right direction. As a result, neither framework is inherently better than the other. Scrum tends to make more sense for teams that get valuable feedback as well as for teams with a predictable workload. If a team plans out their sprint but frequently gets interrupted by incoming defects in production, then their sprint plans will hold up less often. This reduces the value of sprint planning which devalues the benefit of Scrum. So for highly interrupted teams where their short term plans are less likely to hold up, I prefer Kanban.