In one corner, we have the Certified Scrum Master, known to his friends as the Extreme Programmer, and to his children as the LeSS SAFe DAD... Agile!
In the other corner, we have the Lean culture machine, who Continuously Delivers his Infrastructure as Code, he's named his left arm dev and his right arm ops... DevOps!
Although I've taken the hype to an extreme, the sound bites about Agile and DevOps can make them sound like very different ideas. Compounding the confusion, both concepts seem to defy definition, even as they have their own jargon and slogans. As the elder, Agile may be less vague, but it's certainly common for people to become frustrated with the myriad of definitions for DevOps. The lack of definition has lead to some common conflation.
Many people think Agile means Scrum and DevOps means Continuous Delivery. This oversimplification creates an unnecessary tension between Agile and DevOps so you may be surprised to find that they are best friends!
There's no denying the historical connection between DevOps and Agile. When Patrick DuBois and Andrew Clay Schafer tried to connect at the Agile 2008 Conference about "Agile Infrastructure", the connection to DevOps was born. Although Patrick later coined the term "DevOps", the Agile Conference continues to honor this connection with a DevOps track. But let's dive deeper than history and consider the practical connections between Agile and DevOps, when we look below the surface of Scrum and Continuous Delivery.
In some teams, Scrum is the difference between a constant, frustrating struggle and productive, rewarding team work. In others, Scrum replaces politics and overcommitment with objectivity and focus. It can also be embraced as if it were dogma. When the constraints of the business or the work itself demand something different, an agile team will leverage the underlying principles of Scrum, then inspect their practices, and adapt to become more effective. This is particularly important when Scrum is applied outside the context of software development.
In the DevOps community, those with Agile experience acknowledge that scrum is useful for tracking planned work. Some work in operations can be planned: releasing a big system change, moving between data centers, or performing system upgrades. But much of the work of operations is unplanned: performance spikes, system outages, and compromised security. These events demand immediate response. There's no time to wait for the items to be prioritized in a backlog or for the next sprint planning session. For this reason, many teams that have come to embrace DevOps thinking, look beyond Scrum to Kanban. This helps them track both kinds of work, and helps them understand the interplay between them. Or, they adopt a hybrid approach, often called Scrumban or Kanplan (kanban with a backlog).
At Atlassian, we have recognized that it helps to have two different roles for products we operate. Our Product Owners are good at understanding the features that users need but they are not so good at weighing those features against non-functional capabilities like performance, reliability, and security. So some SaaS products at Atlassian also have a Service Owner, responsible for prioritizing those non-functional capabilities. From time-to-time the two owners may have to do some "horse trading" but most of the time, these can be worked by independent teams. This might not be the only way to "amplify feedback" from operations, but it does help overcome an all-too-common bias in Product Owners about features. This "two owner" approach isn't the only path to DevOps. What's important is understanding these non-functional characteristics as "features" and being able to plan and prioritize them just like any functional user story.