This post continues the book club discussion of The Phoenix Project. See also: The Phoenix Project – Part 1
Here are my notes for chapters 6-10…
You can’t assign random people to just any project. This speaks to silos of knowledge, especially in organizations where you have a wide variety of tech stacks.
On a related note, for sprinting teams, not every team can pick up stories based on the story-point value. If one team is accustomed to dealing with a certain project, their velocity will be faster than other teams.
All three of us have worked in shops where we ignore the IT process (e.g., help ticket) and go directly to the IT person that gets stuff done.
The book’s example of the large change management tool that was built can be equated to Jira or TFS. These systems are so generalized that they can be over-configured to the point where it’s too cumbersome to use. For example, there could be a master configuration/workflow that has required fields that only make sense for 80% of your projects.
It was interesting to see the sunk cost fallacy of the expensive change management system they tried. (They spent time and money on it, so why not use it… even if it’s broken and doesn’t serve us.) Patty later came around to trying something else.
People play games with systems so that their particular problems are more important than others. For example, all emails from one particular director are sent with high importance.
It’s important to define what change means to your organization. A related definition that must be codified is definition of done. If people in your org don’t agree on those, chaos is inevitable.
Instead of one general calling the shots, you have ten generals… and they’re speaking directly to the privates instead of using the chain of command. These generals are often what we call stakeholders. Sometimes the loudest voice wins.
Jameson has read Making Work Visible, and he said that book resonates with the statement from this book: If you can’t see it, you can’t manage it.
Geoff has read The Goal; the summary in The Phoenix Project captures the essence well. It’s useless to optimize anything downstream from the bottleneck because those things will be starved for work; it’s also useless to optimize anything before the bottleneck because you’ll accumulate inventory.
Jameson shared the concept of the critical few, wherein the company executives identify a few things that should be the focus for the whole company. Houston said he’s heard of this in other companies where even the lowest employee on the org chart knows what to focus on and how their impact will be applied.
The CEO laughed at Bill for asking for prioritization and diminished the importance of that decision by saying if he asked his board what he should focus on, he’d be laughed out of the room. I disagree; it’s the CEO’s job to define, clarify, and support priorities. If everything is important, nothing is.
The CAB (change advisory board) is doing risk management — which changes are the riskiest/most fragile. You need business stakeholders there, too. There can be problems when everyone’s project is the most important. The representatives sent to these meetings are sometimes the people with the most knowledge or time in the seat, rather than the people with the best leadership skills.
Do we always need eyes/approvals on the fragile changes? It sounded like this was a temporary measure until a process could be developed. An unfortunate outcome is that someone pitches such a process, but it’s shot down because it has some flaw, any flaw (also called “yes, but”). You need a core system in place now; deal with the edge cases later.
In the example of the Severity 1 credit card payment incident, all departments were pointing at everyone else until it circled the entire room. This shows how many dependencies exist to make this system work. No one was willing to take responsibility; it was always someone else’s fault.
Jameson mentioned the book Extreme Ownership. It’s written from a military perspective about how the team owns the mission (failure or success). So if a team fails to deliver, the team lead owns it, and in turn the project manager owns it, and so on up to the CEO. I asked about the scenario I see at my job quite often where our project is dependent on many other stakeholders (site support, external systems). Jameson said the key part is communication and caring about others’ success. Also, you have to reduce the risk of those dependencies.
Related to reducing risk and communicating, your team needs to make that work visible and plan for it. Document what other work you have to do that’s blocking your current work. If you ended up 20 hours behind in the sprint because the 20 hours you planned to finish was eaten up by support calls, hidden dependencies, etc., that will be very evident in retrospectives.
None of us has worked in an organization that did drills for emergencies and high-severity impediments.
I like how Bill continues to affirm that his goal is to “ask and understand”, rather than blame and fire.
Sometimes having the right title and throwing your weight around to state that things are going to change around here helps.
One of Bill’s goals — which he explicitly states to Brent — is that the habit of always going to Brent has to be broken. This can be difficult because Brent has a somewhat passive personality and says yes to most everyone. The book even speculates about why Brent may like his current arrangement… he’s virtually impossible to replace.
Houston and I loved the idea of following Brent around with a camera and a keylogger to find out how he’s solving these problems. “Going into a trance and solving a problem” isn’t repeatable.
Houston commented that management was speculating what the “carrot” should be for Brent (e.g,. more PTO). How about asking Brent what he’d like?