DevOps Principles and Practices Explained in Ten Minutes

Ever wondered what DevOps practices and principles are about but don’t have time to read a book? In a fast-paced world where time is of the essence, understanding the core principles of DevOps can provide a significant advantage to software development teams. This article explains, with examples, DevOps practices.

There are many variations of DevOps. I prefer the “DevOps Handbook” by Gene Kim, Jez Humble, Patrick Debois, and John Willis. Their book explains the Three Ways, Value Streams, Theory of Constraints and System Thinking.

Some famous books. Picture by Fredrik Carleson

What is DevOps Practice?

In its simplest terms, DevOps is short for Development + Operations. The strategy is similar to the Shift Left idea, where programmers and testers work together in the team. You can work more efficiently by putting together people with the necessary skills. You get a better flow and reduce time to production. You avoid Waste in the process, such as hand-overs, work in progress, delays, defects, etc.

You can combine all necessary competencies — Dev, Security and business. Then you can call it DevSecOps, BizOps, DevSecBizOps etc. Your imagination is the limit.

The fundamental assumption is that you can create value faster by putting together the right people. Assuming you have a culture emphasizing flow, fast feedback and continuous learning.

Continuous Integration (CI) and Delivery (CD) are similar to DevOps but with one crucial difference. In CI/CD, you wish to automate the process without human interaction.

DevOps Practice, in contrast, involves humans. By involving humans, we also introduce unpredictability. When we run a pipeline, we expect to get the same result every time we run it. When we give the same problem to different teams, they will solve it differently with various results. By automating, we can remove unpredictability. But often, we face complex situations that we can’t automate.

DevOps Culture

Collaboration and communication are critical for processes that cannot be automated. Or when a step-by-step list cannot be followed. When we work in unpredictable situations, we need several people’s expertise. We need to collaborate, proceed through trial and error, and learn as we go along to achieve a result.

Suppose a task is simple and understandable. Then one person can complete the job getting the same result every time following instructions. In that case, we don’t need the same amount of collaboration and communication.

DevOps Practices rely on experimentation, fast feedback and continuous learning to handle unpredictability. The practices are called The Three Ways in the DevOps Handbook: Flow, Feedback, and Continuous Learning.

The Three ways

Flow is about having work flowing as fast as possible throughout a process or value chain. There are usually a lot of constraints that stop our flow.

A quote from U.S. Navy Seals says, “Slow is smooth, and smooth is fast”. It’s a reminder that the best way to move fast in a professional setting is to take time, slow down, and do the job right. If you move too fast and in the wrong direction, you open yourself to flanking manoeuvres and put yourself in danger. By moving slowly and getting feedback from your environment, you can adjust and reach your objective faster.

Feedback is about getting the correct information, when needed, and doing something about it.

Flow allows us to put something into production fast, and feedback loops enable us to learn. Continuous learning is about learning from what has been previously realized. You correct the mistake and then change the system to prevent the errors from happening again. This is sometimes called Double-loop learning.

There are many practices, frameworks, tools etc., that can help us once we have established a mindset towards the Three Ways, such as

• The Theory of Constraints (ToC)
• System Thinking
• Value Streams

In addition to the above, the Seven Wastes of Software Development also is helpful to keep in mind.

Photo by Andrew Seaman on Unsplash

The Theory of Constraints

The Theory of Constraints (TOC) is a management philosophy developed by Eliyahu M. Goldratt in the 1980s. It is a framework for identifying and managing constraints or bottlenecks in a system. The purpose is to improve overall performance and productivity.

The fundamental principle of TOC is that any system is limited in achieving its goals by one or a few constraints (bottlenecks). A constraint is any factor that prevents the system from achieving higher performance levels or throughput.

The TOC approach consists of five critical steps explained below with an example:

