Outcome-oriented SAFe objectives
Can you combine OKRs and SAFe on the team level??
I've come across a number of companies considering if it is possible to apply Objectives and Key Results (OKRs) on team level while doing SAFe. The dilemma and trick is to harmonise the use of OKRs and SAFe quarterly cycles on team level. Taken separately, SAFe and OKRs have similar, but clearly distinct ways of stating team objectives.??
I'm sure there are people out there saying that this should not be done. SAFe does not currently recommend including the Objectives and Key Results (OKRs) on team level. Still OKRs have brough a lot of good in terms of clarity of strategy and focus on outcomes. Many companies are looking to roll out OKRs on all the way to team level, just as most OKR experts suggest.?
My take is that OKRs on team level and the SAFe overall program increment cycle can be combined. This will lead to a few central SAFe concepts getting redefined. I however think this would be for the good.???
The SAFe increment cycle could be more outcome-oriented and punchy with the conscious application of OKRs and outcome-thinking. The parts of this article are 1) small intro with the "why" 2) Outcome-oriented OKRs as substitute for SAFe PI objectives 3) Connecting with the larger organisation and 4) Measurement as making progress.???
This one is slightly more "process-nerdy" as an article. Hope you enjoy still.?
Feature factory or outcome factory??
Disciplined use of Objectives and Key Results can lead to focus on outcome. The first and foremost challenge applying OKRs gives you is painting a vivid and measurable picture of the near future. You must be specific enough with the key results to define them precisely enough. The key results should be so specific you can measure the change and track progress. That specificity and measurability is very much the heart of outcome orientation too.?
I've run a feature factory way back in history. John Cutler has laid out the essence of what a feature factory looks in the classic blog 12 signs you're working in a feature factory. The main attributes of the factory are 1) No measurement, 2) Success theater, 3) Rapid shuffling of teams and projects (aka Team Tetris), and 4) No connection to core customer, product or business metrics. The feature backlog is the raw material. The development organisation is the factory. You run the factory to maximize the feature throughput. It is very easy to get stuck running a volume-oriented operation that just cranks out "stuff".???
I've written that the development loop must connect the organisation to real outcomes in Measure and check outcomes together. That connection to outcomes shifts us from output to outcome. The work must start with customer and product outcomes. The work is done only when we've either reached the outcome or learned why getting there is impossible.??
Let's aim for an outcome factory.?
Business objectives or OKRs?
The SAFe model uses the concept of business objectives (also known as PI Objectives) to articulate and communicate team goals for an increment/quarter. The business objectives are very similar statements to OKRs and they should "Communicate and highlight each team’s contribution to business value". The team objectives should be focused and written in a SMART fashion.??
This all sounds like all should be fine. My experience is somewhat contrary. My guess is that the term "business value contribution" is too vague for most teams to apply in practise. I often see just restatement of feature titles and deliverables on the actual objectives written in the places I visit. That is, we are still quite output-centric in applying the SAFe?objective statements. The notion of articulating the clear contribution to business value is just beyond thinking models of most teams – and sadly many product owners too.??
Objectives and Key Results, while not easy, do a better job at helping everyone spell out the change to be created. The thinking model is more focused. There's just much more knowledge out there now on how to write good Objectives and Key Results.??
If you want to foster outcome-orientation in the SAFe cycle, I would recommend giving OKRs a try as team objectives.??
Finally, I'll address two ripple effects that stem from the change of team objectives to OKRs.?
Stakeholder/business owner handshake should shine light on the "why"?
?The SAFe model has a novel way to include business owners and key stakeholders into the planning and followup process. SAFe has included an explicit "handshake" step where the business owners give a numeric score for each objective. The scale is 1 to 10. 10 is the maximum business value.??
This handshake is a really simple way to enforce discussion between the team and the business owners. The thinking is that by giving the number the business owners then have skin in the game. They are forced to understand what the team aims for. The business owners are forced to articulate, as number, the contribution that the team makes.??
I would change the handshake to a qualitative one. The business owner should articulate the connection, as they see it, between the team OKRs and the strategic "why". The business owners should understand the OKRs. Then they should explain how they see the expected results (as expressed by the OKRs) moving the business forward. The business owners thus give further business and context guidance. They state the "why" of the OKRs. We can then record that for inspect & adapt in the future.?
Predictability measurement as making progress?
Finally, there will be a change on how progress is measured. The SAFe model tracks delivery predictability by looking at variance between expected and actual business value delivered. At the end of the increment/quarter, the teams evaluate the business value delivered of each SAFe?objective. The scale of actual business value delivered of an objective at the end of increment is 1-10.??
In the original SAFe model, the business value is evaluated in a discussion. The evaluation is usually subjective as most team objective statements are not really outcomes that could be measured. Many, if not most, objectives are about deliverables and features. No wonder customer or product outcome sometimes gets forgotten. ?
Running team goals with OKRs would lend directly to measurement and evaluation of reaching expected outcomes. You simply run a standard OKR cycle debrief and check which key results have been met. The OKR has two schools of thought whether or not there should be stretch in the objectives. Either way, you get clear results.??
SAFe however does hold you accountable for consistency of delivery predictability.??
The most appealing facet of SAFe for some organisations is the notion of predictability. SAFe aims for close to 100% predictability as measured by plan vs actual comparison. The idea is that you can get to a repeatable process which all the time yields measured business outcomes. I think the lack of rigor in terms of outcome definition is where things slip so easily to a feature factory mode.??
I would change the notion of predictability. I would have a business owner rate strategic progress on scale –1 to 3. The scale is: -1 = "we are losing ground", 0 = "I see no progress", 1 = "some progress seen", 2 = "good strategic progress", 3 = "we're clearly winning new business". I know this deliberately vague. However, this directs the discussion to bridge the gap between outcomes and strategic impact. But most of all, the scale gives a number that you can view as a trend. You goal then is to get as close to 3 consistently.??
?There is no longer the notion of 100% predictable flow of features. Aiming for outcomes is more variable as OKRs have taught us. However, there can be steady strategic process on the higher level.??
Get to outcomes consistently. Make sure you are consistently working on outcomes that have strategic impact. Small tweak but a big step away from output-orientation.??
References???
---?
?
PS: More of outcome-oriented thinking at nitor.com/productleadership??.