If you are in the world of software development you may have heard of something called Kanban method. In this article we are going to talk about this method of task management to see what it is and so that you can evaluate whether to introduce it in the modus operandi of your business.

The first thing to say about Kanban is that it is a very popular agile development methodology used in a large number of software companies. I am not going to go into its origins (in many places you can get information about it), and I am going to focus on what it pursues and how it works.

Basically, Kanban is a way of working and distributing tasks to a team, making sure that they arrive in the right measures and avoiding overlapping or bottlenecks. 

Put like that, you probably didn't understand much. Even a purist who knows what Kanban is all about will have raised an eyebrow. We will see later how this sentence makes sense.

PRINCIPLES OF THE KANBAN METHOD

Let's talk first about the basic principles of this methodology: 

START WITH WHAT YOU DO NOW

This means that starting to work with Kanban does not mean that you have to start from scratch or reconfigure the way you perform a task. Kanban will help us to get organized, but it is not intended to interfere too much in how we perform our duties today.

COMMIT TO PURSUE INCREMENTAL AND EVOLUTIONARY CHANGES

The idea is to work on iterations in which we improve/change little by little what we are developing. Kanban is against drastic changes, as they have a higher failure rate than incremental and evolutionary changes.

RESPECTS THE CURRENT PROCESS, INCLUDING ROLES, RESPONSIBILITIES, AND POSITIONS

Kanban tries to be respectful of the organization and does not require you to change the organization, the position of its members, or their responsibilities.

ENCOURAGES LEADERSHIP AT ALL LEVELS

Kanban is about every member of the team (from the most senior member to the last intern) taking leadership, encouraging everyone to contribute ideas, recommendations, self-training and any other type of activity that is positive for the project's future.

The idea is that you don't just do what you're told to do, but take it a step further and also focus on what's best for the company as a whole.

HOW KANBAN WORKS

Ok, one thing is how Kanban works in an industrial process and another thing is how it works on a day-to-day basis in a development team. 

Regarding the day-to-day, I would dare to say that each company adapts the Kanban board to its usual modus operandi. This is neither bad nor good, it is simply that the pure Kanban, the industrial one, is too complex for the structure of an SME, so the complexity of this methodology is usually lowered somewhat. If you have noticed the principles of Kanban, one of them was about the fact that the current structures and roles of the company are respected. This invites us not to make a big effort to adapt to this methodology.

So, let's talk about how Kanban could work in a software development company. Here I have included some elements that will remind you of Scrum, but that I think help us to work better with Kanban. 

---

Then, for the more curious, I will explain a bit about how “complex” Kanban works, but without going into all its details.

---

STEP 1. WE MEET TO CREATE THE REQUIREMENTS LIST

The project manager, together with the customer, will be in charge of listing everything they need to be included in the product. These requirements will be given in the same way we usually deal with requirements, Kanban does not force you to document them in any specific way.

---

If I may, I would give the requirements in the form of user stories (Scrum) or with assumptions and hypotheses (Lean Startup). 

---

Once we have the list, we will have to prioritize it, assuming which tasks are the first to be developed (by logic or by risk).

STEP 2. CREATE AN EMPTY KANBAN BOARD (OR SEVERAL)

Now we are going to create a Kanban board. This board will have a series of columns that will specify the status of each task we are going to enter. Depending on how you work, the columns could define different statuses. For example, a very basic Kanban would be the classic three-column Kanban:

• ToDo: tasks to be addressed.
• DoingThe following are some of the tasks that are currently being performed.
• Donetasks that we have already completed.

But your usual workflow may require more states, so your dashboard could include them as long as they are sequential, i.e., a task needs to go from one state to another until it reaches its state of completed.

In my case, I would put five columns:

1. StoriesThese are the tasks. Here they are accumulated before entering ToDo. Why not put them directly into the ToDo? Because it may not be the right time, as one task may depend on another, or because we do not want to clutter the column. ToDo.
2. ToDo: tasks to be addressed.
3. DoingThe following are some of the tasks that are currently being performed.
4. Testing: tasks being tested by the quality team.
5. Done: tasks that we have already completed and tested.

The priority of the tasks will be defined by the order in which we place them. A task placed on top of another will be more important and we should try to tackle it first.

We can also use colors in the tasks to identify their difficulty (or their estimated duration, if it is something we are clear about).

If we have a multidisciplinary team, there can be more than one canvas board. For example, if we have a software development team and a design team, each can have its own dashboard, or new columns can be included in the current dashboard to reflect all the actions we are going to perform on each task.

STEP 3. STORIES COLUMN

We put in the column Stories those tasks/requirements we had agreed upon in step one.

STEP 4. DETERMINE LIMITS OF WORK IN PROGRESS 

Depending on the resources we have available, we will limit the number of tasks that can be in each column. For example, if we have two developers, we may not want to have more than 4 tasks in the column ToDo. However, if we have six people in the quality control department, then we can let the limit of the column be the same. Testing is higher.

Here it is usually good to set limits that are higher than the number of people who are in charge of the task. Imagine that a task, for whatever reason, blocks us. This way we could always leave it in place and take another one, avoiding running out of work. 

STEP 5. FILL IN THE ALL COLUMN

Fill in the column ToDo with the requirements that we consider that can already be addressed (those that we want to be developed immediately), taking into account the limits that we had agreed in step three.

Here we must also document which tasks we have put in ToDo and the exact date and time we did it.

