Allan Kelly has been an Agile guide on the cutting edge for years now. His latest work focuses on OKRs, In particular, how you reconcile OKRs with the values of Agile. 

Listen to the episode to hear:

• Why it’s a good idea to throw away or ignore your product backlog (and what to do instead)
• Why OKRs give teams autonomy and enable self-management, releasing senior executives from getting bogged down in the detail
• How to make business sense of overwhelming lists of feature ideas or tasks
• Why achieving 100% of your objectives can actually be a bad idea

About Allan Kelly

Allan is best known for… his 2012 essay Dear Customer: the truth about IT … identifying diseconomies of scale in software development … founding the #NoProject movement … creating Retrospective Dialogue Sheets … the hybrid Xanpan method … organizing the Agile on the Beach conference … value poker in the Dragon’s Den, and a few books including: Business Patterns, Little Book of Requirements and User Stories, and the twins, Project Myopia and Continuous Digital.

• Allan’s website
• Allan on Twitter
• Allan on LinkedIn
• Agile OKRs on amazon

Transcript

[00:00:00.085] 
If your CEO tended to every planning meeting, that might be cool in a five person startup but a 5000 person organization, if the CEO is going to every planning meeting, forget about his time. Scheduling finds just micromanagement, isn’t it, to see if a team is really going to have their own power, their own freedom to make their own choices if a team is going to get I mean, it was expressed most of their own destiny. If a team is truly going to be able to say this is what we’re going to do, the product is truly going to have the power to say, our customers want this, I’m going to deliver this.

[00:00:40.135] 
And they’re not constantly second guessing what the CEO wants or they’re not constantly checking with the higher ups that they want, what they’re after. If a team is going to have that autonomy. Then how are you going to reconcile that you don’t want the higher ups be connected, you actually want them to see you as a black box?

[00:01:00.165] 
So I know it’s frustrating, but there’s a good side to that. And it seems to me that, OK, OCA’s feel about the right level. You are listening to the online remotely podcast, the show dedicated to helping lead distributed teams under difficult circumstances. I’m the host Luke Show and I’ve participated in a run distributed teams for almost a decade as a practitioner. I’m speaking with experts on leadership, strategic alignment and a lot more to help you navigate the issues start facing after you get.

[00:01:44.695] 
Welcome, welcome, welcome. This is Lou again with the line remotely up, know the management teams podcast. I am considering rebranding the podcast, so just in case you do see slightly different visuals or a different name, if you are looking to listen to it for your own benefit or to share it with someone.

[00:02:07.975] 
Be aware that there might be a different name. So today we’re speaking with Alan Kelly. Now, Alan is a good friend of mine. Now, Alan Kelly has been on the cutting edge of Agile for quite a while. I think he was one of the main popularizers behind the idea of moving away from projects and it towards products with the No Projects movement at the moment. He’s primarily focused on objectives and key results and in particular reconciling OK, ours as they’ve been applied with agile in a way that makes sense.

[00:02:46.825] 
So on today’s episode, you will hear why it’s a good idea to throw away or ignore your product backlog and what to do instead, why? OK, give team autonomy and enable self-management, releasing senior executives from getting bogged down in detail on how to make business sense of overwhelming lists of feature ideas or tasks, and also why achieving one hundred percent of your objectives can actually be an empty pattern or a bad idea for your company. So without further ado, let’s dig into the show, Ellen Kelly, welcome to the podcast.

[00:03:29.865] 
Thank you for having me. Looking forward to this.

[00:03:31.755] 
Tell us a little bit about your background with OK, here’s how you got into the topic.

[00:03:39.285] 
I call myself an actual guide mobile home, an actual couch. I decided a while ago that I do more than just coaching. I kind of more can’t help direct people. So about 18 months ago, I was I was working with a company, a large financial institution, almost certainly not the one you’re thinking of, but one you have heard of. And I was helping the other teams get agile, you know, to do this. We suddenly had this additional thing and it was OK.

[00:04:12.555] 
And I think the senior team at this financial institution were were being guided by rather expensive consultancy, shall we say. And suddenly we were told that we were to adopt. OK, and it was a bit like you remember the old Dilbert cartoon where Dilbert goes into the manager’s office and the manager says, I want you to do agile programming. And there was as if we’re going to do agile programming, we need training, we need materials. We needed all the rest of it.

[00:04:39.855] 
And the manager says that was your training and it kind of felt a bit like that. And without doing OK was as an agile person who’s been around for a few years, myself and the other agile coaches, we all kind of knew a better OK, was that knocking around? For a few years now, people have been talking about them on and off in agile circles. So we kind of new objectives and key results. The thing you want to do and some of the milestones, big bits that you need to build for that.

[00:05:10.995] 
So we kind of knew that. But that was like a deep his own knowledge did went. So we all rushed out and we bought the John Doe book, OK, measure what matters and we start reading blogs. You know, we all start trying to get with it. I will admit. I was quite skeptical. I’m very wary of numeric targets, and I some of your listeners may come across a thing called Goodhart Law Goodhart Laws from Charles Goodhart, who was a professor at the London School of Economics.

[00:05:44.375] 
And he was a really serious economist. He’s retired now and he coined I think it’s now called Goodhart Law, which is. Anita, listicle measurement when used as a target will change its behavior and he was talking economic sense, particularly about inflation, but it had been seen in other social sciences that this happens and we can see it in software as the best example is Vosta points. If you’ve got a team that is measuring that capacity and story points and they measure the velocity every iteration, and you then introduce a manager who says, come on, team, let’s see if we can get extra 20 points.

[00:06:24.865] 
Sprint. Yeah, let’s get more points to a score high. Let’s do Paula. You will find before long that your numbers are going up, your numbers are going up in a straight line. You are not actually producing any more, but you are scoring more points, which, for those of you in economics mind, you will recognize this is called inflation. I have seen a few teams value that the teams come under pressure to score more points and consciously or subconsciously, their estimates go up.

[00:06:59.795] 
And anyway, I was well versed in these kind of ideas and it is a couple of good books on the danger of targets. And so I was really skeptical about, OK, but you know what? I start working with them. I worked. They worked well, they they really put a good focused team, they improve communication with the rest of the company, they gave us an opportunity to step back once in a while and some bigger questions and really to question that.

[00:07:31.685] 
Is it backlog, backlog, backlog? You know, before that, it just seemed to be burning down the backlog, which nobody ever gets a burned out backlog and, you know, reacting to what customers want. And there’s always a difficult question, you know, should you be doing what you plan to do or should you be reacting to the customers and this problem doesn’t go away with OK, also, if anything becomes more obvious, but it’s a problem to talk about because there’s value in firefighting if the fire over here has value in putting the fire out, you know, but if all you ever do is fight fires, all you’ll ever be is a firefighter.

[00:08:07.725] 
And while fighting fires is a respectable profession, not everyone can or should be a firefighter and work with. OK, we start to see these issues. And I started the answer, OK, I really like test first management. It’s like writing down what you want to achieve and how you can test for it and. Another one of my fears was, ah, OK, just a reinvention of management by objectives, where somebody at the top of the organization says, this is what I want you to do.

[00:08:40.635] 
And these things cascade down the organization. I start to realize that if you use them correctly. OK, I was running the opposite direction. They cascade up the organization and I found they worked. I had to go and eat my hat. And so I started to write some notes on how I’ve been using OK and what I found and how I recommended you use them. And then lockdown happened. And of course, we all need to do in lock down.

[00:09:10.935] 
And these few notes blossomed into what now looks like a book.

[00:09:17.585] 
I’ve had that experience, too. So now we can just throw away the backlog.

[00:09:23.385] 
That would be my advice. OK, I’m expecting this to be the most controversial part of my take on. OK, as I’ve noticed in a while, I’ve been putting the book together before then when I was working OK, and while putting the book together, I’ve made a point of trying to read some other authors and particularly blogs and people’s experience tales. And there’s a few places where I think I might disagree with more common wisdom generally with my other books.

[00:09:53.925] 
Won’t be surprised to hear me say that’s one of my big takeaways, is throw away the backlog. And I’ll tell you, this was an actual experiment. When I was working with O’Collins, I started to realize that the OCC was saying, do one thing and we’ve got this backlog over here of a bunch of things to do. And I’ve been preaching for years that stories in a backlog should be small. And he the objectives, big things. How do you marry the two of them together?

[00:10:25.125] 
When you look at it as two approaches, you either say, as many teams do with a spring goal. By the way, you either look at a backlog, decide what you want to do, and then you craft a spring goal in this case, an OK all around it and effect the OK. I’ll just codifies what you’re going to do anyway. But yeah, yeah, it was something bigger in advance. We should talk about the cadence of, OK, here’s the three month cycle as opposed to the spin cycle.

[00:10:50.505] 
But OK, I was working a three month cycle. One way is how this kind of gaze into your crystal ball of the backlog you think you’re going to do for three months and then you crafton OK are to explain that the other way is to say, let’s step back. Put the backlog to one side. Let’s think about what we’re really trying to achieve here. Let’s think about our mission or goal or strategy, what our customers ask, what whatever the inputs are that you are, you are taking in Aleksic.

[00:11:25.415] 
What are our big objectives here? What are our big goals? Codify them in accounts. And then when you start executing within the quarter, you come to the OK and you say, right, here’s the objective. Here’s the key result we’re going to aim for this week, the sprint. Well, what do we need to do to move from where we are now towards that key result in that objective? If there is something in the backlog that can contribute to this, then by all means, let’s take out the backlog and let’s use it.

[00:11:57.755] 
But just because something isn’t in the backlog, if this is your priority, one objective, this is your priority, one key result, if this is the thing you’re going to be working on, then just not in the backlog, why would you not do it? Because it takes like a minute to write me a stick into the backlog if you if you want to be correct about this. But the thing about stepping back and thinking about what are the outcomes you want, what are the bigger goals, the strategies, the more meaty things, and how can we move from here to there and the backlog?

[00:12:35.045] 
Secondly, as I say, I’d almost get the third away. I’ve struggled with this, too, I kind of always saw the backlog as this big sunk cost aggregator and especially of all the effort of pruning it and keeping it pretty and complete. And then when you actually were trying to do business planning, it was very difficult to do it from the perspective of your backlog because it would always dictate what to do rather than come at it from a business perspective.

[00:13:07.105] 
You know, in the early days of agile, the backlog was a wonderful idea. The backlog was the things we were going to do. But we are now 10, 20 years into that journey and we have invented some wonderful electronic tracking tools. And those tools have turned into a bottomless pit that we can keep putting stuff in the backlog and in the backlog and in the backlog. And no team ever burns down that backlog. No team ever empties the backlog.

[00:13:41.695] 
And if you do, you’re doing wrong anyway. And what was a great, great benefit in the early days is now it doesn’t scale. Twenty years later, we see that it doesn’t scale. It’s fine when you’re starting out. It’s finally new to all this stuff when you’ve got two thousand stories in and you’re arguing over what an epic and what’s the story and and what’s the top of this thing and what’s the bottom of this thing?

[00:14:09.265] 
Subtask. Yeah. And now we can’t see the wood for the trees were lost in all this detail. And absolutely in a sprint, you want a team that’s delivering lots and lots of really small pieces, lots and lots of really small stories and value. But we need that bigger picture thing. And Sprinkel was kind of it for a while, but sprinkled never really worked out, I think, because Jeff and Ken thought it would. I think one of the things about, OK, ours is, is they give us a middle level planning tool, the stories in the spring to really good for the day to day detail and making sure we get something delivered and longer term processes, whether you call them road maps, visions, business plans, what we would call a whole bunch of tools there.

[00:14:57.955] 
Which product owners, MBAs are the masters of? What we’ve been lacking is something in the middle. We used to have released plans and people come with a release plan. They’ve looked a few months into the future. But now the teams release like 10 times a day with continuous delivery. You release poneys use, OK, fill this middle ground. It’s something more meaningful than a sprint worth of work, but isn’t looking so far into the future as to be too remote from today.

[00:15:30.475] 
Today? Yeah, my sense is with Sprint’s is that they even though you can get a piece of work done, like one or a couple of features, it’s and and, you know, and you can demo it at the end of it, it’s often not enough, in my experience, particularly with a bigger project, for it to be a meaningful, from a business perspective, a set of features and. Yeah, yeah. And I think it’s more at that level that the sprints are useful, but it still feels a bit more back endian.

