The Phoenix Project

Gene Kim, Kevin Behr, & George Spafford

ISBN13: 978-0-9882625-9-1

The Phoenix Project is the latest book from the trio of authors Kim, Behr, and Spafford. Ardent students of IT may recognize them as the authors of the Visible Ops Handbook¹. Their new book is a very entertaining story rather than a staid handbook. The Phoenix Project is a narrative on project management being reborn within a fictional company. Published recently the book delves into a fairly new area of Information Technology (IT) named Development Operations often referred to simply as DevOps. This marriage of operations and development improves operational efficiency and cross-functional collaboration between business units if done right.

In the book we follow Bill Palmer, a freshly minted Vice President of IT Operations, as he transforms a dysfunctional IT group into the key driver for the company. Bill is mentored throughout the book by Erik Reid, a guy who embraces the principles of Lean Manufacturing and how they apply to DevOps. The book is a very entertaining read with thoughtful commentary peppered throughout.

At the beginning the company is in a sharp decline. The IT unit in charge of launching the new product that will save the business, project Phoenix, is a wreck and the IT boss just got fired. Bill is asked to complete project Phoenix. He doesn’t quite know what he is getting into but he knows it is a mess. The project until this point has been managed in a waterfall project management style and the deliverables have been delayed until everything is complete. Immediately Bill sees this as a problem as no one really knows how complete Phoenix is, no testing has been done, and they have to launch in just a few weeks; on top of that normal operations must continue as well.

Through meetings cast in a sardonic light we are shown there are few processes in place and the ones that exist are not followed by anyone. By adopting agile software development practices the team slowly starts to turn the project around. Following a disastrous launch of Phoenix, a wake-up call resonates throughout the team. They start to give the processes an honest chance and again, the workflow improves and the subsequent releases are less challenging. However, the company is still tanking. Bill gets approval to speak with the heads of other divisions to determine what they need Phoenix to do now, rather than when it was first dreamt up. Gathering this data allows Bill to pivot, to borrow a term from the Lean Startup². They reprioritized their backlog and started producing software that provided immediate value to those using it. I feel that is the key take-away from the book, identifying the business goal of the organization and then ensuring that the work is always striving to move the company towards that goal. The authors really drive the point home by having the company software security officer John shaken to his very core when his work is swept under the rug by auditors. After a hiatus from work he returns ready to make sure the security issues that are prioritized are ones that help the business achieve their goals, rather than stopping them from doing so as had been his previous modus operandi.

Eventually Bill helps transform the company from within. The CEO Steve Masters comes to realize the importance of IT in his company. At the beginning of the book IT was thought of as a necessary component to be dealt with, not the core asset that it is for any operation in any industry.

Kanban: Successful Evolutionary Change for Your Technology Business

By David J. Anderson, ISBN 978-0984521401

Kanban is a process we have been using in the WebTech office for over a year now. We have adopted the system slowly and recently presented our version of Kanban at the Pacific Northwest Drupal Summit. During the Q & A portion it was suggested that I read this book. The last few chapters offer strategies for managing issues we have been experiencing as we move more of our work into a Kanban model.

The book itself is organized into twenty chapters; helpfully the end of each chapter has a list of takeaways that are easily digestible. The book guides the reader through what Kanban is, how to develop a system for your work, and then how to get the maximum performance from the system you implement. Though the book was only published in 2010 it feels dated. Much of the software and websites mentioned no longer exist. However, in their place strong sets of tools have developed.

Kanban is a visual system of identifying work that needs to be completed (the queue), selecting a task to complete, and then following through until it is complete. A challenge we run into is having our queue be a little overwhelming in terms of size. Early in the book, on page 30, Mr. Anderson discusses balancing demand with throughput. He identifies that Limiting Work In Progress (WIP) is the key to Kanban being successful. There are several ways to accomplish this and by implementing a few strategies we have seen our throughput increase dramatically.

Limiting WIP to increase throughput is counter-intuitive but we have been increasing our throughput by about twenty-five percent when compared to not limiting WIP. Chapter 7 deals with visualizing the work. Several ideas were presented that we were able to add to our JIRA Kanban tools including WIP indicators for our columns with the most constraint. There is a thorough discussion of Eli Goldratt’s The Goal when Mr. Anderson delves into bottlenecks and constraints. The gist he tries to get across is that the Five Focusing steps used in The Goal can be a great process to use when finding bottlenecks. Bottlenecks in Kanban slow everything down so you want to make sure a strategy is in place to minimize disruptions to that resource. Chapter 17 deals with bottlenecks in detail and has a fun story about SR-520 and the WSDOT Ferry system to help visualize the myriad of issues around bottlenecks within Kanban.

The last chapter covers issue management and escalation policies. Again, the queue can fill up very quickly and without an effective policy for choosing what gets priority our developers are often left in lurch of indecision.

As our student team grows making sure we that they can confidently self-select issues from our queue is vital to continued success. Mr. Anderson’s book certainly has helped mitigate pain points we have been facing. If you and your team use any sort of agile work process, consider reading this book and giving Kanban a try.

Additional Kanban Resources:

• http://limitedwipsociety.ning.com/
• https://www.atlassian.com/agile/kanban
• http://www.everydaykanban.com/what-is-kanban/
• Purchase from a local press in Sequim.