Agile and OKRs: Publishing your API in a Standardized Format

So, your organization has passed down a mandate that you’re going to do OKRs. Now what? In this episode, I’m joined by Allan Kelly. Allan is an agile coach, author of 7 books, and keynote speaker. His introduction to OKRs was exactly this — it came down as a mandate and he had to figure things out. He’s got some controversial ideas around maintaining a backlog (spoiler: he thinks it’s okay to nuke your backlog and start anew every quarter). He believes it’s okay not to achieve your key results. In his mind, there’s something far more important—delivering business benefit. We’ll discuss these things and more.

“Every time you need to decide what you're doing next, you go back to your OKRs." – Allan (26:28)

What you will learn in this episode

• (00:42) Who Allan is and what he’s all about
• (02:10) How Allan was introduced to OKRs
• (06:39) Who is supposed to set OKRs?
• (08:44) You have permission to delete your backlog
• (15:38) Feature factories
• (17:07) Mild, radical, and corporate agile
• (22:11) What conditions do you need to make OKRs successful?
• (25:38) How OKRs are like APIs
• (31:23) Getting 1% better at every retrospective
• (37:00) When is it okay not to make progress on key results?
• (41:02) Quick-fire questions

Relevant links

• Succeeding with OKRs in Agile: How to create & deliver objectives & key results for teams
• Agile on the Beach

The full transcript

Allan (00:01): You're publishing your API in a standardized format called objectives and key results. And you can read other teams standardized formats, and you can compare and you can give feedback. And in defining this, the team is defining their own space because those OKRs place boundaries on what the team is going to do and what the team is not going to do this quarter.

Intro (00:26): Welcome to dreams with deadlines, a podcast by Gtmhub about aligning strategy execution, and promoting outcome driven cultures through the proven objectives and key results methodology. I'm your host, Jenny Harrell, VP of product evangelism at Gtmhub. So your organization has passed down a mandate that you're going to do OKRs. Now what? In this episode, I'm joined by Allan Kelly. Allan is an agile coach, author of seven books and keynote speaker. His introduction to OKRs was exactly this. It came down as a mandate and he had to figure things out. He's got some controversial ideas around maintaining a backlog spoiler. He thinks it's okay to nuke your backlog and start it new every quarter. He believes it's okay to not achieve your key results. In his mind, there's something far more are important, delivering business benefit. We'll discuss these things and more, let's jump in. 

Jenny (01:29): So today I'm really excited because I have Allan Kelly with me. We're going to talk agile OKRs, all things technology. Thank you for being on the show.

Allan (01:39): Thank you for having me.

Jenny (01:42): So you've been in tech for 30 years now going on, right? 

Allan (01:48): And you make me sound old. I have to say I started at a very young age. 

Jenny (01:52): Let's go with, it's not old, you're experienced. I think that's the interesting thing about folks in the west, is you think that if you have 10 year in the business, it's somehow a bad thing, I think it's glorious, because there's a lot that comes with experience. Well, tell us how you got here, Allan. Like how'd you get to where you are today?

Allan (02:11): Wow. So your older listeners may remember back the eighties, we got microcomputers and you could have a (02:19 inaudible). I was one of those kids, I got one just before I became a teenager and that was me for my teenage years. I worked at an early age, how to make money out of these things. And so naturally off to university, even before I graduated, I had a couple of pretty cool jobs, summer jobs, internships we call them now. And I graduated and I had like 10. I could program the hinge leg of a donkey. I got to work around London. I got to go to California. But about the 10 year mark, 10 years after graduation things got a bit boring. I could program my way out of anything, but I increasingly realized it wasn't the code that was the problem. It was the way we were set up, the way we were managed, the things we were being asked to do. 

(03:17) And I'd seen successful projects. I'd seen unsuccessful projects and I kind of pivoted, as we'd say today. I headed off on this course into, I guess, we call management. But it coincided with the rise of agile. And so I kind of jumped on that bandwagon if you like and I've actually spent not a lot of time managing and a lot more time consulting and advising companies and just one thing has led to another and I've had a fantastic time in the last 10, 15 years.

