Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework

by Mik Kersten

As tech giants and startups disrupt every market, those who master large-scale software delivery will define the economic landscape of the 21st century, just as the masters of mass production defined the landscape in the 20th. Unfortunately, business and technology leaders are woefully ill-equipped to solve the problems posed by digital transformation. At the current rate of disruption, half of S&P 500 companies will be replaced in the next ten years. A new approach is needed.In Project to Product, Value Stream Network pioneer and technology business leader Dr. Mik Kersten introduces the Flow Framework—a new way of seeing, measuring, and managing software delivery. The Flow Framework will enable your company’s evolution from project-oriented dinosaur to product-centric innovator that thrives in the Age of Software. If you’re driving your organization’s transformation at any level, this is the book for you.

Genres: Business, Management, Nonfiction, Leadership, Technology, Software, Professional Development

336 pages, Kindle Edition

Published November 20, 2018

Reviews

[Bjoern Rochel · Rating 4 out of 5]

Basically a different spin on taking ideas from the LEAN movement and theory of constraints into the world of software producing companies. People who felt inspired by „The Phoenix Project“, „The Devops Handbook“ or „Accelerate“ will likely also enjoy this book.

It introduces a new generalized model - called the Flow model - to surface and reason about end-2-end value streams and align the operational AND managerial center of companies around them.

I especially liked the ideas of Flow distribution (e.g. ratio of defects, features, risks and debts), Flow efficiency (ratio of cycle time to lead time) and the idea that a value stream is not manufacturing-line-esque , but is actually a network, which needs to be supported by a connected network of tools underneath to make the flows fully visible.

I‘ve listened to the book on audible, which so wouldn’t‘t recommend. The audio-book is accompanied by 80pages of charts and various visual depictions of the Flow model. That was a bit tedious to follow. It‘s probably neither a good candidate for e-readers because of the usual problems with displaying charts on e-ink displays.

But go for the book. I enjoyed it ;)

[Mac · Rating 3 out of 5]

I felt it was very hit and miss.

From the title, the book is screaming to treat software items as products and not just projects. The key takes from this are to focus on supporting a piece of software through its lifecycle - but the how to focus on that seems a bit left up to the reader to decide (create service teams that stick with it forever).

There are other aspects that I missed how they're connected to treating it as a product but I do think them worthy of commenting.

I liked the idea of cutting down software artifacts to four distinct groups (though some user stories could satisfy multiple - say a better deployment pattern enabling higher availability (risk reduction) and reducing tech debt - so there is some hair splitting) and then using those groups to control prioritization. It definitely seems like at least a framework for better outcomes than most.

While it does make it explicit, I'm not sure there is much difference in the Value Stream Network over a Value Stream Map. The distinction seemed to hinge around VSM being linear flow focused but VSN being multipath. VSM can represent multipath as well so that seems odd. It does do a good job of correlating some concretes (ticket tracking / work tracking systems / kanban / etc) to their positions on the VSM/VSN. So it's definitely worth it for that exercise alone.

Overall the information in the book is based on good concepts and the read is relatively quick, so it definitely is a good source if you're relatively new to the areas. It makes lots of good references, so it can also act as a bibliography to more concrete or deeper treatments of those concepts.

[Alan Fahrner · Rating 5 out of 5]

A Book that Demands a Decision

DevOps guru Gene Kim rightly introduced this book with, "Every decade there are a couple of books that genuinely change my worldview. ... This is one such book."

Mik Kersten provides ample evidence that the project and cost center orientation of so many software producing companies doesn't fit the Age of Software, and suggests a way becoming product-centric via a focus on value flow. The book is a an appealing combination of real-world examples of those who got it right (and who didn't) and practical explanations of what needs to be done to build measurable value networks.

Net effect for me? A mind that is racing on how best to distill it into something I can evangelize in my workplace. This isn't a "single read" type of work, and extra kudos to Kersten for the useful glossary and extensive index.

Get the book. Your company's future may depend on what it'll bring to light.

[Roman · Rating 2 out of 5]

should have been a blog post

[Jeff Mousty · Rating 3 out of 5]

This book is an easy read, you could in theory plow through it in 2 days if you really wanted to. The flow framework itself sounds like a great idea if you can tie everything together, but what i took from the book was more little things here and there. I also took more books i might want to see if they’re worth my time and others i had already tackled.

