Promoting a Service Ownership Culture
In his previous blog, The DevOps Origin Story, xMatters Director of Cloud Operations Adam Serediuk discussed the uncertain origin story of DevOps and how the culture has evolved over the years. In the collaborative DevOps culture, teams share work and often inherit work from others. In the second and final installment of his blog series, Adam contends that service ownership is the evolution of Agile methodology.
It’s difficult for someone to get excited about taking on ownership when someone else did the initial work - they know they’re about to inherit someone else’s (unknown) technical debt, which they’ll likely never have the time to address. This creates animosity and a victim mentality, as opposed to being involved and invested in the ownership change.
You also need to be honest about why you want individual teams to have increased responsibility, as it doesn’t come for free. The day to day realities of maintaining and supporting services will use some of that team’s time, and you’re asking people to take on more responsibility – but what’s their reward?
The reward for this additional ownership is the time to produce and run your service, measured against its SLOs. I view service ownership as a Product Owner initiative. Individual services, which support products, have customer deliverables. Their uptime, performance, security, and more are important product features that are customer requirements. It’s nobody else’s responsibility to deliver those requirements and features.
As a product initiative, this gives teams license and freedom to meet these requirements, and lets you define and control where you invest your time. If SLOs are being met, the team can focus on new features. If they’re not being met, the team needs to focus on meeting the existing requirements.
This change should bring joy. Joy because you can deploy and troubleshoot faster, and because these requirements are first-class citizens in the product. Less stress, faster results, fewer failures, and more restful nights. These are things that make everyone happy.
Opportunity knocks
During a cloud migration or any other major architectural change, there’s an opportunity to do things differently. At xMatters we let teams own their service and the responsibility for their development and deployment. Any new technical debt or faults are theirs and theirs alone. By scheduling these activities in multiple sprints, these teams had the time and resources to learn new architectures, address previous technical debt that would not scale in a cloud environment, and had skin in the game with their new responsibilities.
This has had two profound effects. First, each team responsible for setting up a service understands its operation, deployment, runtime, and monitoring. Second, there’s already an awareness of the scale and complexity of the system.
Modern architectures are composed of many services and are greater than the sum of their parts. With service ownership there are fewer individuals who understand the entirety of the system, because no one person or team is responsible for its operation. This can have an unwanted side effect of finger pointing (“my service is fine”) and lengthier troubleshooting timelines. However, this is a scalable system; individual unicorns who understand every aspect and nuance of a system cannot scale. This may work in smaller environments but it’s not realistic as an organization grows.
What problem are you trying to solve?
Growing companies struggle with scaling their development activities with production operations. An increasing number of services is creating a vast ecosystem of services in production that becomes difficult for one team (or department) to support. This has reintroduced some common issues that DevOps had set to resolve, and there are too many half-implemented DevOps cultures where the DevOps representative is responsible for deployment/monitoring/etc. Service ownership sets out to correct that.
I’ve found the following to be some best practices to introduce and promote service ownership, along with some lessons learned:
- Be honest about why you want service ownership and the investment required – you know you best.
- If you have the opportunity to establish ownership as part of a major change, whether organizational or technical, seize it. It’s better to have everyone be part of the change than to have the change be something happening to them.
- Involve the teams in the decision process and listen carefully to their feedback, as they’re going to be living the day-to-day reality.
Make teams accountable for their service:
- Honor their authority and ability to meet their service objectives.
- Continually measure and report on the state of service objectives and address any misses.
- Ensure only the team responsible is alerted for their service’s health checks; it’s nobody else’s responsibility that their service works.
If that service fails, for whatever reason, that’s well… a failure. Call them bugs, call them Sev-1 issues or whatever your organization does, but if it was a customer-impacting failure, it needs resolution and prevention. The priority of that resolution depends entirely on whether an agreement (SLO) was not met. An SLO violation receives the highest priority.
Collaboration remains at the core
Like the technology itself, the way we build it, the processes and its cultures are evolving. However, one thing is clear: Development and Operations must collaborate. As these teams grow, and complexity increases, service ownership is the evolution of Agile methodology.