I really enjoyed reading the story of the Unicorn project. It was a well written and enjoyable novel. Unfortunately, I also think it was a missed opportunity in both better expressing some concepts covered in the book and completely missed a set of related concepts that might have made the book better. That said, especially for people who enjoy software development related novels, the Unicorn Project is recommended.Because this is a novel, the rest of the review is likely to contain spoilers.The book consists of three parts. These parts are only labeled with dates, but they are roughly (1) the miserable current reality, (2) the rebellion, and (3) the unicorn project.The first part, slightly larger than 100 pages, is a description of the current situation in Parts Unlimited. The main character, Maxine, is published for an IT failure and gets expelled to The Phoenix Project. This is a deadmarch IT project which is the absolute worst and unfortunately quite familiar for some of us that have been working in large organizations. This part describes in-depth how bad things are, perhaps even a bit exaggerated at times.The second part starts when one of the people who do want to improve things (Kurt) becomes a development manager and is given the opportunity to do things differently. The other people who join him call themselves the rebellion and they adopt modern development (DevOps) practices to improve the development work. They convince Maggie from marketing that they can build and deliver a really important feature that might save the company.The third part, the rebellion expands and needs a new name and becomes the Unicorn Project. They adopt modern development practices and some modern technology and with that dramatically improve the product. This leads to significantly increased revenue and they save the company. Next the company changes their focus to include more innovation so that it will be less likely that it will be disrupted by a competitor.As said, the biggest plus for this book was that was easy and enjoyable to read. The lessons it tried to convey were mostly good, such as focus on developer efficiency, automated builds, test, and deployment, and modern technologies and architectures. It introduce "the five ideals" which seem useful principles for improving product development.I was disappointed that some of the above mentioned concepts were not explained in-depth. But my biggest disappointed was that it seemed to miss some ideas completely and didn't seem to offer a long-term way forward for a product development organisation. Let me clarify a bit. The first part was a perfect description of what happens in development when you create narrow-focused functional and component teams who do not collaborate (or just collaborate through tools). Then the second part starts breaking some of these silos and moves to a more cross-functional approach, yet they still *seem* keep team-code ownership rather than moving through cross-team code ownership. It wasn't completely clear as the teams were still structured around the architectural components, yet the author referred at least a couple of times to them as feature teams. Closely related, the book showed well how you can get things done cross-teams when you have a clear #1 priority (expedited development), but it didn't cover how an effective development organization would be structured so that all the teams can work effectively, not just the ones that work on the expedited features.In conclusion, I would give the book 3 stars for content and 4 stars for writing and story. As it is a novel and I did enjoy it, I'll round it up... 4 stars.