This Post Has 8 Comments

1. Great story about software engineers and their struggles in a legacy enterprise
   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.

   Reply

2. Enjoyable read and a missed opportunity.
   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.

   Reply

3. Excellent sequel
   When I read The Phoenix Project years ago, I never imagined that there was a follow-up book from the standpoint of the dev teams. While I kinda knew what the content would be, the story was very enjoyable and confirmed some of my suspicions.

   Reply

4. Really worth to read it all!!!Once you make it through the first 100 pages it all becomes really great to read.I highly recommend it.

   Reply

5. I truly enjoyed each page of this book. So many good advices to be used by everyone that works in the enterprise world. Recommend recommend recommend.

   Reply

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

   Reply

7. Excelente livro

   Reply

8. Hats off to Gene Kim for coming up with this “fictional” novel and keeping it very interesting even though it’s based off a mundane digital transformation, that every company seems to be doing nowadays. Beautifully captures the vast problems caused by antiquated tech debt and highlights the true cost of accepting something just because it’s the “process”And who knows how many companies would have shut down just because they did not have a loyal team like Rebellion within them or if Sarah had won the battle.Eagerly waiting for the next part, already can imagine Brent and Shannon breaking their heads over the cloud egress costs and with all their Panther and Narwhal data stuck between a dozen cloud providers. Let’s see how they tackle that!

   Reply