Imagine you get blamed by management, you personally, for some systemic issue that caused widespread disruption. They're looking for a scapegoat - someone to fire so the negative focus gets sucked out in the wake of that person's departure - but in this case you were lucky enough to have a friend in high places. So you get reassigned, sent to a cumbersome impossible trailing-edge project where no one will notice you. Maybe your growing anger and resentment will finally make it possible for you to seek revenge, to pay them back? Maybe you can teach them all a lesson? But there's something about you that just can't go there - you don't create problems, you solve them! And despite your worst intentions, you find yourself getting curious about this back-water project - why is it so broken? Where do I get started, figuring it all out? Who can help and how did it get this way? What value could customers get if we could just find a way to deliver results? 

This is the opening setup for Maxine Chambers, development leader and software architect at Parts Unlimited, Inc., in The Unicorn Project, Gene Kim's follow-up to The Phoenix Project. As stated in its subtitle, The Unicorn Project is "a novel about developers, digital disruption, and thriving in the age of data."

Kim brings together key concepts from Geoffrey Moore, Jez Humble, Donald Reinertsen, Mik Kersten, Mark Schwartz, Peter Senge, and stories from the trenches of transformation from the DevOps Enterprise Summit conference series to capture a blueprint for transformational success that's based on the perspectives and efforts of software engineers.

Not many novels bring to life the daily struggles of software engineers, so this comparatively rare mirror placed in front of us offers a welcome chance to reflect on a large set of key questions, such as:

• How close are we to the results of our efforts? Do we get to see our customers' delight?

• Can we execute quick experiments, get rapid feedback, and iterate?

• Are we fans of pragmatic programming, functional programming?

• How often are we bitten by mutability in our code?

• Are we satisfied in our work? If not, what might be some systemic causes of our dissatisfaction?

• Do our systems enable us to focus or are we continually context-shifting?

• Are we able to collaborate easily across functions and teams?

• Even better, have we reduced interdependencies to the absolute minimum?

• When things go wrong, does the organization focus on blame or on systemic corrections?

• Are we generating technical debt faster than we're paying it down?

• How much toil do we face every day? Unplanned work? Internal work?

• How do we carve out time for improvement, or even time just to think?

• What's the relationship between engineering and "the business" really like, here?

But despite all the instructional value in this book, it's very easy to get caught up in the drama of the story. Parts Unlimited is a very large, traditional enterprise that must transform to survive. The legacy of complex and entangled architectures, out-of-date processes, methods, and tools have generated a context in which innovation dies long before it can complete its journey to customers. A brave group of engineers form a "rebellion" to confront this legacy and create a lasting business transformation, both technological and cultural.

To organize the dramatic principles at work in the story, Gene Kim came up with The Five Ideals of DevOps:

1. Locality and Simplicity (reduce interdependency, own your code in production, microservices architecture)

2. Focus, Flow, and Joy (limit work in progress, make work visible, see the value of your contributions)

3. Improvement of Daily Work (pay down technical debt, streamline the architecture)

4. Psychological Safety (blameless culture, systems thinking, shared context)

5. Customer Focus (core vs. context, feedback)

Elements of the storyline are adeptly woven through these five ideals, clarifying each one and giving them practical weight. Plot twists, setbacks, sudden breakthroughs, a major RIF, taking a sledgehammer to old server equipment, and C-level treachery make this a very compelling read.

One of my favorite parts involves a QA joke Bill Sempf shared on Twitter: "QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv."

Although the speed at which certain miraculous improvements happen defies belief at times, the novel is full of inspiring tales of software engineers getting excited about better methods, shaking off the shackles of the status quo, and getting it done right.

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.

Having read "The Unicorn Project," I found it to be a solid resource in the realm of technology and business. Gene Kim, the author, weaves an informative narrative around Maxine, a protagonist navigating through a stifling corporate landscape. The journey she undertakes represents a familiar struggle for many in a similar position.

The book's main principles are embodied in the Five Ideals: Locality and Simplicity, Focus, Flow and Joy, Improvement of Daily Work, Psychological Safety, and Customer Focus. Through these, I got a comprehensive understanding of what it takes to implement change in a rigid system.

Maxine's journey in redefining the errors of 'The Phoenix Project' showcases the interconnectedness of business and technology. It underlined the significance of balance and harmony within an organization's different functions.

"The Unicorn Project" extensively covers DevOps, presenting it not just as a toolset or process, but as a culture and philosophy that promotes constant learning, collaboration, and innovation. However, the frequency of technical jargon used may make it challenging for those not deeply entrenched in the tech field.

Despite being heavily rooted in technology and software development, the book carries a broader appeal due to its engaging narrative style. Even though the extensive use of technical terminology might pose a slight barrier, it's still a worthwhile read for anyone interested in understanding the digital landscape of modern businesses.

I've always said that there is no customer problem so bad that I couldn't come in and make it worse. The Unicorn Project, while an entertaining business novel, is chalk full of coding and other technical references that go right over my head. That being said, I still heartily enjoyed the book and learned a tremendous amount from reading it.

In The Unicorn Project, Gene Kim retells The Phoenix Project story of IT and corresponding business transformation at the struggling auto-parts store giant, Parts Unlimited, but from the completely different perspective of Maxine Chambers and the IT staff. An hoc team, The Rebellion, fights back against the bureaucracy, waste and, most importantly, technical debt inherent in the 100-year old company. The mysterious Yoda-like tech guru, Erik (also featured in The Phoenix Project) explains, “There are many definitions, but my favorite is how it was originally defined by Ward Cunningham in 2003. He said, ‘technical debt is what you feel the next time you want to make a change.’”

Given the recent release of the final Star Wars saga, The Unicorn Project’s rebellion is particularly timely. And Gene includes plenty of fun Star Wars trivia subtly embedded throughout the book.

Business philosophy worthy of a Naval Ravikant is scattered throughout The Unicorn Project such as this gem, "Every tech giant has nearly been killed by technical debt. You name it: Facebook, Amazon, Netflix, Google, Microsoft, eBay, LinkedIn, Twitter, and so many more." IT guru, Erik, chimes in with observations like, "Interestingly, Satya Nadella, CEO of Microsoft, still has a culture that if a developer ever has a choice between working on a feature or developer productivity, they should always choose developer productivity."

The Unicorn Project also includes practical snippets for non-IT workers such as when an executive reminds employees at a celebratory meeting, "Uh, just a reminder, this is insider information. If you use this information to trade Parts Unlimited stock, you can go to prison. Dick Landry, our CFO, told me to tell you that he will assist in your prosecution as per your employment contract." The book even highlights a very relevant word for IT, "Complect." Erik explains, "It's an archaic word, resurrected by Sensei Rich Hickey. 'Complect' means to turn something simple into something complex." He makes sure to call out

One of the passages resonated personally: “Maxine thinks with a grin, “We’re racking up a heck of a bill with the cloud computing providers, but absolutely no one in Marketing is complaining because the business benefits are so spectacular.” I spend a good deal of my time explaining how cloud is an operating model, not a destination, and that an enterprise cloud model can bring enable the business benefits of public cloud combined with the much lower cost and greater control of on-prem. In fact, Gene even includes a reference to the Nutanix Workshops website.

Heroin Maxine says near the end of the book, "Technology needs to be embedded in the business, not external to it or merely aligned with it.” The wonder of The Unicorn Project is that by the end of the book, Gene has not only convinced his readers about the truth of this declaration, but he’s helped them experience second-hand why it’s so.

I have been a Developer, Engineer and Project Manager in IT for the last 20 odd years. I have been fortunate enough to have worked with and for several Tech Giants. The names and places change; but, the story remains the same. Why is it that most everyone can relate to "Dilbert?" Alas, I rest my case. The Unicorn Project, is stellar on a variety of fronts; unlike the "Phoenix Projects" it covers the whole gamut of a Corporation struggling for a foot hold in an ever decreasing market.

The author did an amazing job of capturing the different "political" motives, even to the level of the Board and really demonstrated how little input CEO's have when Board Members go rouge. The book is not an easy read and I would say that it was almost frantic; yet it had to be. I could relate personally with most of the cast (Dev, Eng, PM) and the solutions were more than Ideals or Steps. We've all seen these things and been told they hold the key to success. (If only the whole organization would follow) As stated, this is an amazing book and both the "Phoenix Project" and the "Unicorn Project" should be mandatory reading for everyone within an organization, regardless the size. From Peons, to Managers, to CEOs, CFO's, COO's to Board Members. Dilbert will live forever if the lessons in this book are not learned and learned well.

