3 Takeaways from "The Phoenix Project"

~ view this post on dev.to ~

A few months ago at work one of my coworkers had a great idea to create an engineering book club. I’ll be honest and admit that at the time, I haven’t really read many books about engineering or programming. Granted, I had read a lot about the subject, but not really in book form. I mostly assumed that the more permanent nature of books made the information inside quickly outdated in the ever-changing landscape of software development.

While both of these things are true, books are permanent and software development changes quickly, the kind of knowledge that gets written into books isn’t the kind of knowledge that goes out of style fast. The longer format of books makes them great for disseminating theories, principles, and ideas. Ideas about human nature, how people work together, decision making, communication, leadership… these are all just as relevant to software development as they are to any other field.

Back at work, the book club is starting up and I think that it sounds like a great idea so I sign up. The first book is “The Phoenix Project”.

Unfortunately for me, when it came to “reading an assigned book by a certain due date” I quickly fell into the old college habit of putting it off until the night before and then trying to skim it in hopes of gleaning enough useful information to have a short conversation about it.

Of course, this didn’t really work and when it came time for the book club meeting the next day I just ended up skipping it. And then I skipped the rest of the meetings because I was already behind, in for a penny in for a pound and all that.

After the club was finished with that book and selecting another, I regretted not seriously participating and decided to give it a better shot this time. The next book we voted to read was “The DevOps Handbook” (apparently we really want to learn about DevOps). It’s the sequel to “The Phoenix Project” and since I’m now fully committed, I have to go back and binge the first book before I can start the second… so I do that.

Here are my takeaways from “The Phoenix Project”.

Outcomes are what matter

“Remember, outcomes are what matter—not the process, not controls, or, for that matter, what work you complete.” ¹

Coming from a book that talks a lot about processes, I feel like this is a big statement. But it’s a reminder that processes are only beneficial if they create good outcomes that further the goals of the company.

Some common dev team and engineering org processes include:

• work methodology (scrum vs kanban)
• project creation/grooming (discovery meetings, ticket creation, backlog grooming)
• change/bug ticket creation and prioritization

These processes are important and it is great to optimize them for what works best with an organization, but the focus should always be on reaching a company goal. Hopefully, there can be a bread crumb trail to follow directly from the process to achieving the goal.

“Remember, it goes beyond reducing wip. Being able to take needless work out of the system is more important than being able to put more work into the system. To do that, you need to know what matters to the achievement of the business objectives, whether it’s projects, operations, strategy, compliance with laws and regulations, security, or whatever.” ²

This quote just reemphasizes the importance of achieving business objectives. I loved the analogies between the plant floor mentioned in the book, factory MRP-8, and an IT/Dev organization. The business objectives are likened to finished goods shipping out of the factory. If the business never meets its objectives then it’s as if the factory never ships a finished product and all you’re left with is an unhappy customer that wants their money back.

Everyone needs slack time

“…everyone needs idle time, or slack time. If no one has slack time, wip gets stuck in the system. Or more specifically, stuck in queues, just waiting.” ³

Slack time is important for so many reasons… reducing cognitive overload, preventing burnout, and facilitating work/life balance. This quote helps connect slack time to achieving company goals as well.

A personal example of this for me is when my dev team looks at our sprint velocity. Sprint velocity is a measurement of how much work we were able to complete in a 2 week increment. Before the two weeks start we all agree to an amount, a specific number, of work. We always compare this amount of work to our previous sprints (2 week increments) and try to judge if it’s an appropriate amount or not.

Let’s say we usually complete 40 points worth of work in a sprint. When we are agreeing to how much work we want to take on in our upcoming sprint we factor in the knowledge that we average 40 points and that we also need slack time. In this case, we’d probably only agree to 32 points of work. This allows us to have some built in slack time and space because sometimes work doesn’t go quite as smoothly as you expect.

Occasionally, for various reasons, we’ve decided to agree to exactly 40 points of work for the upcoming sprint and in every case, I can think of it usually didn’t turn out how we’d hoped. We struggle to meet that goal of 40 points, work doesn’t get done in time, and things carry over to affect the timing of future projects.

Slack time is important.

Continually focus on learning and improving

‘Improving daily work is even more important than doing daily work.’ The Third Way is all about ensuring that we’re continually putting tension into the system, so that we’re continually reinforcing habits and improving something. ⁴

This is my favorite takeaway from the book and one that is very important to me. Growth is a core value in my life and it’s something that is constantly at the forefront of my mind.

In regards to the book and a dev team, this growth can look like a lot of things. The team can actually learn new things like how to use a new tool, programming language, or how a certain product feature works.

It can also look like small tweaks to processes, communication, or workflows that make teams and individuals slightly more effective than they were before.

The key concept is that a team is always iterating on themselves and their ideas so they try to continually improve, even if it’s just a tiny amount. As the saying goes, if you aren’t moving forward then you’re moving backward. This growth mindset doesn’t just happen naturally, it has to be intentionally nurtured.

Overall, I found this book to be an easy read and a good story about the merits of agile practices and how to work better as a team and a company. Having already been familiar with agile and some of the pitfalls an IT department can face, it started to become very predictable and repetitive at points. But I think it was an entertaining read nonetheless.

—