Scan barcode
bookanonjeff's review against another edition
informative
reflective
slow-paced
5.0
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.
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.
austinbrrtt's review against another edition
3.0
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.
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.
chrisxaustin's review against another edition
4.0
I had high hopes for this book after listening to the Idealcast episode with the author, listening to several of the author's podcast episodes, and watching some of the author's videos.
At conferences I often find that the first 10 minutes of each session focuses on why I should care about the subject... I'm already at the talk, I know why I care about it, and I'd prefer that we move directly to approaches to solving this type of problem.
This book focused very heavily on why a change is needed, adding historical context to the problem. That's a useful and interesting subject, especially when it helps to communicate these ideas to people who haven't realized that there's a problem yet. The case studies lacked depth so they're more anecdotal.
I kept waiting for the book to move from the Why to the How. What I wanted was a book on analyzing and implementing a value stream network, but sadly it never quite got there.
I did derive value from it, but not as much as I had hoped. I would have preferred the first 150 pages be closer to 50 pages, then add another 50 pages worth of How, with case studies that show how a value stream network was mapped and the considerations around it.
At conferences I often find that the first 10 minutes of each session focuses on why I should care about the subject... I'm already at the talk, I know why I care about it, and I'd prefer that we move directly to approaches to solving this type of problem.
This book focused very heavily on why a change is needed, adding historical context to the problem. That's a useful and interesting subject, especially when it helps to communicate these ideas to people who haven't realized that there's a problem yet. The case studies lacked depth so they're more anecdotal.
I kept waiting for the book to move from the Why to the How. What I wanted was a book on analyzing and implementing a value stream network, but sadly it never quite got there.
I did derive value from it, but not as much as I had hoped. I would have preferred the first 150 pages be closer to 50 pages, then add another 50 pages worth of How, with case studies that show how a value stream network was mapped and the considerations around it.
allagainforart's review against another edition
challenging
slow-paced
1.0
Main takeaways:
- Business leaders need to have meaningful insight into the work being completed by IT/engineering and vice versa.
- Business leaders should be able to answer the following questions - Who is the customer? What value is the customer pulling? What are the value streams? Where is the bottleneck?
- Disparate and unconnected system (ex. no integration between customer service ticketing system and engineering system) can make these questions difficult to answer
- This kind of insight from business leaders is easier to accomplish when business leaders at the top of an organization come from an IT/engineering background (ex. Bill Gates with Microsoft).
- Organizations are using outdated management models from past technological revolutions to drive digital transformation in the age of software, and they're wasting money in the process.
- Enterprise IT organizations have a lot of work to do to catch up with the agility of startups and huge tech giants.
- The differences in Product vs. Project mindset (table illustrating the differences on pg. 54) and why product mindset is beneficial (pgs. 57-61).
- It's common for the business to be thinking of work in terms of projects while IT/engineering approaches work in a product oriented way, which means there has to be "constant mapping and remapping." I read this as having to redo roadmaps as plans change.
- Definition of technical debt and importance of paying down technical debt.
Book assumes you are already familiar with:
- Agile and Lean
- Fordism and Taylorism
Heavily pulls from:
- Technological Revolutions and Financial Capital by Carlota Perez
Criticisms:
- Overly dense and could have been edited down a lot
- Why not focus on a software company as the main case study instead of BMW (as others have pointed out, only to say later in the book that it's not the best comparison?)
- The takeaways seem too obvious for someone with a lot of experience in software product management, but they are not explained well enough for someone brand new to the discipline. Maybe it's for business leaders who have read a lot about product management but are not that familiar with it in practice, or for enterprise IT professionals trying to reframe their way of thinking.
Pros:
- Provides a lot of historical context (Xerox, Nokia, Microsoft, etc.)
mapodofu's review against another edition
2.0
Stalled out. Couldn't finish this one - too dense, not written to be all that interesting.
More...