[00:16:01.885] 
I hate to say these words because they are so cliched, but it’s this big picture thing. And I said nebulous words, and everyone uses them without thinking, and often it’s worth asking what what you mean by bigger. But this idea that you’ve got some purpose, some mission, something else, you’re not just a story machine, that stories go in and software comes out. I want you to be a story machine. But in terms of framing the team’s reason for existence and understanding where they add value, because it’s so easy to get lost in this story machine, where you going to spent planning?

[00:16:46.965] 
You pick up a bunch of stories, you pick up a bunch of customer asks, you get really good at churning them out and delivering them, surely. And everyone sees a value from those little bits you’re adding, but you’re going back whatever fire-fighting before. If that’s all you have to do, that’s all you’ll ever be. Do you that episode of The Simpsons where Homer designed the car. There’s an episode where Homer guesses Honokaa, so it gives it like 16 cup holders and he gives you a reclining booth and he’s got all these features in those cool features on their own.

[00:17:18.855] 
You put them into one call. It’s like a four wheel drive, sports car kind of thing. And there’s no cohesion there, you know, it’s a bit like iTunes, really, you know, iTunes, there’s there’s no cohesion. There’s no meaning. You OK to call it that? You’ve made to be. But, you know, subtle little things. And I think that’s sometimes lacking in the software creation. And again, we can get lost in our own success.

[00:17:47.325] 
Yeah. Yeah.

[00:17:48.255] 
I think the other thing that I have seen is quite a struggle sometimes is that if at the story level, people higher up just don’t have the time to get into that level of detail when talking with teams. Yeah. And it’s just difficult for them to make all of those connections the same way the team does. So I think that is probably another thing. That’s a really good point.

[00:18:17.295] 
And you’re dead on. I mean, how many times does a team say the higher ups don’t understand this, they don’t get this, they’re not going. And I totally feel that pain. But at the same time, I don’t want the higher ups getting involved in detail. Would you like if your CEO tended to every planning meeting that might be cool in a five person startup, but a 5000 person organization? If the CEO is going to every planning meeting, forget about his time scheduling things.

[00:18:48.615] 
Just micromanagement, isn’t it, to see if a team is really going to have their own power, their own freedom to make their own choices. If a team is going to get the expression master their own destiny, if a team is truly going to be able to say this is what we’re going to do, the product is truly going to have the power to say, our customers want this, I’m going to deliver this. And they’re not constantly second guessing what the CEO wants or they’re not constantly checking with the higher ups that they want, what they’re after, if a team is going to have that autonomy.

[00:19:24.825] 
Then how are you going to reconcile that you don’t want the higher ups to be connected, you actually want them to see you as a black box? So I know it’s frustrating. But there’s a good side to that, and it seems to me that, OK, ours feel about the right level, they’re the team able to say every quarter we step back. And essentially the simple way to explain it was simple thing to aim for is a quarter, 13 weeks, OK, four quarters, 52 weeks in a quarter’s 13 weeks, 12 weeks, six sprints.

[00:20:02.705] 
Most teams of just delivering stuff on one week of stopping, stepping back, reviewing what you’ve achieved in the last quarter to a quarterly retrospective review, OK. Those books are off. And some time to think about next quarter to get out of the detail, to think broadly. And absolutely, this should be led by your product owner, product manager, whoever, whoever’s wearing that. What does the customer want? What does the customer value hat? And they have the skills experience that specifically they should lead the conversation.

[00:20:36.575] 
But it’s a team decision. So what are they going to do? What are they going to be the objectives? What they’re going to be the key results. You then see the other managers around you that the CEO, the CFO, God knows who they are, stakeholders in that team. They honestly telling them what to do. They are setting the overall the ultimate goals. They are painting bigger picture, the vision, whatever we want to call it.

[00:21:01.475] 
But the team able to say, hey, this is what you’ve articulated as the ultimate objective for this organization. We as a team with the input of our product owner who’s been talking to customers and with what we can see is happening technologically, this is what we see is our objectives for the next quarter. And they can play that back to the senior managers and the senior managers can comment on it. But will we move the senior people from those day to day conversations, even the sprint level conversations?

[00:21:34.265] 
And once those senior people say, OK, those OK, good, I can see why they make sense to this company, then in effect, they’re saying, right, team, we trust you, get on and do it. We aren’t going to bother. We might check in half way through, but really we’re not going to bother you. Get on and do it at the end of the quarter. Come back to us. We’ll talk about how you did.

[00:21:57.155] 
We’ll talk about what’s coming next. But if a team are going to have autonomy, if a team is really going to be self organizing itself, managing you, you don’t want senior people showing up every five minutes. And I think, OK, I can facilitate that. Yeah, that makes sense, the thing that’s kind of playing in my head is the power struggle between the team, which wants to define their own objectives versus the, let’s say, long term planning done by senior executives who then want to control everything around them to make sure that things go in that in that direction that they expect it is not about control or is it really about value?

[00:22:39.085] 
Is it really about the customers do a mental exercise in a mental experiment? Everybody has a boss. And ultimately your boss is the customer, the person who part with their money or doesn’t part with their money. And if the senior people are thinking we want to grow this business, what will our customers part with money for in the future? How can we satisfy our customers?

[00:23:03.005] 
Then what they are saying should be the same as what the product owners and the teams are seeing at the ground level, and if they’re not, then either there’s a breakdown in communication. One side or the other isn’t explaining that they actually got the same direction, the same thing to some explaining or perhaps there may be more value here. They are seeing different sides of the same coin. They’re seeing different aspects of what the customer wants. Maybe they’re looking at different customers as if there’s a friction between what the the higher ups want and what the teams on the ground want to explore and understand.

[00:23:42.795] 
Because this is a special value there, and so actually, I think, again, OK, because, OK, ours should be a common language between the senior team and the delivery team. OK, all should be facilitating that. There shouldn’t be a friction there. I know this shouldn’t and always is. And some of that friction is natural. Mm hmm. Because people have different takes on things. But what we want to do is we want to find a harmonious way through this.

[00:24:12.775] 
Well defined objectives everybody’s happy with, I guess, yes. Yeah, so this is why I say, you know, I think of organizations that I don’t think of the hierarchical chart with one person at the top and you layer Lailah down. I think the more like imagine the solar system and the person at the center of the sun is probably the CEO or maybe the CTO is person somebody important. But the sun doesn’t control the orbits of the planet, that they go around on their own trajectories.

[00:24:45.265] 
That’s their own stuff going on. And each one of these teams, a planet going around the CEO and some of those planets have moons. Some of those teams work with other teams and there’s moons floating around with them as well. And sometimes you’ve got some combination. You may have two or three teams over here who work together and they need to coordinate more. You may have a team over there which is also orbiting the same CEO, but they’ve got very different aims, objectives.

[00:25:13.355] 
They’re doing something very different just to get into the key results a little bit. So we’ve got the objective, which is the top level, let’s say, goal for a given person or team, and then each of those objectives you figure out. A handful of key results, which you think will help you achieve that objective. So. One of the things that I’m always curious about is what if you achieve the key results but the objective isn’t achieved?

[00:25:40.535] 
How do you articulate key results in a way that they actually you’re actually quite sure that they will help you achieve the objective?

[00:25:48.605] 
You know, I increasingly see them all as hypotheses, theories. We have this objective. We are objective is to make the customer happy. Our objective is to use a car that goes twice as many miles per gallon. And those key results, often times they’re just hypothesis. We think if we create a better design for wheels, we will improve car engine efficiency. We can prove 20 percent of efficiency by biofuels. And so those key results are things we are going to try and do in order to meet the objective.

[00:26:28.025] 
Sometimes there may be more concrete. There may be actual bits to build. Other times I say the hypothesis, the things we’re going to try and do, we are going to experiment with a new design of wheel to see if we can improve car performance. You can decide in your own results how you phrase the results because you you want to achieve your results. But if you phrase your key result as a hypothesis. Key result, one is we will experiment with a new design attire, which we hope to improve fuel efficiency by 20 percent.

[00:27:04.595] 
Now, whether you improve fuel efficiency by 20 percent or not is not ultimately the key result. The key result is doing the experiment. Now, when you are planning, you may have the expectation that achieving that key result will move you towards your objective. But it’s possible you do the experiment. You should kill the key result. And actually it doesn’t contribute to objective. You aren’t aiming for 100 percent compliance with your objectives and key results. We will all want to score points and we all want to get one percent of all school and 100 percent as a top mark.

