A very common topic of discussion amongst Product Managers in general, and Agile practitioners in particular, involves the comparison of different forms of process and project management.  By far the most prominent and popular of these are Kanban and Scrum.  And, much to my own personal dismay, often these discussions wind up devolving into some form of “religious war” between fanatical fundamentalists on either side — insisting simply and without substance that their way is the best way.

The simple fact is that one is not necessarily better than the other — when, how, and where you use either of these approaches depends greatly on what problems you’re trying to solve, what kind of culture you have or want to have, and how the people you have doing the actual work want to manage themselves.  To say, in broad strokes, that either Kanban or Scrum is objectively “better” than the other misses the point entirely.  Both are equally good and equally bad, depending on the circumstances.

It’s probably important to first level-set with some definitions, so that we understand exactly what we’re talking about, why we’re talking about it, and what the benefits and drawbacks of each approach actually is…

What is Kanban?

Kanban is perhaps the most direct descendant of the world of lean manufacturing from the 1940s, during the Japanese post-war reconstruction.  Part of the Toyota Production System, the goal of Kanban (literally, “signboard”) is to create an environment of “just-in-time” delivery — originally within the manufacturing context, but later adapted to software development and general project management.  The fundamental concept is that every step in a process can provide “signals” to other steps, either forward or backward, such that we can determine a minimum and maximum amount of effort and productivity at each stage.

As adopted in the software world, Kanban specifically focuses on “work in progress” and “lanes” of work that are required to deliver software.  In essence, you create a board with horizontal and vertical “swim lanes” — the horizontal lanes may map to features, products, teams, or even individual resources; the vertical lanes map to the process itself, applying a known capacity limit at each step in the process.  A really basic Kanban board might look something like the following:

You’ll note that the “To Do” bucket has a work item limit of ten, but only four items in it.  This is good — it means that there’s room for more work in the To Do line; on the other side of the coin, there is a work item limit of five in the Done bucket, but eight items assigned there — this shows that there’s a backup in the process that needs to be addressed.   And there’s no work item limit on the Deployed column, because there’s no further work required on those items — they’re “closed”.

The primary advantage of Kanban is that it’s a “pull” process for the team — they take the top item in their vertical lane, work on it until it’s done, and move it to the next lane.  Once  that’s done, they take the next item in the lane and work it until it’s done, then move that to the next lane.  It’s a very production-line mentality, and while you can do estimates using story points or hours, the primary measure of progress and productivity is the number of work items in each lane, not the time it’s going to take to get any one thing done.  The idea is to move into a “just in time” mindset, where you’re finishing the top item at the same time that another work item is coming in to take it’s place.

The primary disadvantage of a traditional, “pure” Kanban approach is that it can be very difficult to estimate when any given work item might be done, as there may be a widely-varied mix of sizes and shapes in the swim lane, and the goal is to do each item to completion before taking on the next.  This can be frustrating in organizations that are strongly date-driven, as a “pure” Kanban approach only promises that something will be done when it’s done.  This focus on pure delivery does, however, provide benefits with increased quality in most situations.

What is Scrum?

Scrum is an Agile methodology that grew directly out of the work of several originators of the Agile Manifesto and Agile Principles — Ken Schwaber and Jeff Sutherland.  In many ways, Scrum is much more prescriptive than Kanban, in that it has specific expectations regarding principles, roles, and ceremonies; Kanban, on the other hand, is strictly focused on managing the flow of work, and agnostic about how you actually deliver that work.

Scrum is based on the following expectations:

• Principles
  • Teams should be self-organized and self-organizing.
  • Teams should be capable of full-stack development.
  • Teams should be focused on continual improvement.
  • Priorities are determined by the business, execution is determined by the engineers
  • Execution should be iterative and time-boxed.
• Roles
  • The Product Owner represents the customer and the business interests to the team.
  • The Scrum Master operates as a facilitator and remover of obstacles.
  • The team (5-9 people) makes commitments and self-enforces those commitments.
• Ceremonies
  • Backlog Grooming takes place to ensure work items are estimated and prioritized.
  • Sprint Planning ensures that the team knows, understands, and commits to deliverables.
  • Daily Standups exist for each team member to deliver updates and call out blockers.
  • Sprint Reviews demonstrate the outcome of the sprint to stakeholders.
  • Sprint Retrospectives provide the team an opportunity.

That’s a lot to take in, but it all really boils down to the following:

• Teams make commitments based on what they think they can do.
• Iterations are short, time-boxed, and focused on delivering potentially shippable results.
• The business sets the priority, the team estimates the effort, and the team delivers iteratively.

There’s quite the cottage industry involved in the Scrum world — there are any number of consultants and experts who will offer their services to make your team “Agile” and to make them conform to the expectations of Scrum.  And, if you don’t know what you’re doing, that’s probably a good idea — but as I’ve stated here, Scrum is just a foundation from which to build, adapt, and adopt better and more effective ways of working.

The benefits of Scrum is that it’s highly-structured, outcome-focused, and empowers teams to guide their own destiny.  A lot of trust is placed on teams in Scrum — that they can estimate appropriately, that they can devise solutions in time-constrained iterations, and that they’re willing and able to do full-stack development in an iterative fashion.  Especially in organizations that are starting out or building new products, having regular and consistent reviews of demonstrable progress can be supremely empowering.

The primary drawback of Scrum is that it’s widely misunderstood, adopted only in part, and/or adopted as Gospel truth that cannot ever be changed.  There are many in the software development world who rely on the Scrum Guide as the only source of truth, and there are equally as many people who think or claim to know what Scrum is but have never actually gone through any formal training or fully understand the why of the expectations, roles, and ceremonies — they can talk the talk but have never walked the walk.  Additionally, Scrum requires strong development teams willing and able to take on challenges without necessarily having detailed, to-the-letter specifications.  Agile in general, and Scrum in particular, works best when you have teams made up of dedicate problem solvers and not just code-monkeys.

When Should I Choose One Over The Other?

There’s no one-size-fits-all answer to this question — and, in fact, there are many successful teams who use some combination of both approaches, popularly known as “ScrumBan”.  As with any Agile tool, process, or approach, you need to try something to determine whether it fits your needs and your culture, and then adopt and adapt as necessary.

Anyone who tries to tell you that there is one solution that will solve all of your problems — especially without doing a detailed analysis of how your team, your company, and your culture works, is selling you snake oil.  Don’t trust them and definitely don’t give them money.  Try iterative improvement, and you’ll see better and more repeatable success.