TopPodcast.com
Menu
  • Home
  • Top Charts
  • Top Networks
  • Top Apps
  • Top Independents
  • Top Podfluencers
  • Top Picks
    • Top Business Podcasts
    • Top True Crime Podcasts
    • Top Finance Podcasts
    • Top Comedy Podcasts
    • Top Music Podcasts
    • Top Womens Podcasts
    • Top Kids Podcasts
    • Top Sports Podcasts
    • Top News Podcasts
    • Top Tech Podcasts
    • Top Crypto Podcasts
    • Top Entrepreneurial Podcasts
    • Top Fantasy Sports Podcasts
    • Top Political Podcasts
    • Top Science Podcasts
    • Top Self Help Podcasts
    • Top Sports Betting Podcasts
    • Top Stocks Podcasts
  • Podcast News
  • About Us
  • Podcast Advertising
  • Contact
Not in our directory?
Add Show Here
Podcast Equipment
Center

toppodcastlogoOur TOPPODCAST Picks

  • Comedy
  • Crypto
  • Sports
  • News
  • Politics
  • True Crime
  • Business
  • Finance

Follow Us

toppodcastlogoStay Connected

    View Top 200 Chart
    Back to Rankings Page
    Technology

    Agile Mentors Podcast from Mountain Goat Software

    Mountain Goat Software’s Agile Mentors Podcast is for agilists of all levels. Whether you’re new to agile and Scrum or have years of experience, listen in to find answers to your questions and new ways to succeed with agile.

    Advertise

    Copyright: © 2023 Mountain Goat Software

    • Apple Podcasts
    • Google Play
    • Spotify

    Latest Episodes:
    #118: The Secrets to Agile Success with Mike Cohn Oct 02, 2024
    Show notes

    In this episode of the Agile Mentors Podcast, Brian Milner and Mike Cohn reveal the keys to achieving lasting success with Agile methodologies. From embracing experimentation and fostering a culture of continuous improvement to improving communication with consistent vocabulary, they offer practical, relatable insights for Agile practitioners at all levels. Overview Brian and Mike discuss the essential ingredients to Agile success, touching on the power of experimentation, the need for flexible coaching, and building a culture of continuous improvement. The conversation dives deep into the importance of effective communication within teams, especially through user stories and consistent vocabulary, ensuring that Agile teams stay aligned. With personal anecdotes and actionable tips, this episode provides a roadmap for anyone looking to excel with Agile. References and resources mentioned in the show: Mike CohnEssential Scrum by Ken RubinAgile & Scrum Glossary#85: Effectively Managing Dependencies with Ken RubinDependencies Are Killing Your Agile Flow at Scale by Ken RubinCreating a Software Engineering Culture by Karl WiegersPrivate Scrum & Agile TrainingAgile For LeadersWorking on a Scrum Team ClassesStory Writing WorkshopJoin the Agile Mentors CommunitySubscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection. Auto-generated Transcript: Brian (00:00)Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today we have our favorite back with us, Mike Cohn is here. Welcome back, Mike. Mike (00:12)Thanks, Brian. It's good to be here. Hi, everybody. Brian (00:15)So happy when Mike can make time and be with us here on the show. Obviously Mike has a lot of wisdom and experience to share with us. So we wanted to bring him in because we were talking about doing an episode titled The Secret Staggile Success. I remember back in the day in the 80s, was a movie called The Secret to My Success. There was a really obscure movie. was Michael J. Fox. Yes, it was Michael J. Fox. Mike (00:37)Michael J. Fox? Yeah, so it's not that obscure. Brian (00:41)But I still hear that theme song in my head. when we talked about this title, that's what I thought about. But we wanted to talk about maybe some hidden things or things that aren't as immediately apparent to people that are crucial to being successful when you go agile or if your teams are working in an agile way. So let's just open things up, Mike. What's one of the things you had thought about when we talked about this? Mike (01:10)think the number one secret to Agile success for me is being willing to experiment, to try new things. And if you think back, Agile itself, Scrum itself, began as experiments. They were probably teams going, know, this waterfall stuff we've been doing doesn't work. Let's try something different. Somebody else went, yeah, let's do something unusual, and let's try iterating or something. And so Agile itself began as experiments. And yet I see teams kind of get stuck in the mud and not willing to experiment. And I think that's to their detriment. We want to try things out. And silly, trivial examples, try different sprint links. Don't do a one -week sprint link and go, Agile doesn't work. It's not for us. No. Brian (01:52)Yeah. Mike (01:59)Maybe one week sprints are for you. Try a three week iteration or I try something different. And I think the the idea of experimentation is how we come up with new ideas. It's how we learn. It's how we get better. And so if you're going to succeed, you better have that that focus on experimentation. Brian (02:19)Yeah, there's a surprising number of Scrum Masters I've encountered that I'll hear stories about how they run the same exact retrospective, every single retrospective. And I just think, what are you doing? How can you be trying to communicate this and teach the team that this whole thing is based on doing little small experiments and seeing what the result is, when you're not willing to try something new in just how you run a retrospective? So yeah, I completely agree. I think the key there for me is demonstrate it. If you want them to pick up on that, then do it yourself. Mike (02:56)worked with a company years ago that fired their scrum master for basically for being too rigid. He had read something in Ken Schwaber's second book, and I don't want to pick on Ken's book, but he has this wacky sentence in there, and there are wacky sentences in my books, right? So somebody can go find those, and I mean, I get it. But anyway, Ken wrote that the daily scrum must be conducted left to right, starting with the person on the left of the scrum master. And it's like, what? Why is this mandatory? It must be left to right. Anyway, this guy read that in the book and insisted that the Daily Scrum be left to right, starting with the person on left of the Scrum Master. And his team knew that was insane, right? It's just nuts. And so they would mess with him. They would do things like he would call on the person to his left and the person on the right would start talking. he would point to the person on the left to start and they were standing in a semi -circle. They would move, right? So the person on the left was no longer on the left. And they were just messing with him over this. And he would just get mad and insisted it had to be left right because the book said so. And I don't know what it was with him, but he was just stuck on this. Ultimately ended up getting fired for it. Yeah, I heard this story because I ran into him at a conference and I saw him there and he Brian (04:14)Wow. Mike (04:20)looked a little down. It's like, you know, said his name and how are you doing? And he told me this story. And he said, you know, he'd gotten better since then. But, you know, don't get stuck on things. It's just not the it's just not a very agile mindset. Brian (04:34)Yeah. I mean, if you can't, no matter what it is too, I think that if you can't point to what you hope to achieve from doing it that way, or what's the purpose behind us doing it that way, that's questionable part of your process to just say, I can't point to any reason why this, any good that this thing does going left to right person by person, but. Ken said we should do it. I guess, no, I mean, if there's no reason, if you don't see the benefit in it, why would we do that? Mike (05:07)Knowing Ken, I think he was just trying to make it easier for people. Here's one less thing you got to think about. Start on your left and go around the room. But the way it's written and the way this guy interpreted it was like, shalt go left to right. It's like you've got to be willing to, I think, out the way that a known proven way start out that way. So yeah, go ahead and start left to right. It says so. I don't know any different. Might as well go this way. Brian (05:17)You Mike (05:35)But then experiment, learn, figure it out for yourselves. I I can't think of a successful company or team that I've worked with that ever quoted this Scrum Guide at me, right? You know, they may start out exactly the way a Scrum Guide says, or my favorite is Ken Rubin's Essential Scrum Book, start out in a known proven way, but then experiment, make agile your own. Don't throw away the important stuff, and that's why you have to start in a known proven way, but as you get experience, experiment, throw things out. Brian (05:46)Yeah. I love that. Yeah, I think that's a really good one. So a good one to start us off. Thanks for that. Mike (06:12)Yeah, that's, that's what I'm buying. Brian, can I ask you for one of your secrets to agile success? Brian (06:17)Sure. Well, and this one I know it's going to be a little, know, boy, it'd be nice if I could do that, but I, you know, we can't do that. And I understand that this is not going to be for everyone, but one of the things that I think is important is to have some kind of a coaching presence. Now, just to be clear about this, this doesn't mean that you have to, you know, fight tooth and nail to hire some outside consultant or anything like that. I understand budgets are tight and there may not be an ability to do that. But I think if I, you know, if you're a scrum master, then I think that having the ability to continue your learning journey and grow is really important and, and having someone you can go and bounce things off of. So if you can't have someone, if you, if you can't have someone on staff or someone there that's an outside consultant that can help you and coach you through the early stages, I think that could be really, really helpful. And to me, it's an accelerator. I think that kind of thing is something that can really, yes, we will go through training. We understand kind of the basics, but then the coach is sort of like pouring gasoline on that fire to say, now we're going to go from zero to 60 and I'm going to help you get there because I know the pitfalls to look out for and I know how to get you there. But if you don't have that ability, I think it's important to maintain some of those mentorship relationships that you can find through different community groups. Mike (07:18)Mm Brian (07:44)Maybe you'd find some kind of a weekly meetup or a monthly meetup or something that you could go to. Even if it's just a meetup of peers, right? There's not someone that you would say, that person's been in this for 10 years. No, we're all kind of in the same place. But if we can meet up in their network of my peers and let's talk about what's going on at your place, I'll talk about what's going on at my place, and we can share with each other and... help each other find the best solutions. Even that level, I think of coaching is really imperative and can really make an impact on how successful your implementation is. Mike (08:25)I think you're right. I think back to the earliest days of Agile, and at least of Agile training. And I'm thinking back to when I was teaching public courses on Agile in 2003, 2004, 2000, actually, the early days. One of the big benefits of the class, beyond whatever learning somebody had in the class, one of the big benefits was just feeling like you weren't alone in the world. And I remember people describing a problem, whatever it was. Like, my bosses aren't on board with this. and somebody would describe a problem and then somebody else in the class would just merely sympathize. Right. Yeah, mine too. I'm struggling with that too. That was like one level of support that was awesome. It was even better if there was somebody in the class who said something like, yeah, we had that problem and here's what we did. Right. But these were not people who were any smarter than each other. It wasn't like the person who'd worked through the problem was that much smarter. They probably just had a six month head start and Having that ability to go into a class and hear that you weren't alone and that your problems were not that unique was extremely valuable for people even way back then when there were not a lot of people doing this. Brian (09:32)Yeah, and I've said this before, and I probably said this to you, Mike, but one of the things I think people love the most when they come to the advanced classes that we offer is really being able to get sympathy from others, the camaraderie of talking to somebody else and saying, yeah, I've gone through that. It's not, I tell people at beginning of the class, it's Mike (09:48)Mm -hmm. Brian (09:59)likely not going to be a teaching point that sticks with you as much as it's going to be hearing from your peers and actually getting to learn from each other that's going to stick with you as much through those classes. to me, I think that's one of the reasons why those classes are so much fun is because I learned from the people who come to them. Mike (10:20)absolutely, absolutely. Some of what you're describing is why we set up our Agile mentors community years ago. Agile mentors community, not just the podcast, is a community we have where people who take one of our courses get a free membership. I hired a consultant to kind of give me advice on some business stuff years ago. he used the try. And I asked him, hey, we're thinking about starting this community. What do you think? I don't remember if he said do it or don't, but I do remember a term he used. He called it a continuity program. And it was a way to continue a relationship with people who taken our courses. And like I said, we give it away free to people who take classes because we know that a class isn't enough to get people successful, but it's a start. It gets people over some hurdles. It gives them the foundations of the education they need. But they're going to have ongoing questions. And our community has been wonderful because we have so many good people in there who helped each other out. And again, they're often somebody who's just six months ahead in their journey, helping somebody who's right behind them or, you know, there's somebody just in a similar industry and can sympathize or give advice on how they worked through a problem. Brian (11:29)Yeah, that's awesome. So we talked about experimentation, we talked about coaching. Mike, what was another one that was on your list? Mike (11:36)One for me is to focus more on practices than frameworks. The frameworks get all the attention. Should we do Scrum or should we do Kanban? Should we do extreme programming, going back a little bit more when that was extremely popular, still around, but not as popular? Should we do safe? And so people focus on their frameworks because they're these big, visible things. And I think what we want to do more is pick the right practices for us. Now, that's not to diminish frameworks. I think the frameworks are good. They're a good starting point. But I've said for years, if I have a team and they start with Scrum or if they start with Kanban, if they're doing the good old inspect and adapt thing, they're going to end up in the same place. They're going to invent the right Agile for them. And very likely, that's going to be some elements of Scrum, some elements of Kanban, perhaps some elements of Safe if it's big. I don't think it matters all that much where you start. I think it's worthy of some consideration. But if you're inspecting and adapting, you're g…

    Full show notes at the publisher

    #117: How AI and Automation Are Redefining Success for Developers with Lance Dacy Sep 25, 2024
    Show notes

    In this episode, Brian Milner and Lance Dacy dive into the evolving world of software development, exploring how AI and automation are reshaping the landscape. They discuss the essential skills developers need in this new era, from embracing AI as a tool to mastering emotional intelligence and continuous learning. Overview Brian and Lance discuss the transformative impact AI and automation are having on the software industry. They explore the importance of adaptability, continuous learning, and cross-functional expertise, emphasizing how developers can thrive by embracing AI as a tool rather than a threat. The conversation highlights the growing need for soft skills like emotional intelligence, curiosity, and collaborative leadership, and encourages developers to be open to new technologies and ways of working to stay competitive in the ever-evolving tech landscape. References and resources mentioned in the show: Lance DacyBig Agile“Be curious, not judgemental” – Walt Whitman#54: Unlocking Agile’s Power in the World of Data Science with Lance Dacy#63: The Interplay Between Data Science and Agile with Lance Dacy#82: The Intersection of AI and Agile with Emilia Breton#99: AI & Agile Learning with Hunter HillegasAccurate Agile PlanningMountain Goat Software Certified Scrum and Agile Training ScheduleCertified ScrumMaster® Training and Scrum CertificationCertified Scrum Product Owner® TrainingAdvanced Certified Scrum Product Owner®Advanced Certified ScrumMaster®Join the Agile Mentors CommunitySubscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away. Auto-generated Transcript: Brian (00:00)Welcome in Agile Mentors. How's your week going? I hope everyone's week is going well. Yeah, I'm switching things up. I'm not saying things exactly as I did the past 100 episodes. But welcome in. I hope you guys are having a great week. We are back with you here at the Agile Mentors Podcast. And I have one of our favorites back with us. I have one of our repeat visitors, Lance Dacys with us. Welcome back, Lance. Lance Dacy (00:28)Thank you, Brian. Great to be here. Brian (00:30)Always excited to have Lance with us because we always have such great conversations. And I wanted to have Lance back because we were talking about something recently that I think might be a good topic for us, might be on a lot of people's minds. And that is really kind of getting into this, what we've loosely termed the new age of development. With the new tools and new kind of the way that AI has worked its way into things and automation. How is this going to change and affect our teams? How is it going to change and affect how we develop? How is it going to change and affect the software industry? Lance, I know you had some thoughts on this. I'm going to just open the floor for you and let you take it from there. Lance Dacy (01:15)That's great, Brian. My heart is always with organizations and developers, just trying to help people get better. You and I shared that vision that I remember a long time ago, even at DFW Scrum, one of our vision statements was just trying to help you to do better today than you did yesterday. It's like, what are the things that we can help teams and organizations? And something's real heavy on my mind lately as I work with these teams. You know, we have these notions out there like Agile is dead and, you know, where is Agile headed? And that's not really what this is about here because I think what's happening, as a lot of people have already said, it's just become more of the mainstream. Let's quit labeling it. You know, like Mike always tells us, object -oriented programming won. We don't really call it that anymore. Objects won and off we went. So I'm not really focused so much on the agile type scenario, but we do work in Scrum and agile teams and I see plenty of organizations that need help with that. And I still encounter to this day, developers who are lagging behind on their skills, right? We get so focused in the day -to -day feature development of our roadmap and things like that. that I just fear that developers aren't setting enough time aside or not challenging the organization to help them do that, to learn new skills. And I started compiling this list of like, if I go in and start teaching teams how to do scrum and how to manage your backlog and how to do that, it doesn't matter if they don't have the skills because everything we talk about in Agile is based on reducing waste and the more of these skills gaps that we have. then I find the more handoffs and the more bottlenecks and you know that's one of the eight waste, you know, of lean. And so that's what I wanted to talk about today. And I love the topic like the new age of development. I'm not going to sit here in a spouse to claim to say, here's all the skills you're going to need. But as you and I work, I think we can find plenty of examples to help guide some of these people, even Scrum Masters that are coaching teams or agile coaches, you know, just kind of put some thoughts in their mind about. know, these skills and I have about a short list of five that I've seen growing and then thought we'd go from there. Brian (03:30)That sounds great. I want to dive into one that I know is on your list and it's one we kind of talked about here beforehand, but that is kind of how AI is affecting teams and the skills needed to be relevant with that. Now, I want to preface this by just saying my own personal opinion here on this. I'm not a doom and gloom person when it comes to AI. don't really see it much different than... Lance Dacy (03:34)Thank So, I'll see you. Brian (03:59)how automation really changed things like testing. When automation entered the testing realm, we didn't lose all our testers. We still needed testing. It just was a tool that enhanced the way we did testing. And I think AI is sort of going to be that for how we program. don't think we're at a place where, or I don't know, things could change quickly, obviously, but I don't feel like we're within 10 years. of it completely replacing developers. I think we're still going to need to have expertise. We're still going to need to have that guidance. Maybe 10 years is too big of a window. don't know. Maybe five years? I don't know. Lance Dacy (04:42)These days you don't know. I just thought yesterday something changed. No, I'm just kidding. Brian (04:46)Right, right. But I don't see that happening in the near term window for sure, just because it does a lot of things well, but it doesn't create. It can do things based on what's already been done, but it can't really then go through and create something entirely new itself. So I think you still need human beings for that component of it. Lance Dacy (05:04)Done. Brian (05:15)And I think for developers, learning how to integrate that kind of tool set to help you reduce your errors, define bugs, AI is great at looking over a huge chunk of your code and finding potential issues that you can go back and look at. That can save you enormous amounts of time. So I think there's skill involved there for for the developers segment that I think is embracing it rather than kind of holding it at arm's length and saying, that's the enemy, that's gonna somehow replace me. No, think of it like automation. It's not to replace you, it's just another tool to enhance and give you time to do other things. Lance Dacy (06:02)I think, you know, you mentioned, don't think you and I either would be convicted of being doom and gloom people. think we're pretty well optimistic, right? It is scary. mean, obviously these things that are changing, you're like, my gosh, I have to, the main word I keep thinking about is adaptability. You know, I've got four kids. I keep telling them the best skill they can do is learn how to learn, you know, and I think you just used a perfect example in development about test automation. Brian (06:10)Yeah. Lance Dacy (06:30)We weren't scared of that. The testers might have been because they're like, well, what do I do now? Well, you got to go learn a new skill, right? But it freed us up. Can you imagine still doing, there's companies out there that still do manual testing, and they have to wait until all the changes are in until they do testing, and you will never compete. in a good hyper competitive marketplace doing things like this. So the test automation freed us up and actually what I used to tell my teams is it gives you more confidence, right? So developers can make more radical changes in the code without feeling like, know, you. You blow on something and then it breaks. know, y 'all ever seen code like that before? And it's like, I think it builds their confidence that test automation helped them to be more efficient and more productive because they can experiment more. think that's the goal is I write this code and I can quickly test to see what happens. And I start building my confidence and I can make more radical changes to the system instead of tiptoeing or walking on eggshells. So I'll date myself a little bit. Your example is probably much better than mine. But can you believe I don't use a Maps Go anymore? Y 'all remember the days of trying to navigate a street address with a Maps Go or a real map? I mean, I'm kind of at that bridge where we started having online maps, but you still had to know where you're going and print it out before you left and then take it in your car. You're still trying to read it as you're driving. I mean, who does that anymore, right? So I get in my car these days and now I don't even have to plug CarPlay or Android or whatever you have. It's wireless. You just get in and I'm now a co -pilot in my car. And we kind of laughed about that. think the last episode we're on and I can just drive around in it. I just do what it tells me to do. But it'll never replace my experience, my opinions, and my knowledge of the world. So I can. Brian (08:05)Right. Lance Dacy (08:20)you know, sidestep any suggestions it has, but it helps me be more productive. It knows where traffic is. I don't know that. You know, I know the city I live in and I know five different ways to get somewhere, but I don't know if there's a road closed or anything like that. So I feel like with developers, we need to start embracing some of these tools to help you be more confident, help you. mean, goal of agility, right, is to go faster, go faster than our competitors. So I feel like that's the premise of what we're trying to accomplish here is optimism with these tools. AI is just one of them. But we all have that in our day -to -day lives. test automation is good. I've got the driving. What's another one you got, Brian, that's made you more efficient with AI? Brian (09:01)Well, just before we move on, one thing I wanted to kind of throw out there because I heard this example recently for AI and I thought this was a kind of a really good practical example. If you've been a developer for any amount of time or if you've ever developed in the past, you've unlikely encountered a situation where you've had to go into somebody else's code. And when you do that and you have to enter, especially if it's like a rat's nest of code that you can't really make it out, it's been there for a long time. and it's fragile, no one wants to delve into it. Well, I read this article from a guy who basically had used this legacy code base and entered into AI and had AI go through and comment and help them learn what the different sections of the code did and how it was structured and organized. And it just saved them an enormous amount of time in trying to understand what had come before. Because you know, Like I said, we've all entered those places where we've had to come in behind someone else that is no longer there and try to figure out where we get started, even if it's not code, right? Even if it's something else, but we've all had to come behind someone else. And if we can take a folder full of documents, feed it into AI and then say, help me understand blah, blah, blah. Yeah, summarize this. Help me understand where would I go for this? That's just an enormous time saver. And that's what I think is really great about it is Lance Dacy (10:17)you summarize this. Brian (10:27)So as far as skills are concerned, think prompt engineering is a good one. think coding, interacting with code with an AI agent so that you can create your own AI agents so that you can programmatically call that information. If you're a coder and you can do that, man, to me it's like it just exploded. And now the possibilities are endless of what you can do with that kind of stuff. Lance Dacy (10:57)just dated myself with Cliff Notes too, right? Just think of it like on the fly Cliff Notes. And I heard Alastair Coburn, one of the thought leaders in our industry, been around for a very long time trying to help humans and machines interact better. And he kind of summarized really well about what it's doing in his life is saving him keystrokes. Brian (11:03)Right! Lance Dacy (11:19)And that's kind of like what I wanted to focus on with developers. Can you imagine if you got to spend more time being creative and less time writing on a keyboard to the computer, like you just talk to it. I'm getting to the point now, I used to text all the time and I used to laugh at people that hold the phone up to their voice and they talk into it. I fat finger things and misspelled things so much, all I do is just talk into it anymore. So I feel like coding, that's what it's, you're not even going to tell it the code to write. You're going to have to be... more problem solving design engineer, you less code writing, more problem solving and understanding the domain in which you're trying to automate and algorithm design and ethical considerations that go along with that. But the computer won't be able to do that, but it'll save you keystrokes. It'll save you time. And I think Alistair summed that up pretty good that way. Brian (12:07)Yeah, it's architecture, right? We have to be better architects at what it is we're trying to develop. that way we can give the rough architecture and let AI do the dirty work of the small details to fill in. Lance Dacy (12:21)Well, you mentioned something too about boundaries, right? So AI has to operate within boundaries of what you feed it to learn off of. It's very, I'm not going to say never always really, that's a hard thing t…

    Full show notes at the publisher

    #116: Turning Weird User Actions into Big Wins with Gojko Adzic Sep 18, 2024
    Show notes

    What do lizards have to do with product growth? In this episode, Gojko Adzic reveals how unusual user behaviors can unlock massive opportunities for product innovation. Discover the four steps to mastering "Lizard Optimization" and learn how you can turn strange user actions into game-changing insights. Overview In this episode of the Agile Mentors Podcast, host Brian Milner chats with Gojko Adzic about his new book, Lizard Optimization. Gojko explains the concept of finding product growth signals in strange user behaviors, sharing examples where unexpected user actions led to product breakthroughs. He outlines a four-step process for optimizing products by learning, zeroing in, removing obstacles, and double-checking. Gojko also discusses helpful tools like session recorders and observability tools that can enhance product development by uncovering and addressing unique user behaviors. References and resources mentioned in the show: Gojko Adzic50% OFF Lizard Optimization by Gojko AdzicMismatch: How Inclusion Shapes Design by Kat HolmesTrustworthy Online Experiments by Ron KohaviAdvanced Certified Scrum Product Owner®Subscribe to the Agile Mentors PodcastJoin the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Gojko Adzic is an award-winning software consultant and author, specializing in agile and lean quality improvement, with expertise in impact mapping, agile testing, and behavior-driven development. A frequent speaker at global software conferences, Gojko is also a co-creator of MindMup and Narakeet, and has helped companies worldwide enhance their software delivery, from large financial institutions to innovative startups. Auto-generated Transcript: Brian (00:00)Welcome in Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today, very special guest we have with us. have Mr. Goiko Atshich with us. I hope I said that correctly. Did I say it correctly? Close enough. Okay. Well, welcome in, Goiko. Glad to have you here. Gojko (00:15)Close enough, close enough. Brian (00:21)Very, very, very happy to have Goiko with us. If you're not familiar with Goiko's name, you probably are familiar with some of his work. One of the things I was telling him that we teach in our advanced product owner class every time is impact mapping, which is a tool that Goiko has written about and kind of come up with on his own as well. Gojko (00:21)Thank you very much for inviting me. Brian (00:47)But today we're having him on because he has a new book coming out called Lizard Optimization, Unlock Product Growth by Engaging Long Tail Users. And I really wanted to talk to him about that and help him explain, have him explain to us a little bit about this idea, this new concept that his new book is about. So, Goiko, let's talk about it. Lizard Optimization, in a nutshell, what do you mean by that? What is it? Gojko (01:14)We're going to jump into that, but I just need to correct one of the things you said. I think it's very, very important. You said I came up with impact mapping and I didn't. I just wrote a popular book about that. And it's very important to credit people who actually came up with that. It's kind of the in -use design agency in Sweden. And I think, you know, they should get the credit for it. I literally just wrote a popular book. Brian (01:19)Okay. Gotcha. Gotcha, gotcha. Apologies for that incorrect. Thank you for making that correction. So lizard optimization. Gojko (01:44)So, lizard optimization. Good. So, lizard optimization is an idea to find signals for product ideas and product development ideas in strange user behaviors. When you meet somebody who does something you completely do not understand, why on earth somebody would do something like that? Brian (02:03)Okay. Gojko (02:11)and it looks like it's not done by humans, it looks like it's done by somebody who follows their own lizard logic, using stuff like that as signals to improve our products. Not just for lizards, but for everybody. So the idea came from a very explosive growth phase for one of the products I'm working on, where it... had lots of people doing crazy things I could never figure out why they were doing it. For example, one of the things the tool does is it helps people create videos from PowerPoints. You put some kind of your voiceover in the speaker notes, the tool creates a video by using text to speech engines to create voiceover from the speaker notes, aligns everything and it's all kind of for you. People kept creating blank videos and paying me for this. I was thinking about why on earth would somebody be creating blank videos and it must be a bug and if it's a bug then they want their money back and they'll complain. So I chased up a few of these people and I tried to kind of understand what's going on because I originally thought we have a bug in the development pipeline for the videos. So... I started asking like, you know, I'm using some, I don't know, Google slides or, you know, keynote or whatever to produce PowerPoints. Maybe there's a bug how we read that. And the person, no, no, we, know, official Microsoft PowerPoint. They said, well, can you please open the PowerPoint you uploaded? Do you see anything on the slides when you open it? And the person, no, it's blank. Right? Okay, so it's blank for you as well. I said, yeah. So. Brian (03:48)Yeah. Gojko (03:54)What's going on? so what I've done is through UX interviews and iterating with users and research, we've made it very, very easy to do advanced configuration on text -to -speech. And it was so much easier than the alternative things that people were creating blank PowerPoints just to use the text -to -speech engines so they can then extract the audio track from it. Brian (03:54)Yeah, why? Gojko (04:23)and then use that and it was this whole mess of obstacles I was putting in front of people to get the good audio. It wasn't the original intention of the tool. It wasn't the original value, but people were getting unintended value from it. And then I ended up building just a very simple screen for people to upload the Word document instead of PowerPoints. And it was much faster for users to do that. A month later, there was many audio files being built as videos. Two months later, audio... production overtook video production. then at the moment, people are building many, many more audio files than video files on the platform. So it was an incredible growth because of this kind of crazy insight of what people were doing. kind of usually, at least kind of in the products I worked on before, when you have somebody abusing the product, product management fight against it. There's a wonderful story about this in... Founders at work a book by Jessica Livingston and she talks about this kind of group of super smart people in late 90s who Came up with a very very efficient Cryptography algorithm and a way to compute the cryptography so they can run it on low -power devices like Paul pilots Paul pilots were you know like mobile phones, but in late 90s and Then they had to figure out, how do we monetize this? Why would anybody want to do this? So they came up with the idea to do money transfer pumping, Palm pilots, you know, why not? And kind of the built a website. This was the late nineties as a way of just demoing this software to people who didn't have a Palm pilot device next to them. The idea was that you'd kind of see it on the website, learn about it, then maybe download the Palm pilot app and use it in anger. People kept just using the website, they're not downloading the Palm Pilot app. So the product management really wasn't happy. And they were trying to push people from the website to the Palm Pilot app. were trying to, they were fighting against people using this for money transfer on the web and even prohibiting them from using the logo and advertising it. They had this whole thing where nobody could explain why users were using the website because it was a demo thing. It was not finished. It was not sexy. It was just silly. And Jessica kind of talks to one of these people who insists that it was totally inexplicable. Nobody could understand it. But then a bit later, they realized that the website had one and half million users and that the Pongpilot app had 12 ,000 users. So they kind of decided, well, that's where the product is really. And that's like today, people know them as PayPal. They're one of the biggest payment processes in the world because kind of, you know, they realized this is where the product is going. And I think in many, many companies, people Brian (07:03)Ha ha. Gojko (07:18)stumble upon these things as happy accidents. And I think there's a lot more to it. We can deliberately optimize products by looking for unintended usage and not fighting it, just not fighting it. just understand this is what people are getting as value. And I think for me as a solo product founder and developer and product manager on it, One of the really interesting things is when you have somebody engaging with your product in an unexpected way, most of the difficult work for that user is already done. That person knows about you, they're on your website or they're using your product, the marketing and acquisition work is done. But something's preventing them from achieving their goals or they're achieving some value that you did not really know that they're going to achieve. you know, that's something the product can do to help them and remove these obstacles to success. So that's kind of what lizard optimization is making this process more systematic rather than relying on happy accidents. And by making it more systematic, then we can help product management not fight it and skip this whole phase of trying to fight against our users and claim that users are stupid or non -technical or... They don't understand the product, but they're trying to figure out, well, that's what the real goals are. And then following that. Brian (08:47)That's awesome. So the pivot, right? The pivot from here's what we thought our problem was we were solving to now here's what we're actually solving and we should organize around this actual problem, right? Gojko (09:02)or here's what we're going to solve additionally. This is the problem we've solved, but hey, there's this problem as well. And then the product can grow by solving multiple problems for people and solving related problems and solving it for different groups of people, for example. And that's the really interesting thing because I think if you have a product that's already doing something well for your users and a subset of them are misusing it in some way, then kind of... Brian (09:04)Yeah. Gojko (09:30)The product might already be optimized for the majority of users, but there might be a new market somewhere else. So there might be a different market where we can help kind of a different group of users and then the product can grow. Brian (09:43)Yeah, I like to focus on the user. There's an exercise that we'll do in one of our product owner classes where we have a fake product that is a smart refrigerator. And one of the exercises we try to get them to brainstorm the different kinds of users that they might have for it. And one of the things that always comes out in that class is as they're going through and trying to describe the types of users, they inevitably hit to this crossroads where they start to decide Well, yes, we're thinking of this as a home product, something for people to use in their homes. But then the idea crosses their mind, well, what about commercial kitchens? What about people who might use this in another setting? And it's always an interesting conversation to say, well, now you've got a strategic choice to make, because you can target both. You can target one. You can say, we're ignoring the other and we're only going in this direction. So to me, I think that's kind of one of the interesting crossroad points is to say, how do I know when it's time to not just say, great, we have this other customer segment that we didn't know about, but actually we should start to pivot towards that customer segment and start to really target them. Gojko (11:03)Yeah, think that's a fundamental question of product development, isn't it? Do you keep true to your vision even if it's not coming out or if something else is there that's kind more important than I think? For me, there's a couple of aspects to that. One is, laser focus is really important to launch a product. You can't launch a product by targeting... the whole market and targeting a niche type, figuring out, you know, user personas, figuring out like really, really, this is the product who we think the product, this is the group who we think the product is for and giving them a hundred percent of what they need is much better than giving 2 % to everybody because then the product is irrelevant. But then to grow the product, we need to kind of grow the user base as well. And I think one of the things that... is interesting to look at and this comes from a book called Lean Analytics. It's one of my kind of favorite product management books is to look at the frequency and urgency of usage. If you have a group that's kind of using your product, a subgroup that's using your product very frequently compared to everybody else, that might be kind of the place where you want to go. The more frequently, the more urgently people reach for your product when they have this problem. the more likely they are going to be a good market for it. with kind of another product that I've launched in 2013, we originally thought it's going to be a product for professional users. And we aimed at the professional users. And then we found that a subcategory that we didn't really expect, were kind of teachers and children in schools. we're using it a lot more frequently than professional users. And then we started simplifying the user interface significantly so that it can be used by children. And it's a very, very popular tool in schools now. We are not fighting against other professional tools. We were kind of really one of the first in the education market there. And it's still a very popular tool in the education market because we figured a subgroup that's using it very frequently. Brian (13:14)Hmm. Yeah, that's awesome. How do you know when, you know, what kind of threshold do you look for to determine that, this is, because, you know, in your book, you're talking about, you know, behaviors that are not normal, right? People using your product in a way that you didn't anticipate. And what kind of threshold do you look for to that says, hey, it's worth investigating this? You know, I've got this percentage or this number of people who are using it in this strange way. At what point do you chase that down? Gojko (13:49)I think…

    Full show notes at the publisher

    #115: Aligning Leadership for Success with Dr. Tess Thompson Sep 11, 2024
    Show notes

    Join Brian and Dr. Tess Thompson as they delve into the complexities of scaling Agile, highlighting the challenges of aligning leadership priorities, fostering transparency, and applying system-level thinking for successful organizational transformations. Overview In this insightful episode, Dr. Tess Thompson tackles the pressing challenges organizations face when scaling Agile, with a focus on the critical role of leadership alignment. Drawing from her extensive experience, she explains how misaligned priorities at the leadership level can stall progress and waste resources. Dr. Thompson emphasizes the importance of system-level thinking, transparency, and communication between teams and leaders to resolve misalignments and ensure success. She also shares her holistic approach, blending practices from various Agile frameworks to meet the specific needs of different organizations. References and resources mentioned in the show: Dr. Tess ThompsonScrum Inc.Scrum.org#68: The Pros and Cons and Real World Applications of SAFe with Mike Hall#94: Connecting Teams and Leadership with Anthony CoppedgeThree Questions to Determine If an Organization Is Agile by Mike CohnCertified Scrum Product Owner® TrainingJoin the Agile Mentors CommunitySubscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Dr. Tess Thompson is a visionary leader in Agile transformations, with over three decades of experience reshaping industries from energy to biotech across the globe. As a professor at St. Mary's University, her dedication to fostering Agile leaders has empowered countless individuals to embrace adaptability and forge their own path to success. Auto-generated Transcript: Brian (00:00)Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have a very special guest with me. I have Dr. Tess Thompson with me. Welcome in Dr. Thompson. Tess Thompson (00:13)Hi, I'm glad to be here. Brian (00:16)I'm so happy to have Dr. Thompson with us. And just for people who aren't familiar, let me make sure that I introduce her and give you the background a little bit. First of all, she's been in this business for almost 40 years now. She's been doing stuff in IT since the 80s. She is a principal consultant and RST fellow with Scrum Inc. Scrum .inc, I should say. She is a PST as well with scrum .org. So two different organizations from two different founders of Scrum. She has been a professor at St. Mary's University. So has that kind of educational background as well. And I was asking her beforehand if there's anything else I needed to say. And she said, well, make sure you say I've got nine grandchildren. That's kind of my claim to fame. I love that. So. Nine grandchildren, very happy for that. So that's who we're talking with. And we wanted to have Dr. Thompson because there's a lot of experience here that she brings to the table in the realm of scaling, obviously being connected so closely with those two organizations. So with all that out of the way, let's talk about scaling a little bit. And Dr. Thompson, what I want to start with is just Tess Thompson (01:27)I'm Brian (01:40)When you work with organizations today that have scaling issues, what are organizations really struggling with? What's kind of the main issues that you see organizations have with scaling today? Tess Thompson (01:55)I would say there's a lot of things, but I would say still the biggest problem is getting everybody to align on what the priority is. So at some point, like you get alignment with maybe people that are doing Scrum and they're the people that are above them, but then the people above them are out of alignment. like, for example, one of the clients I have right now brought some consultants in to work on a project. Brian (01:59)Yeah, right. Tess Thompson (02:24)And those consultants have been stuck now for four weeks. And where the alignment problem is, is actually up at the C -suite with this client. Because one of them says, nope, we were supposed to help. That was a priority in 2023. And the other one's like, no, this is a priority in 2024. And they're not helping each other. So in the meantime, this project is stuck for four weeks. And we're spending money on people that are sitting there doing nothing. Brian (02:50)So just when you say alignment, give us kind of a flavor. when leaders are misaligned, what kind of things are they, are there different ideas about priority or different ideas about why they're doing this? What are they misaligned on? Okay. Tess Thompson (03:09)Both, both, I would say both. The, you know, especially as the companies get bigger and bigger, we have a CEO who's got some priorities, but then all the C -suite under them have their own priorities and they're not always, and then they break down to the next level and these priorities start to get out of alignment because people start bringing in their own objectives and their own priorities and they often don't match what somebody else is doing. So part of it is the different incentives and just the organizations being so big, they have to get even these priorities aligned at different levels. Brian (03:49)So this is kind of an amazing thing, I think, for people to latch onto here, because I hear a lot of people in just regular base level classes talk about how there's a disconnect between them and the leadership on how they're going to do Scrum and how this fits into the overall structure of the organization. just understand, Dr. Thompson here is talking about organizations that The leadership has stated, at least in some way, or form, we're in alignment with this. We want to do this. We want to have Scrum throughout our organization. But even in those situations, we're seeing these misalignments of just priorities and what are the drivers really for what they're trying to do. So I find that fascinating that talking to so many people who just wish that their leadership could get on board. with what it is they're trying to do, that even in those organizations where they do, quote unquote, get on board, there's still these kind of fundamental disconnects. Tess Thompson (04:51)Yep, absolutely. In fact, I do very little work anymore on scrum specific. is many organizations, I mean, almost every organization I go into anymore has some shape or form of scrum going on or people with experience with it. Some people, you know, they're not, it's something that they're trying to do anyway, something agile. And they're... They're getting things done quicker. They're delivering with higher quality. They have better communication at that level. But then as you go up the chain, things start to break down and then teams are stuck. So organizations can only get product out the door with high quality as quick as possible. The more the organ... We have to really think the system. So most of the work that I do today is around the system, which is scaling. It's system agility. Otherwise you start having, you just run into optimization in areas, that local optimization problem. Brian (05:58)Yeah, yeah, not seeing the whole, right? Tess Thompson (06:02)Right, absolutely. So I think that over the years that Agile has been around, we're seeing more and more of it, but then it's, like I said, almost all my work now is system level and not down at the team level. So often I'm not even using Scrum language when I'm talking. It is about alignment. It is about prioritization. So yes, at a Scrum level, your product owner is putting the order of the product backlog, and then the team can pull out off that backlog. based on value from all the different stakeholders that the product owner is working with. But in a big organization, those stakeholders can be a manager, can be a director, it can be another department, it can be, it's from all over the place. And then at some point, how does that work coming into the product owner roll up to the priority of the department or a higher level? And then how does that roll up to the higher level? And that's where we start running into messes. Brian (06:58)Yeah. Yeah. Yeah. mean, it's like you said, with all these various priorities, with all these various drivers, I've always talked to product owners and say, it's a tough job. You're balancing the needs and desires of all these people into one product, and you're having to take them all into account. So yeah, it's not easy. It's not an easy job. Tess Thompson (07:08)You. Brian (07:27)Well, so I'm curious about, you say you don't really even use the Scrum language as much when you're talking to the leaders, because they're not really interested in that, right? They're not really interested in, we doing this exactly according to what the Scrum guide says? They're interested in the outcome, right? The results that you're getting from this. Yeah, so I'm kind of curious, especially since you're a fellow with Scrum Inc. And I know that the... Tess Thompson (07:37)No. Absolutely. Brian (07:55)a Scrum at Scale kind of strategy is very specific about how these things are implemented. There's practices and all sorts of stuff that Scrum at Scale kind of implements. Would you categorize yourself as sort of a Scrum at Scale implementation consultant? Or is it more of just, I take more of a holistic approach to the scaling. Tess Thompson (08:19)Holistic, absolutely. So actually, I'm certified in Nexus, Scrummit Scale, Less, and Safe. I mean, I have all of them. So I always think you need to bring the best tool to the job. One of the things I like about Scrummit Scale and Nexus is they're just so simple. Like if, hey, if these two teams are not, if we need to coordinate, let's get these product owners together and work together to figure out what is really the order. So whether we call it a meta scrum or we call it something else, I don't think that language matters as much as seeing the need and then bringing in a tool to help meet that need. If these teams are interdependent and they need to be chatting to help get rid of those interdependencies, well, let's spin up a scrum of scrums here. Brian (08:58)Yeah. Yeah. Yeah. I've had someone on before that we've talked through kind of the safe model a little bit and talked about how, you know, there's so much additional overhead, there's so much additional roles and events and all these other things that get added from the safe perspective, that it can be very, very overwhelming for a lot of organizations to look at that and say, well, gosh, how are we ever going to, I mean, we're barely hanging on with it, trying to understand what Scrum is. And now we're going to layer in all these other things and, Tess Thompson (09:22)Thanks. Okay. Brian (09:38)It just seems like a recipe for disaster to try to understand all these things. So I guess one of the things that I had in that previous conversation was this dialogue about how you match the problem to the practice. You find the problem that is going on in the organization and you find the right practice that solves that, but not necessarily implementing the whole smorgasbord of practices because you may be trying to solve problems you don't have. Do you see that as kind of your approach when you work with organizations or how do you match the practices to what's actually going on on the ground? Tess Thompson (10:18)Yeah, I would say, you know, it's kind of similar to what happened with, so I'm also a PMP. So when we When we put together the PIMBOK over the years, it became this, know, it was supposed to be, these are best practices that you can have. And over time, it became very, big, thick book and people didn't understand they were only supposed to implement whatever tool from that book really helped solve the problems they were having. And started implementing the whole thing. And I think that's what happens too with like, Brian (10:50)Ha ha. Tess Thompson (10:53)safe or any of these agile practices, even though, know, Ken and Jeff went completely the opposite of PMI and said, hey, we're just going to roll out. This is the absolute minimum that you need for running, running a team or a project or product. And, but it's not enough. So you need to add in some more things to it. You got to bring in some additional tools to help depending on the organization, such as road mapping. I really believe that's one of the. I spend a lot of time helping organizations and product owners think about, we do need to plan ahead. And that is one of the pieces I do like about SAFE is that in their PI planning, have the getting some product owners and teams together to plan together to look out further, I think is pretty essential in most organizations. Now, do we need to do it on a regular cadence of every eight weeks? And do we need to have 200 teams together? I think Brian (11:23)Yeah. Tess Thompson (11:49)Sometimes it's, think organizations end up implementing all of SAFE, kind of like in the pin box, if you will, and it's way more than they need. So I think it's taking the elements of all of these and then using them to meet the need of the organization. I mean, if you're a 30 person organization, do you need a bunch of release trains and engineers and stuff? No. Brian (11:59)Yeah. Yeah. Yeah, I mean, it's very interesting to me with your background that you have all of these different scaling frameworks in mind. How much of what you do do you feel is aligned to a specific framework and how much of it is just piecemeal across the different frameworks? Tess Thompson (12:34)I would say I'm most aligned to, well, Scrum at Scale, never solely. It's always piecemeal. It is a piecemeal thing because I really do believe that teams do get to need to plan out in almost every company I go into. Teams do need to plan out more than one sprint. Brian (12:44)Hmm. Tess Thompson (12:54)Okay, we need to plan out and we're never delivering anything alone with one team. It seems like we're always need multiple teams. So we need that coordination and we need some of the scaling practices for sure. I really use a variation of safe of PI planning, but then I layer in, so we put together our plan for let's say the month, maybe we have a product goal for the month. And then I use the version of PI planning to get the teams together to plan out for sprints. weekly sprints to get to that product goal and try to get rid of the dependencies and problems that we see between the teams. And then we let it run. But then I pull in from Scrum at Scale, definitely the Metascrum. Like every sprint, let's still get the product owners together and revise our sprint plans because we've learned a lot in the last sprint or we learned a lot today. So we're not just going to let it ride for a month, for example, we're going to still get together at a regular cadence, like once per spr…

    Full show notes at the publisher

    #114: Is Agile Dead? with Scott Dunn Sep 04, 2024
    Show notes

    Is Agile really dead, or are we just doing it wrong? Tune in as Brian and Scott dive deep into the controversies and misconceptions surrounding Agile practices and what it really takes to make Agile work in today’s organizations. Overview In this episode, Brian and Agile Mentors Podcast regular, Scott Dunn, tackle the provocative question: "Is Agile Dead?" sparked by recent claims of Agile's high failure rates. They discuss the validity of these claims, the common pitfalls of bad Agile implementations, and the importance of continuous improvement and experimentation in Agile practices. The conversation explores the shortcomings of current training approaches, the crucial role of effective coaching and leadership support, and how to overcome the widespread misconceptions about Agile. Brian and Scott emphasize the need to focus on outcomes and ongoing learning rather than getting bogged down by methodology debates and rigid terminologies. References and resources mentioned in the show: Scott Dunn#93: The Rise of Human Skills and Agile Acumen with Evan LeybournAre Agile and Scrum Dead? By Mike CohnJoin the Agile Mentors CommunityMountain Goat Software Certified Scrum and Agile Training ScheduleSubscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum. Auto-generated Transcript: Brian (00:00)Welcome in Agile Mentors. Welcome back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today, friend of the show, regular, you know him, you love him, Mr. Scott Dunn is with us. Welcome back, Scott. Scott (00:13)That's my new favorite intro ever. So thank you, Brian. Always glad to be and then glad to talk shop. So I appreciate you making me some space so that I get to work with you again. Brian (00:16)Ha ha ha. Yeah, we need like walkout music for you. know, like when the pitcher comes out to the mound, the relief pitcher or the wrestler comes out, you know, or whatever, they play the walkout music. We need walkout music. We wanted to have Scott back because there's a hot topic and this is your hot take alert because this show I'm sure is gonna be full of personal hot takes here on the subject. Scott (00:30)Yeah yeah, there you go. Brian (00:50)And that is, is Agile dead? There has been a lot of talk recently about this in the past few months. There's been a lot of blog posts written, a lot of armchair quarterbacks chiming in and trying to make sense of this. So before we dive in, Scott, I want to give a little bit of background to our listeners in case you're not aware of something that happened, where this came from, right? Because I think that there was In one sense, there's always an undercurrent. There's always people out there who are ready to say Agile's dead, right? And so they're waiting to pounce on anything that would back them up. And there was someone who was very happy to oblige about that. There was a company called Engprax, E -N -G -P -R -A -X. I couldn't find much out about them except they're a consulting company. And they put out an article that was announcing research they had done that said that 260 % higher failure rates for Agile software projects. That's what their study revealed. Yeah, 268%. So let's just start there, right? But the article is very thinly veiled in support. of another competing process, believe it or not, called Impact Engineering that is authored with a book that's just out, believe it or not, by a gentleman named Junade Ali. Now I have no idea, I have never crossed paths with this gentleman. I don't know his philosophy or his, much more about him. I did look him up on LinkedIn. He's been in the business for about 11 years. If I trace back to his first thing, it's about 11 years ago. He currently lists himself as the chief executive officer of a stealth startup. Well, I think I can remove the mask of what that stealth startup is because it is Ingeprax. So he is the head of that company. I found another article that did the research in support of his book. Scott (03:03)Hahaha Brian (03:12)announcing his new process that is a competitor, of course, to Agile. Now, there's been a lot of back and forth. He's tried to defend this and say, you know, the research is solid, but here's the thing I always say, without data, it didn't happen. If you're not showing me the actual methodology, if you're not showing me the scientific research paper behind it that says, here's the methodology of the research, here's how we conducted it, here's the... There are some details that are in the article, one of which is that the research was done over a period of about five days. So it was research over about five days. was interviewing a set of, I'm trying to scroll through and find the numbers. I think it was like 250 or so engineers from the UK and 350 from the US. It's something around those numbers. But it was interviews with engineers over a period of about five days. Scott (03:50)Wow. Brian (04:11)And so the numbers are based on these engineers' recall of what their idea of success was in projects, whether it was an Agile project or not an Agile project, by their definition of whether it was an Agile project or not. He doesn't really describe in the article what success is. So saying that it's 268 % failure, what is a failure? It doesn't really state that plainly. So again, where's the data, right? I'm not going to go on and on about the research and the fact, but I just want to give the background before we dive into it because that article is what now you will see quite a few blog posts and things crossing your desk on LinkedIn that say, wow, look, this new study says 268 % failure rate for agile projects. Well, anytime you see something like that, check the source. You have to check the source. I try to do this in any conference talk I do. I put the links to the sources. And I try to only list data that comes from scientific studies, where you can find the actual research paper and dive into it and get into the nitty gritty of it if you really want to. Otherwise, as I said, it didn't happen. He says in the article, hey, we had PhD people that looked over our work, unnamed PhD people. So you can't even question whether that person was someone legitimate who did it. Just trust him that they were legitimate. So I set that up because I don't mean to take so much time here at start of the episode, but I just wanted to set the foundation. If you weren't aware of that kind of thing or where that came from, you may not even been aware of the background of where that study came from. Scott (05:46)You Brian (06:04)And the fact that the person who kind of sponsored it is got an ulterior motive, right? They're trying to push their own methodology and they're publishing research that they collected, they are publishing, that just so happens to support their foregone conclusion that Agile's bad and their methodology is better. So, but Scott. Scott (06:31)I'm just trying. Brian (06:32)So let's get into the topic because what I really want to get into is, I'm sure you've seen people post things like this and there's been sort of this wave of things in the past year or so of people who are so quick and anxious to say Agile is dead. So what's your general impression there? What have you seen? What have you experienced and how do you respond if someone in class says, hey, is Agile dead? Scott (06:43)Mm Mm I great, great question. So for those listening, I want to just want to affirm that probably a lot of you had experiences like, well, certainly wasn't going great or we're not seeing what we thought and all those things. So part of this, Brian, is I think the ethos of why those things take off like that is I do think there's a general feeling of is this really working for us or not? That's that's fair. So I'm not going to pretend like, it's always goes great. It's, you know, be Pollyanna about that. I remember actually this year. of a CEO, a company saying, Agile absolutely does not work. We're going to go all the way back to just full waterfall. Right. That to me is kind of that harbinger of like, wow, it's built up enough for someone to say that. So a couple of thoughts I have, and I'm going to be pragmatic like you for my friends that are hearing this or maybe thinking this or people at your company are pushing back a bit, is I'm to go back and say, well, okay, let's just say that Agile is dead. So what are you going to do? Are you really going to go back to waterfall? Well, we already know that story. whole reason, for those listening, consider this, whole reason Agile took off was the option A wasn't working and very clearly wasn't working for complex projects like software. Now for this person to come and recommend XYZ, of course, not surprising for all the listeners out there. Obviously, there's a marketplace, there's business. I get it that people are going to pitch and recommend what they do my classic one in our space Brian would be because obviously you I Mike within Mountain Goat are teaching the CSM CSPO and I'll see like 350 page books of get ready for the CSM exam like right the scrum guide itself is I mean how many pages so come on Brian (08:38)You Scott (08:47)And they'll even be like, you know, misrepresentation. So clearly people are doing things in their own self interest. get that. as you as people out there, hear information, I love what you're saying is to just like look into it and really be mindful of what's their angle for some of that. But back to your question, is Agile dead? I would argue that Agile partly done or halfway is dead in the sense that that doesn't work or what I would kind of call Agile theater. Agile hand waving, spread the agile pace. So I've been doing this 18 years, I think, since becoming a Scrum Master. And I was on project delivery before that and managing IT people. So I've seen all the things that weren't working well as a developer, et cetera. And I saw the results of what I got. And I've seen plenty of stories beyond that. But what I see more and more is people who are further away from the beginnings and what they're kind of doing is implementing what's comfortable. And I would agree that doesn't work. in that sense, that Agile is dead. In a follow on the idea of and really kind of putting together realizing is for those out there that your company is the one implementing Agile, who usually gets that? Well, it's probably going to be the PMO. And I'm going to poke a little bit here, certainly for my PMO friends, but as a former PMP working within the PMO, what's the PMO responsible for? So if I go to your typical company, say, hey, we're going to go Agile. That's under the purview of who it's a, it's a, there's going to be a group that's responsible for watching over execution delivery. Who is that? It's a PMO. Think about this. The PMO is not responsible for like learning continuous improvement innovation. They're responsible primarily for, for status reporting, managing to a given date, managing resources, escalating issues, but not necessarily for improving. So they bring in Agile sense of, what do we need to do without maybe understanding it fully and really. How do we just manage this process and not, hey, we're starting off from point A, but we're going to learn and get better as we go across. It's going to stop where they feel like, I think we have a new process that implemented. Does it get the results? You know, I don't know and I don't understand how it works to fix that. So they may not be getting results is what I commonly see. I'm seeing a slew. I can tell you the last several companies just in these last few months we've worked with. We've got to fix our process is not working. Are you agile? Yes. But you look at it and they'd miss a lot of fundamentals. And so now we're kind of resetting a lot of people that are struggling with the same issues everyone's talking about. Visibility, predictability, can we deliver this by the date we gave senior management? And they're not by and large. For those who say agile is dead, one of the other options, people have put together agile manifesto had lots of ideas, lots of other approaches besides scrum, but even if just take scrum. Look, scrum is based on lean. Is lean dead? And scrum is an empirical process. Is empiricism dead? Does that not work? So I kind of come back like, what are your options? Just think about the results you're getting. Whose fault is that? And what are we even basing what we're looking at? The roots of it are all very solid. So yeah, I'm going to push back quite a bit on that, what I've seen. And maybe see some of those same. Results or lack of results for organizations Brian because I know that it doesn't always go great out there and in the marketplace is coming. Try to roll this out. Brian (12:07)Yeah, yeah, there's a, so I have a couple thoughts here. One is just in general, I think you're absolutely right that there's, know, well, just listeners, ask yourself, what percentage of Agile practices out there do you think are doing Agile the right way? Right? And I don't mean like a hundred percent. I just mean they are, they're all in on it. They're trying to do it the right way. I don't know what number you have in your head, I would say, don't know, Scott, what would you say? Scott (12:43)They're doing it right? Brian (12:45)Yeah, they're not perfect, right? But they're committed to doing it right. They're committed to doing it according to what the Agile Manifesto says, that sort of stuff. Scott (12:55)Fairly Fairly smart, right? I'm guessing, my first number that came to mind, you asked, I'd say 10%. That's my, maybe less than that. Brian (13:02)Okay. Yeah, I would bet it's a small thing, right? Now that right there, I think is something that we can talk about. Why is it that small? Right? Why is it that small? And I think that there's a discussion that's a legitimate discussion to be had about, well, maybe the structure that was put in place to spread this and train people up and get them, you know, situated to do this well. has failed. And if that's the case, that's the problem. It's not really that the methodology is bad. It's that we didn't do a good job of explaining it or training people for it. that's a separate discussion. But I think that there's a lot of bad agile out there. And I'll just put it to you this way. If you like to hike or camp or anything like that. If you are an aficion…

    Full show notes at the publisher

    #113: Influence Without Authority with Christopher DiBella Aug 28, 2024
    Show notes

    Join Brian Milner as he talks with leadership expert Christopher DiBella about mastering the art of influencing without authority. Learn how to lead with respect, empathy, and compassion to inspire your team, even when you don’t hold the official title. Overview In this episode of the Agile Mentors Podcast, Brian interviews Christopher DiBella, an expert in leadership and organizational development, about the power of influencing without authority. They explore how Agile leaders, especially Scrum Masters, can effectively guide teams and influence organizational culture through respect, empathy, and compassion. Chris shares practical strategies for building trust, navigating generational differences, and leading through relationships rather than formal authority. The discussion also emphasizes the critical importance of understanding the motivations and needs of others to achieve lasting influence. Whether you're an Agile coach, Scrum Master, or organizational leader, this episode provides actionable advice for leading in a way that inspires collaboration and growth. References and resources mentioned in the show: Christopher DiBellaThe Leadership Survival Guide: A Blueprint for Leading with Purpose and Impact by Christopher DiBella, PH.D.#37 Servant Leadership, Not Spineless Leadership with Brad Swanson#70 The Role of a Leader in Agile with Mike Cohn#109 Leadership and Culture in DevOps with Claire ClarkShort Answers to Big Questions About Agile Leaders by Mike CohnCertified ScrumMaster® Training and Scrum CertificationCertified Scrum Product Owner® TrainingAdvanced Certified Scrum Product Owner®Advanced Certified ScrumMaster®Mike Cohn’s Better User Stories CourseMountain Goat Software Certified Scrum and Agile Training ScheduleJoin the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Christopher DiBella is a leadership coach dedicated to empowering aspiring leaders by teaching influential leadership practices that streamline processes and maximize potential. As the founder of the Institute of Leadership Coaching and Development, Chris is committed to helping others lead with respect, empathy, and compassion to build engaged, high-performing teams. Auto-generated Transcript: Brian (00:00)Welcome in Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have a very special guest with me. I have Mr. Chris DiBella with us. Welcome in, Chris. Chris (00:13)Thanks so much, Brian. I appreciate you guys having me. Brian (00:15)Absolutely. We're very excited to have Chris on. Chris, if you're not familiar with Chris and his work, just a brief little introduction here for you. Chris has an MBA in project management. has a PhD in organizational leadership. He's an author and speaker. He's the founder of something called, actually founder and president, excuse me, of the Institute of Leadership, Coaching and Development. And he has a book that should be out right about now while you're listening to this called the leadership survival guide quotes to keep you from going extinct as a leader. So very, very interesting title there. I can't wait to read that. That sounds amazing. But the reason we wanted to have Chris on was one of the topics that Chris focuses on and talks about from time to time is the topic of influencing without authority. And I thought that's really, really interesting in the Agile world and how that relates to things like Scrum Masters and how we work within the organization and stuff. So let's start there, Chris. Let's just talk about where that, what does that title mean to you influencing without authority? Where did that come from? How did that enter your sphere? Chris (01:27)Well, I mean, for the last couple of years, it's a topic that's just been gaining a lot of momentum within the workplace. I guess the easiest way for me to describe the topic is to say that influencing without authority is simply the ability to motivate others to get them to take your direction. But we all know that the real world doesn't work that way. And it's not so easy to get people on board with our ideas and thought processes. So we just need to be more methodical in our approach. when it comes to influencing others. And it's more important now, particularly because when dealing with the different generational and personal generational differences and personalities in the workplace. Brian (02:06)I'm kind of curious how you define that difference. What does influencing with authority look like? What does influencing without authority look like? Chris (02:18)So they kind of both the same. think people sometimes fail to realize that influence is what actually provides power, right? And not authority. So they both kind of fall on the same lines for me. So when you're trying to influence others, you got to remember that with or without authority, you're trying to get somebody, you're persuading somebody, recently you're coercing them to try to get onto your thought process. So you just got to remember that. When you're dealing with them, that you have the capacity to impact what happens next in their lives. Their lives, sorry, not lives. like you have the ability to shape their actions and their behaviors and their opinions, but you also have the ability to have an effect on their character or their continued development. Right. And kind of adding a little bit more to that question is Ken Blanchard, said that the key to successful leadership in today's workplace is influence and not authority. So for someone to be an influential leader, they just need to learn the skills of confidence and clarity and communication. So that to me implies that even if you're not in a formal position of authority, you can still have an influence on those around you. So it's kind of just bouncing off. You know, there's a thin line of with or without authority. It's just understanding people and understanding how to get the best out of them. And you don't need to be called leader or manager to get that out of people. Brian (03:48)I'm kind of curious because especially with your background in project management, kind of more traditional project management, how does that play in project management? I mean, I've gotten in trouble sometimes in talking in class about this issue because I've, know, in my work history, my experience with traditional project management was very much one of... authority. was very much that that person who was the project manager, basically there was a date, a set of work that we're trying to accomplish. it seemed as if the project manager's job was to kind of drive the team, push the team, be the parent of the team, and make sure that they come in on time, on scope, on budget. How does the project management community in today's environment see this dichotomy between leading with influence or with authority. Chris (04:50)So that's a great question because I think, can I even touch on Scrum teams with this? Cause, cause I think they're, kind of go hand in hand for me. Right. and I, you know, from, if we use project management or Scrum teams as an example, right. No one, even as a project manager, right. No one has any real form of authority on the people side of things. Project managers really are just people put in place just to get things done. Right. They don't, they don't have an official title to get things done. Right. So it can be argued that. Brian (04:54)Yeah, yeah, yeah, please. Chris (05:20)while these individuals on a Scrum team or a project management team have no formal authority at all, that they're still ultimately responsible for project outcomes, right? Or it can be argued that an authority is inherently given to them based on their ability to act on behalf of all those objectives. Right. But the bigger point for me is that if there's no formal authority given, this could just limit the influence that someone has on the people in the processes side. Right. But that doesn't mean that you still can't be an effective leader who others look to. And this type of authority is based more on who you are as a person and how you treat others, as opposed to simply being viewed by that title that you possess. So I think there's there's a very strong connection there between Scrumteam and project managers. Brian (06:04)Yeah, I mean, it's a tricky thing because I mean, I think about this, like a lot of things, I'll make sports analogies and how I think about these relationships. And when I think about like the coach of a team, the coach can't make the players perform better. It has to be their own personal decision to do what they need to do. But on the other hand, we definitely hold the coach accountable if the team isn't doing well. And it seems almost like slightly unfair, you know, to think about this, that I can't really, I don't really have the authority to make that person do something. I have to, as we said, influence them to do it. Chris (06:50)So can I touch on that real quick? Cause you brought up a great analogy that I like to talk about from coaching perspective. So I used to coach soccer and if I start rambling, just tell me to shut up, but I'm licensed to coach up to a college level, right? But I always opted to coach at about the 12 and 13 year age group for boys and girls. And I chose this age group because I believe that this is just where I could have the most influence on them in their development and in their soccer growth, right? Brian (06:59)You Chris (07:20)The high school level and college level, they could still learn, but they've already got it in there at that age, right? They they've already established who they are on the field, their own identity, right? And they have a good enough skillset to go out there and play the game. But I wanted to be a part of getting them to that point. So I decided that coaching at a younger age group would just give me a better opportunity to mold those players into those high school and college athletes. And anyone listening to this with kids understands. how much influence we have on them at that age. But we also know how difficult it is to effectively influence them in a way that allows them to develop into their own person. So whether we're coaching 12 and 13 year olds, or if we're trying to coach and mentor our peers or our followers, there are just a lot of similar attributes that can be used to influence others to get them to achieve their goals and their successes and those outcomes. Brian (08:11)Yeah. Yeah, I completely agree. you know, it kind of, it kind of brings to mind the, mean, we've talked, we talked a little bit about project managers, but, and, and touched a little bit on Scrum teams, but you know, that, that relationship with a, a, a Scrum master, think is also really interesting to consider in light of this, because I know one of the phrases that we use as trainers a lot when we talk about the Scrum master is a Scrum master leads through influence, not authority. And that that's kind of a defining characteristic of what a scrum master does. What does that mean to you? Because I know you speak about scrum as well and you have a lot of knowledge in this area. So how does that translate into the role a scrum master would play? Chris (08:58)So if you take it from a Scrum Master perspective, right? mean, that's kind of positional influence, right? So that can come from someone's job title or depending on the hierarchical level of that role, you know, that can have an effect on how influence is also portrayed, either positively or negatively. So whether you're a Scrum Master or some other form of positional leader, it just means that you're followed by other people. So how you choose to impact their life. from an influential aspect will determine the level of followership that you're able to acquire from them. Right. And then kind of going along with that, again, you know, there's really no formal authority in that role, but the influence can stem from expertise and just being competent. Right. That provides you with the background and the experience needed to be recognized for people to go to you for that advice, the leadership advice. But if you also have the available resources that your team needs and you know how to acquire them as well as deploy them, then you're going to have an impact on their success as well, right? If you have the necessary tools to provide them, that's also going to increase the likelihood of them trusting in you as those relationships are developed because that's really what influence is. It's about building relationships and developing those bonds, you know, and then influence. The biggest thing for me with influence is being direct and transparent in your approach. Whether you're a scrum master, project manager, anybody with or without authority, if you're direct and you're transparent and you seem genuine to people and you have a firm, a fair, and a professional tone, that's just going to let other people know that you can be counted on, right? And that you genuinely have their best interests at heart. So that's kind of where earned influence will begin to develop. Brian (10:50)Yeah. You know, I, there's a, there's a kind of aspect of this I try to draw out too, when we talk about this in class and that influence, as you said, trust relationship, right? It takes, it takes investment. It's not, influence doesn't come instantaneously. When you think about just in general in your life, the people who influenced you. Right, to use that word influence, that's a shift, that's a big shift. And when you think about the people that influence you versus the people who tell you what to do. And from my perspective, most of the people I would say, yeah, I'm heavily influenced by this or by that. It generally comes from the fact that I have, even if they're a public figure, even if it's, know, you know, Simon Sinek or Gary Vanderchuck, you know, I would say they influenced me not because I just heard one quote, but because I've consistently heard what they speak on and consistently say, yeah, I'm aligned to that. And this is really influencing the way I think about stuff. So how would you advise, especially someone like a scrum master, you know, if they say, yeah, I want to lead through influence, not authority, but... I've got a job to do. How do they start paving that road so that the influence is invited? Chris (12:26)Yeah. I love the Gary V shout out because I love Gary. He swears a lot like I do. So I'm actually being pretty good right now. I mean, I guess the first question to ask is, you know, when you think of the term influencer leadership, not for you, but in general, like when you think about it, what's the first thing that comes to mind, right? What are you hoping to get or achieve through that influence? Are you trying to get people on the same wavelength as you? Are y…

    Full show notes at the publisher

    #112: Exploring Collaboration Styles with Jessica Guistolise Aug 21, 2024
    Show notes

    Discover how recognizing and accommodating different collaboration styles can transform your Agile team dynamics. Join Brian Milner and Jessica Guistolise as they delve into the key to effective and inclusive collaboration. Overview In this episode of the Agile Mentors Podcast, Brian interviews Jessica Guistolise about the diverse collaboration styles that impact team dynamics. They explore the importance of recognizing and accommodating different collaboration styles—relational, expressive, and introspective—to create effective and inclusive collaborative environments. Jessica provides practical tips for Scrum Masters and facilitators to cater to these styles during meetings and retrospectives. The discussion emphasizes the value of diversity in collaboration styles, which brings different perspectives and ideas to the table, fostering creativity and innovation. References and resources mentioned in the show: Jessica GuistoliseLucidThe Collaboration Style Quiz & ReportThe Global Scrum GatheringAdvanced Certified ScrumMaster®Certified ScrumMaster® Training and Scrum CertificationAdvanced Certified Scrum Product Owner®Certified Scrum Product Owner® TrainingJoin the Agile Mentors CommunityMountain Goat Software Certified Scrum and Agile Training ScheduleSubscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Jessica Guistolise is an Agile Evangelist and coach at Lucid who excels in helping organizations deliver continuous value to their customers. With a passion for people over process, she specializes in change adoption, gaining critical buy-in, and establishing trust in Agile methodologies across various industries. Auto-generated Transcript: Brian (00:00)Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have a special guest with us. have Jessica Gastolis with us. Did I say that correctly? Jessica Guistolise (00:14)You did. Thank you so much. It's a mouthful. I am so happy to be here. Thank you so much for inviting Brian (00:21)Absolutely, incredibly excited to have you here. For those who aren't familiar with Jessica, she is an evangelist at Lucid. So I'm sure we'll hear a little bit about that as we talk. She is an agile coach and she has the credentials to back that up. She has from the Coaches Training Institute, a professional coach certification and also she's an ORSC coach, if you are familiar with that. I'm familiar with that. I know there's a lot that goes into getting those. So it's not just, you know, filling out a, sending in some box stops and, you know, getting it back in the mail. and, so the reason I wanted to have Jessica on is because she was speaking at, or she did speak at the scrum gathering that just took place, back in May. And, she had a couple of talks actually that she did with, Brian Stallings there. but one of them really caught my And I thought it would be interesting here to the audience. And that's about collaboration styles. So let's dive into that topic. When we talk about collaboration styles, Jessica, don't we all collaborate the same? Jessica Guistolise (01:33)You know, it's funny, we don't actually. Though, although there is a kind of a misconception that we do because we collaborate in the way that we collaborate, but not everybody collaborates in the same way. And so for us to create really amazing collaborative environments, it's helpful to have an awareness of those different styles. And if we facilitate in such a way that cares to each one of those styles, you're gonna get so much more in the room than you would if you only stick with, well, here's how I collaborate. So obviously this is the way to do it. Brian (02:09)Right. Yeah, I think this is such an important topic because I know one of the questions I'll get a lot in classes or just even in Q &A sessions when we talk about retrospectives is, I'm having a hard time facilitating my retrospective and my team doesn't want to talk or my team's quiet and shy. And to me, this is all kind of indicative of this concept of you're probably not recognizing that they have different collaboration styles than you do. Jessica Guistolise (02:41)Yeah, absolutely. And it's so amazing because I think as Scrum Masters, as Agile Coaches, this is a really important piece to recognize because as the facilitator, you're really building the container. think of these events as like the containers and the folks who are doing the work, they're all the content. But if you build a container that's going to allow for that content to emerge in a healthy way, you just, I mean, Anything's possible. Brian (03:10)Right, right. And you know, one of the things I love to say in classes is just that, you know, that facilitation, that's the root goes back to this phrase, it means to make easy. And you know, that's our job is to make whatever that thing is easy. And if we are, if we're not aware of our own personal preference and style and how we collaborate, then it's harder for us to even be empathetic or recognize that other people have different styles and much less how to accommodate them and be inclusive of them in those environments. So I just think it's a really important Jessica Guistolise (03:51)Well, and the interesting thing too, besides easy, there's also an element of safety. Because if you're asking me to collaborate in a way that makes me really uncomfortable, then I'm spending all of that time in my discomfort and trying to put forth ideas. Those two things are so, they clash. And so there's also an element of just creating an environment of not just easy because this is the way that I collaborate, but I feel safe in collaborating in a that make sense to me. In fact, there's some, there are a couple of styles that are almost opposites. So if you're asking me to collaborate in that way, ooh, I am not sharing anything with you. Brian (04:31)Right, right, you have that amygdala hijack going on. You're kind of, you're in that fight or flight mode of just, my gosh, I'm panicked. I don't want to do this. I feel highly uncomfortable. you know, it's, can, you know, literally it's blocking those neural pathways of actually being able to collaborate and access, you know, the parts of your brain that would allow you to, to contribute in that kind of environment. Jessica Guistolise (04:59)Yeah, it's fascinating actually, right before the study that was done came out, I was in a collaboration with a group of people who were collaborating in a way that was wildly uncomfortable. And I came out of that meeting feeling dumb. Like I really was like, wow, I didn't, I just gave nothing. But then, you know, a little while later I was like, well, but I have this idea and this idea and this, wait a minute. I was just stuck because this isn't a way that's very comfortable for me. Brian (05:28)Yeah. Well, you know, I know you probably know this, but for anyone else listening out there as well, I have definitely felt that way as well in sessions that were kind of contrary to, you know, opposite of what I prefer. And, you know, the way I always describe it is I don't, I'm not a person who thinks out loud. I think internally, I think quietly and then express it later. I need time to process and work through things. But I recognize there are others who are verbal processors who need to speak out loud and and You know if you're in a meeting with a bunch of those Types of people who have that collaboration style and and yours is a quiet one Then you know I've walked out of those rooms before feeling like gosh I'm the dumb one in this meeting because I didn't have anything to contribute Jessica Guistolise (06:12)Yeah, I didn't provide any value in that, but there is, there's so important to recognize that. And I think there's, there's, there are ways to create these containers and to create these collaboration sales that really help to make it so that everyone can feel comfortable collaborating in the way that is going to be comfortable for them. And it just, it's, you know, it's the facilitator work of being prepared. Brian (06:16)Right, right. Jessica Guistolise (06:38)preparing for the meeting or the event, creating the container in a way that's going to be safe, comfortable, and easy for everyone. Brian (06:45)Yeah, absolutely. All right, well, let's get to the meat of that then, because I know there are a few, you kind of delineated these in the presentation that you had. So walk us through, what are the differences in these different kinds of collaboration styles? Jessica Guistolise (06:59)Yeah, so the study was done, Lucid did a really interesting study. I was so excited by this. And what they found was over half of knowledge workers identify with one of three collaboration styles. And the other part of that is you may not land fully in one of the three and you may have kind of a blend of them, but these are the ones that we see most often. And one of the things that I always like to point out too is that none of these are Like it's just the way that you feel comfortable. They're all really helpful and healthy and really great ways of coming together. So I'll start with the one that I most identify with because it makes the most sense to me. That's we normally create collaboration is we see how do I collaborate and I'll collaborate with you. So the first is relational. And so relational collaborators really want that human connection. Like they want to be, they want to spend some time. How was your weekend? Or just if it's a brand new person, let's get to know each other a little bit before we dive into trying to solve problems. there's it's, it's almost like, for me, I just feel like I need to be in relation with, in relationship with someone before I'm comfortable collaborating. It's like, the metaphor I like to use is, is like baking bread. If I'm in relationship with you, I'm gonna bring you ingredients and recipes and stuff that I'm playing with and trying to figure out. But if I'm not in relationship with you, I will have that entire thing baked and then bring it out and see if you like it. But that's not collaboration, right? That's me by myself and how much better is the bread gonna be if somebody says, well, let's try this and let's try this and let's try this. So that's a relational Brian (08:49)So that sounds like that one in particular needs just a tremendous amount of trust to be effective. Jessica Guistolise (08:55)It does. really does. And I actually, I'll tell you a story about this because, so I, I was working with, an individual who had an interesting problem to solve another agile coach. and he'd come up to me and he was like, I have this interesting problem. Do you have anything in your coaching toolbox or knapsack that you can pull out for me really quickly? And I was like, Hmm, you know what? actually don't. but let me think about And so I went, was doing some other things and sort of in the back of my brain. And then I had just an absolutely ridiculous idea. I mean, it was like, I, I felt silly even thinking it, let alone saying it out loud, but I was in really great relationship with this other individual. So I ran across the hall and I said, okay, I have a really dumb idea. And he goes, okay, let's hear it. And I told him, and he goes, wow, that's really dumb. Let's play with it. And so we played with it and got it into something and he took it back to the team and it worked spectacularly. And I think he's still using it today as an exercise that'll help with the team's collaboration. but if I hadn't been in relationship with him, I would have had that dumb idea and then I would have let it go. Brian (10:10)Right, right, because you know, you don't want to get made fun of or you don't want to be made to feel dumb or anything. So yeah, absolutely. You got to have that trust and sense of safety with them to be able to bring it up. That's a great Jessica Guistolise (10:23)Yeah. The second one is one that I wish I had more of and I just don't. So some people identify as expressives. If you're an expressive collaborator, you are ready to dive in at any moment. Like somebody can throw out a topic and you've got, you're the first voice in the room. You love using visuals and drawing out your ideas and throwing up sticky notes and emojis. You're one of those people that's I'm ready to, I'm just ready to share. I really wish I had more of that. Sometimes I think of them as blerters. Like they're just willing to blurt it out. Whatever is there on top of mind and a brainstorm. And I just, think that's so admirable and it's just not a skill that I have. Brian (11:09)So less of that filter then. mean, it sounds like they don't necessarily need to have that basis of trust. They're just sort of always willing to say what's on the top of their mind and get it out in the open. Jessica Guistolise (11:22)Yeah, yeah, I think it's a great way of expressing themselves. And they also have maybe a harder time spending that time getting into relationship and all of that ooey gooey stuff. And they're like, let's get to the work, you know. But if we have an awareness that I as an expressive am working with a relational collaborator, some of the work is getting into relationship. So now I feel more comfortable spending that time because I know that the work we're going to do after that is going to be greatly Brian (11:57)And correct me here if I'm wrong, because I'm just trying to make sure that we're understanding all speaking the same terminology here, but it sounds like the way you describe this, that expressives are not necessarily verbal expressives. Like you mentioned, someone who's more sketch note based or anything like that. So they may not feel comfortable speaking, but they're very comfortable with the concept of getting an idea out of their head quickly in one way, or Jessica Guistolise (12:26)Yes, exactly. It could be in visual form. think of like people who always have memes or GIFs at their fingertips. Like they're just ready to go and send out these their ideas into the world and not hold on to them tightly. know, they hold them on, hold on to them, Lucy, please, because they're coming out in the world. Brian (12:44)Hold on loosely, but don't let go. Awesome, I love that. Okay, and then was there another one? Jessica Guistolise (12:52)There is. So the last one is introspective. So an introspective collaborator, I dip my toe in introspective collaboration as well. Deep work is really, you love deep work. Spending time really processing, thinking through, chewing on an idea, tossing, playing with it a little bit yourself before beginning to share. It's the opportunity to do some research, do…

    Full show notes at the publisher

    #111: Adapting to the Future of Work with Heather McGowan Aug 14, 2024
    Show notes

    Explore the dynamic future of work with Brian Milner and Heather McGowan as they discuss the essential shifts in mindset and culture needed to thrive in the augmented era. Overview In this episode of the Agile Mentors Podcast, Brian Milner interviews Heather McGowan, a renowned future of work strategist, about the rapidly changing landscape of work in the augmented era. Heather emphasizes the importance of adaptation, empathy, and human connection in response to technological, societal, and cultural shifts. They discuss the pervasive issue of loneliness in the workplace and the critical role of leaders in fostering a culture of trust, agency, and high expectations to drive performance and productivity. Heather also shares insights on finding personal purpose and intrinsic motivation to excel in the future of work. This conversation provides valuable strategies for individuals and leaders to navigate the evolving work environment successfully. References and resources mentioned in the show: Heather McGowanHeather’s Website The Adaptation Advantage by Heather McGowan & Chris ShipleyThe Empathy Advantage by Heather McGowan & Chris ShipleyThe UpSwing by Robert PutnamAgile Training for Teams & LeadersSubscribe to the Agile Mentors PodcastMountain Goat Software Certified Scrum and Agile Training ScheduleJoin the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Heather McGowan is a leading strategist and keynote speaker on the Future of Work, known for transforming mindsets and organizations with her insights on continuous learning, leadership, and culture. Her groundbreaking approach has empowered employees, enhanced leaders' effectiveness through empathy, and driven businesses to achieve their goals in a rapidly evolving market. Auto-generated Transcript: Brian (00:00)Welcome in Agile Mentors. We're back with you for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today we have someone I'm very, very excited to have on. She was the keynote speaker that kicked off our Scrum Gathering in New Orleans this year. It's Ms. Heather McGowan. So welcome in, Heather. Heather (00:20)Hey there, thanks so much for having Brian (00:23)I'm so excited to have Heather in. If you're not familiar with Heather's work, she has, think, the best job title I think I've ever heard. She is the future of work strategist. And like I said, that's awesome. I love that. But beyond that, there's a lot that I could say about Heather to introduce her to you. But I'll give you a couple of things just so you kind of understand the perspective of her coming home. First, She was named one of the top 50 female futurists by Forbes. So let that sink in. She also has two incredible books out there. One called The Adaptation Advantage. has more than two books, two recent books. The Adaptation Advantage, Let Go, Learn Fast, and Thrive in the Future of Work. That's one. And her latest one that just came out recently, it's called The Empathy Advantage. leading the empowered workforce. And I'm very, excited to have her on because her talk at the Scrum Gathering really captured my imagination. And I think everyone's imagination there. so let's just dive in, Heather. Let's talk about this whole concept of the future of work. And I think one of the ways you started in the presentation, I think, was really important to try to understand where we are on the timeline of the work. the way we have progressed through ways of working. So where are we? Where would you put us on the timeline? Heather (01:57)Yeah, so first of all, the title, Future Work Strategist, was not something I applied for. It's a title. Brian (02:03)Really? Because I want to fill out that job application. Heather (02:07)It's a title I created because I felt like there was a need for many of us to be working in looking at the future work, which is something that will never be done. It often gets conflated with being about where we work or DEI issues, but really it is about those things. But for me, it's about leadership, it's about workforce, it's about learning, it's about adaptation, it's about purpose. It's about adapting right now pretty rapid changes that are not only technological, but societal and cultural and demographic and generational. And we're wrestling with just a lot of change at once. one of the things I say to folks is sometimes I think that the majority of what we're going to be doing in the near term is helping each other adapt. Because we're to have to adapt at a clip we've never had to adapt to before. Prior generations had maybe one paradigm shifting change in a generation. Now we might have three or four. Brian (03:02)Yeah. Heather (03:03)So in terms of where we are, we had the agricultural era and the industrial era and the information era. Well, we're now in the augmented era. So we're dealing with technology consuming tasks that we do at a faster and faster clip. And a lot of people kind of catastrophize it about technology taking away jobs. We're the only species that would invent things to make ourselves irrelevant. that's how what people, but it doesn't make any sense. What we're really doing is inventing technologies that augment our potential. And it requires us to not only learn and adapt and think about differently about who we are, which is what the adaptation advantage was really about, but how do we relate to each other? How do we get the best out of each other? And that's really what the empathy advantage was about. So we're in the augmented era. Technology is going to continue to come at a faster and faster clip. But it's more important for us to think about how we learn and adapt and how we lean into our uniquely human skills. Because... The technology can provide the answers, but it's up to us to find the questions. Brian (04:04)That's awesome. Yeah. I think that's such an excellent point that, you know, just trying to think about the fact that, yes, in previous generations, there may have been one paradigm shifting kind of change that comes through a lifetime in the way that we work. But in our lifetimes, we've dealt with the Internet coming on board and we've dealt with multiple revolutions since then, mobile and AI. And these things happen. it's such a greater clip that it really does shift even even things like COVID changing, a lot of places working from home previously was always in the office. It seems like change is the constant now and that change is kind of the thing that we need to get good at is being adaptive and able to change. Why do you feel like, I'm just kind of curious of your opinion on this, why do feel like we're so resistant as humans to just change in general? Heather (05:00)I think we have a fear of obsolescence. then in times like right now, I delve into this sometimes in some of my talks, is we're going through some pretty significant division and polarization. It's really acute in the US, but it's happening all over the world. You look at the elections in France and the UK recently. I think it's important to understand how that happened because a lot of people think that's just social media. And technology did come into play, but if you look back in the US anyway in the 70s and 80s, that's when we started to see a real erosion in our social fabric. We started having fewer people over for dinner and being part of fewer fewer clubs, talking to our neighbors less. So we got more and more isolated. And then we had a loneliness epidemic that's been around for at least a decade or so, which, and when you're lonely, your amygdala, the kind of reptilian part of your brain goes into overdrive. So you go into fight or flight mode. So you have a lot of change, isolation, fight or flight mode, and then you throw in social media that kind of catastrophizes things. And we're all in this us versus them mode. And we've stopped seeing, hearing each other. And one of my messages in almost all my talks is we have so much more in common than we have in difference. They show lots of studies from it. So if we just could start talking to each other again, we may not vote for the same candidate. We don't vote for the same teams, but we both love the sport. And that's what we need to get back to is understanding how much we have in common because so much of the work we're going to be doing, especially when technology comes in, is communication, collaboration, exploration. And all of those things require us to relate to each other because you're going to see something that I don't see. And if I only hired people who think like me, it would be tragic because I wouldn't see the entirety of the opportunity. So if you want to really drive profitable growth in your company, you want those diversities of inputs and you want to set a culture that has people see and hear each other so you can see optimally the opportunity space. And because that's what we're going to be doing. It's most of the work we're going be doing. Brian (06:55)Yeah, yeah, this is a fascinating fact to me because I, one of the things I start in your presentation is just this idea about loneliness. And I absolutely agree. You know, there's, I think we all can kind of recognize that even though we've tried to create these social media companies that to try to, you know, get a, gain a stronger sense of connection in some ways it's driven the opposite of this sort of loneliness factor. But I'm curious from from some sort of a sociological perspective, that has, it seems, transferred into our workplace. And I know one of your stats there was about how we feel more lonely at work. And I'm just curious, what do you think is driving that, the kind of sense of loneliness that we have while at Heather (07:48)Yeah, know, some folks will point that to being about where we work. That's not my area of expertise. There plenty of people who look at where we work. That may be a factor for some folks if you're working remotely and you don't see other people, certainly a factor. But what I think what's really happening is we've outsized what work is in our lives. So community used to consist of social interactions, religious affiliations. clubs and groups we belong to, all of those kind of, if you think of them as circles, because everything's visual to me, all those circles shrank and work became bigger. So now part of it's generational change, but more and more people are looking for work to provide their purpose, work to provide most of their relationships, work to fill these. So it's a little bit in terms of how we're interacting with each other that's causing the loneliness, but it's also an outsize expectation we have around work. So now it becomes table stakes for a lot of organizations for work to be my self -expression, work to be my sense of purpose, work to be where I think about my values. And it wasn't like that a few decades ago. Brian (08:49)Yeah. Yeah, that's, I just, I love that point. think you're absolutely hitting the nail on the head with that. And, and, know, just so everyone listening doesn't, doesn't misinterpret this in any way, you know, we're not, we're not saying in any way that those other kinds of organizations like churches or community groups or anything are bad or that you shouldn't see community and those kinds of things. It's just that our society has sort of moved away from those as being the foundational, places where we get community and you're I absolutely agree. is, work has sort of filled that. Sort of analogous, I think, to the way that police have become the front line of our mental health, Heather (09:27)Mental health, yeah, exactly. Exactly, and that's not fair to the police and they're not prepared to do that and, you know, we suffer. I think the point with work is that that is where we are. So if you're leading an organization today, that is a reality. I hope that changes. I'm a big fan of Robert Putnam. He wrote Bullying Alone in the late 90s and he pointed out the sort of phrase we're having in ourselves, of fabric. He had another book that came out in, I think it was 2020 or 2021, in the middle of pandemic where he... which was called the upswing, where he says we go through these kind of, you you think about it like a pendulum, we go through periods of high collectivism, you know, the kind of the eye to the we. And we're at the highest, you know, the lowest level of the we and the highest level of the eye in terms of being isolated and all that we do. And we're primed to go back into a we phase. So I'll be interested to see what forms of community start to emerge because we're primed to have that happen. Soon, like I notice is a, live most of the time in Florida, part of the time in Massachusetts. It's a restaurant I go to in Florida. And I was like, why do we love that restaurant so much? I do like the food. It's very good. But it has a situation that an empty seat is is a, is anywhere you could sit. So if I come in by myself or with one other person, they would sit me at the table with one other person or two or 300 people. It's community seating. So you end up sitting with people that you don't know having conversations. It's kind of like a forced community. It's fantastic. Brian (10:53)Yeah, that's awesome. I love that. I mean, I will say, you know, the introvert part of me is like, I don't want to sit down. Right. Yeah. I identify with that. Yeah. Awesome. Well, so if we have this problem, right, we're dealing with, with a fear of change. We're dealing with a work in place that is lonelier than it's ever been. And we were dealing with a population that's seeking belongings, sinking. Heather (10:59)I'm an introvert too, but when I'm forced, it's good for me. Brian (11:23)connection and community while at work. I think you're right that that has a profound impact on the way we work even. And I know you talked a little bit about just kind of the main drivers of productivity, the main drivers of being successful. And I think that this is maybe counterintuitive to what some people think. Help us, talk us through that a little bit about what you found as far as what really drives productivity. Heather (11:58)Sure, so just to give you a little background on me that relates to this point. So I spent the last, prior to when I started speaking full time, which is about 10 years ago, I spent 10 to 15 years working on the corporate side, industrial design, product design, design strategy, so new innovation stuff. And every organization I went into, I felt people really weren't equipped. to propositionally think. They could reiterate on the existing solutions. If they had a product, they could make another version of that product, but they couldn't jump entirely to a white space an…

    Full show notes at the publisher

    #110: Overcoming Organizational Dysfunctions with Lucy O’Keefe Aug 07, 2024
    Show notes

    Explore the hidden barriers to successful Scrum adoption as Brian Milner and Lucy O'Keefe dive into organizational dysfunctions and cultural impediments in this insightful episode of the Agile Mentors Podcast. Overview In this episode of the Agile Mentors Podcast, Brian Milner sits down with Lucy O’Keefe to unpack the organizational dysfunctions highlighted in their talk at the Scrum Gathering. They delve into how culture can significantly hinder Scrum adoption and discuss other common impediments like resistance to change, command and control leadership, and siloed teams. Emphasizing the importance of transparency, inspection, and adaptation, Brian and Lucy offer actionable insights to help organizations overcome these challenges. Listeners will also learn why leadership understanding and stakeholder participation are crucial for successful Agile adoption and the necessity of training in Agile values and principles for true organizational change. References and resources mentioned in the show: Lucy O’KeefeDart Frog ConsultingPath to CTC - Monthly Cohorts#109 Leadership and Culture in DevOps with Claire ClarkAgile for LeadersJoin the Agile Mentors CommunityMountain Goat Software Certified Scrum and Agile Training ScheduleSubscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Lucy O'Keefe has over 28 years of IT experience and has worn multiple hats in the Agile world - developer, Product Owner, Scrum Master, and now, Certified Scrum Trainer® (CST) where she uses her experience to ensure each student has a great training experience. Auto-generated Transcript: Brian (00:00)Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner, and we have a favorite back with us today. We have Ms. Lucy O 'Keefe with us. Welcome in Lucy. Lucy O'Keefe (00:12)Thank you so much, Brian. Happy to be here again. Brian (00:14)Very happy to have Lucy back with us. Lucy and I saw each other recently. Actually, I think it was the first time we saw each other in person, right? Yeah. We finally saw each other in person at the Scrum Gathering that took place recently in New Orleans. And I had the pleasure of getting to see Lucy's talk that she had there at the Scrum Gathering. And... Lucy O'Keefe (00:22)It was the first time, yep. Finally. Brian (00:41)She gave a talk with Joe Miller called, Scrum Unmasked, Unveiling the Dysfunctions Within Our Organizations. And I thought it would be a good opportunity to bring Lucy back and talk a little bit about this topic, because this is an important topic. And it was a packed room, it was full of people that wanted to know about this as well. So I thought it'd be a good chance for us to share this with the audience. But to start this, actually, before I even begin, I get ahead of myself. myself here a little bit. For those who maybe haven't heard Lucy on the podcast before, Lucy is a CST. She has a CTC. Her company is called Dart Frog Consulting. And she also has started recently this mentoring program with a new smally that is kind of a really interesting concept. It's a CTC mentoring cohort. So if that's something you're interested in, We'll put links into our show notes that you can get in contact with her about that. But if you're interested in pursuing certified team coach certification with the Scrum Alliance, that's a really great way to do that. You get a group of people around it and kind of go on that journey together. But let's talk about this topic. And I thought a good way to start was actually to be a little bit meta about this. I want to go behind the scenes a little bit. and think about where this topic came from, what's the genesis of where this came from and how you and Joe hooked up on this. So give us a little bit of the backstory of where this idea came from. Lucy O'Keefe (02:20)So to start, Joe and I have worked together. We worked at a consulting firm together. And funny enough, we actually were both speakers at a virtual conference a few years ago. He was on the panel and I was an actual speaker, but we never met. Back then we met actually when we started working in the same consulting firm. And of course I left the consulting firm a few years ago to go independent, but we just kept in touch and we always wanted to do something together. so when, when I was trying to figure out topics for the scrum gathering in New Orleans, I reached out to him and I asked if he would want to do a talk with me. A lot of times it's much easier to do it with somebody else. And I thought it would be fun because he and I see eye to eye on a lot of stuff. And I think we, we complement each other pretty well. But when we were talking about what topics we'd want to talk about, I kind of always go back to the things that I've experienced when I've been in organizations. And I think, I think a lot of us have experienced kind of something, something similar where people are going to say, scrum just doesn't work for us. Right. I actually, it was actually one of my first blogs that I wrote probably six, seven years ago was about that, about people saying, it just doesn't work for us. There, you know, it's not something that we can do. So I kind of got this idea that this is what we should be talking about. And I always go back to. Ken Trebers quote, and I said this during the talk, you may recall, you know, scrum is like your mother -in -law, it points out all your faults. So this idea that scrum is holding up this mirror, you know, to the organization is something that I always talk about. And I think it's important for scrum masters and others in organizations to understand that, no, it's not scrum that's the issue. It's that we have all this stuff that's not, going well in our organizations and we're just putting Scrum on top of it without fixing the issues, right? So we're trying to put a band -aid on what's going on in our organization instead of looking at the root cause. So I just thought that that would be a great topic to talk about. Brian (04:27)I love that. And I think that's a great way to look at it because you're right. It's not something that's going to fix everything, but it does make it very revealing. I remember the phrase I've always heard people use is it's not a silver bullet, it's a silver mirror. You know, like it's going to reflect back very honestly to you what's going on. Awesome. Well, that's that. Thank you for the backstory. I really appreciate that because I know a lot of people, you know, if you're listening to this, you may be considering, you know, do I want to submit and try to speak at a conference? So. Lucy O'Keefe (04:41)Yep. Brian (04:57)just to give a little background to where those kind of ideas come from. I thought that would be interesting little sideline there. So let's get into our topic. Let's talk about some of these dysfunctions because I know the main point of this was talking about organizational dysfunctions, kind of some common problem. So hit us up. Give us a few of these big organizational dysfunctions that you guys talked about. Lucy O'Keefe (05:22)So I think the main one and one that's probably going to resonate with a lot of people is culture. For me, culture is always the biggest issue. People are the biggest issue, right? You know, as you know, you probably remember this, right? In the previous Scrum guide, it would say, Scrum is simple to understand, but difficult to master, right? Or difficult to implement because it involves people. So culture is the biggest issue and culture encompasses... quite a few things, right? It could be resistance to change within an organization. It could be a lack of empowerment. It could be command and control, which I'm sure you've seen in plenty of organizations. I've seen plenty of organizations, even though we know that we are hiring the best people, a lot of leaders or managers actually I'll call them, you know, still want to be in control, still want to be the people telling people what to do. And it's very hard to go to... to a way of working where it's like, okay, I need to remove myself from the equation and trust that these people are gonna do what they should be doing. So I think culture encompasses a lot of the other things that we talk about when we're talking about organizational impediments. Another thing is organizational structure. Are we highly hierarchical? Are we a matrixed organization? Do we still have these silo teams, right? That work on just specific skills? And I'm sure you've seen this. I'm sure you've worked in waterfall just like I have in the past, right? You have your business analysts on one side. You have your designers on another side and then your developers and then your testers, right? And they're all reporting into a business analyst or tester or developer or anything like that. So there is no cohesive team that has one. focus or one objective. You know, we're matric, you know, getting these people out of that matrix and putting them into a team. But they're all just interested in their own thing, right? It's a very siloed way of working. So it's very hard to make that transition into, okay, we are a product team and we work together. And we have to be dedicated and stable. Because we're not used to seeing that in a lot of organizations, people are not dedicated to teams. And we're talking about waterfall. I have barely seen any of that. I used to have a team where, and there was already a scrum team, but we had three BAs on the team and they were each 33%. And that's something that is very normal. And even when I'm teaching my classes and I'm sure you have the same questions or comments, a lot of people are like, well, this is very hard for us because we have John Doe here who, you know, he's in five different teams. How is he going to go to all these events? So that's definitely another organizational impediment, which for me kind of goes back to culture as well. Right? So those things are big things. Leadership not understanding. Yeah, sorry. Yeah, no, go ahead. Brian (08:10)Yes. Yeah. I was thinking, I was thinking, sorry, I didn't mean to interrupt you, but I was just, I was thinking the same thing that when you said that, that just, yeah, it is very, the hierarchy of the organization is very cultural. And if you, you know, if we're, we're trying to empower teams and instill in them this idea that, Hey, you need to, in order to move fast, you've got to have autonomy and you've got to have the ability to go and make decisions. that's, that's very. much ingrained in how we structure our organization. If I have to get approval for everything I do, that's going to run counter to what we're trying to do in a Scrum environment. So I love that you made that connection. I absolutely agree with you. It's a very cultural thing. Lucy O'Keefe (08:59)It is, it is. Yeah. And as I said before, I think a lot of the impediments we see go back to culture, leadership, understanding leadership participation, a lot of organizations when they're thinking about agile, they're thinking about scrum. It's like, okay, the teams need to do that. All right. Let's, let's start in IT and our IT teams are going to start doing scrum and who cares about the rest of the organization. We're going to keep thinking the way that, that we've always been thinking. We're going to keep budgeting the way we've always budgeted. And then we have. We have a lot more resistance, a lot more conflict because we have a team that's trying to work in a certain way. And then you have stakeholders and leadership that are expecting things to be the way that they always were. So stakeholder participation, for example, you know, a lot of stakeholders are going to be like, well, I already told you what I want. Why are you coming to me every two weeks or, you know, however long our sprints are, you know, for to get feedback. You know what I want. I shouldn't have to talk to you about it. Right. So there's that lack of understanding of what's in it for them. So back to culture again, right, understanding that this is a whole cultural shift. It's not just a team shift. So leadership needs to understand that. And of course, as you know, you know, we have, you know, certified agile leadership programs that I'm trying not trying to do a plug here for those classes. I don't even teach them. But. Brian (10:03)Yeah. Ha ha ha. Lucy O'Keefe (10:22)it's so important that leadership understands what it means to be an agile organization and what it means to lead in an agile organization. And I think when they do that, when they're able to get that understanding, it's going to make it a lot easier for everybody to succeed. So once again, that is another big impediment that I've seen is the lack of leadership and stakeholder understanding. Brian (10:46)Yeah, absolutely agree. I mean, it's almost like the concept seems to be more, like you said, we'll start from the team and build up when really it should be more of a from a top down or even not even kind of whole, right. Right, it's kind of, it's a whole organization thing. And if we try to compartmentalize it and say, no, we're just gonna do this group. Lucy O'Keefe (10:57)up and down. Or even from both extremes and meet in the middle. Right? Yeah. Brian (11:13)then we're already kind of setting ourselves up to fail a little bit because I can't change the culture of just one segment of my organization. If I do that and they have a different culture than the rest of the organization, then we have cultures at odds with each other and they're set to fail. The more dominant one's gonna overtake the lesser one, which is usually gonna be the scrum side of things. So yeah, I completely agree. Yeah, yeah, frustration. Lucy O'Keefe (11:37)Exactly. Yeah. And it causes a lot of frustration. Yeah. It causes a lot of frustration for the team. Right. So I was actually at a, I was contracting at an agricultural manufacturing company. I may have brought this up before, but like the, the stakeholders didn't understand why they had to come to sprint and review, why, why they had to talk to the product owner instead of just talking to the engineers themselves. And it wasn't until I had. the lunch and learn with the stakeholders and help them understand what's in it for them because that's what's so important. How am I going to, how is it going to improve things for me if I abide by what you're trying to do? It wasn't until we did that, that they were like, I understand now why I need to talk to the product owner. I understand now why I shouldn't be dealing with the developers or the engineers themselves. I understand now why my feedback's needed. Yeah, it's great that no…

    Full show notes at the publisher

    #109: Leadership and Culture in DevOps with Claire Clark Jul 31, 2024
    Show notes

    Join Brian as he chats with DevOps expert Claire Clark about the cultural and mindset shifts needed for successful DevOps adoption, the concept of 'shift left,' and the crucial role of leadership support. Overview In this episode of the Agile Mentors Podcast, Brian and Claire Clark, founder of Sienso, winner of the The Great British Business Woman Award, and freelance software development executive, delve into the world of DevOps. Claire explains that DevOps is far more than just tools and processes—it's about fostering the right mindset and cultural shifts within the team. They discuss the 'shift left' approach, emphasizing the importance of considering end stages of software development early on. Claire highlights the critical role of leadership in supporting DevOps principles and aligning team goals. She also shares strategies for measuring success through a maturity matrix and underscores the importance of continuous improvement. This conversation provides a holistic view of DevOps, integrating both technical and cultural aspects. References and resources mentioned in the show: Claire ClarkSienso#108 Adaptive Organizations with Ken RickardMountain Goat Software’s Working on a Scrum TeamJoin the Agile Mentors CommunitySubscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Claire Clark is a multi-award-winning transformational leader and Chartered Engineer with over 20 years of experience in Software Engineering. Specializing in leading high-performing teams, Agile transformation, and DevOps, Claire has successfully managed complex projects across various industries, including cybersecurity, logistics, and financial services. Auto-generated Transcript: Brian (00:00)Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast. And today we have a very special guest with us, someone I've been trying to get on for a while. We have Ms. Claire Clark with us. Welcome in, Claire. Glad you're here. Claire has been in our world for a while here at Mountain Goat. And she's had lots of interactions with us and Mike and over the years. Claire Clark (00:13)Hi, hi, good to meet you. Brian (00:29)And just for people who aren't familiar with Claire and her work, she is, I guess the best way to describe it is kind of a freelance software development executive. She kind of comes in in high level, kind of more temporary positions, would you say, Claire? Okay. Yeah, kind of coming in on the spot positions to help get people over the hump and get them situated and set up the way they need to be from an executive level. Claire Clark (00:44)Yeah. Yeah. Brian (00:56)Her company is called Cienso and she's won numerous awards over the years, but most recently she had a really huge honor. She was the winner in the engineering category of the Great British Businesswoman Awards. So first of all, congratulations on that. That's awesome. And the reason that we wanted to have Claire on was... Claire Clark (01:15)Thank you. Brian (01:22)just to share a little bit of her knowledge with us, and particularly the area of DevOps. She's done a lot of work with teams and building the teams. And we've had some really interesting discussions offline about this area. So let's start and just set the table a little bit here, Claire, for everyone. When we're talking about DevOps, first of all, let's just kind of explain what that means for people who aren't familiar with it. Claire Clark (01:47)Yeah. So I tend to describe it as it's a way that teams collaborate for the continuous delivery of a product from end to end, to get the value of the product to a customer. So it, it's not a specific process, a specific tool. It's a little bit around the mindset and approach to things. And how you get that continuous development and delivery of a software product, for example, to a customer. So yeah, I think people often tend to see it as possibly it's a tool thing or it's a process thing. And it's not quite that, it's all elements of that and a mindset side of it as well. Brian (02:42)Awesome. Yeah. That was the thing that I found really interesting in our conversation. And some of the things I've seen you write about this online, it's just the concept here that DevOps is really kind of a mindset. It's kind of a cultural thing. It's kind of culture first. And a lot of times we think of this as a set of practices. So let's get into that a little bit. How does the adoption of DevOps kind of change the culture? Claire Clark (03:03)Yeah. Brian (03:11)in an organization. Claire Clark (03:12)Yeah, I think in terms of changing the culture, it taps quite a lot into the agile side of culture, I guess, in that it promotes that collaboration and the continuous delivery of an integration of software, of a software product to a customer. So what I found is that, for example, with agile, That brought together a big collaboration with development and test and your product function. And then the DevOps kind of movement, I'll call it, sort of come to life a bit more. And that's where it then changed the culture again in terms of extending, I guess, the kind of agile side of things, but embedding the continuous integration and delivery into what the software engineering team does. So the operational aspects of the software. become more forefront into the, into like the team's thinking. They become like shift left. Do you think about this earlier? How are you going to maintain and deploy systems and how are they going to integrate? And I think that's where it's really shifted the culture quite a lot where instead of it being the, you know, we create, create the software and now there's an operational aspect of how we then deploy and integrate some of the dev op development and test aspects. into that. So I feel like it's really got into the mind, a lot of people's minds that we need to think of the full end to end when we're talking about building and delivering a product. It's everything and it's how you can make that pipeline that chain through that development team more of a continuous approach. So teams that have succeeded with Agile tend to be able to approach. embedding that DevOps mindset that bit more because there's a lot of overlap between some of the principles and the mindset needed between the two. So. Brian (05:16)Yeah, no, I absolutely agree. And you mentioned a term there that I've always loved in the DevOps community. And just in case people there aren't familiar with it, when you talk about shift left, what does that mean to you? What do you mean by shift left? Claire Clark (05:32)So for me, it means if you took a typical software development lifecycle and there's requirements, development and test and so on, it's very sequential and it typically follows the order. And what the mindset brings with DevOps and shift left, and you see this a lot with testing the term shift left is think about the latter stages up front. So the more you can think about some of those end, stages of software development and deployment and integration to customer systems, the more you think about them upfront, the more you start to design the way of working in what you're doing through agile and your continuous approaches, you start to embed that earlier. So it becomes a thought right at the front instead of being an add -on at the end. So shift left in essence being... what normally you would have done in a sequential manner and ends up far down the chain, you start trying to identify how could we do, how could we bring this earlier? What, you know, you start thinking about earlier, start looking at the practices and tooling and all those processes that people are doing in the software team. You start then to identify that can change the test, your test and your design. That can change then what you've. product functionality and non -functional requirements need to be. It's always about making sure that them later stages, what traditionally were later, are thought about upfront at the start, designed, planned in, and continuous efforts all the way along the software development lifecycle to embed them. So it becomes an easier stream from end to end and more automated and more, I guess, more constant flow through the system. So yeah, shift left is think about the end at the start as much as you can. Brian (07:37)I love that. Think about the end of the start. Yeah, that's a great way to phrase it. I love that. So when you we've talked about kind of the mindset behind this, the culture behind it. So when you when you come in and work with a new group, do you start with kind of a more culture approach and work on mindset first or you kind of go right into practices and let it kind of flow along the way? How do you approach that kind of shift when you start to work with a new New team. Claire Clark (08:07)Yeah, it's interesting because it's the balance because when you're introducing any of these practices, it means typically it would mean there's some form of change for a team and change itself is difficult for people to go through at times. And in terms of embedding some of the success of the frameworks and the processes, you can only really succeed if people are coming at that with the right mindset. because otherwise you can get people who say, I don't want to change. I don't understand why I need to change. So you can explain the kind of value in why to do some of these things. But fundamentally, what underpins that in all of this is a mindset. And in Agile, I've talked before on some presentations about how important an Agile mindset is. So being able to sort of... accept that, you know, change will happen, you know, change is the only constant that happens and the more that people can start to understand, I guess, appreciate that and then come up a new thing, a new challenge, start coming at that with how can I make that work and it's then subtleties that if you don't challenge the two together, Brian (09:11)Right. Claire Clark (09:34)you won't succeed in getting the benefits from Agile and DevOps. You could have the best processes in the world, but if the mindset's not there, you're never going to reap the benefits of what you're trying to achieve. So I try to work with teams on both fronts at the same time, because like I say, you can have the right mindset, but they might not understand the process or the right process. If the mindset's not there, the implementation won't come to fruition. Brian (10:02)Yeah, we actually just had another episode that was, I think it was our last episode actually, looking at the order of this. But when we were talking, we were talking with Ken Ricard about the overlap between change groups and the lean change overlapping with Agile and how really that ability to shift and adjust and change is really at the central core of it. What other kind of key cultural shifts do you feel like are necessary when a group starts to adopt DevOps practices that they really need to get a handle on? Claire Clark (10:43)Yeah, I found that some teams really struggle with the concept of the shift left side of it. So it tends to be, we've always done it this way. And because it's become second nature to do certain aspects, you know, certain aspects of the software delivery and development in a certain manner, that trying to open up people's minds to say there is another way and it's different. Brian (10:52)Yeah. Claire Clark (11:13)And it will feel different, but you've got to be open to trying that. And here's why. So I think the cultural side of it is I still see at times some teams that are really focused on DevOps tooling. And it's, I think the mind set shift, the cultural shift is it's not, that's a part of it. Part of DevOps is the tooling you have to do that. And same as when people struggled on the agile journey initially is, you know, thinking agile was, you know, user stories and Jira and yeah, Jira and things like that. And that's, that's a tool that facilitates you to work in that way. But having a tool like that, a Camman board it or so on, doesn't make you agile. And it is that. Brian (11:50)Sure. Right. Right. Claire Clark (12:08)It's that same thing with DevOps. There's some brilliant tools out there now and we are getting that shift left approach and using them tools to integrate at different stages of the software development more of the operational aspects and getting that continuous integration. But I think with Agile, people, a lot of teams have gone over time now and through the great work like what Mike does, helping people understand how to. to really come on board and get the best out of an agile way of working. It feels like with DevOps, we're in a similar spot where some people have really got it. They get that mindset, they live and breathe the kind of DevOps side of it. But there are still a lot of teams that you come across and DevOps is still a tool. It's still a thing. And maybe they get that tool in place and hey, presto, we're DevOps. And it's like... Some of the subtleties that you don't see, it's not in a process, it's not in a tool. That behavior and that mindset is what I think there's still a bit more of a journey to go on across the industry with that DevOps side of it. It just feels so similar to when Agile sort of come out and the challenges people were facing there and what we believed Agile is and what Agile really is. Brian (13:29)Yeah, that's a great analogy. I love thinking about it that way. I mean, it's like if you have a boat that's in a garage, you can get in the boat, you can turn it on, you've got a fantastic tool, but if you don't ever put it in the water, it's not going to really live up to its purpose. And that's kind of the way people, I think, sometimes look at some of these tools is, well, we got the tool, so we're sailors now, right? We can... We know how to drive our boat because we have a boat. No, you got to put it in the water, right? You got to actually know where to use it. Claire Clark (14:01)Yeah. Yeah. Yeah. One example I always think of is it's a bit like having a scenario where there's a driver and there's a really fancy, you know, car, but it's got no engine. So you can have all of these elements and you could say, I'm a racing car driver, I've got this really fancy car. Brian (14:18)Mmm. Claire Clark (14:25)It looks great and you know, it's got all the features on it and all of the buttons you can press, but, but underneath the core of that is the engine. And I liken it to like with Agile and DevOps, the core underneath this is the mindset. And it's that, it's that hearts and minds of the principles behind DevOps principles behind Agile that if people buy into that, the rest is a bit easier to implement. But often people can have tooling shoved at them or a nice fancy car in that scenario. But it doesn…

    Full show notes at the publisher

    Previous 1 6 7 8 9 10 19 Next

    Related Podcasts

    Reply All

    1

    Reply All Games & Hobbies
    Inside VR & AR

    2

    Inside VR & AR Gadgets
    Note to Self

    3

    Note to Self News
    BrainStuff

    4

    BrainStuff Natural Sciences
    This Week in Tech (Audio)

    5

    This Week in Tech (Audio) News
    Hands-On Tech (Audio)

    6

    Hands-On Tech (Audio) Technology
    footer-logo

    Contact Us

    Toll Free: 844-670-7747

    Links

    • Home
    • Top Charts
    • Networks
    • Apps
    • Independents Podcasts
    • Podcast Advertising
    • Podcast News
    • Contact Us
    • About Us
    • Analytics & Insights

    Stay Connected

      Privacy, Terms of Use & Our Code of Ethics Protecting Content Creators Copyrights