OKRs in Agile Q&A part 2: The Backlog

Continuing from my last post and more questions arising from my Reawakening Agile with OKRs talk.

In my OKR book I advice teams to forget about the backlog and instead use the OKRs as a story generating machine. As I expected, this grabs people’s attention. For many this might be the most surprising piece of advice in the boo, and perhaps the most controversial.

So it is hardly surprising that there were several questions around this:

Q1: If the backlog isn€™t a reflection of what we need to do in order to move towards our vision what is it for?

Exactly. If the backlog does not reflect your vision then what is the point of a backlog?

First off, if the backlog is aligned with your vision, and things are working well then why change? Certainly don’t add OKRs unless they are addressing a problem, and when you add OKRs see if there is anything else you can remove. If OKRs are simply repackaging the backlog then why both? Why add to the tools and processes in use?

For a few fortunate teams that is indeed the case. However, for many teams the backlog also contains a multitude of work which is not part of the vision and requested fixes. The backlog long ago became a dumping ground for requests.

Yet removing work from the backlog becomes hard. Product Owners feels they lack the authority or confidence to actually say “No, we will not do that.” At the same time the teams performance is judged by “how much backlog” gets done. Success or failure come down to “is the backlog done?” Thus the backlog comes into conflict with the OKRs.

In the book I introduce Jeff Bezo’s “Day 1” approach where company works as if today is the first day and questions what they are doing. OKR setting needs to be a day-1 experience.

Q2: Backlog needs reviewing to align with OKRs, surely?

That is one approach, set the OKRs and then before or during every planning meeting comb through the backlog and find work which will move you towards the OKR. That will work if you have a few dozen items in the backlog but what if you have a thousand or more? What if the backlog has been passed down from a previous product owner or a requirements document? In both cases that work will be harder.

The bigger problem is: what if you think of something that is not in the backlog and will move you towards the OKRs?

Do you say No?
I expect not, I expect you will quickly write it, slip it into the backlog and say “look what I just found”

Now the backlog is a collection of ideas which might, or might not, help achieve the OKRs but which you might not do.

At which point, what is the point? Why not just brainstorm what you can do?

Q3: Isn’t OKR then a guidance to create Backlog? or prioritize it?

Create a backlog, yes, the OKR is guidance to create a backlog – its a story generating machine. So what is the point of having 500 stories which describe work not related to the current OKRs? Will not get done anytime soon? And likely will never be done? But which confuse the governance process and drawn everyones morale because “we still have 500 PBIs to do.”

Once you have your OKRs then there is little point in creating any more backlog then you will do in the next three months. You may generate 12 months of work but since OKRs are reset every three months the chances are three quarters of those stories will be thrown away.

So every quarter reset the backlog and start over. That is pretty much what I’m advocating.

Prioritizing the backlog, see Q2 above.

Q4: How have you approached the removal of backlogs? small experiment?
Q5: Have you done this in real life? How did you persuade people?

OK, you found me out, we didn’t actually throw the backlog away. There was some history in there which was useful and more importantly it would have drawn too much attention to the team. Instead we just ignored it.

This started as a small experiment between me – as Agile Coach – and the Product Owner: we just opted to ignore it.

We set the OKRs based on current priorities and strategy. Then in the planning meetings if we knew of a story in the backlog we pulled it up. But actually, this turned out to be more work than it was worth. Plus, by challenging the team we got better answers and more involvement.

It didn’t take long before the team noticed what was happening but I don’t think they minded much. Again they might say “O I know there is a story in there to do…” but more generally we just wrote new stories there and then: the OKRs were a story generating machine.

In the book I describe a further experiment I ran with another coach, as a result she came to the same conclusion: OKRs before backlog. While we shared this with other coaches – and indeed anyone who wanted to talk about it – we didn’t make a big fuss or publicise it. I’m doing that now.

Succeeding with OKRs in Agile

I see this approach as the logical conclusion of working with OKRs so I don’t think you need to make a fuss. You can just do it and I expect more teams to reach this conclusion. Except of course, those backlog-slaves who are labouring under corporate agile to burn-down the backlog!

Succeeding with OKRs in Agile is available in print or ebook format from Amazon now, an audio version will be out in the next few weeks. I will be repeating Reawakening Agile for Agile Newbury next month and discussing OKRs with Adrian Reed in May.


Subscribe to my blog newsletter and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

OKRs in Agile Q&A (part 1)

It shouldn’t surprise you to learn that I’m doing a lot of talks about Succeeding with OKRs in Agile at the moment. Last Tuesday spoke to Digital Transformation in London and Lean Agile Coaching London groups (a joint Meetup). At the end there were a lot of questions and I didn’t get to answer them all – in fact more have come in on mail and twitter since. I’ll try and answer them here, but there are so many questions I need to split this post in two.