Jenny (03:53): I saw one of the pieces that you have written for your own blog about OKRs. Tell us about how you transit from this agile coaching and then incorporated OKRs into some of your consultancy work. When did that approximately happen? Why did that happen?

Allan (04:11): I would love to say it was part of a grand plan. Really it was forced on me in the first instance. I was working with this client and I was coaching some agile teams. And then the (04:24 inaudible) came down for above, Val Schult use OKRs. And me and the other agile coaches on the gig, because there's quite a large financial services client working like, okay, we know what OKRs are. We've heard them. We have heard people talk about them, but we all looked at each other and none of us had actually used them in anger before. We set off on this combined collective learning experience. And yes, we went out and we read blogs and papers and yes, like everyone else we rush out and by measure what matters. And like anyone who's read measure what matters carefully, you start to notice the problems with it. It's a great book, but if you pay attention, it's a little bit inconsistent. 

And I also found a very salesy book, exactly how wonderful OKRs are. And I think one of your other guests was talking about this other week, when they were talking about the second-order effects of OKRs. How do you actually do this stuff? Well, I was actually working through it with a couple of teams, with three teams in total and I mean I face up to those problems. And so there's a great experiment. And some of the other coaches who've coached their teams were comparing notes and we did actually run a couple of experiments. Didn't always tell the teams they're being experimented on. That all came to an end. 

And I started to write down some notes about it. And then do you know what happened next? The lockdown? So it became a bit of a project for me to write those notes and turn them into a book. And since then, I find the reason my phone rings more often than not, is not agile, it's around OKRs. So it starts as a force pivot. But I think agile has this problem beyond the two-week mark, an OKRs fill a gap there. So I think they fit right in.

Jenny (06:25): When you had experimented with these teams that didn't know that they were being experimented on. What was one of the first things that you had observed about OKRs and its application, that was challenging for them?

Allan (06:39): The whole setting process, who is setting the OKRs. And it's almost like everyone's in a room, standing, looking at each other. And the team are looking at the senior management kinda saying, what should we be setting? What are your OKRs? And the management are either by design or by default, they're staring at the teams thinking, what are you setting? What are you going to do? And how does this product owner person come into the mix? Because the product owner is supposed to be like the owner of the product. Now another conversation we have another day is about this mixed up world of product donor and product manager. But leave that on side, who's setting these, okay, they're just looking at each other and then you start to set them. And certainly with one of my teams, its almost like, can we really set these ourselves?

Are we really allowed to do these? It was kind of expecting that somebody was going to come along and tell them what the OKR should be. I don't think the organization has really communicated what they expected of the teams, to what degree they were going to tell the teams and what degree the teams were going to make it up. And to this day I kind of think that the reason the organization didn't pass down some OKRs was because they didn't know what they would do themselves and they hadn't got their own act together. And perhaps if they had, they'd have set some more leadership, but it was beneficial, this almost benign neglect that the team then got to set their own. And we got the experiment and we got to set some patterns. Then the next thing that became a problem is OKRs or backlog. Do the OKR come from your backlog or does the backlog come from your OKRs?

Jenny (08:33): So what's the answer to that question because you have a very unique perspective on this, like spoiler alert for all of the folks that are listening. Allan is about to tell you that you can delete your backlog.

Allan (08:45): Yeah. And I tell you, this was one of the experiments. One of the coaches on one of the other teams, this was like our second or third iteration of OKRs. And I remember distinctly having coffee with her and we were talking about this. Do we craft OKRs that reflect what we intend to do, drawing from the backlog or do we set OKRs and the backlog just has to fall in place? And we talked about this. I decided that I was going to lead my team to forget about the backlog, set the OKRs that delivered business benefit. And she decided that the backlog had primacy and they needed to craft OKRs to reflect their backlog plans for the next three months. 

So we set off and we took space a couple of times during the three months. Because we talked every week about something another. Three months later I remember being back in the same coffee shop in the building and talking to myself about how did that experiment go? And before he said anything else, she said, I'm doing it your way next time.

Jenny (09:48): Why did she come around? I'm sure she has figured out some things, I mean three months in for you, what did she realize that you did kind of before having even tried it. 

Allan (10:04): Imagine your typical scrum team and you're sitting there and you've got 2000 items in your backlog. Can you write down a plan for the next six durations over what you intend to do? Look at your backlog, take out the things you're going to do for the next six weeks, put them down. And now write some statements around those things, which are not those things themselves, but reflect the general themes that you are going to do. So there's your first two challenges and your third challenge is to stick to that plan. So that's part of what it is. It mix into a big planning exercise and a big fortune-telling exercise and then a discipline exercise. The other thing is, so teams, in the scrum books you burn down the backlog. I don't know about you. But those sort of teams are once in a blue moon. Teams tend to have these backlogs that just grow and grow and grow either because the stuff they didn't realize they needed to do, or because particularly if you're doing discovery in parallel with development, you're discovering what the customers want.

Jenny (11:20): As you're building it.

Allan (11:22): Exactly. And if you do measure, learn and lean startup and all that good stuff, it wouldn't be any other way.

Jenny (11:31): Yes because it is not waterfall on the front end either. These things are happening kind of iteratively on top of all of that.

Allan (11:39): Exactly. So reversing your OKRs out of the backlog. Actually it's damn difficult.

Jenny (11:47): It's not impossible. 

Allan (11:49): No, I know people do it and I know people tell me the OKRs are there to prioritize the backlog. So another thought experiment for you. You do your OKRs, you're picking items out of the backlog. You're scheduling all the rest of it and you find there's something the OKRs imply that's not in the backlog. What are you going to do? 

Jenny (12:11): What do you do?

Allan (12:12):  Well, you could say, hey, it's not in the backlog. We're not going to do it. 

Jenny (12:16): That's one option. 

Allan (12:17): More likely, you're going to say, oh, let's quickly write it down, slip it into the backlog and pretend it was there all along. Once you've done that, you start to say, hang on, the OKRs are business objectives, the OKRs are outcomes more than objectives. These are outcomes, the business want. These are outcomes we consider beneficial, not just to the business, to our customers, our stakeholders, the team themselves. These are the outcomes. And I should say that I prefer to say outcomes and key results, rather than objectives and key results. It just resonates more. Makes it more, somehow objective.  

Jenny(12:56): Inaudible.

Allan (12:57): Yes, so anyway we can write now the outcomes we want as a business, as a technology team, we can write those things down. And we can set them as goals for the next three months. And then we can go back to our backlog and we can rummage through it. And if we find things that will contribute to that, we're going to do it. But you know what, if we think of things we can do, which is going to add more value or move us towards that goal in a better way, we're going to do it. And so your OKRs at best become a way of organizing and filter your backlog. But actually if every three months you wipe the slate clean and say, forget the past, the past is gone. Let is think a fresh from what we know now. Let us not be bound by what we've written in the past. And we focus on just the outcomes, I actually find you get a better result. 

There's too many teams that have these backlogs, which are overgrown, runaway. And we've lost sight of the forest for the trees. You can't see the big things because you're so in the detail, the backlogs. So I go to the extreme and I say effectively throw your backlog away, sit down when you're setting your OKRs, what is going to make a difference to this team, this business, these customers, what are the outcomes we want? And then that's what we're going to shoot for. If something, somebody thought of six months ago is useful. Hey, we're going to think of it again. If somebody's prewritten something, we'll probably find it. But if they haven't and we think of a good idea, we're going to go with that. And our success is not measured on how much backlog we burn down. Our success is measured more on the benefit we deliver and possibly how many of those OKRs we can put a red tick by.

Jenny (14:58): Under what circumstances does it make sense where you can derive your OKRs from the backlog versus your approach? Because obviously these are intelligent people. They're coach in their own right, They have successful teams I would imagine. And so there needs to be some boundary conditions upon which these kinds of ideas make sense. So what have you seen that would lend one to say, it's okay to keep your backlog and it's okay to derive your OKRs, but just be aware that these are the conditions that would make that the most successful kind of approach

Allan (15:41): Oh I like that. So I'm pausing because there are an awful lot of teams out there who are measured on the quantity they deliver. And the term that often gets used as a feature factory.

Jenny (16:00): I've heard many of that, yes. 

Allan (16:02): And I think in those circumstances it probably makes sense to craft your OKRs around the subsection of backlog that you were going to do.

Jenny (16:12): Because that is the outcome they want to be able to.

Allan (16:15): Yes. And if that is what your organization is asking you to do, if that is what your organization is considering success, then you'd be stupid not to do it. That said, I do not believe that is the best way of working on, that gives you the most fulfilling career. I know plenty of other people that argue with it, we must be missing something because plenty of teams do it. So it's obviously got some advantage. So as with all these things inspect and adapt. 

Jenny (16:51): You've mentioned, I've seen some of your writing where you mention you started calling things mild agile, radical agile, corporate agile. Can you talk through what each of these terms mean?

Allan (17:08): OK. So I've kind of stopped using the term mild agile. I needed two terms to contrast two parts of agile. And at first I called them mild and radical. Mild agile now I tend to call corporate agile because that's the environment you find it in. And what I'd noticed was there's two broad varieties of agile. You got two strains of agile. One is the agile you read about in books. It's the agile we all want and some of the rough edges have been knocked off the case studies. It's not really as pretty as the books paint, but it's the agile we all dreamed of. Those of us who were there in the early days of agile, where you've got these motivated teams who are delivering super regularly and they're making a difference to the world and those teams exist, those teams really do exist. 

They are few and far between. For most organizations, agile is better than what went before. At the same time, we've got this diluted agile, which I tend to call corporate agile because that's where you find it. You find it in the big banks, you find it in the big corporations. You find it places where, yeah, big banks, big corporations, all those kind of people. This is not the kind of agile that we were dreaming of 15, 20 years ago. This has a lot of agile. It has sprints. It has stand up. And a lot of other good stuff, but somehow it lacks the passion of that radical agile that many of us were dreaming about before and different people have identified this and they've called it by different names.

But there's something about the corporate environment that when you try and bring agile into it, it's a combination of things. For starters, corporations, by the nature of risk averse. If you're a start up, what have you got to lose? There's you and your three mates in a loft somewhere living on credit cards. How bad could it be? In fact, most things you could do have been improvement over this. So you can take chances because you've got nothing to lose. When you are a multi-billion dollar corporation, you can lose billions of dollars. You could even Sarbanes Oxy, get somebody put in jail. So corporations are naturally risk averse. And this means they back away from some of the more radical agile practices and they tend to keep some of the traditional methods in place. It's just at a cultural level. They don't make that change.

And also they have this annoying habit of not giving teams, spending authority. This really frustrates their hell of me. Teams get told, or you are now agile. You now master your own destiny. You can do what you want, but if you want to spend any money, you need to come and ask for it. And the answer is probably no. So they kind of water down agile. And in the end, you get this kind of corporate agile, where people are still following the process. People are still keeping their heads down. People are still in mode from the customers, the feedback cycles are missing. And annoyingly, it's still an improvement over what went before. Simply with some teams, all they may do is hold a standup meeting. But you know, even that improves things over what went before. And so agile looks at success. But it's not that rich, radical, passionate, agile, that some of us we're shooting for. Some of that has to do with the fact that we aren't really pushing authority down to the teams and letting the teams really be mini business units.

Jenny (21:14): Oftentimes, OKRs are rejected I think by product and engineering teams, is another technique for management to have a layer of oversight. And so OKRs by virtue of that frame are not welcome, where it seems like you are an advocate for them, but then there’s conditions in which the methodology will thrive. Under what conditions, if we were to kind of have that magic wand and to speak to the enterprise, because a lot of them do listen to this show, and they're adopting these digital and agile transformations as we speak. And we've all seen that they've started to accelerate as a result of this work-from-home situation that we find ourselves in. What are the conditions that would make OKRs agile practices really not only survive in the organization and the way that it was intended, but also thrive.

Allan (22:13): So let's take this from the top down as it were. So the leadership team, they know they should be, but really they should be about vision, purpose missions. They want to paint a picture of where they want to go. They want to paint a shining city on a hill and say, this is where we want to go to. This is how we want to make the world a better place. Our organization are, hopefully you have a good purpose of people believing, this is where we want to go. But I don't want them to go any further than that. I kinda want them to stop there. I want them to leave some wide space. I want them to leave a void there. I don't want them to try and tell people how to do it. Most definitely not OKRs and post from above, management by objective style, or I tend to call them cascading OKRs, where one layer tells the layer below, then tells the lay below. So managers, senior leadership paint the vision and then leave wide space. Because today I would expect, not all companies have moved away from the project model, but the safe Spotify, the other scaling frameworks.

Jenny (23:36): Like less, for example.

Allan (23:39): My own (23:39 inaudible) digital, they all subscribe for a model, which moves away from the project. People talk about products over projects or team over projects. The fundamental idea is we move away from this idea that a project is a temporary entity. We have standing teams, standing products, and the default position is that these things will continue and continue and continue. So we no longer disband teams. So we're not setting OKRs and objectives and then deciding which teams are going to fulfill them. We have these teams and we say to the teams, here's where we want to go to. You know what your team does. You know, what your product or your services, how can you as a team further this organization's mission and goals and purpose. How can you contribute to this? And it's for the teams to come back with OKRs. So if you like, the OKRs are coming from the bottom up.

Now this shouldn't be just the bottom telling the top how they're going to do things. That's as bad as the top telling the bottom, how to do things. This should be a cooperative exercise. This is collaboration to achieve some outcomes. But it is largely the teams that are deciding what their OKRs are and the teams should be looking at what their speciality is. What their products are, what their services are. Their specialists in the team. Be their product managers, product owners, business owners, whoever, are thinking about what the customers want. They're listening to what the senior leaders are saying are the goals. And you're crafting OKRs with respect to all of this information, not with respect to your backlog and what you thought you might do six months ago. But respect to how you confer the business goals, the business mission, and satisfy your customers and honor your own product.

And so the teams come back and the teams propose their OKRs. And in proposing them, I said, there's some negotiation. They review them. They get feedback because actually I love feedback. So let's get feedback off our stakeholders. In proposing the team is in effect creating their own API. They're saying organization, this is what you can expect from us this quarter. And that itself is a form of test first management. The team are saying, these are the outcomes we are going to try and deliver. And here are key results and key results effectively form our acceptance criteria. This is test first management. We are sitting down at the beginning of the quarter or whatever your period is, thinking long and hard you are publishing your API in a standardized format called objectives and key results. 

And you can read other teams, standardized formats, and you can compare and you can give feedback. And in defining this, the team is defining their own space because those OKRs place boundaries on what the team is going to do and what the team is not going to do this quarter. And within those boundaries, the team has made its own space. Now the team does what the team needs to do to meet those OKRs and add benefits. So it's a team-driven process and it's more bottom up than top down. And that I see as very empowering.

Jenny (27:18): How do we make sure to avoid the set and forget type thing that happens sometimes within organizations that do OKRs? They say it and they're like, okay, we spend all this time setting it. And then people do a bunch of work mid-quarter. They get to the end. They're like, oh my gosh, we have to update our OKRs before quarter-end checkout. And we have to reset again. At what point, or what kind of practices have you seen where OKRs are blended in with sprints or blended in with some of the practices that we know are kind of the building blocks of agile methods.

Allan (27:55): So it's really quite simple, particularly when you remove the backlog. Every time you need to decide what you're doing next, you go back to your OKRs. So in scrum, that's obviously your sprint planning meeting. I'm happy for you to walk into your sprint planning meeting under no preparation whatsoever. You look at your OKRs. You say, where are these OKRs, which OKR or OKRs are we going to focus on in this sprint? What do we need to do to move that forward? You write out your tickets, your stories, whatever you call them, and then you get on and do it. In (28:34 inaudible), it's not that different. It's the replenishment meeting or perhaps it's whenever a slot comes free, you go back to the OKRs.

Now that's the basic model. You may want to adjust it. You may want to say at the beginning, we'll think long and hard about this and we'll write a three-month backlog and then we'll keep going back to the backlog. You may want to do some kind of pre-planning, refinement meeting to flush things. I don't care what you do, but basically the work that goes into your sprint, the work that goes on or board should be coming directly from your OKRs. You should be able to look at anything you're doing and say, this story contributes to that OKR. I know people talk about the mid-quarter checking. I'm going back to the old XP principle, 10 up to 10, every sprint, every time you need to decide what to do next, you go back to your OKRs and say, which OKR are we focusing on, what do we need to do to move it forward?

Jenny (29:35): In the same way then, we also at the end of a period or at the end of anything, we do these retrospective meetings, where we're evaluating what we did well, arguably what we didn't do well, what we should have done but didn't do. There's a myriad of ways to do this. When you are talking with your teams through the, let's say reflect and reset period of OKRs and end of quarter closeout. How do you coach these teams to think through it so that they can be effective in doing the test, iterate, learn stuff, and also taking all that stuff and folding, or pushing it forward?

Allan (30:22): I'm not sure I have any magic silver bullets there. I think, on the one hand I resist seeing the, the quarter, the 13 week cycle as a super sprint. On another level, it is a super sprint. And I think it's many of the traditional retrospective style techniques. So say, let's go back and let's talk about what we've been doing. Let's talk about how we can improve the OKRs, where we've hit, what do we do right there? The OKRs we missed, what do we do? Not necessarily wrong there, but why didn't we hit them because there's legitimate reasons for not hitting OKRs. Most teams, if you're following a scrum, you're going to be doing a two week iteration everywhere anyway. It makes logical sense at the end of an OKR cycle, you stop and you reflect about the whole period and you reflect about your setting of your OKRs, how you did it, you reflect about what happened, how you handle it and you come up with improvements next time.

And perhaps there's no silver bullets there because A, most of their retrospective techniques are the same. And B retrospectives are almost, I often think of them as they are about 1% change. If out of any given retrospective, you can make team 1% better. And I don't think that's a very ambitious goal. I think that that should be achievable. If you can make your team 1% better, every retrospective then that's 25% percent over a year, factor in compound interest rate. You're probably up over 30% now. What do they call it? The growth of small gains. So no real silver bullets there. It's retrospectives, it's working with teams, usual agile coaching style behaviors, particularly working with product owners, scrum masters if you've got them. But product owners, especially because they are key people because they're the people on the team who are tasked, not with writing Java or JavaScript or testing. They're tasked with understanding what the customers and stakeholders need, value and want. So they're really in this process.

Jenny (32:46): To this end, you made a controversial statement to me and I was taken aback. I'll be honest, you said, I don't really care if we make progress on our key results. And you stated something else, that this is what our team should care about. Can you talk about this? Because I thought this is really interesting. Once you have something that goes into the world, that has inertia, you mentioned, it has momentum. And something we need to be mindful of, is that it's difficult to kill things. So we should be very thoughtful about what we're going to build and what we're going to release, because we're going to have to debug it, maintain it, maybe even expound upon it later. What is that thing that you do care about if you don't care about making progress on key results?

Allan (33:36): I care about delivering benefit and I'm using the word benefit here, not value. They're largely synonymous, but when you say value, people see a dollar sign and you think the world we're living in the moment, the benefit of Astra Zeneca or Pfizer or something else, there is a dollar value to it, but there's something much more important, which benefit there. So what I ask is that your team is delivering benefit. And if at the end of the quarter, you can look back and say, look, we missed every one of our OKRs, but we delivered a shared load of benefit. We really did stuff that has made people's lives better, then I will defend you. I think OKRs, one way of writing OKRs is to write them as hypothesis. And that's a really clever way of writing an OKRs.

We will test the assumption that blah, blah, blah, because rather than achieving the thing itself, you've made the test, the objective. And so whether the thing you do works or doesn't work. The fact that you ran the test means you can tick it as achieved. But whether you write an OKR as a hypothesis or not. Every OKR is a type of hypothesis, you are hypothesizing about this limited number of things that you've written down will benefit your organization and your stakeholders. And if part way through that quarter, that cycle, you realize that these will not add value. There's no point in continuing. To borrow scrum term, you might call it abnormal termination of OKRs. Similarly, you might learn something that causes you to see something even more valuable, and you might redirect yourself or unfortunately I had seen this one happen often, the house starts to burn down and you have to run away and put some fires out. And if you hadn't those fires out, then you'd have lost some of benefit.

One of the problem with OKRs is people want to see new shiny things. And quite often what you need to pay attention to is the shiny things you built six months ago. And it's not so much about new revenue. It's about revenue protection. It's about risk reduction. So if you are part way through the OKR cycle and you realize that you've got a problem over here, then it would be negligent to pursue your OKRs and ignore that thing. Now at this time, it's also irresponsible to divert from your OKRs every time something unexpected happens. You need this rod of OKRs up your back. But you are allowed to move away from it. And that balance is hard to achieve. What I ask is at the end of the quarter, when you're looking back, that you can justify your actions and say, we did the right thing, we added benefit in the right way.

And to that end, I don't care whether you hit 70%, 100% or 0% to your OKRs. If you added benefit. Now, couple with that, the fact that if you do have a hard and fast number to hit in your OKRs, you're going to get unintended consequences as people pursue that target and adjust their behaviors, either in OKR setting or during the quarter, which means they will hit their target as expected, but they will also miss by a country mile, actually delivering real benefit. So when it comes to judging a success of your OKR cycle, I actually want to step away from just ticking and crossing OKRs. That's a useful exercise and it's useful for retrospectives and it's useful for reflection and feedback. But the ultimate success or failure thing, isn't how many OKRs you hit. It's what did you achieve?

Jenny (37:53): Do you have an example for our people to hear about maybe a scenario where the team did not make a lick of progress or they made marginal progress at least numerically, but it was very clear that they delivered the benefit to the customer, to the business. If there's one you can share, just so that we can put context or color around this, because I think this is probably a difficult concept without an example, to be able to accept.

Allan (38:23) : The one that springs to mind was an upgrade we had to do. So we had an existing system, we had some OKRs. One of the component, because all softwares are full of open source libraries these days. And one of the libraries come out of date and one could argue that it should have been updated before, but it hadn't been. And if I'm being honest, it turned into a bit of a death march. And because it was absorbing so much of our capacity, we missed other OKRs by loads. But at the end of the day, we got it over the line. And when we were questioned about it, some body pointed out that this library we had been upgrading had actually been responsible for a major security breach a year ago. I forget, was it target in the US or one of those big retailers had suffered security breaches because they were using this version of a library. 

Yeah. Arguably we should have bloody well, upgraded it sooner, but it hadn't been. We got into that position. Now it turned out to be far more effort than anyone imagined it went on. It blew all the stuff out of the water, but it would've been irresponsible to leave our system with a great big security hole. Almost with a sign saying, hack me here.

Jenny (39:52): Oh goodness. Yes. And with all of the CSOs and cybersecurity folks probably listening in they're like, yes, of course you would want to address that before you hit your OKRs, if they weren't a part of them. 

Allan (40:05): And people like that and to you and me that was really obvious isn't it?

Jenny (40:10): Super obvious. 

Allan (40:11): But it can be incredibly difficult for people further up the food chain to understand. And like, first of all, you have to get past that. Well, why didn't you fix it six months ago, problem. But then also you got to say, well, it is what it is. We are where we are, we could build you the shiny thing you're after, but let's just run over these consequences. So one of the things I say in the book is make the benefit of your OKRs blindingly obvious because there are people who look at your OKRs and they don't know half of what you look at. And if the benefit is not obvious, if it can't be communicated to the simple mind CEO, then you're going to have to defend you OKR.

Jenny (41:03): Allan I think there's so many nuggets here that hopefully our listeners are going to benefit because I think you've demystify some of, hopefully a lot of things that agile teams are really struggling with now that they probably had a similar mandate from above that said, thou shalt do OKRs. And they're looking at themselves and each other, like, okay, now what? So thank you so much for that. We're going to go into some quick fire questions if that's all good with you. The first is well, what's your dream with the deadline?

Allan (41:37): I know you asked people this, so I've been thinking about it and I have some very grandiose dreams. I think the one I share with the other 7 billion people on the planet is for COVID to be over. And I'm going to say, please, I'm going to beg not to have a deadline on this because we want to do it right. We're speaking just as we might be heading back into in. So we got to get right. So grandiose dreams, I have some very mundane dreams about my family. We need to do some work on the house this coming year. And I hope we time it well with the school holidays, but actually those middle level dreams, I've had a fantastic successful career. And if I look at my bucket list or bucket lists, I've written over the years, I've achieved most of the things I want to do. I have some grand dreams. I have some mundane dreams, but those ones in the middle, like (42:39 inaudible) deadlines are a bit short to the moment. 

