GUEST POST: OKR for Agile Teams
I’ve really excited to announce this guest post by Felipe Castro. One of the most common questions I get is, “how do Agile and OKRs fit together?” Felipe is an Agile coach AND an OKRs proponent, and thus the perfect person to share this knowledge!
OKR for Agile Teams
Agile was created as an alternative to waterfall for managing software development projects. As such, it is focused on managing deliverables (user stories or features) and not actual value (business results).
In fact, there is not a single ceremony in Agile for tracking results.
Several Agile teams are stuck in the “ship it and forget it” mindset: after we have shipped the feature, forget about it!
The Agile Manifesto itself refers to valuable software and working software interchangeably:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (first principle)
Working software is the primary measure of progress. (seventh principle)
Implicit in the Manifesto is the assumption that all working software is valuable – which is obviously wrong. Some projects will deliver value and others won’t. Some features will be adopted by users while others will fail.
Much has been written about the need to focus on “building the right product” versus “building the product right”, but, as Marty Cagan wrote on the preface to Radical Focus: “Teams today are all too often feature factories, with little regard for whether or not the features actually solve the underlying business problems.”
An Agile team exists to deliver value. But the value of a feature can only be measured after it is shipped. User stories are just experiments and have to be treated as such.
OKRs to the rescue
When used properly, OKR can complement Agile and help it to evolve. But what would be a proper use of OKR?
The proper way to use OKR is to track actual value and not project deliverables. As Christina tweeted:
Success is not checking a box.
Success is having an impact.
If you complete all tasks and nothing ever gets better, that’s not success.
Quoting Lean Performance’s Beginner’s Guide to OKR:
“There are two basic types of Key Results:
- Milestone Key Results: Measure the completion of tasks and activities or the delivery of project milestones or deliverables;
- Value-based Key Results: Measure actual results and the successful delivery of value (or a value component) to the organization. Value-based Key Results measure the outcomes of successful activities.
Examples of Milestone Key Results are:
- Release beta version of the product;
- Launch a monetization tab;
- Create a new training program;
- Develop a new lead generation campaign.
Milestone Key Results usually start with verbs like: launch, create, develop, deliver, build, make, implement, define, release, test, prepare and plan.
The Key Results [from the Guide’s previous OKR example] are all value-based:
- Increase average weekly visits to 3.3 per active user;
- Increase non paid (organic) traffic to 80%;
- Reach a NPS (Net Promoter Score) of 52%;
- Reduce revenue churn to 1%;
- Increase engagement (users that complete a full profile) to 75%.
Value-based Key Results are usually built around a specific metric that represents a value lever for the organization.
The typical structure of a Value-based Key Result is:
Increase/Reduce ABC-metric from X to Y ”
If you are using Milestone Key Results, you are using OKR as a project management tool and, as such, not fully utilizing OKR’s potential.
OKRs define success criteria for an organization – OKRs should define whether a person or a team achieved success. But in order to do that, OKRs cannot be based on milestones (or effort) for three main reasons:
1) We want a results-focused culture, not one focused on tasks
We do not want a culture in which a team can focus on delivering the product backlog regardless of the business results. We want a culture that is focused on delivering value for the company and for the customers.
2) If you did all your tasks and nothing improved, that is not success.
Success is improving something: customers are more satisfied, sales are higher, costs have been reduced. As per Christina’s tweet, if you did all your tasks but they got you nowhere, that is not success.
So in spite of the “Project Management Triangle”, the fact is that delivering a project on time, on scope and on budget is not enough. The project must be delivered successfully – meaning that the objectives that motivated the project in the first place have to be reached.
3) Your action plan (or product backlog) is just a series of hypotheses
The Lean Startup methodology taught us that an idea is just a non-validated hypothesis. In the same way, in the real world we don’t know if our action plan will actually improve our results or add value to the organization. The action plan is just a list of hypotheses, so you should not attach your OKRs to non-validated bets.
From Agile Project Management to Goal Agility
OKR can complement Agile and Lean in 5 dimensions:
- Transitioning from features to value;
- Enabling autonomous, self-organizing teams;
- Adopting value-based ceremonies;
- Enabling Agile adoption by replacing predictability with results;
- Incentivizing leaner approaches and smaller batches.
1) Transitioning from features to value
As Cagan wrote on how to solve the “feature factory” mindset:
“When used properly, [OKRs] help to reframe this situation from output (features on roadmaps) to outcome (business results).”
Cagan also recommended that companies used OKR as an alternative to roadmaps, abandoning the traditional focus on a long list of future features for a focus on adding value – regardless of which features will be shipped.
I’ve had the opportunity of facilitating this transition for Locaweb, the leader in professional hosting services in Brazil. After a trial period, Locaweb’s 9 different product teams abandoned product roadmaps in the beginning of 2016 and are now completely focused on delivering their OKRs.
2) Enabling autonomous, self-organizing teams
Using OKR as an alternative to roadmaps enables team autonomy by changing what is expected from the teams. The role of the team changes:
From: “delivering the features the stakeholders want”;
To: “achieving the OKRs agreed with the stakeholders”.
The eleventh principle of the Agile Manifesto states:
The best architectures, requirements, and designs emerge from self-organizing teams.
But self-organizing teams need clear direction. In order to have a high-alignment, high-autonomy company, formed by self-organizing teams, you have to set a “True North” for the organization. A set of OKRs for each team will do just that.
3) Adopting value-based ceremonies
As I’ve mentioned in the beginning of the post, Agile lacks ceremonies for tracking results. By adopting OKR, Agile teams can change this scenario. The idea is not to add more meetings, but in fact to reduce managerial overhead by making them more effective.
I am trying not to be too prescriptive here, so please consider this as general guidelines that should be adapted to your unique context. Even if that means adding more ceremonies.
The OKRs should be used to decide which features to work on. If a feature does not contribute to the team’s OKRs, it should not be a priority – unless it is a commitment to another team, and was aligned as such.
Teams using Scrum should strive for setting Sprint Goals that contribute to the teams’ OKRs. One of the options is to use an adaptation of the Hypothesis-Driven Development model:
We believe <this capability>
Will contribute to <this Objective>
We will know we have succeeded when <we see an improvement in those Key Results>
Standups should start by tracking OKR progress, in order to connect the team with the achieved results. This daily OKR check-in should be very quick. The more frequent your check-ins, the less time they will take. This is even more important if you are delivering continuously and not in batches (or a release train), since the measurement cycles will have to be shorter.
Following The Radical Focus model, demos could be expanded to other teams, including sales and marketing (the “Friday wins”). Again, you don’t need to have an “OKR Demo” and a Review.
There is a debate on whether OKR progress should be tracked during the Planning or the Review (in an adaptation of the Radical Focus’ “Monday Commitments”). This model is still evolving.
Just remember that it can take a few days or more after shipping a story for it to affect the OKRs. If you are doing the OKR check-in during the Review, it will mean that you will be demoing the stories of your last iteration and tracking the results of the stories you have already shipped.
Retros should also include a discussion on how to improve the OKR process: Are we using the right metrics/Key Results? Are we being too conservative/aggressive with our OKRs? Can we improve our measurement infrastructure? What have we learned that could be improved for the next OKR iteration?
Teams are free to decide on the cadence of the OKR Retrospective. As an alternative, some companies are doing it in the begging of each OKR iteration.
4) Enabling Agile adoption by replacing predictability with results
One of the main barriers for Agile adoption and expansion is the fear of losing control and predictability. Agile transformation projects usually require a leap of faith by the stakeholders: “We will abandon the closed scope and detailed project schedule, but trust us, it will all work out for the best.”
OKR can help to overcome this fear by replacing the perceived predictability of a Gantt chart with a commitment to deliver pre-defined business results.
Instead of committing to deliver feature X by Y date, the team commits to iterate towards the agreed results.
5) Incentivizing leaner approaches and smaller batches
When used properly, OKR can force the team to adopt leaner approaches and smaller batches.
A common mistake made by teams that are starting with OKR is to consider that they have the whole OKR iteration (usually a quarter) to develop features that will impact the Key Results on the next iteration. That is not true.
A better approach is to use OKR to implement a value-based timebox: you have to deliver value (i.e. improve the Key Results) until the end of the iteration. This means that team will not be able to spend 2-3 months developing a new release.
They will have to ship an incremental improvement quickly (a MVP, pilot or experiment), in order to measure its impact on the OKRs and adjust accordingly. And since the stories are just experiments, we know that not all of them will work – forcing the team to adopt even leaner approaches.
We cannot allow a team to waste 1/4 of a year pursuing an non-validated hypothesis. Adopting value-based time-boxes can help to solve that.
I hope that this post helped you to understand how to use OKR in your Agile teams. As I have mentioned, this is an evolving model and I would love to connect and get your feedback and questions.
In order to know more about the practice of OKR, please join us at OKR Alliance, the community of OKR adopters.