Product Agility

The Dumbest Thing I Ever Did in Agile (With Jeff Anderson)

August 14, 2024 • Ben Maynard & Jeff Anderson • Season 2 • Episode 29

Share episode

Send us a text

In this episode of the Product Agility Podcast, we sit down with Jeff Anderson, founder of Agile by Design, and a veteran of the agile change space with over 20 years of experience. Jeff shares his unique journey, from navigating the complexities of large consultancies like Deloitte to founding his own agile consultancy that helps organisations thrive through teamwork and innovation.

Jeff’s candid story about "The Dumbest Thing I Ever Did in Agile" offers valuable lessons and insights. This episode highlights the challenges and rewards of working in environments that don’t always fit conventional molds, and how Jeff's experiences have shaped his approach to agile transformations.

Key Takeaways:

  • The importance of situational empathy in agile practices
  • Why proximity between developers and users is crucial
  • How adversity can fuel professional growth and innovation

Whether you're an agile coach, product manager, or someone interested in organisational change, this episode offers practical insights and real-world stories that can inspire you to embrace challenges and drive meaningful change in your own work.

Tune in to gain actionable advice from Jeff's extensive experience and learn how to navigate the often-turbulent waters of agile transformation with confidence.

Links and Resources:

Connect with Jeff on LinkedIn: https://www.linkedin.com/in/thomasjeffreyandersontwin/

Get Jeff's Book "Organizing Toward Agility" on Amazon: https://amzn.to/4fSDNyU

Check out Agile By Design success stories: https://www.agilebydesign.com/case-studies

Book a Free Change Canvas session with Jeff's Team: https://www.agilebydesign.com/free-change-canvas

Host Bio

Ben is a seasoned expert in product agility coaching, unleashing the potential of people and products. With over a decade of experience, his focus now is product-led growth & agility in organisations of all sizes.

Stay up-to-date with us on our social media📱!

Ben Maynard

🔗 http://bitly.ws/GFwi

🐦 http://bitly.ws/GFwq

💻 http://bitly.ws/GFwz

Product Agility Podcast

🔗 http://bitly.ws/FdVJ

🐦 http://bitly.ws/FdVT

🤳 http://bitly.ws/FdW9

🎶 http://bitly.ws/FdWj

🎥 http://bitly.ws/FdWy

💻 http://bitly.ws/GFuS

👤 http://bitly.ws/GFvy


Listen & Share On Spotify & iTunes


Want to come on the podcast?

Want to be a guest or have a guest request? Let us know here https://bit.ly/49osN80