Jenny (42:43): I understand that. Well, you've mentioned that you've spent many a year now, 10 years as one of the founders for agile on the beach, which hopefully maybe in the new year, you all will be able to hold in person and that would be glorious. What have you really appreciated about this particular event and the people that get to come and experience it?

Allan (43:08): What do I appreciate most about agile on the beach? It's a really relaxed atmosphere and I have one of those lessons I've learned again, is that people learn best when they're relaxed. And I've had some fantastic conversations over beer on the beach. I've done some serious learning.

Jenny (43:35): So it really is just, I remember I was talking to a mentor of mine a long time ago, and he would say, a change of place and a change of pace equals a change in perspective.

Allan (43:45): Right, yes, years ago I started saying to myself go and stand somewhere different. That was the motivating factor why I went to California for a couple years. I thought I've got to go and stand and view this industry from somewhere else. So I moved over to California.

Jenny (44:03): Well, I mean, you are where the heart of where this whole thing is so that's really cool. Last question. For those who, and you shared a lot of just knowledge about your experience with OKRs in a very candid way, I appreciate that. For those who are starting out, or those who are trying again because maybe they have failed at trying to implement this in their organization, but they're trying, what would you you give is like your piece of advice for them as they're approaching this, what would you tell them? Or what wisdom would you want to impart based on your experiences with your clients and teams that you've worked with who've gone through this?

Allan (44:50): So there are two parts of this. When you add something, whether it be agile or OKRs or anything else, you have to also take something else away. You also have to unlearn. And some of the things that brought you success in the past, you need to let go of, and if you simply do what you were doing before, and you add agile, you simply add OKRs, you've got all the overhead and admin and everything else that you had before. Plus you've got this new thing and you've got the overhead of making the two of them work together. So you've got this idea to give something up. You're going to add OKRs possibly at the same time as agile, or perhaps you've already added agile. You need to make all work subservient to those OKRs and you need to let go of all the other things that are driving your work. Those are the things you might want to incorporate them as OKRs in their own. Incorporate them when you're setting your OKRs. If you've got a (46:02 inaudible) chart with dates you need to make, write that into your OKRs. Do not have two or three parallel management systems of which OKRs are one that you are running. Make OKRs it, revisit them every sprint.

Jenny (46:22): Sound advice. Basically what you're saying is try not to have a divided mind because that sounds horrific. Yeah because as you put it, OKRs are a way of thinking through what decisions, what you're going to prioritize and why. 

Allan (46:37): Some of the problems you'll see when you do agile and OKRs as well is the process is reflecting back to you things you need to change. And when you have those difficulties, it's not a problem with agile or problem with OKRs, it's a problem you need to address. And there may be an agile or an OKR way of addressing it, but you need to work out how you're going to address this problem rather than just adding more to it.

Jenny (47:08): Or chucking it all together. This has been a fantastic conversation. I've had such fun just learning from you. Can you tell the folks about your book really quickly, we'll close out with that so they can go pick up a copy?

Allan (47:23): Okay. So the book is called succeeding with OKRs in agile. It's available from all good bookstores, including that one in Seattle. And it's just under 200 pages. Somebody commented shortly after I published it that they'd read it in two and a half hours. I said to my wife, I am so disappointed, that book is taken over a year to put it together. And she said, no, you need to see it as a compliment, you've written a readable book. So I don't thinks it's very expensively priced. I just encourage you to get a copy and have a read, and if you have any questions, please email me.

Jenny (48:04): Sounds great. Looking forward to hearing people chatting about this book online. Thanks so much, Allan, for your time. It's been a joy having you on the show. 

Allan (48:11): I too. 

Outro: That's it for this episode of Dreams with Deadlines. Thanks for listening. If you like today's episode, please subscribe and share. Show notes can be found on quantive.com/radio. If you want to learn more about our product and services, head out to quantive.com. If you have questions that you'd like answered on the show, shoot us an email at radio@quantive.com. Tune in next time.