Overcoming Antipatterns of IT Transformation

Overcoming the most common mistakes large organizations make when trying to shift to DevOps, Agile or modernize apps

John Ediger – DevOps & Agile Transformation Leader

As a DevOps & Agile transformation consultant, one of the most common questions I get is, “what have other companies struggled with in their transformation attempts such that we can learn from their mistakes?”

Figure 1: Four of the most common antipatterns observed in large scale transformation and IT modernization attempts

This has inspired me to describe a short list of what I have observed as the most common and problematic antipatterns of transformation and modernization attempts, along with how to overcome these tendencies.

The use of the term antipattern is defined in the paper as, “a commonly repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results”.    Each of these four are very common, and understandably tempting.   Many IT leaders cut their teeth in a waterfall, plan-driven, and control-oriented world.   It’s not their fault.   An agile way of leading takes practice and learning but it also requires a bit of unlearning.

While the term “IT Transformation” is used widely and at varying levels, the scope used in this paper primarily involves efforts to radically improve business outcomes, speed, and agility by leveraging approaches such as Agile, DevOps, Cloud, and Applications Modernization.

Let’s first walk through the basic reasons that these four all too common antipatterns result in a failure to meet even the basic expectations of such transformations, and are often even detrimental to business outcomes.

  1. Modernize for modernization sake

We know that the majority of organizations today are contemplating or doing some sort of IT modernization and/or transformation.   Most are in some state of agile transformation and are looking to modernize their IT capabilities.  A 2018 survey1 by Statista showed only a measly 9% had not started to adopt DevOps or had no plans to do so.  Everyone else is transforming or getting ready to.  A rapidly growing number of organizations are pursuing cloud, shifting to microservices getting off mainframes or are engaging in app modernization projects.

There is nothing wrong with this of course.  The problem arises when these are pursued simply to modernize without specific outcomes or goals.   DevOps, for example, is a means to an end, not an end-state in itself.   The same is true for cloud, app refactoring, mainframe migration and other app modernization endeavors.  These are not easy undertakings and require a large commitment across the organization.

Likewise, agile transformations should be done with an intent to get specific benefits for the organization.  Without this intent, results may not be commensurate with the very large effort of making the switch.  With both DevOps and Agile, I’ve seen too many organizations stop short of realizing their expected large gains because they did not aim for specific outcomes.

The desired outcomes should also be realistic and match what DevOps and Agile actually are meant to do.   Some leaders have misperceptions about what an agile transformation can accomplish.   Just recently I was with a team who believed that agile will speed up code development and was trying to calculate what cost savings they can glean from an agile transformation.   Groups such as these often shoot way too low.  For example, rather than trying to get a 5% productivity gain from an IT department (which is not even the goal of agile in the first place), why not shoot for the larger gains that agile affords?

The true agile benefits are both more profound and more strategic.  Organizations which holistically adopt agile are able to rapidly respond to changes in the environment, including market, technology, competition, and other forces.   Another key benefit which dwarfs the benefits of solely focusing on the dev team efficiency is the ability to adjust plans quickly based on stakeholder feedback to get the right capabilities implemented to best meet the desired outcomes.   Rather than meeting a set of established requirements, agile teams work to meet business outcomes.  Instead of reducing their risk of not meeting a schedule, they reduce a bigger risk – the risk of not achieving desired results and outcomes with the right features.

As Mark Schwartz points out in his latest book, War and Peace and IT2, Microsoft found in a large study that among requirements, “only 1/3 of ideas actually accomplished their intended objective; another 1/3 actually had the opposite result, and 1/3 don’t have either effect”.  This is where agile shines – not in meeting documented requirements faster, but in implementing less of the wrong features and more of the right features.  The agile principle here is “maximizing the amount of work NOT done”.  Now rather than a small IT development productivity gain, we’re talking about much larger and more impactful productivity gains for the business overall.   But if an organization just sought after generic IT modernization by ‘doing agile” they may miss the greater gains and true power of “being agile”.

With a DevOps transformation effort, if the goal is simply to be “doing DevOps”, teams may reap some nice efficiencies or local optimization through the use of automation.  But the biggest results come from targeting specific and measurable desired outcomes, and leveraging the pertinent DevOps practices and patterns to achieve those.   Again, it’s not doing DevOps for DevOps sake, but meeting specific goals such as improved cycle time, measurable quality gains, and/or radical reductions in MTTR and change failure rates.

As DORA3-6 proved within their industry-wide studies, companies that made the most use of DevOps practices, with relentless focus on such specific measurable results, improved not just IT productivity, but company-wide results.  These companies were 1.53 times as likely to meet or exceed their organization’s goals such as profitability, market share, units sold, and operating efficiency.  They had 50% higher growth in market cap years7 over those companies that did not make this kind of deliberate and persistent use of DevOps practices.  These organizations did not achieve these results by generically modernizing just because it was the latest and greatest IT trend.

2. Big Bang Transformation

Another very common IT Transformation and Modernization anti-pattern that I have observed is where organizations attempt very large “big-bang” transformations.   We know these add significant risk and rarely work.   Regardless, they are still often attempted, and as a result can set organizations back further than had they never even tried the transformation in the first place.

Figure 2: From “Lean Enterprise – How High Performance Organizations Innovate at Scale” – Jez Humble, Joanne Molesky & Barry O’Reilly

This is well documented by many of the today’s leading IT thought leaders.  Jez Humble, Joanne Molesky & Barry O’Reilly in 2015, provided a good overview of the risks of this phenomenon in their book, Lean Enterprise8 (in my opinion a must read for all technology and business executives and leaders).  They show the humorous and all-to-familiar graph of organizations oscillating between “business as usual” and “change program” with a repeated sliding back to their previous state.   Beyond a big bang transformation being unsuccessful, it has the larger risk of reducing the appetite of leaders to attempt such a change again, citing that “we tried that, it didn’t work” or “see, I knew such a change was overrated … or not worth it”.

The ultimate irony is when leaders use a big-bang, plan-driven, waterfall approach when the transformation itself is to move off waterfall (to go agile and adopt DevOps).  Sounds crazy, but I see this all the time – going agile in a waterfall manner?!  (I even see this within service provider and consulting firms). The basis of agile is to be able to adjust plans and requirements based on learnings from incremental implementation and feedback loops.  This is a perfect fit for transformations especially because of the inevitable issues, roadblocks, and cultural inertia which can only be discovered through actual implementation attempts.  An agile approach allows for quick and flexible adjustments to the discovered roadblocks and constraints.  The misconception by many waterfall-minded leaders is that a strict and detailed roll-out plan provides more control and less risk.  Nothing could be further from the truth.  In fact the opposite is true.  For anyone with doubts about this, I recommend reading Mark Schwartz’s prior book, A Seat at the Table9, which provides a compelling (and humorous) view of risk, planning, requirements, governance, and transformation – all from an agile leadership vs. a waterfall-based perspective. 

The other problems with Big Bang transformations is that they tend to run long and yield results predominantly at the end of the transformation.  Given the rapid pace of IT advances and changes, this often leads to the necessity of starting a new transformation again as soon as the initial transformation has completed.  The recommended pattern here is to do continuous transformation and use an agile approach.  You get results as you go and you have flexibility to continuously adjust as the IT landscape changes.  Risk is reduced through transforming in small increments and making adjustments and removing impediments based on learning from the actions taken.   Lower risk, more control, more predictability, and more results!  This is the antidote for the Big Bang transformation anti pattern.  Agile at its finest.

3. One-size-fits-all adoption

This third antipattern of one-size-fits-all adoption I see most prominently with DevOps transformation efforts, but is also common with shifts to cloud, micro services, and several other transformation and modernization attempts.

Here’s how this anti pattern plays out for DevOps adoption.  An organization has some local successes with a couple teams, but they struggle to scale adoption broadly.  Using the approach well known by management for decades, they mandate “adoption” and create a status tracking mechanism measuring that every team adopts the tools and becomes “compliant” or “converted” to DevOps.

