Kanban for DevOPS
Kanban 101
Getting Started
Advanced Kanban
Kanban Metrics
Kanban Use Cases
Kanban Software
Using Kanban for DevOps and Continuous Delivery
What is DevOps?
To some, DevOps is about culture, to others it’s a software development methodology on its own. While there will always be discussion and favorite definitions, DevOps has generally come to encompass a philosophy that emphasizes communication, collaboration and cooperation between software developers and the other stake holders in the information technology industry.
Why DevOps?
There is general acknowledgement that actual software development, quality assurance and IT operations are interdependent and there is a need to ensure that these functions (traditionally always functionally independent) need to work as one to ensure rapid delivery of products or services that meet industry standards. And this is why the concepts of continuous integration (for developers), automation (QA) and continuous delivery (IT operations) have become increasingly popular. The goal remains the same though – to deliver a stable, feature rich system to your end user.
DevOps has come to be recognized to incorporate a whole set of tools and technologies that seamlessly integrates the application or software development lifecycle from spec to design to development, testing and deployment. Properly implemented and integrated, these tools enable Continuous Build, Continuous Integration, Continuous Testing and Continuous Deployment. Thus, DevOps enables incremental, continuous deployment of small changes and updates to products and websites with minimal to zero downtime. In today’s world of SaaS-based application delivery and consumption, DevOps has become a critical success factor for technology vendors to deliver newer product features, defect fixes and performance and security updates in near real-time.
Why Kanban for DevOps?
The primary advantage that Kanban has is that it encourages teams to focus on improving flow in the system. As teams adopt Kanban, they become good at continuously delivering work they have completed. Thus, Kanban facilitates doing incremental product releases with small chunks of new functionality or defect fixes. This feature of Kanban makes it well suited to DevOps’ continuous delivery and deployment requirements.
The other big advantage of Kanban is how it enables you to visualize your entire value-stream and ensure stable flow. It helps you combine the workflows of different functions and activities right from Development to Integration/ Build, Test, Deployment and beyond that to application monitoring. Initially, it will help your Dev and Ops teams to work in a collaborative manner. Over a period of time, you can evolve into a single team and single workflow that includes all of Dev and Ops activities. Kanban provides you visibility to this entire process – and transformation to a DevOps culture.
This visibility ensures everyone knows what stages a work item must flow through to ensure it’s considered ‘Done and Successful’, and this has noticeable advantages –
-
Identifying what needs to be fixed – mapping your workflow shows you what needs to be fixed first with the processes you follow. Indeed, with Kanban, you begin with what you’re currently doing and then try to continuously improve
-
Priorities – Your stakeholders know what work items are prioritized with just one glance at ‘the board’. This ensures that the right/ important work is pulled after taking into consideration how it affects the overall stability of the system (picking the right one ensures minimum friction is introduced). This also ensures that every team, including internal customers, knows what’s in alignment with the business’ goals
-
Blocked worked is immediately noticed – if there is a dependency or issue, the decision makers can immediately step in and figure out what to do next – there is no cost of delayed feedback
-
The pull system – Kanban encourages you to ‘stop starting and start finishing’ – ensures that you spend your time on a minimum possible number of work items at a time, thereby reducing frequent context switching and loss of productivity. This also ensures that flow is constant – when you’re stuck on one task, there’s nothing preventing others from pulling new work i.e. the overall system is stable
-
Automation – the board shows how your work flows, where your bottlenecks are, what your cycle time is – in effect showing you where automation might help and what needs to be improved
Kanban cannot replace strategy and intent – you need to have developers who are willing to do bits of QA and understand how much change they can introduce into the system without disrupting the flow, and you need your operations team to understand what changes (features) to prepare for to ensure stability. It can definitely help with both though – when you have everyone on board (literally!) there is less tension all around and ensures every function (and individual) is more effective and knows what exactly needs to be done.
Why not Scrum?
While Scrum can and does work well in delivery environments where the need to deliver may not be truly “continuous” (after all you are working with a minimum of a 2-3 week sprint cycle), Kanban’s very nature makes it more suitable. If you look at most DevOps implementations in the field – you’ll find it’s difficult to fit it into a standard sprint. Kanban’s pull rather than push, and the concept of flow that forms its basis sits rather well with DevOps. Also, continuous delivery and Kanban work well together – both are just-in-time systems that focus on getting one thing right at a time (most of the time!). And course, the flexibility that Kanban brings in is an added bonus.
How does one get started?
-
Your Dev team can track their own work on a separate Kanban board. For the basics of a Kanban board read our article on Kanban Boards
-
Ops can have their own boards that revolve around automation, production and support that have work items of the form ‘Maintenance’, ‘Implementation’, ‘Desktop/ Server Support’ among others
-
Your overall value-stream should be tracked on a separate Kanban board where Dev and Ops have their own lanes. (Check our page on portfolio kanban for details on how to set up and use hierarchical boards.)
-
We wouldn’t suggest applying DevOps at the user story level. Whatever you define as your MMF (minimum marketable feature) or Epic, or Release (any unit really) should probably be WIP limited, not individual stories. It’s possibly the only sensible/ easiest way to help map and manage your entire value – stream.
Have you already adopted DevOps? Are you evaluating the use of Kanban for your DevOps teams? Using SwiftKanban and our integration product SwiftSync, we can help you get your DevOps solution up and running in no time at all. Just drop us a line at [email protected] or sign up for a free trial! If you would like us to work with you to develop your own DevOps solution, just let us know.
If you are already using SwiftKanban and need help with setting up your Kanban boards, contact us at [email protected]
Signup for updates!
Visualize your workflow and manage your work in an Easy and Intuitive way.
Try our Enterprise Plan FREE for 30 days.