The authors central theme is the BMW Group Leipzig plant in Germany. Which is kind of interesting, because a key theme in the book is how manufacturing and software are different animals. So I think he tells you the bmw story because he spent a lot time trying to relate it's efficiencies to software development when he couldn't.

I really like this line in the book that i think emphasizes my last point, "Manufacturing is about maximizing throughput of the same widget; software is about maximizing the iteration and feedback loops that continually reshape the widget."

The four flow items in the framework (think of them as types of work):
-Features
-Defects
-Risks
-Debts

Understanding your teams distribution of these 4 items across their defined cadence is key and not each teams distribution will be the same. However be sure to understand that if debts are never addressed you will end up a product that isn't able to delivered. Instead it will just have to be thrown out or rebuilt from the ground up. An example they give in the book is when Apple went from OS9 to OSx it was a complete rebuild.

5 metrics to understand at the value stream level
-Flow Distribution
-Flow velocity
-Flow time
-Flow load
-Flow efficiency

The book pulls in a lot of material, so if your a reader i would say its worth your time to see how the theories are tied to the framework. If your not a reader, i think i would divert you to other core material before this book so that you can embrace those core theories better first before getting little pieces here or there.

Enjoy!

[Tristan Greaves · Rating 2 out of 5]

There's some good ideas here in terms of how product-based development is more valuable than project-based development. We've seen that before, of course, but there are some good examples. The Value Stream Network is pitched as a method of tracking that value from the genesis of an idea all the way to showing the business value.

The book uses BMW's car manufacturing lines as a example of Best Practice in its key case study, but then right at the end of the book, says ".... but software development is different, so this doesn't really fit". The linkage is weak -- the point seemed to simply be how important it is to be able to see the value of what you are doing at every point. That really did not need so many words (multiple references throughout the book) to say.

The main issue is that there is precious little information on how to actually _implement_ what the author is proposing. It explains at the end what a Value Stream Network is, and how it ties everything together, but deliberately says that the technical information on how to implement it is out of scope.

It comes across as a sales pitch: Here's the intro, now use my company to help you implement it.

[Andrew Anderson · Rating 2 out of 5]

Stalled out. Couldn't finish this one - too dense, not written to be all that interesting.

[Matt · Rating 2 out of 5]

There is some interesting ideas in here, however, the book ends up feeling like a gigantic advertisement for Tasktop.

[Joe · Rating 2 out of 5]

This is a tough book to review. I liked the flow framework and how the book talks of software delivery as the next age's means of production. Making the connection on how to use the concept of Lean and flow to manage the success of software product delivery was great.

But this book just wasn't well written - it rambled and skirted over concepts. Often concepts were brought up and treated like they were standard for everyone to know rather than obscure ideas from very specific research; the result being not enough time was given to explain them making them poor support for the author's point. Parts 1 and 3 of this book were unnecessary and the valuable Part 2 could have been a blog post.

Part 3 was especially egregious since the author makes the claim that the only way to really get a handle on your value stream management is to connect all your tools (and by extension artifacts and items) together. Then the author mentions that he just so happens to run a company that provides this very service! This really made the book seem like a giant ad for the author's company rather than a introduction of a new way to think about managing software value.

[Raphael Donaire · Rating 3 out of 5]

The book has good insights into the difference between project and product. Besides that, the author shares important aspects about why to measure flow and businesses metrics when you are dealing with software products.
The issue type classification is another good contribution.
The final part didn't deliver valuable knowledge of value stream mapping. The content was superficial, didn't have consistent examples and the link with the other chapters was lost.
If you are looking for some inspiration and need a reference to change your company mindset for a product one this book could share good thoughts.

[Olivia Liendo · Rating 4 out of 5]

The book argues that the companies that master the new means of production will displace those that take more time to adapt. "No business or sector is safe from digital disruption, even though the pace of the disruption will vary across sectors and businesses," Kersten explains.

"An insurance company that provides a first-rate digital experience will displace the one that does not. And if the insurance sector itself does not move fast enough on the digital front, one of the tech giants could move into that market in search of a vehicle for growth."

The author mentions that the quaternary sector, which is composed of knowledge-work industries such as technology, *media*, education, and government, moves at an even faster rate of digital change "by virtue of being the newest and most malleable sector."

Organizations need to focus on building products that delight and engage users and deliver desired business outcomes, argues @mik_kersten, rather than bog themselves down in project-oriented activity metrics.

Interestingly, according to the book, these are the most fundamental questions to production:
Who is the customer?
What value is the customer pulling?
What are the value streams?
Where is the bottleneck?

