Felipe Castro and I have discussed OKRs for hours over the phone. In early 2016, we first met in person at my childhoold home in San Anselmo, Califorrnia. 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 share the stories in this post, I'm pleased to 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 was so high?
Felipe: My presentation looked at the intersection of OKRs and Agile, and it was way overbooked. The initial interest was high because as a large number of companies adopt Agile and Lean Startup, they face a conflict with the way they traditionally set goals. There is no way to use Agile with the Balanced Scorecard or any form of static planning since the whole point is to iterate.
But what resonated was the transformative potential of using Agile with Value-based OKRs.
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 as 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. When you explain that OKRs should be Value-based, measuring the delivery of value to the organization or the customer, this conversation 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, but I prefer the term value since you can have an outcome that delivers no value. For example, making the product faster is an outcome, but if the customers feel it was already fast enough, this result would have 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 the 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 (no need to mention their name!) 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.
What I see over and over again is that the 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.
When you adopt Value-based OKRs, the conversation changes. Engineers are problem solvers, so if instead of presenting them with your solution, you give them the autonomy to focus on the problem they will 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 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.
Look for an upcoming webinar that will feature highight from Felipe's actual Agile2016 presentation! To learn more about Felipe, check Lean Performance