The problem with this is multifaceted.  First, it rarely yield results (more on this in anti pattern #4).  Second, DevOps is by definition a continuously improving endeavor, not something you finish, become compliant with or convert to. Third, and the part most often missed, is that DevOps includes a myriad of principles, practices, patterns and tools which can and should be applied selectively and in order of priority dependent upon the specific needs, goals, current state and challenges of each particular app or value stream.  Sure there are a few common tools and some common organizational DevOps patterns which may make sense to universally apply, but this is the exception, not the rule.

Let’s illustrate this by taking three actual simple examples (abbreviated case studies) of different value streams, as shown in the following table:

Figure 3: Three examples of application value streams showing current state
and recommended DevOps starting points based on Value Stream Mapping

There are endless examples, with apps of all types: COTS apps, mainframe apps, SAP apps, mobile apps, legacy apps, SaaS apps, apps in maintenance mode, mission critical apps, etc.   DevOps principles of fast flow, amplification of feedback loops, and continuous improvement/experimentation apply to all of these.  They all can make use of well-established DevOps/Agile/Lean patterns and practices such as continuous integration, everything in version control, shift left continuous testing, service virtualization, infrastructure-as-code, and combining dev, test and support engineering.  These are just a few of many dozen of DevOps options.   The trick is to NOT assume all value streams within one organization have the same current state, goals, needs and challenges and NOT to treat DevOps adoption as something that all teams must obediently comply to and ‘check the box’.   Unless of course the organization just wants to claim that they have “completed” a DevOps or Agile transformation, but they are not really interested in the results.

There is also a very important human factor with avoiding the one-size-fits-all anti-pattern.   I’ve heard Gary Gruver, an early DevOps transformation pioneer from HP (where I cut my teeth), tell this story multiple times.   You mandate to a skeptical team manager to implement DevOps, claiming it will dramatically improve their speed and quality.   They reluctantly comply, get limited results and say, “see, it did not really work”.

On the other hand, if you hold them accountable to specific speed and quality objectives, provide them a framework of a set of Agile and DevOps principles, practices and patterns, (along with coaching and training support) and let them determine the best way to achieve those results, teams will own the results and accomplish objectives much more effectively than any mandated checklist.

The one mandate I do recommend that all executives make, is for the team to adopt a disciplined continuous improvement and transformation process (aka DevOps Kaizen).   By setting the business objectives, and driving the continuous improvement process, executives will see much better transformation results than by mandating a one-size-fits-all checklist.

4.Technology and Tools only focus

This is the grandfather of transformation anti-patterns.  Intellectually, I believe most understand this – the fact that tools are the 20% and the 80% is about how teams work (culture, leadership, practices, principles, and mindset).   But when it comes to actual priority, emphasis and steps taken within transformation efforts, I see the majority of organizations expecting transformations to DevOps, Agile, Cloud, etc. be successful simply by rolling out tools, methodologies and lifecycle processes.

I have run countless DevOps/Agile leadership workshops and seminars talking about critical success factors in transformation where I emphasize this critical 80/20 rule.  Heads nod in agreement and understanding.  Then the questions start — the majority of them are about tools.

Figure 4: While tools are important, they pale in comparison to the culture change aspects of DevOps and Agile transformations

The tools are the easiest part of the equation, while the culture change is more challenging and more difficult to measure.   It’s no wonder that this is often over-looked as part of transformation efforts, but focusing only on the 20% (the tools) will at best get 20% of the benefits.

Numerous companies have asked for help and advice about how to scale DevOps adoption.   They have experienced pockets of success with a few small unicorn teams but are struggling with scaling beyond that.   They explain how they have provided and mandated a common toolchain.  But they are not seeing widespread adoption or they are not getting expected results.   Tools alone are not the answer.

The critical success factors for DevOps mostly center on how teams work.   This includes continually adopting rapid feedback loops, continuously optimizing end-to-end flow, continual improvement through hypotheses and experimentation, ownership of outcomes, collaboration, eliminating silos, automation, shifting left, empowering teams, etc.   Tools play an important role here but the tools are not the solution.   DevOps is not a set of tools, or the “onboarding” of tools.   Not even close.

A classic example is Jez Humble’s famous three questions10 where he asks an audience to raise their hands if they are “doing continuous integration”, which is one of many DevOps practices.  All those using CI tools, like Jenkins and doing automated builds and automated testing typically raise their hands.  He proceeds to have people keep their hands up only if “1) all the engineers pushing their code into trunk / master (not feature branches) on a daily basis, 2) every commit triggers a run of unit tests, and 3) when the build is broken, it is typically fixed within 10 minutes?”    The hands successively drop and by the end, there are very few really doing CI, and hence really getting expected results.   But the leadership team has rolled out the tools and the teams have “adopted” them. A similar antipattern exists with Agile.   Teams roll out agile by adopting not only the tool, but all the important ceremonies, such as with scrum, for example.   These are essential initial steps, but they don’t mean that these organizations are reaping sweeping benefits.   Agility is about much more than methodology.  As described in anti-pattern #1, many of these teams “do agile” but are not “being agile”.  They may go through the motions, using the tools and the methodology, but without truly incorporating the agile principles, continuously improving, and adopting agile end-to-end across functions (especially across leadership, governance, and business), results tend to be minimal.   Local optimization when adopting agile is a very common variation of this antipattern, sometime referred to as water-scrum-fall.

