Intro teaser

[00:00:29] Allan: And she was like, "but, we're marked down on that. That's a black mark at this organization, my manager will want to know how I got it wrong". 

[00:00:36] Allan: We want to keep stripping away these things and saying, "if we go back to the core, are we delivering benefit to our customers? Are we improving?" 

[00:00:47] Allan: There's a word in Japan that started at Toyota, which means death by overwork. And it literally means people dropping dead from overwork. 

[00:00:55] Allan: They're hard questions, but ultimately they're probably the only two questions [00:01:00] you need to ask.

[00:01:00] Scott: In this episode with Allan Kelly, we discussed his secret weapon against bosses who tell you everything has the same priority. How the only thing you can do wrong in work is to stay fixed. And the only two questions you really need to ask at work.

Main show

[00:01:14] Scott: hi, Allan welcome to the show. Really glad to have you here. Would you mind just giving a bit of an introduction to yourself for the listeners, please?

[00:01:22] Allan: I help management teams, building software-intensive products and services. Now, this usually involves applying the agile word, agile thinking agile approach for me, agile is just the best toolkit we have available at moment.

[00:01:35] Allan: Normally it starts off with people saying "we need to manage our dependencies, synchronize our teams, we need to plan forecast ahead". Or when "will it be done?" Something like that. I used to be a hardcore programmer back in the day. And I always see myself in my mind's eye. I am trying to help the developers that I was 20, 25 years ago.

[00:01:57] Allan: 'cause I know how painful it can be. I'm [00:02:00] fortunate that means I sometimes have to speak a bit of business to get in with the people who perhaps have the power. So in a nutshell, that's me. Oh. And between that, I write books. I've written a few books. 

[00:02:11] Scott: You have written a few books. 

[00:02:12] Scott: We're going to talk about a few things today, but to kick us off, it's probably worth just mentioning that you've written a post on LinkedIn recently. That's, dare I say gone quite viral, but it certainly struck a chord with people. Do you want to just tell us a bit about that? 

[00:02:26] Allan: Yeah. I summarized and explained something I've been saying for a few years, and that is that the only thing you can do wrong in agile is to work the same way you were three months ago. 

[00:02:39] Allan: To me, agile all about learning and changing and hopefully improving. And if all you're doing is going through the motions the same way as you did three months ago, I don't see where you're trying to change.

[00:02:52] Allan: I don't see where you're learning. So that's my test for being agile. 

[00:02:58] Allan: Now there's [00:03:00] a corollary to that, which I only realized more recently. If agile implies some kind of learning and change, then the opposite of agile is not learning and changing. The opposite of agile is static. It's a failure to learn.

[00:03:14] Allan: It's a failure to work in different ways. 

[00:03:16] Allan: We're at a point now where I think we do need another word rather than waterfall to talk about what is not agile. 

[00:03:22] Allan: So I put these things together in a post and I've been completely blown away by the number of comments, reshares, likes I've had. It certainly hit a chord with some people. 

[00:03:34] Scott: What triggered that thought for you? You've obviously been in the industry a long time. Was there a particular moment, in work that triggered it? 

[00:03:41] Allan: On this occasion, there was an exact moment I can almost date it. A few years ago, going back a good few years now, I was working with a big well-known airline that shall remain nameless so that if I say anything bad about them, they won't get upset. 

[00:03:56] Allan: It was a new year it was January. I was going to visit them because good. [00:04:00] My style of working although I'm an agile coach, my preferred way of working is not to be with the team all the time. I kind of drop in for a few days here and there and talk to people, address problems, work through issues with them, and then leave the teams to get on and try doing stuff.

[00:04:15] Allan: So this was January. I was going in for my first visit of the year and I was driving in and I'm thinking, "you know, I need to fire these guys as clients, they're not changing they're not improving. We're still arguing about getting the product managers and the business analysts to sit next to each other. They're the business side and the IT side neither of them want to move the desks"

[00:04:36] Allan: And I felt a bit frustrated with them, to be honest. So I got in and during the course of the day, I was doing my usual trick of going around lots of people I'd talked to before and seeing how things were going and taking the temperature. 

