What do you think?
Rate this book
Leading the Transformation: Applying Agile and DevOps Principles at Scale
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, providing a clear framework for improving development and delivery. Instead of the traditional Agile and DevOps approaches that focus on improving the effectiveness of teams, this book targets the coordination of work across teams in large organizations—an improvement that executives are uniquely positioned to lead.
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, providing a clear framework for improving development and delivery. Instead of the traditional Agile and DevOps approaches that focus on improving the effectiveness of teams, this book targets the coordination of work across teams in large organizations—an improvement that executives are uniquely positioned to lead.
113 pages, Kindle Edition
First published July 26, 2015
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 31 reviews
January 2, 2016
Very practical advice for leading the DevOps transformation including setting busibess objectives, practices to adopt, progress measures, and culture change. The audience is senior managers who must improve the stability and throughput of software delivered by their organization.
October 14, 2016
A practical guide for executives on how to apply Agile and DevOps principles to large organizations. This book is based on real-world experience at HP and it doesn't try to sugar coat how difficult such a transformation really is. They tell you up front that it took them 3 years, which is the right time scale for thinking about these issues. That's because it's not just about tossing in a few new technologies or techniques; it's about changing how people think, the goals of the organization, and the company's entire culture. It's a slow and painful process, but one that's well-worth doing.
Here are some of the new ideas and lessons I got from this book:
* Don't try to "do Agile" or "do DevOps". These are techniques for accomplishing a goal and not goals in and of themselves. The goals you should focus on are the ones that are important to your business, such as increasing productivity, releasing code more often, increasing the stability of code in production, and so on. Once you have these goals in mind, you can then pick tools from Agile or DevOps to accomplish those goals. But don't forget that these are just tools, and that your ultimate end goals are something else.
* Even once you've picked certain "tools" from Agile or DevOps, don't try to do everything all at once. For example, if you try to do continuous integration, continuous delivery, automated testing, trunk-based development, and 20 other DevOps techniques at the same time, then the project will become too large. Large projects require approval for large budgets; they require trying to prove that the project is a higher priority than other initiatives; they require going a long time without seeing any results or ROI; and most importantly, research has shown consistently that the larger the project, the more likely it is to fail. Instead, identify a small, incremental aspect of Agile or DevOps that will allow you to see improvements quickly. Implement just that aspect, which you can typically do with minimal approval, and allow everyone to see the impact it has. Then repeat the process again and again, each time biting off small chunks that each show an improvement.
* Focus on getting feedback a) as quickly as possible that b) localizes the problem as much as possible to the actual cause. If it takes weeks or months to get feedback, a developer won't remember what code was responsible or that they were even the one to write it, and fixing the issue will take much longer. On the other hand, if you can get feedback quickly--say, immediately after the commit--then the developer will know exactly the cause, know for sure they were responsible, and will be able to fix it quickly. Moreover, they will learn much more from rapid feedback, and if they can run the same tests locally, they are more likely to prevent the issue in the first place.
* Break tests into layers. For example, one layer of tests for each individual component; another layer for several components working together; another layer for the system as a whole. As you go up each level, the tests become more and more expensive (e.g. layer 1 may take seconds, layer 2 may take minutes, layer 3 may take hours). Therefore, you want to continuously identify "acceptance tests" at each layer that are most likely to prevent issues from slipping into the next layer. For example, if you see a test repeatedly failing in layer 3, that means you know how to test some particular type of functionality, but you're not doing it in the earlier layers. If this layer 3 failure happens often, then you may want to add a new acceptance test for this exact issue at layer 1 or 2, since those can catch the issue in seconds or minutes, instead of only catching it in layer 3, where it takes hours.
* When converting a testing process from manual to automated, don't just script the exact actions you would take manually. For example, a manual test for a credit card payment web page may involve going to the website, signing up for an account, clicking a confirmation email, logging in, entering your credit card details, ..., 15 other steps, and then clicking a "pay now" button. If you create an automated test that does these exact steps and the test fails, you won't know if the cause is that the "pay now" button is broken or any of the 20 steps before it. Automated tests can be designed in a fundamentally different way than manual testing that allows them to provide not only faster and more reliable feedback, but also much more localized feedback that points to the exact cause. A better alternative for the credit card test would be to configure the automated test to run on top of mock data where the user already has the account fully set up so that all the test has to do is click the "pay now" button. If that test fails, you can be more or less certain that it's the button that's broken and not any of the 20 prior steps.
The book does have some downsides.
* Most of the chapters are very high level: there are relatively few concrete technical recommendations, no architecture diagrams, and nothing resembling a line of code in the entire book. Perhaps that's because they expect the target audience to be semi-technical executives, but without concrete examples, it's hard to know how to apply some of the advice. Having worked at a company that went through a similar transformation, I was already familiar with most of the terms, but I imagine someone new to the ideas of Agile and DevOps would struggle to use this book, as it lacks sufficient technical detail for how to put these practices in motion. Fortunately, it's a quick read, and at the end, there is a list of further reading which includes several books with lots of technical details.
* Too many buzzwords. The writing sounds too much like managerial-speak, falling into the "kingdom of nouns" trap where they use a bunch of custom fancy-sound vocabulary (usually ending in "ion") instead of clearly expressing what they mean with simple verbs.
Finally, some of my favorite quotes:
“We see many companies that embark on a “do Agile” journey. They plan a big investment. They hire coaches to start training small Agile teams and plan a big organizational change. They go to conferences to benchmark how well they are “doing DevOps or Agile.” They see and feel improvements, but the management teams struggle to show bottom-line business results to the CFO. Not having clear business objectives is a key source of the problem.”
“Most traditional organizations, when faced with the reality of just how inaccurate their software planning processes are, tend to react by investing more and more in planning. They do this because they are convinced that with enough effort they will make their plan accurate. It works for every other part of their business, so why not with software? The reality is that with software you are reaching a point of diminishing returns, and at that point the best way to learn more about the schedule is to start writing code.”
“In traditional organizations when you describe the vision and direction of large-scale CD on trunk to the engineers, they immediately will tell you why it won’t work and how it will break when bringing in large changes [...] Once engineers have worked in an environment like this they can’t imagine having worked any other way. Before they have experienced it, though, they can’t imagine how it could ever work.”
“Let the pain of increasing the frequency on this production-like environment drive the priority of your technical changes. This will force you to fix the issues in priority order and provide the fastest time to value for the transformation.”
“Developers want to do a good job, and they assume they have until they get feedback to the contrary. If this feedback is delayed by weeks or months, then it can be seen as beating up developers for defects they don’t even remember creating. If feedback comes within a few hours of the developer commit and the tools and tests can accurately identify which commits introduced the problem, the feedback gets to engineers while they are still thinking about and working on that part of the code.”
Here are some of the new ideas and lessons I got from this book:
* Don't try to "do Agile" or "do DevOps". These are techniques for accomplishing a goal and not goals in and of themselves. The goals you should focus on are the ones that are important to your business, such as increasing productivity, releasing code more often, increasing the stability of code in production, and so on. Once you have these goals in mind, you can then pick tools from Agile or DevOps to accomplish those goals. But don't forget that these are just tools, and that your ultimate end goals are something else.
* Even once you've picked certain "tools" from Agile or DevOps, don't try to do everything all at once. For example, if you try to do continuous integration, continuous delivery, automated testing, trunk-based development, and 20 other DevOps techniques at the same time, then the project will become too large. Large projects require approval for large budgets; they require trying to prove that the project is a higher priority than other initiatives; they require going a long time without seeing any results or ROI; and most importantly, research has shown consistently that the larger the project, the more likely it is to fail. Instead, identify a small, incremental aspect of Agile or DevOps that will allow you to see improvements quickly. Implement just that aspect, which you can typically do with minimal approval, and allow everyone to see the impact it has. Then repeat the process again and again, each time biting off small chunks that each show an improvement.
* Focus on getting feedback a) as quickly as possible that b) localizes the problem as much as possible to the actual cause. If it takes weeks or months to get feedback, a developer won't remember what code was responsible or that they were even the one to write it, and fixing the issue will take much longer. On the other hand, if you can get feedback quickly--say, immediately after the commit--then the developer will know exactly the cause, know for sure they were responsible, and will be able to fix it quickly. Moreover, they will learn much more from rapid feedback, and if they can run the same tests locally, they are more likely to prevent the issue in the first place.
* Break tests into layers. For example, one layer of tests for each individual component; another layer for several components working together; another layer for the system as a whole. As you go up each level, the tests become more and more expensive (e.g. layer 1 may take seconds, layer 2 may take minutes, layer 3 may take hours). Therefore, you want to continuously identify "acceptance tests" at each layer that are most likely to prevent issues from slipping into the next layer. For example, if you see a test repeatedly failing in layer 3, that means you know how to test some particular type of functionality, but you're not doing it in the earlier layers. If this layer 3 failure happens often, then you may want to add a new acceptance test for this exact issue at layer 1 or 2, since those can catch the issue in seconds or minutes, instead of only catching it in layer 3, where it takes hours.
* When converting a testing process from manual to automated, don't just script the exact actions you would take manually. For example, a manual test for a credit card payment web page may involve going to the website, signing up for an account, clicking a confirmation email, logging in, entering your credit card details, ..., 15 other steps, and then clicking a "pay now" button. If you create an automated test that does these exact steps and the test fails, you won't know if the cause is that the "pay now" button is broken or any of the 20 steps before it. Automated tests can be designed in a fundamentally different way than manual testing that allows them to provide not only faster and more reliable feedback, but also much more localized feedback that points to the exact cause. A better alternative for the credit card test would be to configure the automated test to run on top of mock data where the user already has the account fully set up so that all the test has to do is click the "pay now" button. If that test fails, you can be more or less certain that it's the button that's broken and not any of the 20 prior steps.
The book does have some downsides.
* Most of the chapters are very high level: there are relatively few concrete technical recommendations, no architecture diagrams, and nothing resembling a line of code in the entire book. Perhaps that's because they expect the target audience to be semi-technical executives, but without concrete examples, it's hard to know how to apply some of the advice. Having worked at a company that went through a similar transformation, I was already familiar with most of the terms, but I imagine someone new to the ideas of Agile and DevOps would struggle to use this book, as it lacks sufficient technical detail for how to put these practices in motion. Fortunately, it's a quick read, and at the end, there is a list of further reading which includes several books with lots of technical details.
* Too many buzzwords. The writing sounds too much like managerial-speak, falling into the "kingdom of nouns" trap where they use a bunch of custom fancy-sound vocabulary (usually ending in "ion") instead of clearly expressing what they mean with simple verbs.
Finally, some of my favorite quotes:
“We see many companies that embark on a “do Agile” journey. They plan a big investment. They hire coaches to start training small Agile teams and plan a big organizational change. They go to conferences to benchmark how well they are “doing DevOps or Agile.” They see and feel improvements, but the management teams struggle to show bottom-line business results to the CFO. Not having clear business objectives is a key source of the problem.”
“Most traditional organizations, when faced with the reality of just how inaccurate their software planning processes are, tend to react by investing more and more in planning. They do this because they are convinced that with enough effort they will make their plan accurate. It works for every other part of their business, so why not with software? The reality is that with software you are reaching a point of diminishing returns, and at that point the best way to learn more about the schedule is to start writing code.”
“In traditional organizations when you describe the vision and direction of large-scale CD on trunk to the engineers, they immediately will tell you why it won’t work and how it will break when bringing in large changes [...] Once engineers have worked in an environment like this they can’t imagine having worked any other way. Before they have experienced it, though, they can’t imagine how it could ever work.”
“Let the pain of increasing the frequency on this production-like environment drive the priority of your technical changes. This will force you to fix the issues in priority order and provide the fastest time to value for the transformation.”
“Developers want to do a good job, and they assume they have until they get feedback to the contrary. If this feedback is delayed by weeks or months, then it can be seen as beating up developers for defects they don’t even remember creating. If feedback comes within a few hours of the developer commit and the tools and tests can accurately identify which commits introduced the problem, the feedback gets to engineers while they are still thinking about and working on that part of the code.”
June 29, 2017
A quick introduction to the core ideas around extending continuous improvement to software operations. By focusing on large enterprises it shows how concepts are applied outside the domain you might expect. The ideas are developed in terms of concrete business objectives. The explanations are very clear. They discuss the concepts that need to be evangelized to drive the shift to continuous development, rigorous testing, and rapid development cycles in a large organization and are clear about the benefits.
A small book, it is a bit dense so it will take a little longer to read than one might expect.
A small book, it is a bit dense so it will take a little longer to read than one might expect.
December 31, 2019
A concise 100-pages book on how to drive Agile and DevOps transformation for executives, a distilled learning from the HP printer case study as famously referred in the Continuous Delivery book. This book serves greatly as introductory materials for executives who want to understand why they should adopt Agile and DevOps and what important technical practices to drive in order to be highly successful. The case study referred showed that such transformation is possible in any type of software projects, provided that proper business objectives are set with determination to shift the culture and embrace continuous improvement process.
March 28, 2021
This was one the top 10 DevOps books from the LinkedIN learning path for DevOps engineering.
The book ‘Leading The Transformation’ is aimed at inspiring executive leaders to understand how software is unlike other products with it being so flexible and changeable. Because of this, it needs to be managed in a very nimble fashion, a.k.a using Agile development practices. The book went into enough detail to provide technical description and examples of DevOps tooling, such as Continuous Delivery pipelines.
The book ‘Leading The Transformation’ is aimed at inspiring executive leaders to understand how software is unlike other products with it being so flexible and changeable. Because of this, it needs to be managed in a very nimble fashion, a.k.a using Agile development practices. The book went into enough detail to provide technical description and examples of DevOps tooling, such as Continuous Delivery pipelines.
January 30, 2023
Knowledge Level: Basic
Audience: Whoever wants to understand the principles of DevOps and introduction to agile.
Review: The author explains the principles of DevOps with examples of his implementation in HP. It's small and easy/quick to read
Audio Candidate: Yes
Lessons Learned: Companies should start the transformation at the organizational level, not the team level. Framework: Business Objectives, Continuous process in place and apply agile at scale. The big challenge is cultural change.
Audience: Whoever wants to understand the principles of DevOps and introduction to agile.
Review: The author explains the principles of DevOps with examples of his implementation in HP. It's small and easy/quick to read
Audio Candidate: Yes
Lessons Learned: Companies should start the transformation at the organizational level, not the team level. Framework: Business Objectives, Continuous process in place and apply agile at scale. The big challenge is cultural change.
November 22, 2017
This book is a quick read, maybe a little too quick/efficient/terse. The main idea presented - that executives need to maintain a clear, ongoing set of business priorities that can guide enterprise-level DevOps and continuous delivery transformations - is well-taken, but they could have provided a more robust analysis/conversation that addressed some of the other factors that may have helped or hurt their own experience at HP. However, what I got out was well worth the time I put in.
March 26, 2022
Essence of Agile and DevOps distilled into less than 100 pages. Rather a long article than a book. Perfect for leaders who really want to make a change.
Agile and DevOps have become just another set of buzzwords to create new "Transformation Leader" roles, Center of Excellence teams etc. Instead of creating large scale agile transformation projects people should focus on small scale changes on team level and leading by example.
Agile and DevOps have become just another set of buzzwords to create new "Transformation Leader" roles, Center of Excellence teams etc. Instead of creating large scale agile transformation projects people should focus on small scale changes on team level and leading by example.
August 10, 2018
This book really focusses on the technical challenges teams run into when moving to continuous integration and deployment. It highlights the balance between the cultural and technical changes and the support of leadership. Highly recommend for people working in large organisations working with legacy code bases.
December 26, 2022
Really good book on Devops. Ideal for any team/organization that is starting to apply it or is thinking into.
Based on a real word example (HP) every chapter brings an idea and how it was applied. Easy to follow and understand. Lacking a bit more examples, but for the size of the book, you cannot ask for better.
Based on a real word example (HP) every chapter brings an idea and how it was applied. Easy to follow and understand. Lacking a bit more examples, but for the size of the book, you cannot ask for better.
August 22, 2018
Excellent executive level summary of Agile and DevOps principles. A good gateway drug to get the more resistant leaders in your organization to understand the imperatives and benefits for evolving your org.
July 10, 2019
No nonsense fast overview of HP's dev ops mindset change. There are a lot of sage wisdom in this fast read. The big nugget, move toward a continually stable trunk and release often if you want to enable a true change.
The bits on firmware and embedded also echo some of my experiences as well.
The bits on firmware and embedded also echo some of my experiences as well.
July 23, 2020
A great simple book that does a really good job summarizing some of the devops and agile principles. Would recommend. Will reference and already have multiple times. Really gold for enterprises trying to go to agile.
April 3, 2022
A good executive/leadership view of how to enable your organisation's technology. I followed this up with the White Belt certification and highly recommend the book and course to anyone struggling with legacy technology and a desire to deliver software and technology faster and safer.
February 11, 2019
How can you make agile methods work in organisations
January 26, 2020
I enjoyed the background on Toyota Kata, 6 sigma, Kanban and how manufacturing has its place in software development. The book was repetitive and failed to spark many new insights.
June 25, 2020
Quick to the point tips on implementation. Moreover being an audio book, you can listen to it while walking or commuting to office.
April 14, 2022
not sure why this is still in my currently reading list, finished this ages ago. Not bad. certainly useful information in it.
December 20, 2016
I recommend this, one of my favourite transformation books. Choir-preaching to be sure. Compared to
Lean Enterprise: How High Performance Organizations Innovate at Scale
, which I'd suggest reading first, Leading the Transformation covered slightly different ground and greater depth in the areas of DevOps. A big take-away is the need to get executive commitment in order to effect meaningful change, which must be orchestrated through change management. Although The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses started a lot of this conversation, this and others extend to larger organisations.
September 21, 2017
A quick and enjoyable read grasping the broad scope of how one applying agile and devops in larger organizations. Note that this book mostly covers the principles and not the details on how to apply it. I also liked that they had reference cases throughout the book to back their points.
November 29, 2015
Solid overview And techniques to succeed
I liked the fact that the book focused on how to mature the environment to get to DevOps. Pragmatism and focus on continuous improvement rather than trying to force by the Agile book. If you are thinking about DevOps or you think you already it, important you check this book out.
It is clear that the authors' experience is centered around product, similar experience applies to IT application development. Similar is not same. Would be better to articulate the distinction.
I liked the fact that the book focused on how to mature the environment to get to DevOps. Pragmatism and focus on continuous improvement rather than trying to force by the Agile book. If you are thinking about DevOps or you think you already it, important you check this book out.
It is clear that the authors' experience is centered around product, similar experience applies to IT application development. Similar is not same. Would be better to articulate the distinction.
July 26, 2016
A nice summary of what it takes to turn around large-scale enterprise software development processes. If, like me, you are not a CTO of a large enterprise, you'll spend a lot of the book nodding in agreement and feeling like there's not a ton you can do about any of it without executive buy in. As far as the writing style, this was an excellent bed time read, so good, in fact, that it took me over a month to finish 100 pages. This book could have benefited from a proofreader as well.
June 7, 2016
This is a very good book for executives leading organizations and businesses whose primary function is software development. Hats off to the authors for discussing pragmatic ways that large traditional organizations can employ when making the turn to agile operating principles.
September 1, 2018
As a transformation consultant, this is my new go to recommendation for executive leadership. This book is a quick but detailed read on how and more importantly why companies perform agile/devops transformations.
March 30, 2016
Great Starter on DevOps!
This book was exactly what I was looking for and I highly recommend if you're an executive or manager planning or pondering this change!
This book was exactly what I was looking for and I highly recommend if you're an executive or manager planning or pondering this change!
June 4, 2016
Really interesting book for senior leader wish to bring improvement in their development cycle. The transformation approach is really interesting.
April 9, 2016
A good summary on moving from Waterfall to Devops company-wide . Based on the author experience at HP's Printer Division.
July 22, 2019
Great story, well put together
April 18, 2017
First the good stuff: the book is fast (you can read it over an evening), free of any technical mumbo=jumbo and the best thing is that it doesn't talk of any one specific framework. It provides a generic thinking on how an enterprise can go about applying agile and devops principles at scale. It gives elaborate guidance on what all should be done to improve test automation, or building a gating system to improve builds at enterprise level, and so on.
Now the not-so-good stuff. There is no real mention of "agile" in the way agile practitioners understand or practice it. While the discussion on delivery pipeline is highly relevant, the discussion is devoid of agile practices, or agile engineering methods and so on. Of course, as the authors mention in the beginning of the book - they found more value in how the team came together than in how individual teams actually did their work, the same theme seems to present throughout the book. So, the book is a good starting point for someone to start thinking of how to improve the build and release pipeline, but not agile par se.
Now the not-so-good stuff. There is no real mention of "agile" in the way agile practitioners understand or practice it. While the discussion on delivery pipeline is highly relevant, the discussion is devoid of agile practices, or agile engineering methods and so on. Of course, as the authors mention in the beginning of the book - they found more value in how the team came together than in how individual teams actually did their work, the same theme seems to present throughout the book. So, the book is a good starting point for someone to start thinking of how to improve the build and release pipeline, but not agile par se.
Read
May 28, 2018Good read with a background of revolutionizing firmware development at HP. Stresses that we need to follow business value rather than just implement agile / lean / DevOps in 7 steps.
Displaying 1 - 30 of 31 reviews