In this interview, Mark Levy, the director of strategy at Micro Focus, explains why DevOps is so important when making the move from waterfall to agile. He details speed versus quality when it comes to agile, why agile transformations take so long, and first steps you should take.
Josiah Renaudin: Welcome back to another TechWell interview. Today I’m joined by Mark Levy, director of strategic marketing at Micro Focus. We’ll be discussing how to evolve from waterfall to agile by taking advantage of DevOps. Mark, thanks so much for speaking with us. Before we actually dig into that topic, can you just give us a snapshot of your experience in the industry?
Mark Levy: My career spans over twenty-five years of experience in enterprise software focusing on both application development and IT operations. Prior to joining Micro Focus, I’ve held product management and product development positions focusing on application development, service, availability, and performance management. I’ve specifically focused on application delivery and release management since 2008 and have followed the DevOps movement for the last five years. I have also been hosting a web seminar series called the “DevOps Drive-in” for the last three years where we have interviewed thought leaders such as Gene Kim, Jez Humble, Gary Gruver, Patrick Debois, and others on topics such as DevOps best practices, culture, and high performance IT.
Josiah Renaudin: The amount of pressure that IT organizations are under to accelerate product delivery continues to increase year over year. What do you think has caused this greater demand for speed?
Mark Levy: Software development and delivery has always been a race against time. I was a developer for over ten years and we were always racing to a date. But over the last several years, that race has entered an even more challenging phase. There are three external trends that are putting pressure on the business.
First is the empowered, digitally enabled, demanding customer. With the explosion of mobile apps and low switching costs, the business needs to deliver quickly to prove out business ideas and innovations. Customer expectations have also risen with the adoption of consumer technologies that are intuitive, easy to use, and incredibly powerful. The business has to deliver new software faster to meet customers’ expectations.
The second trend relates to digital competitors. Firms that use software to disrupt established markets can move faster than traditional hardware or people-based businesses. Battles are already being waged across many industries between incumbents and software-powered companies. This is putting pressure on the business to deliver more digital products, services and channels.
The last trend points to the fact that Mark Andreessen was spot on in 2011 when he penned his essay on “Why Software is Eating the World." Today, software success is increasingly indistinguishable from business success. All business innovation requires new software, changes to software, or both. And business innovations can’t wait for long software cycles to finish.
Josiah Renaudin: Without adopting agile, is it even possible to meet these speed demands without sacrificing quality in some way?
Mark Levy: It depends on where the constraints are. You could adopt agile development but if it takes six weeks to request, provision, and stand-up your test environments, you might not get the results you were expecting. Accelerating application delivery is the number one reason companies implement agile development methodologies but agile, by itself, is often not sufficient. There are many delivery bottlenecks downstream from the development team.
As far as the “speed versus quality” trade-off, with modern software practices, you should not have to make a choice. By automating and building quality into your development and delivery process and “shifting left” your testing, speed increases and quality improves. DevOps has proven that speed and quality are not mutually exclusive.
Josiah Renaudin: Why is it that agile transformations are so long and expensive? Why can’t we just flip a switch and suddenly become agile?
Mark Levy: Enterprise IT is complex, sophisticated, dynamic, and frequently chaotic. These large development organizations frequently have thousands of developers and hundreds of teams that develop on different architectures and platforms from different locations and typically use different processes and tools to develop and deploy software. Each enterprise has its own unique DNA that has organically evolved through generations of applications and technologies with its own historic set of artifacts and processes.
Enterprise agile transformations in these types of large organizations are multi-faceted and fundamentally have to transform the culture and change or replace existing processes and tools. There is a big investment required before any results are delivered and big delivery bottlenecks still exist. This type of transformation is not sudden and can take up to several years to complete with some teams transitioning quickly, while others taking longer depending on a number of factors.
Josiah Renaudin: In your mind, as the Internet of Things, automation, and AI continue to play key roles in software development and testing, is transitioning from waterfall to agile essential?
Mark Levy: I think it is essential but the question is “How do you get there?” and “Where are your constraints in delivering business value to your customers?” As mentioned above, you can’t just flip a switch, especially if you have a hundred software development teams. The transition will take time and happen incrementally. Are there things you can do today to accelerate the delivery of business value to your customers while you transition your development teams to agile software practices? This is where DevOps takes a broader view of the delivery process and there are things you can do to accelerate software delivery as your waterfall teams transition to agile.
Josiah Renaudin: Can you give your own personal definition of DevOps and why it’s become such an important term in modern software?
Mark Levy: There are many definitions out there. There is also no DevOps Manifesto which is interesting. As the “godfather” of the DevOps movement and the expert who actually coined the term, I asked Patrick Dubois about the fact that there is no “official” definition or manifesto. Patrick explained to me that they left the definition vague on purpose since each organization is different and has its own unique set of challenges.
I think of DevOps as a state of collaboration between development, QA, and IT operations intended to produce better business outcomes. DevOps is not something you do, but rather a state you continuously move towards by implementing a culture of continuous improvement and by doing many different things.
Josiah Renaudin: Now, you argue that you can accelerate product delivery faster and with lower risk by using DevOps practices first to automate your deployment pipeline. Can you explain how and why?
Mark Levy: If you look at the overall delivery process, it is much broader than just the development process and there are many primary sources of application delivery cost and waste that can result in long lead times. The objective is to remove the “slack” in the system and find ways to continuously reduce cycle times quickly and efficiently.
There are many areas that we could focus on from the initial business idea proposed to production support, but for this discussion, let’s focus on the manual effort to deliver software. This involves manual testing, manual deployments and the manual provisioning of environments. These activities are expensive, slow, and very error-prone. Automating these activities within the deployment pipeline will result in faster cycle times at a lower cost with fewer production incidents regardless of the development methodology. As development teams transition to faster and more iterative development methodologies, the delivery cycle times will continue to shrink and continuously improve.
Josiah Renaudin: What are some DevOps practices that teams can leverage to both deliver products faster and maintain the quality that users demand?
Mark Levy: We have already highlighted one of the main principles of DevOps, which is automation. Automation not only saves time, but prevents defects and creates consistency but you still need to have something to deploy. Automation is one principle of the larger practice of continuous delivery, which ensures that the code is always in a deployable state. There are several other principles of continuous delivery which help teams deliver products faster and with quality. I would recommend picking up a copy of Continuous Delivery by Jez Humble and David Farley.
Many of the DevOps practices are well documented and not hard to find. I think the interesting thing is that a lot of these practices are not new but borrowed from other industries and adapted for software delivery. For example, DevOps has borrowed practices from agile, lean, continuous improvement, and system thinking. These practices span across both technical and cultural domains as well. In the cultural domain, practices like blameless post-mortems encourages collaboration, learning, respect, honesty and trust and with these practices you not only deliver faster and with better quality but your teams have a far better time doing it, which is a huge win.
Josiah Renaudin: More than anything, what central piece of advice would you give to a team that’s ready to move from waterfall to agile, but doesn’t quite know where to start?
Mark Levy: I would recommend when you start doing the initial research, view the end-to-end process of taking a business idea and delivering value to the customer as the “system.” You must see the system, follow the flow, and understand the constraints. Focus on improving the whole, not just optimizing parts. Create a value stream map of your delivery process to understand what constraints exist in the system. Make sure you continually ask yourself: “Why” am I doing this? How does this transformation or task provide a better business outcome? There are some great books to read as well. I would recommend Mike Cohn’s book Succeeding with Agile: Software Development Using Scrum, Gene Kim’s The Phoenix Project and his latest, The DevOps Handbook. I also think Gary Gruver’s book Leading the Transformation: Applying Agile and DevOps Principles at Scale gives a very pragmatic framework to work from.
Mark is director of strategy at Micro Focus, providing insight into how modern software practices such as agile and DevOps enable large enterprise IT organizations to build and deliver software faster and with less risk. Over the last twenty-five years, Mark has held marketing, product management, product development positions focusing application development, service, availability, and performance management. Mark speaks and writes on modern software practices from mainframe to mobile and is the host of the web seminar series the “DevOps Drive-in” where he interviews industry thought leaders on topics such as DevOps best practices, culture, and high performance IT.
