Here’s a controversial opinion: if your organization struggles with being agile, it’ll struggle with DevOps. DevOps cannot succeed where Agile has failed.

Why? Here’s my hypothesis:

  1. Agile, DevOps, Lean are all manifestations of the same principles. Collaborate better, reduce waste, focus on customer value, continually improve.

  2. These fundamental principles are either part of the culture already, or they’re not. As a result, for organizations that already grok agility, DevOps feels like a natural next step. For those that don’t, it feels like a challenge, a threat to existing systems, practices, and hierarchies.

  3. Organizations that try to apply these principles superficially (“doing Agile”) without changing the underlying culture (“Being agile”) tend to fail. We’ve heard this message in many forms now:

    • “DevOps is a culture, not a role”
    • “Agile is a culture, not a process”
    • “Lean is a way of thinking”
    • “If you have a DevOps team, you’re doing it wrong”

It’s always interesting when people ask for some kind of proof to justify moving towards DevOps. Even now, as I re-read the Agile principles for the nth time, the truth in these ideas and their correlation to DevOps are almost self-evident. But as an exercise it’s useful to go back and show the similarities.

DevOps’ Three Ways

  • from Gene Kim

1. Systems Thinking

Idea: Focus on the performance of the entire value chain, instead of just a particular function or silo. “Value” being whatever satisfies our customer.

For instance, what use is it to optimize our dev cycle from 10 days to 8 days, if Operations is still deploying to Production only once a month? Our customers still have to wait that month to get value. Focus on how every part of our SDLC: BA, dev, QA, Ops (and yes, even organization structure and management decisions) play into our time to market.

Related Agile principles:

  • #1: to Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • #2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • #3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • #7: Working software is the primary measure of progress.

2. Amplify Feedback Loops

If our understanding of “value” improves, then how long does it take to embrace the consequent changes? How long before we even find out? How long before our response to that change can go out to Production? How many people need to “mobilize” to respond to that change?

Idea: Quick feedback loops allow us to adjust our ideas/actions/targets sooner. The more that people work together, the shorter our feedback loops get. Conversely, the more we silo them or enforce rigid hierarchies, the longer our feedback loops get. How can a team self-organize if they’re constantly running into organizational silos?

If we accept this, how big a stretch is it to get Dev and Ops working together daily?

How big is a stretch to co-locate with not just Ops, but BA, Sec, QA, and the customers as well?

Related Agile principles:

  • #4: Business people and developers must work together daily throughout the project.
  • #6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • #11: The best architectures, requirements, and designs emerge from self-organizing teams.

3. Culture of Continuous Experimentation and Learning

Again, at the risk of stating the self-evident: continuous learning and experimentation are how we stay ahead of the competition and “win” in the customer’s evaluation. We must understand what value is to the customer, and then learn how to provide it, and then how to do it faster and better than everyone else.

This is also why a great indicator of an agile organization is to see how they handle mistakes or failures (both of a system and human kind.) Learning prevention and recovery, without finding scapegoats, is critical.

Related Agile principles:

  • #5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • #8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • #9: Continuous attention to technical excellence and good design enhances agility.
  • #10: Simplicity–the art of maximizing the amount of work not done–is essential.
  • #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Summary

If you find yourself justifying DevOps to a company that isn’t Agile, you’ll need to start at a much higher level, to ensure the idea is adopted successfully.