I always love going into those meeting rooms where there are different color post-it notes all over the room that looks like a 3M sales rep threw up everywhere. For the longest time I just considered it one of those strange things R&D did. Then one day I was extremely early for a meeting and actually got to spend some time studying what was cluttered all over the glass wall and I began to realize there was a definite method to the madness. This Kanban board concept wasn't just for the engineers, it was for everyone to see where work was being performed and its status. I loved the visual nature of it, and the fact that I could get accurate information without reading release notes or technical requirements documents was refreshing.
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:
Never pass a known defect to downstream work centers
Never allow local optimization to create global degradation
Always seek to increase flow
Always seek to achieve profound understanding of the system
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.