Q&A: Gary Gruver and Tommy Mouser, authors of Leading the Transformation: Applying Agile and DevOps Principles at Scale

We asked coauthors Gary Gruver and Tommy Mouser to answer a few questions about the challenges and triumphs with large-scale DevOps transformations.

You also can download an excerpt of Leading the Transformation or learn a little more about this latest publishing effort here at IT Revolution. Enjoy!

What problems do you see executives struggling with as they lead an enterprise-level DevOps initiative?

Tommy Mouser: Most of the information available regarding DevOps initiatives is focused on small teams or small organizations. As a result, when large enterprise organizations begin a journey to adopt these principles they follow the well-known processes that work for small teams. Executives in these enterprise organizations quickly observe that they are not getting the productivity gains and cost savings that they were expecting, and they struggle to understand why and how they should alter their approach. Leading the Transformation describes and explains how enterprise executives can approach the challenges associated with transforming a large software development organization.

Gary Gruver: Leading a successful transformation in a large organization is hard work that requires a lot of change management. Executives will need to gain the support of their bosses, peers, and team if the transformation is going to be effective. The best approach, as we discuss in chapter 4, is to be transparent and involve as many of those constituents as possible in the executive-led continuous improvement journey. This journey is going to take time and the organization will learn a lot about what is most effective for addressing the unique challenges of their organization along the way. The keys to avoiding resistance to change are including them in the process, involve them in prioritizing improvements, and tracking the progress. This approach with monthly checkpoints that everyone attends keeps everyone on the same page and helps to avoid pockets of resistance.

Are the biggest struggles technical, cultural, or both?

TM: In my experience the biggest challenges are associated with shifting the culture within large enterprise organizations. The technology that is needed is well understood and widely available. The trick is in how to use this technology and how to clearly communicate your intentions to a large, and often global, workforce. It is very difficult to get hundreds or thousands of software practitioners all on the same page and behaving differently than they have in the past. As with any major shift in a business, successfully transforming your software development methodologies will require the executives to set clear, high-level business objectives and then measure the organization’s ability to meet those objectives.

GG: The biggest struggles by far are the cultural changes. The technical changes are very doable, but they will have limited impact on the business if you can’t get people to change how they work on a day-to-day basis. All it takes is a few developers not buying into the process to break the builds and impact the effectiveness of the entire organization. If the executives can’t get the organization to embrace the cultural changes, then they should not waste their time on technical solutions that on their own will provide limited improvements.

Based on your extensive experience at HP and Macys.com, can you describe the effects that are possible as a result of a DevOps transformation?

TM: Significant productivity gains in the range of 30%–50% can be achieved when an organization that is using an older methodology like Waterfall converts and begins applying Continuous Integration / Continuous Delivery and DevOps principles. Overhauling the fundamental principles of a large software organization is non-trivial and will take time and to be successful. The senior executives will need to stay directly engaged. However, the benefits are substantial. In many large enterprise organizations the software development budget is measured in tens or hundreds of millions. If even a 30% productivity gain is achieved, the business will have many options that are not available to this today. For example, the business can hold software spending steady and increase the number of products or features that are brought to market. Or, the business could hold throughput steady and re-invest the savings in other parts of the business. At the same time that these savings are being realized, the business can also expect to see a dramatic rise in the quality of the software that is being delivered.

GG: The productivity improvements and business impacts can be dramatic. Before we started the transformation at HP, firmware had been the bottleneck of the business for 2 decades and marketing had all but given up asking for new features. The dramatic impact that the transformation had on the business is as follows:

• Firmware no longer the bottleneck
• R&D costs reduced 45%
• 140% more products supported
• capacity for innovation from 5% to 40% of capacity

What do you feel is the biggest barrier to improving software development processes in large traditional organizations?

GG: Engaged executives that are willing to get into the details and lead the transformation. This transformation is not going to happen based on directives from on high or managing by metrics. Software development productivity is just too hard to measure. The executives are going to have to find the time to engage with the organization on the journey to get a more qualitative feel for what is working and what should be improved next. If the executives are not willing to take the time to engage with the organization at this level the transformation is much less likely to be successful.

What is the single most important thing that an executive can do to ensure the successful transformation of their enterprise level software development methodology?

TM: Stay directly involved. One of the fundamental principles of the Agile/DevOps methodologies is the practice of regularly reviewing what was delivered in the previous iteration and setting your next iteration goals based on your previous deliverables and learnings. Executives must follow this practice as well. Not at the level of each and every software feature, but rather at the business objective level. After each iteration, executives must review progress towards their business objectives and allocate resources to resolve any obstacles that are preventing their software teams from achieving those goals. For example, if productivity is not rising at the expected rate, the executives may ask “Why?” or “What are the parts of the development process that are taking too long or are too hard?” The next iteration must include the work needed to address these issues. Senior-level executives are generally the ones authorized to divert software development resources away from feature development and onto the work needed to solve tool and process problems. As such, they must stay directly involved to ensure that adequate resources are applied to solving the underlying challenges that are slowing down the progress of the transformation.