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. 

In this episode we cover:

• How to nudge teams into being more ambitious
• How to choose metrics without distorting incentives or cross-department collaboration
• Why “digital” means something else than you probably thought it means, and how it affects how we manage

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: Businesvs 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.115] 
That’s the kind of attitude I want people to have with OK, ours, and that is we’re going to come into this. Don’t forget everything you’ve ever learned. Don’t be ignorant, but don’t be worried about saying, hey, we built this thing last quarter and we thought it’d be reusable, but now we look out OK, we don’t quite need it and be prepared to look afresh at what the Oscars are, what you’re trying to achieve, what what the product owner wants, what the feedback.

[00:00:27.775] 
Look at all that afresh. Don’t be restricted by what’s gone before and be prepared to restart your thinking process and say, look, we have a quarter here.

[00:00:40.675] 
This is day one of the quarter. Hmm. What a week. How are we going to move forward on this anew every day, the quarter. You won’t be asking yourself a question. You are listening to the online remotely podcast and the show dedicated to helping lead distributor teams under difficult circumstances. I’m the host, Luke Scherba, 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 work to help you navigate the issues start facing after you get.

[00:01:19.015] 
You’re welcome, welcome, welcome back. Today, we are continuing the conversation with agile coach or guide Allen Kelly, and we cover topics such as how to nudge teams into being more ambitious, how to choose metrics without distorting incentives or cross department collaboration in larger companies, and also why digital means something else than you probably thought it means and how it affects how we manage. So without further ado, here’s Allen.

[00:01:58.795] 
We’re talking about ambition. So how do you get teams to be more ambitious when they’re doing their planning?

[00:02:06.505] 
I don’t have the answers. I and the more I’ve looked at it, the more I thought about this, the more I think it comes down to and I’m sure many of the readers will know this psychological safety. Which which is a big topic at the moment, Amy Edmonson’s written the book on. You know, we’re going to share this organization.

[00:02:29.665] 
There are some organizations, even some teams, which value predictability more than anything. So as much as OK all the time, make it be ambitious. There are some people who value predictability more than that one team are working with. Last year I was on a conference call. This would be before conference calls got trendy and everyone did just have to be accomplished. And there was another team that used the product my team was creating. They said, well, what what are we going to get next?

[00:02:58.855] 
What are the what are your objectives? And I remember on this call us outlining the objectives for the coming quarter. And at the end of the quarter, the project manager on this other team said, and how excited do you have? You’re going to meet these objectives? How reliable can we take these? And I said, oh, I think I think we’ll do seven and 10. And this something like what if they’re like three weeks, seven of which time are you going to get what they want?

[00:03:26.495] 
Predictability? Yeah, which of course is your ambition. If you want predictability, you can use the OK, our method. Let’s just make sure that you say that you have the predictability because most people have ambition. So first of all, you’re going to need an organization that recognizes value and values, ambition, and you’re going to have to explain to people that if it’s predictability thereafter, this isn’t that debilitating. Either they need to change or we need to change the system.

[00:04:04.385] 
And then it comes down to individuals. I’ve seen so many people over the years who who have been scarred by every time a developers have been asked for an estimate and they’ve not met it, which is like every day of the week. You don’t like the kind of scar’s around with them. I think as an organization, you’ve really got to start paying attention to this thing called psychological safety. And if I’m being really truthful, I hope they’re not listening or maybe I don’t.

[00:04:33.405] 
This organization I was with last year, I don’t think they appreciated that. If they did appreciate it, it wasn’t really being spelled out, if you can overturn this application called OCA’s, you need an operating system to provide psychological safety is an absolute baseline.

[00:04:49.765] 
Absolutely. Yeah. If people can say what they think, then it makes it difficult to really do much else.

[00:04:55.825] 
The first point on that, I won’t go into how you achieve psychological safety. Go with the book much better than me. But what I would say is a starting point is you got a divorce compensation, bonuses, renumeration pay from hitting us and. I think every author I’ve read about says this you do not bonus people anything, OK? You do not tie our success to performance reviews and annual appraisals because that is exactly where you would get what’s called gall displacement or tort law referred to before.

[00:05:34.605] 
But people make sure they hit the target to get their salary, their bonus. You have to divorce. OK, from that.

[00:05:41.535] 
Unfortunately, every H.R. department on the planet seems to look OK and say, oh, material for performance reviews and bonuses.

[00:05:50.805] 
So so if you are in an organization that’s implementing or cares, what would you tie bonuses to?

