Kanban for Self-management DevOps Teams

Avatar for evgeny.savitsky

Finally you did it, you made a technical launch of your service and now your team is in transition to support stage. You had launched well tested minimum viable product and now it is time to listen to your customers, evolve and implement required features, fix issues your team didn't find before.

You find that interest to your service is growing all the time. You get more and more customers, thus you have more conversations, support tickets, issues and bugs you should resolve as soon as possible.

There are some post-launch process traits you should be aware of. Predictable and regular sprints are over. Team meets huge amount of unplanned work like tickets customers had left on helpdesk site and urgent issues like alerts got from application and server monitoring tools. Now you have clear visibility of the technical debt increasing because of hidden issues, exceptions and bugs automatically reported from the every layer of your application stack and middleware.

Software Kanban is the management system that allows to control all these chaotic activities on the basis of several simple principles.

Process Visualization

Development process is consisted of several stages like analysis, development, testing, etc. To visualize your process you should identify all stages each issue or feature pass through and make it visible to all of your team members via electronic board. Each stage is displayed as a column on the task board. Every task should be in a single column at a time. Set of tasks in each stage builds a work queue at corresponding stage.

Pull Tasks from the Queue

There is backlog of what is undone yet, e.g. features or issues. It is the first column on the kanban board. Every team member pulls the task from corresponding queue (like coding or testing) only when he has completed the previous task. When a task is done then it should be moved into Done area of a corresponding stage. It is like a backlog for a subsequent stage. For example when a feature is coded corresponding card is moved into "Development: done" column, after that tester pulls it into his work queue and moves into the column "Testing".

Work-in-progress Limit (WIP)

Within each stage it takes different time to complete tasks required like evolving requirements, coding or testing. Also team members have different skillset, so there is specialization - one is responsible for testing, another is responsible for development for example. That is why the process throughput is not the same on different stages. Work in progress limit shows how many tasks at a time can be in the corresponding stage. For example, if you have one person with testing skillset then WIP for testing stage should be equal to 1 initially.

How Kanban Board Helps your Team?

The key requirement should be met to use Kanban management system for DevOps team is to handle all teams activity on single board. There shouldn't be parallel work queues formed by emails or chat messages. Single backlog allows to make clear prioritization of what should be done first, e.g. some of new features, urgent issues or tasks to reduce technical debt. When using single work queue for every person then amount of interruptive work is reduced dramatically and team members are prevented of context switching. It leads to getting of more qualitative work results for less time.

Moreover, Kanban system is full of visual metrics you can use to make your process effective and more productive. When you discover long or constantly growing work queues it signals that you find bottleneck in the process, thus subsequent stages have lower throughput then prior stages. Here is the challenge to your team to adapt process to avoid any bottlenecks. Average lead time metric shows how quickly the team resolves issues and implements features. The important thing is to minimize that value by discarding all time wasted activities which do not bring real value to the process. This is the way team can build effective and rapid process to deliver new functionality for customers along with reducing technical debt of the service.

Evgeny Savitsky