"We need a new framework to plan, monitor, and ensure the success of today's software-centric digital transformations," writes @mik_kersten.
Product > Project Mentality
Emphasis on Profit > Cost
Adherence to Delivery of Business Value > Time Frames

[Mike McGinniss · Rating 5 out of 5]

Great read

This book is extremely important for anyone playing a role in transforming how your organization works. We are moving beyond the industrial and manufacturing age into a world that is powered by technology. Understanding how to restructure an organization around business value and create visible links to where business activity links to that value is critical. And it has to be done with a specific focus on how technology and software development drives business value.

[Sri Shivananda · Rating 4 out of 5]

I came across this book when researching value stream management and the flow framework. I like the structured concepts in the book and look forward to applying these to enhance agility and predictable delivery of value at scale. I recommend this to all product and technology professionals operating at scale.

[Joris Laenen · Rating 4 out of 5]

Heel interessant, nog niet direct relevant maar wel essentieel voor langdurig succes in software producten

[Marc Bless · Rating 3 out of 5]

Not really an eye opener. The book describes basic metrics of flow, business results, and how tools, artifacts and value streams are connected. It totally misses how to implement the proposed model of the Flow Framework.
Nice to know, homework to apply.

[Austin Barrett · Rating 3 out of 5]

I think this book is a bit overhyped. Overall, I agree with what it says, but I feel it could have been better structured to get its point across. Beyond that, it seemed to drag on, never getting to its point (although there were plenty of interesting tangential insights and examples along the way). The beginning felt like it was building up suspense for what the flow framework was, and then at some point it just switched to winding down and reflecting on the flow framework without at any point obviously stating what it was. It’s almost like it sneakily covered the details of it over a long period. I would have liked to start with the basics of what the flow framework is before all the anecdotes and details. Perhaps the diagrams were meant to show that, but I was only able to understand a few of them, after I already understood what it was trying to convey.

I did get value out of reading the book, and I’m glad I ready it, but it was not enjoyable to read, and I’m more so glad it’s over.

[Justas Butkus · Rating 4 out of 5]

The idea should be very interesting to anyone working on the software part of the technology at any number of companies. To an extent it’s easier understood by those with the technical background, but author does a good job at trying to appeal to people with sheer management background having some understanding at least of the Lean practices. In any case it should be a mandatory reading for all software teams.

[Larry Burks · Rating 5 out of 5]

Mik ties together many different threads I have been following over the last several years, from lean manufacturing to lean team work, and places it within the value stream context. I look forward to working these ideas into my daily practice.

PS. I liked the book so much, I decided to get a job at Mik’s company, Tasktop.

[Jack Coates · Rating 3 out of 5]

Boring and facile, like the average book of its ilk. These are designed to sell consulting services, after all. It’s not wrong, it’s just a lot of words to wrestle with intangible questions... so it’s not right either. The BMW anecdotes were interesting.

[Tim Dugan · Rating 3 out of 5]

Some small confusion which could have been fixed with editing

The ideas seem good

But like many of these books it doesn’t seem to be adequate information to actually implement them

[Ruben · Rating 2 out of 5]

Some good points, but mostly about big enterprises and trying to draw an analogy with manufacturing. Could probably be summarized in an article rather than a book.

[Chris Esposo · Rating 4 out of 5]

Very good book outlining a new workflow management process for software (and other analytic) development, that promises to extend either DevOps or Agile to include "business value", and not just technical KPIs related to code development. The process is called "flow framework"/"value stream".

The author does a good job outlining why such a system is required, by going through a grand tour of technology that segments history in the usual way, via modes of production. According to this view, we now live in the mid-stage software era, and the author's main thesis for the book is that technology-native firms like Google, FB, Amazon, or more recently various fintech startups, have an advantage in this era because they are software/code-natives, and code is central to both operations, the business, and product. Thus, implementing Agile or DevOps into the work process stream is natural and provides tremendous dividends to these types of firms. However, legacy firms, who are not tech-natives, with substantial non-technical overheads in terms of resources and business-relationships, cannot succeed by naively implementing Agile or DevOps. The author reasons that most of these projects will be too constricted in scope, and will likely fail because of that fact. In essence, the initiatives do not leverage a "whole of enterprise" transformation, and will thus die in obscurity.

