Yuval Yeret is a senior enterprise Agile Coach at AgileSparks. He published ‘Holy land of Kanban’ and is the recipient of the Brickell Key Award for Lean Kanban community excellence. At the upcoming Agile India conference he is talking on good and bad ways to kickstart agile the Kanban way.
He spoke to InfoQ about the synergies between Kanban and DevOps.
InfoQ: You received the Brickell Key Award for Lean Kanban community excellence, driving Kanban adoption in Israel. Tell us a bit about your experience popularising Kanban in Israel.
Well, It has certainly been an interesting journey so far. It is hard to popularise a disruptive innovation like Kanban under a strong incumbent like Scrum. I found that the best way to get traction for the ideas behind kanban was to focus on what job it could do better than scrum for people. Turns out Kanban is quite good at doing the job of educating leadership about Lean/Flow since its language is more explicitly connected to the Lean/Flow concepts. It is also quite good at helping organizations who like to “build their own agile” rather than following a methodology religiously. It is also a great “gateway drug” method to get you going towards a lean/agile way of doing things. The visibility and mindset you use catalyzes the right kinds of behaviors and structures. I’ve seen several cases of teams starting with Kanban on top of their waterfallish structures and processes and starting to use more agile structures and processes like Feature teams, User Stories, ATDD, CI as they learned about the potential value these changes might provide when considered through a flow perspective
InfoQ: You claim that Kanban is a match made in heaven with DevOps. Tell us why?
DevOps talks about System Thinking, End to End Flow, Closing and amplifying feedback loops. All of those can be done with an iterative approach but in most real-world scenarios are a bit hard to fit into a sprint and are better managed as a flow using something like a Kanban pull-system. At the other end, the highly mature teams with Continuous Delivery capabilities balk at the “slowness/inflexibility” of the scrum iteration and prefer a fast-flow kanban system. In addition, DevOps is typically a journey for most organizations. The most popular description of that journey is found in “The Pheonix Project” by Gene Kim (which is highly recommended btw). And that journey’s steps - System Thinking, Amplify Feedback Loops, Continuously Experiment towards improvement map very well to Kanban’s principles of starting with where you are with respect to how things are done and by who as well as the practices of Visualization, Flow Management, Different levels of feedback loops
InfoQ: What is the biggest challenge in implementing Kanban on DevOps?
I would say the biggest challenge is having the discipline and resolve to get to an end to end visualization of the workflow (especially if this is only in your sphere of influence, not your sphere of control) not to mention move to Pull mode and WIP limits. You step into dangerous territory when you convey messages like “we will not pull this, we’ve reached our WIP limit”.
Another challenge that is even more extreme in DevOps compared to typical Agile situations is the need for end to end leadership looking at the performance of the entire value stream. (Agile only needs to bridge the Product/Dev/Test)
InfoQ: DevOps and Continuous Delivery is becoming pretty mainstream. At companies where these approaches are used, what metrics are they capturing to prove the ROI?
I wouldn’t necessarily say DevOps and/or Continuous Delivery is mainstream. I think there is a big chasm to cross. The Innovators who were typically web companies like NetFlix, Flickr, Etsy, Flickr, Amazon, Google. Then came early adopter companies which ranged from other web companies to companies with adventurous IT organizations with a real need to innovate faster in order to compete and/or a real sustainability crisis to deal with. Based on these problems/reasons for DevOps the typical metrics are deployment frequency, lead time for changes, and mean time to recover from failure.
Early adopters by their nature are less interested in metrics and ROI since they went into DevOps with an urgent business problem to solve. So initially data wasn’t readily available. But as DevOps is trying to cross this chasm it indeed needs to make a stronger business case as the mainstream market typically looks for this kind of proof as well as the validation that DevOps indeed works for a similar context to the one they are in. People like Gene Kim and some others in the DevOps community realized this some time ago and started issuing “State of DevOps” reports yearly. The 2014 report goes beyond reporting on the benefits for these operational metrics and is able to show a correlation between these leaner operational metrics and better IT performance overall as well as even better business results.
InfoQ: What is your favorite DevOps principles? Anything that changed the way you view software development?
I’m a Kanban guy. So I like Systems Thinking and Visualization of the end to end flow. Every time I help a group look end to end and see the light bulbs turn on just by seeing the initial kanban board view of their current situation it is a very satisfying moment. Asking them to play “what if” and simulate the future or a past scenario makes it even more realistic and drives the understanding of the lean/DevOps principles even deeper. I also like to help people understand the cost of the delayed feedback in the way they are currently doing things and use it to reduce the batch sizes in their processes and justify investment in various practices and even structural changes. This combines the “Amplify Feedback Loops” principle together with Don Reinertsen’s Cost of Delay/Flow principles.
InfoQ: What are some of the common problems, while applying DevOps concepts to Enterprise IT/ Product Development as compared to hosted-web apps?
Well the toughest problem is that Continuous Delivery is much harder and sometimes even an unrealistic goal. This makes it harder to close the feedback loop. It also makes it harder to justify tighter internal loops as people will tell you “why bother”. The way I deal with that is emphasize the cost of delayed feedback not just the cost of delayed time to market. I also insist the organization try to find creative ways to close the feedback loop like a cloud-based lab, early access programs, etc. I also emphasize that DevOps!=CD. You can benefit a lot from the DevOps thinking, principles and practices without going all the way to CD. I find Reinertsen’s principles of flow very useful in this context.
InfoQ: Is there any special advice you would provide to people applying WIP limits to DevOps projects?
Especially when talking about enterprise DevOps your end to end flow will probably NOT be at the user story level. It will probably more at the “MMF”/Feature”/”Epic” level, whatever you want to call that unit beyond the story that DOES make some sense at the business level to deploy and enable for users. In these cases people should make sure that their WIP limits and their flow visualization in general apply at this level. In fact, in several enterprise DevOps cases we started from agile teams using some process like Scrum/Kanban/Scrumban and DevOps was one of the triggers for starting to actively manage the end to end flow of Epics/Features. To learn more, come to my workshop at Agile India 2015 conference.