Difference between revisions of "The Phoenix Project"

From Wurst-Wasser.net
Jump to: navigation, search
(More cultural change)
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
After I've read (okay, listened to) the [http://www.audible.de/pd/English-Business/The-Phoenix-Project-Hoerbuch/B00VAZVUD0/ref=a_search_c4_1_3_srTtl?qid=1484510312&sr=1-3 Phoenix Project] I'd like to share my thoughts:
 
After I've read (okay, listened to) the [http://www.audible.de/pd/English-Business/The-Phoenix-Project-Hoerbuch/B00VAZVUD0/ref=a_search_c4_1_3_srTtl?qid=1484510312&sr=1-3 Phoenix Project] I'd like to share my thoughts:
  
 +
=== Cultural Change ===
 
* Conflicts between developers and operations cause outages, slow delivery and additional work
 
* 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]] enables you to deliver new features faster, greater customer satisfaction, greater market share, more productive (and most importantly) happier employees
Line 17: Line 18:
 
** Don't divide and conquer
 
** Don't divide and conquer
 
** Use peer review (and do that without fear or doubt)
 
** Use peer review (and do that without fear or doubt)
 +
 +
=== Deployment ===
 
* Deploy as often as you can. Make it daily routine. (not nightly, not on weekends, avoid downtime)
 
* Deploy as often as you can. Make it daily routine. (not nightly, not on weekends, avoid downtime)
 
* Make smaller changes, more often
 
* Make smaller changes, more often
 
* Automate all unit + integration tests  
 
* Automate all unit + integration tests  
 
* Use agile techniques, if possible
 
* Use agile techniques, if possible
* The three ways
+
=== The Three Ways ===
** First way: Improve the workflow from development to deployment
+
* First way: Improve the workflow from development to deployment
** Second way: Instant feedback, using:
+
* Second way: Instant feedback, using:
*** stopping the assembly line (meaning, stop deployment, if tests fail)
+
** 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
+
** care as much about the work effort as the improvement of your working and workflows
*** use automated tests
+
** use automated tests
*** shared pain of developers and OPs
+
** shared pain of developers and OPs
*** measure the effects or your changes
+
** measure the effects or your changes
** Third way: Cultural change
+
* Third way: Cultural change
*** build a culture, that lets you take risks, learn from success (and failures)
+
** build a culture, that lets you take risks, learn from success (and failures)
*** accept that repetition and practice is the foundation of mastery
+
** 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 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
 
*** [https://plus.google.com/+BrunoOliveira/posts/B9eSCNK7oNe Geek Productivity Chart]
 
*** [https://en.wikipedia.org/wiki/Little's_law Little's Law]
 
* TOC - [https://de.wikipedia.org/wiki/Theory_of_Constraints Theory Of Constraints Method]
 
** identify the system's constraints
 
** decide how to exploit the constraints
 
** subordinate everything else to the above decision
 
** elevate the system's constraints
 
** if you broke this constraint, start over
 
* 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)
 
  
 +
=== 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 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
 +
** [https://plus.google.com/+BrunoOliveira/posts/B9eSCNK7oNe Geek Productivity Chart]
 +
** [https://en.wikipedia.org/wiki/Little's_law Little's Law]
 +
** TOC - [https://de.wikipedia.org/wiki/Theory_of_Constraints Theory Of Constraints Method]
 +
*** identify the system's constraints
 +
*** decide how to exploit the constraints
 +
*** subordinate everything else to the above decision
 +
*** elevate the system's constraints
 +
*** if you broke this constraint, start over
 +
=== 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…)  
 
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…)  
  

Latest revision as of 10:06, 19 May 2020

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)

Deployment

  • 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 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: