While the DevOps methodology has existed for a while, it’s still a hot topic. Companies desire it but struggle with implementation.

DevOps is ubiquitous. Although a compelling trend, it should adapt to products, not the reverse.

Some disagree. I’m often asked, “Should we start with Docker or Kubernetes?” These questions are irrelevant without understanding the product.

Fancy terms like cloud, Kubernetes, containers, configuration management, and Infrastructure-as-Code promise improvements. But they’re to DevOps what telescopes are to astronomy—useful but not essential.

At its heart, DevOps bridges the gap between client expectations and development output. It emphasizes short release cycles, iterative design, and automation. What’s crucial for achieving this?

“Great communication,” you’re right! Tools are valuable only when they enhance communication.

Knowing what’s essential for completion is key. The job isn’t “code committed.” It’s “client accepted the production change.”

Once this is clear, document it. I recommend a README.md. Everyone, including newcomers, can stay informed.

Automation, the next step, is optional but a natural progression. Yes, it’s often associated with DevOps.

Wait, optional? Isn’t DevOps about deployments?

“DevOps engineer” often refers to a reliability, platform, or automation engineer. These roles enable DevOps, but the term is ambiguous.

Let’s examine DevOps further.

Understanding DevOps

Firstly, DevOps is not:

1. It isn’t just a job title prefix
2. It isn’t a team (though “Dev” and “Ops” are)
3. It isn’t a technology
4. It doesn’t mean “a coding system administrator”
5. It doesn’t mean “automating stuff”
6. It doesn’t mean “eliminating the operations team”

Therefore, “hiring a DevOps engineer” or “creating a DevOps team” doesn’t guarantee future-proofing. It’s like Agile development. Would you hire an “Agile developer”? It’s about how you develop, not a role.

DevOps is a methodology, a culture, a spirit. It means everyone—developers, operations, product managers—shares a vision maintained through communication. To a lesser degree, it involves using shared tools that benefit the product, not just individuals.

This requires a mindset shift, which is the main challenge. People must step outside their comfort zones and collaborate with different skill sets. Developers learn cloud and deployment; operations embrace coding and automation. Everyone learns and has new responsibilities.

It’s not easy, but with good communication and a shared goal, it’s achievable. This involves establishing a culture, lightweight processes, and proper documentation.

DevOps Automation as Documentation

Consider this: most DevOps tools are documentation tools:

• Readable build scripts document the build process.
• CI pipelines document the integration process.
• CD pipelines document product deployment.
• Configuration management documents installation and setup.
• Infrastructure-as-Code formally documents infrastructure.
• Containers’ Dockerfiles document microservice building and configuration.

These concepts enhance team communication by documenting processes, whether manual or automated. The key is stakeholder accessibility.

Code-based documentation surpasses manuals. Code is verifiable, predictable, and produces consistent output with the same input.

Written instructions breed interpretations. Ambiguity leads to assumptions, leaving you with little control.

Code is straightforward. Without concrete steps, it halts. These steps are crucial for DevOps communication.

DevOps Communication: Bridging the Gap

The Phoenix Project illustrates the struggles of a newly promoted manager handling a complex deployment. With communication lacking, everyone fights fires with little progress. The book is aptly subtitled “A DevOps Story.”

Interestingly, no new tools are introduced. Can communication alone achieve DevOps? The book proves it’s possible.

While the protagonists’ methods might seem “old school” (using physical cards instead of bug trackers), improvements arise once everyone communicates.

You might think better interfaces, like SLAs or incident backlogs, improve collaboration. However, tearing down barriers and fostering empathy and shared purpose create a unified team.

DevOps Team Structure: One Product, One Team

Ideally, a product has one team: the product team.

I experienced a team lacking a shared goal. Development prioritized pushing changes; validation aimed to prevent defects. Separate managers and evaluations created a divide.

Result? Development and validation played “defect ping-pong.” Development focused on finding test flaws instead of fixing bugs.

The release cycle suffered from excessive overhead due to reports and counter-reports. Both teams should have shared a goal and worked together. Siloed mentalities hindered progress.

Fighting Waste: A Collective Effort

Lean production, inspiring the Agile Manifesto (which in turn introduced us to DevOps), emphasizes waste reduction—anything not directly contributing to the client’s needs. Work-in-progress pileups and unnecessary process steps are wasteful.

Waste is best identified from a high level. Within a team, procedures might seem essential, but from a product perspective, they might be useless.

To identify waste, collaborate and analyze the product lifecycle from the client’s viewpoint. Is a feature necessary? If not, skip it. Are processes lean? Scrutinize those crossing team boundaries.

For optimal product development, invite an outsider for a fresh perspective. They can ask insightful questions and identify improvement areas.

DevOps Principles: Embracing CALMS

CALMS effectively summarizes DevOps practice:

• Culture
• Automation
• Lean
• Measurement
• Sharing

It’s a sandwich. Technical aspects (Automation, Lean, Measurement) are enveloped by soft skills (Culture, Sharing). Communication underpins culture, allowing us to share values and reach a consensus.

Sharing, even something simple like food, is communicative. It conveys care and goes beyond verbal communication.

Sharing ideas and tools necessitates communication: How? Where? Who benefits?

Focusing solely on technical aspects misses the point. An unused automated deployment script, while potentially saving its creator time, signifies wasted potential. Imagine the time saved if shared!

DevOps Connects Business and Development

DevOps is said to bridge operations and development. This is partially true. It connects all units, offering business and clients near real-time visibility into development.

This shorter feedback loop benefits everyone. Increased work visibility allows developers to observe how clients use their code. Traditional deployment delays feedback for months. Continuous deployment enables immediate problem response. Developers, operations, business, and clients can collaborate in real-time to adapt the application.

Tools First? Reconsider

Tools are essential, but they can’t replace good communication and empathy. I witnessed a product where one team owned the build process, while another owned the code.

Build system issues were rampant. Developers struggled with a customized, poorly documented system. Despite wanting improvement, communication between teams was nonexistent. Both sides introduced new tools without consultation, widening the gap instead of closing it.

For a successful DevOps transformation, prioritize communication. Don’t assume solutions; brainstorm openly. You might discover, for example, that tooling needs improvement. Only then consider adjustments or new tools to avoid exacerbating the problem.

DevOps Shortcut: Enhanced Communication

Earlier, I mentioned the “Docker vs. Kubernetes” dilemma. Now, you understand this question is best addressed after DevOps-minded preparation.

If your product team understands DevOps benefits, they can collaborate with the client to set expectations. Engineers can then determine the development and deployment model, followed by tool selection.

Documented requirements simplify technology choices.

I’m an advocate for powerful DevOps automation tools. However, our work revolves around people. Let’s prioritize improving this aspect of DevOps instead of chasing another certification.