How to involve the whole team in setting quarterly objectives (OKRs)?

Question

Context

I'm a scrum master in a small (15 FTEs) organization that's about one year into a slow agile transformation. So far the shift towards agile has been limited to the Development team, but the other teams are also wanting to move in that direction.

Recently, the leadership (4 people) has expressed an opening to integrate the whole team in setting objectives for the quarter (we use OKRs) in order to increase visibility on goals and increase team engagement and buy-in.

The issue

We did a test, which went relatively well, but the time people had to come up with objectives was minimal, and the team had neither sufficient access to most of the important information, nor enough time to really understand that information.

The leadership is aware of the limitations of this exercise, but they also want to keep going and improve, which is encouraging.

Proposed solution

I'm thinking of planning a one-day off-site for the whole team about a month before the start of the next quarter, where we would

• Review previous OKR results and do a retrospective to learn from what we did
• Set new OKRs together
• Have other important meta conversations (e.g. values, psychological safety, etc.)
• Do some informal team building

The OKRs would then be used to fuel the roadmapping process and spur initiatives. The hope is that the team would have a shared understanding of what needs doing and feel more engaged.

Question

What approaches do you recommend to make this process engaging and fruitful?

Workshop ideas would be useful, but I especially need help on how to give the team access to the information they need to set meaningful objectives without asking them to read for a whole week. One solution that was proposed would be for each team to write an input paper on their context and share it with others one week before the retreat.

Answer 1

First of all: great idea with the workshop! And thumbs up for OKRs!
Ad your question: I've made good experiences with having the people who have the needed information plus your team in one room for some time. If your board supports you, this should be possible for at least half a day. So your team and the special department can develop the base for the OKRs together. This won't waste time with reading papers over papers, will prevent misinformation and will give you buy-in from everyone involved.

Answer 2

Great question, and congrats on the transition to a more agile-way of delivering value. I'm going to assume your organization is using the Scrum framework if you're a Scrum Master, so my answer is scoped with that in mind.

Creating and promoting transparency is a key function of the Scrum Master role, and it's encouraging to see you feel strongly about this. I've been in a similar situation before, and a great start is to work with your management team to prioritize team OKRs. This is important as it helps the team focus on providing detailed plans re: the most valuable OKR, with lesser detail given to less-prioritized OKRs. Continue to work with management to make sure OKR value priority is up-to-date.

This will also help with information transfer so the team doesn't have to ingest and deliver on the details for everything all at once. Just the prioritized OKR first. Other OKR details can be refined as empirical evidence, knowledge and requirements emerge.

Once a prioritized OKR is accomplished or "done", the team should have an understanding/head start on incrementally building towards the next, providing details along the way as to how they plan on accomplishing the goal. This in turn can be delivered to management/visualized for transparency's sake.

I'd also use the Scrum events to promote and coach the team towards their OKRs. Coach the team on discussing how their daily work progresses towards OKRs during the Daily Scrum (where applicable). Are they on track? Blocked? Off track? That's helpful information to know as a Scrum Master.

Review how the increment moves the team closer to their OKRs at Sprint Review.

Help bake OKRs into refined work items and help the team find the balance in selected work during Sprint Planning.

Have the team inspect themselves and their progress towards their OKRs during their Sprint Retrospective. Refining/discussing their definition of done to help meet an OKR would make sense here.

It could also help to infuse OKRs into each sprint goal/team work agreements.

With all this in mind, your team can incrementally and iteratively inspect and adapt progress towards those OKRs without having to ingest and act upon them all at once. But the crux of this revolves around prioritizing OKRs first. This may also involve coaching your management team on the value of prioritization to maximize empirical process control theory and Scrum Values (thinking of Focus, mainly). Then, if for some reason an OKR shifts in priority, the team can adapt their plans to meet new priorities without wasted effort.