This post continues the book club discussion of The Phoenix Project. See also: The Phoenix Project – Part 2
Here are my notes for chapters 11-15…
Scheduled changes aren’t getting completed because Brent is the hidden dependency. Knowledge should be spread, not hoarded.
The Change Advisory Board (CAB) suspects they’re causing too much change, but they are not the problem. They approve valid changes; the initiators of the change own the work. We liked that the CAB was reflective on their role (e.g., “are we the problem”).
Working around the process — which is instinctual to move faster — would mean the CAB would lose situational awareness.
As things go from bad to worse, we see the lack of communication and visibility between development and operations.
Developers and QC aren’t going at the same pace, and there’s a lack of preparation and oversight. QC can’t even complete a full smoke test, which makes QC the bottleneck. A smoke test is about finding build errors, high-severity bugs, and should be automated. A regression test is more thorough.
Bill tries to communicate risk to Steve and is dismissed; everyone things IT is crying wolf. We do see a small amount of Steve holding Sarah accountable.
Lesson learned: Compliance may cause more process, but ignoring it is either expensive or detrimental to your business. (Example: The website was showing the credit card information of the last successful order.)
Steve wonders whether he has a leadership problem or a “wrong people on the bus” problem. It’s the former, as leadership determines who’s on the bus.
Despite Steve’s military leadership background, he’s not taking ownership of the people below him; he’s only concerned about the board of directors.
“Maybe IT isn’t in our DNA.” There are ways to treat IT like a product you manufacture, which is the point of this book. We can benefit from 100+ years of experience to apply it to IT needs.
Our group had some good discussion about the pace of technology change and how it’s difficult to keep up. We agreed that it’s tempting for top management to ignore the maintenance side of bringing in new tech (as opposed to the upfront cost, or lack thereof). Convincing people to pump the brakes needs to happen near the top of the org chart, as the people at the bottom already see the problem.
There’s a planning problem with long road maps (e.g., next three years of releases). On the other side, people want to know what they’re paying for and when they’ll get it.
“Momentum is the illusion of progress.” — James Gracik
There should be a focus on identifying sources of unplanned work and eliminating those sources.
The “-ities” of software are the first to go when crunch-time hits: maintainability, security, readability, testability, etc.
Outcomes > process, but the ends can justify the means. You need to distinguish between what work matters to the business and what doesn’t.