Deloitte, like a lot of other big consultancies, doesn't follow the advice it's get it gives. And that I mean that in a good way because if you go to a company like Deloitte the Loft and say, oh, you want to do org design or you want to manage a certain way and they'll give you advice that's all very specialized and very like nailing everybody down into one specific thing. It's very planned. But on the inside, you're expected to just be somebody who could take on anything and do anything. Welcome to the Product Agility podcast, the missing link between agile and product. The purpose of this podcast is to share practical tips, strategies and stories from world class thought leaders and practitioners. Why, I hear you ask? Well, I want to increase your knowledge and your motivation to experiment so that together we can create ever more successful products. My name is Ben Maynard and I'm your host. What has driven me for the last decade to bridge the gap between agility and product is a deep rooted belief that people and products evolving together can achieve mutual excellence. Hello and welcome to the Product Agility podcast. We are joined by Jeff Anderson. I wanted to get Jeff onto the show because he's got some fascinating stories, life stories and non standard stories I would say. I think it's something that we can all learn some lessons from because there are certain challenges that Jeff has faced and I think with a certain degree of it would appear like humour along the way, which has got him to where he is today, which is in quite a fantastic position. So I don't want to do them a disservice and say things that maybe the right things to say. So Jeff, welcome to the podcast and if you wouldn't mind introducing yourself to our listeners, that'd be greatly appreciated. Sure. So hi everyone, Jeff Anderson been in the agile change space for the last 20 or so years. I run a firm called Agile by design, you know, has 30 or so an extremely passionate change agents who I'd love to unleash everywhere I possibly can. What else can I say that's about me. I've written a few books that if you're really having trouble falling asleep and you want to read some really thick tile, sort of, you know how to's. It's cured my insomnia anyway, so I recommend them. The first one is the lean change method and it's all about running change like a startup. And the next one is called Organizing towards Agility, which is why don't we change the existing organizational design jargon with something that's actually a little bit useful? What else can I say about me? Husband, dad, two kids, love role-playing games and all things nerdy. Brilliant. Well, you'll fit right in, Jeff. It's brilliant to have you here. And yes, you're an author, a businessman. But yeah, you are a successful entrepreneur and businessman, author, all great things. And you're here today to share. I suppose we touched what I touched with what it was to cover. And where we decided we'll begin was with dumb things. And so, Jeff, given that you've written a book on change related matters and you've got a depth here, 20 years of experience in this field, the question we decided to start with was, what's the dumbest thing you've ever done in this kind of agile change thingy that we are faced with? I think the dumbest thing I ever did is a senior partner and his protege were having a bit of a spat around how to do delivery on an extremely large program. There must have been, I don't know, 10 teams and 10s, if not hundreds of millions of dollars being spent every year, all kinds of politics. And they were having a spat on how to get things done. And on paper, the senior developer was definitely in the right in terms of how to, according to my, you know, perfect opinion around how to get things done. And the his protege, who was another newly minted partner, had less experience. And I felt like, and he felt like was running around with scissors. The older partner said, hey, I want you to go in there and be my sword. Go in there, tell him how to do it. This is how we're going to get it done. They're consultants. They can take it. And and, you know, assess it bias and mandate. And then I went and that did not go well for me, to say the least. So a few weeks in that partner who's the protege, lots of politics involved, went to the head of the firm. This is over at Deloitte. And I'll say the name of the firm, but I won't say the names of the names. And he escalated. I shouldn't have done that because it's just a dumb thing to do. But B, my backer pulled my support from me without telling me. He just let me keep going. But with Plaza, he wanted plausible deniability, I guess, or I don't know what his thinking was. So off I went. You know, kind of here's how we're going to do agile. We're going to do it this way and it's going to be right and it's going to be whatever. And it just landed in my face in the worst possible way it possibly could happen. I had a poor team of coaches who are trying to get things done. People kind of like like the resistance kind of there's a groundswell of like agile versus management kind of type of scenario. It's probably one of the things that helped me get fired eventually over at Deloitte. No one said that was one of the reasons. But you know, both partners ended up not being very happy with me afterwards, right? Big senior partner wasn't happy because he felt I didn't get anything done. The other partner thought I was an asshole, which he probably wasn't that incorrect about. And it was like a real interesting life lesson around don't do the right things the wrong way. If you can't do it the right way, don't do it at all, basically. So, but it's an extreme version of that lesson where at the end of it, I kind of looked at it and said, OK, well, that wasn't successful. But B, what was I doing? Like, why did I say yes? I should have never said yes, Jeff, it sounds to me, and this is a my influences from our previous conversations as well, but in Deloitte, you're a bit of a quite a phrase, square peg in a round hole like you. Yeah, Yeah, you see. Yeah. It just didn't seem like you you fit. I mean, that must have caused other tension and problems for you along the way. I mean, the good thing about working at Deloitte, I wouldn't trade the experience for anything is Deloitte, like a lot of other big consultancies, doesn't follow the advice it's get it gives. And I mean that in a good way, because if you go to a company like Deloitte, they'll often say, oh, you want to do org design or you want to manage a certain way, and they'll give you advice that's all very specialized and very like nailing everybody down into one specific thing. It's very planned, but on the inside, you're expected to just be somebody who could take on anything and do anything. And teams get formed around the initiatives that you have to do. And you don't really have any bosses, people that are more senior than you, but no one person is your boss. Which is interesting because we, you know, at least for me, you know, both the agile world, the progressive world, call it self managing world, whatever you want it we, we ascribe to a lot of those concepts, which is the team should be formed around the value. It's OK to have seniority, but it's, it's not OK to necessarily have a boss. It shouldn't be a reporting line relationship and you should be as cross functional as you can. And so, so those are the good parts of working in the big consultancy firm because they, they really teach you that. I remember the first time I tried to do any type of management consulting, advisory engagement, I didn't even know what those words were. I'm a developer by trade. I like code. I like to write code. It works, show it to a user. So that part's not wasn't so great, you know, showing it to users, but the writing the code part was great. And all of a sudden I'm asked to do, I don't know, an infrastructure advisory assessment, you know, on the performance implications of I don't know, blah, blah, blah. And I'm like, can I just go right to for loop over here? Like, yeah, I was like, so I don't even know what any of these words mean. And that would be the more technical side. And on the other side, it'd be like, OK, let's go and assess the cultural impact of new ways of working. And I'm like, yeah, I don't know what that means. So that was good. The bad part is most big consultancy firms have very few checks on the behaviour of their leaders. And so I had, I ended up having a really good partner who had to leave and I can get into that story. There's a whole story there, too. Biggest risk for the firm did I cause, but then I got replaced sort of working with another partner who's do you know, Kellyanne Conway is she's like a big adviser to Donald Trump, you know, big Trump kind of, you know, fan her husband hates Trump. So it's a really interesting dichotomy. And so he'll go on Twitter and call he's a psychologist. And like, I've just come up with the term to define Trump malignant narcissist, which is a, a narcissist with even more bad behaviour that goes around and start having the nice side of the narcissist. It's kind of like mean all the time, you know, narcissist. That was my boss. He was a bit of a malignant narcissist, you know, and some people could deal with them quite well because they just, you know, put on the positive side. You know, but but the hot just down did all the things and that was just not me. So I had a quite toxic relationship with, you know, one of the people that I had to work under. And he was the person that was put on top of me to sort of keep me under control, so to speak. Lots of fun. How did he do? Yeah. How did he do? How did he try and exert that control over you? I helped one a bunch of business and, you know, helped land probably one of the biggest engagements at the time for the firm. And he would say, oh, because we the US is in charge of staff and he'd say some other parts are stopping. I can't put you on that project. So he'd like waylay me on two different projects, but wouldn't tell me, but tell other people. So you kind of do the you wouldn't do it directly. He'd go around me basically, or he'd go to my team and say, you know, you shouldn't listen to Jeff. You should listen to this guy over here. He's got a better future, you know, he'd do kind of stuff like that. You know, so there's lots of like, sneaking and sort of backslide backstabbing and, you know, just what? And so it's never quite out in the open. It was all kind of like just, you know, around the corner and, you know, give me a $1000 bonus for the year or something like that. Like, it's kind of like, you know, when you give a waiter A1 cent tip to literally do stuff like that. So I mean, when we were having our conversation, there was a particular post, which I was from LinkedIn that I was made aware of. Yeah. And at the top of the post, it says, yeah, partners didn't trust you in front of clients, like alone. You some kind of chaperone. Was that the the same time or so when I first started at Deloitte? It was for my technical skills. I was good at content management, which was a big thing in the early 2000s. And so I got hired as a developer and got put in a software architecture, sort of software architect position. And clients didn't trust me in front of clients. And that was my own fault because I was the kind of person in a big meeting with an executive and exactly would say, hey, you know, I don't like that. I have to do like, hit some data, hit submit, then it comes back and tells me it's wrong. I want to have it in the page. And I'd be like, oh, well, you know, you have to use it with JavaScript. So if you want to code it twice, I guess you could do it that way if you wanted to. Like, you know, like in that kind of voice from The Simpsons, right? Yeah, exactly would just look at me like I was a complete a hole and everyone would be kind of almost like embarrassed for me basically. So that's why people didn't trust me for the clients because, you know, I was that guy, right? Conceited development. I mean, maybe that they're the point. Perhaps. You know, yeah, no, they they did have an actual point. The problem with my life back then is I'd gotten into Agile purely because of the developer joy part of it. Testing was better, integration was better, just made work more fun. But I hadn't really taken to the idea that you've got to actually work well with other people in order to get to just get anything done and being just to be taken seriously in a room, you need to kind of just be a little bit empathetic about. That's the one thing that Dwight taught me. They they have a bad word for it. They call it professional hygiene, makes it sound like you're dirty if you don't do it and it's kind of pejorative. But I call it situational empathy. Like so if people are used to clean looking presentations and they're not used to any other form of communication, don't start with scrawling sticky notes all over the place. And kind of going, you know, like who it's time for agile, like meet them where they are, get some credibility and then go do the thing that you want to do, you know, because they, they start to trust you. So I was my first foray into learning situational empathy that that that manager who told me that, by the way, was instrumental to getting me from, I don't know, senior consultant to senior manager in like 2 years. I was like the over age developer at a consultancy and all these young kind of smart a type MBAs. And I'm like the over age developer kind of going, what am I doing here? And he, he kind of smacked me around a bit. You know, it's kind of like some parents kind of beat you and then tell you they love you and, and kind of help you be better. He was one of those kind of guys definitely gave me the support I needed to move forward. And then problem is, is once all those guys left, then I was like, oh, I'm in trouble. So, you know, that was actually, that was pretty helpful. Part of my frustration there was it got so bad that I actually lost the use of my hands during that time. And I started developing this chronic pain. And so I had to go on disability for a while, which if I give one message to anybody out there, if they have to go on disability or lose work or whatever, you're not your disability, You're not your pain like, like it's not you. It's something that's happening to you and you can overcome it. Because I came back to work with my hands still not working, but at least being in less pain. And I felt like an art critic who couldn't see, like a blind art critic. I was like, how am I going to do this job? And immediately got thrown into more advisory type stuff. And that's when I was like, OK, I've got a bunch of young kids who want to help. They don't know anything. They're just fresh out of school. I got to do a whole bunch of work that I don't know anything about. So learning how to, I think that was my first understanding of how to actually work in a team and how to mentor others because I had no choice. I was going to, I was going to either do that or I was going to be, I was going to be out of a job for sure. I couldn't get anything done. So do you think you would have come to that realization in the end anyway if you hadn't have had that? Yeah. Lost the use of your hands. I was always good at mentoring other kind of like bright young sort of kids fresh out of school, so to speak, like, but on the programming side. But what this did is it forced me to, every engagement I got on, even if I was staffed by myself, the first thing I would do is get a lay of the land and say, where can I get leverage? And leverage is like a fancy consulting term for getting some junior beans under you to kind of get things done. And that would be my first job. I'd go in and I wasn't doing it Machiavellian. Like. I was just more like, OK, I found some areas where I can provide value. I think I understand what that value is. Hey, you know, I could get somebody doing this full time and then get the person to say, yeah, so leverage became my first point of value. And then mentoring people with what I knew. It actually, I had a number of people saying I was the coolest person they ever worked with at Deloitte because all I did is level them up. But yeah, I can't I have no, no other abilities. I I can't even I could barely send e-mail voice record so bad. I'll tell you a story about an e-mail was sent. I sent it out. This is funny again, one of these engagements, I have no idea how to do the work. So I'm reaching out to every architectural subject matter expert I can find to help me with this infrastructure data OPS thing. And my voice recognition for some reason, like to translate subject matter expert into sluts is just, I don't know, it's, it's kind of nowhere near close to that. I mean something right? So, so, so I send this thing out to every senior manager and partner and say, you know, need some help from some architectural sluts. And you know, I'm like, Oh no, I'm going to be in so much trouble. Again, this is with a different senior manager. He's really cool, really helped me in my career as well. And he just laughed and said, I don't just send a reply, I'll say, you know, I use voice recognition and sometimes it makes a mistake. So I did that. No reply. So I think I'm in serious trouble all of a sudden read architecture slots. I think I know somebody over here forward the architecture slut e-mail didn't die for about 3 weeks. It's just just read forward kept going and going. No one said a word. So you know, that's the thing. I wonder if they were they recommended different people if it had to come through as it was intended. I wonder did you get Yeah. Oh yeah. You're not the architecture subject matter expert of infrastructure. You're the infrastructure slot. OK. I mean, that's not even going to go deeper on what that really it was a question that's been mulling around my head, right? Is that you said you've got into agile because of a developer joy aspect to it. But then I think that the one thing that which organizations miss people to miss or they avoid is that for me, one of the most critical things. And I think you say it's critical just because I think everyone has overlooked it, which is that that proximity between the people who are receiving the thing and the people that are creating the thing. When I first said business people and developers, and I've lost count on the arguments I've had with people saying, well, when they said that I don't think it meant a product. I think it meant the people who were receiving the thing give it actual feedback as much as possible. Absolutely. And then people will say, oh, well, you know, they make up shit excuses like, oh, that's that's what the approach to the role is for. If they go and talk to the users and then come back and they represent the business like no, isn't it was made for. And then people would tell and say, Oh, well, you know, these these developer sorts, they didn't want to talk to her. Like, you know, they ain't got no social skills. They've asked Jeff. He likes to sit in this closet and just write code and then appear every now and again, right? He's like a mushroom. You've got to keep them in the dark, you know, and then make a mushroom. That's great. And people have said that about similar developers I've worked over the years. And they just overlooked that for whatever reason, right? Oh, it's not important. It never meant that. And then all that was bullshit, right? Because it's one of the most important things we can do. And yeah, you. Is it fair to say that you develop this you required because of the awful situation you found yourself in, which is you lost the use of your hands and you had to develop those other skills. Now it's wondering in your experience, when you're just in your opinion, like what does it take to help developers? People are very technically focused who maybe don't want to engage with it, feel like they can engage the users or the customers directly. Like what does it take to help them go on that journey? Yeah, or, or is it just a lost cause? Well, I mean, there may be some technical people who fit the stereotype and don't necessarily want to spend a lot of time, but it doesn't mean a they, if they didn't spend the time, they wouldn't get good at it. So I think what's missing from a lot of these, even these like agile transformations is simply opportunity. What are the things I like to do? And we, we call it different things based on what the client wants to call it, but team distance. And so like team customer distance. And so, you know, often you'll have a team and then team will work with the product group and then the product group will work with Rd. Then Rd. might talk to the line of business representative who talks to the geographical Rep. Like there's seven hops over to the customer and we sort of say, OK, so are we going to get that down to three or two or one? Or how do we get it to 0 occasionally? So I mean, that lesson I learned a long time ago, my first, my first job was working for my dad. I'd skipped the whole university thing and just done some night school type stuff, which made it hard to find a good job. And my dad and my older brother were investment advisors. And this is, you know, we're talking the early 90s now, but they, he had had a computer on his desk since the early 80s. He was a bit ahead of time. He had his own database. So they'd asked me to update their portfolio management system. And I was working on half a screen here and half a screen there and over engineering this thing over here and doing all the things that somebody with undiagnosed ADD would do if given, you know, kind of access to a big system and started building it. And my dad just basically wanted to find me basically. And my older brother's like my older brother, bless his heart, came to the rescue and said, no, dad, we're not going to fire Jeff. We're actually just going to spend time with him. We do that instead. Like, you know what a novel idea, right? And so my older brother worked with me for an hour and said, here's I want to get done. And then he'd leave for the day, come back the next day. And of course, I only hacked it and three other things. He's like, no, you're gonna finish that screen and only that screen. And we basically worked in sprints of a day. And then, as the trust grew, the Sprint's team maybe to about a week. But I just got one thing done, showed it to him, got the feedback, fixed it, did it again. And so that kind of when Agile first came along and I told that to my dad, he's like, oh, like that's that thing you did with me and Tim, like back in the, you know, back in 1992 or something. Like, yeah, except for not really, because a lot of people doing Agile aren't really doing that. So we're, you know, I'm trying to help them actually do that thing, you know, like work, work with an end user and get a small piece of work done and get their opinion. You know, like, not complicated, but very complicated for some reason. Yeah. So, yeah. What does it? And if someone's listening to this now they're wondering, OK, they're in a situation where they are working with teams and this could be the product coach, it could be an agile coach, scrum master. That's somebody in one of those positions who's wondering, well, yes, I've got the team. Yeah, there are there are people that I would love to get closer and we're only a couple of hops away from the customer. But it isn't so much that they can't make it happen. It's just that they from the the team, the individual perspective on that team doesn't really want to do it or is kind of struggling to get their head around it. Have you got any advice for those people? I mean, most of my experience has been the teams don't have permission to do it. One thing I like to do is, is one of the things that I did that is a Frankenstein monster that I just, it worked once and then it didn't work 10 times. So I don't want to ever do it again. It's just like agile maturity assessment. Like let's measure our agile success by, you know, how good you are at, you know, flowing stories through or how good you are at, I don't know, thin slicing or whatever you want to call it. All good stuff to do, but just don't measure that. Measure the operating model itself and then make changes to it. So one of the things we like to do is measure how many times has a team talked to their customers and executives love dashboards, right? So if you can get it on a dashboard and you can kind of show like, you know, like lots of frequency, not a lot of frequency or lots of feedback, not a lot of feedback, load feedback and put everything together and say, hey, this isn't like we're not here to punish teams, but we're going to remove the barriers like a septic expectation, you know, if you want this team to survive and thrive, speak to your customers. And then B, what can we do to get I've got a flying minutes that'll just add to the humor. What's in the way? And some people might be like, I've never spoken to a customer before. We don't have those skills. OK, let's get somebody on the team that's going to not be the social person for the developer, but pair with you, coach, make it easy. You know, maybe go with you the first time, show you how to do it, you know, like that would be a pure developer that you know, that pure developer team that's maybe never done that. Just get in there and pair with them and kind of coach them how to do it. Then some other places there's all kinds of organizations that are just in the way. Oh, you don't like they they're ones that own the customer. So often we'll be like, well, it's important that the teams are close to the customer, so why don't you come along too? And we do that sort of bring them along, get them there, get the trust of the organization and the credibility that this team can do that and then back off and let them go do it. I really, I really think a lot of people say I don't want to. And it's more like, A, I've never done it before. B, no ones allowed me to do it before. Excellent with that kind of side Ave. explored right, I think because I was just intrigued because you were in a put in a position where you couldn't use your hands, so you couldn't type, you couldn't use a mouse around and that that's been really a lot to deal with. I just and this is me being a little bit nosy here, but what on earth was it that caused that that break between your brain and your hands? Like what what it's a chronic pain condition. That undiagnosed chronic pain is the official no says and started in my shoulders and then I moved to my hands and then eventually we can get to the point where I had lost the ability to walk without excruciating pain. And so I still have this condition, but you know, high amounts of stress will cause it to so or an injury could inflamed it and then get worse too. So there's like a mixture of physical and definitely stress makes it a lot worse. Because I noticed for a fact, because the second time I went on medical leave, I'd started with my hands and moved into my hips. And it was just the dealing with a bit of a, you know, a toxic sort of narcissistic boss who's basically taking credit for all the work I was doing as well as undercutting everything I was doing and trying to do chiropractic and none of it working. And it took the birth of my son, which by the way, next door we had a big beer store in Ontario. You have these big beer storage with huge parking lots and you've got a whole kind of like cautery of local homeless or almost homeless people all hanging about. And it's, it's quite the zoo. And this is my wife's second child. And we're on our way out the door and we don't make it past the parking lot. The baby comes out basically. Yeah, it's at night time. So we didn't have the typical zoo of people there at least. But there was like, you know, first of all, the first thing I did was like, I almost had a heart attack. Thank God we had a doula who decided to meet us there and not at the at the hospital. Yeah, she just comes running out the car with a blanket in tow. Down baby out on and I'm like then I breathe then I'm like looking at this sort of picture of my wife lying down on this blanket this baby here and it says the beer store. I'm like, OK, so I had to take a photo of that and I send it to my family immediately and go baby something like baby's born in parking lot. Turn the phone off get my back to the hospital. You do where you know all the thing turn the phone on the next morning and of course you know I've got like 9000. I was like, is this Photoshop? Is this really nice poor mood in the sky, you know? Yeah. God, what a story. You had some. You had some. And I can wings happen. Yeah. And then I can walk. So after that, I was like, oh, my legs feel better. Really. So what was it the stress of like pure opportunity podcast conversation, but I'm intrigued now, right. It was, yeah. Was it the baby was born event that was like the some subconscious weightlifting or weird like some adrenaline slash. My brain shifts like it's really. A lot of people suffer from chronic pain and the worst thing that you can do for people with chronic pain is, you know, give them Oxycontin and have gonna say, yeah, go away. Like I I totally avoided the the painkiller drugs and tried to be as like I wrote my first book while suffering through all of this chronic pain. And this is quite interesting. I couldn't use a mouse or a keyboard so that what I could draw. So the way I wrote the book is I would do these little hand drawings and I'd lay them out on a big sheet of paper. And I had a tripod with an iPhone, and I'd take a photo and then I'd voice wreck it and I'd move the photos around. I'd use voice recognition. And eventually I got a whole book full of pictures and writing that I got somebody to kind of like soft copy for me, basically. So that got me through my first kind of like, burst of pain. It's like, you know, just doodling away basically. So the reason I tell that is because my occupational theatry said, Jeff, yeah, you've got a really active brain for someone in this much pain. Most people that suffer from pain, they suffer because they're suffering. It's if you stay active and stay moving, eventually the chronic pain goes away. So, or it goes down, you know? Yeah. And so then you, you were getting through all of this. And then at some point, Deloitte, your job went away like it was amazing. What came first? What, what left first to paint up a job? Oh, certainly when my job left, I lost even more pain for sure about that. I didn't. You know, The funny thing wise is that I told you about that little partner civil war I got myself mixed up to and now two partners hated me, which is never a good thing. I was also working on an agile transformation out West in Calgary, which is a big oil and DAS area, and the price of oil had just bottomed out. And so all the agile people were considered fluff and just gotten fired off the engagement. But there's also a bit of a perspective that if I had done a better job, I could have, you know, kind of mitigated that. And so I went from a lot of people loving me to a lot of people not liking me so much. And then I was working with, I have not named this other name, but it's a pervera of big agile software who was like, hey Jeff, you've got a client and they want to do agile like in a big way. Do you want to help? I'm like, let's get Deloitte to help. Turned out when they priced it, it was like a $70 million job. So when you think it was nuts, it was, I don't know, or $7,000,000, I don't know. I'm like evil 8 billion gazillion jillion dollars. It was a lot of money. And the bigger a job is a Deloitte that you're selling, the more you have a risk process in place. Partners need to look at it. They need to make sure they're comfortable with it because you can get sued for that amount of money. You want to make sure you can deliver and it's all good stuff, right? I was working with a partner in the States because it was an American client and an American software vendor. And he was like, well, we're never going to get through the review process in time these things due next week. Why don't we make the bid, give it to the software vendor, They kind of brand, it's their bid, and they'll just mention that they should work with us. And I'm like, OK, sure. I mean, technically legal, technically feasible, We won't get in all kinds of trouble. So we do that. The team doing the presentation is packaging it up. I'm on a plane from Europe, so I was doing a little bit of a book tour with Deloitte on all the agile stuff I was doing. And so I'm not even around when this is happening. The software vendor gets the date of the proposal, the time wrong. So they've got our proposal, but our guys didn't scrub the Deloitte stuff from the proposal. They gave it to the vendor to do it and then they panicked because they got the time wrong and so they rushed it. And so when they sent it, it had all kinds of Deloitte stuff on it, including a whole bunch of like partners that I directly worked for his names on it. So all of a sudden, my partner's names are on this $7,000,000 proposal that they don't even know about. It's not going to prove this, not with whatever. And that team's about to get into a holy blast of hell. And I'm like, and the US partner is saying, oh, I never said anything about this because he just went like, he had his own issues to deal with. So he just, you know, kind of rolled out his belly and just denied any involvement. So I just looked at it and went, I think I could see the writing on the wall here, guys. It was me. It was all me. I just kind of volunteered and sort of said, yeah, yeah, yeah, yeah, yeah. Just send up my way. It wasn't this team. It wasn't this guy over here. Like, I just, I just took it all, basically. Wow. That was it. Nice. But I was happy if the person was like, Jeff, we've had some good conversations and some tough conversations, and today's gonna be a tough conversation. There's your final day. I'm like, oh, that's not a tough conversation at all. Like I'm gonna, I'm not really deal with The best part is this, he gives me my papers, which has an NBA and I can't work with any competition and all that kind of stuff. And if I if I'm a good boy, I get a year's pay. But but on my you know, I looked at my contract when I brought on this contract said I had to be a good boy for six months. That one said I had to be a good boy for a year with no pay. So I got six months of not having like only six months of non compete. So I was like super good deal, right. So I was like, this is great. I'm glad they don't read their own paperwork. And I just signed it off I went. It's quite happy. Yeah. And what have you never looked back since? Oh, God, no. I mean, the only way I look back is I went and I called up two of the people that this is my generation. I had these generations of agile teams who had gone up through the firm and become much more successful than I was. And I take the next batch and throw my latest batch of the two most senior guys. I called them up and said, listen by myself, I'm a one because I've got energy, I've got enthusiasm, but I'm a mess. I'm all over the place, right? Like, I'm a crazy man, you guys are, You're creative, but you're structured, you deliver well, you've got stamina. We get together, we're going to be A5 or A7 with the three of us. So I talked to them both and then they both convinced each other and then they both laughed and kind of joined me. And then we grabbed a few more folks, you know, not, it wasn't like a route, but like a good 10 or so crew. And yeah, never look back. Amazing. Thanks. And what type of work are you, you and your organization doing now? Well, it started out as very much and it still is. We're called Agile by design, which is, you know, like we're not the agile by accident kind of guys over there. We actually think about what we're doing. You know, that's a bit of a yeah, but a bit of a shot at some of the stuff we've seen. And it's it's very similar to the work we did at Deloitte, but it's it's evolved. Agile is becoming less and less important and and really. Helping organizations understand how awesome they can be by putting people into teams and getting them close to their users is basically our mission. And helping them understand what their outcomes are and how to kind of get that into execution through teamwork is our big goal. Yeah, it's quite a journey. And in the midst of all of that, two books as well. Yeah. So the lean change methods, the first one, and that one came about because at Deloitte, I was, as I was learning. So as I was growing up at the same time that I was growing up. So I'm a developer. Agile was all about development. All of a sudden agile estimating and planning comes out and I'm like, oh, I can use sticky notes to talk with other people about what they're doing too. And then as things like the Kanban method came out, I was like, oh, wait a minute, I can actually look at end to end kind of organizational dynamics. And there's a lot more to Kanban that people think in terms of like collaborating around the work in real time and disbanding. And there's lots of organizational patterns that I was able to unlock. And then I was getting into sort of more product development stuff, lean startup, and that's where the real shift happened because I was learning about consulting at the same time and doing things the consulting way. So it's kind of like, oh, we've got to have a change plan and a road map and, you know, 20 page deck of all the things we're going to do and a capability model. And you know, like, that's the classic consulting model is you've got to spend a good three to six months building a lot of PowerPoint before you can make any meaningful change, you know, and you know, all assessments and all this other stuff. And by the time I got to my third agile change where we would do that and then we would start like, OK, let's stand up some teams or get some flow going or do anything. None of the plans make sense. And it didn't like make a little bit of sense or I was kind of off. It was so off that it's like we had just tried to, you know, ask him to see Gito to give birth to an elephant. Like it just brutally wrong. On a couple of those transformations, we were still there to kind of help massage things in a different direction. So, so one of these transformations, we are asked to re centralized it use Ontario public sector. They love centralizing their IT functions. Used to be you'd have one ministry, one IT function. Now they're like, no, we'll have three or four ministries with an IT function and everything will be so much more efficient. And we were asked to help with that and we're like, well, we'll help and we'll make it not so bad by putting Kanban up so at least we're visualizing things and get it going. None of the Kanban systems work. No one was talking to each other. There was like there's no synergies to be found anywhere at all. Like the top upfront, like we weren't a fan of what the design was anyway. It was a specialist centralization design, but. I'm new enough to consulting and not having so much hubris and I'm like, well, as long as we get the right teams in place and get the right cadences in place, it should be fine. And it absolutely was not fine because you had geographic information systems developers off in the country over here, and yet people were worrying about assessing the toxicity of, you know, building sites over there. They had not their businesses that have nothing to each other. So we started putting Kanban in place where they were, in the local areas where they were. And the good thing that came out of that was you don't need to be high end developer to be successful. Like this is public sector, unionized legacy code base. And the amount of pride you saw in this group's Kanban system and watching them try to limit work in process and lose every time, but still getting it somewhat under control, like the amount of pride they took improving things really sort of opened my eyes. And so I came up with this thing called the Lean change method. And, and the lean change method is this idea that if you're a bunch of change agents in an organization, you're a startup and your customers, the organization, and you need to get as close to them as possible and iterate on the change as frequently as possible. I mean, not rocket science or anything like that, but by formalizing it and putting a method behind it, it allowed me to sort of combat some of the others in the firm who wanted to do it a certain way. I'm like, you can't do it that way. This is how you do it. And here's a book even says so sort of helpful from that end. David, in your book, do you cover how to motivate people? Because I think that's one of the missing links with a lot of this is that there's methods and suppose you can approach it and certain attitudes you can take on. But if people don't give a shit about the change, then I mean, it's going to be difficult to get an attraction. So do you have any tips with people who find themselves in situations where yes, there is a change happening on the horizon and they're wondering how enough to actually motivate people, right, get involved. Yeah. The big one that worked for us, me there is we had two sources of motivation. One you think would have worked, but thanks to the one of them was around motive like purpose and urgency. And in big enterprise organizations it can be hard to get to purpose and urgency. But we did have that lever to pull on and in some cases it was appropriate and it worked. The other big lever that was I think much more successful was Co creation and agency. So we'd have these, I don't know if you've seen these big lean startup canvases where people plot out their businesses. So we created a change version of that and we kind of walk in with an open like a blank poster and sort of say, well, like what are you trying to achieve and what's in the way? What are the problems like what's stopping you from being successful? And for each of those things that were in the way, we would suggest sometimes a very out-of-the-box agile countermeasure and then we have to do a bunch of education or sometimes we just be like, oh, so you guys need to talk more often. Or oh, we need to nail down some of this engineering over here or oh, you don't have access to the operations. We need to get operations here. So we created a very bespoke change plan for every team and it was their plan and we'd visually manage it. And so we didn't start with this big a agile. We kind of came in and said, hey, we're here to help with like new ways of working. Let's Co create this with you, visually manage that change with you. By the time we got to the agile stuff, they're already used to a visual board because we're managing their change that way. They're already used to a canvas because they'd seen one. We might have mapped out some of the processes they want to do using a story map. And so we started like, it's kind of like sneaking in agile in the name of doing what they wanted to do. So sort of that Co creation and agency is quite a good motivator. I can talk more about some of the other stuff I've done later, but like at least out of that book, that was the big idea that if you Co create things and you give people agency and ownership of it, they'll get a lot more done. And if you just sort of come in with the big a agile hammer and say that will shout track velocity or you know, whatever. So very with that, people are turning up and they are contributing their own problems that they want to be solved, given them an opportunity to solve that problem, providing them with skills, ideas exactly to yeah, to solve that which happened to be from the agile Canon. So by the time it actually kind of gets around to maybe so the next kind of few stages of this, they're already used to a lot of the things which are going to be espousing anyway. Right. Exactly. I mean, rather than people don't like to be lectured to and taught over long periods of time. So getting into their work as quickly as you can and making it real with their work and then giving them choice. I think, I think it was one of the people that worked at my firm. I went on a tour and I, I had gone on this for myself, but he he went on a tour of all these Toyota plants and there's no standardization across the plants, but they all had similar looking tools and techniques because the, the, the the principles and the values and all that stuff was taught to them. And yes, there were people were told there are examples in other places and people sort of naturally gravitated to the same kind of things. So it's kind of interesting. Amazing. Yeah. That is really interesting. Yeah. I'd love to impede that more, but just keep an eye on this clock. And even though we had a few technical difficulties at the beginning, which will probably be on the edit room floor of a tub, this is released. It's probably time for us to start bringing this to a close. Jeff, I kind of. Wish that we could have done this in person because I think it been nice for me to have a go on your arcade machine you've got in the back. But you know, ever in. If you're ever in Toronto and you feel like coming up to Prince Edward County, just let me know and let me know, mate. Yeah, no, like, well, let me if you want to invite me over for some reason, you know, if you ever need any lean UX or large score scrum training, let me know. I'll come over. I'll come over. Yeah. But thank you very much for this time. It's been really, it's just been so nice listening to your story, right? Because I think that's too often that podcasts are, you know, covering some of the basics of agile or products. And but the one thing I really hope that and everyone listened to this, I hope you appreciate it too, is just people telling real stories about challenges and things they've ever come. And I think there's probably lessons we can all learn from the journey that you've been on. I mean, one of the lessons I'd love to just leave with everybody is when I started running my firm, I was really like, this is not going to scale. I've got a few great people and you know, it's hard enough creating a big team at Deloitte. Forget about creating a big team. You know, not that I needed a big team, but it's just not going to scale. And what I noticed is we paid attention to finding people that had faced similar conditions, were frustrated by it and had tried to do something about it. And that became our hiring criteria. I mean, along with the ability to communicate and be supportive and situational, you know, all the learning stuff. But we didn't look at a single resume and we didn't hire. I don't think we at a, you know, the 30 or so folks we brought on board, maybe two of them had agile experience. Is, is so the lesson areas, don't be ashamed of your adversity. I think your adversity actually, it's adversity that makes you into a stronger performer and a stronger professional. Well, awesome way to end the conversation, Chair. Thank you so much. And I couldn't agree more. And everyone listening, I hope you also agree to that. I would love for you listening wherever you may be, just to take a moment to get on to LinkedIn and let us know what you think of this episode. If you follow the Product Agility podcast, you'll see that there have been plenty of promotion for this episode. So comment on a post, start your own post perhaps, and let us know what it was you loved about this episode, perhaps what has inspired you to make a change and overcome some of your own adversity. So yeah, that just need to say. Jeff, thank you again for coming on. It's been an absolute delight. If people did want to contact you, I assume LinkedIn is the most convenient place for them. Yeah, absolutely. Connect and LinkedIn or agilebydesign.com. Either way, Agile, bydesign.com. We'll get those details put into the show notes. And everyone, thank you. They're very much listening. We should be back again next week with another fantastic guest. Who that is? Well, you just have to subscribe to the podcast to find out. Thank you for visiting. And Jeff, thank you very much for coming on. Really great to be here, Ben.

People on this episode

Head Shot

Ben Maynard

Host