206-960-2891 robert@majureworks.com

When navigating digital change®, software value stream flow challenges bedevil organizations as they try translating disparate activities into valuable flows. For instance, I’ve spent a chunk of 2019 focused on rolling out a new software prioritization process for my organization and experienced plenty of challenges along the way. Mik Kersten’s book, “Project to Product”, proposes a new flow framework to help organizations address these challenges. Despite countless research, articles, and books, the software industry struggles to find common ground on which to reliably produce software-based value. On the contrary, automotive industries migrated to now, well-understood lean manufacturing systems. Hence, Mr. Kersten uses the automotive industry, specifically the Leipzig BMW plant, as the narrative anchor throughout the book.

Software value stream flow challenges analogous to automotive manufacturing line

Mr. Kersten proposes the Flow Framework™ as a way to solve software value stream flow challenges. He leads the reader through a progression of ideas with interim summary milestones along the journey. Thus, he organizes the book into an introduction plus three parts: The Flow Framework, Value Stream Metrics, and Value Stream Networks.

Five Historical Ages

Software value stream flow challenges in context of industrial revolution heavy iron machinery

In the introduction, Mr. Kersten frames a historical context of five ages:

  • Industrial Revolution
  • Age of Steam and Railways
  • Age of Steel and Heavy Engineering
  • Age of Oil and Mass Production
  • Age of Software and Digital

Within each age he defines an installation period, a turning point, and deployment period. For instance, he considers us fifty years into the current software and digital age with an undetermined amount of time left in the deployment period. He refers to this framing through the remainder of the book.

Addressing Software Value Stream Flow Challenges Using the Flow Framework™

Part I introduces the Flow Framework™ as a means to address software value stream flow challenges. Mr. Kersten spends much of Part I making the case for rethinking how software is developed and managed. First, he elaborates on the Age of Software and its disruptive nature. In addition, he articulates three epiphanies:

  1. Waste increases as software scales due to architecture-value stream disconnects
  2. Misapplying project management methods create value stream disconnects
  3. Linear manufacturing is not analogous to software value streams

Before describing the flow framework, he provides examples of failures (a large bank and Nokia) to further make the case for change. Finally, Part I concludes with introduction of four flow items:

  • Features delivering new business value
  • Defects fixing quality issues
  • Risks for security, governance, and compliance
  • Technical debt to remove impediments to future delivery

Value Stream Metrics

In contrast to Part I’s theme of making the case for change, Part II begins helping us visualize tangible ways to resolve software value stream flow challenges. Accordingly, Mr. Kersten introduces five flow metrics:

  • Flow distribution measuring allocation of flow items during a sprint or similar unit of time
  • Flow velocity measuring the number of flow items completed in a time period
  • Flow time indicating the the time required to traverse the flow stream toward release
  • Flow load quantifying the work-in-progress
  • Flow efficiency measuring the amount of time an item is actively worked versus the wait time

Anyone that has defined software metrics knows the challenge of connecting those metrics to business results. The Flow Framework™ includes four business result metrics:

  1. Value
  2. Cost
  3. Quality
  4. Staff happiness

Mr. Kersten lands Part II with negative examples from Equifax and Nokia and a positive one from Microsoft.

Value Stream Networks to the Rescue

At this point, the reader has journeyed through the preparatory material and is ready to visualize the Flow Framework™ in an enterprise environment. In Part III, Mr. Kersten pivots away from the automotive industry and introduces three networks: tool network, artifact network and value stream network. First, the tool and artifact network connect through an integration model. Furthermore, the artifact and value stream network connect through an activity model. Finally, the value stream network connects to business value through the product model. Moreover, he defines metrics to gauge the efficacy of these models: connectivity, traceability, and alignment indices.

Mr. Kersten devotes several pages to issue of tool proliferation and its negative effect on value streams. This resonated with me. For example, he noted how the tech giants develop their own in-house tools thus creating a competitive advantage.

Observations

“Project to Product” describes an elegant yet simple framework for addressing software value stream flow challenges. It is as good as I’ve seen to date and it influences my thinking. I especially like the flow elements of features, defects, risks, and debt. However, the tech industry continues to struggle in defining common ground on this topic. For this reason, the Flow Framework™ will remain one of many frameworks and processes circulating in the industry. Mr. Kersten accurately notes that our challenges arise from the networked nature of software value streams and the dissimilarity to the automotive industry’s linear flow.

This brings me to a criticism, or suggestion. We’re exhausting the software-automotive analogy with recent books such as this and others like “The Phoenix Project.” While I did appreciate the narrative thread of the BMW plant analogy, I found myself on page 183, near the end, reading that software value streams are not at all like linear automotive manufacturing, but like airline networks. While Mr. Kersten provided some initial exploration of the revised analogy, I was left pondering where he could have taken his thinking.

Software value stream flow challenges more analogous to an airline route map

As I mentioned earlier, I appreciated the discussion on the negative effects of tool proliferation. For example, even in my own work, I have to jump between Jira, Smartsheet, Slack, Microsoft Office, ServiceNow, Workplace and a host of other applications. Mr. Kersten refers to accidental complexity – I concur. Most importantly, this proliferation is a significant source of software value stream flow challenges. If an organization cannot budget a half a billion dollars annually on internal tool development, one needs effective governance strategies to remain competitive.

Summary

In summary, I recommend this book. I find the Flow Framework™ an effective foundation to think about your software value chains. It stimulated my thinking and yet leaves me prepared to add my own insights into the areas I manage.

%d bloggers like this: