Transcend the “Feature Factory” Mindset Using Modern Agile and OKR

Agile adoption in most companies focuses on delivery. Scaling frameworks usually do not help, as they take the path of least resistance and concentrate on improving software development through lots of practices rather than focusing on achieving business agility.

When it comes to setting goals, the waterfall command-and-control mindset is still the norm: organizations use an annual, top-down process to create a set of static goals that is in direct conflict with being agile.

“Cascading" goals is a standard corporate process. Can you think of a more top-down waterfall analogy than a cascade?

Waterfall goals and metrics turn teams into "feature factories" with no focus on delivering value. As John Cutler describes, many developers are “just sitting in the factory, cranking out features, and sending them down the line.”

Marty Cagan highlights the huge missed opportunity of feature factories: “teams are just there to flesh out the details, code and test, with little understanding of the bigger context, and even less belief that these are in fact the right solutions.” That is, the people closest to work have no influence on making decisions to help their customers or leverage existing solutions.

Instead of giving teams the autonomy to create great products, this failed version of Agile revolves around a set of projects approved by management.

Frederick Taylor would rejoice to see that his teachings are still in use today. "The work of every workman is fully planned out by the management at least one day in advance,” he wrote in 1911 in The Principles of Scientific Management.

In the Taylorist approach to Agile, teams exist to deliver projects and features planned in advance by the executives. This waterfall planning model slows companies down and makes it harder for them to adapt to change while increasing risk and waste.

How can we even call them agile adoptions? Practitioners know that using Agile to deliver a waterfall plan has limited benefits:  70% of them report tension between their teams and the rest of the organization, while  63% of agile adoption failures are linked to the company culture and philosophy being at odds with agile values.

A Better Way

The alternative to transcend the feature factory mindset is to embrace Modern Agile's four principles. However, how can we apply them in practice? How can we "be" Agile in the modern sense?

There is one actionable tool for business agility that, if used correctly, will support the adoption of the four Modern Agile principles. This tool is OKR (Objectives and Key Results), the goal setting framework used by firms like Intel, Google, and Spotify.

The big difference from traditional planning methods? OKRs are set and evaluated frequently - typically quarterly. Furthermore, rather than being cascaded down the organization by the executives, OKR is bidirectional: teams create most of their OKRs in alignment with the company goals and then contract them with the managers in a bubble-up approach.

This approach provides a much more engaging environment for teams, who now feel responsible and accountable for the goals they help set, which they track on a fast weekly cycle.

Setting challenging goals is a fundamental tenet of OKR, which drives results and creativity. As Amantha Imber reported, research shows that if we put people in a role that challenges them, 67 per cent will demonstrate above-average creativity and innovation in their performance.

Dan Montgomery puts it well, “OKR is the day to day engine for organizational agility.”

How can OKR support the four Modern Agile principles?

Deliver Value Continuously

Scaling agile is hard because scaling delivery (which is why corps go agile) doesn't scale value. Jeff Gothelf, co-author of Lean UX and Sense and Respond

As Felipe previously wrote here at InfoQ, the Agile Manifesto is wrong. The seventh principle, "Working software is the primary measure of progress,” is outdated and misleading. It was conceived at a time when agilists had to convince people that delivering documentation was not enough.

This old assumption that working software is a measure of progress rests on the belief that all software that works is valuable. We now know that this is not true. We need to provide valuable software - as in the first principle of the Manifesto. Modern Agile teaches us to focus on continuously delivering real value to help make our customers awesome.

Modern Agile knows that "done" only matters if it adds value, as in this great provocation from John Cutler: ”the often forgotten rightmost column. Did it work?”.

We need to abandon task-based concepts such as the definition of done, burn-down charts, and velocity, to focus on value. Instead of acceptance criteria, we need success criteria - with OKR.

Although the wording of the Manifesto is misleading, some of its authors have written explicitly about the need to focus on outcomes:

The key to [defeating] waterfall is to realize that agilists value Outcomes over Features. The feature list is a valuable tool, but it's a means not an end. What really matters is the overall outcome, which I think of as value to the customers. Martin Fowler

Because it's just a framework, OKR can be used to measure outputs. The mere measurement of activities, however, is not a proper use of OKR and is incompatible with Modern Agile.

Practicing Modern Agile requires frequently setting and evaluating Value-based OKRs, which measure the delivery of value to the customer or the organization.

The two examples below clearly show the difference:

By adopting Value-based OKRs, teams can focus on delivering value. However, how can they do that "continuously"?

The OKR quarterly cycle can act as the ultimate timebox to deliver value: every team has to generate value during the quarter, improving the selected Key Results. Instead of big releases, teams focus on testing hypotheses and experimenting and learning rapidly, which leads us to the next principle.

Experiment & Learn Rapidly

Instead of being data-driven, outdated Agile is driven by the HIPPO: the Highest Paid Person’s Opinion, as brilliantly illustrated in the book How Google Works:

