Agile, Scrum, and Kanban: What the Heck Do These Words Really Mean?

When a software developer hears news about a “new JavaScript framework” or a “new IDE,” he doesn’t need to ask more questions to clarify what it’s about. But if he hears about a “new agile framework,” he will likely do the Homer-Simpsonian nodding, pretending that he knows what it’s about, but he will have one, and only one, question: What the heck does “agile framework” mean?
In the modern software development environment, we increasingly hear words like “agile,” “scrum,” and “kanban,” and they are often used improperly. In this article, I’ll try to explain and to clarify some of these terms.

Agile

If you want to be the smartass of the crowd, you should use the word “agile” in every other sentence when you are talking about the work process. It has a pretty wide range, does not obligate you to know much about the subject you are talking about, and it is a really nice adjective or adverb: “thinking agile,” “agile approach,” “according to agile principles.” But what does “agile” really mean?
“Agile” refers to “agile software development,” the approach to development that follows agile principles. But what the heck are “agile principles?” Take a look at the Agile Manifesto and at the 12 principles of agile, which lay the foundations of agile development. From the Manifesto:

Agile principles encourage continuous delivery of functioning software, close communication among teams, and high adaptability to changing needs. If you follow these values and principles in your work, you can say that you are working in an agile environment. So, agile software development is not a methodology, it is just a set of different methodologies, frameworks, and techniques that follow the same principles. It can be said that “agile” is a framework for thinking and making decisions.

But why is it so important to follow these principles in our work?
The Manifesto and principles are the result of searching for the best solutions that have evolved over the decades in response to the challenges of software development. Throughout the 70s, 80s, and 90s, different developers and teams all over the world had been experimenting with methods of working and approaches to problem solving, inventing different frameworks and techniques (such as scrum and Extreme Programming), and even coming to the same ideas in parallel. Finally, in February 2001, seventeen developers got together and found the common denominators for all these diverse ideas and experiences. That is how the manifesto was created.

Scrum

If you talk about “agile” methods without knowing what they mean, you may slip up and say things that will uncover you in front of the interlocutor who knows the subject: “Scrum and other agile methodologies.”
Scrum is not a methodology, though we’ve all heard it called such more often than the number of killings in Game of Thrones. Scrum won’t give an answer to every question, and it won’t provide you with the precise procedure for responding to every situation you face. And probably as a result of this incorrect interpretation, most scrum implementations are also wrong: Teams don’t get value. This results in probably the most foolish statement about scrum: “Scrum doesn’t work.”
What is scrum? The Scrum Guide defines scrum as:

So it’s a framework, and like any other framework it can be, and regularly is, used the wrong way. Using scrum effectively requires not merely adopting the structure set out by scrum, but having a deep understanding and appreciation for agile principles across the entire team.
Scrum consists of three roles: Product Owner, Scrum Master, and Development Team; four ceremonies: Planning Meeting, Daily Scrum, Sprint Review, and Sprint Retrospective; and three artifacts: Product Backlog, Sprint Backlog, and Product Increment. It is organized into regular time frames, which we call sprints. Sprints should last between one and four weeks.
The Product Owner, or PO, is responsible for guiding the project’s direction. As new tasks and features are determined, the PO adds them to the Product Backlog. A sprint starts with a Planning Meeting where the Development Team selects the tasks from the Product Backlog to work on and plans how they will be implemented. That is followed by development, during which the Dev Team uses the Sprint Backlog to track progress and meets for the Daily Scrum in order to synchronize activities and adjust the plan, if needed. The result of development should be a Product Increment, something that can be applied to the product and released immediately. At the end of the sprint, the Product Increment is presented to the Product Owner at the Sprint Review, where the product backlog is augmented if further changes are needed. Afterwards, the whole team attends the Sprint Retrospective (also known as the Pub Meeting) where they talk about the work process and how it can be improved.

That’s it in a few sentences, but if you need a detailed explanation of how scrum works, check out this articlewritten by your truly.
It is easy to learn and understand scrum, but it’s hard to adopt. There are many reasons this framework may or may not be a good fit for a project. It often requires a lot of changes, not only in everyday development, but also culturally. Scrum fits best with development of complex products, ones that last a long time and that include different kinds of specialists.
Why is scrum so popular, and why does it have an advantage over the traditional waterfall model? Simply put, because it delivers more value to a product and customers. With “heavyweight” methods such as waterfall, horror stories abound in which nobody sees anything of the project for months. With scrum, that is not possible.
Scrum is all about the value that is delivered to end users. If you really utilize scrum, you need to deliver something of value every sprint. The value can be measured, and the team is also forced to inspect impediments and adapt, with the goal of delivering more value in the next iteration.
In most software development we are not building a skyscraper; we don’t need to have the whole plan ready before we start, and stick to that plan until the end. We are developing software, and we have the ability to adapt to different situations and to change the product requirements during development. For a long time, many developers saw this as the eighth deadly sin, but from the product perspective it is a huge benefit for optimizing predictability and controlling risk. Scrum is developed around this ability, and its implementation gives a reliable and efficient way of dealing with necessary changes.
Many techniques are used in conjunction with scrum: planning poker, pair programming, test-driven development (TDD), behavior-driven development (BDD), and others. They are not really a part of scrum, but rather compatible techniques. One method often mentioned at the same time as scrum is kanban, and there is a lot of confusion about what these two things mean in relationship to each other.

