If you’re starting here, you might want to see the introduction (and table of contents) or you may want to go back to the previous post DevOps 101: Culture and Mindset.
DevOps didn’t come from nowhere, and it doesn’t operate in a vacuum. Any time you’re trying to apply DevOps principles, there are already going to be existing ways of doing things either in the workplace or, at the very least, in the minds of the team as they come together. You might build a team of thirty professionals, and they would have thirty different opinions on the “right” way to do things.
Relatedly, it’s hard to define DevOps, because it’s one of those terms that’s used in slightly different ways by different people. There’s a fair amount of debate about what is and isn’t DevOps.
There’s a whole discussion about whether or not it should be “DevOps” or “DevSecOps” and whether or not the two terms refer to the same thing. In a future post, I’ll explain why I prefer the term DevOps, even though I think everyone would agree that the “Sec” (Security) portion of the culture is extremely important.
To muddy the waters even further, a lot of people tend to define DevOps by the techniques or tools that a DevOps engineer would employ: automated testing, automated pipelines, monitoring tools, etc. The DevOps engineer (and more soon on why that’s a contradiction) tends to be the one working on infrastructure, Developer Experience, or automated pipelines.
But the techniques, in my opinion, are always going to be secondary to what DevOps is trying to accomplish, which I think you could roughly sum up as:
- Shared ownership
- Workflow automation
- Rapid feedback
- Customer focus
The goal, as always, is to deliver the most value to the end user as possible within your resource constraints. But DevOps as a philosophy is an opinion that the best way to make that happen is an empowered team iterating quickly on customer feedback and constantly improving their processes.
But DevOps isn’t the only set of methodologies in software development. I wanted to take a moment to talk about how DevOps culture fits in with two other answers to that question of how to provide value: Agile and Lean.
Agile
If you’re reading this, you probably know Agile Methodology. You’ve likely used it, and there’s a very good chance you’ve slept through trainings on it. So I won’t dwell too much on what Agile is; the focus here is on how it relates to DevOps culture.
Agile methodology , in a nutshell, is a very short, iterative approach to the software development life cycle (SDLC; see the diagram if you need a refresher). The core of Agile is to frequently make small, iterative changes, deliver them, get user feedback, and repeat.
Let’s take a brief detour into history so we can contrast Agile with the much-used-but-never-admitted-to Waterfall approach. Prior to the popularization of Agile, software development shops would plan out features months (if not years) in advance. They would have little to no user feedback during the development. Designers and managers would plan out development in stages, where each stage in the SDLC was completed in sequence and passed on to those responsible for the next stage. Development would move forward and downward in the massive charts, hence the term “waterfall”. Waterfall originated with physical manufacturing processes, where there might be thousands of parts to design, build, and assemble into a single product.
In software, under the Waterfall Methodology, developers would often work on a slew of new features, and then everyone would spend a lot of time at the end trying to integrate dozens or hundreds of changes into the code base all at once.
It’s probably hard for modern developers to imagine the state of the industry before Agile really caught on. Don’t get me wrong: Agile has its flaws, but it’s miles (kilometers?) better than what came before!
Unlike Waterfall, Agile instead prefers to focus on the value a team can add in the present and from the users’ point of view. In Agile, if a thing isn’t in the hands of users, then it might as well not be done at all. And where a Waterfall method might spend months on a feature, Agile emphasizes breaking changes down into tiny increments that can be completed within a single “sprint” of just a few weeks.
Because the feedback loop is so short in Agile, a team can adapt quickly to what the users say about new features. Is it accessible enough? Does it not work as expected? In Agile, you can course-correct quickly.
I don’t want to get too bogged down on Agile Methodology; it’s important to DevOps culture, but it’s also described very well elsewhere. What I want to note is how it intersects with DevOps culture in a few important ways:
- Agile promotes active collaboration with customers and stakeholders throughout the development process. By involving customers in decision-making and regularly gathering feedback, teams can align their efforts with customer needs and deliver value more effectively. This principle aligns with DevOps’ customer-centric approach.
- Agile values human interactions and communication within teams. Effective collaboration and communication fostered by Agile practices are essential in DevOps culture, where cross-functional teams work closely together to deliver software solutions.
- Agile prioritizes working software as the primary measure of progress. Similarly, DevOps encourages the continuous delivery of working software through automation and streamlined processes. This principle emphasizes the importance of delivering tangible results over excessive documentation.
- Agile recognizes the need to be adaptable and responsive to change. DevOps aligns with this principle by emphasizing flexibility, iterative development, and the ability to rapidly respond to evolving customer requirements and market demands.
Lean Principles
I don’t think software development as an industry is nearly as aware of Lean methodology as they are of Agile. It isn’t required reading, and you don’t have to list it as a core skill on your resume. If you’re consulting, as I’ve done for most of my recent work, then the customer has probably never even heard of Lean.
Lean methodology, also known as Lean manufacturing or Lean thinking, is a systematic approach focused on eliminating waste, maximizing value, and continuously improving processes. It originated from the Toyota Production System (TPS) and has since been applied to various industries, including software development. Lean emphasizes creating value for customers by streamlining processes, reducing inefficiencies, and optimizing resource utilization.
Lean is about constantly evaluating development workflows and asking “Can I make this faster? Use fewer resources? Require less human input? Do I even need to do this at all?” Where Agile is about iterating quickly on the product, Lean is about iterating frequently on the processes.
In software development, the DevOps movement has borrowed a few concepts from Lean. Here’s how they compare:
- Lean focuses on identifying and eliminating waste or non-value-added activities. This aligns with DevOps, which aims to streamline processes, automate repetitive tasks, and minimize unnecessary work to increase efficiency and reduce waste.
- Lean emphasizes building quality into the development process rather than relying solely on post-production testing. Similarly, DevOps emphasizes automated testing and quality assurance practices throughout the software delivery pipeline to ensure high-quality software releases.
- Lean encourages empowering individuals and teams to make decisions, identify and solve problems, and continuously improve processes. DevOps culture values autonomy and encourages cross-functional teams to take ownership and responsibility for the software delivery process.
- Lean promotes rapid and frequent delivery of value to customers. This aligns with DevOps’ focus on continuous integration, continuous delivery, and shortening the time between code changes and deployment to enable faster feedback loops and accelerate value delivery.
- Lean emphasizes respect for individuals and their contributions. DevOps culture fosters a collaborative and inclusive environment that values the expertise and contributions of all team members, promoting mutual respect and creating a culture of trust and psychological safety.
As you can see, DevOps draws a fair amount of its inspiration from methodologies that were already being used in software development or in other fields of manufacturing. While DevOps has developed its own techniques and cultures, it’s still useful to consider where a lot of its core values came from and how they continue to interact with the prevailing thoughts within the industry.
Next: Cross-Functional Teams and why they’re important to delivering quality products quickly.
Build Artifacts with Andrew 