is an experienced executive with a proven track record of transforming software development processes and working with executives in large organizations. As co-author of A Practical Approach to Large-Scale Agile Development, he documented how HP revolutionized software development while he was the director of the LaserJet Firmware development lab at HP. As VP of QE, Release, and Operations at Macys.com he led their transition to continuous delivery. Gary currently lives in Idaho with his wife and enjoys skiing, hiking, and mountain biking.
Starting and Scaling DevOps in the Enterprise is a quick, easy-to-read guide that helps structure those improvements by providing a framework that large organizations can use to understand DevOps principles in the context of their current development processes and gain alignment across the organization for successful implementations.
The book illustrates how to analyze your current development and delivery processes to ensure you gain positive momentum by implementing the DevOps practices that will have the greatest immediate impact on the productivity of your organization, with the goal of achieving continuous improvement over time.
Software is becoming more and more important across a broad range of industries, yet most technology executives struggle to deliver software improvements their businesses require. Leading-edge companies like Amazon and Google are applying DevOps and Agile principles to deliver large software projects faster than anyone thought possible. But most executives don’t understand how to transform their current legacy systems and processes to scale these principles across their organizations.
"Leading the Transformation" is an executive guide to transforming software development processes in large organizations. The book and presentation focus on showing executives how to lead the transformation of Enterprise scale software development processes. Instead of the traditional Agile and DevOps approaches that focus on improving the effectiveness of teams, this book targets the biggest inefficiencies in most large organizations that executives are uniquely positioned to address, which is coordinating the work across teams.
Today, even the largest development organizations are turning to agile methodologies, seeking major productivity and quality improvements. However, large-scale agile development is difficult, and publicly available case studies have been scarce. Now, three agile pioneers at Hewlett-Packard present a candid, start-to-finish insider’s look at how they’ve succeeded with agile in one of the company’s most mission-critical software environments: firmware for HP LaserJet printers.
This book tells the story of an extraordinary experiment and journey. Could agile principles be applied to re-architect an enormous legacy code base? Could agile enable both timely delivery and ongoing innovation? Could it really be applied to 400+ developers distributed across four states, three continents, and four business units? Could it go beyond delivering incremental gains, to meet the stretch goal of 10x developer productivity improvements?
It could, and it did—but getting there was not easy.
Writing for both managers and technologists, the authors candidly discuss both their successes and failures, presenting actionable lessons for other development organizations, as well as approaches that have proven themselves repeatedly in HP’s challenging environment. They not only illuminate the potential benefits of agile in large-scale development, they also systematically show how these benefits can actually be achieved.
Gary is an executive with years of experience transforming software delivery processes at enterprises as diverse as HP and macys.com. For keynote addresses, Gary presents to various audiences about the benefits and pitfalls of applying Agile and Dev-Ops principles to software development teams. Gary focuses on the two most commonly unmet business needs: time to innovation, and product reliability. In doing so, he breaks down the development and deployment process issues that block improvement. Gary examines code management and architecture, automated testing, and the deployment pipeline in order to illustrate existing inefficiencies and highlight solution strategies. His passion and experience provide the inspiration for executives to create and implement a practical, continuous improvement plan.
Gary’s executive workshops are designed to prepare C-Level and SVP-Level executives to lead the transformation of their software development processes. These workshops lead teams through a review of possible improvements and highlight the challenges of enterprise transformation. They focus on engaging management teams to coordinate and implement the cultural changes required to successfully implement DevOps principles. Participants will clarify business objectives, paint a vision for the organization, prioritize improvement efforts, and track progress.
Hands-on workshops for VPs and directors define business objectives and identify cost drivers, schedule drivers, and areas of improvement. Gary walks participants through the steps of defining and assigning concrete sprint objectives. These workshops are designed to fine tune the process of selecting and utilizing the appropriate agile tools to deliver results. Rather than prescribe processes, Gary empowers participants to discover their cost drivers and own the implementation of process improvements.
As I start interacting more with the DevOps community, I have started hearing more and more concerns about resistance to changes due to audit and regulatory compliance concerns. I have found this somewhat surprising because I had not run into these issues while leading large-scale transformations. In fact, in my experience I have found audit to be a great partner in supporting these changes once they understood the benefits it provides them and the business. Therefore, I thought it would be valuable to write a quick post to show how a DevOps transformation with the rigors of a solid continuous delivery pipeline can improve the business and simplify/improve the auditing process. The goal in sharing this perspective is to help other organizations understand how the DevOps teams and audit can work together to simplify the processes while ensuring the audit and regulatory compliance requirements are fulfilled.
The goal of auditing is to reduce business risk by ensuring the organization is following appropriate processes. For software development this is done by understanding the processes that are designed to support the software development life-cycle and are managing changes appropriately. The auditing team then comes in usually annually to provide a 3rd party review of the organization to ensure they are following the agreed upon processes. This is done by interviewing team members and searching for evidence that the processes are being followed. This typically requires tracking of sample of changes and approvals through various different documentation tools to ensure that the people in the organization are properly following the process and documenting all of the changes. It is important to provide these audits because people are not very good at following all the process details especially when they get in a hurry so audits are put in place they are accountable for following the process. The continuous delivery pipeline addresses the inherent inconsistency in people by automating the process.
The first step is understanding the objective of the different steps in the current auditing process. The next step is understanding how the development processes are going to change as the organization implements an automated continuous delivery pipeline. Then the team needs to define how best to achieve the objectives of the auditing process using the new development processes.
This frequently starts with an understanding of the current processes with all the checks and balances for gating changes into production. These gates are frequently just approvals by people based on criteria that are not documented or consistent. When you are automating the deployment pipeline you will need to spend time with the gatekeepers to clarify and document their criteria so you can execute them with automated tests.
The processes and environments will also need to be clearly documented so it can be automated with scripted environments, scripted deployments, evolutionary database, test automation, and source code management tools. This rigor puts everything that defines any changes that will happen in production from application code and environment definition to the automated tests that were used for approval under tight computer controls. You can then work with the audit team to agree upon exactly what information should be stored where for audit purposed. Then as you are setting up the automated deployment pipeline include them in customer acceptance testing of the all the audit data. This may take some work to debug your automation to ensure it is collecting all the right data in all the right places but once that is done you will know the process is followed correctly every time and the right data is being collected for every change instead of just relying on a sample audit.
Probably the biggest change between before and after the transformation is how the processes are being managed and how you ensure the process is being followed. Before the transformation you are trying to ensure humans are consistently following a defined process. This is something that humans are not good at so it requires a lot of detailed oversight.
After the transformation almost all of the process is automated and changes are all automatically documented. You are no longer dependent on an individual updating the results of their manual testing in a document. In fact you are not reliant at all on a human to ensure the process is followed for each change. Instead you are dependent on ensuring the computers execute the same automation in the same way every time, which is something computers do very well. Anyone that has raised teenagers and worked with computers can appreciate how much better computers are at doing what they are told every time.