If you missed the presentation the slides are online and there is a recording on YouTube. Alternatively I’ll be presenting again at Agile Newbury in April and the Craft Conference in May.

Q: You said “the companies which make the most profits don’t aim to maximise profits.” Do you have any references for that?

A: I’ve heard this argued several times, although its not a clear cut case because you can’t do an experiment and profit isn’t always the best measure of commercial success. You might look at share price, or earning per share or several other measures.

The most recent – and probably the best – evidence I’ve seen is from Alex Edmunds in his book Grow the Pie. Edmunds argues that profits are but one part of the value created by companies, those who focuses exclusively on profits neglect the other parts, society looses out, and profits are less than they could have been.

The good news is Edmunds presents lots of evidence, and counter evidence. The bad news is: that can make for a lot of reading – sometimes dry.

John Kay in Obliquity makes a similar point in a more readable book but one that lacks so much hard research. Another book worth reading on the subject of profits and value is Mariana Mazzucato, The Value of Everything.

Q: Where I’ve seen companies use OKRs they are set by the people at the top and passed down the organisation. Surely letting teams set their own OKRs would loose alignment?

Yes, I get the impression that this is what many companies do. But to my mind that is little more than a re-invention of MBOs (management by objective) and ignores agile. Agile demands that teams be given real responsibility and authority.

As for alignment I would rather the organisation put its efforts into removing the need to align, removing dependencies and building independent, autonomous teams. (I’ve written about Amoeba teams and the MVT model before.)

This is not to say alignment isn’t important but it is secondary. First you want teams which are delivering benefit, when you have that you can seek to optimise them.

Succeeding with OKRs in Agile

Q: How do OKRs work in organisations with large numbers of teams who need to resolve competing visions and priorities but who depend on each other?

Q: To what extent should OKR’s be negotiated – either between teams (where Team A is dependent on the output of Team B); or between senior management and Teams?

OKRs aren’t a silver bullet. Yes OKRs can help, because OKRs define an API to the team you can tell others what to expect. Better still, you – or your product owner – can consult and negotiate with those other teams and find out what they need.

The ultimate answer is not better co-ordination or even communication, it is removing those dependencies, making teams more independent. Conflicting OKRs will highlight those problems but aligning those OKRs will never be a complete solution.

What you absolutely must avoid is having one person, or a small cadre of people, decide what each group needs and issuing OKRs to others to fulfil it. That destroys team independence, the aim here – in agile, in the twenty first century, in digital business – is independence.

Some people talk about these ideas under the title “Descaling the corporation.” This about increasing team coherence and reducing coupling. Corporation need to reduce the connections and dependencies.

Q: How granular should OKRs be (in terms of departments), e.g. should you have separate OKRs for Product and Customer Success? Even though they are both partially responsible for renewals?

I’d have to look at the context here but in general I would rather remove that distinction between those departments. Your aim is “customer renewals”, the question is “what can we do to increase renewals?” – maybe that is best achieved through a product enhancement, maybe through helping customers succeed or maybe though something else. Don’t just span boundaries, rethink them. Start with the outcome and work back rather than starting with your own structure.

Q: How to start to introduce OKRs in corporate environment?

Q: What can be a first step with OKRs in deeply traditional company?

As always start small, run an experiment. However, there is a difference to agile. My approach to agile has always been very much “just do it.” There are lots of agile practices and you as an individual can just start adopting them, in time you can involve other people . Its far easier to introduce agile bottom-up than top-down.

But with OKRs things are a little different because OKRs are a team level tool. So right from the start you need to take your team with you. Second, because OKRs represent a communications interface – a team API if you like – and because Agile OKRs require respect for team autonomy you need someone a little higher up to support the move. That someone should be able to provide “air cover” for your experiment.

Once you have those positions in place then just try it, run an experiment for a quarter or two. Hopefully you will be able to see success which can propel you further and help enrol others.

One technique I’ve used before it a book study group: gather some people who are interested in learning and improving. Choose a book – my OKR book being the obvious choice! – and meet (lunch time if you want) every two weeks. Work through the book together, discuss every chapter.

I don’t think that prescription changes if the company is “deeply traditional” – although I expect the journey will be harder, you may have more trouble recruiting companions or securing air-cover.

Q: How do you deal with resistance of change in organisations?

Unfortunately there is no silver bullet. I feel introducing any change is often an exercise in throwing mud at a wall, or even banging your head on the wall. The level of personal perseverance can be very high, make sure you celebrate every win no matter how small.

