According to big data, as Seth Stephens-Davidowitz tells us in Everybody Lies,¹ only 9% of readers read the summary of a book, so why bother? I was sharing this nugget of information with my spouse as I was reluctantly contemplating how to end this book. She was incredulous; surely this piece of information is false, she claimed. During her writing of a PhD thesis in urban planning, she and her fellow doctorate students always flipped to the summary of a book or research to analyze the merits of the information.

Upon further pondering, I think I know where the discrepancy is. Big data analyzes the reading patterns of e-books, books in digital format, and one can only assume that flipping to the summary of a print book is much easier than scrolling to the ending of an e-book. Match that with reading patterns of print vs. digital books and you might conclude that the 9% mentioned above is quite misleading;² actually many readers might be flipping to the end of the book to read whether the author is worth his salt. On top of which, big data still doesn’t tell us who those 9% might be; maybe they are the most esteemed leaders of society? So here I am writing the summary.

We fail to empathize with our consumers : I started this book with a story about lean implementation in a color-coating manufacturing line. What I omitted is that we had data; we had lots and lots of data. As industrial engineers we were taught that we’ll find the answer in the data. The three of us sifted through 13 spreadsheet files detailing two years’ worth of production times. We analyzed them by every means an engineer can think of: filtering, sorting, statistical analysis, pivot tables, pivot charts, VBA macros, and nada. We couldn’t find the solution. The data measured outputs and we were interested in impacts. While the data was a first necessary step, it was a partial solution. We had to observe the process to gain the necessary insights. We had to spend day and night shifts with the employees; drink dark roasted coffee, no cream, no sugar, seven times boiled, with them; observe their behavior during the breaks; and notice the patterns of effort and speed. The data doesn’t tell us this story; the consumers do. Starting with the customer in mind is key. Accordingly, that was my first chapter. Lean thinking starts with empathizing with the consumer, and that’s something data can’t offer.

We lose the forest for the trees: During the same trip to Helsingborg, Sweden where I met Henrik Kniberg, I also had the opportunity to sit through Douglas Hubbard’s talk where he explained how to measure anything.³ What struck me the most wasn’t that we could measure anything that we wanted; rather, it was that the measurements we focus on often measure what we already know and don’t provide much value. As this was a project management conference, he shared his research demonstrating that the indicators we often monitor for predicting the success of a project were misleading. While the accurate indicator for project success was measured, it was lost in the vast amount of data we were accumulating! The concept was both innovative and stimulating, and it complemented a book I released previously that year. In The Agile PMO ,⁴ I describe how project management offices often invest inordinate effort in managing non-value-driven tasks. They encumber the organization with tools, techniques, and templates that are obstructing the delivery of value. They require compliance to impractical duration, cost estimating and time reporting in order to measure progress against the plan. However, Douglas Hubbard demonstrated that not only are PMOs wasteful, they also have little impact on project success. In this book, you notice this recurring pattern of waste. Too much data is waste. We are limited by our ability to analyze data and it often stands in the way of truly understanding where we are and where we’re heading.

We are bound to the data we observe and measure : Daniel Kahneman’s Thinking Fast and Slow describes a concept called WYSIATI—What You See Is All There Is. He continues to explain⁵ that WYSIATI means that we use the information we have as if it is the only information. We don’t spend much time saying, “Well, there is much we don’t know.” We make do with what we do know. And that concept is very central to the functioning of our mind. In other words, the data we measure provides an answer to what we were looking for in the first place. We are searching under the light rather than asking how big the area is outside the light. The user experience, product, and engineering team that was developing a new editor based on the surveys from the consumers and the feedback from marketing and operations was doing as they were told; they created a rich, customizable, feature-full solution based on the data that was analyzed. However, the data didn’t tell the story of what users really needed, which was a fast and simple-to-use editor, since it wasn’t what they were looking for in the first place. Another famous Daniel, Daniel Gilbert, a Harvard College Professor of Psychology at Harvard University, discusses the challenge in a famous TED talk and in his book⁶; people play the lottery since they see all the winners. They are oblivious to the losers.⁷ My niece wants to pursue a career in singing because she is infatuated with the success of her favorite singer without asking how many failed along the way. At the airport, the bookstands display successful businessman selling their secrets of success. However, how many have followed the same secret advice and never reached the airport bookstand? Thus, data tells us a skewed story, a partial story, rather than complete story, the story that’s hidden from sight. Of course, this isn’t the fault of the data, but the fault of the questions we are asking and the blind conviction with which we are treating it.

In this book, the idea that more is not better is a thread implicitly presented. In the introduction, I discussed my favorite microwave example. The device with more buttons doesn’t make it a better product; on the contrary, it makes it burdensome and complex. The various assumptions we might have concerning the product, market, and users are not validated. These are the same assumptions that are collected before the product is authorized by senior executives and are captured by the business analyst in page three of the marketing requirement document but are never revisited later. Rather than iteratively creating small releases of the product based on the assumptions and validating them with consumer feedback, the product is created “big bang” style and more often than not fails.

