Friday, February 3, 2017

Sound bites from 'The Phoenix Project' novel


The Phoenix Project is such a riveting story. Being a software developer, it resonated so well with me. Even if you are not a software developer, there is something to be learned from this book. This book shows how important it is to be honest, have integrity, faith, encourage risks and continuously improve in small but meaningful steps. The principles learned from this book can be applied to any industry, process, organization and even relationships. 



I have a few quotes when I was done reading the book.


Automation creed
    If it can be done once, it can be automated for future occurrences. 

    If it needs to be done more than once, it must be automated.

    People before process. 

    Feeling of being in control is an illusion. Let go of that feeling and breathe because you can still succeed when you succeed as a team.



    Four types of work
    1. Business projects
    • Business initiatives
    • Typically tracked by the project management office

    1. Internal IT Projects
    • Infrastructure and IT operations projects
    • Projects required to support the business projects
    • Internally generated improvement projects

    1. Changes
    • Generated by business projects and internal IT projects.
    • Track both business and IT project changes in the same ticketing system

    1. Unplanned work and recovery work
    • Operational incidents
    • Caused by business projects, internal IT projects and changes
    • Always at the expense of other planned work commitments
    • Track them and automate to prevent them

    Wait time formula
    wait time = (% busy) / (% idle)

    The three ways explained
    1. First way
    • Work flows from left to right from development to IT operations to market
    • Maximize flow
      • Small batch sizes of work
      • Small intervals of work
      • Never pass defects to downstream work centers
      • Continually optimize for global goals of the business organization
    • Necessary practices
      • Continuous build, integration and deployment
      • Create environments on demand using the same process to create all environments
      • Limit work in process (WIP)
      • Build systems and organizations that are safe to change by keeping both agile and nimble

    1. Second way
    • Constant flow of feedback from right to left at all stages of the value stream
    • Prevent problems from happening again. By doing this we create  quality at source.
    • Create and embed knowledge where needed
    • Necessary practices
      • Stop the production pipeline when builds and tests fail in the deployment pipeline.
      • Continually elevate the ‘improvement of daily work’ over 'daily work’.
      • Create fast automated test suites to ensure code is always in a deployable state.
      • Create shared goals and shared pain between development and IT organizations.
      • Monitoring to ensure code and environments are operating as designed and customer goals are being met.
    1. Third way
    • Culture that encourages continual experimentation
    • Encourage taking risks 
    • Share an understanding that repetition and practice is the key factor for perfection.
    • Necessary practices
      • Creating a culture of innovation, risk taking and high trust.
      • Allocating at least 20% of dev and IT on non-functional requirements
      • Continual reinforcement that improvements are encouraged and celebrated.

    Identify and focus on
    1. Constraints
    2. Materials
    3. Resources