The Agile enterprise has been discussed time and again, but Gene Kim's work on the subject has a fresh perspective. The Unicorn Project is a rehash of an older idea, first explored by the author in The Phoenix Project, a novel about Devops transformation in IT.
The Unicorn Project tells the story of Maxine, a senior engineer at Parts Unlimited, a large manufacturer and retailer of car parts. Maxine is blamed for a payroll disaster and gets sent into exile to the Phoenix Project - a new initiative that for the past 3 years has yielded no tangible results. In her first week, she tries to run a build of Phoenix on her laptop and fails in the most spectacular ways possible. And then, she embarks on a remarkable journey that propels her to the top of the company. This is a story about digital transformation, a story where an old, entrenched company takes the sledgehammer to its old datacenter, redefines itself around technology, and manages to innovate and disrupt in ways that were thought to be reserved for nimble startups which overnight turn into glittery Unicorns.
If you like far-fetched ideals, then you're in for a ride. The story follows Maxine through her most exhilarating highs, and her most depressing lows as she navigates the endless maze that is corporate bureaucracy. She meets a rag-tag team of rebels and they join forces to create the most awesome Agile team ever known to man. They can do it all: debug race conditions, build CI solutions, run their own stuff in production, ignore any architecture review, defy all odds, all in the name of customer satisfaction.
If you take everything to heart, this book is over the top. There's no way that all of this could happen in one place. But that's the beauty of it: it doesn't need to be realistic in order to teach something. And there are a lot of teaching moments in the book. As we follow the Rebellion through their trials and tribulations, it's impossible not to recognize the issues they are facing. Sure, not everything applies to everyone; but anyone can identify with at least a few of these situations. Impossible build times? Lack of testing? No access to production? No dev environment? No one knows what the other team is doing? These are classic problems that plague every company that does IT.
If you cut through to the essence, there are five ideals to uphold. Each teaches us something about how to solve problems at scale, and how to empower teams to do transformative work.
The first ideal is locality and simplicity. Keep things simple. Complex solutions create dependencies and are operational burdens. Separate Core work - your core business, your competitive advantage - from Context work - things like email and payroll - and you're halfway there. Teams should focus on what creates value for their customers. The other half is locality: co-locate teams that need to work together; move data where it needs to be used.
If you follow the second ideal of focus, flow and joy, then your team is working on things that matter, and they know it. They have all the skills that they need, they are seldom interrupted, and can achieve a state of flow where they deliver with a predictable and sustainable speed. This is expressed in Scrum as Velocity.
The third ideal is my favourite: improve your daily work. The work process is more important than the work itself. A teams' Agile process is the cornerstone to their success. Improve the way we work and benefit from boosts in productivity that last for years. Ignore it at your own peril. Here, you can apply any of the core ideas and tools of Agile and Devops: Scrum, Kanban, retrospectives, CI/CD, testing, automation, you name it. These are like power-ups to a team, helping them stay empowered and productive.
The fourth ideal is the most important one: psychological safety. This is touched upon many times in the book. If people feel safe to explore ideas, investigations are done without blame, then solutions will appear more easily.
The fifth ideal is customer focus. Remember Core vs Context? Everything you do needs to help the business. Otherwise, it doesn't belong in your work queue.
The book tapers off at the end, following the team through a series of tremendous successes. Hey! What did you expect? Idealism at its best. I have enjoyed the book right to the end; if anything, it rekindled my lost love for Agile and process, which is a good thing.