Kanban VS Scrum - How to be Agile

I originally posted this on freeCodeCamp years ago. I think it's still a topic people want to learn about, so I've bumped it here and edited it to update it.

Scrum and Kanban are the two most popular project management techniques in business today. As a developer, I think it's important to understand these processes, as you will likely be heavily involved in them if you are part of a team. By understanding, we can stay focused on solving problems and not be too frightened by some buzzwords.

I'm a developer by trade, but my last job was in product management. I tried both of these methodologies to improve productivity and efficiency in delivering products and services in the best possible way. They also help organizations quickly adapt to changes in demand for their products/services.

What is Scrum?

Scrum is a project management methodology designed for cross-functional teams of less than 10 members working on complex projects. Its primary goal is to use the team member's various skills to create a solution/product for the customer/end-user.

The word Scrum is derived from the game of rugby where players of both teams interlock and try to gain possession of the ball as a functional unit.

Scrum runs on three major pillars, transparency, inspection and adaptation. This methodology is based on the premise that the customer/end-user could change their mind about what they want or there could be changes which a planned approach cannot deal with.

The project is usually started with what information is available. Afterwards, changes or tweaks can be made whenever necessary while tracking the developmental process.

The project is broken down into distinct actions called sprints that have to be completed within a fixed timeframe or iterations. The average duration for sprints is usually two weeks to a month.

Progress is tracked through daily scrums which are 15 minutes fixed stand up meetings. This encourages close interaction and communication between team members rather than the traditional sequential approach.

What is Kanban?

Kanban is a visual project management framework which was created from lean software development process and used in Agile project management. The word Kanban is a Japanese word meaning Billboard and was derived from the lean manufacturing methods pioneered by the vehicle manufacturer Toyota in Japan.

It visualizes the work process and progress through Kanban Boards. It's used for products/solutions that require continuous delivery and aims to balance demand with available capacity (Pull system) rather than push out products to the market (Push system).

The aim of using Kanban is to remove bottlenecks during the production process so that the project can flow smoothly and still be kept within budget. It's usually used in combination with other agile methodologies like Scrum.

History

The Evolution of Scrum

The Scrum methodology was first mentioned in a 1986 Harvard Business Review article 'The New New Product Development Game' by Hirotaka Takeuchi and Ikujiro Nonaka.

The authors described this process they initially called the holistic or rugby approach as a new developmental process that would increase the speed and flexibility with which commercial products were brought to the market. They saw it as "good at bringing about innovation continuously, incrementally and spirally".

1993 saw the initial use of this methodology by Jeff Sutherland along with John Scumniotales and Jeff Mckenna at Easel Corporation. Two years later Sutherland and Ken Schwaber co-presented a paper describing the Scrum methodology at the Object-Oriented Programming, Systems, Languages and Applications '95 (OOPSLA) conference in Austin, Texas.

Schwaber also wrote the first scrum text in 2001 along with Mike Beedle called Agile Software Development with Scrum. That same year saw the two authors along with Sutherland and 14 other experts on Scrum draft the Agile Manifesto in Utah which specified the principles, features and values of this methodology.

The Scrum Alliance was created in 2002 by Schwaber to provide a governing body for the Scrum methodology as well as formal certification through the CSM (Certified ScrumMaster) program. Schwaber later left the alliance in 2009 to set up Scrum.org which is in charge of the Professional Scrum Accreditation Series.

Since 2010, a document called the Scrum Guide has provided guidelines for the Scrum methodology and has been revised regularly, with the latest version released on November 2017.

Evolution of Kanban

Kanban started life as a manufacturing methodology promoted on the factory floors of Toyota by Taiichi Ohno, who is known as the father of the Toyota Production System.

Ohno was looking for a way to increase productivity and reduce inefficiencies during the car manufacturing process while avoiding making products that couldn't get sold and lost money for the company.

In a quest to get a solution, Ohno would stumble on it during a visit to a Tokyo supermarket in 1943. There, he noticed that the products on sale were only restocked when they were almost sold out according to customer demand instead of through regular supplies from the vendor. This ensured that the supermarket had very little excess inventory and ran efficiently.

