book-review devops 
…until code is in production, no value is actually being generated, because it’s merely WIP stuck in the system.
I meant to write this post last year but am glad to have this 2019 post to ease back into doing code-related side projects. The Phoenix Project is not a technical read but meant to highlight software management issues and solutions through a story. Between deadlines, clients, and teams, bottlenecks occur:
- unplanned work and many unknowns with no visual tracking
- no time allocated for testing, deployment, and other operations
- team members being over or under utilized
The book demonstrated four types of work throughout the story with unplanned work being arguably the biggest pain point due to the other three types of work not being handled adequately. The characters initially experienced 24/7 pressure because no processes or planning were followed. Therefore, whenever an issue came up from Development or Operations, that issue became the most pressing until the next issue. The constant all-hands-on-deck approach didn’t adequately handle any of the issues as most characters were pulled into every single important issue.
- Business projects
- Internal IT projects (e.g. deployment)
- Changes
- Unplanned Work
The book then gradually introduces three ways to foster consistent and safe intervals of work, client-development feedback, and experimentation. The importance of tests during deployment as only quality code should move forward. Visible production telemetry creates trust and feedback loops where happier developers, operations, and clients reside.
- Flow (fasten delivery of work)
- Feedback
- Continual Learning and Experimentation
Overall, I highly recommend this book, where some situations seem all to familiar, to glean insights into how management matters in software development.