This explains the poor track records of Agile being implemented in large east coast firms, and the increasing encroachment of newer west coast firms into traditional industries like retail banking, where their superior process-engineered workflow across their enterprises affords them a huge leg-up vis-a-vis the legacies. These firms not only implement better operations from a service standpoint, but they also are faster at need-finding, and faster to innovate (or correct).

Accompanying the written narrative is a fully fleshed-out exposition of the method of the flow framework, mostly through nicely produced diagrams and mind-mapping pictographs and charts. These are great, but after 2 reads, I still don't entirely grok the framework enough to comfortably implement it (though that is exactly what I'll be doing shortly). This unease might just be natural though, like learning mathematics, the real understanding is often derived from struggling with the problem sets. Analogously, maybe facility with this material will only come after successfully implementating system within one's organization several times, helping your enterprise implement this across different teams say.

The key to this framework is understanding how it provides a unified cost-benefit accounting between multiple dimensions of technical value and business value. So by the end of the exercise, your team should know how to answer the question: "what to spend the next few weeks on, servicing technical debt on your infrastructure, or need finding new features that add value for the business?" This and similar question are answered by understanding the complex interactions, within the multi-layered flow topology, across the 3 dimensions of product, integration, and traceability. Specifically, how collisions or stoppage in one dimension can impact for on the other two.

To help the reader understand how this all could work in practice, the author uses a few exemplars, with BMW being the one that takes the majority of the page count volume. This helps out a little, but as a first-time practitioner to this subject, I still feel like it's all a bit vague. Still, I know enough and thought of it enough to see how this can help out in a lot of scenarios, especially in ones where the organization may have to be nimble through constant change cause of fickleness of the client, much of which will originate from inferior alignment with the business.

Lastly, although the primary use case of this is software development, I think it is also applicable to data analytic processes as well, perhaps even more so. Overall, not perfect, but still recommended. Especially for those will want through Project Phoenix.

[Sooraj · Rating 4 out of 5]

A recommended book for IT product, project managers and IT leaders.

Author Mik Kersten starts with the general statement that every industry has become a tech industry - A car today contains many more LoC as compared some of the consumer applications from a BigTech company. Then he observes that despite making progress on optimization and visualization by applying lean and agile concepts from the manufacturing industry, tech industry is still struggling to produce the same quality of business outcomes, except for the Big Tech. As a result, the Big Tech is disrupting traditional business at a much faster pace compared to the pace at which traditional businesses are able to adopt digitalization. One reason for this is that companies are focused on optimization of local value streams the rather than the end-to-end business value stream e.g. DevOps caters to the optimization of only the delivery process. Another reason is an outdated project mindset, where software initiatives are managed using waterfall budget, timelines and resource planning which encourages the wrong set of behaviors in the organization.

Mik suggests that the first mindset shift that is needed is a shift to product mindset, where each software is treated like product with its own lifecycle. Budget and resource planning can then be made on an agile basis adapting to the needs of the product's lifecycle phase.
Mik then introduces the concept of flow and value streams, and introduces flow items and flow metrics as a way to measure flow through end to end business value streams. He then then recommends how to connect flow metrics to business outcomes.
In the last section, Mik introduces the concept of value stream network which depicts how value flows across the value streams in the form of artifacts via tools and people. Having a good visualization of the value stream network allows us to take business decisions such as identifying where to optimize, eliminating redundant tools and processes etc.

Other content includes the evolutionary phases of industries, conclusions drawn from his personal experiences such as his trip to the BMW plant in Leipzig, and case studies such as Nokia's downfall, the Equifax security breach, Airbus's requirements for traceability etc.

Now coming to my feedback:
Value & value density: The book introduces new concepts, so a lot of value in there. The book is just about 200 pages, value per page is high, similar to other books of this genre
Complexity: The content is complex, which doesn't make for easy reading. Many times I had to reread and revisit stuff. If you are not a regular reader, this is going to be a tough one to finish.
Ease of Reading: While the sequence of content is good, the language at many places could have been much simpler.
Other feedback: The correlation between many events mentioned in the books, and the conclusions and the new ideas in this book is not very clear. For example, while his trip to BMW plant inspired him to conclude that visualization of software flow must become similar to that of car manufacturing, it doesn't explain what led to his realization that flow metrics and value stream networks are the answer to that.

All in all 4 stars for the content.

[Julian Dunn · Rating 4 out of 5]

