At the end of last year and to much fanfare, Gene Kim released his follow-up book to the Phoenix Project, the Unicorn Project, a novel about “developers, digital disruption, and thriving in the age of data.” I encourage everyone involved in digital transformation projects, or just thinking about digital transformation to give it a read. The book is written in three parts and I’ll review one part at a time. Here is a brief summary of Part 1.
If you haven’t read the Phoenix Project, that’s OK. To summarize, the Phoenix Project takes place inside and around a fictional auto-parts company, Parts Unlimited, with retail outlets nationwide. The novel is about Bill Palmer, a recently promoted VP of IT and other company executives as they race to develop and bring on-line a new customer facing system, code named “Phoenix” which will attempt to close the gap between its arch-rival, that is “eating Parts Unlimited’s lunch.” Phoenix is a service catalog / retail site, closely integrated to its respective e-commerce channels. Along the way, nearly every IT calamity possible befalls the company.
Part 1 of the Unicorn Project by contrast, reviews the early failures of “Phoenix” from the Dev rather than the Ops perspective. Here the main character is Maxine, a very successful architect/developer who has just been “exiled” to the Phoenix Project. After just a short time coming up to speed on Phoenix, Maxine quickly understands why things have gone so far south. For example:
- Issues with help desk ticket system in trying to get approval to build a dev environment. Everything requires a ticket to be opened first. Lots of notifications spawn other tickets and soon Maxine gets hammered by a lack of disk space and no way to get new drives ordered quickly.
- During a Dev and Ops meeting, no one can determine how many servers will be required. Getting a production environment requires 100s of tickets. The Firewall team alone needs four weeks to respond to all the tickets.
- Kurt, one of the QA Managers is running a black market and gets everything that developers need like servers without having to submit tickets. (must be before AWS)
- The QA Department doesn’t want to automate testing because of the cost savings which could reduce its next year budget. They feel developers should be kept away from testers anyway.
Later, Maxine joins Kurt’s band of “misfits” who plan surreptitiously on how to improve the development process. Along the way, they meet up with Erik, an efficiency expert/agile coach now working as a bartender. From Erik the team learns about the five ideals:
- Locality and simplicity. Design locality in our systems and the organizations that build them. And we need simplicity in everything we do–it must be easy to do work.
- Focus, flow and joy. Work in small batches, ideally single piece flow, getting fast and continual feedback. These are the conditions that allow for focus and flow, challenge, learning, discovery, mastering our domain, and even joy.
- Improvement of daily work. Elevation of daily work over daily work itself. (aka continual improvement)
- Psychological safety. Where it is safe to talk about problems and mistakes.
- Customer focus. Ruthlessly question whether something actually matters to our customers and are they willing to pay us for it?
Stay tuned for Part 2 to see the five ideals in action…..
Dick Stark's Blog 