In this blog, I provide a short summary comparing three Agile approaches I often hear about: Scrum, Kanban and Scrumban. I also give some succinct recommendations about when to use one over the others.
Scrum
At its core Scrum is an iterative and incremental Agile software development framework for managing product development. The framework defines three roles, five events, three artifacts, and six principles.
Scrum is designed for teams of three to nine developers who break their work into chunks that can be completed within a fixed time period, called sprints. The team tracks their progress and re-plans in daily 15-minute stand-up meetings, called the daily scrum, and collaborate to deliver workable software every sprint.
Scrum defines a flexible, holistic product development strategy where a development team works as a unit to reach a common goal. This mindset challenges the assumptions of the more traditional, sequential approach to product development. It enables teams to self-organize by encouraging physical co-location or close online collaboration, as well as daily face-to-face communication among all team members and disciplines involved in the effort.
Scrum adopts an evidence-based empirical approach, accepting that the problem cannot be fully understood or defined up front. Instead, focus is placed on maximizing the team’s ability to respond to emerging requirements, deliver value quickly and adapt to new technologies and changes in market conditions.
My recommendation is to use Scrum in those environments where a team is allowed to focus on a single project and is unlikely to be interrupted in the middle of a sprint.
Kanban
Kanban is a management method for improving service delivery. It builds on Lean and Theory of Constraints and it emphasizes visualization, deferred commitment, a focus on the flow of work, and just-in-time (JIT) delivery. Kanban is an effective tool to support a whole delivery system and is an excellent way to promote process improvement. Problem areas are highlighted by measuring lead time of the entire process and cycle times of each process step. One of the main benefits of Kanban is that it establishes an upper limit to the work-in-process (WIP) inventory and avoids overloading the delivery system or any step within it.
My recommendation is to use Kanban in those situations when a team has a very hard time controlling the amount of incoming work, either because they are responding to production issues, supporting unplanned requests, answering questions from upper management, or balancing other demands for their time.
Scrumban
Scrumban is a software development framework that leverages elements of Scrum while using Kanban to drive continuous improvement. The first article on Scrumban described several levels of transition from Scrum to Kanban. Corey Ladas wrote a paper on the subject in 2009.
Scrumban emphasizes principles and practices that are not part of Scrum’s traditional foundation.
The original concept behind Scrumban, as developed by Corey Ladas, was a transitional state for Scrum teams moving to Kanban. But the term has evolved and no agreed-upon definition of Scrumban is dominant today. It is generally taken to mean a software delivery framework that integrates elements of Scrum and Kanban. Depending upon a specific organization’s needs or challenges the combination can vary; this is why there is no universal definition of the term.
My recommendation is to use Scrumban when a team has a hard time completing the work they committed to within the sprint, regardless of why that occurs. The introduction of WIP limits will help focus their attention on the most important items and allow them to deliver more reliably.
References:
https://en.wikipedia.org/wiki/Scrum_(software_development)
https://en.wikipedia.org/wiki/Kanban
https://en.wikipedia.org/wiki/Scrumban