Reawakening Agile with OKRs?

Once upon a time, say about 10 years or so back, when I visited companies or spoke at conferences I usually met developers who said "We really want to try doing agile, but management doesn't understand it and won't let us do it." Back then developers wanted to do agile, agile represented a bold new way of working which offered the chance to fix so much which just seemed wrong.

Today I still meet developers keen to do agile "properly" but I'm far more likely to meet managers who want their teams to work agile but say "My teams don't want to do it". Somewhere along the line the fun, excitement and hope offered by agile got lost.

There are still teams out there who enjoy the work and experience the excitement of working collaboratively in an ever changing environment. 

As agile has become more widespread it has also been diluted and lost much of its appeal in many places. Teams are expected to "just do stuff", backlogs and stories have ceased to be a starting point for conversation and negotiation; the backlog has become an instrument of tyranny "when will it be done?"

I've been wrestling with this dichotomy for a while. As someone who read "Extreme Programming Explained" within weeks of publication and evangelised a better way it honestly hurts when developers tell me "agile is a management thing" or "agile is micro management." That's not the agile I signed-up for, it's not the agile I advocate.

Last year I started calling these forms "Mild Agile" and "Radical Agile" but increasingly I think it is not "mild" its "Corporate." As corporations have got the agile buzz and see it is a good thing agile has changed. 

There is an irony here, for a decade or more those of us in the vanguard sought to explain agile in language managers could understand. At some point we succeeded, managers got it, but in the process agile was watered down, it lost its radical edge.

To be fair "corporate agile" may not be the agile I dreamed of but it is still often better than what went before. For a big corporation, like a legacy bank, the formulaic application of Scrum or SAFe may represent a significant improvement over the previous state.

Nor should I equate "radical" with good. Radical implies risk and any sensible company isn't going to take on risk if it doesn't need to. The problem is that when risk is removed, agile is diluted and excitement is lost - it's like swapping a 300 foot roller coaster with loops for the preschool merry-go-round.

When you de-radicalise many agile techniques what you are left with isn't that much different from where you started - and still lacking in fun. 

One person pair programming? That's just programming.

Automated Unit Testing where you don't automate the difficult bits and only run once a day. Bring back 1992, all is forgiven!

Story point estimates where every team in the company makes one point equal to one day. That's just estimating.

User Stories written by analysts, implemented by programmers and tested by testers with no verbal communication. That's just waterfall.

Stripping back the radical bits of agile also strips out the feedback loops and learning processes that underpin agile. Similarly the push towards scaling agile has led to a standardisation which discourages the very variations and experiments that generate learning.

I could debate why this has happened and who is to blame but that isn't a very productive conversation. There are many contributing factors, understanding why this has happened is only half the story. What is needed is a way of reintroducing the radical ideas, creating feedback loops and learning opportunities and allowing teams to experiment.

While there are countless proposals for "Agile 2.0" the agile world has become far bigger and far more commercialised (just try Googling for “Agile 2.0” to see what I mean). In the early days the pioneers knew one another and shared - remember Snowbird? There was a friendly rivalry between XP and Scrum. Today there are thousands of agile experts, dozens of famous names and scores of consultancies all trying to get our attention.

An unlikely solution

Amongst all of this a couple of years ago I stumbled into OKRs - objectives and key results. While I'd known about OKRs for years I wasn't keen on them. At first sight look a lot like "management by objectives" (MBOs) which management guru Peter Drucker both invented and then eschewed. 

Adding to my dislike was the way OKRs put numerical targets on things. There are so many examples of such an approach going wrong that it even has a name, "goal displacement" and even a law, "Goodhart's Law," to warn against it.

In the spirit of experimentation I used OKRs with several teams and I got a surprise: they can be very effective, and while they might be used in a very anti-agile way they can be also enhance agile.

For example, OKRs create another source of work for a team. The team needs to decide quite early on what the relationship is between OKRs and the backlogs. Which comes first?

The approach I found works best is to lead with OKRs - what the team want to do. So throw your backlog away and adopt a just-in-time requirements approach. Stop seeing "more work than we have money and time to do" as a sign of failure and see it is a sign of success.

Every time you need to plan work return to your OKRs and ask: *What can we do now, in the time we have, to move closer to our OKRs?*

Stop worrying about burning-down the backlog and put purpose first, remember why the team exists, ask *Right here, right now, how can we add value?*