Companies are stuck with the old Agile delusion that showing software to stakeholders during a sprint review or demo is an adequate measure of progress.

It is only possible to Experiment & Learn Rapidly when we focus on outcomes and evidence rather than personal opinions.

OKR replaces the HIPPO with measurable experiments that allow the team to learn and iterate. It enables teams to adopt practices such as Hypothesis-Driven Development, as described by Barry O'Reilly:

1. We believe <this capability>
2. Will result in <this outcome>
3. We will have confidence to proceed when <we see a measurable signal>

If our goal is a business outcome and we give the team the freedom to experiment towards that goal, small investments can lead to awesome results. In one such example, a 20-minute feature tripled sales for 'Know Your Company', while Eric Elliott delivered "one Jira ticket that made his employer $1MM/Month”.

Make People Awesome

If you’re just using your engineers to code, you’re only getting about half their value. Marty Cagan

The underlying assumption of the feature factory model is that the team is incapable of deciding what to build. This approach is based on the taylorist principle of separation between planning and doing, which is both toxic and demotivating.

The Modern Agile principle 'Make People Awesome' is grounded in providing people with opportunities to contribute their best ideas.

When your team has no voice regarding what to build and just empties their plate of backlog features one after another, they are not awesome. Moreover, you are not getting their full contribution.

To truly enable autonomous self-organizing teams, you need to give them the freedom to decide how to achieve the desired valuable outcomes. The purpose of the team has to change from “delivering the features the stakeholders want” to “achieving the agreed Value-based OKRs.”

Henrik Kniberg has a great slide highlighting this shift in purpose:

In the traditional Agile approach, teams work on things because somebody told them to (“Sam”). In the other extreme, teams work on things for no other reason than “they feel like it.”

To make people awesome, we need a third option. Teams that have a purpose and understand how they can make an impact. They have a clear line of sight between their work and the company strategy.

Make Safety a Prerequisite

A team of researchers from Google found that the leading dynamic that sets successful teams apart from other teams is psychological safety: Can we take risks on this team without feeling insecure or embarrassed? Can we overcome fear and reluctance to speak up with potentially controversial ideas or questions?

One of the fundamental tenets of OKR is that companies should not punish people for pursuing ambitious goals. By decoupling OKR from compensation and promotions, companies can create psychologically safe environments where people can try bold ideas.

However, to Make Safety a Prerequisite, companies also have to shorten their validation cycles drastically. Several years after the release of The Lean Startup, most organizations are still working for months without delivering anything to the end user.

They expose themselves to risk by having teams, in their most part only composed of developers, incrementally and blindly delivering a waterfall backlog to a staging environment, without any form of external validation.

To reduce risk companies need to stop to blindly follow plans and evolve from continuous integration to continuous delivery and continuous validation.

The only way it's all going to go according to plan is if you don't learn anything. Kent Beck

To make things worse, these plans are mostly devised by a single Product Owner or Manager, who sometimes doesn't even have access to product data to make good decisions. This sort of situation is demoralizing and unsafe. Mary Poppendieck, author of Leading Lean Software Development, wrote:

Perhaps the biggest shortcoming of agile development practices is the way in which teams decide what to do. [...] for the longest time, answering these questions have not been considered the responsibility of the development team or the DevOps team. Mary Poppendieck

OKR Makes Safety a Prerequisite by ensuring that the teams collaborate on setting goals and deciding what to build (or experiment with) and adopt shorter feedback cycles, reducing risk and waste.

As David J Bland wrote, “[the process of] annual planning and budgeting collide with your efforts to adapt and change your roadmap as you learn in the market... Leaders are finally realizing that to make their organizations more agile, they’ll need to start addressing some of these [fundamental] functions to achieve organizational agility.”

Conclusion

Just as with any other planning framework, OKR is not perfect and can be misused. We believe that Modern Agile's four principles to they can be a valuable guide your OKR practice and an actionable starting point for your Modern Agile journey.

Combining Modern Agile with the proper use of OKR can be a lightweight, joyful way for organizations to help their people achieve awesome results.

For more thoughts on Modern Agile and OKR, check-out modernagile.org and felipecastro.com.

Thanks to Lael Gold, Joshua Kerievsky, Bill Wake and Tim Ottinger for early reviews.

About the Authors

Felipe Castro is a Goal Hacker. He helps organizations transform how they use goals by adopting OKR, the Silicon Valley framework for agile goal setting. He created the Set-Align-Achieve cycle, a simple method to avoid OKR’s most common pitfalls. Felipe blogs at felipecastro.com.

Alexandre Freire Kawakami is a programmer, coach, scientist, student and teacher who loves to push boundaries of agile software delivery. As Managing Director at Industrial Logic, he focuses on delivering quality software and services to solve our client’s real world problems, and helps provide the tools needed to create a pathway to excellence for his team.