Kanban or Scrum? by Ron Lichty

I’ve been asked by more than one team I’m training: Kanban or Scrum?

Of course, the first answer is to ask if you’re even being agile. There are way too many teams doing scrum or doing kanban, and way too few teams being agile!

While Agile values and principles apply equally to Scrum and Kanban, Scrum and Kanban do not equally support Agile values and principles required for different kinds of work.

Scrum, with its aspirational sprint goal, its sprint planning ceremony, its daily scrums to ensure teams come together at least daily to replan, and its end-of-sprint demo and retrospective, supports teamwork taking on a larger product or project, one set of increments at a time: the team supporting every one of its members every day as they together encounter, share and resolve challenges and deliver the increments.

When Kanban teams set and hold themselves accountable to appropriate Work-in-Progress Limits, the need for everyone with a piece of the story to finish before anyone can be finished can motivate internal teamwork that drives completion and delivery. But Kanban can feel much more oriented to piecework and more difficult to connect the team to customers and larger outcomes and impacts, given lack of a larger (sprint) goal. Output over outcomes. That leads us, whenever possible, to leverage Scrum for projects and products and Kanban for rolling-requests teams that need to change up their backlogs daily to ensure appropriate customer responsiveness.

If you find yourselves with a product team using Kanban, you’ll need to devote more focus to connecting members of the team to customers, impact and mission in addition to each other. And with Kanban’s lack of regular cadence, retrospectives can become irregular and experiments (for more team joy, better thruput, higher quality, …) too infrequent.

On the other hand, outside pressure applied to Scrum teams can cause them to focus on output instead of outcomes; and lack of value-focus can lead to standups that devolve to status meetings, planning ceremonies that focus on output rather than outcomes, demos that teams sleep-walk through, and retrospectives that seldom or never yield an experiment to try in the coming sprint.

There are, of course, other choices than Scrum or Kanban - I’d urge teams to seriously consider overlaying either with as many XP engineering practices (pair or ensemble programming, test driven development, continuous integration/continuous deployment, continuous refactoring, …) as is viable - or mix a cocktail of the best of all three - and to look at emerging approaches like Shape Up or FAST. But it’s inevitably Scrum vs Kanban about which I’m asked.

Regardless whether Scrum or Kanban or something else, teams need to be diligent in asking if they’re being agile - if their practices are delivering on the promises of teamwork and customer focus embedded in agile’s values and principles and core to being agile.