Used in a traditional MBO-style one might expect top managers to set OKRs which then cascade down the company with each team being given their own small part to undertake. That would require a Gosplan style planning department and would rob teams of autonomy and real decision making power. (Gosplan was the agency responsible for creating 5-year plans in the USSR, and everyone knows how that story ended.)

Instead, leaders should lead. Leaders should stick to big things. They should emphasise the purpose and mission of the organization, they should set large goals for the whole organization but those goals should not be specific for teams. 

Leaders should then say to the teams: "This is where we want to go and this is why we want to go. How can your team help?" 

Teams then set their own OKRs. Teams themselves are in the best place to decide how they can contribute to organizational goals. Each team has a specialist mix of skills and unique people which together create products and provide services. Teams are not islands so they need to listen to what others - particularly customers - want and value when setting their OKRs. 

Decentralised decision making

Suppose the CEO of our online store sets the organisational goal of entering the Canadian market. Traditionally planners would draw up a plan, decide what was needed, set smaller goals which cascade these down the organization. Existing teams might be broken up and new ones formed to undertake the plan.

In a bottom-up world the CEO's goal is a challenge to the teams in the organisation. The payments team would quickly realise this meant the payments systems needed to handle Canadian dollars and set themselves some goals to do so.

Similarly the fraud team would set about considering what needed to change in their systems and what they needed to change. They may see the need for enhancements to the payments system so the two teams need to coordinate and perhaps include key results to satisfy the other.

In the process teams might find they needed extra staffing or specialist skills. Rather than planners deciding the skills and staffing needed, then pushing these resources to the teams, the autonomous teams pull these from inside or outside the organisation as needed.

Rather than centralised planners deciding what was needed the autonomous parts of the organisation would decide how to respond and coordinate with others were needed. Each team - and particularly the product owners - would understand the opportunities to deliver benefit to customers, stakeholders and executives, then decide what to do.

We know from bitter experience that meaningless deadlines, and dates far into the future fail to motivate people. We know sprints, improving lead time and working in the small works. But the downside of this is that we lose sight of the bigger goals - one can't see the wood for the trees - and purpose.

OKRs can address this problem by allowing teams to take a three month view. Three months is something of a Goldilocks time frame: not so short that we cannot have non-trivial goals, but not so long that the end is far away.

Challenged by leaders to help move towards the ultimate goal in the next quarter teams can think broadly and expansively. All views can be heard and options considered. When distilled to specific OKRs with numbers attached the team's own goals - set by the team - can be shared and discussed with others. 

OKRs are a powerful tool for focusing teams but perhaps more importantly OKRs are a communication tool. Think of them as an abstract interface.

The OKRs tell others - specifically leaders - what they can expect from the team and how the team will contribute towards the bigger goals. Teams and leaders can negotiate around that interface and it can be shared with others.

Then, behind the interface, the team is responsible for implementation. Implementation might be a black box to the leaders. The team has the authority and can organize how they deliver on their goal.

Reawaken agile?

Right now OKRs have the power to reawaken agile or to kill it. OKRs represent a form of test-first management which when used with an agile ethos can help devolve authority to teams and improve communication between teams doing the work and those holding power thereby building a virtuous circle.

Yet used naively OKRs threaten to increase the workload on the team, re-introduce top-down management and create target gaming on a monumental scale. Worst of all they might rob agile of any legitimacy. 

To finish I should say I too have a product to sell, I've written a book, on combining OKRs and agile (Succeeding with OKRs in Agile) so this article may be seen as self-serving. However, I write because I see the potential to reawaken the radical nature of agile and re-alight the passion I, and many others, felt in the early years. 

There may be other tools which can do this - indeed I hope we have several vaccines! Today OKRs seem to be building up a head of steam and becoming more widely adopted. 

Perhaps this is because they can trace their origins back to MBOs, and perhaps because they are approved of by big-name-consultancies. Either way, OKRs have a legitimacy much of agile lacked for a long time. Still, like Scrum, behind this management friendly veneer is a tool which has the power to vastly improve developers lives.

Yoan Thirion produced this infographic summary of the key messages from Succeeding with OKR’s in Agile:

Infographic by: Yoan Thirion

About the Author

Allan Kelly guides software professionals enjoy more fulfilling and satisfying work by improving the way work is organised and requests are made. Happier people and better ways of working make for more effective companies, greater value and competitive advantage. His wide experience of the challenges faced in software development underpins his advice, coaching, training and writing. Allan's latest book is "Succeeding with OKRs in Agile".