You are part of a new project where you are developing a website for a construction material selling company. The project timeline looks like three months. You are asked to come up with your project plan and execution strategy. Which execution style do you choose to work on this project?
You have been working on an iPhone app project. The app allows users to trade in multiple stock exchanges using one id and maintain their portfolio across multiple exchanges. What is your style of execution for this project?
You are in between a project that’s supposed to finish in the next 30 days…but it won’t be. It has a four-month timeline and three months are gone already. Only 25 percent of the work is done. You realize that the project board and methodology you are following are not working out. How will you change your style of execution to bring the project back to amber at least?
You probably thought of using agile at least once in all the above examples. And maybe you also had thought of using scrum, Kanban, XP, Lean, etc. based on your experience. But in most of the cases in your product/project management, you would have decided to use a specific style, either as part of your experiment or as part of your experience. Mostly, it’d be based on your previous product management experiences and expertise in your environment.
But have you thought of how these different methodologies in agile itself make a significant difference in using them for a specific kind of project? Have you sought to know why one should use scrum over Kanban? Why continue to use one methodology even though the project is suffering and urges for an administrational strategy change?
In this article, we’ll learn why and how we decide to choose a certain style or methodology for execution. We’ll take the two most popular agile methods, — scrum and Kanban — learn their differences, and learn where and how they suit certain project/product management situations.
Before we dig in, let’s have an understanding of agile. As an adjective, agile means the ability to move quickly and easily. In terms of software development, we’ll defer to Wikipedia.
Wiki describes some key words of the agile methodology: early delivery, continual improvement, responding fast to change, self-organizing, and cross-functional teams.
These mirror the descriptions from the Agile Alliance, which founded it.
Well, Agile Alliance didn’t give any particular definition to the agile methodology and agile term itself, but they signed four rules and 12 principles that describe the totality of what agile development means. This implies that you are independent in defining your agile methodology provided these rules guide it.
Agile is a methodology that, when followed, helps you:
There is no single rule or set of definitions or processes to follow, hence:
Any process you define that allows you to follow the Agile Manifesto and can be guided by agile principles can be called an agile methodology.
We’re going to get into the nitty-gritty of what agile and Kanban are shortly. But if you already know the roles, principles, and practices of each and don’t feel like reading all of it again, here’s a summary table highlighting the high-level differences between the two:
| Scrum | Kanban | |
| Objective | Delivers shippable products following an iterative approach in a time-boxed fashion. Focuses on delivering value in each iteration. | Deliver shippable products in a continuous flow based on demand. Focuses on managing the flow of work and limiting waste. |
| Roles | Scrum has three roles: product owner, scrum master, and scrum team. | Kanban doesn’t require you to define any roles, rather it works with existing roles and hierarchy. |
| Cadence | Time-boxed sprints that increment the product after every sprint. | Continuous flow of work where next work is taken once the current completes. |
| Work in progress limits | There are no limits. Team members move work items to in-progress as they need/can. | Strictly limits and guides work-in-progress items at any given point in time. |
| Change adaption | Restricts adapting any changes during the sprint. Change adaptation is encouraged during sprint planning, i.e. any changes proposed during the sprint are taken up in the next sprint. | Due to its continuous flow nature, changes can be adapted any time the task is in progress or complete. |
| Prioritization | Follows a pull system but prioritizes and pulls items for a sprint only done in sprint planning. | Follows a pull system but any time the capacity is available, the next priority work is pulled. |
| Ceremonies | Strictly adheres to standard defined meetings and in the same sequence for every sprint starting from planning to review. | No strict ceremonies are defined but a need for adherence to implementing strong feedback loops. To achieve this, teams are independent of their own meetings. |
| Delivery timeframe | Delivery is in the form of release as decided by the organization or authority. May decide to release one sprint’s work to market, or club multiple sprints per the set objectives. | Delivery is continuous and purely on an on-demand basis. The product is shipped as and when it is completed. |
And if you indeed want to skip ahead past all the finer details within scrum and Kanban, you can skip ahead towards what we’ll cover towards the end of the article:
The two most popular agile frameworks among them are scrum and Kanban. Let’s talk about scrum first here.
First, there are two organizations run by the co-creators of scrum: Scrum Inc. and Scrum.org. Here’s the representation of the scrum process from Scrum.org:
As stated by the founders, scrum is a way to get work done as a team in small pieces at a time, with continuous experimentation and feedback loops along the way to learn and improve as you go. Scrum helps people and teams deliver value incrementally in a collaborative way. As an agile framework, scrum provides just enough structure for people and teams to integrate into how they work, while adding the right practices to optimize for their specific needs.
In sum, scrum is an agile framework that helps you finish the project work in an iterative and incremental improvisation manner. It defines certain roles, pillars, values, artifacts, and a process that helps teams collaborate and execute efficiently, delivering products and constantly adapting to change.
Scrum has three different roles, let’s talk about them briefly here: a product owner, a scrum master, and developers.
The product owner owns the product. This person has the sole responsibility of making the product successful. They speak with customers, gather their input, communicate with all the stakeholders, and ensure the product and its features generate the right value for the customers and targeted capital for the business. Think of a product owner as a director of any movie. They vision the product and drive the product towards that vision.
Developers (the scrum team) are the magicians, as I like to call them. Developers build the product and ship it to market. They plan their work as per prioritization and sprint goals, exhibit quality in the product’s every deliverable, deliver every definition of done in requirements, and collaborate, adapt, and execute the best to meet the sprint goal.
The scrum master is a scrum expert. This is the person who knows how to execute projects the scrum way. They bridge every gap between the product owner and developers. The scrum master is responsible for executing scrum processes (which we will discuss shortly) smoothly and ensuring the team reaches the goal every time.
We talked about the roles above. Let’s talk about the pillars and values of scrum now. There are three pillars and five values of scrum:
Scrum, being empirical in nature, needs the work to be transparent across the scrum team, as well as other stakeholders. There needs to be frequent inspection to detect any problems in the execution process. Finally, the environment should adapt to change and respond as quickly as possible.
And then there are five values — commitment, openness, focus, courage, and respect — which are self-explanatory. One should be practicing and following these values to ensure they maintain trust among those involved in scrum.
Now you know about scrum! Let’s talk about its core: the process.
The scrum process involves constant short runs. We call them sprints. Sprints are time-boxed runs that execute one after another without any gap between them. It’s recommended to run 2–4 week sprints. I recommend running a 2-week sprint, as it is short but enough to deliver a shippable product/increment.
Within every sprint, the scrum team will attend specific events/ceremonies and manage the artifacts while delivering the actual shippable product.
What are those four artifacts?
Product backlog: a list of features and functionalities that a product should have to add value to its end users/customers. The product owner is responsible for managing the product backlog and ensuring that it’s up-to-date and has every backlog item prioritized. This is one running document with a list of backlog items till the lifespan of the product.
User story: in agile, we call a deep description of a feature or functionality a user story. A user story clearly defines the feature, how the user will be using it, what is the completeness (definition of done) of the feature, and at what state it becomes acceptable to the user and shippable.
Sprint backlog: a set of backlog items from the product backlog to work on and deliver in the current sprint. The scrum team owns and manages this. It is a subset of the product backlog and the scrum team creates it at the beginning of every sprint by clearly defining its goal.
Release backlog/increment: a release backlog, as the name suggests, is a shippable product to customers. It’s a (kind of) draft release note, you could say, that’s refined further to share with customers and other stakeholders. A product owner decides if there’s a valuable shipment and whether or not to release it to customers. It could be a deliverable from one sprint or a product owner could club deliverables from multiple sprints.
There are different ceremonies within scrum. First, we have sprint planning. This is the meeting where the scrum team, product owner, scrum master, and any other required stakeholder sit together and create a sprint backlog.
After sprint planning, the scrum team jumps into execution, design, and implementation. There is a need to collaborate and unblock each other during the sprint. The scrum team meets daily along with the scrum master and product owner at a designated time for about 15 minutes. It’s also called a daily standup.
Celebrating the end of the sprint is the sprint review. The scrum team, along with the scrum master, presents the work done during the sprint and showcases the value incremented in the product after the current sprint.
The last one, the sprint retrospective, celebrates the end of the sprint. The scrum team and scrum master meet to discuss what went well during the sprint, what went wrong, what can be improved, and any concerns.
Scrum uses a variety of metrics to measure success.
First, we have team capacity. This is defined in terms of hours. Usually, it’s the number of resources multiplied by eight-hour working days. But it’s important to account for unforeseen activities or a planned leave by team members, etc. A good practice is considering 80 percent of team hours the sprint capacity.
Scrum doesn’t estimate tasks in terms of hours or days. Instead, we use what we call story points. It is simply a complexity that a user story can be.
Story point estimation helps know if it’s possible to complete a story that sprint or not.
A burndown chart is a visual representation used by stakeholders and scrum teams to measure the amount of work completed for a given period. It plots the actual hours burnt by the team and the amount of work to be completed.
Even though a burndown chart is likely the most popular graph for scrum teams and is very helpful in gauging progress, it lacks certain information as to what current work items are in progress or lagging. It’s also dependent on the data the scrum team enters and can lead to unrealistic expectations.
Lastly, we have team velocity. This is the number of story points the team can deliver in a sprint. It is the average of the last five sprints’ story points delivered by the scrum team.
Maybe the oldest agile methodology in use today, Kanban has its roots of evolution beginning from the 1940s when Toyota coined a system to improvise its production process and inventory management. Taiichi Ohno, a young industrial engineer, founded this system named Kanban.
Taiichi Ohno focused on something called waste. He explained waste in Toyota Manufacturing unit(s) as:
Taiichi decided to eliminate seven wastes, for which he defined Kanban as a system. Even if you apply these wastes in our software development, they are relevant with a different context and terminology.
Taiichi created a framework where he focused on solving two things:
With this, the Toyota Production System framework was formed. Every finished product was attached to a card and once the product was sold, the card was removed and returned to the production line. Production (supply) was only made based on demand and every material (used for production) was attached to a card (Kanban) signaling the demand.
As the item or material moved through the production line, the card was removed and would return to the operator. The operator was instructed to work on the new item only when the card reached them back. This maintained the supply for the demand across the value chain end-to-end till the external suppliers.
Within Kanban, there are four core principles:
Change is inevitable, but at the same time, a sudden change can cause irreversible damage to the system. Kanban accounts for this and doesn’t force you to change the way you are working today. It helps identify the issues you are facing in the current system and address them.
It is hard to deliver something big fast or immediately. But at the same time, delaying deliverables makes your executive group concerned and they may decide against the project due to cash burns they visualize.
Kanban follows an incremental delivery approach where every participant understands and delivers them progressively. They also work towards the improvisation of processes regularly in every increment.
You are part of a larger organization that doesn’t practice Kanban, but there is some system in place to deliver results. Kanban respects this and guides implementation and adaptation via its third principle.
You work towards building an environment that can adapt Kanban as a practice over a period of time. Kanban doesn’t force you to change any current practices. It doesn’t change any current roles people are playing in the organization. It doesn’t change responsibilities either. It’s gentle work towards improving current practices and removing inefficiencies without changing the organizational framework.
How would things be if everyone in your team is a leader? Kanban drives this behavior and encourages ownership with its fourth principle. Every team member has the freedom to take any action and justify it with strong reasoning.
Let’s talk about the six core practices of Kanban.
Kanban follows a practice where the entire project is drawn on a single visualization board, dividing each step/milestone/operation into columns:
The board works on a pull system, where each team member pulls the card from one column to another as per the state change of that particular work/task. This visualization allows everyone in the team to understand a task’s current state and know what it takes to complete it.
The primary focus of Kanban is to produce only for a need and limit waste. If more work items are in progress than the operators/workers capacity, that’s waste. Kanban restricts the work-in-progress tasks to the actual capacity or a defined threshold.
It is very important to implement a pull system. Defining the maximum number of cards (work items) per step (column in the board) allows team members to pull the next work item to the board only when there is room or capacity to take up the next work.
Kanban doesn’t talk about managing a team, people, or individual tasks. It restricts you to only managing the flow. This means tracking how smoothly the work items move from one state (column) to another toward the end deliverable.
When everyone in your team understands what to work on and align towards, it is much easier to accomplish together as a team. Kanban practice requires making every process and policy published. This helps in building a common understanding of a goal.
Without feedback, either from people or the system itself, how can you improve? And continuous improvement is one of the key agile principles. Kanban practice requires you to implement some feedback system to collect feedback periodically. When and how you collect feedback, Kanban doesn’t enforce any specific process. Instead, it allows you to define your feedback-collecting system per the nature of your project.
If everyone in the team understands the problem and swears towards resolving it, that’s the ideal team state — it’s possible to implement and adapt any process. Kanban enforces the common understanding of issues, goals, states, and accomplishments that helps teams collaborate and continuously improvise experimenting with proven scientific models, methods, and metrics.
Now that you learned about the principles and practices, let’s learn a bit about the Kanban cadences. I simply call them ceremonies just to celebrate. 🙂
This meeting happens daily for 15 minutes. Unlike other agile standups, the team focuses here on the flow of the board and discusses blockers, new learnings, etc. The team walks through the board and mentions any impediments to move the cards. The WIP items are specifically looked at in this meeting to see if limits are maintained.
This meeting happens on-demand (some teams follow it weekly or bi-weekly) for about 30 minutes to 1 hour. The team focuses on ensuring it has tasks as per capacity. The team walks through the priority cards and pulls them to the board up until capacity. The main goal is to have enough tasks on board and the team commits to delivering them.
This meeting happens on-demand, bi-weekly, or monthly for about 30 minutes. The teams evaluate their performance against the quality, speed, and other delivery metrics. The major goal here is to improve customer satisfaction with the product/service.
This meeting happens on-demand or monthly for 1–2 hours. All the managers come together to present their Kanban team’s performance and share findings. The participants discuss each of these concerns and develop new processes and policies to address them. The major goal here is to improvise flow at the organizational level.
This meeting happens monthly for about 1 hour. The team discusses the risks identified, the causes, and the mitigation.
This meeting happens quarterly. This is the most important meeting where the current strategy is revisited and modified based on the new market trends and customer demand changes. The outcome of this meeting is new guidelines, product ideas, or OKRs.
Think of this meeting as a release meeting. This meeting happens per delivery or release decision to market. The items or goods produced are reviewed against the acceptance standards and it’s decided whether or not to release them to the customer. The identified defects are further discussed in risk and operational review meetings. The goal is to release work to customers as soon as possible once it is ready after review.
Well, I never see a need to define specific roles as it defies the third principle. But, there are two very common roles defined today:
Also called a flow manager, the SDM is responsible for maintaining a smooth flow of work till delivery across all times. They are responsible for ensuring the seven Kanban cadences happen and the outcomes of those are constantly applied to the team and process.
Sometimes known as priority manager, the SRM is responsible for requesting work from the team based on priority and capacity. They are also responsible for reducing risk in systems that would affect deliveries and quality. They ensure the right order of work is pulled and requested from the team and ensure process excellency to avoid defects.
Kanban itself doesn’t mandate any of these roles and if you see the responsibilities above, it would look to you like the team member(s) from the Kanban team would play these secondary roles apart from working on their assigned cards.
Let’s discuss key metrics that help in gaining efficiency insights using Kanban.
The period from the initial work request till its delivery. Lead time tells you how long a work item will take for delivery, on average.
The time of work from start to finish. It doesn’t include the time waited from its initial request or the time waited for delivery after completion. Cycle time helps you to know the time needed to take a task to completion and improvise it.
Simply put, the total tasks completed for the given time. Throughput allows you to measure team performance/productivity. This is an important metric as it lets you decide on the production capacity and improvise it.
While we have talked in detail about scrum and Kanban, here we’ll list some key differences that make them significantly different from each other.
From the most significant differences between scrum and Kanban, there is one key differentiator that directly helps in choosing the right methodology for your project type. Unlike scrum, Kanban doesn’t give you roles or change your current working style.
Kanban puts you in a place where you start with your current style of doing things and improvise slowly towards optimality in your production and delivery. It doesn’t ask you to elevate suddenly into another process or system. For example, if you are following the waterfall model in your project management, scrum would require you to update your entire team set up and change it into three different roles.
Scrum would also update your entire requirement into a product backlog and defined sprint ceremonies, whereas Kanban says to do it the way you are currently executing. Kanban only creates a board with the right events that push an important step or milestone toward completion. You can call those steps a status, maybe in software projects, such as in planning, planned, in progress, done, delivered, etc. This itself makes a significant difference between Kanban and scrum.
On the other hand, Kanban needs a buy-in across the organization and every team working would need to follow Kanban. Otherwise, dependent teams would mess up processes and grow inefficient. Scrum can be implemented in one team while others can run their own process, even though they are integrating and dependent.
You cannot compare apples to pears. Some will even tell you that they both taste the same, but the same is not true. We have discussed both methodologies in detail and the key differences they inhibit above. If you have learned it correctly, you have the answer already.
Both are very powerful methodologies applicable in almost all projects. Just that, they behave differently, the arrangements are different and the way of execution differs. But, there can be certain types of projects where anyone of these is best. It depends mostly on these factors:
So, scrum or Kanban. Both are great and can be practiced in any kind of project, provided you know how efficiently they can be used to deliver.
Let’s list a few types of projects and define which method, scrum or Kanban, is best for them:
If you don’t have enough time to give a good background or base to start with, the best methodology here would be Kanban. Scrum requires an experienced team that can follow a strict sprint process. Scrum requires lots of planning and prioritization and, in this case, you do not have enough time for any such thing. Hence, adopt Kanban and elevate it to other processes if required in the future.
You have the option to structure your project and team well here. You can clearly derive the product backlog, priorities, and timeline to deliver it from the roadmap defined. Hence, choose scrum, as it best suits the right amount of experience and planning to execute the project.
This says that teams are independent in the organization and work has boundaries of execution. It’s best to choose scrum, as scrum can be trained and executed in only one team without any dependencies. Kanban would require the complete organization to practice Kanban and manage flows to deliver the end products.
Choose Kanban. This is important, as teams are dependent and have to work collaboratively. Kanban develops a flow between each of the teams and their WIP and delivery sequence. Hence, it creates the right structure to develop and deliver products.
Here, some might say scrum can do this since we have SAFe agile where scrums of scrums happen. It is not that it cannot, but based on easier adaptability for the environment and efficient run, you should choose Kanban.
Choose Kanban. Kanban provides flexibility in project changes focusing on managing the overall flow. These kinds of projects have varying priorities, unclear roadmaps, and underdeveloped plans to execute. You and your team will have to do lots of work on the process creation and application side itself to execute this project in a scrum way.
Well you can choose any method here, but I prefer scrum since you can divide projects into smaller milestones and deliver in a timely manner. If a project cannot keep time estimates and requires continuous delivery, choose Kanban.
If you doubt “what if I use the other methodology in the above project types,” that’s absolutely okay — provided that you know what you are doing and have a clear execution picture of how efficiently you can use one methodology over another in your project. This also involves you gauging upfront how well execution teams adapt the methodology and how well the overall environment will embrace the process to deliver value.
Scrum or Kanban (or any lean agile frameworks) are powerful tools for you to execute your project. The important thing is not to know which one to practice for your project, but rather to know how efficiently you can use the framework for your project. Many times, or most of the time, I have taken a hybrid approach in the building process for my products and have done well leveraging benefits from combining these frameworks.
Let’s conclude our discussion with an assignment. I request you to revisit the projects I mentioned in the beginning and reanswer your choice of framework/methodology to execute them. I will definitely read it if you comment and provide my opinion there. Please give your answers in the comments section below.
Signing off for now. Thank you!
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Rangarakesh Kanchamreddy shares how he helps standardize the product requirements process via templates, context-setting, and collaboration.
Outliers show you where your product is brittle, where your assumptions break, and where your next act might be hiding.
Michael Tuccinard discusses his efforts working with organizations to change perspectives and tactics around user experience.
Aislinn Wright talks about pillars that have shaped her product strategy, including open-mindedness and always asking why.
Learn more →
