Here Is How to Apply Kanban for DevOps Teams

DevOps teams are a strange mixture of people with a background in IT operations, System administration, software development, consulting, field operations, and support. People who do DevOps are the new "warriors" of the IT industry as it comes to them to automate and deploy to production in the fastest and most cost-effective way possible. It's a tough job as it requires a lot of skills in various domains, deals with a never-ending queue of issues to tackle and a lot of angry people knock on your door if things go wrong.

The Kanban method can help DevOps teams put some order into their daily work and the lean theory can definitely be leveraged to improve the flow across the DevOps teams. Below is a sample Kanban board that IT guys can use to get up to speed with Kanban:

DevOps Kanban Board Structure Example

While you may choose to implement a much more complex board, we would like to suggest starting with the simplest format possible and improving as appropriate. With the sample board above there are three default columns "To Do", "Doing" and "Done", but we have added three horizontal lanes. Let us go through them one by one.

• Production Issues - this is the nightmare of every DevOps team. Production issues means unhappy users and this is the worst thing that can happen. If you have something in this lane, you must stop doing whatever it is that you are doing and tackle the production issue. Once the issue is fixed and marked Done, then you can continue with your ordinary tasks.
• Automation - a great deal of the work in a DevOps team is automating repeatable tasks or at least it should be. Having this lane on your Kanban board is a way to say "Yes, we understand automation, we give it a special place on our Kanban board, and we want to measure how many jobs we automate and how much time it takes".
• Operations - this is where support tickets come in or where you put some administrative tasks like meetings, phone calls, etc. Try to keep this lane as empty as possible, it will give room for automation or strategic projects.

What Are the Top 3 Benefits of Using Kanban in the DevOps World?

1. Kanban Combines Multiple Streams into One

One of the most common issues that a DevOps team experiences are the number of customers they have. By a customer, I mean someone that needs something from you. Such a team usually works with the development team, the support team, the management team, the infrastructure team (if there is one) with the end-user and probably, even more, depending on the size of the company.

If you respond to each request without any sort of schedule, you will soon be killed by context switching and the lack of clear priorities. Kanban helps teams (not only DevOps teams) to limit the amount of allowed work in progress and by that ensure things get done without too many distractions. When something is moved to do, you can take the next one and knowing how much things you have in the queue actually gives you the chance to predict when request X will be completed.

2. Gives Leverage to Say NO

If your plate is full already, Kanban will tell you. You hit the WIP limits - you can do no more (at least not without sacrificing your productivity). When someone comes to your desk and asks for something "very urgent", show them the board and just ask them to wait. Do not make compromises unless it is a customer or production-related issue, which should always be your number one priority. The great thing is that Kanban does the job for you - you don't have to explain, you don't have to estimate or judge - just point to the WIP limits and the size of your To-Do queue.

3. Improves Flow Team Communication

When a DevOps (or any other) team works on a dozen of important projects and literally hundreds of smaller items, it is very easy for some things to get stuck and submerge into oblivion. Since Kanban preaches "once started, must be completed" type of attitude, it becomes obvious when a certain thing does not progress. This allows the team members to identify it as an issue and work together towards completion by which you get both flow and team communication improved.

What Are the 3 Myths About Kanban Used in DevOps?

1. Start with Scrum, then Move to Kanban

Here is the first Agile myth and I’m not sure where this rumor started but we don’t know any Kanban thought leader who has ever advised anyone to start with Scrum and only then move to Kanban. Scrum can be a nice start in some cases of course but some teams might prefer to start with a flow-based method from the beginning of their project…and that’s Kanban.

Kanban manages small pieces in a chaotic environment extremely well and allows teams to create a work breakdown structure that still keeps the big picture at bay. What’s more? You can start applying it before you even have a team. Scrum and Kanban are two very different methods, both widely applicable, both valuable but neither one can be identified as a truly advisable start to absolutely any project.

2. Kanban Is Only for Support Teams

It may be true that support teams benefit a great deal from applying Kanban to their work, however, it is definitely not true that only support teams can do it. Support teams generally deal with similar work items every time and strict deadlines, that’s why a structured board works well for that process.

However, Kanban is capable of reflecting every process or flow, not just the linear ones – it depends on the way you’re working. One must recognize that a Kanban board doesn’t dictate how your team should break down your work. Instead, it reflects your optimal process and can be as flexible and varied as your project demands. Not every task will be in the format of a support ticket, but it absolutely doesn’t have to be in order to follow a similar flow on a Kanban board.

3. There Is No Planning and Estimation in Kanban

Perhaps the root of this misconception is the belief that according to Kanban, estimates and planning would actually be considered waste because they don’t bring direct value, they only aim to predict how value will be created later on in the project. Although there is a grain of truth in that, there is a form of waste accepted in the lean world, referred to as necessary waste.

Planning often falls into that category. No company out there does Kanban without some sort of planning and there are no exceptions to this at all. Project forecasting might be inaccurate for a long time, but even with Kanban, teams will still want to have a sense of the goal. However, despite the fact that every business requires planning, Kanban advises not to spend an excessive amount of time on it.

Conclusion

Kanban is probably the best thing that can happen to a DevOps team from the "project/process management" point of view. It is infinitely flexible and is able to address the core issues that a regular DevOps team has in a lightweight and unobtrusive way. Definitely, give it a try and let us know how that works for you in the comments section below.