Kanban Agile vs Scrum vs Kanban

Scrum and Kanban are different methodologies that embrace the Agile manifesto. These three words (Agile, Scrum and Kanban) share common values and principles and therefore can be confused as synonyms, but they are not. If you seek to improve the way you deliver value to customers, first you must understand the Agile mindset; and then decide to use Scrum, Kanban, or other techniques like eXtreme Programming and even Scrumban. Now that we have clarity how each of these three words are connected, let’s explore each of them separately…

Agile – Uncovering better ways to do “it” and helping others do “it”.

To explain Agile, we must rely on the Manifesto for Agile Software Development. It was introduced in 2001 as a natural consequence of the world embracing software in almost everything we do. This is the challenge but also the beauty of Agile, that it’s not a detailed program (or book) that explains step by step how to be Agile. Instead, it’s a short manifest that focuses on human behaviors as the key to producing great results.

Although we already provided a link to the Agile Manifesto, we must make sure that we actually read it carefully. Too often people talk about Agile, but have never read or understood the actual Agile Manifesto. It’s only 68 words to introduce the 4 values:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

There are 3 sections in the Manifesto… The first section is an honest realization that there might be “better ways of developing software”. Before software and Agile, we focused on tangible deliverables like building a house. In that world, the results were predictable, easy to envision and we could rely on a plan-driven approach like Waterfall to predict tasks associated with a project. Fast forward to a world where software is used in almost all functions, including software to design and track the work for building a house. The biggest difference is that software is NOT predictable. Therefore why continue to use a technique that was never intended for something like software?

The second section covers the 4 values. But before reading these we must read the third section that acts as a disclaimer to fully appreciate the format of the 4 values. By stating “while there is value in the items on the right, we value the items on the left more” the intent is to not completely disregard the concepts on the right, but to naturally embrace the concepts on the left as the new way to behave in an Agile way. Too many times I’ve heard someone say “In Agile we don’t document”, that is simply not true and the Agile Manifesto does not say that. Let’s explore the 4 values in detail.

“Individuals and interactions over processes and tools” simply promotes the fact that we are humans and should rely on human qualities to solve problems. The most important aspect in solving a problem is to first state the problem clearly and only then start solutioning. Instead of jumping directly into creating a ticket in a tool, or following an already established process, how about leveraging what humans (homo sapiens) do well as a specie… being wise (sapient) and thinking first. Once the thinking is done by interacting with other humans, then it is fine to leverage tools and processes to achieve a well-defined goal or problem. Don’t be passive aggressive and hide behind tools and processes, instead be human and include others in lively interactions.

“Working software over comprehensive documentation” is about setting a clear way to measure results in software. If you are asked to deliver a login page (software) to a customer, then the unit of measure is a login page (working software) for the customer actually use and confirm that it meets their needs. You can still produce a document (if it’s valuable and useful to achieve the goal), but the final result will only focus on the customer being able to use the working software.

One of my favorite techniques which also embraces the previous value is to conduct “shoulder checks”. Instead of formal approvals on documents that don’t fully represent the final product, software developers will instead do a “shoulder check” by inviting their customer to look over their shoulder at the software as it’s being developed. This can also be done virtually using a screen share, but the goal is to keep your customer involved, so that the final result has been accomplished in a partnership. This prevents from having surprises or misunderstandings that often happen when only looking at documents.

“Customer collaboration over contract negotiation” refers to building healthy relationships while respecting that contracts are in place. It’s ok to have contracts, but when a customer asks for something new (or changes their mind), the expected behavior is to engage the customer to fully understand their ask and then assess if there is a need to look at the contract. The opposite behavior to avoid in Agile, is to start with the contract, shut down the conversation and in most cases not even fully understand the customer.

“Responding to change over following a plan” is about stating the obvious, that change is part of the journey. The big difference in Agile is how we respond to change. In Waterfall we invest so much in upfront documentation to produce a plan, that change is seen as a mistake that requires a punishing change request process, as well as finding someone to blame for the change. In Agile, we have plans like the release plan (months), iteration plan (weeks) and the daily stand-up (today), but these are short cycles that can easily introduce a change in the next cycle. Also, requirements in Agile are in the form of small work items within a prioritized backlog. Instead of a massive document with multiple versions to track changes, a new work item can simply be added to the Agile backlog.

In addition to these 4 values, the Agile Manifesto also includes 12 principles that you can read in full details here. The 12 principles include: satisfy the customer, welcome change, deliver frequently, work as a team, motivate people, communicate face-to-face, measure working software, keep a sustainable pace, excel at quality, keep it simple, self-organize and reflect and adjust regularly.

Principles by definition are the foundation for behavior, but unlike values that are deeply held beliefs, principles are at play whether you believe in them or not. This is why we focused on the values and only mentioned the principles, but be sure to fully understand these 12 principles.

In conclusion, the Agile manifesto offers a simple, but extremely helpful way to adopt new powerful habits to drive positive behaviors. Now that we understand the Agile mindset, it’s time to explore two of the most popular Agile methodologies: Scrum and Kanban.

Scrum – The framework based on rugby and iterative development.

The origins of Scrum can be traced back to Hirotaka Takeuchi and Ikujiro Nonaka authors of “The New New Product Development Game” from the Harvard Business Review, January 1986. The quote below explains the connection to rugby, which is a team sport played around the world:

“The ‘relay race’ approach to product development may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.”

