Re-Read Saturday, Project to Product, Week 8, Chapter 7: The Ground Truth of Enterprise Tool Networks

Before we dive in I would like to share an observation. I have re-read any number of books over the years. Some have not held up well and I just moved on; others reinforced the ideas and excitement I garnered during the first read and that is great. The really exciting re-reads are those that for whatever reason deliver new revelations. Project to Product is one of the later re-reads. This week is one of those big jumps for me — it did not start that way but a few things came together and there it was. We will wrap this re-read up in three or four entries and I will expand on a pattern I am seeing in how I synthesize information (hopefully it will be useful for you also). Now back to your previously scheduled re-read.

This week we begin Part III of Project to Product. In this portion of the book, Kersten puts the Flow Framework into motion. The core of these three chapters is the introduction of the idea of a value stream network. He introduces and defines the concept based on three epiphanies he had. Chapter 7: The Ground Truth of Enterprise Tool Networks introduces the first two epiphanies. They are:

Epiphany 1: Software productivity declines and thrashing increases as software scales, due to disconnects between the architecture and the value stream.

Epiphany 2: Disconnected software value streams are the bottlenecks to software productivity at scale. These value-stream disconnects are caused by the misapplication of the project-management model.

Those of us that have been in the world of software engineering (however loosely we want to use the word engineering) will recognize the truth of these two statements. The book does a great job at tracing Kersten’s journey to these ideas. On reflection, I think that acknowledging that disconnections cause real friction is the first step to recognizing that you have a real problem. Real problems do not magically go away.

Having studied how work is done for a number of years I have observed that disconnections accumulate over time. Small changes to practices are made to address a problem here and there, parts of the flow are ignored because it works well enough, and once an organization grows no one has an end-to-end view of what is being delivered. Just as technical debt accumulates in code, process and flow debt accumulates in the value stream. Kersten’s point about software development being an invisible flow (when compared to the flow of in a manufacturing system) provides a rationale for why it is so easy to ignore . . . until it is not.

As I re-read this chapter, I was struck by how often when helping teams and organizations to address their real need to deliver more value we talk about the need to continuously improve. I can remember using the phrase “inspect and adapt” at least five times this week alone. In many cases, it falls on deaf ears. Not for any lack of need or want, but rather because time and investment in improvement is not available. There is an old saying, “if you are up to your butt in alligators, it is hard to remember that your goal was to drain the swamp.” Flow and process debt must be acknowledged, measured, and retired or organizations will suffer the consequences (go back and re-re-read Chapter 6).

Seth Godin publishes a daily blog that I read religiously; this week he published, Stairstep and the curve (the same day I re-read chapter 7). He wrote, “One day we’re at one state or scale or system, and then we’re leaping to the next level.” Considering Kersten’s epiphanies and the journey required to generate the disconnects that generated those leaps of understanding, unless we truly invest the time and energy to understand the end-to-end value stream then continually improve it, we will be stuck in a sawtooth pattern of periodic crises.

Have you bought your copy? Project to Product https://amzn.to/2WzvPac (Amazon Affiliate Link)