Ohno would bring this technique to Toyota thought it would take 10 years for it to be fully operational. A big part of this process would be the communication system which made use of visual cards called Kanban that illustrated to the workers in each stage of the vehicle manufacturing process what needed to be done, and the materials needed, in clear terms.

It also adjusted the number of vehicles manufactured to the demand by the public instead of utilizing the full productive capacity. This process was also known as lean manufacturing or 'Just in Time' production.

This helped standardize the production process, removed inefficiencies, and made Toyota nimble and flexible by avoiding the accumulation of excess products that couldn't be sold. This was a problem American auto manufacturers were also having.

This turned Toyota into a global auto giant. After its adoption in the automotive industry, the Kanban philosophy spread all over the world and into different industries.

Kanban would become popular in service/knowledge industries due to the work of David J. Anderson. He was an admirer of the lean manufacturing process who applied a pull system of development influenced by Ohno's Kanban philosophy while working with a Microsoft XIT Sustaining Engineering group in 2004.

The next few years would see Anderson and some other colleagues shape the features and principles of the Kanban methodology. The Kanban methodology spread through management conferences and talks and more companies began to adopt it.

Anderson collated his experiences with Kanban in a book published in 2010 'Successful Evolutionary Change for your Technology Business' which is regarded as the most comprehensive definition of the Kanban methodology for Knowledge workers.

The Scrum Principles/Values

The Scrum project management methodology became part of the Agile development approaches which spread in the late 1990s and early 2000s. These were an effort to find a solution to the high failure rate in software development.

The Waterfall Development approach used primarily before this point in the software industry was rigid and inflexible. Product development had to follow rigidly laid-down procedures and documentation.

Scrum allowed software developers the flexibility and freedom to respond to changes in development. It also called for the involvement of the customer in the development process rather than being a bystander.

This methodology later spread to other industries. Scrum has become the most used agile project management methodology. Research indicates that it is in use in 66% of all projects incorporating agile development methods.

Scrum is easy to understand and follow as it avoids rigid instructions and procedures. With Scrum, organizations can do whatever is needed to get the project done, adapting to circumstances that might suddenly arise. This flexibility is one reason Eric Naiburg, marketing vice president at scrum.org, calls Scrum the opposite of a to-do list.

The breaking down of projects into sprints makes it suited for complex undertakings while the involvement of the customer in the development process enhances transparency.

The Agile Manifesto

The Agile Manifesto set out to address frustrations among software project developers in 2001 and came out with four principles. Today these principles are the bedrock of the Scrum project management philosophy and have spread beyond the software industry. They state that projects should value:

Individuals and interactions over processes and tools.
Working products/solutions over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

Scrum Best Practices

There are some best practices which underpin the Scrum methodology.
We are ensuring Customer Satisfaction through early and continuous product delivery.
Testing and incorporating product owner feedback daily.
Welcoming and responding to changing requirements even late in the development process.
We are working together with the customer on the development process.
We are providing the support and environment for motivated individuals to get the work done.
Emphasis on face to face communication within and to the team.
We are measuring progress through a working solution/product.
We are promoting development at a sustainable pace.
We are enhancing agility by devotion to technical excellence and good design.
Self-organizing teams being the best way to get the best architecture, requirements and designs.
Having regular reflections on improving effectiveness through sprint reviews and adjusting actions to suit such.
We are respecting the balance between the team members' professional and private lives to keep stress to a minimum.

Benefits of Scrum

The scrum methodology is the most widely used agile project management methodology for the following reasons.

Freedom of initiative: Professionals who love the freedom to take initiatives are in love with the scrum process due to its self-organizing ethos. This tends to boost team morale.

High-quality products/services: Products and services that are produced using the scrum process tend to be of a high quality due to the various iterations and improvements they have had to go through as well as customer involvement in the development.

Shorter delivery times: This is a result of the incremental development process which shortens the delivery time by 30%-40%. The involvement of the customer in the development is also a factor here.

