Kanban vs Scrum: Understanding the Tools for Agile Success

Kanban vs Scrum: Understanding the Tools for Agile Success process.st/kanban-vs-scrum December 30, 2019

Oliver Peterson December 30, 2019

You’ll often hear the question: “Which is better? Kanban or Scrum?” or variations of this eternal deathmatch between two of the most well-established agile methodologies.

People are wasting energy fighting over which methodology trumps another. If you’re an agile organization, you should be placing principle above practice.

It makes a lot of sense to ask questions like “why might I want to use Kanban over Scrum?”, and there are a lot of differences between the two. But fundamentally, they are both agile methodologies, and the principle behind why you might want to use both can be in alignment.

You may even find they can work well together, as part of a unified strategy. You need to consider what approach will work best for your team.

1/14

My aim with this article is to approach the question of “Kanban vs Scrum” by clearly presenting both approaches in terms of when, how, and why you might choose to use either of them.

I’ll also talk about the capacity for overlapping Kanban and Scrum approaches, and how some additional tools like Process Street can factor into that equation.

Here’s a breakdown of how we’ll approach comparing “Kanban vs Scrum”: Let’s start with a basic primer on what it means to be agile.

Agile 101: What makes a team agile?

You can’t just adopt an “agile methodology” and expect to be agile. Your team needs to adopt an agile mentality.

This goes beyond simply the tools (“doing” agile); it’s about adopting the principles that will enable agile success (“being” agile).

Kanban and Scrum are both ways of “doing” agile.

You will sometimes see “agile” referred to on the same level as Kanban or Scrum, for example “Kanban vs Scrum vs Agile vs Waterfall”. This presentation of agile as an alternate approach like Kanban or Scrum can be misleading.

In reality, for all intents and purposes, Kanban and Scrum both fall under the umbrella of an agile approach. Beware of fake agile.

2/14

So what makes a team agile? To begin with, embracing agile principles and facilitating a workplace environment where individual team members are encouraged to develop their own agile values.

There will always be processes and procedures you can hand to your team, while telling them “go do agile”, but there are deeper characteristics that promote the right kind of habits that will lead to agile success.

Collaborative team environment Teamwork is the backbone of any agile approach. Your team must be successful in working together in a collaborative environment.

Non-agile teams typically offload specific tasks to individual team members and work, for the most part, in isolation. Perhaps they come together once a week and discuss progress.

This is not the way to do agile.

Successful agile teams work together, listen to each others’ feedback, and observe the work being done as a whole team unit. As the team collaborates on features together, higher transparency of work being done as well as a combined workforce of problem-solving means it is less likely that there will be an imbalance of work-started against workcompleted.

Paying close attention to feedback Feedback is crucial for agile success. Getting feedback is part of working with iterations – so teams can focus on getting a small feature or update working, and then obtain some valuable feedback about it.

Customers, testers, and even other developers should be given the chance to offer feedback at each iteration. Feedback is most valuable when taken in small doses, so there isn’t the risk of a large amount of work being done, then rendered useless or invalid by feedback.

Small, iterative steps where features are closely monitored, then tweaked based on close feedback, is one of the behaviors of successful agile teams.

Being robust and adaptive You can’t always predict the conditions of a project, agile or not. Some objects just can’t be overcome, and certain specifications are bound to change. But, the work has to be done.

The difference between agile and non-agile teams is that agile teams are adaptive in the face of any challenge.

Agile teams are explorative, and team members should be open to going beyond their area 3/14

of expertise. That doesn’t mean wading out of your depth; approaching a task or problem you have absolutely no idea about isn’t what agile is about. Sales managers shouldn’t be forced to perform the role of product owner, for example.

It’s more about defaulting to action, and not being afraid to deviate away from a set process.

If it’s clear you can add value to an existing process or work being done, then that should be encouraged.

Acting like an owner This value is sometimes defined as “being intrepid”, and it represents one of the most important elements of agile success.

It represents a workplace environment where individuals are on an equal playing field, where everyone strives to a standard of collective and individual ownership of work.

This means team members aren’t afraid to challenge one another, and there isn’t a filter on communication. Values like “telling it like it is” are held up in the interest of transparency and clear communication.

It’s not all about macho parading, though. Just as important is the skill of listening and acknowledging the input of all team members equally. Knowing when to concede; when to say “I don’t know”, and admit you were wrong about something. It also includes not being too prideful or embarrassed to ask for help.

4/14

All of this combines to result in teams that are highly self-organized and high performing, with a big focus on collective continuous improvement.

What is Kanban?

The term “kanban” (lowercase k) is a type of lean manufacturing system for communicating what, when, and how much of something is needed to be produced; this might include tools like Kanban boards and task cards. It’s a method for improving efficiency in manufacturing.

The name comes from Taiichi Ohno, an industrial engineer at Toyota in Japan during the early 1940s. Also spelled “kamban” in Japanese, it roughly translates to “billboard”, and was originally chosen to represent the “available capacity (to work)”.

This original production planning system was expanded upon by David J. Anderson chiefly in his 2010 book Kanban: Successful Evolutionary Change for Your Technology Business.

It was in Anderson’s work that the principle was first applied to software development. His methodology is often differentiated from the original Toyota method by capitalizing the “K” in “Kanban”.

Kanban is defined as a system for continuous improvement. Anderson takes care to make clear that Kanban alone is not simply a software development methodology; that rather, it is fundamentally a system for process improvement to be applied to existing software development processes.

Kanban is not a software development lifecycle methodology or an approach to project management. It requires that some process is already in place so that Kanban can be applied to incrementally change the underlying process. – David J. Anderson The type of Kanban I’ll be expanding upon is Anderson’s methodology, which has typically become associated with the use of visual Kanban boards and task cards, and widely applied as a method for software development and lean project management.

So, the key features of Anderson’s Kanban system are defined as: Using visual workflows Finishing what you started (and limiting WIP) Workflow management Focusing on the process Prioritizing feedback Continuous improvement The Kanban board

5/14

Kanban workflow Kanban is based on the principle of continuous improvement, where teams are supposed to be agile and ready to shift priorities based on constantly changing demands and requirements.

A big part of the Kanban workflow is the Kanban board – where work is organized in columns representing stages like “To Do”, “In Progress”, “Ready for Review”, and “Done”.

Importantly, Kanban encourages teams to customize this Kanban view to suit how your team works.

At Process Street, the content team uses a modified version of a Kanban board in Airtable to keep track of tasks. Our core columns are: Idea Inbox Upcoming Doing Reviewing Done Move

Kanban roles Kanban teams are more horizontal; there is less of a managerial focus, and everyone is encouraged to step up and own the board.

It’s common to see teams enlist “agile coaches”, but there is no single “Kanban Master” akin to the Scrum Master.

In short, it’s the joint responsibility of the whole team to make sure the tasks on the board are delivered.

Key metrics Kanban teams should focus on: Lead time Cycle time How much WIP at any given time

6/14

Source

Lead time is the time it takes from the time a work card is created, to the time it’s finished.

Cycle time is the time from when work is actually started, to when it’s finished.

Shortening cycle time can be a good indicator of a successful Kanban team.

Another metric to look at is how much work is ongoing at any given time. Given that Kanban is about reducing WIP, it may be pertinent to set caps on how many tasks can be active at any one time in a Kanban system.

Once these limits are reached, typically in a given column, it’ll become clear where the focus of work should be, and the team can swarm these items to get them moved to finished.

Be ready for change Kanban workflows are designed to shift and change constantly. Teams should realize this, and embrace the changing nature of Kanban workflows.

For example, new items are constantly being added based on need and context of the project, and existing tasks may get bottlenecked or removed for all manner of reasons.

Kanban, as an agile methodology, is all about being ready to adapt to changing requirements.

What is Scrum?

7/14

Scrum was first coined in the 1986 paper The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka. The name comes from the sport of rugby, intended to place importance on working together as a team in complex and competitive environments.

Originally, as the paper suggests, the focus was on product development in general, not just software development as the term has come to be widely associated.

What the paper proposed was that higher levels of performance are achieved when teams met the following criteria: Smaller, focused teams High levels of self-organization Objective-oriented, as opposed to task-oriented Teams are given capacity to design their own approach in order to reach shared objectives Two key roles in the Scrum methodology include the Scrum Master and the Product Owner.

8/14

Source

Scrum Master The Scrum Master is the one responsible for making sure the team is “being agile”, as well as following all of the policies and procedures that were agreed upon.

Key responsibilities of the Scrum Master include: Problem solving and removing obstacles in the way of the Scrum and “being agile” Overseeing and maintaining a healthy, productive work environment Facilitating good relations between the team and the product owner, as well as external stakeholders

Product Owner The Product Owner is the individual responsible for making sure the desired outcome of a product is in-line with the vision of the development team, and any other key requirements.

9/14

Their key responsibilities include: Making sure everyone on the team clearly understands the shared vision of the development team Making decisions based on task, feature, and product priority, in the best interest of maintaining a high value product, while minimizing output Determine whether or not work is satisfactory, in terms of product feature specifications Ensure the team and workflow is transparent

Differences between Kanban and Scrum Teamwork and roles Scrum: Scrum Teams are comprised of a Scrum Master, Product Owner, and Team Members.

Kanban: There are no set roles. The team is more horizontal, and responsibility is shared across the team. No-one is expected to be cross-functional.

Workflow and visualization Scrum: Work is organized in terms of tasks, often using a work board (Scrum board).

Categories might include: Started, For Review, and Done, and will reflect the different stages of a team’s specific workflow.

Kanban: Similar focus on different workflow states (Doing, Waiting, Done) with an additional focus on the amount of work-in-progress (WIP), which represents a key performance indicator for Kanban teams.

Cadence and planning Scrum: There is a clear schedule, with an emphasis on key milestones or “story points” for delivery of important features. There is a focus on iterative progress, where each iteration is clearly market by a working build.

Kanban: No hard schedule or definite number of iterations. However, Kanban teams do work iteratively; there is just less of an emphasis on a strict timetable for work completion.

