To help set the context for those starting points, I must first attempt a definition for "DevOps" and the goal toward which it aims. The word "DevOps" is a portmanteau of "Development" and "Operations". It was formed from a realization that "Devs" and "Ops", while normally separated, needed to collaborate more closely in order to increase the value that they provided to the rest of the business. To accomplish this closer collaboration, many of the leading principles from physical manufacturing were applied with great success. This led to a paradigm shift as the business value was consistently delivered at an ever-increasing pace, allowing those businesses that ingrained DevOps principles and practices into their daily work to "win in the marketplace".
Giving baby steps for each part of the typical organization would easily lead to an overly lengthy article and would quickly go outside my realm of expertise. To prevent this, I have identified three typical personas that I have worked with and will give the starting points for each one. These personas are the individual contributor, the team lead, and the manager.
The Personas
The individual contributor is the person whose daily work delivers the actual business value. This person could be a software developer, a systems administrator, or a quality assurance tester. For this person, I would recommend starting out with automating their development environment. Make sure that it can be set up consistently, repeatedly, and imitates the production environment. Pay attention to what makes setting up the environment painful and generates unplanned work. That pain is a signal of improvements that could be made to the product and product development process. Often, these improvements help ensure that their work meets the ideal of locality and simplicity, which leads the team to be happier and more productive.
The team lead is the person whose daily work involves providing technical guidance to the individual contributors on the team. For this person, I would recommend starting with mapping out the steps required for taking the code from commit to in use by customers, how long each step takes, and how many people are required to accomplish each step. This helps with ensuring that the team is always aware of opportunities to improve daily work, and of communicating to the managers when the team is about to hit a roadblock so that it can be removed before they reach it, enabling the continuous flow of value to the customer and a constant tightening of the feedback loop.
The manager is the person whose daily work involves coordinating the direction of multiple teams and keeping them in alignment. For this person, I would recommend examining one of the products in his or her portfolio with the goal of communicating and clarifying the impact that a DevOps transformation would have on the people working on the product. When this communication is done well, the teams will grasp how the goals of the DevOps transformation align with the goals of the product and when to signal that they have run into an impediment to achieving those goals that need help from the manager to solve. This builds psychological safety which is incredibly important (though not sufficient) for ensuring that the members of each team are happy with the products they are delivering. This has a follow-on effect of delighting the customers through the increasingly rapid delivery of value.
These steps alone will not cause a DevOps transformation, but they will begin the journey and hopefully provide some quick wins. However, I must give a word of caution, which I think might be best illustrated with a story.
Learning a New Skill is Hard
My wife and I enjoy taking our girls to the park. One of them at toddler age refused to walk completely on her own. At the same time, she loved to ride down the slides, especially when I was waiting for her at the bottom. She would land at the bottom on her feet and then put her arms up, expecting me to pick her up. After doing this a few times, I had a sudden insight and stepped back a pace or two from the bottom of the slide and put my arms out. Down she came and landed on her feet. Then she started toddling towards me while I started walking backward with my hands out. About 5 steps later she stopped and started crying, not because she thought I was running away from her, but because she suddenly realized she was doing what she thought she was not ready to do. After a few more trips to the park that week, she finally had enough confidence and willingness to walk by herself.
This happens in DevOps as well. During the initial push, the team will begin to perform and then hit a wall because they are not good at it yet or they hit political headwinds and must slow down in order to deal with them. This frustration can lead to DevOps being perceived as just another fad that does not change anything. Sometimes you must push through the frustration and recognize that the benefit to everyone is worth the time and pain in learning to get it right both within the team and in the organization.
A Final Note
Every DevOps journey is about streamlining the delivery of value to the customer in a way that benefits all who are involved in the process. For all to benefit, we need to ensure that we are always learning not only about the need as given but upon the sources of that need so that the business is handling the real problem rather than the apparent one. There is nothing more demoralizing than finding out that a journey will never end because the real problems are not being addressed. When a customer's need is met and the need disappears, then the journey for more effectively meeting that need is finished. By continuously learning from the customer and streamlining to meet the customer's need the company will be able to pivot and change to meet new needs, otherwise it will disappear along with the old need. Such a pivot can only happen when the business has a higher purpose outside of simply making money by fulfilling the customer's needs. This higher purpose not only drives the individual contributor, the team lead, and the manager to greater levels of excellence. It also can drive the direction that customers are going in their own journey and that we are all on. Discussion of that wider journey, however, is outside the scope of this article. Good luck and God be with you as you begin your DevOps journey. If you would like any help or more information, reach out! Improving can help you get started on these baby steps.
*Many thanks to the authors of DevOps Handbook, Project to Product, and Sooner, Safer, Happier. Without them, I would not have had the vocabulary to write this article.