In the introduction, I explained that while many books have been written on lean, agile, design thinking, disciplined delivery, scaled agile, and lean user experience, we are missing the business agility driver and the unified engine integrating them to a single delivery model in the enterprise. I further described this in the first section, which illustrated the limits of the various methods and the tweaks and adaptations I made when scaling them to big businesses. The first chapter in this section explained that starting with the customer in mind is easier said than done. Inside-out thinking rules in organizations. Employees hide behind mounds of data, yielding them proficiently to fight back any suggestion regarding direct feedback from the consumer, while in truth they are terrified of that exact direct interaction with users, internal and external. I offered best practices to circumvent this fear and suggested the usage of a living persona that is constantly refined to pull the entrenched employees to interact with users. In the second chapter, I introduced objectives and key results (OKRs) as a mechanism to focus on a small number of objectives and collecting the right data that supports them. That is contrary to the many top-down KPIs that often organizations collect that hardly support the transformation. It is also an example of how too much data stands in the way of achieving the vision we set out to accomplish. In the third chapter, I described the myriad frameworks that organizations have in place, yet many are operating in a silo, not aligned with business outcomes and disconnected from one another. Once again, there’s a lot of data, but the value is not in more data; rather, it is in identifying and synthesizing an integrative operating model. The fourth chapter of section one discussed the challenges I had when introducing the concepts of vanity metrics and validated learning in enterprises. We are convinced that if we could measure and report just one more thing about anything, our results will improve. Measurement drives behavior; however is this the behavior we are trying to achieve? In agile implementation, executives are blinded by measuring teams’ velocity; that’s indeed more data but it yields the wrong metric and leads to bad team behavior and gaming the system. In the fifth and last chapter of the first section, I presented the lean startup concept of pivot or persevere. Enterprises fear pivoting. Once a project is approved, or a product is developed, it is very hard to kill it. Actually, the traditional data collection mechanisms that the enterprise puts in place are such that support the completion of the endeavour. Hardly ever does the data that we select to collect undermine the effort itself. In the rare occurrence that the data points to pivoting, the decision makers either ask for more data rather than act on what they have or ignore the data altogether.

The three chapters of part 2 described a framework, not a one-size-fit-all methodology, providing a set of tools and techniques with well-defined values and best practices while retaining the flexibility of implementation. The section focused on the transformation steps of the first 30 days, the first 90 days, and the first 12 months; it provided guidelines for rapid implementation. Success is based on the ability to move from long-held beliefs of central, data-driven decision making to embracing a local, lean agile team where decisions are based on feedback from the customer. The three case studies in section three told the same story: a lean agile transformation is about getting the organization to test small and respond quickly.

There’s nothing inherently wrong with collecting a lot data; rather it is our ability to comprehend and analyze large volumes of it, as well as the fact that the more you invest in collecting it, the more you are committed to it. This was already evident to me in 2005 when I was working as a program budget and schedule controller at a facility turnaround of a petrochemical plant. We were tasked with producing huge Gantt charts initially using Microsoft Project® and later on Primavera®. The 4,000 tasks in the schedule plan were of little use to the managers and I noticed that any plan that was more than 30 task entries was useless. The quest to identify and monitor every 6-hour-long activity of the 30-day petrochemical process plant turnaround was futile; more was less. The same phenomena occurred later at a medical device manufacturing plant where I was introduced to the NP complex problem of scheduling.⁸ Planning the sequence of parts to production was tricky; identifying the sequencing of the 75 plastic extruders and timing the production with the downstream assembly lines was next to impossible. I was consulting the vice president of operations; however, I wasn’t able to dissuade him from investing $525,000 to purchase software to optimize the scheduling process. A year later, scheduling software in place, the five manufacturing engineers spent three days once a month configuring the software with the data to generate production plans. The only problem was that a day into the cycle of the new plan, something would go wrong, a machine would break down, and the plan would go out the window.

This is not new. In Lean Thinking: Banish Waste and Create Wealth in Your Corporation, authors Womack and Jones⁹ describe the same pattern in production facilities: executives invest in the best and most expensive automatic production machine and software only to find out that it limits production flexibility and response time to the market. When faced with changing market conditions, more is less. The same problem is exposed in product management: running numerous focus groups, sending survey upon survey, gathering more and more data, yet unable to act upon it in a timely manner. Sometimes this is referred to as analysis paralysis.

More data isn’t bad in itself; our ability to act upon it is the challenge and the tendency to delay decisions and create larger and larger solutions. In that sense, lean agile enables local, relatively cheap, quick decisions. When the decisions are wrong, the impact is minimal.

To recap, I’d like to revisit the example of how a healthcare provider used the approach to strategize and execute the replacement of a policy administration back-end system it had in place for 50 years. Similar, costly replacement projects are everywhere and are often late in delivery, cost more than expected, with users hardly ever happy with the results. The system they had in place was outdated, overdue for change, and not able to support the consumer experience the company wanted to provide. Traditionally, these projects commence with a long stage of requirement gathering done through workshops, job shadowing, and interviews. The requirement document is extensive, there’s too much data that all too often both captures the legacy thinking that has been around the company for decades as well as lists numerous exceptions that occur rarely. The team created a synergetic unified delivery model and then used lean agile methods to identify the most important system elements that they then put in place, released internally, and received customer feedback on. Then they iteratively added new products and migrated existing ones based on discussions with the product, operations, marketing, and sales teams.

One might argue that since they replaced a legacy system, the full scope of functionality was predetermined. However, they learned that many existing legacy features were obsolete; others were developed in the past, taking into account legacy constraints that needed to be revisited; and yet others were based on regulatory interpretations that could be reassessed. These features would have found themselves part of the new system if the team followed the traditional approach to requirement gathering and project management. However, following lean agile principles, the team was able to shave off half of the normal forecasted duration, reduce cost, and, most importantly, deliver a system that was in line with the future vision rather than capturing legacy thinking.