Antidote to the leading transformation antipatterns

Given these four primary transformation antipatterns …

  1. Modernizing for modernization sake,
  2. Big-bang transformation,
  3. One-size fits all adoption,
  4. Technology & Tool dominant focus,

…   what is the antidote?  What are the best ways to prevent and avoid these traps?

The first step is to understand and recognize these patterns when they happen.   Seems obvious, but waterfall ways of thinking are ingrained, and organizations are often unaware of the underlying mindset, culture and paradigm by which they are operating.  In addition, we need to replace these with proven principles, disciplined implementation methods and known successful transformation patterns.

Recommendation include:

  • Think of transformation as a continuous process that never ends rather than one big transformation or even a set of large projects
  • Use tried and true agile principles and practices for transformation, just as a team would for agile product development or maintenance, such as:
    • prioritized epic backlogs
    • hypothesis and action-driven rather than plan-driven
    • incremental results focus
    • doing small improvements followed by quick assessment and adjustments
  • Use a data driven approach, whereby transformation efforts are applied to value streams based on their specific outcome goals and challenges.   Adopt Value Stream Mapping (the right way).
  • Align leadership at all levels to support, encourage, and model a culture of continuous improvement where teams are empowered and accountable to measurable value stream goals.  This involves
    • sponsoring and tracking goals and kaizen iterations
    • addressing org-wide impediments
    • empowering teams
    • helping the organization fundamentally “get good at getting better”
  • Create an enablement team of coaches, rather than a heavy governance and/or compliance team, such as a traditional PMO
  • Partner with a Service Provider who applies these principles and approaches into their consulting, enablement, and delivery offerings.   This partnership helps an organization become self-sufficient in their continuous transformation and modernization efforts.

There are two core threads common to all these principles and patterns which are critical success factors:

  • Leadership & Culture
  • A system or framework for continuous transformation.

First, leadership culture change is paramount.  This culture shift requires multiple ingredients (too many to embellish upon in this paper), but these include a burning platform, a clear vision, and continuous development of executives, leaders and practitioners.   A good transformation consultant is highly recommended to help with this.  As DORA11 has also demonstrated, culture can also be influenced and changed through consistent application of practices, such as Continuous Delivery.   In other words, the adoption of technical practices from the bottom up can actually shift the broader organization culture. 

The development of leaders and practitioners cannot be underestimated.   The DevOps and Agile practices and tools have minimal impact without all levels of the organization understanding and embracing a body of knowledge of principles core philosophies which have revolutionized both IT and business.   These include but are not limited to the Agile Manifesto, Systems Thinking, DevOps-Lean Product Development, which entail elements such as Value Stream Management, Three Ways of DevOps, Kaizen, Minimal Viable Product, and Lean-Agile leadership.  This may sound like a lot, but these principles are the underpinnings of the absolute best way of developing and managing systems today.   These are proven science which continue to evolve and improve.   They are not fads or trends, and should be considered mandatory elements of the continuous learning and development curricula by leaders and practitioners alike.