The image below shows a “scrum”, which represents a method of restarting play in rugby. Another key term that we will explain later in the context of the Scrum framework is a “sprint”, which is when a rugby player runs with the ball in short bursts to score a goal.

PierreSelim from Wikimedia Commons

When it comes to Scrum as an Agile methodology, there is an official Scrum Guide written and maintained by the co-creators of Scrum: Ken Schwaber and Jeff Sutherland. Since Scrum is a framework, it’s critical to not select only pieces, or invent new ones. To get the full benefits of Scrum, just stick to applying the full framework, which is illustrated in the image below from Scrum.org.

First, start with producing a Product Backlog that contains currently known work for your Scrum team. As shown in the image, the work items in the Product Backlog can be of different sizes, but the items to be taken next must be sized to fit in the length of a Sprint. A Sprint is a timebox that the Scrum team often chooses to set at two weeks, but should never be more than one month.

Now that the Scrum team has a clear list of upcoming work ready to deliver, the Sprint can start. There are 4 events within a sprint:

• Sprint Planning to plan work to include in the Sprint (Sprint Backlog)
• Daily Scrum set to last no more than 15 minutes for the Scrum team to plan their current day
• Sprint Review to present the end result of the Sprint
• Sprint Retrospective to conclude the Sprint by seeking ways to improve the Scrum team

There are also 3 roles in Scrum:

• Product Owner who owns the Product Backlog and is responsible for the success of the product
• Scrum Master who is a facilitator and master of Scrum responsible for the success of the team
• Development Team made of professionals who work collaboratively to deliver a product increment

Lastly, there are 3 artifacts:

• Product Backlog to represent a prioritized list of work items known for the product
• Sprint Backlog to represent only the work items selected for a Sprint
• Increment to represent the work items completed during a Sprint

The Scrum framework is ideal for complex work that requires a team of crossfunctional professionals who work very closely every day to solve this work. The concept of a Sprint permits the team to deliver small product increments to release to customers as soon as they are completed. To ensure the highest quality of work, the Scrum team must have a clear definition of “Done” to ensure that the work always meets that definition. Ultimately, Scrum is an empirical process that empowers Scrum team members to learn from their shared experience and keep getting better over time.

Before moving to Kanban, we must mention that Scrum teams usually visualize their sprint backlog on a task board… That board is actually a basic Kanban board.

Kanban – The visual way to increase efficiency.

The Kanban methodology was pioneered by Toyota through the leadership of Taiichi Ohno, who is known as the father of the Toyota Production System.

Toyota Production System (TPS) – source: toyota-global.com

Toyota Production System (TPS) – source: toyota-global.com

Although this methodology originated in the manufacturing world long before Agile and software was broadly used, it has been embraced as an Agile methodology. The concept of visualizing the ideal flow of work on a board that tracks work items as cards fully align with the values and principles from Agile. For example, it promotes transparency, simplicity and a sustainable pace of development.

As illustrated above, a Kanban card is meant to capture all the work on a single card with sections and signals to quickly see the work. By identifying key inputs, it helps the requester to provide exactly what is needed to successfully complete the work. Once the card is on the board, it flows through the ideal process represented by the board, to deliver that work. The process must be continuously improved by the team so that the cards keep flowing as efficiently as possible. Achieving “faster time to market” is the #1 reason why organizations choose to be Agile and this is where Kanban shines.

Below is a simple example of a Kanban board that represents a process to resolve problems.

Screenshot from Kanban Zone.

To understand what is Kanban, just like Agile and Scrum we must understand a few basic concepts, which this methodology captures as 5 properties…

“Visualize the workflow” by capturing all your work on cards and visually tracking these cards on a board that represents the ideal workflow. Learn more…

“Limit the Work-In-Progress (WIP)” by setting a maximum number of cards that should be worked on within the columns of the board that represent when this work is in progress. Learn more…

“Measure and manage the flow” by seeing bottlenecks on the board and leveraging Kanban metrics like the throughput and cycle time, so that the team can better understand their capacity and ideal flow of work. Learn more…

“Make the process explicit” by literally writing in each column of your board the exact definition of “Done” for that column before the card can be moved to the next column. Learn more…

“Improve collaboratively (using models and empirical evidence)” by empowering the team to base their decisions on the observable, so that it can create a culture of continuous improvement. Learn more…

With this method, there are no specific roles or events, just a board that the team uses as the main artifact to collaborate and hold everyone accountable. The significant advantage of Kanban is the simplicity. With a team of experts at the process represented on the board, this approach creates a continuous flow of work that the team keeps tweaking to always seek more efficiency.

Agile vs Scrum vs Kanban

To briefly illustrate Kanban Agile vs Scrum vs Kanban, here is a side by side comparison on the few concepts that can be compared. This is not meant to be a complete list, but instead to show that Kanban Agile is truly a mindset and that Scrum and Kanban are methods that embrace that mindset by providing a framework for teams to operate.

Agile has nothing prescriptive that a team must do or use. Scrum has a few components that constitute its framework, and Kanban is pretty much just a board that holds everything the team needs. It’s worth mentioning that Agile teams sometimes blend Agile methodologies, for example, Scrumban is a technique that teams embrace to get the best of both.

Don’t forget that before choosing between Scrum or Kanban, you must first decide if you want to be Agile. If the answer is yes, then make sure to embrace the Kanban Agile mindset by following the values and principles from the Agile Manifesto. Scrum and Kanban will provide the format for doing Agile, but being Agile is the key to improve the way we collaborate as humans.