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.