[00:04:50] Allan: I also got to meet two new people a senior business analyst and a junior project manager who had recently started the airline and [00:05:00] both of them independently, almost a first thing they said, when they walked into the room was. " I've worked places that call themselves agile before, and this place is so much better." 

[00:05:12] Allan: And that was an epiphany to me that here I was beating myself up and being down about this client because they weren't drinking more agile Kool-Aid they weren't improving. They weren't doing stuff. They weren't taking advice and yet they were a damn sight better than many other places, both in absolute terms and if you want to measure it by doing agile, and it's not so much about where you are, but where you came from that, you are better than you were. And so when I see people proposing tests for agile they frustrate me a bit, but the same way when people talk to you as being scrum- but teams or agile in name only for many of these teams, the few agile [00:06:00] practices they've got the prototype agile process they've got, it's still a massive improvement over what came before. 

[00:06:08] Allan: And actually, if you've started to get into the learning and change cycle, the continuous improvement cycle. Does it really matter where you are today? Hopefully, you're better than you were in the past, but if you really got a continuous improvement cycle going, you're going to get there. It may be Scrum. It may be something else. It may be something no one ever thought of before. But if you are actively learning, reflecting, trying to improve and not every attempt will work out, sometimes you'll want to reverse things, then, you know, that's the important thing, isn't it?

[00:06:43] Allan: That's what you should be getting at so hence this comment that the only thing you can do wrong in agile is to work the same way you did three months ago. If you are just repeating yourself, if you're not changing, then that's static and that's [00:07:00] decidedly, not agile.

[00:07:01] Allan: So all I'm asking you to do is keep trying to get better.

[00:07:05] Scott: And we're talking about agile as in the proper definition of agile and not necessarily the manifesto, it's actually the principle of being able to move fast with easy grace as Josh talked about on a previous show. 

[00:07:19] Scott: And that's what a lot of companies need to do to stay relevant and competitive, but it's wrapped up in all the connotations around processes and methodologies and I've seen and heard from yourself and others that people just get caught up on that and miss the whole point.

[00:07:35] Allan: It's an example of what gets called goal displacement. When faced with a particularly difficult problem or problem you don't want to face up to or problem, you can't even comprehend, perhaps, your brain likes to substitute the problem you're facing for an easier problem.

[00:07:52] Allan: And we all do this all the time. It's one of our solution solving techniques. You know, you can't solve a problem, so you solve a simpler problem and hopefully, you can then [00:08:00] attempt a bigger problem. 

[00:08:01] Allan: Get institutionalised and organizations fall into this trap called goal displacement, where they start chasing some goal, they think is attainable or at least quantifiable over the ultimate goal.

[00:08:15] Allan: And let's be honest, this ultimate goal of agile to be constantly improving is difficult. And some of the things you need to change in your organization are hard to change. It's far easier to say, "we'll just have a planning meeting every two weeks. We'll appoint someone Product Owner. We will write things in user stories and have a checklist of ceremonies and practices that you can go down and say " tick, tick, tick!"

[00:08:41] Allan: "We are 80% Scrum we are 82% Kanban" or whatever. And ultimately we want to keep stripping it back to the bare metal. We want to keep stripping away these things and saying, "if we go back to the core, are we delivering benefit to our customers? Are we [00:09:00] improving?" And constantly keep challenging ourselves on that.

[00:09:03] Allan: They're hard questions, but ultimately they're probably the only two questions you need to ask.

[00:09:08] Scott: Yeah. And do you think people think of these things, these processes, and I'm going to talk about Prince as well as a kind of comfort blanket, like, "well, if I've got a plan" or "I've got loads of documentation about something, somehow I'm safe from the reality of the world outside. That's moving much quicker than we are." 

[00:09:26] Allan: Yeah. Well, again, it's goal displacement, 

[00:09:28] Scott: So you would put that under the same banner?

