DevOps people will love this book
Here's a book that really surprised me. I heard one of my managers referring to it many times, to illustrate decisions that we should take while facing real world problems.
Invariably, I found myself amused while identifying my past experiences with the characters in the book, reminding me of my previous teams, colleagues and managers. In the meantime, I took a deep dive into manufacturing philosophies, as well as Lean and Agile development methodologies; concepts in the base of DevOps.
A Novel about IT, DevOps and helping your business win
Bill is an IT manager at Parts Unlimited. It's Tuesday morning and on his drive into the office, Bill gets a call from the CEO.
The company's new IT initiative, code named Phoenix Project is massively over budget and very late. The CEO wants Bill to fix the mess in ninety days or else Bill's entire department will be outsourced.
With the help of a prospective board member and his mysterious philosophy of The Three Ways, Bill starts to see that IT work has more in common with manufacturing plant work than he ever imagined.
In a fast-paced and entertaining style, three luminaries of the DevOps movement deliver a story that anyone who works in IT will recognise. Readers will not only learn how to improve their own IT organisations, they'll never view IT the same way again.
DevOps key concepts
During the story, board member candidate Erik Reid keeps dragging our interim CIO down to the parts manufacturing plant to give him the lesson of the day. Many of the concepts are similar and the problem-solving solutions used in plant manufacturing can and should be applied to IT Operations.
Reduce WIP and protect and elevate your constraints
WIP stands for Work in Progress. In the story, the key constraint that affected everything was a Parts Unlimited’s key engineer, Brent Geller. We all have had a “Brent” on our staff. This is the one person who is the go-to engineer for everything. When we need something new, give it to Brent. The more work the company gave Brent, the more WIP they created because he was that one person and everything relied on him to push the workflow.
The following graph from the book shows wait-time as a function of how busy a resource at a work centre is. Erik used this to show why Brent’s “simple 30-minute changes” were taking weeks to get completed.
Kanban boards to visualise WIP
A Kanban board is a visualisation tool to help teams reduce WIP. The difference between a Kanban board and Scrum is that Scrum has fixed-length sprints and no changes occur during a sprint, while a Kanban board shows continuous flow and changes happen at any time.
In the story, they paid for and deployed a very expensive ITIL (Information Technology Infrastructure Library) tracking system and relied on project managers to keep the system updated with detailed analysis of each of their projects, but never had the time to do that so the system failed miserably. By adopting the Kanban board system, the entire team could visualise the work moving through the system and make decisions about restricting or increasing the flow.
Toyota Kata
The basic idea is to eliminate waste in every nook and cranny within the company. The book borrows heavily from Mike Rother’s book, Toyota Kata, and the idea of continuous improvement is a key concept. The story begins with Parts Unlimited years behind on the Project Phoenix. At the end of the story, it's rolling out code changes to Project Phoenix ten times a day.
The Three Ways
The Way is a metaphor for continuous delivery. In the story, as the interim CEO adopts The Way, he is able to continuously deploy new code and updates as often as is needed, every day, multiple times a day.
- The Flow: Understand how work moves through the system and know that changes will have random effects. Always try to increase the flow but never pass defects downstream.
- Feedback: Understand needs from both internal and external customers. Shorten the feedback loops whenever possible.
- Continual Learning: Encourage experimentation and learn from failure. Recognise that the kata will build mastery.
Technical Debt
When you start to look at where your employees are spending their time, one contributing factor is the unintentional deployment of fragile artefacts or systems. The story begins with Parts Unlimited swimming in technical debt. IT Ops can’t get any “real” work done because the team is constantly reacting to emergencies around failing systems.
The Five Dysfunctions of a Team
In this Patrick Lencioni’s book, of the major reasons that a team fails is the lack of trust between team members. He says there are five indicators of this team problem: unwillingness to be vulnerable within the group, cosmetic discussions versus passionate and constructive debate, no accountability, publicly supporting a decision while privately undermining it, and focusing on individual success versus team success.
In the story, when the team is days from utter failure, the CEO gathers the team together and walks his way through these indicators. He tells a very personal story about the status of the company; has a pointed discussion about what is really going on; explains to the group that he is accountable for the success or failure of Project Phoenix and will hold his subordinates responsible for their parts; and, finally, he imparts that the team’s success will be the thing that keeps the company solvent.
DevOps Across the Organization
Bill and John meet with managers in the business teams, from sales to finance, to understand performance measures across the organisation, how they rely on IT, and the business risks IT brings for each measure, following Erik's "magic glasses" learnings.
At first, several business team members, for example, are antagonistic towards the open approach Bill and his IT co-workers encourage. Yet, by the end of the book, Maggie - part of the business team in charge of promotions and pricing roadmaps - is attending stand-ups for the IT project linked to her objectives. She’s even demoing results to the team at the sprint retrospective in the kind of cross-functional approach to projects that really sings when everyone has a shared goal.
Avoiding Isolation
In the closing chapters of the book, John’s security team works closely with the development team, integrating security tests into the build procedures, testing and reviewing them earlier in the cycle. As a result, we see a radical shift in approach from earlier chapters, when John and his team were viewed as a disruption to be avoided.
References
The Phoenix Project gives us a remarkable human perspective over IT challenges, but its scope stretches far beyond the Novel concept into past, emerging, and current state-of-the-art DevOps management processes. For a deeper dive into each of these subjects, I suggest that you start your journey by using the links below. Good readings!
- The Phoenix Project book at Amazon
- ITSM - IT Service Management
- ITIL - IT Infrastructure Library
- The Cybersecurity Canon
- Book review at Simple Talk
- Resource guide for The Phoenix Project
- COBIT 5 Goals Cascade
______________________________________________________________________
Please “like” this or comment; and share it.
Jorge Fonseca is an IT Solutions Architect and Entrepreneur, specialised in Systems Integration projects for the Airline Industry and Health Care sector. Over 15 years of holistic and certified experience: Master in IT, MBA in Enterprise Management, CGEIT by ISACA, PMP by PMI, Scrum Master, MCP by Microsoft, OCA by Oracle, ITIL-F3.
Write him at [email protected], or read more of his articles.