[00:05:56.685] 
For example, I’d either not have bonuses or I would tie bonuses to profitability of perhaps the whole company or if it’s a very big company to the profitability or revenue is a better one of the actual product. I think it’s Mary Poppins, like in Lean Software Development. She has this great advice that you tie bonuses and similar things one level above where people are. You don’t you don’t incentivize the immediate thing, you incentivize contributing something bigger. If you incentivize the immediate thing, people get very good at meeting that, but the side effects will cause damage elsewhere.

[00:06:43.145] 
So one level in terms of within the organizational structure or in Mary’s case, she was saying one level within the organizational structure, that is a starting point.

[00:06:54.195] 
That is where I’d look at years ago, I used to work for a small software company. I remember they tied annual bonuses just to play in profit. Maybe we but and that seemed excellent to me. That was a way of saying, look, you are an individual, you’re part of this system, you’re part of the company. You need to do your work. But actually you also need to help the overall enterprise work on stuff. And it seems a very fair way of doing it.

[00:07:25.385] 
The incentives are right when you tie them too closely to individual performance, you get well. Banks are a classic example, aren’t they? People manage to to get their bonuses and banks. But we see banks again and again getting into difficulty and having rogue traders, you know, London Whale and all that.

[00:07:43.715] 
Yeah, I never forget those of you old enough to remember Barings Bank, which went belly up in the late 90s. They made a rather cheap film of it is illustrated well in the rogue trader actually had the developer sitting next to him and actually call him to create a new account in Ms. Access, I think it was, and dump all the bad trades in there. Well, once you knew there was another account in the access to access, it gets access to Excel, you know, dumped in the picture is completely different.

[00:08:20.045] 
So speaking of incentives in the context of OK, cars, how do you.

[00:08:27.785] 
How do you align incentives? Across departments, I mean, maybe this is a wider question of just external dependencies and how they influence the outcomes. I mean, what are your thoughts on that?

[00:08:40.605] 
Again, I don’t have a complete answer. And and every was different. Yeah, two things I would say. First of all, the the people I wouldn’t say at the top because it could be halfway down. The people are being charged with deciding what it is you’re trying to achieve, what your mission you’ll be hagwon must be transformed for that purpose. What call the people who decide the need to articulate that. And they need to say, look, as an organization, as a group of teams, we are going after this and actually.

[00:09:13.865] 
I don’t want them to phrase that in, OK? I want them to phrase that in fancy language. I want them to leave the space the teams work out for themselves to. First of all, we all need a common goal. There’s an old Steve Jobs quote saying, as long as we all agree that we’re going to San Francisco, everything’s OK. Whatever we take is when some people think we’re going to San Francisco, some people think we’re going to San Jose, that the problems start.

[00:09:38.645] 
So, first of all, you need to have a clear line on where you’re going. Hmm. The second thing is when it comes to dependencies and interrelationships. I think it’s less about managing these things as it is about eliminating a. We spend a lot of time managing dependent’s, you spend a lot of time creating masterful planning systems to get people to align and agree and interlink and actually. However good your planning is, it can all fail when the slowest team doesn’t deliver what they’re expected to be, far better, I think, put your energy into creating independence to actually start to separate those teams and allow them to move at their own speed up.

[00:10:30.235] 
People get really scared at this point because we’ve all been taught that reuse is a sacred cow. And perhaps what I’m saying here is sometimes you don’t want to be using stuff. You do want to be reinventing the wheel, because when two teams invent their own will, they’re responsible for their own will and they can move as fast as they can keep their own wheel together when they start sharing the same wheel. You’ve now introduced a dependency and now one of the teams has the ability to slow down the other team.

[00:10:59.785] 
So I think part of the solution here is to promote independence. Now, I know you’re not always going to want to do that, and I know it wouldn’t make sense to, first of all, to go and write our own spring framework. But even in that analogy, there is a solution we use Prepackage software all the time we used to spring framework, the we all use McCalls or Windows Microsoft Office. We use package software where you’ve got a big piece of functionality which are used by multiple teams.

[00:11:35.355] 
You probably want to see them as packages that need to be managed and treated like products in their own right with their own their own teams. They’re not an afterthought. A second thing for teams to do. So I don’t have a complete solution to dependency management and relationships. I just I want to make sure you all agree on a common goal. And again, OK, I can help there because you can look at the different locales and say, do they all point in the same direction to reduce dependencies and eliminate them wherever you can?

[00:12:06.135] 
And three, when there are dependencies, call them and run them is one thing. Yeah, I’ve always played with the idea of applying dependency inversion in the context of organizations just defining the boundaries well and thinking of systems in that way, for example, pulling in freelancer’s to to do certain bits of the work.

[00:12:27.395] 
It’s the same kind of thing if you have that well defined onboarding process for freelancers, that you can have a similar arrangement between departments that are self-sufficient in all sectors.