[00:09:29] Allan: Solving a problem is difficult, but you know what, if I can tick the box, that says I've got a full requirements document, then I've done something. Cynics might say it's a cover your arse strategy, but let's not be too cynical. You feel as though you've done something that's within your control.

[00:09:46] Allan: And then the same goes for Gantt charts and all these other mechanisms, people all trying to do their best. They're doing what they think is worthy. 

[00:09:54] Scott: Or what their organization tells them they have to do.

[00:09:56] Allan: Sometimes organizations, they stack the dice in their [00:10:00] favour. 

[00:10:00] Allan: Years ago I did some training for a bunch of business analysts at an insurance company and I was, I was talking about how the requirements change and you're discovering stuff and specification by example and blah, blah, blah. And one of the Business Analysts said, "but what we find out might contradict what's in the requirements and specifications". I said "well yes!". 

[00:10:19] Allan: And she was like, "but, but, we're, we're marked down on that. That's a black mark at this organization, my manager will want to know how I got it wrong". 

[00:10:27] Allan: So organizations, they can stack the deck against you.

[00:10:32] Allan: The other, thing stacked against it is our education system. You do your Prince 2 training, and so you're a certified project manager. And so you feel as if you should be using those kinds of techniques, you should live them. 

[00:10:48] Allan: I once worked, with a project manager who didn't like agile much, but part of his way of dealing with it was to take all the index cards we use for user stories and put them through the printer. So they'll have to Prince 2 to [00:11:00] logo on them. Somehow this made him happier!

[00:11:04] Allan: I graduated from university and I spent the first five years of my life feeling guilty because I was told at university the way we developed software is to do a good design before we code and to do a good design before we code, we really need to understand the requirements and specifications.

[00:11:21] Allan: And so before you do anything, you should understand what you're trying to do and you should design it properly, and then you code it up and testing was a trivial exercise at the end, you know? Yeah. And I went out into the real world and I wanted to do this. I went to several different companies and they didn't do this.

[00:11:38] Allan: Did it something else! You know, they just threw you at the keyboard. and said "start coding" or "here's a lump of code we already have, can you change it?" 

[00:11:46] Allan: I felt guilty. And then in, late 96. I got my dream. I got to work on a proper project. I got to work on a project that was stamped at the ISO 9,000 approval.

[00:11:59] Allan: I got to [00:12:00] work on a project where everything was documented. We had documentation as tall as I am now if you laid it end to end and it was a frigging death march. 

[00:12:08] Allan: It was a death march by name of Railtrack. And some of you may remember what that was. A big chunk of it was cancelled. I got my dream and my dream was hell. 

[00:12:20] Allan: The best thing that came out of that project was, Charing Cross Road, as it was then in London was within walking distance and one lunchtime I was on Charing Cross Road, and back in those days, it was full of bookshops. And I bought this book called "Dynamics of Software Development" by Jim McCarthy. I think Jim McCarthy was saying heretical things "release early" ,"release often" we would now recognize what he was saying there as agile, but this was in the day before we had the word agile and that was where my agile journey started.

[00:12:52] Allan: And now today I look at teams and I see the same guilting people that they aren't doing Scrum [00:13:00] perfectly, or they aren't doing Kanban perfectly, and people say, "oh, well, we're trying to do Scrum, but it's really Scrum- but", or "we're doing our version of Scrum, we're compromising here or there", you know that there are no medals for doing Scrum perfectly the prizes are there for delivering benefit to your customers. 

[00:13:17] Scott: Absolutely. Hearing, you tell that story and from my own experience as well, just reminds me how this just sounds like such common sense. The job of the company and the organization is to deliver value to the customer. It sounds so obvious and it's not just software teams and development teams it's the same for most industries, if not all, isn't it?

[00:13:37] Scott: But we seem to get wrapped up in all this bureaucracy and leadership wanting to, not to give up control. And, I think that links into one of the other points we're going to talk about, which was the authority and who has the actual authority to do the work.

[00:13:50] Scott: And the hierarchy of organizations are still not really compatible. 

