Welcome to the Agile Book Club podcast, where we hang out and talk shop with the authors whose ideas are shaping the Agile landscape. Here is your host, paul Clip.
Paul:Hello to you kind listeners and thank you so much for tuning in to another episode of the Agile Book Club podcast. I am your host, paul Clip, and we've got a great episode for you today. My guest today is Alan Kelly. I know Alan Kelly as an author and as a competitor. That's not fair to say. We're not really competing.
Paul:He is one of the organizers of the Agile on the Beach conference and I know the Agile on the Beach conference very well because in the early days when I was speaking at many conferences, I was rejected by Agile on the Beach and from that moment on I have held that conference in much higher esteem. It's a fabulous event. Conference organizers in Europe aren't in competition with each other. We're learning from each other and we're supporting each other, and what they're doing out there is fabulous. He is also.
Paul:I also know him as an author of many, many books. His books include titles like business patterns for software developers, project Myopia, continuous Digital, the Art of Agile Product Ownership, books to be Written, which was a very inspiring book for me. It inspired the last book that I wrote myself and what we're going to be talking about today, succeeding with OKRs and Agile. Now, of course, that's not enough to say, because these are the days when SEO has met authorship, and so the full title is Succeeding with OKRs and Agile how to Create and Deliver Objectives and Key Results for Teams. And while this is written for teams, it's certainly a book that would resonate with leaders as well and, as you'll hear him explain, agile coaches as well, who are faced with facilitating the introduction of OKRs with their teams.
Paul:And so let's get right into it, because this is a really nice conversation. I think you're gonna like it. Please meet my guest today, alan Kelly. My first question is there are already a lot of books about OKRs out there. There's some really good books about OKRs out there, so why did Succeeding with OKRs and Agile need to be written?
Allan:Well, for starters, none of those books specifically address Agile and OKRs, or rather they didn't when I was writing a book there's probably other books out there that put the two together but it appeared to me that there were places where some interpretations of OKRs conflicted with Agile, and the most obvious one here is that many people take OKRs and they see OKRs as a return to command and control. And certainly if you base your understanding of OKRs on the early literature and Intel 1970s, where they came from, you know you are going to get that kind of thick feel that OKRs are something that managers give to people. And clearly you know, in the Agile world, where we value self-organization, autonomy, self management and all that good stuff, that's a conflict and so we're trying to put these two things together and they are potentially in conflict. So part of writing the book was to say, okay, there is, there may be a conflict here, but they can work together. And that came from my starting point with OKRs. I knew what they were about, I'd heard about them, like almost all Agile coaches have, but I'd never really used them in anger. And I was coaching with a company Financial Services, as often the case and we came back after Christmas and there was an e-dict in the email from the management on high without shall to use OKRs. No guidance, no information on how to use them, why to use them. And so me and other Agile coaches scratch our heads. We start, we start our own learning journey and you know we'll rush out and buy, buy, measure what matters and so on, and we all start cramming and we start doing with our teams and we learn.
Allan:And so the other reason why I wrote the book was I wrote for myself. I think almost all my books I have written for myself, and I know that sounds mean, but it's for myself in two ways. Often it's in writing a book that I really understand the subject. So by writing a book I come to understand. But also I'm imagining the former me. I'm trying to teach the former me who I was once upon a time, and so the genesis of that book was I'd made notes on how to use OKRs and I wanted, I wanted a book, which I would have had, because when I looked for a book at the time, there was no book that said Agile and OKRs. There's no book that acknowledged my concerns about OKRs, and I wanted that book. So I had some rough notes and then a little thing called lockdown happened and it became my lockdown project. So the book was written for me and, yes, I learned a lot in writing it. But it's also a present to the person I was a few years ago.
Paul:So you describe OKRs in a way that is not in conflict with Agile principles and practices, but are they simply a separate tool or are they complementary to agile practices?
Allan:I think they could be treated like a separate tool. I would rather you didn't do that. I would rather you didn't just add them as something else. You do with everything else and this is one of my complaints about a lot of agile implementations that they take the organization, they take the current processes and they add agile. It's purely additive, and if you do that, you end up with everything everything you're doing before and all the new stuff, and you increase your own workload, your own overhead, and I think you can make the same mistake with OKRs. You can just add OKRs and it's one more tool you have to administer, one more thing you have to set, and I've come across teams who are very frustrated that they're already doing their backlogs, their burn down. They have their product, my all the rest of it, and they've got to do OKRs in addition. So, while you can use them like that, I don't want you to use them like that. I actually want you to go to the other extreme and I want you to make everything about OKRs.
Allan:I want OKRs to be your management paradigm and I think, when you view them through an agile lens, okrs are actually test first management, the same way a developer will write the text they know they want to create something. They will write the tests for the things they want to create and then they aren't finished until they meet the tests and that plays out the unit test level, the acceptance test level, the BDD behavior level. Okrs are test first management. Tell me the outcome you want the team to bring about in three months time. Objective. Now tell me how you're going to measure that outcome. What are your success criteria? And they are acceptance criteria. We call them key results. So I think when you bring in an agile mindset to OKRs, they are test first management and I think that's why they're compatible. But once you've done that, you want to orientate your world around that.
Paul:Well, one of the things that you said as well in the book which resonated with me is the idea that OKRs can fill that middle ground in the planning cycle between the one year and the five year plans, the mission, the vision of the organization and the two week cadence in which teams are running, in order to give not only reasonably long periods of stability in the plans but also some regular intervals for reflecting on and adapting to change inside the year.
Allan:Yes, and I think that's quite important.
Allan:You want to periodically take off your manufacturing, your doing, your delivery hat.
Allan:You want to breathe a sigh of relief, relax, and then you want to think bigger pictures with a cliche, so let's say wider, more generally and you want to connect up with you know the real reason why your organization is here, what your strategy or your mission and to think about both these things every day is is complex and most of us don't do it.
Allan:And you know, sometimes, when we're under the thumb, where customers are shouting at us people want things delivered the temptation is to narrow, narrow, narrow and just get on and deliver, and I want us to stop and step back and think more widely. This also, incidentally, means we're mixing up the roles, because you know, traditionally you might accept a business analyst or product manager type person to be thinking more strategically and thinking about the future, and you're expecting your your code is in your testers to be down in the code, doing it right now. And if we're again to to share this between people on, harness all the brainpower and bring the whole team along, then everybody needs to sometimes switch their perspective and view things differently. So that's why I say yes, let's have a regular cadence, whether it be one week, two weeks, whatever it is, but periodically, I don't mean every year more often, every year, think more broadly.
Paul:You know that fits nicely into a controversial opinion that I've been sharing lately, which is that if agile folks who are so wedded to their, their frameworks are not careful, they're going to be put out of business by product thinkers who are advocating for exactly that for empowering the team and creating empowered product teams yes, I will agree and I'll go one step further that we put our business by our technology, which today means AI, and it's more obvious with AI than it was.
Allan:But if you think about what we're trying to do with defined processes, we're trying to define processes which cover all of angelities, which means we can we can reduce the amount of decisions that are made by the frontline workers. The frontline workers have got a flowchart to follow. So we come up with these more, more prescriptive processes, more detail, and our workers follow them. They get the result. Well, over time, you can start to replace the flowchart and the workers with machines. So ultimately, you know, you end up with a totally automated everything you know, and AI plays into this.
Allan:Now I would argue that actually, what we actually want to value the humans, the things the machine can do yes, we should use a machine for, but we still want humans in the loop to do the machines the things the machines can't. And there are things that humans can do the machines can't do if it's only listening to customers and making customers feel as if they are being heard. You know, I'm sure you can record a customer and play it out into chat, gpt and send a customer a night message, but the moment they realize it they're not going to value it. So, yes, let's have our processes, but we're constantly trying to add more technology in there and I don't think any process can cover every eventuality, and we need humans in the loop.
Paul:Couldn't agree more. You know, I got my start in management in a prison, oh, and I was responsible for running the kitchen crew. So I was the they called it the goodness. What was my job, tell back then food service director? And so I was responsible for running the kitchen and all of my employees were prisoners, who were criminals, who had gotten caught, and so one of the things that is shocking to me, coming from managing those people who were not unclever people, but they weren't engineers by and large, although there were a few chemists, come to think of it, as you can imagine, and really good at logistics too, come to think of it. But in any case, it struck me as just phenomenal when I started working with whole teams of engineers, the idea not to harness that brain power because everyone in the room was smarter than me.
Allan:Yes, and some of this goes back to the outdated management models that the manager knows best, the manager is the expert and the manager instructs people in how to do. You know the old analogy of Henry Ford and all that you put on the wheels, and you put on the wheels every day for the rest of your life. Now, Tim O'Reilly, who people probably know, is from a publishing company. He published an article a few years ago in a management journal and he said today the hard work is done by our systems, specifically by our programs. You know so, yes, there are some workers in the car factory, but a lot of the heavy lifting is done by machine, and when you go shopping, you're probably shopping online and it's a machine that's giving you the options and the machine is taking your payment and the machine is dispatching it.
Allan:And what Tim O'Reilly said is the roles that people used to do are now done by machines. The people who manage the machines are the programmers, and actually the programmers of today are akin to the managers of yesterday who used to manage the shop floor workers and the factory line assembly of people, which I think is brilliant. I absolutely agree with Tim on this. But then you think about the consequences. What this means now is the people we call programmers and testers and analysts.
Allan:They need to understand more about what the company is trying to do, the company's strategy, the company purpose. They need the power to make decisions. There's no point in a programmer saying, oh I need to ask my manager, and the manager and he asked my manager, and going up to hierarchy. That's really inefficient. The management power needs to be with the people with their hands on the keyboard, which are the programmers. This also means that programmers and their related workers need to also view their role as more of a management task, and too often in our world we have managers over here and programmers over here and they seem to be destined to fight. They're just different types of manager.
Paul:Now, that's an idea that I fully intend to explore in a bit more depth with you in the second half of the interview. But let's get back to the book. Yeah, please. You said you wrote the book for yourself and I can certainly appreciate it, but certainly you hoped someone would read it. What kind of a reader did you have in mind?
Allan:I suppose I was extending for myself. I was thinking of that agile coach who comes back from the Christmas break and finds an email in their mailbox that says use OKRs. That was probably the first person as the book developed, and again my whole thinking about the whole team. And I think to set OKRs and to use OKRs effectively you do need to harness the whole team, whatever roles they are. And so those people going back to what I was just saying about management those people need to understand the nature of the beast. You can't just call people into the room and say, right today we're going to set some OKRs.
Allan:The key is always for objective and the key is for key results. Those people need to understand what is there. So the book is also there for the people who suddenly find their agile coach or their manager is leading them through an OKR process and they've been given a copy of Measure what Matters and they look at it and say it's not 1975. I'm not building CPUs, I don't work at Google, I'm not trying to land a man on the moon. So it was very much the average programming team that I had in mind when I was creating it.
Paul:So when you find yourself face to face with someone who is in this position who hasn't heard of OKRs until they get that email on a Monday morning, how do you introduce OKRs to them for the first time?
Allan:I haven't got a surefire recipe. Sometimes you're going to hit the historical perspective and you'll say this is where they came from. Increasingly, I find myself just going for that test driven approach that I talked about before. I think if somebody's been exposed to agile and specifically test driven thinking, at whatever level, then I think the analogy works really well to say look, what we're trying to do here is test first management. We're going to set out what we're trying to achieve.
Allan:The outcome and we need to emphasize it's an outcome, it's not a milestone, it's not a point on a chart, it is something that makes the world a slightly better place. And then we've got our acceptance criteria, our key results around it. So I kind of take that avenue more and more these days. And then I still assume that they're familiar with agile. We've got this cycle over the top of it, this super cycle every 12 weeks, which has been like a super sprint. It's going to start with some setting, some planning, if you like, and it's going to end with reviewing what we've done and it's going to end with a retrospective. So if you want to think of it like agile or skirmish large, it seems to me like this is the year of the second edition.
Allan:Yes.
Paul:Lisa Adkins came out with the second edition of her classic coaching book. I've heard that the fabulous book, the original retrospectives book. I forget the title of the retrospectives book, but I understand that there's a second edition coming out I can't wait for. I love second editions and I love talking to authors about second editions, because it's a lot of work to go back and revisit what you've put so much effort into and you've put it to bed and you've put it behind you and now you're making it a project again. In your case, what was it that made you feel it was worth the time and energy to create a second edition now?
Allan:It took me about a year to get the energy and I'm also going to warn you and any other readers who attempt with books is that today books, particularly ebooks, and especially if you use the Lean Pub platform, it's really an exercise in continuous delivery and continually updating. And with Lean Pub I use Git. I check my code into Git and I hit the button. It does a build and you start. It's difficult to know when you're done and you have to draw a line. And with the original book I drew a line because I didn't want to get any bigger. You say I knew the stuff I was leaving out and, attempting as it was to put that stuff back in for the second edition, I resisted it. But what did make me do it was key results, and I've learned that key results are the bit everyone struggles with. It's in danger of becoming a cliche to say that OKRs are simple in their conception, but the devil is in the detail, that it's difficult to get them to work and what. The first stumbling block is key results. What are key results? And I think that's the thing that's difficult to wrap your head around, and this metaphor of key results as acceptance criteria. The more I worked with it. The more I used it and it was there in the original book the more I worked with it, the more the key results just fell into place and it made sense. And I also know the biggest mistake people make with key results is they see the objective as a Lego house and they see the key results as the Lego bricks are going to put in place. And if they just get the right key results in, then the sum of the key results gives you objective. And I didn't feel as if I'd been clear enough about this. I felt as if there was places where maybe I could be misinterpreted or I wasn't being. I hadn't picked it myself for you. So I want to go back and clarify this and call out the key results of acceptance criteria, and the way I resolve this in the end is the book actually talks about four different types of key results, and the first type I want you to get is key results as acceptance criteria. That's where it all works. Now there's three other ways of doing it, One of which I will kind of accept because it fits in sometimes and I've got vertical slices that you bring together. But there's another couple of ways of implementing it, One of which is the Lego bricks, which I just think is wrong, and I called it out as a way of doing key results, not to recommend it but to say, hey, there's every chance you've got key results like this, and don't do this, Because it's almost.
Allan:It's almost something everybody does on their learning journey. I think everyone starts off with, OK, that's objective, and then they immediately flip into how are we going to meet it? How are we going to build this thing? How are we going to deliver it? And really you want to postpone that conversation. You want to say this is what we want. How are we going to measure it? What are acceptance criteria, success criteria or key results? How are we measuring it? Because I'm a firm believer and this is something we can come back to later if you want that to any problem there are multiple solutions and which solution you create depends on the constraints. So I want you to separate OKR setting into two steps Setting the OKRs, deciding what the outcome is going to be, deciding the key results, the acceptance criteria, the key major parameters, and then, maybe in the afternoon, maybe the next day, maybe next week, think about how you're going to build a solution to meet those criteria.
Paul:There's a couple of things in there we're going to come back to in the second half of the interview, but I want to wrap this half up with one last question which I think is going to become one of my favorite questions for wrapping up the first half of these interviews under this new format, and that is if you found yourself on an elevator with your ideal reader, with an agile coach who hasn't heard of OKRs and just got that email, what would you tell them about your book?
Allan:I would say it's time to leave your backlogs behind. Backlogs are like children's comfort toys there's a better way. We're still discovering it. As the manifesto says, we're always discovering better ways. We want to be more objective focused. If we're going to set objectives, we need a framework. This is it.
Paul:Wonderful and that's a great place to wrap up the first half of the interview, although, if I can say, it is a little funny that the manifesto was written in 2001 and the better way was created in 1975.
Allan:Sometimes it takes time to see the obvious.
Paul:Well, I will say that because of the way that OKRs were traditionally used, I can see why an agile list would bristle at them and it took time. It took time and it took Google to recognize that they could play nicely in an agile, adaptive IT organization and it took a book like yours to make that widely known. Thank you for that. I hope you enjoyed that the first half of my interview with Alan Kelly. In the second half of the interview we're going to do a much deeper dive. But that's two weeks out, which means if what you heard during this interview peaks your curiosity, you have time to get the digital copy of the book, maybe even if you live in a major urban center, to get the physical copy of the book. It looks like it's very nicely produced. I only read the digital copy, which was fine, and read it before we go into a deep dive so you can follow along with us and see if I am successful in anticipating and getting answers to your questions and digging deeper into your burning issues about OKRs and how they work in an agile organization. There will be links in the show notes to get the book and to learn more about Alan Kelly, to his website, to his other books and to some of his social media and as well.
Paul:Oh, and I've got an announcement to make, and it is this the ACE conference this year was absolutely fabulous, as the ACE conference is continuously growing and getting better and better. We had over 500 people this year. It's the second largest ACE conference we've ever had and so the community is coming back. It's coming back from the recession, it's coming back from the pandemic, and we are going to be so ready for them next year, in 2024. And you can be there too.
Paul:The call for speakers has opened for ACE, and so please go to ACEConfcom If you've got a story to tell or message to share. We love hearing from new speakers as well as old speakers, and the call for speakers will be open until mid January, but there's no reason to wait until the last minute. We would love to hear from you, we'd love to hear your talk proposals. It's going to be another fabulous year next year, and you can be a big part of it. Thank you all so much for listening, and I'll see you again in two weeks when we hear the second half of my interview with Alan Kelly.