In our last article, we pointed out that some adoptions of Agile are focused on outputs instead of outcomes. In this article, we will discuss some strategies for making sure your team is focused on the right outcomes.
First, let's explore another Agile principle that is often overlooked: "Simplicity - the art of maximizing the amount of work not done - is essential." We observe teams following this principle when they are trying to simplify code or when they are working with new libraries, tools, etc., but a point that is frequently missed is that sometimes we should avoid writing code altogether. The point is to deliver the outcome with as little output as possible. If we can achieve the outcome by creating an easier alternative to a coding solution, then we should do it. Yes, we will achieve zero velocity, but we will also increase zero complexity, deliver zero bugs, add zero technical debt and so on.
 
But again, how can we change our mindset and start delivering outcomes?
Start With Why

“Money is a perfectly legitimate measurement of goods sold or services rendered. But it is no calculation of value... Value is a feeling, not a calculation. It is perception.” - Simon Sinek, Start with Why

Although every company aims to be profitable, this aim is not usually why the company was created in the first place. Instead, every company is created to solve one or more problems, and those problems must be as clear as possible to everyone within the company. When everyone knows the problems they must solve for their customers, they are engaged in achieving the outcomes the company needs and are free to innovate.
 
In the same way, every team has a responsibility that is different from every other team's. It is important for each team's members to clearly understand their mission and why they exist in the company context. If this is not clear, you can host a Team Mission Statement activity to help the team figure out their "why." (We won't go into the details of how to host these meetings in today's blog, but you can search for articles such as this one on how to host one of these activities.)
 
To be effective, a "why" statement should be short, bold, easy to remember and extremely compelling.
 
North Star Metric
 
The "why" statement of a company is what engages employees and makes them stay. This why statement should lead to a long-term goal. How do you know if the company is going in the right direction? And how do you check to see whether the company is improving its ability to accomplish this goal over time?
 
This is where a North Star Metric is useful. It is the single key measure of the company's success. With a North Star metric, everyone can track and work toward the company's overall success or make a course correction if something isn't working well.
 
We must take care, however, because it is easy to select a vanity metric instead of an outcome metric. For example, while MySpace's metric was the number of registered users - and that's all they were looking for - Facebook's most important metric is Daily/Monthly Active Users, which is far more important than the number of users who are merely registered. Don't be afraid to change your North Star Metric if you realize that it is not aligned with what is most important for your business.
 
OKRs
 
OKRs are a lightweight process for defining goals company-wide. OKRs were most famously adopted by Google in the company's first year when John Doerr - a Google investor - brought that idea from Intel.
 
OKRs follow this template: I will <achieve an objective> measured by <a set of key results>. This template may be divided into two components: the Objective and the Key Results.
 
Objectives are sentences that describe what the company aims to achieve. They are qualitative, meaning we don't measure them. Objectives should be short, easy to remember, challenging and motivational.
 
Key Results are a set of metrics that represent the achievement of goals. For every goal, we can measure between two and five key results.
 
When defining OKRs, we need to create different sets. First of all, there are company OKRs. Once these are established, every department can define their own OKRs based on the company ones. And these department OKRs are also broken down until we get to the team level. Note that OKRs don't necessarily need to have the same timeline. Usually, company OKRs are defined yearly, while team OKRs can be defined quarterly.
Conclusion
There are more ways than one to encourage your team to pursue important outcomes, and what works for one or more companies may not work for you. Be aware of your market situation, your company reality and even your company culture. In the end, pursuing outcomes is a discovery process where you shouldn't be afraid to innovate. Small failures lead to learning, and learning leads to success.
 
What additional ideas do you have for focusing your team/company on pursuing the right outcomes? Please share your ideas in a comment below!

Author

Eduardo Bruno Silva

Eduardo Bruno Silva is a Product Owner at Avenue Code who loves to solve problems for users and customers. He also enjoys reading, video games and craft beer!


Beyond Agile - Product-Driven Companies

READ MORE

Is Your Agile Process Focused on Outputs or Outcomes?

READ MORE

ITIL and Agile: How Each Contributes to IT Best Practices

READ MORE