[00:13:54] Allan: So hierarchy is a good thing. Hierarchy tells us where we are and we all need [00:14:00] a bit of hierarchy because otherwise you're adrift in a wide ocean and it helps us understand what we should be doing. 

[00:14:07] Allan: I have a problem with hierarchy is that it goes from top to bottom. As much as people say, "we have a flat hierarchy here" and that's an oxymoron, if you say to somebody well "describe the company to me" or, you know, "draw me a diagram of a company", they inevitably draw a tree and upside down tree. And at the top, there is a managing director, a CEO, somebody or other, and then everyone else is like the branches of the tree, inverted below there. And we keep seeing it that way. And while that is our view of the company, we are inevitably wedded to this, to elements of command and control. And we're overly wedded to expressions like above and below.

[00:14:48] Allan: We're implying that in our language. The model I've been using for a while and listeners can try this at home. It's really quite simple. 

[00:14:58] Allan: Instead of imagining [00:15:00] your organization as an inverted tree. Imagine your organization as the solar system. At the centre is the sun. Every entity in the solar system has a relationship with the sun.

[00:15:13] Allan: It's bright, it's hot, it's massive gravity. In your organization that's going to be your senior leaders, your CEOs, your managing directors, perhaps a CFO, the CTO, whoever. Yeah. Everybody in your organization has a relationship with the person at the centre. The CEO, most people in an organization can name that person. However, on a day-to-day basis, most of what you do has nothing to do with that person. 

[00:15:43] Allan: You work within a team, you work within a department, so your teams and departments, they're like the planets going around this sun. If you're CEO, it's the centre of your solar system is your son. Your team is a planet going around that. And [00:16:00] possibly your team works quite closely with the CEO, perhaps you're physically close to them in the next office. Or perhaps you're just in the same building. Perhaps you're doing something which the CEO is interested in and your team is like Venus or Mercury. You're, you're close in there you're heavily affected. The heat really gets to you, etc etc 

[00:16:21] Allan: Alternatively, your team might be like, Neptune it's stuck way out. Although the CEO exacts some influence on you, there's a whole load of other stuff going on around you. You follow your path but there's not much heat off the CEO. You get on, you do your own thing. But the sun's not the only force there are the things that are happening around you. Your own moons and this is like any team. Yes, you're trying to do what the CEO and the senior leadership team say, but you're also trying to do what's right for your customers. And you're trying to do what your team thinks is, right.

[00:16:56] Allan: And that might be because your team has got an idea of what the customers will need in [00:17:00] future, or it may be because your technology is taking you in one direction. Your technology is saying, "rebuild me, move me to iPhone!" or something. 

[00:17:09] Allan: And you've also got the force of competitors. If you're in an environment where you have competitors, that is not everyone is, what your competitors are doing. is going to influence what you're doing. And really, as much as the senior leadership team may say, they want you to go in this direction or do that. There's so much else going on that they can't really know what is important for your team and your team needs to understand those forces gather information and make their own decisions.

[00:17:40] Allan: And in Scrum terminology, the Product Owner is the person who's on point for that. The Product Owner is the person who should be at least pulling all this together. Although it should hopefully be more of a shared collective decision. If we start to envisage our, our teams, as, as planets going around the senior leadership team, you start to see [00:18:00] each one is autonomous.

[00:18:01] Allan: Each one is trying to do its best. Each one has a set of forces affecting it, and some are closer than others and some need to coordinate with other teams and some teams don't need to know each other even exists.

[00:18:13] Scott: Yeah, I really like that. I guess that the challenge is that, and I've said it a few times to people, the people at the front line are the ones quite often the closest to the customer and know what the customer needs. The Chief Execs they might have been there at one point in their life, but, they're probably quite out of touch with what's going on.

[00:18:30] Allan: There's a book called Only the Paranoid Survive, By Andy Grove, who was the Head of Intel at one point, it was quite a popular book a few years ago. One of his stories in there is about the senior team, the board in fact at Intel sitting down this would be in the eighties or early nineties and the leadership team coming to the conclusion that Intel had to withdraw from memory chips and[00:19:00] emphasize CPU's. That Intel was going to be a CPU brains company rather than a memory company.

