Last week, I enjoyed participating in an online panel on Devops and lean in legacy environments as part of Continuous Discussions (#c9d9), a series of community panels about Agile, Continuous Delivery and Devops.
The discussion centered on if and how “horses”, legacy environments originally based on waterfall/ITIL, can become “unicorns” with advanced Devops-Agile practices. Questions asked included how to “inject” DevOps and Lean principles across multiple legacy product teams with different technology stacks; how to enable experimentation in legacy environments; and what differences panelists have seen in their production pipelines. Check out a full recording of the panel here:
Continuous Discussions is a community initiative by Electric Cloud, which I’ve been aware of for ages as a strong build automation and optimization tool and apparently has made the smart move of strongly supporting the DevOps movement both by providing test & deployment tools as well as being involved in the community.
Below are a few insights from my contribution to the panel:
How do you make the move from an ITIL/waterfall to an Agile/DevOps perspective in legacy environments?
“I think it’s not a technology issue. 22 years back, we were working with a mainframe in a mission critical places in the Israeli army and we were doing DevOps, deploying every week, dev and operations were talking closely to each other. Those Cobol guys knew how to do Devops, it’s not a technology issue. We didn’t really know about waterfall until we started to do client server projects and something got messed up”. I’ve actually been saying this for a while now. It’s like a pendulum where once upon a time the developer didn’t rely on ops people or testers.
“But today I see that the urge to go to Devops and Agile, at least for systems of innovation, is that people really want to do it, just not sure exactly how to go about it. Culture is not a thing you can implement, tools are something you can implement, but it’s not clear what kinds of tools would be the first to invest in. My approach is to look at things from a flow perspective, get people to look at end-to-end process or value stream from need to production, and see where things get stuck, where there is slow feedbacks, big batches, etc.”
“We show them how to visualize their process using Kanbans or flow diagrams, to get a picture of what is going on in the system, what are the bottlenecks. And when they become aware of those bottlenecks, a concept which is interesting for many people is a combination of different types of costs. Everyone is optimizing for lower overhead and transaction costs. The cost of releasing is high, so people try to release less often, because that will reduce the overhead of releasing. They’re not aware of the cost of delayed feedback or missing time to market.” Classic Reinertsen. Somebody had to represent his Lean Product Development thinking on that panel. Only natural it would be me I guess…
“Only when people start to combine those two costs they understand that maybe a tool that can help reduce transaction cost does have an ROI. The return comes from getting earlier feedback if you have problems in production, or learning whether this innovative feature is in the right direction, and it saves a lot of time later on.”
“It’s kind of trivial at small companies, but at big companies, we see examples such as one company that have been working on their CI for two years, investing millions of dollars going from monolith system that takes days across multiple applications, and now they’re close to CI for some fixed configurations. They’re still working on it. Getting to CD or automating the deployment pipeline is going to take a lot of time they need a lot of clear ROI for it.”
How do you promote experimentation in legacy environments?
“We promote using the language of experimentation whenever you talk about things. Start talking about experiments, MVPs, not just in the product area. At another one of our clients, a household-name enterprise, top managers started to ask people, what’s the experiment here? Can we try to experiment with something?”
“Another aspect is they started calling their business units “startups” – that’s another thing that nurtures entrepreneurial thinking, even in such a large organization – startups report to division leads and in their reporting dashboard, the way they measure of agility is to show the rate of experimentation. They don’t just talk about velocity of output, but also velocity of experiments, velocity of MVPs, whatever it is that they can get out there no matter the size. They can try as small an experiment as they want, the number of experiments they tried is something management talks about and asks about.
“Another thing they talk about is not product experimentation but process experimentation, which is important as well. Let’s make sure we experiment with how we work, retrospectives, can we try to do things differently? In each of these fields, product and process, management is interested in how much experimentation happens and that makes experimentation happen.”
Overall it was an interesting discussion. Hopefully the audience got some good ideas and pointers out of it. Looking forward to participating in another webinar in the future.
On the topic of webinars, I’ll be giving a LeanKit webinar about Flow-driven product development next week. See you there.