1. Identify the Constraint: A team identifies that the primary constraint in their system is the dependency on a key developer, John. He is the only one who can make changes in a critical software component used by all teams. John becomes overwhelmed with tasks as “his” component needs to be changed every time other components are changed. John becomes a bottleneck, causing delays overall in the flow.
2. Exploit the Constraint: Managers wish to ensure John spends his time correctly. They prioritize and allocate tasks requiring John’s unique skills, ensuring his capacity is best used. I.e. make sure that the developer works on changes with the highest priority.
3. Subordinate Non-Constraints: To help John, who is now causing a slowdown, team members like testers and UI designers adjust their tasks and work together with the specialized developer. They balance their work, coordinate their actions, and help keep the job moving well for the whole team.
4. Elevate the Constraint: To solve the slowdown, the team seeks ways to ensure the specialized developer John’s time is freed up. They train other team members to do John’s tasks, automate some work, bring in outside experts, and delegate work so he has more time.
5. Repeat the Process: Once the constraint is addressed, the team returns to step one and identifies the next constraint. For example, inefficient communication, lack of automated testing processes, or limitations in infrastructure. The team identifies and addresses constraints iteratively, striving for continuous improvement.

The focus on identifying and addressing constraints helps streamline workflow.

TOC emphasizes the importance of System Thinking. We are focusing on optimizing the entire system rather than individual components.

In the scenario with John, it is essential to realize that no matter how great and fast John is, he will always be a bottleneck and a risk for the company. Even if he learns to work twice as fast and at the weekends. The result is similar to having one cashier at IKEA. It doesn't matter have fast that person is. You will get queues unless you open more checkouts.

Focusing too narrowly on making individual parts work well might not help the whole system succeed. We usually call this sub-optimizing.

Let’s have another example. Imagine sales being measured on how much new functionality they can sell. Let’s pretend they sell new functions three times what the development unit can deliver. The effect will be priority issues and unhappy customers who did not get their promised functionality on time. In addition, we will have lower quality as the developers have to take shortcuts and death marches to meet deadlines. And an overburdened helpdesk due to all bugs because of lowered quality.

System Thinking

Systems thinking is a mindset that focuses on understanding how various components of a system interact with each other. How different parts collectively influence the behaviour and outcomes of the system as a whole. Sometimes we see this in software development. For example, when we make a small change in one component and suddenly discover unexpected behaviour in other parts of the system.

Let’s consider the example of the Sales mentioned above. A development team faces a recurring problem of missed deadlines and low quality in their software releases. They can apply the critical aspects of systems thinking to address this problem:

1. Holistic Perspective: The development team looks at the bigger picture. They realize that rewarding sales of new functionality puts the developers in a difficult situation.
2. Interconnectedness: The team analyses the interactions and interdependencies within the system. They understand that the pressure to meet unrealistic deadlines is a problem. Furthermore, the lack of automated testing or deployment makes the developers take shortcuts. Shortcuts result in low-quality releases.
3. Feedback Loops: The team identifies feedback loops that perpetuate the problem. Inadequate communication between Development and sales makes the issue hard to address. Sales promise when the functionality will be delivered without talking to the developers. Missed deadlines lead to rushed Development and testing, resulting in lower quality. In turn, low-quality releases require more time for bug fixes, further delaying subsequent releases.
4. Emergent Properties: The team realizes that deadlines are missed, and quality is low because of unrealistic goals. There is a need to grasp how pushing to sell lots of new features impacts the development process. Fixing this issue isn’t just about changing the software process alone; it requires looking at the bigger picture.
5. Dynamic Behavior: The team understands that changes in one aspect of the process have cascading effects on other parts of the organization. If sales sell three times more than they can deliver, they must triple their production. Which seems impossible. The easy fix is writing quick and dirty code. The approach has a cascading effect as it introduces more bugs that will cause the Helpdesk to be overwhelmed.
6. Boundary Definition: The team understands they cannot work within the boundaries of their unit to fix the problem. They must involve other departments and the entire value stream. From sales, development process, communication channels, requirements gathering, help desk, etc.
7. Long-term Perspective: The team takes a long-term perspective. They understand that solving the problem requires addressing underlying issues. Rather than applying quick fixes. Such as increasing communication between the different units. Ensuring their goals and KPIs are aligned and well thought through. A solution could be for sales to focus on selling existing functionality to new customers.

Applying systems thinking, the development team can take a comprehensive approach to address the problem. They understand that understanding how changes outside their domain can have interrelated effects. Only addressing issues within their unit will have little impact.

By considering the system as a whole and looking at the entire Value Stream, systems thinking helps avoid unintended consequences and optimize the system's overall performance.

Value Streams

Let’s consider an example of a software development team. Let’s examine how they can work efficiently in a value stream:

