Felipe Castro and I have discussed OKRs for hours over the phone. In early 2016, we first met in person at my childhood home in San Anselmo, California. Given that Felipe is from Brazil and my parents lived in Brazil back when they were in the Peace Corps, we all got together and shared a good meal and some stories. While I won’t cover the stories here, I will share highlights from my recent discussions with Felipe on the intersection of Agile and OKRs.

Ben: I keep hearing about your OKRs presentation at Agile2016 in Atlanta. Why do you think the level of interest is so high?

Felipe: My presentation looked at the intersection of OKRs and Agile, and it was way overbooked. The initial interest was high. A large number of companies adopt Agile and Lean Startup, and they face a conflict around goal setting. There is no way to use Agile with the Balanced Scorecard or any form of static planning since the whole point is to iterate. The transformative potential of using Agile with Value-based OKRs really resonated with the audience.

Agile is a project management framework, focused on the incremental delivery of a set of tasks (user stories, epics or features) and not actual value (business results). Standalone Agile is not iterative. It lacks ceremonies for tracking results. Iterating requires measurement and adaptation as in the Build-Measure-Learn cycle from Lean Startup.

When properly used, OKR can be the missing link between Agile and Lean, bridging the gap between Product and Engineering. Explaining that OKRs should be Value-based, measuring the delivery of value to the organization or the customer, can transform the company. On the other hand, when you connect Agile with Activity-based (milestone) Key Results, it creates friction since Agile teams already have roadmaps. So why do they need OKRs?

Every time I meet someone that does not understand how to connect OKR and Agile, it’s because they are focusing on activities instead of value.

Some authors refer to output versus outcomes. I prefer the term “value.” You can have an outcome that delivers no value. For example, “making a product faster” is an outcome. However, if the customers feel it was already fast enough, this result offers no value.

Ben: How have your clients successfully integrated Agile with OKRs?

Felipe: All my clients do this at different levels. The most mature ones use OKRs as an alternative to the Product Roadmap.
Instead of having a roadmap listing a series of milestones that the team has to deliver over the next quarter, they use Value-based OKRs with the expected results. It doesn’t matter what features we will end up with, what matters is that we get the value.
This approach gives the team the autonomy to develop features or kill them and iterate more frequently. A tech company with over 1,000 employees has done just this with nine product lines, and they’ve replaced the roadmap with OKRs since January 2016. They will likely NOT go back to a product roadmap.

Regarding OKR Check-ins, the idea is not to add more meetings but to make existing Agile ceremonies more effective by focusing on value instead of activities. Say that’s great that we shipped product X, but now ask “did the metric improve?”  Are we doing an A/B test? Get the conversations about data and experiments, and then iterate.

Ben: Can you describe a story from one of your clients that illustrates the value of combining OKRs with Agile?

Felipe: “Metric literacy” is a key benefit of adopting Value-based OKRs since the engineers begin to understand the business metrics.

I often find that engineers do NOT know the fundamental indicators of the organization. Since the company only talks to them about features, they have never been exposed to the metrics. Adopting Value-based OKRs changes the conversation. Engineers are problem solvers, so if instead of presenting them with your solution, you give them the autonomy to focus on the problem they figure out how to deliver the desired value.

Recently one of my clients told me that after they had created one Key Result to reduce open issues in JIRA, the engineers started studying the issues thoroughly. They started to understand what the customers were complaining about – something they had never done before. The same engineers who seemed not to care changed their behavior in a matter of days when given the autonomy to solve a different problem.

Stay tuned for a webinar featuring highlights from Felipe’s actual Agile2016 presentation! To learn more about Felipe, check Lean Performance