Overall, I think it's an average book. To me it didn't have the power of his other books, especially The Phoenix Project. For those stuck in a large enterprise where you're at the mercy of external siloed teams will enjoy this book more than others. I think many of us old fogies who have worked in the old-style enterprises feel a little nostalgia with the horrors we experienced. To me though, this book didn't flow like The Phoenix Project. It almost felt like the writing was hurried to meet a deadline. Even when it started to flow, that flow was broken with random paragraphs of why functional programming is the best. The evidence presented was even more strange. We should all write functional code to avoid off-by-one errors. My retort is does Gene Kim actually believe someone that can't terminate a for loop properly can actually terminate recursion properly? It just seemed like there were Gene Kim soap-box moments that felt out of place.

This book is very good overall with a few minor flaws.

First, there were some flaws in the writing itself. For example, there are a few uncorrected grammatical errors in it; in particular, the author regularly misuses contractions. Also, the book contains profanity, which I found unnecessary and distracting.

Secondly, the author uncritically (and without evidence) endorses open source software as obviously superior to proprietary software. For example, one character suggests replacing a proprietary server product with Apache Tomcat (which the architectural board summarily rejects due to a lack of a security review); the book treats this as an obviously wrong decision because it's one of the most popular server products on the market, so obviously there can't be any merit to the security concerns. (I'd be curious to see how the author explained the Heartbleed defect in OpenSSL or the recent security nightmare caused by Apache Log4j, both of which occurred in extremely popular open-source software; in the former case, it took 2 years for anyone to notice the defect, and in the latter case, the defect went undetected for 8 years).

One of the great promises of open-source software was that, since the code is available to everyone, defects are supposed to be spotted very quickly. Unfortunately, this neglects the Bystander Effect (which is made worse by the fact that it takes considerable effort to understand open-source projects of any substantial size and complexity, especially if they require detailed knowledge of areas like cryptography or network protocols). This has the result that, in reality, there are often relatively few people working on open-source projects; for example, OpenSSL has only 4 core developers (one of which missed the Heartbleed defect in a code review). The vast majority of people simply assume that other people are checking the security and correctness and simply use the software without question.

It also claims that the team could make extensions and modifications to Tomcat if they needed to because it's open source software. In reality, understanding a server like Apache Tomcat well enough to add entirely new, stable features would probably take months. The author evidently knows this, given that the book states multiple times that it takes 6 - 12 months for a new developer to become truly productive on a new project; however, it never connects this to the fact that that would also make it substantially more difficult for a team that isn't even working on Tomcat full time to make a major extension.

Lest anyone accuse me of being against open-source software, I'm not; I'm simply saying that not all of the claims about it are as obviously true as this book seems to think that they are.

Yes, I do understand that this is a novel, but I still would've liked to have seen a little bit more critical thought in regard to those issues.

The power of story in teaching technical concepts is highly underutilized. Gene Kim & friends achieved a great feat in introducing new people to DevOps in The Phoenix Project, which is a great book about business struggles in digital transformation (from the business' perspective). They achieved even more in The Unicorn Project when they flip the story on its head and tell it from IT's viewpoint. The characters are infinitely relatable and compelling and probably most importantly, tied to real world events/IT stories so that they are grounded in reality.

This is a super fast read in part because it is a fictional story. But don't let that fool you. The book is worth reading again to digest some of the great wisdom imparted at key moments. The book is so instructive that I plan on including it in the curriculum for the software architecture course that I teach at a local university. Well done, Gene!

Jeder in der Softwareentwicklung sollte dieses Buch gelesen haben

This is what i wanted! Great state, cover looks good

If you want a clue about what's happening at Boca Chica, Texas : Starbase, this is a book to read. Perfect introduction to agile management.

Fantástico! Para uma analista de sistemas das antigas como eu, o livro foi uma leitura prazerosa, instrutiva e ao mesmo tempo nostálgica.

I can think of a few words that will help to give a quick summary, these are: Resilience, business and IT alignment, team topologies, innovation.

Really enjoyed this book