Project to Product is a book that is quite good at diagnosing the problems inherent in how many legacy organizations create and deliver software, but falls short in delivering a non-academic approach of how to correct these issues. For example, Kersten spends much of the book admiring the BMW Leipzig plant's ability to "make work visible", and yet admits that DevOps thought leaders over-rotate on comparing software delivery to manufacturing, offering specific examples (that I agree with!) to illustrate how these two processes are radically different.

As a product leader, I found myself generally agreeing with Kersten's statements but struggled to understand how to use them to improve efficiency even in my own organization that is one of the hyper-growth digital natives (and yet we have similar issues with throughput). One gets the sense that Kersten's thinking is so wrapped up in his own product, Tasktop, that the only solution he can think of is to use his software and hire his consultants. The types of "tools" that he provides in the book are insufficient for a product leader to change anything, being that they are at a 30,000 foot level. For example, he explicitly states that while he uses the terms "value" and "software value stream" repeatedly through the book, the actual definition of value ascribed to work items flowing through the system is left as an exercise to the reader. What? Without some pointers on how to correct the issue of, for instance, "what exactly is a user story worth?" or "how do 'story points' map to revenue?", Kersten's pontificating reads purely as academic navel gazing. Plus the invention of new terms like "flow items" (meaning, well, types of work items that developers produce, rather than "flow" in the Csikszentmihalyian sense) is a bit pompous and an overreach.

In sum: I nodded my head while reading the book, bookmarked a few things, but still have no idea what I should do with Kersten's information come Monday, beyond thinking "that was an interesting read".

[Jeff · Rating 5 out of 5]

Intriguing Theory Scant On Application. This is one of those books you might read in a Computer Science degree program - probably more on the Master's degree level rather than the Bachelor's, as this is more designed for Tech/ Business Leadership than necessarily a traditional Bachelor's program that is more geared towards students entering the workplace or pursuing further academic careers. *In theory*, the theory here presented sounds pretty solid. While using a manufacturing plant as the touchpoint even though the author later admits that physical manufacturing and software development actually have little in common even in the theoretical world Kersten has crafted here, the actual software development theories *sound* like they could work. But that is precisely the ultimate problem here - though not enough of a problem to warrant a star deduction. Namely, that in failing to provide even a singular concrete example - even from within a classroom or study! - of how this could potentially work in the "real" world, Kersten does himself and his readers a significant disservice.

This book was actually recommended to me by my Group Manager when speaking of my own future career goals as an existing roughly mid career Senior Developer, and again, from a more Tech Leadership level, the book really was quite fascinating. I just *really* wish there had been even a single instance of real world application of the theory at any level at all.

Recommended.

[Kaspars Koo · Rating 5 out of 5]

Really enjoyed this one. It's divided in 3 parts.

The 1st part looks at the Kondatrief's 5 waves of innovation: 1. Industrial revolution 2. Age of railways and steel 3. Electrification 4. Age of oil, highways, and mass production 5. Age of IT & digital transformation. Each of these waves have transformed the economies at the times and the author argues that we are in the middle of that 5th wave that will transform our current economy. We already have seen industry after industry being disrupted (taxis, hotels, advertisement, news etc.), but the winners still can change because we still haven't arrived at the turning point.

The 2nd part offers the Flow Framework that helps to structure the company according to the value streams a.k.a. products. If your company wants to survive this 5th wave, this is how you should be looking at what value your company creates for your customers. There is a set of metrics for each value stream that can be measured and each value stream is connected with business objectives and metrics.

The 3rd part describes the Value Stream Networks a.k.a. what tools, artifacts, and processes you need to enable the organization to ensure a fast flow of value to your customers and fast feedback back from them to further improve your value proposition.

[Tobias · Rating 3 out of 5]

I purchased this book because of its convincing title and cover text. Navigating most recently in my own work environment through the transformation "from project to product" that the author describes, I was expecting some deep insights about this transformation - its phases, its challenges and hopefully some best practices. Unfortunately the book didn't really fulfill these expectations.

First of all, I must say, I totally share the author's conviction about the basic challenges that software still has to overcome to finally arrive in its golden age (the "deployment phase" as he cites Carlota Perez). I also totally agree with the author's main statement that traditional "project management" is potentially one of the key anti-patterns to this evolution. However firstly I am missing more details about this traditional anti-pattern and it's resilience, and secondly I claim that the way the story is being told is potentially misleading the average reader.