As part of successful continuous transformations, leaders must understand, support, and apply Lean, DevOps and Agile principles and practices.

Continuous Transformation Factory Framework

The second core thread is a system or framework for continuous transformation.   Think of this as a continuous transformation factory building upon all the principles listed above.   It has a lightweight leadership prioritization mechanism using an epic-level Agile Kanban construct to make transformation work visible and limit WIP (work in process).  It’s analogous to a lightweight Portfolio SAFe framework but for transformation rather than solution development.   It leverages Value Stream Mapping and assessments to form lower level prioritized backlogs of transformation epics and stories.   And transformation work is done in sprints with rapid feedback cycles and adjustments, all aimed at business outcomes and measureable results.  A model of this continuous transformation factory framework is depicted below.

The emphasis of the Factory is to achieve measurable business results based on the specific value stream goals.  The teams leverage multiple modernization disciplines (e.g. agile, DevOps, app modernization, automation, and cloud native adoption) in a small-batch prioritized backlog manner.  Rather than approach one of these at a time across the enterprise, these are evaluated as a single set of possible countermeasures and transformation implementations to be applied based on the business needs and improvement goals of the individual value streams.

This is the ultimate antidote to the typical transformation shortcomings due to the all-too-common antipatterns described in this paper.  More details and case studies will follow as evolutions and various customized versions of it are currently being applied successfully across multiple companies.  Stay tuned.

Best of luck in your continuous transformation journey and remember to steer clear of those pesky antipatterns!

Notes:

  1. https://www.statista.com/statistics/673505/worldwide-software-development-survey-devops-adoption/
  2. Schwartz, War and Peace and IT (Portland, OR: IT Revolution, 2019)
  3. https://cloudplatformonline.com/2018-state-of-devops.html
  4. https://puppet.com/resources/whitepaper/2015-state-devops-report
  5. https://puppet.com/resources/whitepaper/2016-state-of-devops-report
  6. https://puppet.com/resources/whitepaper/2017-state-of-devops-report
  7. Forsgren, Humble, and Kim, Accelerate, (Portland, OR: IT Revolution, 2018), 212
  8. Humble, Molesky, O’Reilly, Lean Enterprise, (Sebastopol, CA: O’Reilly Media, Inc., 2015)
  9. Schwartz, A Seat at the Table (Portland, OR: IT Revolution, 2017)
  10. Fowler, Martin, Continuous Integration Certification, https://martinfowler.com/bliki/ContinuousIntegrationCertification.html
  11. Forsgren, Humble, and Kim, Accelerate, (Portland, OR: IT Revolution, 2018), 56-57,87-88

Review of “War and Peace (and I.T.)” by Mark Schwartz

John Ediger – DevOps & Agile Transformation leader

Mark Schwartz’s new book, “War & Peace & IT” is a light and quick read, while being both humorous and extremely insightful about leadership in the digital era. While much shorter and less philosophical than its namesake by Tolstoy, it uses Napoleonic analogies (and other lighter ones) to illustrate how we must change the way we lead in order to digitally transform our companies and survive.

I highly recommend this book for both I.T. and business leaders. I would put it up there with “Lean Enterprise” by Humble, Molesky & O’Reilly and Schwartz’s prior book, “A Seat at the Table”, as must reads for executives who want to learn to lead and compete in an Agile/DevOps/Lean world. This is now a world where DevOps and Agile have changed the way entire companies work, not simply the way IT teams work. Manufacturing companies that didn’t adopt Lean ways a few decades ago no longer exist. The same is happening now with software companies and the adoption of Agile and DevOps, but at a much broader level. And in case you missed it, just about every company is now a software company.

