How-to supercharge agile teams and process using OKRs

In this post, I'll give a brief intro to OKRs and how I think they can be a natural addition to agile software development teams' process and management practices.

What are OKRs?

OKRs are objectives and key results. OKR is a practical and straightforward framework for defining, tracking, and measuring your goals in both an aspirational and quantifiable way. The beauty of the approach is that it can apply to any context; having objectives is relevant for any case and is super simple.

Objectives: Ambitious qualitative goals that motivate the team and push the envelope. Objectives are the primary focus of a group and what they want to accomplish for a period.

Key Results (KRs): Measurable outcomes that clarify what it means to get the objective done. They are like metrics defined in the context of the objective. KRs tend to follow the attributes of SMART goals, but you think more ambitiously and push yourself to achieve aspirational targets.

You can define an OKR using the following simple template:

"We will achieve < OBJECTIVE > as measured by 1) < KR >, 2) < KR > and 3) < KR >"

If you want to learn more about OKRs and how they are related to KPIs, read this blog post.

What's missing in agile, and why are OKRs an excellent complement?

In summary, OKRs can make agile processes better in three ways:

• Setting an objective for the teams
• Creating autonomous teams
• Defining outcomes for features, and stories

Agile processes are often good at helping teams get a defined set of work items done in an organized way. They help bring clarity and visibility to work in progress, and they help optimize the throughput and identify the bottlenecks.

What agile frameworks are missing is a method for helping teams prioritize their backlog and deciding what to work on next. The method that the management team uses to answer that question is often a fuzzy black box, and product owners and scrum masters usually spend a lot of their time debating the answer to that question. It can also result in undesired political and opinionated debates, which can impact the team dynamics negatively. Furthermore, not having a higher-level purpose can often result in spreading the teams too thin and moving in many different directions that won't yield a great outcome.

Clear mission

The OKR framework helps fill in the gap and makes the process of mission/goal setting more structured and ideally consistent between the groups so that they all contribute to the same vision and pull in the same direction. Besides, it results in focusing on doing fewer things better.

For instance, here is an objective we defined for our DevOps team for a quarter:

We will achieve a higher operational availability and lower operational costs.

If you look back at the template earlier in the post, the above statement is missing the KRs.

At this stage, leadership works collaboratively with the team to define the objective and gives it motivational direction but allows it to determine how to achieve the objective and, often, come up with how the goals can be measured (i.e., the KRs), which brings me to my second point.

Autonomy

If the teams help with defining the mission and are given the opportunity to decide how to measure and achieve a goal, they take ownership of the problem, which often results in better outcomes. That's why the framework suggests a collaborative approach for deciding on the KRs. In the above examples, our DevOps team worked collaboratively with the leadership team to complete their OKRs template by adding the following KRs.

We will achieve a higher operational availability and lower operational costs as measured by:

• Zero DevOps owned services in Rackspace (Move everything to AWS)
• XX% reduction in AWS operational cost
• Zero single points of failure

Now think about it... If a capable team and leadership align on OKRs like the above, there is no need for the leadership team to get involved in defining user stories and prioritization of what and how. They can check in frequently (as suggested by the framework) to see where the team is with their KRs. We've mapped this check-in to our sprint pre-planning meeting to align OKRs with our existing agile process and avoid adding more meetings to our calendars.

In the pre-planning meetings, the leadership team reviews how the teams are making progress on the OKRs and what the next set of priorities are; they have started to move the needle in the right direction and avoid prescribing the what and how as much as possible. If the team is not on track to achieve their KRs, more suggestions are made, and the meeting turns into a brainstorming session to put the team back on the right track.

This approach results in extreme ownership by the teams and hands-off management, which is the only way to scale an organization and have more teams autonomously pulling in the same direction.

Defined outcomes

OKRs are all about measuring the right results and focusing the teams and individuals on the right objectives. This powerful concept can be applied at different levels and to different situations, including to:

• Quarterly goals (as discussed above)
• Large product releases
• Features and user stories

Let's talk about stories and features and how OKRs can make what we already do as agile teams much better. Agile frameworks suggest using the definition of done and using a set of Acceptance Criteria (AC) that are focused on functional and non-functional requirements. AC is measurable right after a user story is done. What's missing, though, is a measurable impact on the business and customers after the feature is in customers' hands. This approach in the software industry has resulted in building many features and implementing many user stories that are great ideas by supposedly visionary people with no positive impact on customers. That's why a high percentage of software features are not used. Unfortunately, we also tend to avoid removing these functionalities from the software, which over time results in bloated, complicated software that doesn't deliver on its intentions and confuses the users.

What if we treated features and stories as science experiments with defined, expected outcomes instead? Moreover, what if we were willing to alter or even remove the functionalities if they did not deliver on the expected result and move on to the next experiment?

For example, let's take a look at the following user story:

As a user, I want to be able to

• share my assets easily with my team members who have not yet signed up for the app

As the product team, we want

• users to be able to invite new users to the app while sharing contents

So that

• I can collaborate with everyone on the team and share my work results without jumping through hoops.

So that

• we can expand our app usage within organizations.

OK, well, those are good and complementary user stories written from two points of views that clarify the requirements and also indicates the reason using the "so that" clause, but it is missing information on how we can measure whether the feature is delivering on the expected outcomes.

Let's make it better by adding OKRs:

We will achieve higher user satisfaction and expansion in new accounts as measured by

• X point increase in the satisfaction survey that we show to trial users
• Average Y% increase in new users signing up for all accounts

Note that, with our defined user story, while the functionality can be quickly validated when the feature implementation is done, the expected impact on users (i.e., increased satisfaction) and the business (i.e., increased accounts expansion) are not described as measurable outcomes. The addition of OKR solves this problem by defining a hypothesis to measure the success of the feature against.

Wrap up

The OKRs framework was first developed at Intel, and since then, it has been made famous by Google and used by many successful organizations including LinkedIn, Twitter, and Klipfolio.

In my experience, using OKRs can improve the software development teams' management practices, processes, and products by

1. Giving teams purpose (objectives),
2. Empowering them to autonomously deliver a set of key results that they are accountable for, and
3. Better defining the expected outcome of their deliverables (i.e., release, features, and user stories)

Join the discussion

Let me know how to use OKRs to improve your agile software developement.

- Ali Pourshahid, PhD, is the Director of Software Developement at Klipfolio. He can be reached at @ali_pourshadid.

Still want more?

Check out some of these related articles:

• Key metrics for agile developement teams
• How do dashboards help agile software development teams?
• Why cycle time may be the most important metric in software development