Having learned that work was moving toward an operationally based testing paradigm, I knew I had to learn more about DevOps and how organizations are organized and how they implement a development paired with operations paradigm to be more successful and deliver greater value to their customer. I asked my fellow Agilistas in the Kanban SIG of Agile Denver for a recommendation on books to read. I was directed to the Phoenix Project by Frank. This write up is to share with you what I have learned and how it might apply to my current work.

The book starts out with a mid-level manager thinking he is being called into work because of a problem in his area. Quite the opposite, he was being promoted to head of IT and asked to lead the Payroll system failure as the highest priority. The book then follows his experience over the next few months in his attempts to learn, implement, and create value for his company in the IT department using DevOps.

Through the entire book, his work is compared to an assembly line in a factory. Some people don’t like the factory comparison to software development because they feel it is a creative avenue and that there can not be any creativity in a factory. Quite the opposite. Toyota, many decades ago, implement the kanban (card) system. This was where it was a pull system. Pulling work down the line. So when you were ready for the next item at your station you would raise your card and the next item would be sent down the line. They also instituted weekly retrospectives and implemented one improvement the following week.

With an Agile Transformation to a DevOps model takes discipline and retrospectives This allows one to work through the process in an incremental manner and reflect on what is working and what is not working. The other thing that is important is to have a mentor/coach to help one see how things are working and not working and help direct one to make the tough but good choices to get to where you want to be in your Agile world.

The first thing you learn is to visualize your process; to understand what your work flow is and what work is currently happening. As with the kanban methodology, then you limit your work in process so you can have a faster through put. One looks at the bottlenecks in your flow, analyses them and makes changes accordingly to remove those bottlenecks.

Another thing you learn about is how to replicate the most important person on the team….. More review to be uploaded soon.