The only criticism I have for this book is that there is a fair amount of repeat from “A Seat at the Table”. But I’ll give him a pass as “A Seat At the Table” is worth repeating. It is that good. Plus, these revisited points from his prior book are profound — items such as, IT Leadership in an agile world, the vicious cycle of controlling IT, planning, requirements, transformation, enterprise architecture, build vs buy, governance, risk, and quality. I tried to boil down his “Seat at the Table” book to my top 10 favorite quotes, but there were so many that the best I could do was my top 13. Some are slightly paraphrased.

  1. “You cannot be agile while rigidly following a plan”
  2. “An agile approach can offer the predictability, control, and efficiency that he plan-driven approach cannot”
  3. “Agile projects are not controlled by conformance to plan but by conformance to business value. If the results don’t conform to the plan, the plan was wrong”
  4. “The problem with waterfall is not that requirements are defined in advance, the problem is that there are any requirements at all; … treat requirements as hypotheses”
  5. “At the root of this dysfunctional transformation cycle is in our distinction between the development of a system and its operation and maintenance”
  6. “An incremental dollar invested in an existing system is probably worth even more than an incremental dollar invested in building a new system”
  7. “To be agile, in a sense, means to always be transforming”
  8. “When we see the CIO’s role as controlling projects to deliver on time and on budget, we are missing his or her most critical responsibility”
  9. “Buying off-the-shelf is essentially another way of saying that we know all or most of our requirements in advance”
  10. “It seems strange that back in the Stone Age (yesterday) we believed that it was riskier to develop custom code than to buy”
  11. “Waterfall governance and oversight practices are not only inconsistent with Agile principles, but also fail to take advantage of the power of the Agile way of working”
  12. “In effect, the budgeting process should become a hypothesis testing process”
  13. “Failing projects should never be terminated; only successful ones”

In War and Peace, Mark references many of these same themes but adds even more perspective from the CEO and CFO purview, and adds a myriad of additional insights relevant to leadership in the new world we find ourselves in. There are way too many to comment upon in this review, but if you don’t plan on reading the book (a mistake for CEO’s, CFO’s and CIO’s especially) let me recap a few of my favorites.

One key theme is the dysfunctional relations between “Business and IT”. Just the fact that we still all call it “Business and IT” is a sign that this dysfunction is ingrained in our collective mindset. Rampant is an “us and them” relationship in which the business tries to “control” IT, and IT tries to treat “the business” as a customer. The fact that IT says “the business” is a clue to an ingrained us and them mindset. There are even many IT organizations who still have efforts underway to try to run their IT organization “as a business” — a well meaning endeavor, but a bit misguided from a big picture perspective of IT ideally just being part of the business, just as marketing or finance are.

This traditional “contractor-control” model also goes hand-in-hand with the plan-driven waterfall model where “the business” throws requirements over the wall to IT, and IT “fulfills the order”. In this world, IT is measured by their adherence to budget and schedule. Schwartz points out not only that this model does not work, but it creates unnecessary requirements and “feature bloat”, resulting in costs and inefficiencies from doing work which does not contribute to core business objectives whatsoever.

Through studies, examples, and humor, Schwartz makes the bottom line points that the interaction between IT and Business is the root of much of the waste, inefficiency, and long lead times for capability delivery. The traditional model increases risk, reduces predictability, and above all, undermines business outcomes. To put it in a positive light, he summarizes by saying, “the way we fit IT into the enterprise is the largest factor in fostering organization agility”.

A second core theme is about new ways to think about the business value of IT. We know that ROI (return on investment) is one of the worst ways of measuring IT value. The ‘Investment’ part of that equation is straightforward but the ‘Return’ part is tricky and it is short-sighted to think of software in terms of projects and try to measure the ‘return’. Schwartz has an entire book on this topic called “The Art of Business Value” in which he meanders through clues and common misguided definitions of business value. He then concludes that “business value is simply what the business values”. He expands on that that in “War and Peace” saying that we should have alignment cross-functionally such that business objectives are cascaded down to these cohesive teams that include both business and IT, and that “the leadership team of the enterprise set the vision that, in effect, defines what delivering business value will mean.”

Within this theme, he artfully describes the pitfalls of projects (most fail), the misguided approach of IT cost cutting and benchmarking IT spend ratios with revenue, and perils of IT being responsible for producing outputs instead of business value, among others. A better way to look at IT cost cutting in the digital world is to apply lean concepts to maximize efficiency. Alternate sources of value of IT such as maximizing learning, technical debt reduction to reduce future costs of development, risk mitigating investments, and the strategic value of flexibility to enable rapid response to environmental change. He argues that these become much more valuable “in the digital age — the age dominated by uncertainty”.