[00:12:38.435] 
One thing I will caution you against is platforms or infrastructure, where there is some common component which the organization has and is used by multiple teams in our organization. Mistake I’ve seen so often is they say, hey, this is purely a technical thing for this team, produce it and therefore the product on it could be one of the devs or the product owner can be somebody who used to be a dev will now upgrade those that were to a product manager.

[00:13:04.955] 
And I think that is completely the wrong approach. The idea that where you’ve got a piece of platform infrastructure, you can just turn off to techies. You don’t need a strong product. And I think it’s wrong. I say, in fact, you need your strongest product owners in those positions because those are the products which are furthest from the actual customers. And therefore, you need people in there who are actually very good at getting to customers. You need people in there who are very good at understanding value and understanding how Team A is going to use the same product as Team B, but they’re going to discern value in different ways.

[00:13:43.505] 
And somebody has got the facilitation skills to say, hey, team B, I know you’re asking for this, but team is asking for something else and I’m going to give them priority. So rather than staffing these platform teams with weak product owners, your strongest people that I have seen this kind of thing work out well on a trading platform.

[00:14:06.065] 
And the main concern customers had was that it was too slow and in fact, getting devs who knew the performance side of it really well and also understood enough the customer pain. They ended up being able to create something that was a lot of value to customers without necessarily having additional support from, let’s say, the business side for lack of a better term.

[00:14:27.065] 
I think that is more of an exception than the rule. Yeah, you agree.

[00:14:30.555] 
You also bring it back to OK, are you also touching on something else? I think I say in the book we can prove a bit controversial is that I steer people away from doing pre work. I, I want people to come into that. OK, ask the quarter and then to almost start with a blank sheet of paper. I think so often when we do pre work, whether it’s by writing convenient backlog or designing an architecture or something, the pre work we’ve done has shaped the way we approach the problem and shape the way we’re going to try and create a solution.

[00:15:04.925] 
And if you stand on day one of the quarter and say, hey, we’ve got this amazing, OK, are looks impossible, how are we going to achieve it? There may be ways of doing it, but if you got all this baggage of previous work, then you’re constrained. And also the previous work doesn’t come for free. Somebody’s done it and somebody’s done it in advance, which means that when they were doing in advance, they weren’t contributing to the last quarter because they were doing something else.

[00:15:36.035] 
Towards the end of writing the book, I stumble across something I’m sure you’re familiar with Luke and Jeff Bezos.

[00:15:41.585] 
His idea of it’s always they want. This idea that all seven ninety seven letter to shareholders, yes, yeah, yeah, I think that’s the kind of attitude I want people to have with OK us. And that is we’re going to come into this. Don’t forget everything you’ve ever learned. Don’t be ignorant, but don’t be worried about saying, hey, we built this thing last quarter and we thought it’d be reusable, but now we look out OK, we don’t quite need it and be prepared to look afresh at what the OK are, what you’re trying to achieve, what what the product owner wants for the feedback and to look at all that afresh.

[00:16:22.325] 
Don’t be restricted by what’s gone before and be prepared to restart your thinking process and say, look, we have a quarter here. This is day one of the quarter. What a week. How are we going to move forward on this anew every day, the quarter? You won’t be asking yourself that question. Have you heard of the term zero based thinking? Yeah. Yeah, the question that’s useful there is knowing what you know now, would you would you would you start doing the same thing you were just doing?

[00:16:54.315] 
Yeah.

[00:16:54.655] 
You know, I think we can actually prove this because, you know, you and I, we’ve been in this industry long enough. We see the new people coming in now and remember that we were the new people 20 years ago. And we are fully bright ideas and we can sometimes get a little bit cynical about the new people entering the industry. And we also beat ourselves up as an industry about how we don’t remember our failings.

[00:17:17.655] 
But I think partly because we are an industry where the technology is always advancing and changing and partly because it’s advancing change. We do pull in a lot of new people, sometimes young people, sometimes people have come a fresh story and and they come with a lot of that zero thinking simply because they don’t know now. And sometimes, you know, you and me, we got that will never work. You can throw yourself off a cliff. Are you nine out of 10 times?

[00:17:43.355] 
We’re probably right, but, you know, once in a while people try stuff and they do, they get amazing results.

[00:17:50.885] 
Yeah, there was this amazing book by Arthur C. Clarke called Profiles of the Future that you wrote in the 60s.

[00:17:58.055] 
The premise is just that he goes back and looks at various prognosticators and futurists in the 30s who are saying that it’s impossible that we’re going to have transatlantic flight depending on the exact thing, even by the 60s was already completely commonplace. If you want to be accountable in terms of making broad claims.

