There’s quite a bit buzz on Kanban right now in the DevOps community. Since Scrum has been quite mainstream now, a question we should all be asking is how does the shift from Scrum to Kanban effect DevOps efforts?
Continuous Delivery for Business Agility
The presumptive goal of any DevOps initiative is to move fast, deploy rapidly and be responsive to changing business conditions. Therefore, if we consider our options it becomes very apparent why the Kanban methodology is so progressive and helpful to achieve the desired outcome of business agility. The ability for the business to see status and progress on a daily basis rather than just your daily typical standup meeting waiting for the two or three week sprint to end is very appealing and can be transformational in how work gets communicated and completed.
Alignment Across All Stakeholders
We all want the same thing, right?! Of course we do, but with the Kanban approach it makes the developers work as a team and finish what they started. If one part of a development team is forced (by the Kanban WIP limit) to put in their resources into other parts of the projects to help out, they will start to see the project in a larger perspective and hopefully identify bottlenecks and problems before they arise. Seeing the project at a more holistic level by all stakeholders helps us take a more system-level view of things which is The First Way within the underpinning principles of DevOps. The outcomes of The First Way include:
Take the 'Time-box" Out of the Equation
In Scrum, product owners have a finite time (usually 2-3 weeks) to fit user stories into a sprint. The problem with this is that it creates unnatural breakpoints for the deployment and testing guys. Too small of stories are not potentially shippable product at the end of a sprint, increases dependencies between sprints which can make coordination challenging and makes testing extremely difficult. Whereas with the Kanban approach, there is no prescriptive time limitations. It is about focusing on the most important work and pulling it through the processes at the right time to the right people.
Taking a Kanban approach to your DevOps movement is not for the faint of heart as it is relatively nascent in comparison to it's Agile brethren and there are plenty of discussion points about how it is more effective for time-critical initiatives like an impending product launch or a change management process. However, it is worth consideration and testing to see what positive changes it can bring to how your organization works and will undoubtedly force you to have conversations as to where you are close to violating the work limits. But finding those constraints in your process is where the biggest gains can be had - fixing any other part of the process is just an illusion.
Want to Learn More About Kanban?