OKRs for a team of Scrum Masters & Coaches
Hello fellow Agileists!
My organization has a group of Scrum Masters & coaches and we've been tasked with making our own OKRs each quarter along with the other disciplines within the organization.
We're really struggling here. It's clear for say, a marketing team or engineering team to build out some OKRs with very specific measureable results that relate to the orgs overarching OKRs, but for us, not so easy..
I'm just wondering if anyone here has set any OKRs for themselves or their "Agile Group" and could help me with some examples? I think once we've got a few examples we'll get on the right track. But we're hitting a brick wall here. We've all been a part of OKR planning sessions for dozens of teams in the past, but none really for ourselves.
I'm thinking of something like "Empower teams to reach Agile maturity" or "Empower teams to help themselves become more effective" with KRs focussed around having the team more aware of things like velocity, team health, etc. But this even feels a little.. lackluster maybe?
Really hoping to hear some of your experiences!
Thanks everyone.
My organization has a group of Scrum Masters & coaches and we've been tasked with making our own OKRs each quarter along with the other disciplines within the organization.
We're really struggling here.
Why did Scrum Masters and coaches accept such a task? It’s not just the teams who are struggling, agile change agents are struggling to coach it.
The “tasking” of teams and coaches by executives is the tail wagging the dog. 3 months is a long inspect and adapt cycle, and validated learning is unlikely to be optimized.
Why aren’t Sprint Goals, and the empirical improvements Scrum Teams make to product and process each and every Sprint, being leveraged to support more evidence based management?
How can you measure "Empower teams to reach Agile maturity"?
Totally agree with @Ian Mitchell here.
And to maybe help you out here... why not have 3 objectives here:
1- (improve) Team happyness
2- Delivering working software increment at end of the sprint
3- Achieving sprint goal at end of the sprint
These can be measured for outcome every sprint, and you can report on them every 3 months
If I had a team of anything, I would want some measurement showcasing their success. That said, why do you have a team of Scrum Masters & Coaches? Is it because one exists that the OKRs are even considered?
If keeping the team make sense, how would you consider the team useful and what makes the team successful? Is it number of training/workshops per month or something along those lines?
And to maybe help you out here... why not have 3 objectives here:
1- (improve) Team happyness
2- Delivering working software increment at end of the sprint
3- Achieving sprint goal at end of the sprint
When the team is not happy of any valid reason and the scrum master is doing what he can and the team is still not happy, does the scrum master failed? Same with #3, the scrum master are there to influence and help but not the main factor why the team did not achieve the goal or if they are not happy.
Happy to know your inputs on this one.
I was referring to the objectives as team objectives, not SM objectives. In the end, it is the team "performance" which reflects the servant leadership performance. It is not about failing (or not), it is about improving.
It is not about reaching the sprint goal per se, it is about working / improving towards it if you dont (as a team), it is not about "being happy" per se, but improving team happiness as a team.
If team happyness is bad, like 3 on a scale from 1 - 10, and after 3 months it is 5, the team might still feel "unhappy", but surely you made progress there. Just as an example.
Any kind of metrics or processes which are used to indicate failure, will infere a failure-mindset. If you want failure, or indications of it, you can find it (and will!). Any metrics to indicate growth and improvement, will create a growth-mindset, and if you want want indications of growrth and improvements, you can and will find it
When the team is not happy of any valid reason and the scrum master is doing what he can and the team is still not happy, does the scrum master failed?
Team 'not happy' is too generic. What is the reason for the team's unhappiness ? is this reason transparent enough ? was there enough opportunities for inspect and adapt for team to act on ? it is something team cannot solve themselves ? ( assuming reason is transparent enough)
I just mean that happiness index is just a measurement to act upon. If its low then must be inspected and improved. It just adds the transparency which gives opportunity to act upon.
I like where Xander Ladage going
How about
improve team agility, improve comfortability, ( if somone becoming more comfortable with the team it mean, more collaboration and more trust and therefore improve comfortability