[00:19:06] Allan: And this was a big decision for the board and the senior leadership team. And they take this decision out and they start talking to the managers about implementing it. And the managers are like, "Uh, yeah. So what? We knew that. We've already been acting on that", and what they discovered was at the lower levels of the company, the managers had already come to this realization and they'd already put things in train that meant they were deemphasizing memory, chip manufacturing, and they were emphasizing CPU manufacturing.

[00:19:35] Allan: And Andy Grove talks about how it's the frontline workers, the people interacting with customers who have the best information. And it was because Intel managers had felt as if they had the authority to do things that when the board finally came to the same realization as most of the managers that the company was halfway there.

[00:19:58] Allan: A lot of the senior [00:20:00] executives were from those early days they still saw Intel as a memory company and they were the last people to realize Intel was a CPU company. 

[00:20:07] Scott: I think Peter Drucker talked about the term knowledge workers and the change from the industrial age thinking. 

[00:20:13] Allan: I've long claimed software developers were the prototype of future knowledge workers. I think my argument is being proved at the moment since we coined the word digital. And the reason I've always made his argument is if you wind the clock back 30 years, who had email? who had the first voice over IP systems? who had the early instant messaging systems? Who had the first websites? the first wikis? 

[00:20:43] Allan: All the technology that your modern digital knowledge worker uses all the time. Programmers and other people working in IT had this technology decades before anyone. I remember having email at university in the early nineties. I remember being in a job in 95 and me and my sister in law emailed each other because I worked at a computer company and she worked in an IT department in the civil service.

[00:21:13] Allan: Nobody else had email. We had it because we had early access. As a result of that, people in technology and specifically programmers and let's take, Tim Berners Lee here, Tim Berners Lee sees a problem. He sees how technology can solve it. Tim Berners-Lee created a thing called the Web because Tim Berners-Lee could, 

[00:21:33] Allan: The same pattern played out with Ward Cunningham and wikis. Programmers especially, if they have a need and they can conceive of a way of solving programmers owns the means of production to quote, Karl Marx. And so technology people have been creating these tools that everyone else now uses. As a result, technology people have been using these tools for longer and we start to change our processes, change [00:22:00] our way of working. 

[00:22:00] Allan: You know, it's like, two years ago when everyone suddenly was told to work from home, a lot of the, IT people were like, "yeah so what? We've been saying we should work from home!" 

[00:22:10] Scott: And some of them are doing 

[00:22:11] Allan: Yeah. And now what's driving knowledge work is digital tools. When you start to adopt those digital tools, you start to look a lot more like programmers of 30 years ago. And that's what I think agile is. 

[00:22:25] Allan: Agile is both the product of digitization (digital tools). If you think about the tools we have: wikis email, instant messenger, and digital power, agile is also the set of processes that allow you to maximize the benefit from those digital tools.

[00:22:45] Allan: If you try and cling to a pre-digital working style where the frontline workers don't make decisions, they ask their boss, who asks their boss, who asks their boss, and a decision goes all the way up. and a decision comes down, then your frontline workers all they're doing is moving stuff around.

[00:23:02] Allan: Filing papers we used to say and these days a computer can do all of that. The real value is in making decisions. So if you don't give your frontline workers, the authority and the power to make those decisions and to interact with customers in meaningful ways, you're not going to get the benefit of the digital tools that you just bought. 

[00:23:22] Scott: If we empower the frontline workers to make decisions and have the knowledge, then what would you say is the job of the leaders?

[00:23:27] Allan: So before I answer that, I'm going to pull you up on that word in empower. 

[00:23:30] Scott: Good. Cause I keep, 

[00:23:31] Allan: You keep taunting me, you know, I don't like it. 

[00:23:33] Allan: So, um, there's, there's a Canadian academic called Henry Mintzberg . I've been reading his work for a couple of decades and he's wonderful, a bit antiestablishment like myself.

[00:23:44] Allan: You know, he, he comes up with alternative views. One of his, uh, might be a blog post, certainly one of his books. His rants are about the word empowerment. 

