BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Yuval Yeret talks about the Synergies of Kanban and Devops

| by Shane Hastie on Mar 03, 2015. Estimated reading time: 6 minutes |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Insightful by Jack Carlton

It's good to see that methods like Kanban and the aim for Continuous Delivery are easily called "mainstream" nowadays. Also, the amount of information and data that can be found to help get started is getting astonishing, a lot of it thanks to Yuval.
I mostly based my own agile devops implementation on kanbantool.com/kanban-library/devops-kanban-basics.
Any thoughts on what is coming next? As in "once we all get pioneers of continuous delivery" - what's the next improvement to make (as in a big step up)?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and dont miss out on content that matters to you

BT