Agile, Scrum, Kanban – How did they meet?

There is a lot of talk about Agile when discussing projects and what methodology is used in managing them. A 2017 study by Project Management Institute (PMI) indicates that 71% of organizations use Agile approaches on their projects sometimes, or more frequently than in the past. Organizations say they ‘are/do/use Agile.’ And in more cases than not, they say they are Agile because they use Scrum. And somewhere someone brings up Kanban and everyone nods knowingly.

When I was first introduced to Agile, it was explained to me in the context of Scrum. The words Agile, Scrum, and Kanban were used a lot, and I wasn’t clear how all these things connected or if they connected at all? At first, I felt this ‘Agile’ thing was just another flavor of the month and would go away until I learned it had been formalized with the Agile Manifesto in 2001! So rather than being the flavor of the month, I realized it was actually picking up momentum.

Once I decided to get onboard the Agile train, I sought to clarify for myself what Agile, Scrum, and Kanban are and what they have to do with each other. Having the organized mind of a programmer, I thought that first there was Agile, then came Scrum, followed by Kanban. Imagine my surprise, and confusion, when I discovered that Scrum was introduced in 1986! And that Kanban surfaced in the 1940s and is not even mentioned in the official Scrum Guide!

As I have learned more about Agile, Scrum, and Kanban, I have really had to resist the urge to rearrange them to say that first came Kanban, followed by Scrum, and ‘completed’ by Agile. Instead, I have come to appreciate that for once. We have new ideas that dusted off previously developed solutions rather than trying to invent yet another, ‘better’ mousetrap.

Based on my own experience, and the confusion and frustration that I experienced for a great length of time, I like to explain Agile, Scrum, and Kanban together because they are invariably talked about together. But I also want to start from the tool, describe the process, and end with the methodology.

Five key features of Kanban Board

In a very short explanation, Kanban (Japanese for ‘Billboard, Sign’) is a visual board developed to manage work and inventory at every stage at maximum efficiency. That’s it.

It is a tool that allows you to physically see the work to be done, work being done, and work that has been completed.
In practice, the team assigned to a particular Kanban Board are the people who know the work the best and agree on when what, and who works on an item, and the work items are moved from the to-do to in-progress and to completed columns as the work progresses.
A critical part of using a Kanban Board is that the team meets in front of the board at regular intervals.
The purpose of these stand-up meetings is to identify if there are hold-ups, issues, or bottlenecks that are preventing a work item from being completed or started. They brainstorm together how to resolve the problems and how to prevent them in the future.
The beauty of a Kanban board is how visual it is – completed items are in the completed column, and in-progress items that have no issues can be reviewed very quickly.

While I have identified Kanban as a tool in this article, I must point out that it is the Kanban Board, which is the tool. Kanban as a whole comprises of processes, and expected behaviors, that enable the success of using a Kanban Board.

10 facts about Scrum

To start off, Scrum is not an acronym of anything and can be written with a leading capital, or if you want, no capitalization!
Scrum is a formation in the game of Rugby where the whole team huddles and moves together as a mass to move the ball from one end of the field to another. So, without getting into the details of Rugby, ‘scrum’ as a word represents a huddle of people working toward the same goal.
Scrum, as it is understood in project management, is a framework that defines roles, artifacts, events, and sequence of those events to be used in getting work done by a team.
The Scrum Framework is free for all to use, but unfortunately, not enough people read the 19-page Scrum Guide that explains the framework.
The guide is being kept up-to-date and relevant and contains an incredible amount of thought and detail in its 19 pages.
You cannot just ‘read’ the Scrum Guide. You must study it and actively discuss it with your team because only by thinking through every paragraph will you understand all the pieces of the framework.
While I could go into lots of detail about Scrum, for this article, I will only highlight the fact that Scrum is intended to implement transparency, inspection, and adaptation into the work processes. And this is where Scrum met Kanban!
The to-do work is identified as a ‘backlog’ in Scrum and should be accessible to the team who is expected to work on it. To provide true transparency and visibility to the work being done, a Kanban Board makes sense even though no specific backlog format is indicated in the Scrum Guide.
And while it could be argued that with today’s proliferation of virtual Kanban Boards, the visibility is limited to only those with system access, it is important to remember that only those whose work is on a specific Kanban Board need to have access to it.
Scrum prescribes regular stand-up meetings to discuss the work being done, providing an opportunity to ‘inspect’ the processes within and outside the project team. These findings are summarized in a retrospective review where solutions to prevent issues in the future are brainstormed and then ‘adapted’ in the next work cycle.

10 facts about the Agile Method

I think of Agile as a mindset of the organization and its people and how they get the work done.
It is focused on delivering value to customers without spending time on non-value add internal work products.
Each organization has its own belief of what is value-add and what is non-value add, but the Agile mindset challenges you to justify your belief and not just accept it as ‘this is how it has always been.’
Agile Manifesto and the resulting formalization of Agile Methodology was developed by a group of people in the software development space.
The values and principles are addressing issues experienced in that industry but are by no means exclusive to it.
But by being a relatively new industry, with ever-changing technology, product delivery issues were easily visible and magnified. Projects were consistently late and, in the end, did not deliver what was needed. The Agile Methodology focuses on the fast discovery and fast delivery of the right product.
Traditionally work has been completed through managers who tell their subordinates what to do, when to do it, and in many cases how to do it. While this structure can continue to exist, a key difference with approaching work with the Agile mindset is that the work team does not have hierarchical roles and they decide as a team the what, when, and how the work is done.
And this is where Agile met Kanban – the decision-making right is given to those closest to the work, and the work is visible to all.
But moving the decision making from the managers to the sub-ordinates is not easy and abandoning all forms of project management is not wise.
This is where Agile met Scrum – which provides a structure with its roles, artifacts, events, and schedule for the team. And visibility to the work for the management.

But no tools or processes will make the organization Agile if the values and principles described in the Agile Manifesto are not adapted and embraced by the organization. Like with Scrum, I do have a lot of thoughts about Agile, but for this article, I will sum up an Agile Mindset with one word: Trust! Trust your people to identify issues and to solve them. Trust your people to know how to do their job and seek help when they need it. Trust your people to do the right thing for your organization and your customers. Trust allows people to speak up and present their ideas and respect for each other. If your organization has a strong sense of trust, you are already on the verge of Agile – just let them run with it!

Written by:

Outi Cornette
Agile Coach, Planstreet Inc.
January 13, 2020