Kanban

When you talk about scrum and kanban, one frequently asked question from the crowd will be, “Which is better, scrum or kanban?” And you won’t know what to answer because it’s like comparing apples and oranges, or asking, “Which is better, pancakes or beer?” Both are better.
Kanban is a simple method that aims for just-in-time delivery while not overloading the team members. It is similar to scrum in that the goal is to deliver maximum value at the end, but it is much more flexible than scrum.
Kanban was not invented by the software development community. In fact, it has its origins in manufacturing processes at Toyota, and it has wide usage in other spheres. There are no strict procedures that you should follow, and no strict way you should implement and use kanban; it is, rather, a set of principles and practices, and you can choose from these practices to suit your needs. But there is one most-often used implementation of kanban in software development that includes the usage of a kanban board, consisting of columns representing stages of work, and tasks.
Columns represent the state of a task in the development process. The simplest example consists of three columns: “To Do,” “In Progress,” and “Done.” So, tasks are added to “To Do,” moved to “In Progress” when development starts, and considered “Done” when moved to the last column. But of course, it could be more complex:

“Backlog” → “Defining Specification” → “Ready for Development” → “Development” → “Code Review” → “Testing” → “Deployed” (→ “No one really uses it” → “Completely Removed”).

Every column can have subcolumns; for example, “Development” can be divided into “Planning” and “Coding”; “Testing” can be divided into “Unit Testing” and “Integration Testing,” and so on. Columns might be dedicated to specialists, if appropriate. The team defines the columns and stages according to its needs. Per the “pull” philosophy, tasks should only enter the workflow when the demand for them is immediate.

The purpose of this board is to visualize the workflow, which is the first key practice in kanban. In fact, kanban can be done without a board at all! It could be a simple list of tasks in a Google sheet with different background colors indicating the state of the task, or it can be Gantt charts, diagrams, tables… It could even be a set of buckets in your office, where each one represents the state of the task, and where balls are used as tasks. Just visualise the workflow and provide transparency to the whole process.
Another important principle is to reduce the batch size of your efforts. Simplified, this means avoid multitasking. That can mean reducing the volume of tasks you work on at the same time. If you have three designers in a team, the team might set the maximum number of tasks in the “Designing” column to three.
Like scrum, kanban also sees the team as the most important figure in the process. But it doesn’t suggest roles as scrum does, and you may keep the existing roles to avoid making changes to your existing process. The same stands for continuous improvement: Kanban generally encourages you to learn and improve continuously, but does not prescribe a specific event just for that process, as does scrum’s Sprint Retrospective.

Which Should I Use?

Scrum and kanban are not mutually exclusive and not really comparable. In scrum, there are defined roles, while kanban says, “What the hell, keep your current roles and responsibilities.” Scrum will force you to change your way of working; kanban lets you start with your existing process. In scrum, a clear schedule for events is prescribed by the framework; in kanban you don’t have events. Yet, they have a lot of similarities: Both are value-centric, team members are respected as “bosses” of the system, and essentially, they have the same mission: To continuously eliminate waste and remove obstacles.
But the question, “What should I use in my particular project and with my particular team?” makes much more sense. Kanban doesn’t require so much of the process and cultural changes, and, in most cases, it will be easier to adopt than scrum. Scrum, on the other hand, offers significantly more structure to guide the process, which can eliminate a great deal of overhead as long as everyone is on the same page.
But the beauty of both is that neither is a strict set of rules. There is nothing stopping you from picking and choosing the best scrum elements for you, such as a daily meeting or review. And there is no reason you cannot incorporate a kanban board into scrum.
Scrum has proven to be a highly effective framework when the whole team understands it well. However, in my experience, I find it hard to work in scrum with some clients. The process and cultural changes required for proper scrum implementation can be too much (especially when dealing with someone who believes that he is making a new Google!). On the other hand, kanban is more flexible and doesn’t force people to change. Some authors also say that kanban is a good path to agility, and offers easier implementation of scrum. Others say that using scrum should lead to kanban at the end.
The truth is that every project is different, and there is no one-size-fits-all solution. As a project manager, it is up to you to determine what works best for your team.
This post originally appeared in the Toptal Engineering blog