Many companies use the OKR (Objectives and Key Results) framework to set the goals of agile teams, and the popularity of this approach is constantly growing. The benefits are indisputable, but what about the readiness of agile teams to start using OKR? Take a look at the 3 most common issues that agile teams can help you identify with OKR workshops:
1. Indifference to results and team focus
At the workshop for defining the Objectives and Key Results of the team, only the product owner with the scrum master tries and the rest of the team more or less passively watches. One possible reason is that your team is still used to passively taking on tasks and does not perceive its responsibility for the team’s results. That is why they do not yet own the team goals and do not yet see their role in defining them.
The solution here is rather long-term. One option is to lead the team to teamwork and prioritize team goals over individual ones. And that’s exactly the job for your scrum master/agile coach. Also, be sure to see if your reward system is based on individual goals instead of team goals. Try to involve OKR in agile team ceremonies so that they become a regular part of their lives and the team gets used to them.
2. We want to cover everything we do today in OKR
Some teams initially try to make as many OKRs as possible to see that the team is doing a lot of work. A possible reason is that your team is still focused on maximizing the work done instead of maximizing value for the customer. Many teams are therefore accustomed to initially starting a large number of activities at once and have a fragmented focus. Many open activities lead to their late delivery and often to non-transparent communication about the status of these activities. You can read more about this topic in the article https://lucidbaydigital.com/illusions-about-team-performance-and-fragmented-focus/.
The solution is again longer-term and consists in guiding product owners and teams to prioritize their work. Finish things rather than open new ones all the time. And the same applies to OKR. Define only one or 2 objectives for the team so that the team remembers them and OKR does not become just a task book, which you will always meet at the end of the quarter. And this then leads agile teams to the need to prioritize the focus on a few things.
3. Mistakes in team design
OKRs will also show you the flaws in the design of your agile teams. If teams have to deliver frequently and validate results with customers, it places much greater demands on teams being end-to-end. Suddenly, it will be more transparent, where the team lacks developers, or even other vital roles for a successful delivery. And so your team complains to OKR that they don’t make sense as defined. Try the technique 5 times why at such a moment. You may find that this is a team design issue and not an error in the definition of OKR.
If the problem is in the design of the team, think about whether you will hire the missing specialists, allocate them from elsewhere in the company, or whether someone can learn the missing skill in the team.
Finally
That’s why we liked OKR not only because of their business benefits, but also because of how transparently they show the state of agile teams. As elsewhere in an agile environment, OKRs don’t solve these problems on their own, but they can give you input on how to continue working with your team. And what is your experience with the informative value of OKRs about the state of agile teams?