The Phoenix Project: Difference between revisions

From Wurst-Wasser.net
Jump to navigation Jump to search
No edit summary
Line 24: Line 24:
* 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
=== The four types of work ===
** business projects
* business projects
** internal IT-projects
* internal IT-projects
** changes
* changes
** unplanned work / recovery work
* unplanned work / recovery work
* [[WIP]] kills!
* '''[[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 :) )
** 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.
** 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)…
** 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)
** 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]
* Links & Notes
*** [https://en.wikipedia.org/wiki/Little's_law Little's Law]
** [https://plus.google.com/+BrunoOliveira/posts/B9eSCNK7oNe Geek Productivity Chart]
* TOC - [https://de.wikipedia.org/wiki/Theory_of_Constraints Theory Of Constraints Method]
** [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
** identify the system's constraints
** decide how to exploit the constraints
** decide how to exploit the constraints

Revision as of 09:03, 19 May 2020

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

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