Better return on investment: This is as a result of the shorter delivery times, better product/service quality and fewer defects as a result of continual feedback and the early testing.

Flexibility: Teams are able to react quickly to sudden changes in the market and reflect them in the product/service development.

Drawbacks of Scrum

Like everything else, the Scrum process does have its limitations. Here are some of them.

Need for expertise: Scrum requires professionals with expertise and training on the scrum methodology. This requires upfront investment by the organization.

Scope creep: The customer could request too many modifications on the product/project, which could turn out to be unnecessary.

Expensive: The need for high expertise during the scrum process as well as the constant events makes the scrum process expensive to operate

The Scrum Process

Scrum Teams

The process starts with the formation of a Scrum team to work on a pre-defined solution/project. These teams are usually self-organizing and cross-functional. According to Scrum principles, self-organizing teams are the best way to ensure optimal performance on a project as they can influence how the work will be accomplished rather than follow external directions.

Cross-functionality refers to the different competencies among the team members which enable the Scrum team to have all it requires to accomplish the project within and does away with the need for external help.

An ideal Scrum team shouldn't have more than 9 members to enhance the team spirit, closeness and effectiveness. It's also important that the team members are in the same physical location or are at least online constantly if they work remotely.

Scrum Teams deliver solutions in increments, incorporating the views of the product owner at each product's iteration. This ensures the constant availability of a functional product. There are 5 values or principles which every Scrum team should abide by in order to be effective.

Commitment: Working towards the team goals at every sprint.
Courage: Being able to do the right thing despite conflicts and challenges.
Focus: Concentrating on the team goals and the sprint backlog exclusively.
Openness: Being transparent with one another about the job and its challenges.
Respect: Respecting each and every team member.

Scrum Roles

There are three distinct roles in any Scrum team: the product owner, the Scrum Master, and the Development team.

Product owner: This person represents the customer in the Scrum team and has the responsibility of ensuring the team delivers the project/solution/product according to the customer' s/end user's specifications. They have to communicate the end user's product requirements as well as the customer's feedback at each product's iteration. They also manage the product backlog which identifies the features of the product to be worked on.

Scrum master: This individual ensures that the team follows the Scrum principles and guidelines. They ensure that whatever is needed for the project is made available and take care of any impediments obstructing it. They also facilitate team events and ensure proper communication.

Development team: This comprises the rest of the Scrum team. They have to work together to provide a product/project using their various competencies. They organize themselves and choose their own path in getting the product delivered.

Scrum Events

Communication is vital in the Scrum framework. This is enshrined in the five events or meetings where information about the development process is exchanged regularly.

Backlog refinement: The product owner regularly reviews the product backlog which refers to the list of product features, the work to be done, and the sequence of delivery. They make sure that the backlog is properly prepared in a way that communicates to team members what needs to be done at each sprint.

Sometimes, the order of work has to be modified due to customer feedback or reviews from the development team. The review of the backlog, which is done in between the conclusion of a sprint and before the start of a new one, prioritizes features based on factors like business value, risk and date the features are needed. This review usually delivers the content for the next sprint.

Sprint planning: This is done at the beginning of a sprint to plan what needs to be worked on by the Scrum team. The smaller parts which a project is broken down into are called sprints. They could last from a week to a month.

The sprint meeting, which usually lasts an average of four hours for a 2-week sprint, has the team choosing the backlog items that can be completed during the sprint, how it will be worked on, and the goal for the sprint. These are all included in a sprint backlog.

Daily scrum/stand up: This is a quick daily stand up meeting that lasts a maximum of 15 minutes. The previous day's work is reviewed and challenges are identified by the team as well as individual members.

An individual is tasked with getting solutions to any challenges identified and any uncompleted work from the previous day is highlighted by the Scrum master on the scrum board.

Detailed discussions aren't allowed during scrum meetings. The strategy to be used for the day's work is also agreed upon.

Sprint review: This meeting, which is held at the end of the sprint, is used to review the team's performance. Suppose the work for the day is completed. In that case, the product's iteration is demonstrated and then presented to the customer/end-user along with the sprint backlog containing the 'done' items for their feedback.

The product owner can also make adjustments to the product backlog at this point.

The recommended duration for the meeting is usually a maximum of four hours.

Sprint retrospective: This is an opportunity for the Scrum team to reflect on how effective they were and what could be improved upon for better productivity the next time.

Scrum Artifacts

This refers to the commonly used tools in the scrum process. These are three of them used to record the progress of the Scrum team as well as details of the project.

Product backlog: Is a list of work that has to be done on the project by the scrum team. It contains the product requirements, features to be worked on and bugs that have to be fixed. It's overseen by the product owner and serves as a guide to the team. It's usually reviewed before it makes it into the Sprint backlog.

Sprint backlog: The development team oversees this list, which refers to the list of product features from the product backlog that have to be worked on during the present sprint.

Team members sign up to handle tasks they can handle based on their competencies in the spirit of self-organization and commitment.

Sprint backlogs can be modified during a sprint but the end goal remains constant.

Product increments: This is the end result of the work completed during a sprint. It's usually added to the completed work from previous sprints.

This is usually according to what the Scrum Team defines and agrees as 'Done' status. Most times, this means the product is functional at an optimal level and ready to be delivered to the customer/end-user.

The Kanban Principles and Practices

A cartoon kanban board showing the four columns.

The Kanban Principles

Four core principles form the bedrock of a successful implementation of the Kanban methodology.

Start with the present system: Kanban methodology stresses the need to avoid a culture shock by introducing a new system overnight. Instead, it can be brought into an organization and applied alongside the existing techniques.

This makes Kanban easy to implement and non-disruptive. Changes can then be implemented at a speed that everyone is okay with within a long gestation period while information about the current workflow and its inefficiencies are collected and analyzed.

Make changes incrementally: The Kanban methodology emphasizes gradual and small changes to the status quo. This will enable more buy-in from the organizational members that will be affected by the process, reduce uncertainty and unease, and in turn enable the organization to be turned around for the better as the evidence from previous incremental changes is apparent.

Respect the current workflow processes and roles: The existing work process, functions, and those in charge of them are not done away with immediately when the Kanban methodology is implemented.

The team will decide what roles should be modified, what changes should be introduced, and the right time they should be done. This is to ease the organizational transition among the members and make the incremental changes acceptable among them.

Encourage leadership at every level: Kanban recognizes that leadership qualities can emerge from anybody no matter the level they are in an organization. This is why team members are encouraged to act when there is a need for changes or to kick off initiatives instead of waiting for superior or senior management to order them.

This principle fosters trust and continuous self-improvement (Kaizen) among the team members, helping them to reach their optimal performance levels which will boost organizational productivity in the long run.

Kanban Practices

In order for Kanban implementation to be effective, there are six Kanban practices which teams have to put into action.

Visualize the workflow process: This is the first step when using the Kanban methodology. The process used to deliver the products/services by the organization as well as its flow has to be illustrated on a Kanban board which could be physical or electronic.

Each step in the workflow is represented by a column on the board. The different work items are denoted by Kanban cards of different colours. A collection of related work items can be bunched together using Kanban swim lanes.

The main aim of these is for all parties to understand the functioning of the workflow process from the customer request to the final product/service delivery as well as improve communication and collaboration. With this, different areas of the work process can be tracked and analyzed to identify possible impediments which can be worked on.

Limit the work in progress (WIP): With Kanban, a manageable number of work items should be worked on at a time with a limit placed on the work in progress that can be handled. Work at hand should be completed before moving on to 'pull' in a new task.

Kanban discourages multitasking as it leads to wastage and inefficiencies. WIP limits in the column boards stress the importance of choosing the work the team has to do at the moment carefully as there is a limited capacity which has to be used efficiently.

Focus on the WIP also helps to reduce the cycle times (The duration from the customer request to the final delivery) for a particular product/service.

Manage the workflow: With the Kanban methodology, the various workflow stages and work progress in each of them are highlighted on the Kanban board.

Kanban emphasizes the management of the workflow process instead of the micromanagement of people with the main aim of its implementation being the smooth work process flow at optimal levels.

