What is the Kanban methodology and how to apply it?

We thought it might be a good topic to bring up here. After all, Kanban is something that many people have heard about, at least in the field. Everyone has a basic understanding of the topic, but sometimes the whys and wherefores of things or certain details are left unresolved. So here's a quick rundown of Kanban, its relationship to other methodologies we can apply, and issues to keep in mind. Explained, as always, for humans.

In Japanese, Kanban means   card , or   signal . The name was first used for work processes by Toyota in the 1950s, as part of a way of working they called JIT (Just in Time). One of the fundamental ideas behind it was to move from methodologies   push   to methodologies   Pull . This, which sounds strange when put like this, basically means going from the initial parts of the production chain manufacturing nonstop and sending the parts (push) to the next part of the chain, to working on request from the final parts of the chain (pull). That is, the last process asks the previous one for what it needs; it manufactures only what it has been asked for, never more, and if it needs parts to do so, it orders them backwards, always only what it needs.

And what's this for? Well, among other things, the "just-in-time" approach was to avoid having a pile of things waiting to be used (with wear and tear), and by ordering only what's needed, when it's needed, parts are saved, bottlenecks can be measured, and production is more flexible (it's easier to adapt to changes), etc.

I'm sharing this introduction about its origins for two reasons. First, It's important to understand that although the application of Kanban to the world of software or management is relatively recent, and there are many adaptations that have been made in that process, the original process itself is almost 75 years old, and there is much of the original idea that can be applied to software development or task management of any kind. In fact, I believe it's essential to understand the starting points and the fundamentals that led to the development of a methodology in order to be able to apply it (as with anything else, really).

Now that we understand where Kanban comes from, let's look at how it applies to project management. It's a way of working in which we will:

• Visualize the workflow
• Limit the amount of work we do at once
• We will focus on that "flow" of work
• And we will make continuous improvement of the process

Now point by point.

• Visualize the workflow : As I said at the beginning, Kanban in Japanese means   card   either   signal , and in fact most applications that allow you to work with Kanban usually use cards, such as   Trello . You've probably also seen the typical photo of people with Post-its on windows or office walls. It looks cool and modern, although I admit I've done it in a previous job. Since we want to visualize the workflow, we'll give clear names to the columns on a board and list the tasks in those statuses in each column. If you want, choose a project you'll start soon and do it as you read this article. Decide on statuses for the tasks; it's better to err on the side of minimalism at the beginning; perhaps To Do, In Progress, and Done might work.
• Limit the amount of work we do at once : From a board perspective this would be limiting the number of tasks we have in each column at the same time. In English it is referred to as   Stop starting, start finishing , or stop starting things and start finishing them. You've probably gotten stuck on a topic and started a simpler one, putting the previous one on hold. Perhaps days go by and you suddenly realize that the topic you put on hold has been sitting there for weeks. It's not that switching contexts is always bad, or that leaving tasks blocked to start others, but it's good to limit this and encourage us to finish what we start before moving on to other things.
• Focus on workflow : Now that we have the board set up and limited the amount of work we do at once, tasks should flow. With this step, we want to focus on the flow of tasks, potential bottlenecks, interruptions, and mechanisms that prevent tasks from moving forward as smoothly as they should.
• Continuous process improvement : With the previous point, whether through experience or because we've decided to measure some task parameters (average time from initial to final state, number of tasks completed per week, etc.), we'll have an idea of possible things to improve in the process. With this, and the mindset that Kanban is a methodology to help us as a team do our work better, we can decide what to change to make our lives easier.

An interesting topic we discussed at the beginning about the original Kanban was that it was a methodology   pull   instead of   Push . Instead of doing things and passing them on to the next in the chain, from the end, we would request whatever was needed to finish the product (a car in this case). This applied to the management of other types of projects and with point 3 of the previous list in mind, when we look at the workflow or want to unblock a Kanban board, it's best to always go from right to left. If, for example, we have the statuses "Done, Doing, Blocked, In Review, Done." Before starting to add more work, we'll see if there are things in review that we can already consider closed, what the blocked things are missing to be able to move them on to review, and so on.

This improves the time from when tasks are started to when they are finished and reduces the amount of   topics in the air .

If you're reading this, you've probably also heard of Scrum or other agile methodologies, and you might be wondering whether one or the other would be better for your next project.

The fundamental difference between Scrum and other similar methodologies is that in Scrum we set a time horizon for completing a specific task, whereas in Kanban we don't. In Scrum, we have development cycles, or Sprints, in which we commit to delivering a certain amount of work, provided that that workload doesn't change during the development cycle. It's widely used for new development projects and product development because, on the one hand, we have the flexibility to adapt to changes (deciding now what will be done in the next development cycle), and on the other, the team doesn't have the chaos of constantly changing focus, since what they're working on now remains firmly within the current development cycle.

Kanban, on the other hand, works very well for maintenance projects and teams with less structure for planning the different Scrum development cycles, or when the client doesn't want to be as involved as is necessary in Scrum.

In everyday life, we see that many projects that use Kanban could perfectly use Scrum, working with the client on the time expectations for changes and last-minute tasks, and many projects that use Scrum actually use a disguised Kanban, since the development cycle is changed mid-process or the complete cycles are never delivered, etc.

As a final thought, one of these methodology should help, after using it for a while, the team should notice an improvement in something, in whatever it is they want to improve (which doesn't always have to be doing more tasks, it could be that we want to do them with less stress, living better). It's important to keep this in mind at all times, to use it in the continuous improvement section. Sometimes we insist on using Kanban, Scrum, or the-new-trendy-methodology because we've read somewhere that it's great, but perhaps there are aspects of that methodology that don't fit well with our team's way of working, etc. An important part of all these ways of working is feeling free enough to adapt them and make them fit with our teams.