Book: Leading the Transformation

“Leading the Transformation: Applying Agile and DevOps Principles at Scale” by Gary Gruver and Tommy Mouser

This is a good read that I would recommend to managers and leaders looking to transform your organization toward Agile and DevOps. This book is a short read and provides high-level directions and best practices leaders should do. For implementation how-to, the authors recommended other books for further reading. Here are my notes:

• Result of a transformation:
  “* Development costs reduced from ~ $ 100M to ~ $ 55M
  * 140% increase in the number of products being supported
  * Increased capacity for innovation from 5% to 40%”
• “how teams come together to deliver value in large organizations is the first-order effect, while how individual teams work was a second-order effect.”
• “Software development is such a discovery process that many of the assumptions made in the planning stage quickly become obsolete during development. Additionally, integration and qualification tends to uncover major issues late in the process, which results in frequent and costly schedule slips and/ or working the teams to death.”
• “there are much smaller iterations where complete features are integrated and qualified on a regular basis. Additionally, the entire code base is kept stable so that the code can be released at the end of each iteration, if required. This fixes the schedule and resources while letting the scope absorb the program uncertainty.”
• “The features are all worked on in priority order, with the most valuable features being developed first.”
• “Executives need to understand that the capacity of the organization to absorb change is the biggest constraint to rolling out these improvements.”
• “Therefore, as leaders we feel it is important, wherever possible, to provide the framework with the objectives and let the team have as much design flexibility in defining how the work will get done. It provides them with more interesting work, and they take more ownership of the results. In addition, when the situation changes, those doing the work are likely to sense it and adapt more quickly than an executive would.”
• “Having the executives and managers leading the transformation by setting the business objectives and running the continuous improvement process engages them in the transformation.”
• “Not having clear business objectives is a key source of the problem. If they started out by focusing on the business and just using DevOps ideas or implementing some Agile methods that would provide the biggest improvements, they would find it much easier to show bottom-line financial results.”
• “The first is the activity-based accounting and cycle-time approach that we used at HP. You start with a clear understanding of how people are spending their time and the value the software is intended to provide to your business. This approach addresses the biggest cost and cycle-time drivers that are not key to your business objectives.”
• “The other approach is to focus on the areas that are typically the biggest sources of inefficiencies in most enterprise software development efforts: maintaining always-releasable code and your planning processes. Then apply DevOps and Agile principles to these areas. The beauty of software is that once you develop a new feature, the marginal cost of delivering that feature should be almost zero.”
• “We just set in play a continuous improvement process where we would set objectives and review results each iteration . Additionally, we started focusing in on improving our build and integration process because this was where we thought we would get the best improvements in productivity.”
• “Executives can’t just manage this transformation with metrics. Since software productivity is so hard to measure, they must continuously engage with the organization and its people throughout the journey to get a qualitative feel for what is and isn’t working.”
• “creating a culture of continuous improvement where enterprise-level objectives are set and goals are defined for the iteration. Having iteration checkpoints with retrospectives and incorporating new ideas into the objectives for the next iteration are both essential parts of continuous improvement.”
• “Executives need to establish strategic objectives that make sense and that can be used to drive plans and track progress at the enterprise level.”
• “The leadership team would then spend most of their days walking the floor trying to understand where we were struggling and why.”
• “With this kind of trust comes transparency and with transparency comes a greater ability to fix issues quickly . As executives, we came to understand the importance of this culture shift.”
• “A culture of continuous improvement at the enterprise level is important for any large successful transformation .”
• “Creating a planning process that embraces the Agile principles starts with executives understanding and accepting long-term predictability for software schedules.”
• “For a relatively small investment in planning, you can get a reasonable first pass at the plan. More investment can result in better accuracy up to a point, until you start reaching diminishing returns on your investment.”
• “Therefore, organizations need to decide whether their primary objective is to deliver long-term accurate plans to its executives or if it is to deliver business value to its customers.”
• “Don’t lock in your most flexible asset to commitments for features that are not likely to meet your business objectives . Embrace the flexibility of software by creating a planning process that is designed take advantage of software’s unique flexibility so you can best respond to the ever-changing market.”
• “if these firm long-range commitments require 90– 110% of the capacity, this creates two significant problems. First, when the inevitable discovery does occur during development, you don’t have any built-in capacity to handle the adjustments. Second, you don’t have any capacity left to respond to new discoveries or shifts in the market.”
• “We worked to keep the long-range commitments to less than 50% of the capacity. For shorter time frames when there was less uncertainty, we would commit another 30%. Then for the last part of the capacity, we didn’t really plan but instead focused on delivering to a prioritized backlog. This approach built in flexibility with reserved capacity to respond to the inevitable changes in the market and discoveries during development.”
• “This just-in-time approach to managing our requirements provided a couple of key advantages. First, the investment in breaking the requirements down into more detail was delayed until we knew they would get prioritized for development. Second, since there were not large piles of requirements inventory in the system when the understanding of the market changed, there were not a lot of requirements that needed to be reworked. The net result of all these changes is that planning went from taking ~ 20% of the organization’s capacity down to less than 5%, freeing up an extra 15% of the capacity to focus on delivering business value.”
• “CD tends to cover all the technical approaches for improving code releases and DevOps tends to be focused on the cultural changes. From our perspective you really can’t make the technical changes without the cultural shifts.”
• “1. Improve the quality and speed of feedback for developers”
• “The objective here is to change the feedback process so that rather than beating up the developer for making mistakes they don’t even remember , there is a real-time process that helps them improve.”
• “Executives must ensure that both Development and Operations make the cultural shift of using the same tools and automation to build, test, and deploy if the transformation is going to be successful.”
• “2. Reduce the time and resources required to go from functionality complete or release branching to production”
• “Reducing this time requires automating your entire regression suite and implementing all-new testing so that it can be run every day during the development phase to provide rapid feedback to the developers.”
• “3. Improve the repeatability of the build, deploy, and test process”
• “4. Develop an automated deployment process that will enable you to quickly and efficiently find any deployment or environment issues”
• “5. Remove the duplication of work that comes from supporting multiple branches of similar code”
• “There are lots of different reasons you will hear for needing different branches. Some reasons are customer driven. Other reasons for different branches include the belief that you need branches at different levels of stability or that you will have to bring in architectural changes and different branches make that easier. All these issues have been solved by organizations that have learned how to develop on one trunk and have realized the efficiencies of this approach.”
• “Repeat this phrase until you become comfortable with it: ‘Branches are evil; branches are evil; branches are evil.'”
• “Rearchitecture through abstraction is a technique that allows you to refactor major parts of the code without breaking existing functionality. In this case, you find an interface in the code where you can start the refactoring. This interface should have a nice set of automated tests so you can ensure the new and old code will behave the same way with the rest of the system and you can test both the old and new code paths through this interface to make sure they are working. The old interface is used to keep the code base working until the new refactored code is ready.”
• “evolutionary database is a technique like versioned services that enables you to make database schema changes without breaking existing functionality. Similar to versioning services , instead of modifying the existing data, you add new versions with the schema changes and then deprecate the old versions when all the applications are ready.”
• “if you were going to commit code, you were required to stick around until the build was complete with the automated acceptance tests passing (green).”
• “making sure people were not continuing to commit code into a broken (red) build .”
• “For those developers that had their code auto-reverted, the system would send them an e-mail saying their code was rejected because a certain set of tests had failed. They were then responsible for fixing the issue and recommitting the code. This gave the developers time to fix the issue correctly without the rest of the organization breathing down their necks while the defect blocked the entire deployment pipeline.”
• “Gated commits enabled us to constantly have green builds and avoid train wrecks of broken builds without using the management team’s change management capacity.”
• “we would recommend taking the time to setup auto-revert or gated commits to drive this change. It will take a little more time to get started, but the rollout will go so much more smoothly that it is worth it.”
• “While technology can help, if the executives are not willing to lead and drive cultural changes like developing on trunk, then no amount of technology is going provide the necessary breakthroughs.”
• “The challenge for executives is leading people on the journey from nonbelievers to champions of the new way of working . It is important for executives to understand early on if the organization is embracing this cultural change, because if it doesn’t, all the investments in technical changes will be a waste of time.”
• “Expect to create, architect, and maintain at least as much test code and automation scripts as you create production code.”
• “traditional organizations frequently have tightly coupled legacy applications that can’t be developed and deployed independently . Ideally traditional organizations would clean up the architecture first, so that they could have the same benefits of working with smaller, faster-moving independent teams.”
• “If version 2 of all the components come together in this second build, but component B causes the build to go red, you need to be able to revert back to version 1 of component B and keep version 2 of everything else to get back to a green build. If you can do this with all the different components then you have this basic fundamental covered.”
• “First, if these componentized tests begin to fail, you have a high level of assurance that the functionality that is broken is actually the functionality that the test is designed to exercise. When the team begins to triage the test failures, the likelihood that it is not their failure has decreased dramatically. The team will now quickly learn to pay attention to the test results because a pass or fail is much more likely to be an accurate representation of the state of their functionality.”
• “The idea is to have the business write the specification in an executable form so the automated test and the specification are the same thing.”
• “Providing feedback to developers in an operation-like environment is a key first step that starts helping the organization right away.”
• “Determining if the organization will embrace these cultural changes up front is important because if they won’t, there is no sense in making big investments in technical solutions that on their own won’t help.”
• “The important point is to let the pain of increasing the frequency on this production-like environment drive the priority of your technical changes .”
• “First, more frequent build and test cycles means that fewer developers have committed code since the last build. Second, build up stable components or applications that get qualified and progressed forward to larger integrations of the enterprise system. Ideally the entire system would be fully deployed and tested with every new commit to quickly localize any system issues immediately down to an individual.”
• “First, build and test as much of the system as possible, as often as possible as one unit. Second, break down and simplify the problem by using service virtualization to isolate different parts of the system. Third, pick a subset of the testing for fast feedback before promoting the code forward to more stages for more extensive testing. This subset of tests defines the minimal level of stability that you will allow in the system at each stage of code progression.”

 

Advertisement