[00:18:16.955] 
And that’s the way to really do it, I guess all this to me is summed up in the word digital. I expect there’s quite a few people groaning there when I said where digital. I must admit, until a few years ago, when people used were digital to me, I kind of grown. So save your breath. It’s not necessarily those analog computers never caught on, but I came to realize that.

[00:18:43.255] 
The technology we have today and digital technology, yes, is so much more powerful than the technology we had even 30 years ago, that it’s something new when people outside of technology, the traditional technology base, used the word digital. What they are saying is, my world now looks like your world. What those marketeers and accountants and HRR and salespeople, all of Estima saying when they say the word digital is they’re saying, oh, my God, sales marketing accounts now looks an awful lot more like software and software development than it used to you.

[00:19:26.275] 
Yeah, software is eating the world and all you and somebody said to me, when people use what digital, what they really mean is software. So digitization means a software ization. You digitize a process, you turn it into software. And that is so true. And let me just give you a couple of specifics. 1981, IBM launched the PC. It had twenty nine thousand transistors and it’s Intel eight 088 processor, it had 64 kilobytes of S. of 40 kilobits of memory, max to seven and twenty floppy disks and an eight by twenty five green screen.

[00:20:04.875] 
The iPhone 12 has 12 billion transistors and CPU, 64 gigabytes of RAM, 128 gigabytes of storage. If you took the components of an iPhone excess two years ago and looked at what that would have cost in 1990, want to buy an iPhone X in nineteen ninety one would have been approximately 30 million dollars. Mhm. And you’re walking around with it in your pocket complaining it costs you six hundred dollars or seven hundred dollars. It’s when I entered the world you entered, it was the IBM PC world.

[00:20:42.675] 
And it ain’t that now that increase in power. One of the things it means is that we need new ways of working, we need new ways of managing. We need new processes. The idea that you could run business processes as you did 30 years ago, 40 years ago, the way you manage people 40 years ago be applicable today. It might be. But you have to question not to start off with. And this is why I think ideas like you up until about, OK, ask paper.

[00:21:13.125] 
You had Jody Thompson on the cast a few weeks ago and she all about results only work environment and friend of mine, Mike Burrows, he does gender shift and he talks about outcomes. What we’re getting towards this world where it’s less about looking at what you’re doing and the tasks and the time you’re spending and what is the the outcome. The resources are now so great that humans are key to this. And we really wanna make sure we won’t be getting is what we want the right thing out of them.

[00:21:45.375] 
It’s that’s why our management processes are having to change for someone in a company who wants to get started with, OK, ours, and they’re already running agile.

[00:21:57.585] 
What are some small things they could try or something that quickly yields something useful?

[00:22:04.155] 
The easy way to think about it is that, OK, I typically set reviewed every three months, so it’s almost like having an extra long sprint. I don’t think quite it’s not I think it’s slightly different, but you you want to put a cadence, an additional three months cadence on top of your current sprints. And so to me, that means six sprints and then take some time to stop with you, reflect retrospect and set yourself targets. The tricky thing for any one individual is this isn’t really for you to do alone.

[00:22:40.165] 
This is a team sport. Agile has always been a team sport and an OK more than ever. It’s a team endeavor. So you need to you need to get your team willing to try doing this. And you need to particularly get your your product owner involved and hopefully your product owner once they understand that this is all about going after customer needs, delivering benefits for customers and thinking above the story level. I would hope the product owners will jump at the chance and say to the product owner, OK, let’s let’s start the thinking on the sprint, sprint, sprint level.

[00:23:18.385] 
Let’s think what things thinks we try and achieve in the next three months and set yourself some objectives around that. Do a little bit of a breakdown to the key results and maybe some hypotheses you want to test. It might be some things you want to build. You might want to even time box most key results. So you might say we will allow two weeks for refactoring. You could give a phrase. All right. You can say a key result is that the software internals have improved, but we’ve only improve them by two weeks worth.

[00:23:53.305] 
They’ll always be more refactoring you could do, but will allow two weeks if there’s different waiting for results anyway. Think about those big meet objectives now. I’m going to say three. For me, you don’t go more than three objectives, and each objective has three key results.

[00:24:12.585] 
If you put my arm behind my back and lift it up and make me scream, I guess I’ll accept four objectives. I will accept four key results per objective. But do the math for objectives. Have four key results. Each is 16. You’ve got 13 weeks and a quarter. So they aren’t going to be that big a meeting, are they? So I would rather you were close to three objectives were about three key results each. But that your ballpark.

