The Phoenix Project

Jump to: navigation, search

After I've read (okay, listened to) the Phoenix Project I'd like to share my thoughts:

Cultural Change

  • Conflicts between developers and operations cause outages, slow delivery and additional work
  • DevOps enables you to deliver new features faster, greater customer satisfaction, greater market share, more productive (and most importantly) happier employees
  • DevOps in comparison to old-school practices:
    • 30 times more code deployments
    • 8,000 times shorter code deployment lead time
    • 2 times better change success rate (that is an improvement by 100%!)
    • 12 times faster MTTR
  • It's (again!) not a toolset! It's a mindset!
    • spend one fifth of your time to make lives of the next guy (deployment, OPs) easier
    • everyone respects the work and efforts of others
    • everyone cares about non-functional requirements (quality, scalability, maintainability, security and operatebility (sp?)) as much as functional requirements - they are equally important!
  • DevOps is a cultural change
    • Trust, respect and appreciate everyone
    • Don't control
    • Don't divide and conquer
    • Use peer review (and do that without fear or doubt)


  • Deploy as often as you can. Make it daily routine. (not nightly, not on weekends, avoid downtime)
  • Make smaller changes, more often
  • Automate all unit + integration tests
  • Use agile techniques, if possible

The Three Ways

  • First way: Improve the workflow from development to deployment
  • Second way: Instant feedback, using:
    • stopping the assembly line (meaning, stop deployment, if tests fail)
    • care as much about the work effort as the improvement of your working and workflows
    • use automated tests
    • shared pain of developers and OPs
    • measure the effects or your changes
  • Third way: Cultural change
    • build a culture, that lets you take risks, learn from success (and failures)
    • accept that repetition and practice is the foundation of mastery

The four types of work

  • business projects
  • internal IT-projects
  • changes
  • unplanned work / recovery work

WIP kills!

  • the more jobs you give to a person, the worse will get his output (there is a nice graph in the book (sadly not in the audio book :) )
  • imagine you have three exams on one day (say it's maths, chemistry and physics)- that's already hard enough - but you can manage. Then someone gets you out of the exams every 15 minutes and puts you in another. I think that makes clear: the more jobs you give to someone, the lesser the efficiency will be.
  • and that might not be all: If you have a chain of equally overtaxed persons, your delivery time will be exorbitant (or the strain will kill your workers)…
  • therefore, reduce the WIP (the agile folks will recognize this as the scrum master lets the team to focus on their work and frees them of any distractions or impediments)
  • Links & Notes

More Cultural Change

  • Fear is the path to the dark side
  • trust your coworkers, share
  • don't fear conflicts
  • don't stand back
  • be responsible
  • concentrate on team effort (not your personal)

That are my 2ct about this book. While really enjoying (and many times feeling satisfied, that the main character faced similar challenges like myself) this book I often thought: Hell, this is SO obvious - why don't we just do the right thing? (I guess, most management-driven company's employees will feel this way…)

Since I believe that there's a difference between knowing the path and going the path, I strongly recommend, you read this book yourself. :-)

More links: