What is DevOps?
To some, DevOps is a 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 emphasises communication, collaboration and cooperation between software developers and the other stake holders in the information technology industry.
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 – how do you deliver a stable, feature rich system to your end user?)
Why Kanban for DevOps Projects?
One of Kanban’s chief advantages is how it enables you to visualize your entire value-stream and ensure stable flow. Thus it helps you combine the workflows of different functions and activities right from Dev to Integration/ Build, Test, Deployment and beyond that to application monitoring. Initially, it will help your Dev and Ops people 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 –
- What needs to be fixed – mapping you 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’s (what work items are?) prioritized with just one glance at ‘the board’. This ensures that the right/ important work is picked after taking into consideration how it affects the overall stability of the system (picking the right one ensures minimum friction is introduced). This ensures that every team (including internal customers) knows what’s in alignment with the business’ (department’s) goals.
- Blocked worked is immediately noticed – if there is a dependency or issue, the decision makers/ resolvers 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 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 you 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 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?
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 (and necessary?) 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. And 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.
Are you already using Kanban for DevOps? If you wouldn’t mind sharing your story with us, do mail us at firstname.lastname@example.org. If you need help with setting up your Kanban boards, contact us at email@example.com or sign up for a free trial and use one of our templates!