[00:23:53] Allan: When you go to the doctors when you go to the hospital who has empowered the doctor? [00:24:00] Who empowers the doctor to say, "Hey, we're going to do an operation".

[00:24:04] Allan: Who empowers the nurse to give you a bandage? People who have real power do not need to be empowered. People need to be empowered only because they've been disempowered in the first place. 

[00:24:17] Allan: Empowerment is a type of loan. It's a way of, a more senior person, a person of authority saying, "this is my responsibility, this is what I do, but I'm going to let you have it. I'm going to empower you. I'm lending you the authority. You can do this it's my authority really but I'm lending it to you and if you screw up, then you're in trouble. "

[00:24:40] Scott: " You've got, you've got my power. Don't mess around with my power!" 

[00:24:42] Allan: Exactly it's a loan it's a conditional loan! 

[00:24:45] Allan: What we want is the real authority. We want people to have authority people to act not because their manager has told them to act here to do something. We want to be able to act because it's what's right. Not because they've gone and [00:25:00] checked with some authority that they can do this.

[00:25:02] Allan: They just do what's right and as an organization, we accept or we trust people to do the right thing and we accept that we're all human. We're all inconsistent. We all do something we wish we hadn't done from time to time because if you don't have that, you don't have a feedback cycle. If you don't have a feedback cycle, you're not learning and all the rest of it.

[00:25:23] Allan: So then devolved authority is what we want. 

[00:25:27] Allan: The leadership team, the centre of our u' the centre of our solar system. So obviously we don't want a command and control approach. Everyone hates command and control even with my kids we have problems with command and control.

[00:25:39] Allan: We want everyone acting independently. We want to trust everyone. So, the leadership, what they need to be doing is. I need to use multiple words to describe it. It's one of those things you can't really describe in one word, it's about telling people the direction they want to want to move in.

[00:25:56] Allan: It's about setting the goals. It's about [00:26:00] challenging people. It's about framing, the problems we want to solve. It's about creating an environment where people can do their best work. It's about letting people do what they are best at and trying to make sure that everyone is moving in a similar direction.

[00:26:19] Allan: And if they're not moving in a similar direction and maybe there's a perfectly good reason for it, maybe it is your subsidiary in Argentina or somewhere, which is bringing in very good money, but it's doing something really quite different, in which case the role of the leader is to decide "is that a problem we want to be solving?"

[00:26:37] Allan: Are we just happy to take the money from the Argentinian subsidiary? Should we give them even more freedom and let them go their own way? Or should we learn from them and do something? 

[00:26:47] Allan: The leaders should be leaving what I call white space, they should be leaving blanks. They should be saying, "This is where we want to go , these are our ultimate goals. This is the purpose of the organization". And then you'd be walking the walk [00:27:00] as well as talking the talk, and then they need to be saying to their employees, "How can you help? How can you as a team? How can you as a business analyst, how can you help us as an organization move in that direction and achieve these goals?"

[00:27:16] Allan: Achieving those goals means in the first instance, identifying those goals. So it's deciding what you're going to do, deciding what the problems you're going to solve or what the opportunities are you wanna pursue and hand in hand with that is where they have a bit of power is to say no to things to say, "We are not doing this. We are not going there." 

[00:27:37] Allan: There is one problem which I've stumbled across multiple times in the last six months. And I'm still trying to get my head around it. I talk about it as "strategic whip" or perhaps more correctly, "excess strategic whip". And this is where an organization at the very highest level is simply pushing [00:28:00] too much into the delivery machine is asking the organization to do more than is capable of doing.

[00:28:06] Allan: And most of your listeners have probably come across this concept of work in progress and that hopefully, most people know that when you have too much work in progress, you get delays, you get mistakes. When you do find a problem, it's difficult, to go back and rectify it. There are all sorts of reasons why. 

[00:28:21] Scott: And the human cost, 

