In Chapter 1, The Age of Software, Kersten established that we were at or just past a turning point; those that do not embrace change will face grave difficulties surviving to the next cycle. As a consultant, I work with companies wrestling with trying to transform. Not all succeed for a variety of reasons. In this chapter, the author highlights and compares the lessons derived from his visit to the BMW plant, his study of the development of the Boeing Dreamliner, and the transformation failures at Nokia and a large bank. The first two examples reflect the pinnacle of a product view from the Age of Mass Production which preceded the Age of Software.

There are several lessons in this chapter to understand the Flow Framework. The first is that business outcomes are what matter rather than proxy metrics. Easier said than done because to understand or even identify outcomes organizations need to define their value streams from idea to delivery of value. In the case of BMW or Boeing, value is linked to the delivery of the product and support service across the car or plane’s life cycle. Banks, hospitals, or service organizations often don’t have a crisp understanding of their products. Most organizations refuse to define their value chains and therefore spend HUGE amounts of time, money, and effort optimizing parts of their organization that are not the bottleneck. I strongly suggest referring back to our re-read of The Goal, Actionable Agile, or Tendon’s Tame Your Workflow – there is a consistent theme focused on business outcomes and measuring flow to avoid local optimization. Identifying, defining, and measuring the value chain is hard, anyone that has tried whether they succeeded or not has a learning experience. I am being kind, sometimes a root canal without novocaine is less painful. But, that learning experience is NECESSARY for any transformation to have more than a random chance of success. Kersten recounts that the “large bank” failed three times because of a lack of IT and business integration, coordination, and communication. I suspect that in many of the failures, success was originally defined as training lots of teams, counting lots of commits and releases, and holding lots of meetings rather than delivering more value to the customer. At best these are proxies for what matters to the ultimate business.

Another lesson is that a focus on managing or reducing cost alone destroys capabilities. One of the most common structural issues to change is that IT is viewed monotonically as a cost center. This, again, is a failure to understand the value chain. I have worked in many organizations across many segments and industries. The output of some teams becomes an integral part of the products or services delivered to customers. The software used to account for, dispense, and in some cases compound drugs in a hospital is part of the value chain. The time accounting system for employees is not; while important it is an enabler. The pharmaceutical software is part of the product while the time accounting software supports it. My first job after I got my undergraduate degree was working for a women’s clothing manufacturer. For most of my time in the company, I worked in the marketing department forecasting sales to support production and the salesforce. Across the hall was the “help desk” (a misnomer – they actually coordinated all orders, shipments and had intimate contact with the customer). I was support, and they were on the value chain. When you are not on the value chain, controlling cost is a critical measure because your spend can only influence the bottom line of the P&L. Teams that are on the value need to focus on measuring business outcomes that impact the top line of the P&L. Measuring the wrong thing will deliver the wrong behaviors.

The bottom line of the chapter is that organizations need to shift their focus to products rather than projects. Products fit the age of software, while projects are a holdover concept from the age of mass production. Regardless of whether you embrace the cycle theory, the shift from project to product is code for breaking down the silos between IT and the business and teams within IT and then focusing on flow. Simple to say but this requires changing organizational structure and budgeting to fit value streams rather than departments and functionally specific teams. Another difference in this new paradigm is the need to establish product visions and roadmaps to channel work that focuses on value rather than local optimization.

Buy a copy today

This Week’s Installment:

Week 1: Foreword and Introduction – https://bit.ly/39gIt0A 

Week 2: Age of Software – https://bit.ly/2XYvqyI