The Phoenix Project: Lessons I learned | MezcalDigital

  • The Phoenix Project: Lessons I learned



    The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
    by Gene Kim, Kevin Behr, George Spafford





    At First Glance:

    I enjoyed the book, it is easy to read and it puts forward quite clearly the problems that can be faced by an IT department within the organisation, as well as the solutions to those problems.
    The book remained me of "The Adventures of an IT Leader", but without the academic details at the end of each chapter.

    The Book

    It is an academic book, you read it to learn more about solving problems within an IT Organization. However, it is written as a story. Bill is our hero, and we follow his story after being promoted to VP of IT Operations, and all the problems he faces within the organisation, as well as the solutions he is proposing to each of them.
    The book is not a great novel, so don't expect to read a gripping tale of adventure and betrayal with deep and troubled characters. But the story is a good way to get lessons across, it is fun to read and I could not help myself, but identify few characters with colleagues I have worked on in the past. Mainly because of their job role.

    Lessons

    The book puts forward the idea of DevOps and using Lean Manufacturing concepts in an IT organisation. Whereas Scrum focuses on how to organise work within a Team, this book focuses on how to organise the flow of work within the whole organisation. Drawing parallels with manufacturing engineering. My takeaway lessons are:

    1. About Work in Progress
      1. Make work in progress visible. Make sure you know how much work is in the queue. 
      2. If Work in Progress keeps piling up, then identify and solve the cause.
      3. If Work in Progress is not flowing, then identify and solve the cause.
    2. Understand what type of work is your organisation doing.
    3. Understand how is work flowing within your organisation, and protect your key resources from overworking. 
    4. Define a clear channel of communication and avoid accepting work from unofficial channels.
    5. Work does not finish in the hand-off process, it finishes when it is being used by the end-user.
    6.  Make sure there is a clear communication among all the members involved in the work being done. Avoid the "it is not my problem and it is your fault" attitude. 
      1. Toward this end, create interdisciplinary teams.

    I did not like

    Applying It

    • I am smug to report that a lot of the recommendations the authors propose I implemented them while I was CIO of the City Administration of San Luis Potosi. I confess, I did not know about DevOps, but using User-Centred Design and the Agile Manifesto one can reach the same conclusions. So combining what you know, with what other people know about it, increases your knowledge, and it helps refine and improve what you are doing.
    • Using it to develop Wandr App: right one we are only focused on developing two types of work: Projects and Changes. We don't have internal projects that are independent of projects, and Unplanned work has been under control. One of the key factors to control unplanned work has been to protect resources.
    • Even though we are small, does not mean that soon we will face the problems described in the book. We are close to releasing our products officially to the public, so we need to plan for it. No point building foundations that support a skyscraper if we are only building a one-floor building; we can run out of money or time building things we don't need to release work. But, we do need to plan for it, think about it, and know how we are going to scale from one-floors to two-floors, etc. And the best way to plan and think about it, it is to have the processes ready.

    Overall

    A good book to learn about DevOps, good food for thought and good pointers to more resources to learn more about it.

    Originally published on one of my previous blogs
  • 0 comments:

    Post a Comment