[00:28:22] Allan: human cost as well, you know, we all worship Toyota, but do you know, also Toyota is the home of death by overwork for all the Toyota talks about all the lean books talk about work in progress reducing. There's a word in Japan that started at Toyota, which means death by overwork. And it literally means people dropping dead from overwork or perhaps in the Japanese case, sometimes committing suicide because they feel as if they cannot do too much. 

[00:28:50] Allan: I've been quite involved with OKRs in the last couple of years. And the most obvious way to see this is when your organization is pushing you, encouraging [00:29:00] you strong-arming you into taking on more OKRs to a quarter that you can count on one hand. 

[00:29:06] Scott: Can you just help our listeners who don't know what an OKR is? 

[00:29:09] Allan: Objectives and key results. It's a management technique that started again with Andy Grove at Intel has moved through Google is very popular in startup companies. It basically means you set an objective, a thing you want, an outcome you want at the end of this quarter and key results, which are the success criteria of meeting that objective you'll know, you've met that objective when you can tick yes to all these key results. 

[00:29:37] Allan: Some readers may think that sounds a lot like management by objectives, another older technique, and there are some parallels, but the big difference is that management objectives was of a hierarchical system. Somebody at the top, some planning group decided objectives and they were cascaded down the organization. You were told what your objectives were. 

[00:29:57] Allan: With OKRs the aim [00:30:00] is that your team is formulating the objectives you will pursue as part of your effort to meet some bigger goal or bigger purpose to move the organization forward.

[00:30:13] Scott: So the team come up with them, not the managers. 

[00:30:15] Allan: That's an important difference. Some people still try to impose them top down.

[00:30:20] Allan: I think if you do that you're missing the magic sauce. 

[00:30:23] Scott: Hmm. Which is what we talked about around who's closest to the customer and the problem that needs solving 

[00:30:28] Allan: Exactly. So strategic whip and one way you see it is people are being told to have 18 OKRs -18 objectives 

[00:30:35] Scott: What they just pick that figure out the air?

[00:30:37] Allan: Well, the organization that told me about it they had been told there were 18 priority ones and since they were trying to implement OKRs this ended up being 18 OKRs.

[00:30:47] Allan: If you think about it OKRs s typically run on a quarter cycle. That's 13 weeks. If you've got 18 OKRs you're spending less than one week on each one so they're not particularly [00:31:00] meaningful. 

[00:31:00] Scott: That always grates me that multiple priorities. Look up the definition of priority in the dictionary. It defines one. There is only one there could only be one priority. 

[00:31:08] Allan: My solution is, is to say, well, let's enumerate them priority one, priority two. And if somebody insists that you've got two priority ones or three priority twos, then what they're saying is there's arbitrarily no difference between you can choose arbitrarily.

[00:31:23] Allan: At which point I will get out a special device. I'll show it to Scott on the, on the video. It's got six sides and has a number of dots on each side. Your kids have one called a dice. You can simply roll the dice and see for each one, what the priority is and write it on the card.

[00:31:38] Allan: And the person who said they're all arbitrarily important will quickly correct you, but you may find out what the actual priorities are.

[00:31:46] Scott: I like that. Excellent. Thank you, Allan so just to sum up one of the key messages I'm taking from this is. That as you said at the start standing still is dangerous. And this is for anybody I [00:32:00] think. And it's linked to that growth mindset that I've talked about on the other show with Andrew, it's key, isn't it? And it's this the whole, the world is moving so fast around us 

[00:32:09] Scott: and if we stand still, we're going to fall off or get left behind. 

[00:32:12] Allan: Yeah, 

[00:32:12] Allan: Yeah. What distinguishes us, humans, from the other animals and it's our abilities to learn and to act on that learning. There's a Dutch man. I think if I pronounce it correctly, Arie De Geus he wrote a book some years back called The Living Company. He was a senior planner from Shell and he says in the book, that the only management advantage that companies will have in the future is their ability to learn faster than their competitors. 

[00:32:37] Allan: All the other stuff you can copy but we need to be learning. We need to be acting on that learning and we need to be doing it. And for me, that is fundamentally what agile is. And if you're trying to cling to some way of working you had three months ago, if you're trying to conform to some company playbook, about the way you should work, if you're trying to follow the same process of the other [00:33:00] teams you're working with. Then you're not learning. You're not changing. You're not moving forward. Your static, not agile. 