[00:27:43.565] 
And that shows we’re doing good. The problem is, and this is one of my original fears, though, is that. People will aim lower. Economists call such as fighting instead of aiming to double the fuel economy of a car they’ll say will improve at 10 percent because people are confident that they can do that. Set a lower target. They’ll meet the target. And really, if you try to do something much higher, you may not have got the high objective, but you’ve done better.

[00:28:16.305] 
And if you aim low, it’s the old quote you said be to Aristotle of a problem is not that we aim high and miss, but we aim low and we hit it so common to hear people talk about you’re only aiming to achieve 70 percent of your OK. I think that’s Tigo, which comes from Intel or Google. Sort of the first thing for your organization to do is to articulate what percentage of OK are you aiming at? Now, there’s a slight problem here in the same way that people could aim for 100, a set very safe target to be 100 percent.

[00:28:51.235] 
You can with a bit more sophisticated gameplay, make sure you get 70 as it is the most sophisticated game.

[00:29:00.445] 
But you almost just say, look, let’s just accept on face value, we’re going to try and do this stuff we’re trying to do our best will aim high, will stretch ourselves, but we will we’ve got wiggle room if things don’t go right. We don’t have to hand 100 percent, so I think ultimately the way to judge the success of OK, Charles is not how many accounts are you hitting? It’s not even always making life better for the customer.

[00:29:34.635] 
It’s a question of how much better are we making things? Are we making a difference? Can we see actual benefits for the organization, for the customers, for the stakeholders and.

[00:29:48.705] 
Whether we’re hitting them or not, are we happy that we are achieving as much as we could? So where do people find out more about the book? Right now, the book is in the final stages of writing. I’m just doing some final copyediting, which my hard deadline for that is December the 25th. And so I should be finishing with my changes by Christmas. And in January, it’s going to go to a copyeditor because I will apologize to your readers.

[00:30:21.075] 
Now, I’m dyslexic, so my grandma punctuation, spelling is all over the place. I have a great copyeditor. So Steve will get it for copyediting in January. So you should see the finished product in February. Right now you can buy the book on Pop Limpert dot com slash Agile ocus and you’ll find it and you can buy it for five or six dollars at a moment. And whenever an update comes out, you’ll get that for free when the copycatted is finished and we’ve got that final electronic version that will hit Limpert first of all, then it will appear on Amazon and sometime after that.

[00:31:01.715] 
So probably March time, there’ll be a physical version and an audio version out. So right now, right now, December twenty twenty, look online and in February onwards, you’ll probably find it on Amazon.

[00:31:16.625] 
OK, great. And where else can people connect with you? What are your favorite places to hang out? Well, I hang out on Twitter, but you might get some really insightful comments me on Twitter or you might get me moaning about the government. If you Google Alan Kelly, you usually find me. My website is Alan Peli dot net. You should know I have two L’s and Alan HLL and so I have a blog on the website that gets updated a couple of times a month.

[00:31:43.205] 
I tweet too much on LinkedIn. You can find my LinkedIn. Please join me. The great. Thank you very much. That was really a great show. Ellen shared so many insights, it’s hard to really think of what the biggest one for me was. I think the biggest surprise when I was speaking with Ellen was that Oscar’s aunt used to enforce a formal hierarchy, which is kind of where I was coming from in terms of my understanding of how they work.

[00:32:17.885] 
And I absolutely loved how Ellen flipped it to use Oscars to have productive discussions as almost a boundary or an interface between teams that are out doing things and a senior decision makers in a company which basically allows you to scale much more effectively than you would if you were using traditional agile type of techniques like Scrum. So tune in next week for part two of our discussion with Ellen.

[00:32:56.525] 
And if you have any ideas about topics for the show or for guests that you think would be a good fit, please feel free to reach out to me at contact aligned remotely dot com and then drop me a line and more than happy to hear your thoughts. Catch you next time. Thanks for listening to this episode of the Aligner Remotely podcast, if you enjoy the show, please leave a review on iTunes, Google podcast or wherever you get your podcast.