What DevOps can learn from Kanban

One of the great strengths of Kanban over other Agile methodologies is its great flexibility. For operations, the ability to incorporate interrupts easily is essential. While the goal of any operations team should always be to plan as much as possible, the fact is interrupts do happen. Kanban suggests itself as a natural system for organizing operations workflow but it is far more than that. I believe there is much to be learned from Kanban for anyone leading a DevOps program.

Principles of Kanban

The principles of Kanban align closely with the culture of DevOps. One of the best and more detailed expositions of the Kanban method I have read recently is Kanban from the Inside by Mike Burrows.

Burrows avoids introducing the Kanban method from its Foundation Practices and Core Principles in favor of a system of nine values which he lists as follows:

• Transparency
• Balance
• Collaboration
• Customer Focus
• Flow
• Leadership
• Understanding
• Agreement
• Respect

These nine values could well be listed as the components of a DevOps culture. Burrows goes on to elaborate four foundational principles which he labels as follows:

FP1: Start with what you do now.
FP2: Agree to pursue evolutionary change
FP3: Initially, respect current processes, roles, responsibilities, and job titles.
FP4: Encourage acts of leadership at every level in your organization -- from individual contributor to senior management.

Again these are very useful foundation principles, not only for Kanban but for DevOps in general. FP2 and FP3 on the pursuit of evolutionary change and respecting initial processes are particularly important. More often than not a company turns to DevOps in recognition of broken practices and procedures. Few companies are completely homogeneous and different teams will have their own ideas about what must change and how quickly. The best recipe for success with ah DevOps program is not to seek drastic changes overnight but to encourage new processes as the culture develops.

The DevOps toolset can help tremendously with this this. A move towards configuration management implies a change in practice by both operations and development teams. Self enablement of developers implies changes to roles, responsibilities and in some cases even job titles. But we need the tools in place before we can change process. This is how I interpret FP3: "Initially, respect current processes." Once the tools are in place and we have buy in from some teams and individuals, it becomes easier to convince others.

Encouraging acts of leadership is also central to the DevOps culture. It encourages individuals at every level of an organization to take ownership of the product. Not simply their part of it but the whole product.

Burrows also elaborates six Core Practices as follows:

CP1: Visualize.
CP2: Limit Work-in-Progress (WIP).
CP3: Manage flow.
CP4: Make policies explicit.
CP5: Implement feedback loops.
CP6: Improve collaboratively, evolve experimentally (using models and the scientific method).

As with the foundation principles, these core practices can be of enormous benefit to a DevOps program. Let's look at how each one of these can assist with DevOps.

Kanban and DevOps

Visualize

A friend of mine asked me recently how one measures the success of a DevOps program and the first thing that came to mind was the need for visualization. The Kanban board is the the most basic visualization tool. Anyone interested can see the progression of work through the system. They can see what is blocked, what is in progress and get a rough approximation of when their "most urgent of all tasks"  are likely to be completed. In addition I like to produce metrics relating to team velocity that can illustrate improvements resulting from the introduction of DevOps.

Of course  the Kanban board doesn't account for all the work being done by a team. While there certainly should be a card associated with every task, there are other metrics that become useful when one is implementing infrastructure as code. Tools such as github make it simple to generate reports relating to code checkins, pull requests etc. This should be part of your velocity metrics, as should mean time to acknowledge alerts from your monitoring system and mean time to resolve production issues.

This is all part of the Visualization advocated by Kanban. Make it clear what your team does and where they are at in the workflow.

Limit WiP

Operations teams and even some development teams are invariably pulled every which way by demands from multiple stakeholders. Every stakeholder naturally thinks their issue is the most important issue of the day. Limiting Work-in-Progress in a very visual way can be a useful asset in explaining why people sometimes just need to be patient.

By taking stakeholders to the Kanban board and pointing out the current issues in progress, we can initiate the conversation about what should be dropped in favor of that most urgent issue you are being asked to work on. It is then possible to explain to the person demanding you drop everything that they need to talk to the stakeholders affected if you do so.

Feedback Loops

The success of "pushing back" as I suggest above will be heavily affected by the feedback loops in place. If stakeholders are left wondering if their request is just sitting in some backlog somewhere to never be reviewed, the above push back will not be very successful. We need to provide continuous feedback. Could the stakeholder have done anything different that would make the processing of the request smoother? Could we have done anything different? All of this relates strongly to the first principle of Kanban, transparency. Be totally transparent about your workflows, WiP limits and team velocity. It will pay big dividends in the end.


Collaboration

It should not be necessary to explain to DevOps folks the relationship of CP6 to DevOps. It is the very heart of a DevOps culture. We need to improve collaboratively, both within our team and between teams. That is really what DevOps is about.

Conclusion

In conclusion I want to emphasize that I have presented here only a brief synopsis of ideas of Mike Burrows as elaborated in his work Kanban from the Inside. I strongly advise everyone involved with DevOps to read this book. There is much to learn from the agile movement and Kanban in particular.