How to level up in Scrum using Service Level Objectives!
Scrum Power-Ups — SRE: Service Level Objectives
The world is really rich and the possibilities are mostly endless. By having an open mind we can observe what others have already done and leverage that knowledge. So, we should take a look at some of the concepts proposed by other methods, frameworks, philosophies, and approaches. Let us think about how we can use them in our Scrum environments.
Onwards!
Site Reliability Engineering started within Google in approximately 2003. The publication “Site Reliability Engineering: How Google Runs Production Systems” went into print in 2016.
Amongst others, one of Site Reliability Engineering principles is ‘Service Level Objectives’ (SLO). In short, you can view them as a form of internal Service Level Agreement (SLA) on how your systems perform when it comes to reliability in a given period of time.
A simple example — your system does 10k transactions per month. You’ve agreed with your customer in the SLA that you guarantee 98% of that system’s reliability (successful transactions, let’s say logging in into the system, like a MMO game server). That means that you can “burn” 200 transactions per month without both sides calling in their best lawyers.
But hey, you want to be better than that and you want to have your system to be able to handle 99% reliability. This means that you agree that you can burn 100 transactions without any consequences. Just don’t forget to have a buffer between your SLA and SLO before hitting that magical note of SLA breach where the real fun begins. In the above-mentioned case, the buffer is what is between SLA and SLO so 100 transactions.
So what’s the deal? Well, Scrum may be a viable framework though it’s not an absolute nor you should think that way if you want to progress at a constantly changing world. At least unless you possess some superpowers, then I guess you can think whatever you want of yourself!
It is only reasonable to ponder using whatever has proven successful elsewhere and at least give it a try. Also, Scrum points to cross-functional teams which sounds similar to the DevOps approach to team composition.
Having that in mind — if you write the code and then you are the person who deploys that code and stays on-call then you may have a different perspective than a person who just finished his/her batch of work and hands it over to admins. “It’s not my worry anymore.” right?
If you are a developer that writes code and maintains it, then consider setting up an internal Service Level Objective. At least gauge your team to level up their craftsmanship with “mad skillz” in coding. If you can handle the development part of work, then you can be as good at operations work when given the opportunity.
Let me ask you one question — what’s the magic word that can give you anything you want? If your answer is “sudo” then you can do it.
Of course, the whole SRE discipline is more than just SLO’s, though if you are interested there are many publications out there that can get you hooked, including three books published by Google on the topic that are freely available online.
Keep in mind that it’s a different approach to work. Nonetheless — you can at least give it a try, maybe it will work for you?
