Take a photo of a barcode or cover
This book is written by a CIO. I’m an individual contributor in a large organization. Place where the author suggests trying experiments or making changes that are applicable at guys level would be impossible (and possibly even actively blocked) at my level. I probably would have liked this book better if I was a C-level person.
I ended up reading three of Mark Schwartz's books in short succession, starting with The art of bureucracy, A seat at the table and finally The Art of Business Value. I would not have thought this during the first chapters of the first book. Schwartz's style of writing and the heavy use of unrelated quotes was downright annoying at first, but grew on me gradually.
Overall these books offered a different, and useful, point of view on the topics discussed.
Overall these books offered a different, and useful, point of view on the topics discussed.
A journey to answer the question, what is business value to IT? To the business?
The author is not afraid to ask questions that have long been taken for granted and even states at the end to drive the reader(listener) to question long held beliefs about business and business value.
With a bend at driving the team to discover and work towards delivering business value for themselves. Sadly this line of thinking is still controversial as teams are still adopting faux-agile methodologies while still maintaining waterfall bureaucracies.
The author is not afraid to ask questions that have long been taken for granted and even states at the end to drive the reader(listener) to question long held beliefs about business and business value.
With a bend at driving the team to discover and work towards delivering business value for themselves. Sadly this line of thinking is still controversial as teams are still adopting faux-agile methodologies while still maintaining waterfall bureaucracies.
A must must must must read for anyone working in any part of creating software and bringing it to customers. A freaking great read.
hopeful
informative
fast-paced
informative
reflective
medium-paced
Picked this up at a recent talk from Mark (The Author) I really liked the subject of Business Value. Definitely made me think about value at a deeper level.
This book is hard to evaluate because it depends on the ideas of a lot of other writers, which it critiques, deeply.
But let me see if I can capture the flavor.
In DevOps and software development, for some 20+ years we have evolved a system of small teams. In one of the methodologies, Scrum, a small team's priorities are defined by a "product owner" who, using his or her understanding of "business values" makes decisions for the pipeline.
Schwartz persuasively shows how the existing literature dodges the idea of where this notion of "business value" comes from. Instead of defending a thesis on this, Schwartz patiently shows how existing ideas of ROI don't work very well. In particular, they are bad at understanding time, and neglect the idea that we are trying to situate our work in light of different scenarios that may come to pass.
There is a lot here that is about upsetting the apple cart. I'll note just two:
(1) Schwartz implies that in fact the only people who can really understand "business value" are the builders (I am vastly oversimplifying his point, but I think this is his core point of departure). They are the ones who are closest to the actual process by which the business has defined what is important -- you can, effectively, read these values right off of the "hairball" built by the enterprise.
(2) He suggests that product owners should be drawn from IT. Why? Because they have had to be deep in the values, since they've built the automation.
In short, a refreshing critique of much of the accepted wisdom of Scrum and agile, while still being profoundly committed to the values of agile.
I wouldn't recommend reading this book cold. You really need to have already read, for instance, Ken Schwaber's Agile Product Management with Scrum, or possibly Kent Beck's Extreme Programming Explained.
If your teams know something of doctrinaire Scrum, this could be a wonderful book for a reading group.
But let me see if I can capture the flavor.
In DevOps and software development, for some 20+ years we have evolved a system of small teams. In one of the methodologies, Scrum, a small team's priorities are defined by a "product owner" who, using his or her understanding of "business values" makes decisions for the pipeline.
Schwartz persuasively shows how the existing literature dodges the idea of where this notion of "business value" comes from. Instead of defending a thesis on this, Schwartz patiently shows how existing ideas of ROI don't work very well. In particular, they are bad at understanding time, and neglect the idea that we are trying to situate our work in light of different scenarios that may come to pass.
There is a lot here that is about upsetting the apple cart. I'll note just two:
(1) Schwartz implies that in fact the only people who can really understand "business value" are the builders (I am vastly oversimplifying his point, but I think this is his core point of departure). They are the ones who are closest to the actual process by which the business has defined what is important -- you can, effectively, read these values right off of the "hairball" built by the enterprise.
(2) He suggests that product owners should be drawn from IT. Why? Because they have had to be deep in the values, since they've built the automation.
In short, a refreshing critique of much of the accepted wisdom of Scrum and agile, while still being profoundly committed to the values of agile.
I wouldn't recommend reading this book cold. You really need to have already read, for instance, Ken Schwaber's Agile Product Management with Scrum, or possibly Kent Beck's Extreme Programming Explained.
If your teams know something of doctrinaire Scrum, this could be a wonderful book for a reading group.
In Agile, we love to talk about Business Value, but we can rarely tell you exactly what it means. Mark Schwartz tackles this oft-ignored problem by examining different types of value that you can create, how to measure it, and then he dips a toe in the waters of how to best deliver that value.
Generally aligned with how I'm used to thinking about software, with some good points and deep dives into concepts that Agilists usually hand-wave away.
Generally aligned with how I'm used to thinking about software, with some good points and deep dives into concepts that Agilists usually hand-wave away.
Coming from a technology background, this book has been invaluable to understand some key concepts about business and how to make the marriage of the agile philosophy and “business” successful.
We are very much still in the middle of this transformation from a classical manufacturing approach to a lean development of business.
The key takeaway for me is that as a technologist it is my responsibility as much as everyone else to contribute to the creation of value for the business and this means that I cannot wait to be told what to do or expect for “product” to know it all. I am the business, I am the product.
We are very much still in the middle of this transformation from a classical manufacturing approach to a lean development of business.
The key takeaway for me is that as a technologist it is my responsibility as much as everyone else to contribute to the creation of value for the business and this means that I cannot wait to be told what to do or expect for “product” to know it all. I am the business, I am the product.