How to Deliver Desired Business Outcomes with OKRs in Organizations that use Scaled Agile Framework

What I Learnt from Mark Richards at Enterprise Agile Russia 2019

I continue to share what I have learned at Enterprise Agile Russia 2019, the first of its kind conference in Russia dedicated to the implementation of Scaled Agile Framework. In the last blog post, I covered what stood out for me most from the session titled “Enabling Business Agility by Forming ARTs That Go Beyond Technology” by Mark Richards. Today, I’d like to give you a snapshot of another presentation delivered by Mark, “Improving Alignment, Focus, and Feedback with OKRs”. 

As the title suggests, the presentation was about Objectives and Key Results and how to apply OKRs in SAFe to define business strategy. If you have come across this methodology and are familiar with SAFe, perhaps, just as myself, you have wondered: “Given that SAFe gives detailed guidance on how to scale Agile, why is it that such a cool thing as OKRs isn’t formally there?” Mark illustrated how OKRs can be applied in SAFe to enable organizations to define an effective business strategy.

Mark started by citing John Doer who defined OKRs as a management methodology that helps ensure that the company focuses efforts on the same important issues throughout the organization. 

Mark illustrated how OKRs can be applied to all levels of SAFe to achieve complete alignment and transparency. 

At the Portfolio level, yearly organizational goals can be set in the OKRs format. Epics will be much clearer if Business Outcome Hypothesis to be expressed as Objective and Leading Indicators to be expressed as Key Results.

OKRs can also be defined for the Minimum Viable Product. The decision to pivot or persevere can rest on the Key Results which indicate whether the Objective has been reached.

Here, let me divert a little and say that, to great shame, in software development, not everyone approaches MVP as a Lean-Agile manner. I may not be doing a favor to some of my fellow developers, but even though they may be well aware of how to go about formulating hypothesis statement and developing an MVP, some use it to make a round plug fit into a square hole. Usually, it looks like this: “Let’s reduce the functionality to the bare minimum to fit in the budget – I guess that’s the Minimum part of the MVP :)) – so that the client gets the working version of a product and still has some cash left”. I’ve seen how the lack of cash and restricted budgets would drive the decisions for the MVP. I’m sure you agree that this is fundamentally wrong. In my opinion, formulating the hypothesis statement and metrics correctly are critical to MVP. And that seems to be the hardest part. Please do share how you feel this issue can be addressed in the context of a custom software development. 

Below, using the example of one of the MVPs we have been working on, I’ll illustrate how OKRs are used within the MVP. Whilst working on the MVP, the team was focusing on the objectives dictated by the hypothesis statement. This allowed us to deliver a version of a product, that cost the client 70% less of what they anticipated and is now being used to collect valuable user data and feedback. The following is the hypothesis statement we came up with:

Objective

To develop a mobile app to enable the city dwellers, passing through suburban and rural areas on the way to/from the city, to buy home-grown produce from small farms and village households, located along the way, that are looking to eliminate produce spoilage due to lack of buyers. 

At the moment there is no direct competition. The indirect competition is represented by agro wholesalers, farmers shops, and markets which have the following drawbacks:

• No mobile versions available
• No geo-location available
• Few participants
• No quality control of the products sold
• The seller has no control over the process
• The retailer sets the price
• A limited number of suppliers/sellers

 Thus, there is no single solution that is convenient for both sellers and tech-savvy consumers. Our solution will be a mobile solution which will enable city dwellers to order and buy natural products on their way to or out of the city, whilst providing an outlet for private farmers to sell their stock and ensuring they have complete control over the prices and sales process. 

The Product Objectives:

1. In 17 months, achieve a 4% market share in the Moscow region and revenue of RUB 1million a month. 
2. In 24 months, achieve a 1-3% market share of the Rusian market and revenue 5 million a month.

Key Results for the MVP: 

1. Support expansion of the user base of the app
2. Achieve the volume of 200 transactions a month 
3. Secure investment of (undisclosed information) Rubles to support further app development and marketing.

Admittedly, not all of the Key Results in the example above were expressed as they should have been. However, these gave the team a focus and informed the metrics to gauge whether the MVP has been successful. Moreover, the metrics have empowered the client to have a meaningful and down to the point conversation with the investors, which resulted in the next round of investments.

Getting back to what Mark presented, the OKRs at the Portfolio level can be applied at the ART level and define product strategy guiding the team through Continuous Delivery Pipeline. 

Lastly, Mark suggested that OKRs can be used to clarify and specify PI-objectives by drawing a parallel with SMART-objectives.  

PI Objectives, as shown above, are vague and do not allow for an assessment of how well the ART achieves the set objectives. OKRs address this issue. Objectives are set to be achieved within a certain period, therefore the are time-bound. Key Results are specific and measurable, otherwise, they won’t tell you how well you have done in achieving your Objectives. If you already set PI Objectives in the SMART-format, then you are good. If not, it’s worth trying expressing your PI Objectives with OKRs. The OKRs framework defines how Objectives are to be set and achieved and can be very useful in aligning not only PI Objectives but the entire backlog with the business value the organizational strategy is aiming to achieve.  

In conclusion, Mark emphasized that implementing Key Results may not be straight forward and not always necessary, but with the right application, it can be beneficial in the long-run.

I am pleased that there is a growing community of people interested in learning how to scale Lean-Agile practices and methods in organizations in Russia. Even more so, that here is a forum for people to share knowledge and experience on the topic. SAFe, business agility and process agility are all very big topics, and there is a need for more thought leaders and practitioners to help businesses adapt to the ever-evolving world.