THE USUAL DILEMMA, SCRUM OR KANBAN

Many teams and agile coaches experience a dilemma when they are consulted with a question of choosing between Scrum and Kanban. Between Scrum and Kanban (or even Scrumban) there is nothing like one is better than the other, each brings its own flavor, uniqueness and has the potential to address a unique problem that a team might be facing.

Choosing between scrum and kanban

Scrum and Kanban, both would fit in the complex quadrant of the Cynefin framework developed by Snowden & Boone. This section we will uncover more decision-making points that can help us choose between the two.

Team Maturity v/s Organizational Readiness

This decision-making pointer factors in team’s maturity in agile/lean practices and its organizations readiness to be inclusive of new roles in Scrum and DevOps practices.

For a team having high maturity and working in an organization who practices continuous improvement, we can choose Scrum or Kanban (any or a mix).

For a team with low maturity and working in an organization who is either not ready or a beginner in agile, we can choose Kanban as it allows us to realize current conditions and look for improvements in them.

For a team with low maturity working in an organization with high level of readiness in agile/lean, we choose Scrum. Teams with low maturity tend to work better when they are given a goal with a time-box.

Team Maturity v/s Risk Level

In this, we take a closer look at the team’s maturity in agile/lean practices and the risk level associated with the product.

Teams with low maturity tend to work best in a goal-oriented timeboxed environment like Scrum thereby controlling the risk through regular checks and reviews. Teams with high maturity tend to work best in an empowered environment therefore we choose Scrum or Kanban (any) for such teams who can self-organize and manage risks. 

Cross Functionality v/s Predictability of flow

Here we try to evaluate the teams cross-functional capability v/s the predictability of the flow of incoming work i.e. if a product has low probability of scope creep and/or has less frequent changes in priorities that means it has high predictability of flow of incoming work and vice versa.

A team with low predictability of incoming work i.e. there are frequent changes to scope or changes to the priority of work items, such teams should choose Kanban as preferred approach as it allows them to monitor the cycle times. A highly cross-functional team with high predictability of work can use Scrum whereas a team with less cross-functional skills but with high predictability of work can choose between Scrum or Kanban (any or a mix).

Cross Functional Team v/s Number of Products to be supported

There are teams which have to work on multiple products and each product may be built for different platforms, such teams may have team members with different and contrasting specialized skill-sets.

If a team has to support multiple products then it is best to use Kanban as a centralized sprint planning does not work best given that team members are mostly of specialized skills and will work only on particular work items. This calls for more dynamic way of working like Kanban.

For single product, the team may choose any Scrum or Kanban.

Predictability v/s Responsiveness

This decision-making pointer revolves around what is more important for your customer/business/product i.e. Predictability of teams output or Responsiveness.

If predictability of teams output is the primary concern, then choose Scrum which helps team track their work using burn-up, burn-down and velocity charts.

If responsiveness is the primary concern, then choose Kanban as it helps the team focus on throughput metrics.

If predictability of teams output and responsiveness both are important, then you can choose between Kanban and Scrum. A preference is given to Kanban here as the throughput metrics allows us to monitor the response time as well as other metrics such as lead time distribution allows to monitor the predictability too.

Conclusion

The five-point decision making system helps us to consider various aspects such as

• Teams maturity in agile practices
• Cross-functionality
• Number of products involved.
• Organizations Readiness toward adopting Agile, Lean and DevOps practices
• Customer point of view (Predictability and Responsiveness)

For decision making, it’s best to evaluate using a combination of decision-making pointers (if not all five) to arrive at a conclusion on whether to use Scrum or Kanban.

There are some quadrants in the graphs where there is liberty for the decision-maker to choose between Scrum or Kanban, this is to respect the experience and first-hand information that the decision-makers may have at hand. The decision makers can choose Scrum, Kanban or a mix of both such as Scrumban. In addition, assessing team maturity is not talked about in detail, this is to limit the posts content, however you are free to use your own assessment methods.

The five-point decision making model deliberately does not look into the pros and cons of Scrum/Kanban and neither does it work based on the type of project i.e. Support, Maintenance, greenfield, brownfield etc. This is so because, it believes that both Scrum and Kanban are powerful in their own way and there is nothing like one is better than the other. Which one to choose depends on the situation at hand and as Agile coaches we can help us and our teams think through these pointers to arrive at a logical conclusion on what is the best way forward for the team.

References

Snowden, D. J., & Boone, M. E. . A Leader’s Framework for Decision Making. Retrieved from https://hbr.org/2007/11/a-leaders-framework-for-decision-making

Copyright © 2018 My Agile Diary
This work is licensed under Creative Commons Attribution 4.0 International License. In other words, share generously but provide attribution.

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer’s view.