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.
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