This post concludes the book club discussion of The Phoenix Project. See also: The Phoenix Project – Part 7
Here are my notes for the additional chapters after the main story…
- Brent was cast as a “sharer” instead of a “hoarder.” He means well, but is trapped in a system where he can’t succeed by following the current plan. Hoarders are less tolerated — “everyone is replaceable.”
- Houston didn’t think there was a myth that DevOps replaces Agile. Jameson thought this myth is perpetuated by business folks that don’t really understand it. As Geoff said, “Let’s go buy some DevOps at Walmart on the way home.”
- Given this book, and the follow-on chapters from The DevOps Handbook, is biased toward DevOps solving what ails your company… Geoff wondered what the downside of DevOps is; the book seems to have nothing but positives. Jameson said there’s always a J curve; it tends to get worse before it gets better. Proper DevOps takes experience and skill. You need the specifics, not just a mindset.
- Some companies don’t know how to be successful with DevOps. Big companies will often have teams to manage this.
Time was running a bit short for this meeting, so we quickly covered the high points of the last sections of the book, which are a preview of the first four chapters of The DevOps Handbook. We agreed this could easily be a book for future consideration. The first few chapters give an excellent foundation on major types of work process — Agile, Lean, etc. Here are few parts we spoke about:
- Downward spiral in three acts
- IT ops has problems due to applications that are complex, fragile, or poorly documented; promised to fix them later, but later never comes
- Somebody tries to compensate for a previous broken promise, committing to a course they can’t meet
- Things gradually become more difficult, fear of failure drives everything
- Geoff thought the whole section on the human and economic costs was outstanding. The root is powerlessness.
- The Three Ways
- Fast flow from left to right
- Feedback
- Experimentation and failure
- Chapter 2 talks about limiting WIP (work in process) and interruptions. Houston and Geoff have found it difficult to find an effective way to make those interruptions visible (e.g., “Can you take a look at this?”). Jameson suggested writing down all the time you spent being interrupted and present it as hard evidence about how those context switches affect work.
- We continued that thought with regard to contract work, and that people are hesitant to pay for all the extra work that comes with, well, work.
- There was an interesting side-discussion about the value of having all IT work be done in-house instead of outsourced. Sometimes having an outsider’s opinion (especially if that opinion is pricey) will sway people more than an insider’s opinion. It shouldn’t need to operate this way. Most of our experience with outsource work — usually to the lowest bidder — ends up being disappointing, or costing more in the long-term because of maintaining that work.
- Chapter 2 also had a comprehensive list of things that are considered waste… extra processes, task switching, waiting, defects, etc. and heroics. That last one is a cultural issue where people get praise when maybe they shouldn’t. There’s value is feeling free to go home at 5pm and live your life.
- Chapter 3 talks about feedback. A memorable quote… “In complex systems, adding more inspection steps and approval processes actually increases the likelihood of future failures. The effectiveness of approval processes decreases as we push decision-making further away from where the work is performed.”
- Chapter 4 talks about continual learning and experimentation. Geoff was excited about the concepts presented… high-trust culture, taking risks scientifically, learning from successes and failures, sharing knowledge with others, blameless reviews.
- “…greatness is not achieved by leaders making all the right decisions — instead, the leader’s role is to create the conditions so their team can discover greatness in their daily work. In other words, creating greatness requires both leaders and workers, each of whom are mutually dependent upon each other. …because neither can solve problems alone — leaders are not close enough to the work, which is required to solve any problem, and frontline workers do not have the broader organizational context or the authority to make changes outside their area of work.”