Note I:
So this is finally the beginning of this review, and in the interest of full disclosure Ive been sitting on this review for a long time, longer than I really should have, but writing a review of this book actually seems a little daunting.
Note II:
As this book is a narrative, the review will have some spoilers
The Phoenix Project is a book that anyone who works in Software Development should read. And when I say anyone, I mean ANYONE. Product Owners, Project Managers, IT, Developers, QA all levels of development. The book tries to do the impossible, and bring to light the answer to the quote ITs work for deployment is invisible p.253
***SPOILER filled review starts HERE***
Book starts with a company which has got a major, over-budgeted, overdue, full of bugs, project that needs to go out the door and save the company. And the main, Bill Palmer, just got promoted to VP of IT Operations, and inherited the crap-shoot of a project.
As the book progresses, problems are brought to light that leads the main character to develop processes and rigors to overcome the problems. And along with these new processes and rigors, the reader is brought along the thought process of course correcting and fixing not just your product but actually also your process.
I will digress here and say as the reviewer, I feel obligated to reveal to you, the reader, that I have a long background with Software QA, and during my career as a QA person, the one thing that guided how I approached any of my positions was this one goal, QA the product, QA the process. No process is perfect for the team or the work at the time, so constant review of the process is definitely necessary. Now back to the book.
Throughout the book, key knowledge drops were abound. Fun quotes like the following:
Your problem right now is that you obviously dont actually know what work is
Eliyahu M. Goldratt, . any improvements made anywhere besides the bottleneck are an illusion.
Preventative work supports the company
Until code is in production, no value is generated.
Anyone whos worked in the software industry already knows a lot of this stuff, and have probably already implemented some of the solutions to the common problems. However, the book is rife with as many different challenges as possible, which is why I believe this book is worth reading, even if youve been in the industry for 50 years.
But theres an answer that I was looking for, that this book doesnt provide. And that is the only place where I feel the book is lacking.
The people in the book, all its characters, are supposed to be the avatars for their respective departments (QA, Internal Audit, Dev, Product Owner, CEO, etc etc) At the beginning of the book, even through the first 70 pages, conflict exists across all teams, with finger pointing and blaming everywhere. Even the CEO was throwing fingers and blaming in a ready, SHOOT, aim fashion.
It is because of these conflicts that I read through the book. The other knowledge pearls were a plus, but I was looking for an answer; something to help me and my team get better at interacting with each other. You see, the left overs from the Waterfall process, are the items where people point fingers based on responsibilities. And there has to be a way to help with that transition process from Waterfall to Agile, without just first getting rid of people who were still mentally Waterfall.
It can be said that, without teamwork, none of these solutions and knowledge pearls can be achieved and the book never answers how the teams can get in alignment its here where the book waves the proverbial Hand of God.
Is the book worth reading? DEFINITELY.
Is it the ONLY book worth reading? definitely NOT.
So please do yourselves the favor, buy the book, read the book, and gain all the knowledge pearls the book offers, because at the end of the day, this book really does provide a whole crap ton of them.
Buy on Amazon:
http://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509