Noticeable at first sight, the author uses his visit to BMW production plant Leipzig as the main anchor throughout the book and draws his main consequences from it for software craftsmanship in large enterprises. In my perspective this may be misleading or even counter-productive, at least to the average reader: Automotive production is to be considered one of the most iconic modern manifestos of the industrial revolution. Unfolding in the area of the "obvious" (according to the Cynefin model), it is the result of precise up-front waterfall engineering and relentless process monitoring, striving to avoid any deviation from the a priori defined norm. It is the counter-example to software engineering, whose nature is basically creative exploration in the area of the "complex". Using this anchor of a production plant may leave the impression to the reader that we should lift this traditional production competency onto a higher level and apply it to software as well as for hardware - which is exactly the opposite of what the author wants to bring across as a message, just a tempting impression to the average reader.

Affirming the author's opinion, I truly believe that traditional "project management" culture is the anti-pattern to software craftsmanship - mainly due to two reasons: Firstly, a fixed time span; Secondly, a-priori specification and budgeting ("on time, on spec, on budget"). The book offers some nice perspectives on this, like the following:

Page 17: [...] Many digital transformations have gone wrong by over applying infrastructure concepts of the last revolution to this one. Production and assembly lines are great at reducing variability and reliably producing similar widgets, but software delivery is an inherently variable and creative endeavor that spans a complex network of people, processes, and tools. Unlike manufacturing, in modern software delivery the product development and design process are completely intertwined with the manufacturing process of software releases. Attempting to manage software delivery the way we manage production lines is another instance where frameworks from previous technological revolution are failing us in this one. [...]

Page 176: [...] Manufacturing has a fixed, well-defined set of variations for what will emerge from the end of the line, whereas the design of software features is open ended. Manufacturing needs to minimize variability; software development needs to embrace it. [...]

Page 176: [...] Manufacturing processes aim to achieve the highest feasible level of automation, which is facilitated by removing any creative and nondeterministic work from the production process. In contrast, software delivery focuses on enabling creativity and collaboration at each step, using automation to support creativity. [...]

[Vivek Gupta · Rating 5 out of 5]

If you are in Enterprise IT, you are probably already aware of the buzz words such as “Projects to Products” and “Digital Transformation”. And chances are you are in a middle of one.

If so, I will highly recommend this book by Mik Kersten - “Project to Product”. I ended up highlighting every other page in the book as it resonated and hit close to heart. A lot of them were common pitfalls we all fall for. Mik goes through many case studies and examples (BMW, Nokia, a large bank, Microsoft, Equifax etc.) and his learnings on why digital transformation works or not.

A lot of material out there talks about “Projects to Products” but this book went into so many practical aspects/implications of it that I have not seen discussed as comprehensively elsewhere.

Mik introduces his flow framework which is designed around delivering to value streams. And though value streams in DevOps have existed for a while, this is the first formalized framework that I have seen which looked practical and tailored for software development. A must read. I will post nuggets from the book in a separate post.

[Dennis Chow · Rating 2 out of 5]

Kersten is another Phd guy who mixes all kind of exsisting methodologies, adds his own spin to it, in this case include the word ‘flow’ to everything. Call it a framework, productise it and promote it in a book and voila the Flow framework. Just stick to SAFe and Lean and you will have a much more thorough framework to manage and organize your softtware deliveries.

He keeps on talking about focussing on business value, and how product orientation and his framework are the answer to this. I was curiuos about what he had to say about it and then on p100-101 he writes “every flow item should have a business value explicitly defined. Notably, the Flow Framework does not provide guidance on how to define that value …. That is the role of Agile frameworks”. From that point on I definitely felt I was reading something otiose.

I did like the first part about the technology revolutions starting with the industrial revolution but here he is referring to the work of someone else. The second part when he discusses his Flow Framework It became irritating. Skimmed the last pages.

[Jochen Deferme · Rating 2 out of 5]

Other than the first 3 chapters where others author's content is reframed I don't believe this book is worth reading:
The only inspiration seems to be a single site visit of the BMW production plant. As an engineer who has turned to IT I can attest that the analogy between the two worlds only goes so far. The automotive industry as a whole is focused on efficiency and reducing waste, while the software industry is all about rapid prototyping. According to the Cynefin framework they are in different domains and require a different approach. Trying to transfer the lessons from the complicated domain to the complex is just plain silly.
The FLOW 'framework' that he spends a whole book selling, boils down to also making visible the risk and debt on your backlog. That is it. Not sure what the rest of the book was for other than rehashing common knowledge in the field.
My advice: skip this one