Have you read Accelerate yet? If you haven’t, you might want to go read that one first and come back to Kersten’s book, Project to Product.
When I think about how software is trying to reinvent itself, Accelerate, by Nicole Forsgren, Gene Kim, and Jez Humble is the book that presents the business case for why speed and safety can be the same thing and can improve business outcomes. Dominica DeGrandis starts to unpack the how of restructuring work to support speed and detect workflow problems in Making Work Visible. In that context, Mik Kersten’s Project to Product is about why this transformation in speed and delivery cannot stop at the boundaries of the technology part of the company.
Lots of us who have been working in technology a while know that there is a failure mode where the organization gets all excited about TRANSFORMATION. If you’ve been around for a while, you have a knee jerk cynical reaction to this, because you’ve been through transformations before and they don’t work. At some point, you run into this problem where you can be as agile as you want, up to a certain level, and then an executive is going to say that they understand all that, but what is your commitment for this quarter? There’s this thing where no matter what you do in IT, the rest of the organization isn’t aligned with it, and so you end up doing it halfway.
Taking a holistic view
If you’re lucky, sometimes you’re working for a software company and they actually understand this, but there are a lot more software people working for non-software companies than there are in “the industry”. I’m in Minnesota, so I think of 3M, Medtronic, Target, and Best Buy. They’re not making software for outside consumption, but they are building internal tools, websites, pacemakers, and manufacturing tools—all of which require SO MUCH CODING.
Project to Product is the book about how companies as a whole can take the things we’ve learned from the devops transformation and other innovations, and apply it to what we’re doing. Not just “how do I make better software”, but “how do I make sure I’m making the right software?” and “should I be buying software or building it?” and “how do I know if I’m making any money?”.
The core thesis of this book is that it is possible to look at what value any given activity has for the business, and balance that against future needs. Kersten breaks the work of business value into four chunks:
- Features (new things people want to buy)
- Defects (things that need to be fixed to maintain quality)
- Risks (security vulnerabilities or other things that expose users to harm, or losing product/market fit)
- Debt (work that has been put off, maintenance, updating platforms)
100% of the value of what an organization produces lies in those. A simplistic reading would make you think that psychological safety, accessibility, and inclusion don’t fall in those categories, but Kersten makes it clear that they do. For example, failing to support and promote under-indexed team members induces risk (because the teams and products aren’t as representative) and debt (because backfilling is an avoidable drag on velocity).
How do you decide what percentage of your efforts to allocate to each of these kinds of work? You figure out the value of what you’re producing. Value is not the same as cost or price. For example, Facebook’s value is not about being paid by end users, but selling advertising and user data. The value stream includes features that will encourage users to engage more, but also new ways to extract and share information with the people purchasing it. If they spent all their development effort on the paying customers, users would not see any product improvements and would start to leave the product. So the value stream is all the parts of the organization that contribute to the eventual bottom line.
The problem with implementing this understanding is that it’s very difficult for an organization to conceptualize all the things that it is putting effort into, in a holistic way. The tools are too broken up across organizational silos for us to be able to track a request from end-to-end. And in an organization that makes physical objects, the ends can be a long way from each other — Kersten uses the example of Boeing’s planes, which are designed for a 30 year production cycle and another 30 years of active service and maintenance. Even in software, we are still maintaining and coding for IBM mainframe systems that may be older than some of the people working on them. To handle this, the value stream takes the entire lifecycle cost into account. Toward the back of the book, there are some implementation tools for understanding the ecosystem of software that your organization uses, the organizational barriers information has to cross, and the ways that handoff is managed.
Value streams
Kersten spends a lot of the book in illustrative stories, which I appreciated — it’s always easier for me to grasp a concept when it comes with examples. However, I think it’s important and useful to say up front that
Value Stream: The end-to-end set of activities performed to deliver value to a customer through a product or service
This whole book is about learning to understand the flow of work through a value stream, and “map” it, to find inefficiencies and bottlenecks. Once I understood that’s where we were heading, it was easier for me to compare the examples in the book with my own experience in various industries.
The metrics that make tracking workflow in the value stream are unsurprisingly similar to the velocity metrics from the DORA Report, but with an emphasis on the whole organization, not just software-making.
- Flow distribution (mentioned already – features, defects, risks, bugs)
- Flow velocity (how many items get done in a set time)
- Flow time (how long it takes a single item to get through the system)
- Flow load (work in progress/overloading checks)
- Flow efficiency (how much of the time it takes to complete an item is work vs waiting)
Quotes and key take-aways
As I was reading this book, I had to go find my highlighter because there were so many great quotes and illustrative examples. I’m not going to try to share them all, but here are a few of my favorites:
- We need to elevate the practice of software delivery by connecting today’s business leaders and technologists, and reducing that chasm, not broadening it. To do that, we need a common language that empowers both the technologists and the business stakeholders with the right kind of information to drive good decision-making for the business.
- The vast majority of enterprise IT organizations have no formalized notion of value streams or measurement of how business value is delivered.
- Productivity declines and waste increases as software scales due to disconnects between the architecture and the value stream.
- Software value streams are not linear manufacturing processes but complex collaboration networks that need to be aligned to products.
- We fail when we measure activities, not results. An IT team could be deploying a hundred times per day, but if their work intake is not connected to the needs of the business, the results will not materialize for the business.
- The questions most fundamental to production
- Who is the customer? (the customer and the user may be different)
- What value is the customer pulling? (customer-pulled value is a customer seeing value and exchanging an economic unit for it, which might include attention, adoption, or money)
- What are the value streams? (how does each step of this process work toward value, not just internal goals?)
- Where is the bottleneck? (what is causing delays in this value stream, and are they avoidable?)
- An important aspect of measuring revenue per value stream are the systems for tracking revenue, such as accounting and CRM. These systems need to be set up in away to connect revenue result back to a single product’s value stream. (This feedback loop is one we often miss in the DevOps world)
I’m not doing justice to the nuance of this book or the huge number of examples Kersten provides, but I hope to convince you this is 210 pages worth of your time, because I think this book really illustrates some of the frustrations I’ve had in my career, and how we can start thinking through them and working to share a common language between developers and business folks.
Book review summary
Read if: You are a jaded technology person who is tired of watching enterprise transformations fail for apparently no reason. You will feel satisfied about a loving story of a car factory and the late-in-game realization that software doesn’t always work that way. You’d like to dip your toes into more lean management theory, now that you’re comfortable with lean delivery.
Skip if: Reading utopian stories about people who actually do transformation well is just going to burn you out faster.
Also read: Accelerate and Making Work Visible
Top comments (0)