[00:33:07] Allan: Now if you're in an environment where static is the right answer, absolutely do it. The best example I ever heard was a closed pension fund where there weren't any investments they weren't affected by changing legislation.

[00:33:21] Allan: They just simply had to invest pots of money differently and they could do it very gradually 'cause with pension funding you've got decades to think over. 

[00:33:29] Allan: If you are genuinely in an environment where things aren't changing and maybe static is the right answer. But most organizations I would challenge as you pointed out, the world changes around us.

[00:33:39] Allan: Who thought three months ago, there'll be a near state of war, the market around us, if your commercial changes, the COVID situation changes! And even within an organization, even if it looks like things are static, it's possible the forces within the organization are not in balance and that people aren't happy with the way things are going 

[00:33:59] Allan: The [00:34:00] developers may be really happy with the way they deal with technology, but their customers are unhappy the development team aren't delivering what they want. Or vice versa!

[00:34:07] Allan: Unless everything in your organization is in balance and the forces around you are not moving.

[00:34:14] Allan: Then you need to be learning or you need to be changing. And that's agile. 

[00:34:18] Scott: Brilliant. Thanks Allan. 

[00:34:20] Scott: So final question. If you had to take one book with you to a desert island and you'd recommend for our listeners, what would it be? And it can be one of yours if you want.

[00:34:29] Allan: Oh, yeah. The problem with all of my books is, I would want to change something about just about all of them, with a couple of them. I'd like to cut them in half. 

[00:34:37] Allan: In fact, I've recently unveiled a book on writing books. I've had a conversation about how I write books with so many people I was going, I'd start writing a book about it. So watch this space. 

[00:34:48] Allan: But if I was to say one book one is a Peter Drucker book that I've never completely finished reading. I might well go back to Henry Mintzberg's The Rise and Fall of Strategic Planning. Because[00:35:00] in that book, he details, how organizations came to believe in strategic planning, the organization's particularly in the fifties and sixties believed they could analyze the world around them.

[00:35:11] Allan: They could define a strategy, they could plan that strategy and then they could execute that strategy and bring it to market. Does that sound familiar? He's got one great expression about how the Pentagon bought into this system under McNamara and asked about the strategic planning process at the Pentagon one American General replied "That died in the paddy fields of Vietnam". 

[00:35:39] Allan: When the world around you changes, when you find you're not fighting the war, you thought you were fighting, in our space today, it's digital technology that means we're not fighting the wars we thought we were going to be fighting. You want, what can you do? you've got to react. 

[00:35:52] Scott: Brilliant. So anyone who wants to work with you, how do they get hold of you? 

[00:35:56] Allan: I am very easy. allenkelly.net If you Google Allen Kelly, [00:36:00] there's. There's Alan Kelly, the tailor in Bromley, Alan Kelly, the marriage guidance counsellor in Wimbledon and Alan Kelly, the Agile Coach in Acton. I'll let you work out which one is me.

[00:36:11] Allan: I'm always happy in having connections on LinkedIn. LinkedIn slash in slash Allan Kelly and I'm Allan Kelly net. Stick that into LinkedIn and stick down into your browser. You'll find me. 

[00:36:22] Scott: Thanks Allan I'll put the links in the show notes as well for people.

[00:36:26] Scott: Allan it's been a pleasure having you on the show. Thank you very much for taking 

[00:36:29] Scott: the time 

[00:36:30] Allan: My pleasure thanks Scott. 

Outro
A big, thank you for listening to the Rebel Diaries show. Your time is precious, so thank you. It is appreciated.

We've got more amazing guests lined up so be sure to subscribe for next week's episode.

The full show notes and links to things we've discussed can be found on the website, www.rebeldiaries.net.

Finally, it would really help us out if you can spread the word with your friends and colleagues about the show.

Take care, be a rebel and deliver work with impact.