In addition to this blog, I decided to write a short text about the books I appreciated most. This first exercise was full of learning. Writing a text about a book involves going deeper into the main ideas, revisiting some passages and summarizing the concepts described. For me, it’s a very convenient way to properly assimilate the essence of the book.
So the first book I wanted to share is one I read a few months ago “The Phoenix Project” from Gene Kim, Kevin Behr, George Spafford. It’s an easy-to-read novel about IT & DevOps which uses a story to explain some key concepts about DevOps. On the same way that “The Goals” from Eliyahu M. Goldratt did in the 80’s. Even though “The Phoenix Project” was written some years ago, the key ideas are still valuable for a lot of us and still describe the reality in many companies. I strongly recommend that you read it if you want an overview on how flows work in an IT organization and on a devops implementation.
I will not summarize the book as there are already many articles about. Instead, I will highlight the main ideas and quotes I want to keep in mind.
Four types of work
This is the starting point. Understand what the activities are. Understand what the teams are working on and classify these tasks. Eric (the only character I will quote), the advisor, defines that there are 4 different types of work we need to identify to understand the flow of work inside the company.
First of all, the Business project work. This is the easiest to identify, the one we all have in mind but not especially the one we can be focused on. These are the projects the business really asks IT for, the ones that bring direct customer value.
Then, the IT project work. Essential for delivering the business projects, these projects have often poor visibility and are delivered without any monitoring and communication. It’s mainly infrastructure and operations projects, internal improvements.
Changes. This is all the work done to manage fixes, changes and improvements generated by the two above types of work. And finally, Unplanned work. This one has the ability to affect all the others kind of work, to reduce the delivery of the teams. Unplanned work has often a higher priority due to his nature, and so far, is a nightmare when we want to stay focused on the roadmap. Unplanned work is about incidents, fixing problems in the three previous types of work.
Once identify, you’re able to analyze your teams activities based on these types of work and see either or not you are delivering values. This is also helpful to manage your backlog priorities, identify bottlenecks and so on.
Three ways of devops
The starting point is often the same for every company with a bit of age. The information system is stuck by the weight of history and the flows between the needs and the production had become a real nightmare. It’s difficult to provide values for the business and IT is seen as a brake for all the businesses. No one understands what IT does, with so many people and so little value created.
So it’s probably the right time to understand the Three Ways at the heart of Devops practices and start rework the engineering processes.
The first way is relying to The Flow. Understand and accelerate the flow of work as a whole. Not only at a specific work center level, but at the entire system level. From development to operation to customers. Make the work visible is one of the first step of this way to understand what the teams are working on. As software development may be an abstract concept, we need a way to visualize the work done. A kanban board could be a good start. Doing this exercise, you may be surprised by the amount of work you have in your backlog. Once you know what you have to do, your objective should be having the work flowing from left to right, from business to customer, as quick as possible. The fact you have many ongoing tasks is in the opposite of this objective. Even if it seems not intuitive, you need to limit the amount of work in progress to accelerate the flow. Splitting your tasks in small pieces of work help to accelerate and increase the quality of this pipeline. Last but not least important point of the first way is the understanding of your constraints. You should focus on removing your constraints, whether it is key resource, technology issue, or whatever that can affect your pipeline. Your flow rate is managed by your constraints. It can’t be faster than your biggest constraint is.
As the first way allows to accelerate the flow from left to right, the second way is related to the Feedback. The need to set up and amplify feedback loops for right to left to prevent problems from happening again, and enable faster resolution. A good way to achieve this is to create quality at the source, build quality into everything. Some good practices as code review, peer-programming, ownership, and a strong delivery pipeline with continuous integration, deployment process and fast-automated tests will enable you to provide quality and quick feedback loops to both developers and businesses.
The third way, Continual learning, focuses on creating a culture of continual experimentation and learning. It means creating a culture that encourages experimentation, risks and learns from both successes and failures. Your ability to success in the first two Ways will allow an easy access to continuous learning as you can manage small risks (small WIP), have quick feedbacks on the changes, and provide the ability to quickly rollback in case of issue. In this way, the more you repeat the experimentation, the delivery, the more you mastery. The Third Way is all about ensuring that we’re continually putting tension into the system, so that we’re continually reinforcing habits and improving something.
IT as a competency
Eric (still the advisor) used to spread the idea that ** “IT is not just a department. It’s a competency that we need to gain as an entire company.” ** And this is one of the main ideas we need to keep in mind. It’s not just about IT and business. It’s IT inside the business. Or the business inside IT. You need to organize the flows around IT and business to have a coherent system as a whole and avoid silos. Your information system design is the reflect of your organizational design.
You always pay your debt
Prioritization between business needs, IT Projects and changes is a tough exercise as only the first one is visible for your internal customers. Forgetting the 2 others will provide impacts on the first one on a middle term and finally stuck your all delivery. Eric summarize this idea like this: ** “If an organization doesn’t pay down its technical debt, every calorie in the organization can be spent just paying interest, in the form of unplanned work.” **
The diva syndrome
The last idea I’d like to share is related to the team you are building. Often we’re trying to get only A-players. I think it’s not sufficient, and that can lead to what I call the Diva syndrome. Someone who takes a too huge place in the team, avoiding other way of thinking and team development. Just keep in mind that kind of situation will lead to a constraint in your flow. ** “A great team doesn’t mean that they had the smartest people. What made those teams great is that everyone trusted one another.” **