Quick introduction to Kanban

Whenever we consider using some new tool, framework, process, etc. we immediately think: can we apply this?, will it work for me?

It’s no different with Kanban. Can we apply it in the software development processes?

Yes. Many would agree with me. Many others would say "yes, but some Scrum-like methodology would fit better for my use case"—and that may be completely right as well. As always, the answer is "it depends".

Software development teams use Kanban to organize their work. That is, (roughly speaking,) defining a backlog of tasks, prioritizing them, doing some analysis work, "moving" them to "development", "review", "done", and the list goes on and on, as long as the teams see it fit.

That’s the interesting thing about it: it’s not a restrictive framework that dictates "what must be done", instead it offers guides on how things could improve, rather than specific actions, so it can be easily adopted by different businesses.

Kanban should not be "enforced". As with any other tool, we must be able to identify pain points we have in our teams (or solo-team) and check if the tool can really help us.

For example, if we feel we’re always busy, and yet we can’t get anything done/completed. Or, if we feel the process, as a whole, is not as efficient as it could be. Or maybe we simply don’t have an answer to common questions like "where are we at now?", "when will task XYZ be completed?", "who’s working on feature ABC?", or "what should I work on now?".

In such cases, it may be worth taking some time and consider something like Kanban; something that could lead to improve our efficiency and remove waste of time and resources.

Good news! There’s no need to overhaul the whole business practices in order for us to adopt Kanban. It provides the means to visualize what we’re already doing and which parts could be tweaked to be more efficient. On top of that, the changes required to make things better can be implemented gradually—no need to throw everything away and start from scratch!

That’s the most challenging part of almost anything: getting started. Once we get that little first step, things start to turn smoother.

So it’s important to know how to take that first step.

One approach is to make something like a map or visual representation of our current workflow. This means identifying major processes in our organization/business, department, area, etc. It’s here where we also identify (mentioned in no particular order):

With answers to questions like this, we create one column for the Kanban board. So, for a software development team, we could have the following columns:

It’s after we do this step that we can identify improvements in our current workflow, so it’s normal if some of the things we’re doing are not as efficient as we’d like them to be. That’s expected: it’s from this point from where we start to see areas of improvements and form where we can start to enhance our flow; so it’s important to not try to "beatify" the current state of our processes: we need to see our flaws, so we can tackle them.

Also, at this point, it’s a good idea to define how many work in progress (WIP) we’re willing to keep. For example, a developer shouldn’t have more than one feature ticket in state "Development" at the same time; but probably a marketing specialist can handle three or more tickets with the goal to define different marketing strategies associated with different partners. These limits can then be changed gradually as the team monitors their speed and results in each of the steps.

Once we have our workflow steps defined, it’s time to draw those as columns in a board. It can be done in almost anything we want: a physical whiteboard, a table, a piece of paper, a corkboard, a Kanban board on Jira.

It’s time to visualize the work in progress the team is doing. It’s now when we start adding the tasks to the board and track how they move from one column (step) to another. Also, it’s a good idea to display for each task some meta-data such as creation date, deadline, priority, type, priority, description, notes, definition of "done", history and any other piece of data that helps in monitoring each task. It’s good to display on the board as well who’s working on each task, unless it’s a solo-team.

Nowadays, tools like Jira, make this part trivial, as its boards already bring all these fields really easy to be edited.

As mentioned before, it’s important to define some initials WIP limits. Sometimes this is challenging to do: how do we know the ideal amount of work in progress we can handle? But we must start somewhere, right?

Two approaches can be applied here:

During this time, it’s good to involve the whole team in documenting the process and setting realistic WIP limits everyone is willing to enforce.

The idea of Kanban is that each phase/column "pulls" the work from the previous stage/column, signaling the previous stage "to make another one" (terms from the manufacturing days). This is intentional: the idea is that each stage pulls new work only when it’s possible to complete it. This way, the WIP limits are enforced for each stage.

This mechanism is opposed to a "push system" where each stage would complete the work on it and would "push" it to the next stage, regardless of the workload there and without having in mind the WIP limits.

Put in another way: each team member takes (pull) new tasks only when they’re ready to do the work, and it becomes his/her responsibility until the task is completed for that stage. This doesn’t mean one person can’t complete the tasks associated to the same concept in different stages, quite the opposite. Sometimes it’s the same person who "moves" a task from one state (column/stage) to another, until it’s "done". Again, Kanban is very flexible, and it’s here to help us with our flow, not to put restrictions.

Once we have a visual representation of our process(es), ideally in a Kanban board, we can see at a glance where in the workflow each task is, and it’s really easy to spot bottlenecks early. When the WIP limits are set appropriately, we usually hit a limit as soon as a bottleneck starts to form. That’s why, in part, the power of Kanban comes from the fact that everyone can see when a problem (like bottleneck) is forming and take action early in the workflow, before more work is piled up and everyone needs to start jumping from task to task: this is when clarity is lost because of so many context switches.

Kanban doesn’t force us to monitor, adapt or learn from mistakes; but it’s generally a good idea to do so. Otherwise, we’re not benefitting completely from having a well-defined process structure and WIP limits.

Two tools that are really useful for tracking improvements are lead time and cycle time. Lead time is basically the total time it takes to get something done from the moment someone asks for it until it’s completed. Cycle time is the amount of time spent on a work item by a person or a team up until it’s ready to be delivered.

It’s also generally a good idea for the team to review the metrics and reflect on what’s being done right and what could be improved. This is how, iteration after iteration, the team can reach a point of "optimal" flow in the process. The space and format of this is different for each team. Some things that I’ve seen work in the pass is to have regular meetings, let it be weekly, bi-weekly, or with any other schedule, where everyone is free to express their ideas and observation of how the workflow has changed since the last iteration.

Different tasks have different intrinsic value to customers, different risks, different priorities, etc. By defining "classes of services", policies, and "rules" associated with them, we can change the value that’s delivered and improve the overall workflow.

For example, in a software development team, there could be a class of service called "production bug", which would describe a ticket whose result impacts the customers and the organization directly. Because of this, resolving it is a top priority The following "rules" would apply:

Class of service is a powerful tool that can be implemented and adapted in a variety of ways to optimize the value delivered by the team.

Yes, we can. Kanban doesn’t define what steps, rituals, meetings, or similar team practices are used in the team’s workflow. It is a tool to be used to improve our workflow, in general, but there’s no hard rule that stops us from experimenting and implementing other tools or framework that could also help us.