Similarities between Kanban and Scrum A few immediate similarities that are worth recognizing between Kanban and Scrum include: 10/14

They are both good at breaking down large, complex tasks and processes into smaller, manageable tasks to be completed more efficiently.

They are both methods of continuous improvement, and by nature both prioritize process innovation, improvement and optimization.

They are both designed to be highly transparent and keep all members of the team in the loop with regards to work being done, as well as upcoming work.

Kanban: What’s it good for?

Kanban works really well if your team knows there will be a high number of incoming tasks (tickets, requests, or any kind of modular task) that vary in priority and size.

As opposed to Scrum, which depends on a more clearly defined (but still flexible) project scope, Kanban is better if the scope will be less clear, and there is a need to go with the flow.

In a nutshell, Kanban is great for finding a continuous balance between work and the capacity of the workers on the team, if that’s not something that’s immediately clear.

When to use Kanban Kanban is a method of continuous improvement. This implies there are existing processes to build upon. If you’re doing any kind of development at your team, and you want to figure out a way to tighten-up ship, Kanban might be for you.

Just remember, Kanban is great for keeping your whole team on the same page. Perhaps more than Scrum, it depends on a more self-organizing team, since there is no clear “Kanban Manager”.

Perhaps the most important factor of Kanban is work in progress (WIP). To be successful, the Kanban method requires that strict limits are placed on the amount of WIP ongoing at any given time, in any given column, and that no new work can enter a column that has hit this limit.

This is useful if you’re experiencing bottlenecks and want to try to figure out how to improve that situation, as it encourages individuals to swarm onto areas of overflowing WIP. The ultimate goal of Kanban is to improve your existing processes. Teams will use the Kanban board to guide discussion and changes to process, typically convening for regular meetings to discuss recent developments and analyze existing processes.

Scrum: What’s it good for?

11/14

Scrum is a process management approach that is wide-ranging; any business can adopt and benefit from it. Scrum is good at facilitating flexibility and allowing teams to respond to sudden, unexpected change.

It is also well-suited for improving transparency within teams, which in turn contributes to avoiding some of the pitfalls that arise in working environments where changing requirements are the norm.

When to use Scrum Any time there are requirements that are rapidly changing. For teams who are highly crossfunctional and self-organizing, Scrum works great, too.

Scrum depends on a more well-defined scope than Kanban, at least in the definition of specific project milestones. When it comes to project specifications, though, Scrum only requires a very low-level definition of requirements to function properly; teams who expect a high degree of change to process, product, and high-level requirements should consider Scrum.

Scrum process There are a number of processes relevant to the Scrum framework. They’re all designed to encourage team members to evaluate what’s working and what’s not – bringing together the whole team, as well as Product Owner and Scrum Master, and having an open conversation about the state of the project.

You can find some Scrum process templates below, all using custom built Process Street templates to streamline things for you.

Daily Scrum / standup meeting process Scrums often benefit from a daily standup meeting. They typically happen at the same time each day, and the team will typically review work that is completed during previous days, and subsequently plans the next 24 hours.

Click here to get the daily standup meeting checklist .

Sprint planning process Sprints are a way of dividing up time, typically 7, 14, or 30 days, during which work must be completed.

12/14

In this sprint planning template, the whole team should be involved to help set goals and objectives for the upcoming sprint.

At the end of each sprint, ideally one working software build should be produced.

Click here to get the sprint planning checklist.

Sprint retrospective process The counterpart to sprint planning, a sprint retrospective occurs at the end of a sprint.

During a sprint retro, the team reflects on what happened during the sprint; what went wrong, what worked, and what changes need to be made.

The main goal of a sprint retrospective is continuous improvement.

Click here to get the sprint retrospective checklist.

Kanban process For Kanban, the process is designed to facilitate continuous improvement. There are a certain set of principles that the Kanban method follows, designed to facilitate continuous improvement.

The four principles of Kanban are as follows: 1. Visualize workflows 2. Limit work in progress 3. Focus on flow (by reducing tedious manual tasks and time wasted between important work) 4. Continuous improvement Taking these four principles, and acknowledging that Kanban is at its heart a system for continuous improvement, you can use a template like this process for optimizing a process to augment your Kanban framework.

Using a BPM tool to be more agile Agility is only possible if your team is equipped to be flexible; you need to be able to selforganize and reorganize without too much reliance on a firm, unchanging central structure.

You can use a BPM tool like Process Street to improve agility in your team by allowing your team more autonomous control over their processes.

13/14

How? Well, Process Street is all about process management, as the name suggests. You can create rich, detailed checklists to clearly communicate all of your processes to your team.

So, create one checklist template with detailed instructions and clear information, and pass it on to the team to make sure everyone is on the same page.

You can also quickly and easily edit those processes on-the-fly, with our simple template editor tool. This is one of the biggest advantages of using a BPM software over a traditional paper office – processes are actually followed, scrutinized, and improved upon every day – because the power to do that lies in the hands of each and every person who uses the process – the true process owners.

14/14