Immediately afterwards, we meet with the team and explain each task on the ToDo list, allowing for as many questions as necessary to clarify each requirement.

STEP 6. WE START WORKING ON TASKS

Each team member starts working in a chain. Tasks will be passed from the ToDo at Doing, then to the Testing and finally to the Done (assuming we have not included more columns in between).

STEP 7. DAILY MEETING

Every day we have, first thing in the morning, a 15 or 30 minute meeting where each member of the team gives the following information:

• What he did yesterday.
• What you plan to do today.
• What problems you have encountered.

The purpose of this is none other than to be able to act quickly in the event that a team member is impaired or late.

STEP 8. REFLECT WHEN WE HAVE FINISHED A TASK

Every time someone finishes a task, he/she leaves the date and time in some document. This is called Lead Time, This will help us to know how much each task costs us.

In addition, you should alert the project manager to ensure that there are always tasks in the ToDo column and no one is standing still.

STEP 9.

We continue working (we repeat from section six) until it is time to deliver to the client. Once it is done, the project managers meet with the client and draw conclusions about the client's satisfaction. This will help us to improve the process.

As you can see, Kanban, which is really the board, more than a methodology, is a method that allows us to manage tasks progressively, preventing work from accumulating or missing. 

---

Some of you may have noticed that the Kanban board can be used for anything from a software project to personal tasks. Indeed, in fact, we already use similar systems in our day-to-day work, only somewhat more simplified. 

---

THE ADVANTAGES OF USING KANBAN

After all that we have seen, we can list some of the advantages you would get from working with kanban boards.

1. Excessive production is avoided. The boards force us to keep an optimal production rate, as we try to avoid bottlenecks and lack of work.
2. Less time needs to be spent on planning.
3. It gives us greater flexibility, since we are working on a stock of tasks or requirements little by little, module by module, which allows these requirements to mutate or evolve.
4. It is clearer what each team member is doing and how we are doing in the project.
5. Increases team involvement.

CONCLUSIONS

These conclusions are totally subjective and personal. From my point of view, the Kanban board works well for iterative processes that are not excessively complex. For example, for the maintenance of your service. 

It can be used in developments of all kinds of scope, of course, but it requires the project manager to do a great job in creating the tasks and their assignments. 

My personal way of improving it is, as you may have seen before, to mix it with Scrum, but if the project is too large or complex, I would opt for using a Gantt chart before using a Kanban.

But come on, it's a great tool. The only thing I say is that it is not mandatory to use it if the type of project is not the right one. 

---

TOOLS WITH WHICH I CAN MAKE A KANBAN BOARD

There are a multitude of tools with which you can set up your own Kanban, they don't even need to be specialized. A Googledocs spreadsheet will do. You just have to put the right columns and fill the cells with states or colors.

However, if you want something more targeted, I can think of several alternatives:

• TrelloThe most famous and one of the few that has a free plan.
• KambanizeSpecialized in Kanban but for a fee.
• ZenhubPayment.
• MondayIt is not specific for Kanban but it is so extremely versatile that it could be used for almost anything, including creating Kanban boards. The downside: it's paid.
• AirtableKanban: it is not specific for Kanban but its column-based system allows you to create boards very easily. Moreover, with the free plan you can pull it off perfectly well.

WHAT ABOUT «INDUSTRIAL» KANBAN?

Okay, and this is for the curious: how does the Kanban structure really work when used in an industrial environment with its original approach?

I will explain it briefly. I am not as familiar with it as I would like to be, so I will not go into detail. 

In the following image you will be able to see the cycle of meetings in Kanban, or what is usually called cadences.

REPLENISHMENT MEETING

It is held every week. The purpose of this meeting is to set priorities and select which tasks to tackle next. This is where we would put the task in the Stories column.

DAILY KANBAN

It occurs every day. It is a meeting in which the team members of a system or part of a system evaluate the work in progress.

Here we will look at the problems we encounter and try to solve them. 

SERVICE DELIVERY REVIEW

This meeting, whose date depends on when the software is delivered to the customer, seeks to compare the customer's expectations and the delivered product. It focuses on verifying the team's performance against commitments, quality, delivery time, etc.

In other words, a quality control of our lifelong service.

DELIVERY PLANNING MEETING 

This meeting occurs on demand to review and plan our deliveries to the customer. Unlike the Service Delivery Review is that, while this one is oriented towards planning delivery activities, the previous one was oriented towards examining and improving the service we are providing.

STRATEGY REVIEW

This is the highest level meeting. It is to review and adjust the overall business strategy based on customer feedback and market changes. It also discusses organizational capabilities and key business objectives.

In other words, the bosses meet to discuss the company's strategy, taking into account external aspects such as market changes and internal aspects such as the team's operations. 

OPERATIONS REVIEW

The objective of this meeting is to analyze the efficiency of the different teams and the organization as a whole. Here we review the demand and capacity of each Kanban team, focusing on dependencies and their effects. It is also a good time to identify any underutilized capacity across the organization that can improve delivery times.

RISK REVIEW

The objective of this meeting is to identify risks and bottlenecks before they substantially affect the workflow and then take the necessary measures to mitigate those risks.

To explore more about how to effectively manage tasks and projects in agile environments, we recommend you read our companion article about types and flows of tasks in Agile projects. This post will provide you with a detailed overview of the various kinds of tasks you may encounter and how Agile workflows can be optimized to improve project delivery and team efficiency.