Imagine this: You’re the facilities manager overseeing a factory where cars and trucks are built. There are hundreds, maybe thousands, of people working in a warehouse doing different jobs. Parts are shipped in and routed to their destinations. Workers on an assembly line, or automated machines, fit pieces into place. Quality experts check to ensure vehicles are built to spec. Production needs to move forward without delays or you have a major problem on your hands.
How do you make sure parts get where they need to at the right time? How do you know they’re being installed correctly? If a group of 10 people are installing tires on a sedan or SUV, how quickly can they do it and be ready for the next automobile rolling down the line?
“If they can only do one car an hour,” said Antony Quant, head of delivery at London-based work orchestration and observability platform Cutover, “then there’s no point sending them enough tires down the conveyor belt to fit 50 cars an hour because all that’s going to happen is you’re going to have what we call transient waste, whereby, basically, you’ve got a block — you’ve got a backlog.”
Kanban vs. Scrum
The same workflow dilemmas surface in software development, Quant told me. In some ways, the agile software development framework, whose manifesto was written by a team of 17 software leaders in Snowbird, Utah in 2001, emerged out of a need to bring efficiency to a process involving interdependent teams and tasks. Short cycles of product iteration guided by customer feedback, the theory goes, help these activities move forward seamlessly.
“We don’t have this team and that team, we are a squad,” Quant said. “One team might have more creative people in terms of, say, engineering and product design. Another might have more transactional people. The idea is to bring those skill sets together to make decisions quickly.”
There are two popular schools of thought as to how to do that in practice: kanban and scrum.
Kanban and Scrum, Defined
What Is Kanban?
Kanban, the Japanese word for signboard, was developed by industrial engineer Taiichi Ōno for Toyota in the 1940s. The system of cards to track factory production has since been adopted by software companies to manage their teams’ workflows. Boards organized in columns of task cards, often called user stories, are categorized based on their priority and completion status. Commonly, three principal categories — to-do (or backlog), in progress and done — lay the foundation for production.
What Is Scrum?
Scrum is a workflow framework that proceeds in one- to four-week iterations, or sprints, designed to accomplish business goals. Carried out by small teams, often fewer than 10 people, scrum is a loop-like, adaptive process characterized by regular meetings, such as daily stand-ups, planning sessions, sprint reviews and retrospectives. These rituals are intended to help teams learn from their results, make better decisions and improve their speed and efficiency over time.
Kanban vs. Scrum: How the Frameworks Differ In Practice
While both frameworks stem from agile philosophies, they operate differently. Scrum defines requirements and output based on time — the length of a sprint — while kanban follows more of a triage approach, allowing teams to swarm on high-priority tasks as they arise.
Another difference is how work gets prioritized. In kanban, teams typically address urgent matters first. Scrum ranks tasks based on estimates of their complexity and value to users.
“Kanban maximizes efficiency, where scrum maximizes value,” said Dawid Zimny, a product manager at London-based web agency NerdCow. So, in scrum, “if a task is twice as complex as another, but delivers five times the value, obviously, the higher priority will be that first task.”
“Kanban maximizes efficiency, where scrum maximizes value.”
Staffing is another area where the approaches diverge. On a scrum team, an agile coach and product owner ensure rituals are carried out and production stays on track. In kanban, the board is the arbiter of progress. Self-governing teams are responsible for moving through a backlog of items. While there is less week-to-week accountability with kanban, it is often much more affordable.
“If you have a small organization, say a startup with five employees. Are you going to hire a product owner, a scrum master and a project manager?” said Ryan Vice, CEO of web development company Vice Software, alluding to the potential hiring costs of scrum.
Perhaps the biggest difference is that kanban is primarily visual and tool-based, while scrum is linguistic and interpersonal. Software applications like Trello, Notion, JIRA, Miro, Confluence and Azure DevOps can produce boards tailored to both approaches, but in a kanban framework these boards function as the primary accountability measure. Without a scrum leader (we will be using this term in place of the more commonly used “scrum master” — see note on terminology for more detail) nudging a team toward their goals, the board becomes a benchmark of progress toward key milestones.
REVISITING TERMS LIKE ‘SCRUM MASTER’
Tips for Using Kanban
When to Use Kanban
- Mature teams with high levels of trust tend to do well with kanban because it is self-governing. It’s harder to apply when working with less experienced teams or outside agencies, who may be less reliable in updating a board or have limited access to it.
- Kanban can be instituted at a low cost with limited staff investment. Before a company achieves product-market fit, kanban can be effective to get a product quickly in front of customers and assess its potential.
- Companies with high turnover tend to do well with kanban because the board operates as a single source of truth, preserving historical knowledge that can otherwise be lost when team members leave.
- Kanban got its start in manufacturing and is industry agnostic. It works well for non-technical teams and companies in and outside the software industry.
- Need to respond immediately to critical issues? Kanban may be the way to go. It allows teams to triage high-priority tasks and recruit available individuals to tackle them.
Keep the Columns Simple
It can be tempting to create a kanban board with dozens of categories. But this is not only hard on the eyes — it’s a recipe for confusion. While product management software tools often offer layers upon layers of configurability options, Quant said it’s best to limit the board to no more than five categories. Creating too many columns, or overly specifying cards, can be a distraction from the end goal of expediency.
“The best ones are the most simple, literally: backlog, in progress and done,” he said. “Because people will say, ‘What’s this field?’ or ‘What’s that field?,’ and all that does is add to the white noise of the situation.”
“The best ones are the most simple, literally: backlog, in progress and done.”
Even still, it’s good practice to adapt the board to the needs of a particular team. For example, NerdCow’s product team uses five basic column descriptors: backlog items, in-progress tasks, internal testing and validation, items awaiting client approval and deployed features. In each column, Zimny told me, cards for high-priority items get placed at the top, moving to less urgent items farther down the list. Though not strictly by the book, some companies use a dedicated top-line row for incoming requests that need immediate attention.
“Where kanban is really great is that everybody, in theory, can swarm on something,” Quant said. “A classic software engineering example is a pull request. We swarm on it, somebody reviews it, says ‘It’s good,’ or says ‘It’s bad and needs to be refactored.’ It’s done.”
Set Realistic Workloads
In many ways, kanban is about making the most of a team’s time. But that doesn’t mean you can magically make more of it.
Joseph Misemer, director of customer engagement and principal scrum master at Atlanta-based software development firm HatchWorks, said one of kanban’s greatest assets — that it gives teams the flexibility to pivot quickly to respond to urgent tasks — can also be its Achilles’ heel, if not approached realistically.
“We can’t keep feeding high-priority issues onto the top of the board and not giving people time to close out active tickets,” Misemer said. “Sometimes it’s unavoidable. But we don’t want to say that everything that comes in is an unavoidable interruption to the previous thing because then nothing’s ever going to get done.”
Historical trends can help managers predict a team’s week-by-week capacity and set reasonable expectations. Typically, cards are assigned to individuals or paired team members or fielded somewhat autonomously. When a user clicks a card on the board, a dialog box will reveal a description of a user story or assignment brief. Date fields tied to a card’s length of time in a column can help managers track progress and, in some cases, identify where tasks need to be broken down or handled by multiple team members.
“Some companies use a ‘days in column’ metric.” Zimny said. “So, for example, you’ll see that something is in progress for three, four or five days. If that’s too long, maybe you need to devote more resources to a particular task.”
Groom the Board
Beware of a ballooning in-progress column. That can be a red flag that a team is too large or taking on too much work at once, ZiImny said. Limiting teams to fewer than 10 people, and having them work in pairs to complete tasks as quickly as possible can help reduce backlog.
Having a dedicated request manager to cull tasks that have been completed or are gathering dust can also help. The regular cadence of sprint cycles allows scrum teams to clean house every few weeks. But kanban is an infinitely accretive process and, without someone assigned to groom the board, it can become cluttered and visually cumbersome.
As a liaison between teams, a request manager can also address resource or communication gaps that prevent tasks from moving forward. One of the benefits of a kanban board, Misemer told me, is that it can be shared by teams across departments. This can add visibility to work that might otherwise operate in silos. But departments often have different goals and opinions about how various fields should be used and updated. Adding a human layer can help prevent misunderstandings and insulate a core team from pressures exerted from outside their department.
“We’ve always run kanban with somebody that’s roughly a scrum master,” Misemer said. “Blocks that might be removed with a daily standup can be flagged and cleared. With kanban, you still need to provide that shield from folks that are hassling the team in a way they’re not supposed to.”
Use Kanban for Non-Technical Teams
A non-technical team can apply kanban just as easily as a team of software engineers. Countless product management tools offer kanban templates, and little specialized knowledge is required to get acquainted with the interface, which is typically a drag-and-drop grid of cards.
A content team, for instance, might have categories for stages of the writing process: research, outline, quote requests, first draft, proofreading and so on, Zimny said. NerdCow’s content team, taking a somewhat different approach, uses kanban as a tool for strategic planning and a roadmap to execute their social media strategy.
“If we have blog articles or social media posts to publish, we can take a look at the board, see what needs to be posted to LinkedIn, for example, and take it to ‘in progress’ and then ‘done,’ as easy as that,” Zimny said.
Practice Responsible Stewardship
Ultimately, maintaining a smooth-flowing kanban board comes down to responsible stewardship. You don’t need to hire a scrum leader to implement kanban, you just need to set up a board and train team members how to properly notate fields and update their project status as work progresses. Because the structure of a kanban team is largely egalitarian and limited in managerial oversight, it’s also important for individuals to be disciplined in keeping up with the board, even if there’s not always someone looking over their shoulders to ensure that they are.
“That’s often challenging when it’s a new thing,” Zimny said. “You still have the same workflow, but it’s a new tool and it takes time for people to always remember to move work where it needs to go.” A gentle reminder from a manager, or a callout during a team meeting, can go a long way toward instilling a culture of conscientious self-governance.
Tips for Using Scrum
When to Use Scrum
- Companies that follow predictable development cycles tend to do well with scrum’s one- or two-week sprints.
- Development and product teams willing to engage in open, reflective conversations about what went well or poorly in a project are well suited for scrum, which seeks to continuously refine and improve the iterative process.
- If you value verbal communication over documentation, scrum is likely a good fit as knowledge is often transferred in rituals like daily stand-ups and sprint planning meetings.
- If you want developers to be at the center of the creative decision-making process and do more than just write code, scrum is the right way forward.
- Teams focused on continuously improving their speed are well suited for scrum.
- Mature companies with reliable funding and access to regular customer feedback are in a good position to adopt scrum.
Consider Your Size, Maturity and Resources
Applying scrum effectively is generally only feasible when companies have reached a certain stage of maturity, Vice said. This is due to the costs of staffing key roles — typically, a product owner, product manager and scrum leader. A Series B company that has several development teams and yields a million-plus in revenue is in a good position to adopt scrum, he said. A five-person startup? Not so much.
Moderately sized companies of roughly 50 employees that aren’t ready to invest in a full-time scrum leader to guide teams through sprint ceremonies might appoint a particularly organized, extroverted developer to the role, or have a product manager assume the responsibility. They might allocate 20 to 30 percent of their time to a two-week proof of concept, Quant said. But as a team’s capacity grows these individuals will likely need more support.
“As companies go from napkin to earned revenue, to funding, to later rounds, there’s an appropriate level of money you should invest to staff scrum teams.”
“As companies go from napkin to earned revenue, to funding, to later rounds, there’s an appropriate level of money you should invest to staff scrum teams,” Vice said. “A lot of times when you see folks debating about scrum and if it’s proper, they aren’t thinking about budget or outcomes.”
The percentage of a team’s budget that is reasonable to devote to staffing scrum can vary widely, Vice said, but it’s useful to consider economies of scale when allocating funds. The median base salary of a scrum leader in Chicago is $105,000, but a software development agency may be able to defray such costs by offering the service as part of project fee.
Delineate Roles
The best teams, Vice said, typically have a scrum leader, delivery manager or agile coach — roles that are somewhat synonymous — working across two to four development teams in a full-time capacity. The scrum leader runs ceremonies, leads daily stand-ups, conducts stakeholder demos, plans retrospectives, assigns tasks and determines a team’s capacity.
Scrum leaders, who can be certified through organizations such as the Project Management Institute and Scrum.org, should be coaches, not micromanagers, Vice said. If they are doing their job well, they should also help with interdepartmental diplomacy.
“The scrum [leader] is supposed to be the mediator between [a] product and dev team. So there’s supposed to be kind of this negotiation that goes on between, ‘This is what we need built’ and the dev team saying, ‘Well, that’s going to be too hard, if we do it that way. What if we do it this way,’” Vice said.
In theory, a scrum leader can remain impartial, helping voice the concerns of both teams, while working to build consensus.
Two other roles tend to be important to a well-functioning scrum team, Vice said: a product manager who functions as “a ticket-mover and number-watcher, keeping an eye on the budget and release schedule,” and a product owner, who serves as “the liaison between stakeholders and the scrum leader,” considering customer needs and communicating product requirements to the team.
Establish a Sprint Schedule
Sprint rituals are at the heart of scrum. They help give teams ownership of the development process and offer an opportunity to evaluate progress, address impediments to efficiency and pivot to satisfy customers’ needs, Misemer said.
Rituals may vary depending on the goals and preferences of individual teams, but an understanding of common formats is useful when assessing how to integrate them into your software development cycle. Here’s a look at HatchWorks’ model of common sprint rituals:
- Daily standup: A 15-minute daily meeting where team members discuss what they’ve just finished, what they’re doing that day and any obstacles they’re facing.
- Sprint planning: At the start of every sprint, the team meets to discuss what they will work on for the next one- to four-week cycle. Typically, items are pulled from a backlog, prioritized and assigned to the team.
- Backlog refinement: Several times during a sprint a product owner will introduce future user stories to the development team. Developers get to ask questions, make sure they have a good understanding of the technical guidelines and estimate the effort required. If there are gaps in understanding, a product owner can meet again with stakeholders to provide additional clarity.
- Sprint review: This may be an internal meeting where a scrum team presents the results of a sprint to a product owner, or an external meeting where a product owner reports to stakeholders. It is intended as recognition of the team’s accomplishments and a chance to discuss whether the team achieved its goals and what they can do to improve their velocity.
- Retrospective: Similar to a sprint review but more instructional, retrospectives are an opportunity for a scrum team to have a frank discussion about their successes and failures, with an eye toward replicating good practices and eliminating hang-ups.
Meetings, of course, take time. Ensuring they are productive and occur at a predictable cadence requires good organization and an evaluation of team availability, particularly if teams are in widely different time zones, Vice said. Settling on a consistent agenda may take time, but it’s important to make sure schedules line up or rituals can be carried out in asynchronous formats, like Slack.
Regularly postponed or canceled rituals can be a sign of a deeper problem — a lack of conviction among team members that the meetings hold value.
“Usually there’s an innocent explanation,” Quant said. “But sometimes people don’t get it. And then I would look to my scrum masters and have them talk to their teams and say, ‘OK, what’s happening? Are we in too many Zoom calls? Do we need to do asynchronous stand-ups? What can we do to reduce the time?’”
Clearly Define ‘Ready’ and ‘Done’
Misemer’s best piece of advice for scrum teams is this: “Make sure you don’t accept user stories you shouldn’t.” Teams can save a lot of time and hand-wringing, he told me, by agreeing on a “definition of ready” for all user stories. Often that means breaking a big idea into discrete components.
“If all I’ve got is a single sentence that says, ‘Do a thing,’ there’s a huge probability that I’m going to get it wrong,” Misemer said. “Then, I think it’s important for the scrum leader to stand up and say, ‘We’re not going to take in work that’s not ready,’” Misemer said.
Instead, user stories should articulate subtasks. A user who wants to browse hotel options on a reservation site, for instance, will likely go through a series of steps: searching listings, checking availability, comparing prices, reading reviews and so on. These should be spelled out in the story, so developers understand what the software should allow users to do.
“Make sure you don’t accept user stories you shouldn’t.”
The flip side of defining “ready” is defining “done.” Often this includes a description of the type of testing a product needs to undergo prior to its release and how it will later serve users.
“Scrum teams are supposed to be self-organizing,” Misemer said. “But starting from a blank piece of paper to come up with a ‘definition of done’ can be very difficult. You can forget important things. You can get hung up on things that aren’t important now, but might be important later.”
One way to define “done” is through a user journey map that looks beyond the scope of the sprint to show what a user may wish to do later in their experience with a product. A user may be browsing hotel options, but ultimately, they want to book a location that suits their family’s needs. Without providing clarity around the broader context, user stories can lead to code that is shippable by the end of the sprint, but doesn’t accommodate later capabilities.
Assess Your Team’s Speed
At its core, scrum is about speed. Some teams use a heuristic point system to assess task complexity and, by proxy, the team’s productive capacity.
“If the backlog is well organized, we can project out a few sprints,” Vice said. “You can get to where you say, ‘OK, this is a 30-point team’ or ‘This is a 50-point team.’ And then you’ve pointed out your items ahead, and you can kind of see what’s coming down the pike.”
Points are a relative tool and internally defined. For a development team, points typically relate to coding sophistication. A simple text change in a dialog box might be a one-pointer, an if-then statement might be a two-pointer and a five-pointer might be script for a full feature involving third-party data and web services. Anything above an eight-pointer, which tends to involve “substantial architecture changes,” is best broken up into tasks completed over multiple sprints, he said.
Points can be useful to assess a team’s velocity and anticipate the length of future projects. But they shouldn’t be used as a stand-in for hours worked. “If you ask someone on the team, ‘What is a two-pointer?’ And they say, ‘Oh, that’s four hours,’ in that case, points are not valuable, because you’re just tying teams to deadlines and making the math more complicated,” Vice said.
Instead, points should be used to assess an agile team’s velocity over time: Is the team getting faster from sprint to sprint? If they are, by how much? If they are stagnating or losing steam, scrum leaders and product owners should identify where the process is breaking down and reset expectations.
Prepare for a Cultural Shift
So, let’s say you’ve been operating under kanban for years. When, if ever, is the right time to make the shift to scrum?
“The inflection point is definitely when management wants to have more visibility into what’s going on,” Vice said. “The sales and marketing team want to know, ‘Hey, when can we get this?’” he continued. “Management wants to know, ‘How much is this stuff costing? How fast are things moving?’ There are a lot more of those kinds of questions that need to be answered. And so it’s valuable to spend the extra money to get answers.”
With sprint deadlines negotiated every week or two, scrum offers a fairly concrete picture of a team’s time-bounded progress and allows for long-term forecasting. Sprint reviews after each release serve as an added accountability measure. “What was our goal? Did we meet it? Did we not? Why not?” Quant said.
The interests of executives and investors, in other words, may trigger a need for greater consistency and predictability in a company’s release schedule. Scrum is well suited for this.
“The inflection point is definitely when management wants to have more visibility into what’s going on.”
But be ready for a cultural shift. Transitioning to scrum from kanban, or even a more traditional organizational structure, will likely require more regular communication with stakeholders and among and across teams. A developer used to hunkering down to write code, or a writer used to churning out marketing copy, will be less likely to work in isolated bubbles. For some, that’s a welcome change. For others, it may take getting used to.
At Cutover, lunch-and-learns, workshops, games and demos of collaborative whiteboarding tools help orient employers to the culture and practices of scrum. There are many ways to orient employees to scrum culture, which, at its root, is about embracing open conversations that give fair hearing to diverse perspectives.
“Typically, human beings like to be around like-minded people,” Quant said. “I’m a big fan of soccer. Quite a lot of my friends are big fans of soccer and other sports. That doesn’t mean to say that I don’t hang with people who don’t like soccer. But I think it’s sometimes the same in a work capacity. People get used to working with people in similar roles.”
With scrum, that mindset will need to change.