This enables the team to analyze the workflow process by measuring productivity/efficiency with metrics like cycle time and lead times. This makes it easier to spot any obstructions in the workflow process.

Most times, these obstructions are in the intermediate wait stages where the work has to change hands, but sometimes other factors like worker efficiency have a role to play.

Wherever they are present, adjustments are made in the work process to remove them and make the workflow better. This will enable the cycle times for the product or service to be reduced, ensuring faster turn around and the delivery of better value to the customers.

Communicate the process policies clearly: A big part of Kanban is the communication of policies and process rules on how work is conducted explicitly to all parties concerned so that there is a clear understanding of what is expected of each person. This help provides a standard against which performance can be measured and ensures quality consistency in the product/service delivered.

There have to be work process rules and guidelines for each column like who pulls what, entry and exit criteria for the column, when a task is done etc. which has to be visualized on the Kanban board. This keeps everyone with a visual reference in the organization as they work towards a common goal.

Get feedback regularly and implement it: Feedback is very important to the Kanban methodology. The review and analysis of the workflow stages on the Kanban board during daily stand up meetings are a good opportunity for this. Each of the different aspects of the workflow like delivery and operations should also be reviewed individually to track their progress.

Team members should also comment on their individual observations during the previous day. These daily meetings should be short and be straight to the point. Plans should be set in motion to work on all the feedback received. Getting all this feedback early in the process enables improvements to be made fast so as to improve cycle times and organizational productivity.

Always experiment and improve: The evolutionary change pattern of Kanban enables the use of the scientific investigation method which involves forming a theory, testing it and modifying it to be better.

The workflow process should be evaluated and improved upon continuously. New techniques can be introduced incrementally into the workflow process and observed, and then a decision should be made to keep or remove them depending on how much improvement they bring to the process through evaluating the metrics measurement.

Sometimes, these techniques just need some modification in order to perform optimally. Continuous improvement is the cornerstone of the Kanban methodology.

The Kanban Process

Kanban is a methodology that seeks to improve an organization's efficiency by applying visualization to the work process. It's based on the proven notion that the brain processes pictures more easily than words. With the visualization, areas of inefficiencies become apparent.

Kanban aims to improve the workflow process gradually and incrementally rather than quickly. This reduces the risk to the organization. It also aims to make the work process flow faster.

The Kanban Board

The Kanban board is the main tool for the visual representation of the workflow process. It enables clearer communication among all parties involved with the way information about the project/development process is highlighted through pictures.

Kanban boards can be in physical forms or in a digital/electronic form which is used for teams with remote members. The Kanban board usually comprises of three main columns:

To do: Tasks that haven't been started are listed here.
Doing: Tasks that are being worked on are listed here.
Done: This consists of tasks that have been completed.

Tasks are represented by colored sticky notes or cards. By representing the workflow process with pictures on the Kanban board, the efficiency of the workflow process can be measured, especially with the aid of specialized Kanban software.

Where efficiency is lower than expected, impediments can be traced and then dealt with. This enables higher production efficiency, shorter product cycle times, and improvements in product/service quality.

Benefits of Kanban

Kanban is quickly being adopted by organizations in different industries globally. Some of the reasons for this include the following.

Clear communication and transparency: The workflow visualization on the Kanban boards enables clear communication and lets everybody involved know what is expected of them. It's easy to track work progress which makes it easy to know what action is needed.
Spot impediments quickly: The overcrowding of some of the columns can easily highlight where the work process is being slowed down, thereby necessitating adjustments.
Flexibility: Kanban's ability to be Used in any system or industry and its philosophy of incremental change make it a darling among many organizations desirous of continuous efficiency improvements. It is usually combined with agile project management techniques to make them more effective.
Responsive to demand: Kanban enables capacity to be adjusted to match customer demands, avoiding unnecessary wastage and enabling quick response to changes. Focus and collaboration:** Limited work in progress forces teams to focus on WIP instead of multitasking, thereby enhancing productivity. Collaboration is also enhanced as organizational members help each other overcome challenges in discharging their tasks.