Perhaps the best advice I’ve ever heard comes from the head of the IMF, Kristalina Georgieva, she was asked a similar question in a Financial Times interview last year: “The mistake we often make is to try to zero in on the naysayers and try to convince them, rather than empower and excite the agents of positive change and just ignore the noise.”

Q: How much would you like SMART kind of goals comparing to OKRs?

Most of SMART – specific, measurable, achievable, relative and time-bound – works, although more at the key results level than the objectives level. I would take issue with the A though – achievable or attainable depending on your preference.

Really you want goals which are a bit more than you think you can do. Otherwise you get a problem that economists call satisficing: people aim low, they play it safe as a result the whole exercise becomes a game play.

Now each organisation needs to make a call on what level of balance they expect. Google apparently only expect 70% of OKRs to be achieved, they lean towards more risk, less predictability and more misses.

I do think it is important that leaders stand up and say very clearly what they expect from teams using OKRs. Is the company challenging teams to do their best and accept some failures will occur? Or does the company value predicability and accept some slack in the system? Both are valid choices.

Q: How do you come up with the hypothesis of the Key Results?

Good question, and it is not one confined to OKRs. I’m going to duck the question and suggest you read Barry O’Reilly on Hypothesis Driven Development.

Q: It sounds like you view OKRs as a “root and branch” replacement – its all or nothing?

Maybe. Hopefully.

No, I think you can add OKRs to an existing agile system – that is what I was part of originally. But, once you start working with OKRs and once you start following the logic of OKRs, that is where you end up.

I’ve arrived at a point where I hope OKRs are the basis for a big change in the way we do agile. As I said at the start, many companies do a form of “corporate agile” which lacks the high aims that many of us who dreamed of when doing agile in the first decade of the millennium.

Q: Why do you think the corporate agile virus exists and what is the cure for it?

I could give you a dozen reasons and the truth will still be something different. Let us be clear, corporate agile is better than what went before but it falls far far short of what we dreamed about at the start of the millennium. Right now the biggest problem is probably scaling, companies want a high R-value but in chasing agile working they are getting teams with a very low E-value (effectiveness.)

The cure is the one true test of agile, ask the question: Are we still working the same way we were three months ago?

If you are (the same) then you are not agile. Agile is about learning and changing, hopefully for the better but there will be some backwards steps. Learning creates change and change creates learning – experiments help. Keep learning, keep trying new things, keep changing.

Q: How is this different from the OKR we apply to Strategic themes in Lean Portfolio Management?

I’m not familiar with Lean Portfolio Management so I can’t really comment. Quite possibly it is an alternative implementation of the same ideas.

Q: What if a company has Vision & Mission, and KPIs (company wide, squad wide). should we implement OKRs also?

First: are those things giving you what you want? If so then leave well alone! You could conduct an experiment with OKRs, take a couple of teams, relaxed the other metrics and let them run with OKRs for a year then look at the results.

I don’t know how exactly you are using vision and mission but I would assume you retain them. OKRs are about delivering, in the next three months, progress against your missions which themselves build towards your vision. They should all be expressing your purpose in different words over different periods.

KPIs is more tricky.

To my mind KPIs are a measuring tool, they are a way of saying “We are 1.4 meters high.” In that sense they are compatible with OKRs because you would just have an OKR to advance an KPI, “Objective: increase KPI to 1.8m.”

However, if you are using KPIs as targets things are different. They are overlapping with OKRs, in which case use one or the other.

More worryingly you might hit Goodhart’s Law, goal displacement or satisficing. These are problems I discuss in the book in-relation to OKRs but they are not confined to OKRs.

Finally, mission, vision and KPI already sounds like a lot of competing techniques, if you are going to add OKRs please look again at how you manage “objectives” (in the broadest sense). You may have too many mechanisms. If you are adding OKRs be ready to remove something.

Q: What would you say is the biggest regret / challenge in Succeeding with OKRs in Agile? Something you wish you could have done differently?

Half of me wishes the book was smaller: I believe people are more likely to read (and buy!) smaller books. In terms of getting this message out there I think smaller is better.

The other half of me wishes the book was longer: there is more I have to say, some chapters were left “on the cutting room floor”. So there may be a sequel with these and some new chapters. Plus, a rewrite of a few chapters were I think the message could be reduced and made clearer.

Q: What is / will be the #-tag for these better smarter corporate agile virus enhancing OKR?

Ha ha, I was burned by #NoProjects, it made me famous but I still have the burn scars. So I am absolutely no going to say #NoBacklogs – although you could read that into some of my work.

Increasingly I think Agile needs to lay claim to bottom-up OKRs, not the MBO-lke top-down OKRs which I see some adopting and even hear being advocated. So maybe #AgileOKRs.


Succeeding with OKRs in Agile is available now in print and e-book versions from Amazon.

Audio book coming soon