[00:24:42.345] 
I know that’s tough, but it is by stripping away the other stuff and deciding what you’re going to focus on by saying no to other things, that you achieve the focus and you achieve the communication and you achieve the coherence. If you’ve got, you know, 10 objectives, each of which has three or four key results, and you’re back to the backlog problem. So, OK, like good strategy is about deciding what you’re going to say no to and what you’re going to put to one side.

[00:25:14.575] 
There’s a whole bunch of issues over business as usual, how you deal with that. And I’ll put that to one side. But I think one of the things we want to make a difference for what we want to deliver to our customers, what are the big, meaty things breaking down a little bit and every sprint for that quarter when you go in, you look at your OK and you tick off what you can take off. You decide what you’re going to work on and then you take this day what mentality and you say, right.

[00:25:41.575] 
Given where we are today, given how much time we have left, what can we do that will make a difference, that will move us towards that key result, that objective. Forget whether it’s in the backlog or not. So I think, you know, if you’re if you think about it for your team, I think you can run an experiment. You can say, look for the next quarter will try doing this stuff.

[00:26:08.105] 
Much outside of that, you’re going to need to start getting buy in from the stakeholders around you, particularly stakeholders who have authority over you and you to go by the name of manager, you’re going to get other people even to buy into it, and you’re going to need to create more changes. So I think as an individual, I think you can do stuff without chaos, but I think it’s much more difficult to get start with OK than it is with agile generally, because, OK, ours are by their definition, more strategic, bigger, more team orientated.

[00:26:42.335] 
So does it make sense to map those down to individual based outcomes and key results, or do you advise against that?

[00:26:50.015] 
Initially I’d go against that completely. There was one team I worked with were effectively those five or six people on the team and in effect, everybody had their own objective. Everyone had their own results. Yeah, we we’ve long and agile talked about cross-functional multidisciplinary teams and all that. If you’re going to have OCA’s earmarked for particular individuals, you’re not going to get the team spirit. You’re not know can’t get work flowing across them. I’d even go as far as I’m not keen on individuals having their own private accounts for additional work.

[00:27:26.225] 
It’s a team sport. So, yes, it might be the one you’re OK and involves a lot of database work and it might be that your database is run off their feet and the other team that the team is sitting there twiddling their fingers. Well, I would hope the other team members would find a way of being able to help the database person. I would hope they might say, you know what? I read a book on databases the weekend and I’ll try and help.

[00:27:53.625] 
I would hope people would recognize that it may be quickest if the database does all the database work. But you know what? If the database expert isn’t getting started on stuff because they’re too busy doing something else, if somebody else does a half the speed, they may well finish it quicker than if you wait for the database to become available and then do it again. And this is why I think it is a good fit with Agile, and I think they can promote that team based thinking.

[00:28:20.165] 
It’s a team approach. Nobody crosses the finish line alone. It’s a team thing. So where do people find out more about the book? Right now?

[00:28:29.645] 
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. Now, I’m dyslexic, so my grammar, punctuation, spelling is all over the place, but I have a great copy editor, so Steve will get it copyediting in January.

[00:28:57.875] 
So you should see the finished product in February. Right now you can buy the book online purp Limpert dot com slash Agile OCA’s and you’ll find it and you can buy it for five six dollars at the 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 pop first of all, then it will appear on Amazon and sometime after that. So probably March time, there’ll be a physical version and an audio version out.

[00:29:33.005] 
So right now, right now, December twenty twenty, look online and in February onwards, you’ll probably find it on Amazon. OK, great.

[00:29:44.675] 
And where else can people connect with you? What are your favorite places to hang out?

[00:29:48.635] 
Well, I hang out on Twitter, but you might get some really insightful comments for 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 Kelly. Dot Net. You should know I have two L’s and Alan a HLL. And so I have a blog on the website that gets updated a couple of times a month. I tweet too much. I’m on LinkedIn. You can find a link then please join me.

[00:30:13.235] 
The great. Thank you very much. Thank you, Luke. That was a great episode, and I always enjoy my chats with Alan, so I’m glad you had a chance to listen in and also hopefully enjoy it. I think the main thing which Alan touched upon that is super important is this reference. He had to always day one from Amazon, how much that actually affects how we manage in organizations on a day to day basis. So not getting stuck in just constantly maintaining the status quo and the sunk cost and creating it, but always thinking about how things can be improved and changed.

[00:30:58.355] 
And it’s nice that doctors support that ability to be able to create that change for lack of a better term. Tune in next time. We’ll be back with another episode next Tuesday. Thanks for listening to this episode of The Aligner about the podcast, if you enjoy the show, please leave a review on iTunes, Google podcasts or wherever you get your podcast.