Drawbacks of Kanban

The Kanban methodology has its limitations:

Ill-suited for large projects: Kanban can be challenging to operate in a large-scale situation.
Misuse of Kanban board: The misuse or over-complication of the Kanban board can send the wrong signals about the workflow process which might result in costly mistakes.
Wild demand fluctuations: Irregular product demands could disrupt the Kanban methodology as wrong signals could be sent as a result.
Quality miscues: Kanban methodology drives down inventory levels to almost zero in a bid to reduce wastage. But when there's a quality issue with the final product or service, it could be difficult for the organization to react quickly as a result of the absence of an inventory buffer.

Similarities and Differences Between Scrum and Kanban

Scrum and Kanban are the most adopted productivity improvement tools globally but they are not really direct alternatives to each other like most people believe. They have some similarities but there are also differences between both of them.

Similarities

Both Scrum and Kanban are tools to improve productivity and efficiency as well as minimize wastage.

They are both based on the agile project management technique which emphasizes flexibility and ability to adapt to changes.

They also work on the 'pull' scheduling technique.

They both see improvements in product or service quality and delivery times are the cornerstone of both techniques.

They are both based on the self-organization ethos with team members taking their own initiatives and actions with every member being equal to each other and no orders coming externally.

Complex tasks are usually broken down into smaller, manageable parts.

Scrumban

In many organizations today, Scrum and Kanban are being used and combined in what is known as Scrumban. This was originally created for teams transitioning from Scrum to Kanban but has become a project management methodology in its own right. Under this methodology, the Scrum process is used but it's viewed through the lens of the Kanban improvement system.

A board similar to a Kanban board with coloured cards is used. Work is broken down into iterations. WIP limits are used here while team members choose the tasks they will work on since they are self-organizing.

On-demand planning is a feature of Scrumban. This is the application of planning techniques when new tasks are available rather than on a daily basis. Prioritization of tasks is done so that team members know what tasks are important.

Differences

There are many differences between Scrum and Kanban. This includes:

Definition: Scrum is a framework with specific rules and techniques while Kanban is a workflow visualization tool used alongside an existing system.

Training and management: Scrum requires a lot of education and training, as well as management and professionals with expertise. Kanban, on the other hand, can be easily understood by everybody which makes it cheaper to run and manage.

Change process: Kanban encourages incremental change and is suited for organizations with good, stable workflow structures while organizations that need wholesome change quickly should go for Scrum.

Usage: Kanban is usually used for smaller projects while Scrum is more beneficial for larger, more complex projects.

Roles: Scrum has three defined roles of scrum master, product owner and development teams. Kanban has no defined roles as every team member can take up available duties.

Duration: The Scrum process lasts for the duration of the project/development and is started again with a new undertaking while Kanban is a continuous effort as it is done with products/services that have to be continually delivered.

Teams: Scrum advocates cross-functional teams while specialized teams are the norm in Kanban.

New tasks/Iterations: In Scrum, new items cannot be added outside the preplanned tasks for the sprint, even when the team has the capacity for such additions. In Kanban, new tasks can be worked on as long as the capacity is available.

Ownership: The sprint backlog in the Scrum process is owned by one Scrum team while the Kanban board can be shared by as many teams possible.

Productivity measurement: Kanban measures productivity using a product's/services' cycle time while Scrum measures this using velocity through the sprints.

Team goals: In Scrum, teams focus on collaborating and completing a pre-defined task while Kanban teams are focused on setting goals and reducing the cycle times.

Conclusion

This article doesn't aim to prove which is better between Scrum and Kanban as they are both productivity tools aimed at boosting efficiency. Rather it is aimed at providing an understanding of both tools so that you can make a good decision if choosing between them or you can decide to go with both.

I personally prefer Kanban. But I think that's because a mentor of mine gave me a copy of 'Kanban: Successful Evolutionary Change for your Technology Business' which really helped me when I started needing to make my teams productive. It's definitely a book that should be in every office.

If you have any feedback or want to get in touch find me on Twitter @nialljoemaher or leave a message below.