This post is the latest in Excella’s Dear Agile series of blog posts. Have a question for Dear Agile? Send it to us via our anonymous submission form.
DEAR AGILE –
How do you determine whether to use Scrum or Kanban on a given project? Some folks maintain that Kanban can (or at least should) work anywhere, while others find the structure of Scrum very helpful for some common challenges. What factors should I consider when selecting a methodology, and what should I consider beyond these two approaches?
— WONDERER
DEAR WONDERER –
Teams tend to think that Scrum and Kanban are two different “methodologies” and they should select one. This is a false dichotomy. Scrum and Kanban complement each other and often work well together. There’s no need to choose one over the other.
Scrum is a “process framework.” It leverages fixed time boxes (sprints) to increase focus on short-term goals and minimize task switching. Cross-functional teams are formed to meet the objectives. Prioritization and feedback is provided by a Product Owner and an embedded coach—the Scrum Master—guides the team through cycles of inspection and adaptation to improve their approach.
Kanban is a “management method” that focuses on incremental, evolutionary improvement. It emphasizes “starting where you are” and respecting established roles and processes. Visualization, limited work in progress, and management of flow create a catalyst for continual improvement.
In practice, effective agile teams often merge these approaches. Scrum teams regularly employ “scrum boards” that visualize their work. Some will limit their work in progress by focusing on only one or two stories at a time within a sprint. Retrospective sessions tend to trigger evolutionary improvement, customizing the Scrum Framework to local conditions. These ideas parallel the Kanban Method.
Kanban teams usually establish regular meetings for replenishment—to bring in new work—and for delivery that allow them to gain the benefit of regular cadences. They will not “commit” to a set amount of work within a timebox, but they will establish service level agreements for the delivery of specific functionality and use predictive forecasting for larger amounts of work based on their throughput. It can often be very difficult to classify an effective team that is gaining benefit from both the Scrum Framework and the Kanban Method.
The most important factor in deciding where to start is the current context. Is there a cohesive, cross-functional team in place? If not, is there a desire to create one? Is there a logical choice for a Product Owner? Scrum Master? If the answer to these questions is “no,” then Kanban, with its respect for established structures and ability to “start where you are” is likely a better place to begin.
The nature of the work is also important. Can it be divided into relatively small pieces and demonstrated on a regular basis? Can the team be left with a set of well-defined priorities for two weeks? Is there a need to show working software and gain feedback at the same cadence? If the answer to these is “yes,” then Scrum’s well-defined timeboxes can be an effective starting point.
The key is to gain an understanding of the underlying concepts behind these approaches—the need to limit work in progress, increase focus, accelerate feedback, and enable empowered knowledge workers—and harness them for success in your context, something we’re doing at Excella every day.
About the Author
Trent Hone is an Agile Coach with Excella Consulting and an award-winning Naval Historian. He has worked with dozens of software teams from around the world to improve their art of practice and written extensively about organizational learning. He has been awarded the Edward S. Miller Prize, the Rear Admiral Ernest M. Eller Prize, and was a finalist for the Brickell Key Award. He has presented at Lean Kanban North America, DevOpsDays DC, Lean Agile Scotland, and the Society of Military History’s Annual Meeting.