1. Customer Focus: The team continuously works to understand customer needs and requirements deeply. They communicate directly with stakeholders. They conduct user research and gather feedback to ensure they know the customer expectations and what creates value.
2. End-to-End Flow: The team visualizes the entire lifecycle from a customer perspective. From ideation to deployment and maintenance. They determine how to get a smooth workflow, minimizing delays and bottlenecks. They do so by automating and building processes as much as possible into daily activities.
3. Cross-Functional Collaboration: The team work together with members from various disciplines. Together they have all the necessary skills. They have the power to take something from start to end. This promotes collaboration, knowledge sharing, and efficient decision-making. The approach also ensures the team can independently deliver value to the customer.
4. Value-Adding Activities: The team identifies value-adding activities and strives to optimize them. They focus on activities directly contributing to delivering value to customers. Non-value-adding activities are eliminated or minimized. For example, unnecessary documentation, excessive meetings, gold plating or rework. The approach reduces Waste, improves efficiency, and accelerates value delivery.
5. Visual Mapping: The team uses visual mapping techniques, such as value stream mapping (VSM), to understand their value stream. They visually represent the workflow, depicting activities, handoffs, wait times, and potential bottlenecks. The approach enables them to identify areas for improvement, optimize the flow, and eliminate Waste.
6. Continuous Improvement: The team adopts a culture of continuous improvement. They often look at their work process to find ways to make things smoother, eliminate things that waste time, and improve things. They have meetings to reflect on their work, figure out what they’ve learned, and make small changes to improve their process. This way of working helps them adjust to new needs and technology changes while steadily improving their work.

The Seven Waste of Software Development

The DevOps Handbook does not mention Mary and Tom Poppendieck Seven Wastes from their book "Lean Software Development: An Agile Toolkit in the Context of a software development team". However, the Waste they have identified can help improve the flow of our software process.

Below are examples of typical Waste for a software team.

1. Partially Done Work: An example of partially done work Waste is when a developer starts working on a new feature without completing it before moving on to another task. The approach results in unfinished code, which can cause delays. Think of incomplete features as inventory lying around, taking space and costing money. A feature has value only once it is in production.
2. Overproduction (gold plating): Overproduction occurs when building “good to have” features. Functionality not immediately needed by the customer. Or exceeds their requirements. For instance, if the customer requests a basic functionality. The team goes beyond the requirements and adds optional complex features. The result could be better spent taking time from more prioritized features. In addition, it prolongs the time it takes before the customer gets their wanted functionality.
3. Extra Features: Building additional features Waste is similar to overproduction. But refers explicitly to adding functionalities not required or requested by the customer. For example, suppose the team includes other features without direct value to the customer’s needs. In that case, it consumes time and resources for more prioritized Development.
4. Task Switching: Task switching Waste occurs when team members frequently switch between different tasks or projects. For instance, a developer works on a feature. He is frequently interrupted to address support requests or work on unrelated tasks. This disrupts his focus, reduces productivity, and prolongs the original task’s completion time.
5. Defects: Defects Waste refers to bugs or errors in the software that require rework or fixing. For example, suppose a developer writes quick and dirty code to finish faster. The result is Bugs found in production which will come back and bite him later, causing both task switching and disruption to flow. In addition, it takes extra time to re-read and understand the code again. What looks like a time-saving shortcut may take more time to follow than the standard route.
6. Waiting: Waiting Waste occurs when team members await decisions, dependencies, or approvals. For instance, if a developer waits for feedback or approvals before being able to proceed, it wastes time and delays overall progress.
7. Motion: Motion Waste involves unnecessary movement or activities required to complete a task. An example of motion Waste is if a developer spends significant time searching for relevant documentation, navigating complex codebases, or manually setting up development environments instead of using automated tools. These unnecessary movements and activities increase the time required to complete tasks and reduce efficiency.

Summary

Central to DevOps is the belief that combining diverse skill sets can yield faster value delivery. As many different skills are needed, a key factor for success is to automate as much as possible and build processes into daily work.

The mindset, supported by a culture of flow, rapid feedback, and continuous learning, helps us become continuously better.

DevOps practices aim to empower software development. Understanding concepts like the Three Ways, TOC, Systems Thinking, and Value Streams helps organizations optimize their processes, improve collaboration, and accelerate value delivery.