Scrum vs Kanban: which is right for your personality?

Lean management techniques like Scrum  and  Kanban come up a lot on this blog, due to their status as key concepts in the product management glossary. There are scores of other models and methodologies out there, but none have been able to replace these two. When you’re just starting out in developing, it’s easy to get lost in all the terminology. This article is a personality test of sorts, meant to help explain the differences between the two in terms of traits characteristic to each method. Hopefully, this will help you tackle one of the basic questions every product manager struggles with: deciding which method is right for their team and product.

How Scrum and Kanban came to be

Before we dive in, it may be helpful to understand that Kanban is a visual approach to project management that predates software development. Used in Japan since the late 1940s, it was applied by the Toyota car company to their main plant machine shop in 1953. The name Kanban literally means billboard in Japanese. Its main idea was to manage workflow by placing tasks on a board where workflow and progress are clear to all participants. Kanban helps improve inefficiencies and has been used to schedule lean manufacturing in Agile projects. Agile teams use Kanban boards for story-boarding user stories and for backlog planning in software development.

The term Scrum is a more recent one and was introduced in a “Harvard Business Review” article from 1986 by Hirotaka Takeuchi and Ikujiro Nonaka. It became a part of Agile with the publishing of the seminal book “Agile Software Development with Scrum” in 2001. Scrum is a short “sprint” approach to managing projects. It’s ideal for teams of no more than 10 people, and often is wedded to two-week cycles with short daily meetings. It’s led by what is called a Scrum master. It works within an Agile framework, though there have been attempts to scale Scrum to fit larger organizations.  

Who is Scrum right for?

Lovers of Structure: Scrum is first and foremost a well-defined framework for arranging your work. Introducing Scrum is quite a challenge for a team not used to the agile way of software development: you will have to start working in iterations, build cross-functional teams, and appoint strictly defined roles, such as product owner and  Scrum master. Switching your organization to use Scrum is a fundamental shift which will shake up old habits and transform them into more effective ones.

Socialites: Scrum stresses frequent face-to-face communication between team members by introducing regular meetings for iteration planning, daily status updates, and sprint review. Because you’re moving quickly, you’re meeting often, at least daily. This serves a double purpose by adding to the transparency of the project and keeping team members accountable for their work. It’s also a great way for managers to stay on top of what’s going on.  

Careful Planners: Scrum deals with the endless stream of changes faced by product developers by putting a stress on planning. From sprint planning to sprint retrospective, a big part of the process is making sure the team is aligned about the next steps, priorities, and learnings from previous sprints.

Comitters: Working with Scrum means taking more responsibility, raising code quality, increasing speed. As your teams commit to sprint goals, they are intrinsically motivated to get better and faster in order to deliver what they promised. Scrum leverages team commitment as a change agent. If you have developers that can’t make that commitment, or are routinely pulled into other, unrelated streams of work than you’re better off not making those commitments at all and scrum may not be for you.

Who is Kanban right for?

Spontaneous Souls: Unlike Scrum, Kanban is easy to understand and doesn’t require training and experience. That means you can hit the ground running by introducing change to an existing software development cycle or project management methodology. The principle of Kanban is that you start with whatever you are doing now.

Marathon Men: Kanban’s main difference from Scrum is the lack of sprints. It flows as long as the project needs it to. You don’t have to reset the Kanban board as you move through the project. It flows as long as the project needs it to.  Without a hard deadline, it’s more likely that a task or phase will stagnant and take longer than it needs to. Because WIP is limited in a Kanban system, anything that becomes blocked for any reason tends to clog up the system. If enough work items become blocked the whole process grinds to a halt. This has the effect of focusing the whole team and the wider organization on solving the problem, unblocking the item and restoring flow.

Contortionists: Kanban is great for improving workflow and minimizing the time cycle, but it also increases the process flexibility. If you’re looking for a methodology that can bend, not break, with the winds of change, then Kanban is for you. You’re going to have less waste from the process of running your project because you’re going to see it sooner and can trim what you don’t need. It also improves the delivery flow, so you get what you want from the project, faster.

Like any tool, Scrum and Kanban are neither perfect nor complete. They don’t tell you everything that you need to do, they just provide certain constraints & guidelines. For example, Scrum constrains you to have timeboxed iterations and cross-functional teams, and Kanban constrains you to use visible boards and limit the size of your queues. The trick of successful management is finding the right method for your team’s personality and then sticking to it through rain or shine. At Craft, it was important for us to facilitate both and guarantee you can seamlessly switch from one to the other.