DevOps culture

DevOps is a set of practices that combines software development and IT operations. It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. DevOps is complementary with Agile software development; several DevOps aspects came from the Agile methodology (https://en.wikipedia.org/wiki/DevOps). Diving deeper into that definition, we learn DevOps is a multi-faceted practice. DevOps has seven guiding principles that combine to form DevOps culture. DevOps culture aims to decrease cycle time, apply incremental changes, and create a more streamlined development process.

The following diagram gives a graphical representation of the seven principles of DevOps:

Figure 1.3 – DevOps culture – principles

Now we will take a deeper dive into each of the seven principles of DevOps.

Customer-centric

Test often, get end user feedback frequently, and fail fast. The feedback loop between the customer and end users of products needs to be as short as possible. All actions taken by a team should be focused on the experience of the end user. This is also where the saying shift-left comes from, meaning the sooner a feature is tested for bugs, the quicker it will be resolved, and fewer downstream dependencies will be compromised.

A Tale of Two Start-Ups Bidding to Develop a Fitness Tracker for a Large Insurance Company

Need: A wearable device that will track users' fitness.

Acceptance Criteria: A wearable watch-like device that tracks various workouts.

Company X employs test-driven development and has weekly demos where they receive feedback. During a demo, they showcase a device and describe plans to track running and cycling. They learn that a big portion of their customers are swimmers. The team takes the feedback and shifts priority from running and cycling to swimming. The customer is impressed.

Company Y does not feel it is necessary to have demos as their past applications have done relatively well. The team focuses on the running and cycling workout tracking ability. During acceptance, they receive feedback that the watch must have the ability to track swimming. The development team is unable to meet the requirements in the given time frame. The customer is not impressed.

Outcome: Company X is awarded the contract and goes on to be a billion-dollar company. Company Y is not awarded the contract and receives poor press leading to another failed start-up.

Foster collaboration

The collaboration between the development team and IT operations teams is the most basic must for DevOps. Removal of silos ensures collaboration and alignment across entire organizations, ensuring a singular focus on the customer.

A collaborative culture is most effective when implemented using a top-down approach; executive sponsorship should be lined up ahead of any major culture shift. Another, much slower, approach is grassroots initiatives within an organization. A group of like-minded individuals with a platform to share on is all it takes to start a revolution. The trouble with the latter approach is overtime burnout can occur if you work tirelessly to make a change and see no results time and time again. Instead start with something you do have control over, such as your team.

Robert Weidner is a senior director at Optum and is one of only 26 Certified Enterprise Coaches in the world and is also my mentor and former manager. While working under Robert, our team was empowered to choose what micro team we worked in. We were also encouraged to hop over and help any other micro team who needed our support. When it came to stack ranking the team and fitting us to the bell curve for our bonus, we did our reviews of each team member during an offsite with the entire team present and in the hot seat while receiving feedback. It was frightening, but it worked because the team trusted each other.

End-to-end ownership

Feature teams ensure end-to-end responsibility by giving the team a vertical slice of a product, a feature. The feature, Feature 1: Button X, has two user stories: one for development and one for testing. The definition of done for the feature also requires the feature to be deployed successfully. This can be seen in Figure 1.4. The final piece to note is the ongoing support of Button X also remains with the team. Our company has started to call this You Build It, You Own It (YBYO). The rationale behind this concept is that the team who built something is going to have the most knowledge about it when there is a production issue.

Figure 1.4 – Feature-centered team (E2E ownership)

In traditional development methods such as waterfall, teams are broken down and created at the activity level, also known as a horizontal slice of work. Ownership of a feature is split among various teams. In the following example, three teams must interact with the feature before it makes it to the end user, and another team is responsible for ongoing support. This is problematic; the operational support team is oftentimes not aware of the most recent changes the development team made, leading to extended downtimes and outages:

Figure 1.5 – Waterfall teams

Now, we'll talk about continuous improvement.

Continuous improvement

Continuous improvement was inherited from Lean. The entire team should be encouraged and, more importantly, empowered to make changes without fear of failure. Teams instead use failure as opportunities to improve on flawed processes. This is also known as failing forward. Failing forward allows for better control over risks as well as continuing to push the team forward. For your entertainment, the following is a script (continous_improvement.sh) to ensure your team is empowered to make improvements, continuously:

Figure 1.6 – Continuous improvement shell script

The preceding script is a simple script that defines the flow of how the continuous improvement flow would operate if it were a shell script.

Automate everything

While doing research for this book, I noticed two common wordings: automate everything and automate (almost) everything. Further research revealed a common theme in types of processes that should not be automated, items with no payback, and items including a high degree of design or visual inspection, as seen in the following list (https://dzone.com/articles/what-to-automate-and-what-not-to-automate):

• Automation with no ROI
• Design
• Final QC of an application

Processes should have the least amount of manual intervention possible. The reason for this is simple: humans are error-prone while machines (computers) are excellent at executing high-volume repeatable tasks.

Next, we will cover continuous learning, a DevOps principle that is important for individuals looking to enter the field of DevOps, as well as those looking to stay relevant in the ever-changing field of technology.

Continuous learning

Technology is evolving at an astonishing rate; the most well-known example of this is Moore's law. Moore's law is the observation that the number of transistors in a dense Integrated Circuit (IC) doubles about every 2 years (https://en.wikipedia.org/wiki/Moore%27s_law). The number of transistors that fit into a microprocessor reached over 10 billion in 2017. It was under 10,000 in 1971( https://ourworldindata.org/technological-progress). Being a continuous learner is a personal attribute that will get you hired.

Pro Tip: You Must Be a Continuous Learner If You Wish to Succeed in DevOps

Creating a public project using a new technology is a great way to showcase this to potential hiring managers. Another way is to make sure to leave digital breadcrumbs of the most recent articles you have read, whether it be a post on LinkedIn or a tweet on Twitter.

An example that sticks out is an interview for a senior DevOps engineer role that was down to the final two candidates. Both candidates had tenure with the organization, exceeded the qualifications, interviewed well, and had advanced degrees. The candidate that received an offer displayed a hunger for knowledge throughout the interview process in subtle ways. The candidate chose to focus not on their degree but on a side project that had the purpose of teaching the candidate Golang. The theory of data science was being demonstrated with the application and it was cool. What stuck out, and continues to, was the candidate's desire to learn new things.

In summary, the combination of development and operation along with the seven DevOps principles, when applied together, form the DevOps culture. DevOps is a completely unique derivative of Lean, Agile, and XP aiming to shorten the feedback loop between development and the end user.

Take a look at the following visual depiction of DevOps culture broken down into the practices and principles:

Figure 1.7 – DevOps culture chart

In summary, DevOps culture contains seven guiding principles, as seen in Figure 1.7. In the next section, different career paths for a DevOps engineer will be discussed.