I also want to call out a minor theme Schwartz brings up because it is controversial and misunderstood — the criticism of outsourcing. He mentions it a few times throughout the book. Similar to how Nicole Forsgren and Jez Humble (of DORA & “Accelerate” – also a must read!) demonize outsourcing, you have to read the fine print of each of their criticisms. What they are recommending against is not outsourcing, but functional outsourcing, i.e. delegating specific functions such as just development, or testing, or support, to a service provider. I could not agree more. This is a DevOps antipattern and the DORA report shows a correlation of poor performing organizations with this type of outsourcing. But this does NOT mean that outsourcing overall is a bad practice. In fact, as I have witnessed first hand, that working with a service provider can help an organization become lean and agile and more successfully adopt DevOps practices than if they tried on their own. It depends upon the operating model, leadership, governance, measures, the contract, and of course whether or not the service provider is a DevOps/Agile organization themselves. I personally would never sign a contract with a service provider who is not holistically dedicated to embracing DevOps and Agile into the way they operate and throughout the skills of their workforce.

For example, DXC Technology, where I work, is the world’s leading independent end-to-end IT services company, and has a DevOps and Agile enablement offering to work with clients to help them with continuous transformation to DevOps-Agile practices at the leadership and the team levels. This includes enablement, coaches, consulting, and teams to operate within the client’s organization as cross-functional teams in an agile manner. Or clients can outsource all functions together and we work to align outcome goals with the business. So I would agree with Mark, Nicole, and Jez that certain types of outsourcing (e.g. functional, silo’d, IT separated from business, waterfall governed, plan-driven, output oriented) are bad. But also bad is the case where these same antipatterns are done in-house, without help from an service partner. With the right service provider and by leveraging all the best practices outlined in Nicole/Jez and Mark’s books, we can and do get clients to the level of high performing organizations, and beyond.

Rather than going too deep of some of the other core themes within “War and Peace”, let me list of few of my favorite quotes from the book, to compliment favorites from his prior book. This time I’ll keep it to a top 10 (not easy though):

  1. “…the way enterprises use technology is still based on the mental models from decades ago … like driving a horse and buggy on the freeway”
  2. “The right question to ask is whether the business objectives have been achieved, not whether all the requirements have been delivered”
  3. “Learning only helps you if you are nimble enough to make use of what you learn”
  4. “Writing a requirement is an arrogant gesture … requirements are risky”
  5. “The value of the enterprises capabilities (“the IT asset”) is not just what it can do today, but also in the latent value it has in its ability to adapt to the company’s future needs”
  6. “Reducing the cost of change is simply the definition of agility; to put it bluntly, risk is lack of agility”
  7. “We tend to attach too much weight to the risk of the new and too little weight to the risk of the status quo”
  8. “Bureaucracy is not the enemy of digital transformation; it is merely a codification of how the enterprise has operated until now”
  9. “Maximize the amount of work NOT done”
  10. “The key to digital transformation is to change the way IT and business work together”

Mark provides an incredible amount of wisdom and thought provoking insights behind each of these quotes, and throughout this book. He causes us as IT leaders to not only examine how much we need to learn, but what we need to unlearn, which I believe is the bigger challenge. This is one of the most important books for leaders since “The Lean Enterprise” came out back in 2015. It’s not just hyperbole or trendy any more to say that we must become agile across the organization and adopt DevOps to compete or even to survive. This has now become crystal clear. There is a huge chasm in leadership today between those who really internalize agility and continuous transformation and those who don’t.

Mark concludes the book with a very practical action plan about tying IT initiatives to business outcomes, shortening lead times, emphasizing delivery and results, and treating requirements as hypotheses. He walks through a succinct set of other changes to make, including getting rid of projects, investing in agility, automating controls, hiring T-Shaped people, and especially empowering IT to take ownership of business outcomes rather than just output.

The bottom line is that the change happening now in this digital era requires a very significant change not only in the way teams operate but also in the way business leaders think about technology in the enterprise, and also how we lead. It is a profound shift, not an incremental one. Mark is helping leaders make this mindset shift. Well, only those who read his book.