Agile Mentors Podcast

Missed some episodes this year? Don’t worry—Brian’s got you covered with a highlight reel of 2024’s most memorable moments, featuring game-changing insights from Agile thought leaders and innovators. Tune in to catch up, reflect, and set your sights on a stellar 2025!

Overview

In this special year-end episode of the Agile Mentors Podcast, Brian takes us on a trip down memory lane, sharing highlights from some of the most impactful conversations of the year.

Featuring insights from Agile legends like Mike Cohn, Clinton Keith, Heather McGowan, and more, this curated selection is packed with golden nuggets that you can revisit or discover for the first time.

Whether you missed an episode or want to relive the best moments, this recap is a perfect way to close out 2024 and prepare for what’s ahead.

References and resources mentioned in the show:

#79 Navigating Agile Trends and Challenges in 2024 with Lance Dacy
#86 Revisiting User Stories with Mike Cohn
#90 Mastering Agile Coaching with Cherie Silas
#93 The Rise of Human Skills and Agile Acumen with Evan Leybourn
#100 Navigating the Future of Agile and Scrum with Lance Dacy & Scott Dunn
#111 Adapting to the Future of Work with Heather McGowan
#120 Agile in Gaming with Clinton Keith
#123 Unlocking Team Intelligence with Linda Rising
Subscribe 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 [email protected]

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.

Auto-generated Transcript:

Brian Milner (00:00.622)
I'm Brian Milner and this is the Agile Mentors Podcast, a show about both the personal and organizational journey towards agility. My friends and I will be sharing with you what we've collectively learned from seeing thousands of companies Agile implementations, apparels and pitfalls, as well as the secrets to success. We'll share our personal in the trenches experiences so that you can apply what we've learned in a practical way in your careers. We also hope to hear and learn from you as well. If you're like us and are always in search of better ways of working together, you're in the right place. Join us, mentor, and be mentored. Let's get started.

Brian Milner (00:53.288)
Welcome in Agile Mentors. We are back for the final episode of 2024. Believe it or not, we have reached all the way to the end. You might be thinking, wait, there's a few more weeks left. Yeah, there's a few more weeks left, but the next release date would have been on Christmas Day itself and the one following would have been on New Year's Day. So we're gonna take two weeks off to be with our families after this episode. And we encourage you to enjoy that time, take the time with your family as well and friends, and truly wish you the best over that time period. But before we get there, we do have one more episode for you. We thought what we'd do for today's episode might be tiny bit different than normal. In fact, I don't think we've done anything like this before. What I wanted to do is, since it is the last episode of the year, is to look back over the past year and play you some portions of some of the really fantastic discussions that we had over this past year. Just pull out a handful of these to talk to you about. If they sound interesting to you, maybe you can go back and take a listen to those episodes. So let's get right into it, because I don't want to waste time setting it up any more than that. For starters, I want to go back to something that's now kind of a tradition for us, and the next one you'll hear from us after this episode will be the continuation of that. The beginning of this year in 2024, we started things off and we kicked it off with friend of the show, Lance Dacey. And that episode was really about looking forward into 2024. And for us to talk about what we maybe thought was coming and what we saw in the future, and then trying to somehow make some predictions or give some advice about how we might be better prepared for it. And one of the areas that came out in that discussion was really talking about how leadership affected an Agile transformation and Agile with the culture of an organization. So I'll play you a little clip here from Lance's discussion. One of the thoughts that he had in that episode, really talking more about how we need to go to the next level with our organizations and with the leadership in our organization. Take a listen. We've been trying to scale Scrum and Agile for a long time and we've written the practices on how to do it.

Brian Milner (03:13.23)
but we're not allowing the people to practice that. You know, just got through coaching. My youngest son is in fifth grade and we coach his football team. It's like, we're going to sit down and tell you during this play, here's the stance that you take to block. You're basically a robot. Do everything that we say, even if you don't understand it, because the whole scheme for that play is built on everybody doing their job exactly as prescribed. But as you evolve into professional football or high school football, they've learned so much about those mechanics. that's really fun now because they've got the IQ to respond to what's in front of them. That's agile. And that to me is what we have to start learning in organizations, is we know how to run the play at the team level, but how do we build up the people to run the play correctly in challenges when there's adaptations that need to be made? And a lot of times management and leadership is the suffocating part of that where they don't allow for that. It's always interesting to go back and look at those conversations that we have at beginning of the year. and see kind of how it played out. Were we right? Were we wrong? So if you're interested in that, check out that. That was just episode 79 was the first one that we did in 2024. Next up, I'm gonna jump to episode 86. This was one with our very own Mike Cohn. Mike had come back on because quite frankly, we've had for many years a set of user stories that were sample user stories that you could come to our website and download just as a resource for people if they wanted to see what... samples of user stories look like, try to imagine what that would look like in their particular context. So that's why we had this collection of user stories. Well, Mike went back to re-edit those recently, and then he took kind of another look at it and had forced him to kind of reconsider some things, wanted to share some thoughts about those new ideas and thoughts he had about user stories, just in re-examining ones that he had put together previously. So in this next clip, what you'll hear Mike talk about is really kind of a controversy maybe just his own controversy internally, but kind of a shift that he had over the years and really the template itself for a user story. So take a listen to this. I had a bunch of slides. I looked at them a few years ago to confirm this. I looked at them and they all said, I want to blank, right? And it was what the user wants. And sometimes it's not what the user wants. So if you look at slide decks that I create today, they all say, I.

Brian Milner (05:36.866)
They don't say I can, they don't say I want to, they just say I, and then you fill in the verb. For example, as user, I am required to enter a strong password. I don't want to enter a strong password. I want to type in my dog's name and let the system know it's me, right? So I am required to enter a strong password that doesn't fit with I want to or I can. I can enter a strong password? Well, that doesn't really help. I don't want to. I can enter a strong password. I can enter a weak password. Is that possible? So I do think there's problems with I can, but I leave all of that out of the template and I let the situation determine what that verb should be. Always an interesting conversation there with Mike Cohn. Very, very lucky and fortunate to have him come on usually multiple times per year. And that was just one of the times that Mike came on our show this last year, but really, really interesting stuff there about user stories. If that's something you're interested in, I encourage you to check out that. That was episode 86 with Mike Cohn on user stories. Now we're gonna jump ahead to episode 90. Episode 90, we had a friend of mine, Sheree Silas, come on. Sheree is a very authoritative, knowledgeable person on Agile coaching. In fact, she is the person that I most likely am going to point you to if you come to me and want to find out more about Agile coaching. She has some really great classes and other things that she teaches. And we had her on to talk about Agile coaching, obviously. And one of the things that came up is something that I hear sometimes in classes that Some of this coaching stuff you talk about sounds a little bit like counseling a little bit. Is there a crossover there with counseling? Is this a counseling job? So take a listen to what Shree had to say in response to that question. As an adult coach, you are not an organizational psychologist. You are not a counselor. You are not an organizational therapist or any of those things. That is not the job. The job is consulting, mentoring, training. and some coaching, helping people how to learn how to negotiate, learn how to collaborate, learn how to have good, healthy conflict. And there's helping them to get the business results they want. And it's very frustrating when you kind of hear this taking all the way to the other end of, we're just there to do woo-woo touchy feely stuff. I'm the psychologist. No, that's not your job. And you're not trained to do that. And that's part of the coaching work.

Brian Milner (08:03.136)
is to help them understand what they need and what they don't. And even as a professional coach, it is my job to make sure my client understands what coaching is and what it's not. And as an Agile coach, that's part of the work is to make sure the client understands what this work is and what it's not. Yeah, really good stuff there about Agile coaching. If you're interested in finding out more about that, listen to that episode. You'll hear more from Sheree on episode 90 about Agile coaching. Next up, I have a relatively new friend of mine, but one that, you know, feel like brother from another mother. Mr. Evan Layborn was on and he came on to talk about some research that his organization had done in partnership with the Scrum Alliance. And in particular, there was one component of that that I wanted to question him about because when I initially read it, it gave me a little bit of some misgivings about it. One of the things I mentioned was that traditionally we have always talked about being a T-shaped individual on a Scrum team that had a depth of experience in one area. but a breadth of experience in other areas that you just weren't an expert in. You were only really looking to be an expert in one area. But this report kind of brought to bear this idea of what they're calling a pie-shaped individual. So think about the mathematical symbol pie and how it has two lines going down. It's kind of like a T with two lines going down from it, right? And when I saw that, initially my first thought was, well, is this just organizations trying to get by with less head count? Take a listen to what Evan had to say about that. I want to be clear that when we're talking about pie-shaped individuals and companies looking for pi-shaped individuals, we're not talking about companies who are looking for one person to do two jobs. They're not looking for someone who's got two skills because they're trying to fill two roles. They're trying to fill two jobs. We're talking about one person, one job, and using multiple skill sets to do that job better. more effectively. In the technology world, we've had a word for this in the tech world for 10 years, full stack developer. A full stack developer is a pie-shaping, it's a developer with test competence and operations competence. They can deploy a DevOps environment. That full stack developer is a prime example of a pie-shaped person. It's not one person doing two jobs. It's one person doing one job with a variety of skill sets.

Brian Milner (10:30.752)
and doing that job better, exponentially better because of it. There's some really interesting other insights that Evan had in that episode. highly recommend that to you. That was episode 93 with Mr. Evan Layborne. Next up, well, we celebrated a milestone. We had our hundredth episode, if you can believe it or not. And we thought it would be appropriate to celebrate by having two people that we have on quite frequently on the podcast, Mr. Lance Dacey. and Mr. Scott Dunn. So we had something that we don't often have here on the show where we had multiple guests, but we had Lance and Scott on to really look back over the past 100 episodes and look ahead a little bit into what we thought might be coming. And one of the interesting kind of conversations we had there was thinking about some of the changes taking place in the workplace today. You'll hear Scott kind of start in on this with. thinking about the kind of dilemma organizations are facing with the work from home versus work from office kind of situation. And then Lance will come in and kind of relate it more to some larger agility issues as well. Take a listen. Thinking back to the time when people didn't really want to go agile because they thought it was a fad. And it didn't take but a few years, like, I could be wrong. Maybe that is a thing we need to do, right? And then everyone gets on board. But there was a lot of kicking and screaming and doubting the early years. I think we're going to see that with remote work is made like the proving ground of do you really work this way or not as a manager? you get this or not? You cannot lead and manage people currently how you are going to in the future because they were talking about how the new generation. is coming on board and they just won't tolerate certain things. And I think you hit it on the head with that Scott, that if these managers don't learn how to lead and manage with this newer generation, two or three removed from what I'm talking about, you're not going to have any employees because they will not tolerate it. They do not work that way. It was always such fun to have both those people on our podcast and it was even more fun to have them both on at the same time. So I really appreciate both Lance and Scott really helping us celebrate there. The fact that we crossed that threshold into a

Brian Milner (12:38.326)
our 100th episode. Next up is someone that I found really fascinating. is Miss Heather McGowan. And she was the keynote speaker at the Scrum Gathering this year in New Orleans. And she was so gracious to come on the podcast and talk with us a little bit. She had some really great insights. Just listen to what she had to say here in thinking about sort of the place of work in general as a part of our lives today. 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 this 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. It's a little bit in terms of how we're interacting with each other that's causing illness, 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. I heard from a couple of people after this episode, just friends of mine talking about it. I want to make sure I'm clear about something here that Heather was saying, she's not saying that we should find our values from those places. She's just saying that's kind of how society has shifted a little bit. So you can debate whether it's good or bad, whether the other circles that she mentioned had shrunk or grown or anything like that. But really that's kind of the reality we're left with is that there's a lot of people who find their belongingness from work today, as I said, whether that's a good or bad thing, you can debate. but that's certainly a reality I think we have to live with. And this was a really interesting discussion. So I highly encourage you to check that out if you want to. That was episode number 111 with Heather McGowan. Next up was someone I found really interesting as well. This was Mr. Clinton Keith. Clinton is a veteran of the gaming industry. And I know there's always some interest in that in our listeners and in the Agile community about how you really can apply some of these Agile principles and things.

Brian Milner (14:55.704)
to an industry that's so fast moving like the gaming industry. Well, as I said, Clint has worked in that industry for a very long time and he's seen pretty much everything there. He's worked in all different kinds of gaming companies. He's helped them to learn and apply these agile principles along the way. So I'll just share a snippet of the conversation that we had. In this clip, he's talking really about how some of these principles we talk about like, individuals and interactions over processes and tools and are we letting something like a new technology drive how we do things or is it really more about what's the value we're trying to deliver, right? And in the gaming industry, it's fun. It's delivering something that's fun. So take a listen to what he had to say about kind of one of these experiences he had about really finding the fun. The big light bulb moment was having a short deadline on showing something of value. led to people making better choices from the player's perspective, not this challenge of, what can I do with artificial intelligence over the next two years? That's part of the big challenge with these big, huge games of saying, it's like, hey, if there's not a payoff, if you can't see value, and this was an early lesson I learned working with Nintendo of Japan, the guy that made Mario and Donkey Kong, we worked with him directly, Miyamoto. You always had this thing, it's like, the fun fast, show the value of it. And it always stuck with me. When you have these short deadlines, you want to encourage the teams and the product owners is judge the game. Not what you see in the potential in two years. Judge your vision of the two years against what you're seeing every other week and adjust your expectations. Don't fall in love with your vision. Judge the game. Don't fall in love with your vision. Such great advice there, and I think it's so applicable to really industry. Don't get caught up in that word game, right? Judge the product. Think about it that way. I think sometimes, especially for us as product owners, sometimes we can look at that and say, we've got these grand visions and grand designs for our product, in two years we're gonna have this incredible product that's gonna do all these things. Well, you may not make it to two years. You may not make it to two years if you don't.

Brian Milner (17:16.897)
deliver a value earlier, right? If you don't capture the imagination and attention of your customers, if you don't solve a problem for them upfront, we know the big idea is gonna take longer to get to, but I think what Clinton is saying here, and it's really an important point, I think, is that that's part of what we kind of focus on as Agilist is trying to find the value and deliver it early. So just a really fascinating episode there as well with Clinton. Encourage you to check that out, especially if you have interest in the gaming industry, lots of good content there from him in episode 120. Lastly today, I'm gonna leave you with one last one that wasn't too long ago here, but we had someone that is kind of a beloved figure in the Agile community. She's often referred to as an Agile visionary. That's Ms. Linda Rising. And she came on to talk about multiple things with us, but one of the things that she talked about in our conversation, was about a research project that Google did several years back called Project Aristotle. They were trying to figure out kind of the components, what went into making a high-performing team. So just listen to what Linda has to say about what their scientific research kind of uncovered about really what goes into making a team high-performing. All these different researchers made the same mistake in the beginning. and it's the same mistake organizations make. They thought in the beginning that what makes a smart team is smart people. Wrong. Not that you don't want smart people. You can have a team of very smart people that doesn't have any of these other characteristics that is not intelligent as a group. We really have to wake up and realize, first of all, that we're doing that, that we're valuing IQ or individual intelligence, smartness, you went to this school or you got that particular SAT score. It has nothing to do with that. It's not that there's no correlation, but it's weak. It's much better to have people who have these other characteristics. I just have to say

Brian Milner (19:38.444)
We are so spoiled Agile mentors with some of the great people like Linda Rising that we get to hear on this podcast and learn from really as sort of a masterclass from some of the best thinkers in this industry. And I know I'm very thankful for them taking their time and thankful for people like Linda Rising coming on the show. If that dialogue that you just heard there sounds interesting, check out that episode. It was episode 123. Linda talks about a lot of lot more great stuff there in that episode. But yeah, we get so many great guests on our show and that was just a handful. It's hard to even pick out just, I think we just had eight of them there. It's hard to pick out just eight over the past year, because there were just so many. And any of the other guests on here, I hope you don't feel like you were not in the top eight or anything. This was just a sampling. I just wanted to pull some different kinds of episodes and I think there was quite a variety of guests and topics and things that we had on the show this year. It just makes me excited about thinking about what's possible in the next year. I know we're gonna be trying some new things. I've been interacting with some of you at the Agile Mentors Community and you've been talking to me about some suggestions about things that maybe we can do. And we're gonna try that. We're gonna try some new things going into the new year. So you may see some shifts from time to time of just a few experiments that we might be trying. As always, we'd love to hear your feedback on any of those things, but we're always in search of making this the most valuable use of your time. We think that the quality of the people, like you just heard, is pretty good. We're pretty happy with the people that really decide to come on the show, and we're very humbled by the fact that they choose to come on our show. I just wanna always make it the most valuable use of your time. We want this to be the most valuable Agile podcast that's out there. As always, if there's anything we can do to change that, I'll go ahead and just say that now. email us podcast at mountegoatsoftware.com. Put that at the end of every episode. Truly mean it. If there's things that you want us to experiment with or try, if there's guests you want to hear, in addition to some of these great guests you heard today, there's other people that maybe that you think would be good on the podcast, send us an email, podcast at mountegoatsoftware.com. Or if there's a topic that you want us to cover, let us know that as well. We'd be more than happy to try and put that in. In our planning,

Brian Milner (22:01.666)
we try to always put the listener's suggestion kind of towards the top of our backlog. It may not be the very next thing we do, but we try to make that as soon as possible. Oftentimes we have to find the right guest, but as soon as we find the right guest, we want to get that listener suggestion on as soon as possible. So thank you for those that have made suggestions in the past and keep them coming. I'll just go into a few other things then and wrap up and get you on your way. It's been fun looking back over the last year. And as I said, I'm excited about seeing where we go next year. Speaking of that, just make sure that you like and subscribe to the podcast. That way you don't miss any of these things, like any of these great episodes that you heard little snippets of here in this podcast episode. And with that, I guess that'll be a wrap for another year. So Agile Mentors, my heartfelt happy holidays to you. Whatever you celebrate this season, I truly, truly hope that you get to spend some time with your family, your friends, your loved ones. truly hope that you get some time to reflect on what you're grateful and thankful for. I hope you come back next year refreshed, ready to go. I hope that's part of your sustainable pace, that time of renewing with the people in your life that are closest to you. We look forward to seeing what happens with you in the new year. So join us back next year. We'll kick things off. We'll be back here in just a few weeks. And on the 8th of January will be our next episode that we release. And we'll have our... of annual sit down with Lance Dacey to look ahead to 2025 and see what's coming up then. So join us and hope you have a very, very happy holidays. See you next time on another episode of the Agile Mentors Podcast.

How do you navigate a bumpy job market with an agile mindset? Join Brian and leadership coach Mark Kilby as they explore practical strategies for staying prepared, leveraging your network, and taking ownership of your career during uncertain times.

Overview

In this episode of the Agile Mentors podcast, Brian Milner and Mark Kilby explore how to approach the challenges of today’s unpredictable job market with an agile mindset. Drawing on insights from Mark’s extensive career as a leadership and career coach, they discuss how preparation, adaptability, and proactive networking are essential to staying ahead.

Mark emphasizes the importance of treating your career like a product, continuously iterating and inspecting trends to navigate change effectively. The conversation also delves into the power of maintaining strong professional relationships, keeping your resume and LinkedIn profile up to date, and using experimentation to explore new career paths.

Whether you're facing a career transition, considering your next step, or simply looking to stay prepared, this episode offers actionable advice to help you take ownership of your professional journey.

References and resources mentioned in the show:

Mark Kilby
From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver by Johanna Rothman & Mark Kilby
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe 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 [email protected]

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.

Mark Kilby is a leadership and career coach specializing in helping leaders and teams thrive in complexity. Passionate about building more inclusive and effective organizations, he draws on years of experience guiding professionals through organizational change, remote work transitions, and sustainable growth, all with a focus on fostering trust, collaboration, and long-term success.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back and this is another episode of the Agile Mentors podcast. I'm with you as always Brian Milner and today I've got a friend that I have seen talk several times at conferences, we were talking, I don't think I've actually crossed paths with him personally yet, but Mr. Mark Kilby is here. Welcome in Mark.

Mark Kilby (00:21)
Thank you, Brian, and glad that we finally had a chance to meet virtually face to face at least.

Brian (00:26)
Right? Right? Yeah. And today's world, you know, that's actually saying a lot. You know, that's kind of the default. Mark is a leadership and career coach and has been, you know, a speaker at multiple Agile conferences over the years. He has a book that he co-authored called From Chaos to Successful Distributed Agile Teams. And he has spoken on lots of different topics.

Mark Kilby (00:31)
Yes it is.

Brian (00:51)
But when we talked about having him on, we talked about a topic that I know is very topical here. For some of you, maybe, know, kind of right in the meat of where you are at the moment, but really starting to think about this bumpy job market a little bit and how to navigate that with an agile mindset. You know, this agile stuff is not just stuff we talk about in working with a team, but it actually is a way of thinking about you know, doing anything. give me kind of your description there, Mark. When you think about, you know, navigating a bumpy job market with an agile mindset, how does that look different from others?

Mark Kilby (01:27)
So, well, it. The best way to think about this is whether you get this out of college at career placement or you're working with a career coach later on, it's always plan out your route and just follow the steps. Well, it's kind of hard over the last couple of years to say what the right steps are because so much has happened. And you and I were talking just before we hit the record button about one of the things that gets a little bumpy here in Florida, and we call those hurricanes. And I've learned over the many years living in Florida that you can prepare for hurricanes, but you can't prepare for exactly what happens. And so it's kind of the same way these days with our careers. You can maybe get certain certifications, you may get the right resume, the right LinkedIn profile, but if... If you're not paying attention to how the market shifts, and I think many people have been caught off guard with the latest market shifts, you can be in a world of hurt. how do do the prep to weather that storm? So that's kind what I'm focusing on these days.

Brian (02:42)
That's awesome. That's awesome way to look at it. Cause I think you're right. know, like I know I personally have gone through a couple of, you know, layoff periods in my career and, you know, it's never something when it hits, well, at least I shouldn't say this in my experience, I absolutely were completely prepared for, they were a little bit of a shock when they happened and

Mark Kilby (02:51)
yeah.

Brian (03:05)
first one much more so than the second one. I think you learn something from each time something like that happens. But you mentioned kind of the way the market is shifting and the way things are changing a little bit and trying to be prepared. So I wanna follow that for a little. So when you talk about navigating kind of a bumpy job market and the shifts and being prepared, how do you prepare for the unknown? For things that you don't really know what's coming or you don't really know how things are shifting. How do we do that?

Mark Kilby (03:38)
Yeah. Well, it's paying attention to some of the longer term trends. mean, 100 years ago, know, kind of fall into the hurricane example. We had no way to predict these. And now we've got a little better way. have models to kind of guess and it's still guessing. So, but at least we have a sense of, OK, how big is it going to be? You know, how big is the change that's going to happen? How do we prepare for it? Do we stay in place? Where we're at? Is it time to move and do something else? So it's kind of the same way with our careers these days. I'm gonna guess, not everyone's gonna have the visual, but with the amount of gray on the podcast right now, you could probably relate to this. Our parents probably stuck in the same job. most of their life. I learned early on, especially in tech, the changes that happen rapidly. Matter of fact, the place where I went as a summer intern shut down the next year. The whole plant went poof. But my parents were like, how can you? It's such a great place. This company's been around for decades. But I could tell that the winds were changing. Something was shifting there. So I learned to look at, right, how is the business doing? How is the market doing for the business? And what does that mean for me? So it really helps that we kind of build up our own little model to predict, you know, how is my job going to be here in the next year or so? Even five years ago, I saw early indicators that Azure coaches, scrum masters, we're going to be at risk. But the job market was going to turn. think several people could tell that. But I mean, we had so many that were going into that, that the set of roles and we were also, you we we were seeing some failures as well as successes with transformation. And I remember, so I actually had Ken Schwaber in my, as my my Scrum instructor, I remember him saying, know, Scrum will not solve your problems. It'll make them highly visible. But guess who gets blamed? The person who made it visible. you know, as, as agile coaches and Scrum masters, you know, were the, those folks in particular are always navigating a tightrope. You know, what, what do you, you know, what do you make visible, both the good and the bad? And if, if you're dealing,

Brian (05:55)
Yeah. Right.

Mark Kilby (06:17)
with cultures that are more focused on short-term kind of improvements and not looking at the longer term. How are people staying engaged? How are the steam aligned so they can do to deliver business value? You know, if that's not a focus of the organization, then it's that job, that role is going to be probably misunderstood and was. And so when things start going bad, fingers start getting pointed. It's like, okay, maybe we don't need these folks. And we've seen that for the last couple of years in particular, but we were getting early indicators well before that, well before the pandemic hit. So that shift was gonna happen. So we can model some of this is my point.

Brian (07:01)
Yeah. I like that. Go ahead. Well, I was going to go straight to that. I I like the comparison there with the hurricane. And I was thinking as you were talking about that, why are we better at it now? I would kind of presuppose it's because of the amount of data. But the more data we have, over the years, the better we are. And that if we've suddenly, magically, for whatever reason, lost all our historical data of hurricanes and what they do, then I would imagine we'd be back to square one of not really being able to predict very well about where they go. So translating that over into our careers, I love that comparison. And I love what you're pointing to to say, you can see indicators, can look at the trends, you can see how's the business doing. So that's kind of one of the things I want to ask you about a little bit is, especially here in this agile world, I know there's, I've heard lots of talk about, is this overall an agile thing that is on a decline or is this really more driven as an economy at large that's going through problems. And so we're kind of trickling down from that and feeling that. if I'm an employee for a company, what I'm trying to navigate then and figure out is I want to see trends for our business on the whole, but I also am trying to...

Mark Kilby (08:38)
Mm-hmm.

Brian (08:40)
fit that in with what the overall economy is and the market out there to see, is this just an overall thing for all of businesses right now and for the full economy or is this specifically something to do with our business that is kind of a, I would think a bigger warning sign than to start to get more prepared.

Mark Kilby (08:59)
Well, going back to the hurricane metaphor again, there's multiple things that impact that. It's the same thing for our jobs. So it's what data do you need to gather? And you pointed out to some of that. So what's happening with the company? What are you seeing in press releases? What are you seeing in commentary on your organization? I'll give an example of a company that no longer exists. So can safely speak about this company. So a company I was at early in my career and was well known in the Java programming space. They actually hosted a lot of Java sites at the time. They were also at the top of the, not the AI boom, but what was called the internet boom, know, dot com boom way back. And they went through the same Friends that a lot of companies did spending a lot of money Not pulling not pulling in revenue and it was very public how much they were spending When it became obvious that they bought like very expensive real estate office real estate in in Boston Harbor area and they bought very expensive real estate elsewhere You don't have to be a financial wizard to figure out like all right if they're spending all this money and and we're seeing pundits in other news sources say, yeah, we're not sure about this company. And you're seeing a lot of that. You might start to wonder as an employee, like, I wonder if I am really safe here. Is it time to hunker down or is it time to move? So you've got to gather your own data about your company, your industry, and even the broader economy. If you ignore that, you kind of ignore it at your own peril. We have to be the product owners of our own career.

Brian (10:47)
Mm, I love that. Yeah, that's a great way to look at it. Well, so shifting gears a little bit, because I think we obviously are not going to, we're soothsayers or anything. We can't foretell the future exactly. And there's always going to be things that kind of catch us off guard. There's the unknowns and that's

Mark Kilby (10:48)
Yeah. Yeah.

Brian (11:10)
Partly what we talk about a lot in Agile is just the idea that you can't know everything upfront. So you got to be prepared. You got to have a system that works for you that kind of allows for those unknowns to come along and then allows you to adjust as you're going through. So that's kind of where I want to go next then is if we accept the fact that, we have indicators and they can give us an indication about the job market or about our company. And we have to kind of assess those independently to see if it's time to move or we should be ready for something to happen or not. Once that threshold is crossed, once we make that decision, or it's made for us, then we're into a whole other world. And we talk about this being a bumpy job market. Well, it's bumpy on both sides of that threshold. So how would that apply to you? After you've crossed that threshold, how do we use Agile and an Agile mindset to navigate the task and the hardships of trying to find the next thing?

Mark Kilby (12:16)
Well, there's even a little bit before that. So that's OK, but a great question. And I'll come back around to it. So just as you're starting any agile project or program, there's some setup. There's some prep that you have to put in place. And I'm going to tie back to the hurricane metaphor here also. There are seasons for that prep sometimes. So think about the season you're in.

Brian (12:18)
Okay, sorry.

Mark Kilby (12:41)
month to month, quarter to quarter, and maybe you're wrapping up a big program, that would be a great time to update your resume and your LinkedIn. Not waiting until you're out of a job, but go ahead and just like, you know, I think I'm going to update. And people will say, but I don't want other people to know that I've updated my LinkedIn profile. There's an option for that. You can shut that off so that doesn't happen. But you want to get in that, that there's prep seasons like, okay, if something were to happen, what do I need to do? What do I, what, what I need to have ready? So keeping that resume up to date, keeping that LinkedIn profile up to date, then looking at, okay, I I've kind of doing these, these cycles of, of prep and also reflection on past work. Maybe I want to think about what was the work I enjoyed that I want to amplify through. LinkedIn, resume, and maybe even talk about a LinkedIn and kind of be broadcasting a little bit. I really enjoyed this project we just finished up. That gets you a little bit out there. And I can already hear the introverts cringing. But if you talk about the ideas, what you learned as an introvert, that works for me.

Brian (13:47)
Hahaha.

Mark Kilby (13:56)
I mean, that's how I got into remote work because I found interesting ideas and concepts to talk about. And that's how I got known by that. I looking to make a job switch? No. But I was broadcasting, hey, this is the kind of stuff I really enjoy doing, hoping to attract others who are also interested in that. And yes, it did lead to new job opportunities. So I got hired in 2014 because of the stuff I posted in LinkedIn around those times. So it's kind of doing that inspect and adapt, inspecting, where am I currently as I wrap up a big significant chunk of work? How do I capture some of that? What do I want to reflect? And what do I want to kind of make transparent about what I liked about that? Then let's say the winds turn and things get a little bumpy. Well, if you've... If you've been kind of connecting people, connecting with people online, if you've been kind of talking about, this is kind of things I do, it's much easier to go out there and say, hey, I'm looking for a new opportunity. You've seen what I've talked about online. What ideas, what do you have network? What do you have community? So it makes it much easier if you do some of that prep work and kind of reflect and inspect into that.

Brian (15:20)
Yeah, I'm getting a connection there too. I don't know if this is intentional or not, but I'm getting kind of a connection because I know in the agile world, we're all about how teams work together and just kind of that whole mindset of the best architectures, designs, right? The best stuff comes from a group of people working alongside each other. And I'm connecting that a little bit to what you just said, because you're talking a lot about how you're reaching out to the community through your LinkedIn profile and through post and other things. And that feels a little like you're kind of teaming, like you're teaming up with the network that you've made to try to solve this big problem that you have.

Mark Kilby (16:05)
And from a career standpoint, we team in different ways. mean, how many of us have been to courses, conferences, we've met people that we've kind of connected with, or we've talked about some great ideas, like, yeah, let's stay connected, let's talk more about that. How often do you follow up with those people? Do you like forget until the next conference? Do you maybe check in every six months? Maybe a little sooner? Maybe say, hey, what kind of projects are you working on based on that idea we talked about? Reach out to those connections that you made. of just not to keep them warm, but just to say, hey, what are you working on? How does it compare to what I'm working on? Let's just talk about that. Let's do some more reflection on that.

Brian (16:49)
I think that's great advice because I hear what you were saying earlier and agree. It's kind of a struggle when you're working at a company and you're not really sure yet whether you're moving on or you're not and no one has told you anything. But you're starting to feel the signs and you're starting to look around and say, maybe it's time, but it's not right for me to just blast it. It's not right for me to go to LinkedIn and...

Mark Kilby (17:02)
Mm hmm. Yeah.

Brian (17:15)
Because you don't want the boss or coworker to see that and say, what's going on? You don't want that to happen. But I think you're right. There's more subtle ways you can do that by just starting to connect to key people in your network. And I like that phrase. I like being able to say, hey, what's going on in this area? Or what have you done in this area that we talked about when we last connected? I think that's a great approach to that.

Mark Kilby (17:40)
because it's so much easier to ask for help when you need it then, rather than if you haven't talked to that person in five years since you saw them in a conference. But if you stayed in touch and just talked about, hey, here's some things I'm dealing with at work, how about you? What are you coming across? What are you learning? What are you trying? Or what are you struggling with? And if they know you're struggling, then they might say, hey, you know, I heard of this opportunity. And that's where the network helps you. That's where the team helps you out.

Brian (18:12)
Yeah. They always say that, you know, like that's the, that's your strongest avenue to, to another job is, is, you know, a personal connection and inroad, to the company. Cause you bypass all the, you know, all the silly AI stuff of scanning through resumes and do you have the right keywords and all that stuff? which, know, that's a whole other thing. but, you know, if you do, I think you're right. If you can make that personal connection.

Mark Kilby (18:34)
Mm-hmm.

Brian (18:39)
your resume can go to the top of the pile. You skip the initial vetting, you go to the interview, and once you get the interview, then you're golden from that point forward. Yeah, I love that. That's a great approach and I like the idea of continuing to maintain that network. But I will tell you, from my first layoff to my second layoff and how I kind of approach things was very, very different. And I'm kind of curious how this fits in with what you advise people as well, because I know my first layoff, I got a little snowed by certain people where I started to make strong connections. I started to go through energy process with people and they're in the full recruitment mode at that point, because they don't know if it's going to be you or somebody else. if you get to be... you know, one of the finalists, they're interviewing you, but they're also recruiting you. And I know I made that mistake early in my career of just thinking, well, I'm close. I'm close with these things. So I don't need to worry about continuing to do the day-to-day hard work of reaching out and making new connections and starting the process new. Because I don't want to lead them on. I don't want anybody to think that I'm, you know, interested when I'm so close with this other one over here.

Mark Kilby (19:45)
yeah.

Brian (19:54)
And yeah, I learned pretty quickly that's a mistake. know, those things, there's no promises. And you know, you gotta keep turning that crank every day of sending things out. So how does that fit in a little bit with the strategy?

Mark Kilby (19:58)
Mm-hmm. Yeah. Well. Well. mean, to map it back to Azure concepts, you never prepped just one thing on the backlog. You're looking at what are some things that might pop up in this next sprint or this next phase of work? What is it that we might consider, but we're gonna make the final decision when it's time to make that decision? So you can't be in that stage as you talk about those final conversations and you're still doing the dance with them. It's like. You're confirming is this the right place and they're confirming are you the right one to bring in? That's not the decision point. The decision point is when the offer is made. So you've got to get some other things. You got to keep some other things going in the backlog. Keep it going, keep it going. And I would say even once you've accepted that offer, you might wait a week. because I've had some colleagues where they've gone in, they've gone through those interviews and maybe everything wasn't as advertised in the position. I think some of us have been in that where you go and it's like, this is not the job I signed up for. So keep those other connections warm for a week or two, just in case, just in case.

Brian (21:24)
Yeah, that's great advice. I tell a story sometimes to people in the classes about how there was a job I went to that's interviewed and they were asking me all sorts of agile questions. They wanted me to come in because of my agile expertise. I get in and unfortunately for me, it took a few months before it became clear that they were actually hearing the word agile from their division leader. And the division leader was not using capital A Agile. They were using small a Agile and saying, we just need to be faster. But he would throw out the word Agile. And so they heard Agile and thought, well, we need to know about this Agile thing. And yeah, that was not a good fit. That was not as advertised. I wish I had found that out earlier. But you make the decisions when you cross that threshold. Well, this is good advice. And I'm kind of curious then as well, you know, maybe taking it back a higher step because, you know, maybe I'm not in the place where I'm trying to decide, is it time to leave? But, you know, part of navigating a job market is also navigating a career and trying to understand what's the right next path for me or what's the right next step to get to the next level of where I think I should be in my career. How would you kind of apply an agile mindset to that kind of a process?

Mark Kilby (22:44)
So I will say, since I started with extreme programming, I'll bring in another concept, the spike. How do you set up an experiment where you can explore, is this possible or not? So let's say you're an individual contributor and you're wondering, should I take on a management?

Brian (22:51)
Okay.

Mark Kilby (23:04)
How can you experiment with that? So are you a member of any volunteer organizations? Can you lead an effort and see what that looks like to coordinate people? To actually maybe plan a budget to get some event going? What would that look like for you? What does it look like when not everybody's cooperating? Because when you deal with volunteer teams, it gets way more interesting than it works sometimes. Because you're really trying to appeal to their motivation. You can't fire them if they're a volunteer usually. So if you look for how can I experiment with what's next? And is there some way I can lean into some of the same activities? And then when I go and apply for that management position, say, yeah, I've run some of these things at my church or at this community center, and I've organized this, I've set the budgets for that. So you're already demonstrating some of the possibilities. You're trying to decide, this something that I enjoy, that I will benefit from, that I can lean into that next phase of my career?

Brian (24:12)
Yeah, yeah, I love that. That's really great. Well, this topic is, I think, so topical for a lot of people and, well, just about everyone. Because we're all at some stage of our career, and we're all at some stage of our relationship with the place we're at at the moment. I think we all have to be aware. I think we have to keep our eyes open and ears open. And like you said, try to find those sources of data that can clue me in as to what my situation is and maybe what I need to be prepared for. Is the hurricane coming my way or has it turned?

Mark Kilby (24:44)
Yeah. Yeah. Yep. Yeah.

Brian (24:48)
Before I let you go though, I do want to take just a second here before we wrap things up. Because I mentioned your book earlier, the book From Chaos to Successful Distributed Agile Teams. And I know you've done lots of talks and research on distributed agile teams far before COVID happened. So I guess I'll ask you what What do you think has changed today in the years since COVID, when things now things have started to settle a little bit more? How has the nature of distributed teams shifted in just the past few years?

Mark Kilby (25:25)
Well, I think we're seeing some of those shifts even in the last couple months with the call away from hybrid to fully back in the office. We've seen it with Amazon, we saw it with Dell, we're seeing it with others. So I think we're seeing the companies and the management that was looking at what's next, what's possible, and those that are like, no, we like things the way they work. I assume that we're going to see many existing hybrid setups go away. I see, I think there's very few that are going to survive. There have been some other companies that have gone fully remote, but I think we're going to see a lot more of return fully to the office because it's really hard to live in both spaces at once to be in the office and be remote. It's, it's just too difficult. We probably didn't amplify that enough in the book. That's the one thing that Johanna and I, we've talked many times about updating the book and it's like, no, not yet. It's not quite time. Let's let this phase pass. But I think we're going to see things go back to almost 2018 where there's some companies that are doing well remote. And it's not just startups because there's companies, thousand, 2000 employees that are functioning well, fully remote, but it takes a different mindset.

Brian (26:29)
Yeah.

Mark Kilby (26:49)
around how do you connect, do you keep people engaged, how do you keep them motivated. So all those things that we were all forced to answer during the pandemic, some of these companies have been answering that a little bit more, I would say thoughtfully rather than being forced to answer them.

Brian (27:09)
That's a nice way to look at it. Yeah, I agree with that. Well, mean, so much road has passed our tires from when you guys started that. I mean, you wrote that prior to COVID, right? Yeah. Yeah, talk about a great timing. mean, you guys were really visionary looking ahead there. I'm sure there's no way you could have known there was going to be a massive pandemic, but yeah.

Mark Kilby (27:20)
Yeah, yeah, it came out late 2018. No, no.

Brian (27:32)
It was very timely when that happened to have that knowledge available for folks.

Mark Kilby (27:36)
Yeah, were, well, I want to add, we were never in the mindset that every organization should go remote. That was never ever our intention. But for those who wanted to go remote, that's what that book was for.

Brian (27:44)
Yeah. That's awesome. Yeah. And you know, I know that's not our, not really what we, we focused on the, the podcast here, but I did want to just kind of dip into that a little bit for folks, just in case that is a topic that's of interest to anyone here listening as well. If you're really looking for information in that area, strongly encourage that book for, for you again, from chaos to successful distributed agile teams. And we'll put a link to it in the show notes so people can find it so they can, you know, find your work and. to follow up and any last thoughts here before we close it out?

Mark Kilby (28:26)
Yeah, so I would say whatever you're struggling with, step back from that. I don't care if it's remote work. I don't care if it's a career challenge, but step back and look at what are the patterns that you're seeing and how can you inspect and adapt for those patterns. That's an agile mindset.

Brian (28:47)
I love that. Yeah, it tends to follow that if we put to practice these things we're teaching, you know, and talking about and trying to do in our organizations now and kind of apply that to other areas of our life that, you know, we're going to see similar results. So, I really appreciate you coming on. this has been a great conversation. And, and, as I said, I know, Mark, there's going to be lots of people listening who are just going to eat this up because, you know, if you're in that position, You know, you're looking for any kind of help that you can get. So I hope this is really helpful to folks and I really appreciate you sharing your knowledge in this area.

Mark Kilby (29:22)
Thanks, Brian, for having me on.

Brian (29:25)
Absolutely.

What does it take to be an effective Scrum Master? In this episode, Brian Milner and Gary K. Evans, author of The Effective Scrum Master, explore the nuanced role of Scrum Masters, the importance of people skills, and the shift from efficiency to effectiveness.

Overview

Join Brian Milner as he chats with Agile coach and author Gary K. Evans about the essential qualities of an effective Scrum Master. From fostering self-organizing teams to balancing proactive leadership with people-centered strategies, this conversation unpacks the skills and mindsets needed to thrive in the role.

Whether you’re new to Scrum or a seasoned pro, this episode offers fresh perspectives and practical advice for taking your Agile expertise to the next level.

References and resources mentioned in the show:

Gary K. Evans
The Effective Scrum Master: Advancing Your Craft by Gary K Evans  
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Certified ScrumMaster® Training and Scrum Certification
Advanced Certified ScrumMaster®
Subscribe 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 [email protected]

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.

Gary K. Evans is a seasoned Agile Coach and author of The Effective Scrum Master, with over 30 years of experience transforming Fortune 100 and 500 companies through Lean-Agile practices. Known for his expertise in building high-performing teams and training over 15,000 professionals, Gary brings a unique focus on people-centered solutions to complex organizational challenges.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We are back and it's another episode of the Agile Mentors podcast. We're getting towards the end of the year. I am here with you, as always, Brian Milner. And today I have a very special guest with me, Mr. Gary K. Evans is with us. Welcome in, Gary.

Gary (00:17)
Thank you, Brian. It's great to be here.

Brian (00:19)
Very glad to have Gary with us. Gary is an agile coach. He's a lean consultant. He owns his own company called Evanetics, but he is also the author of a newly published book that came out this summer. It's called The Effective Scrum Master. And it really is a comprehensive guide. It's a really interesting read. So I thought we'd have him on to talk to us about. what that means, an effective scrum master. So scrum master is this episode, I think it's gonna be really a special one for you. So Gary, let's start with that question. When you say an effective scrum master, what is an effective scrum master?

Gary (00:56)
In my experience, I've worked with a lot of Scrum Masters who go through the motions, they understand the events, they focus on how to run these Scrum events. But the teams flounder and they struggle with what should I do next? How do I anticipate things? And the Scrum Masters themselves often get very frustrated. One of the complaints that I hear, especially from early to mid-career Scrum Masters is I have this anxiety. How do I know that my team is operating as efficient, as efficiently and effectively as they can because they focus so much on efficiency. So this idea of effectiveness really is much more important. In fact, John Kern, one of the co-authors of the Agile Manifesto, who wrote the foreword for my book, he focused in on that word effective because we spend so much of our energies trying to be efficient. that we aren't accomplishing what we need to do, which is to build self-organizing, mature teams. And that's really the focus of my book.

Brian (02:01)
That's an awesome distinction, I think, because I like that a lot. There's a conversation that I will have sometimes in class about how that drive or search for trying to be not effective, sorry, what was the other word that you used? Efficient, sorry, sorry, just slipped my mind, ADHD. But the efficient kind of quotient there I think is...

Gary (02:18)
Efficient.

Brian (02:27)
something that in business in the business world today is a highly visible term. It's something that everyone seems to think is needed. But, you know, that really dates back to sort of the assembly line and efficiency experts that would stand behind you with a stop clock and try to get you to do something, you know, point two seconds faster so that it would total up to, you know, more productivity over the course of the day. But that's not the kind of work we do.

Gary (02:56)
I love the fact that you've mentioned that that was really the Frederick Winslow Taylor scientific management approach. And it was very much based on this idea of efficiency. But I have seen so many teams and as an agile coach, I've had multiple experiences of teams that are very, very efficient at going in the wrong direction entirely. They've lost their focus on true north. They don't understand what it is they're actually supposed to do. They think that the Scrum Guide, 14 pages in the Scrum Guide, is their Bible. And that's all that they need to know. And nothing could be further from the truth.

Brian (03:37)
Yeah. Yeah. And to me that, you're talking about efficiency versus effectiveness. You know, if we were a company that was trying to create a new drug to cure some disease, you know, I want effective. I don't want efficient. I don't want someone, I don't want to produce a million pills that don't work. I want to produce, you I'd rather produce one that works, you know.

Gary (03:59)
Exactly.

Brian (04:05)
And that seems to be kind of something that I think a lot of teams are missing today.

Gary (04:09)
It does indeed.

Brian (04:10)
Well, good. I like that distinction. I think that's a good distinction and that's a good place for us to start to think about this role as being kind of more effective. I think that they're sort of, I don't know, I'm kind of curious what your take is on this. Is it a marketing problem? Is it an education problem? Why is there so much confusion, I think, about what a scrum master, what a good scrum master is?

Gary (04:41)
That's a really deep and broad question. Part of it is that in the beginning, when Scrum was introduced into the community and was just beginning to become known, there were two attributes of Scrum Masters that were repeated again and again and again. That was you became a servant leader for the team and you removed impediments.

Brian (04:44)
Just a light casual one here.

Gary (05:09)
Unfortunately, most people stopped at that point. And they didn't realize that this, the Scrum Master role, and I'll admit, I take a very expansive view of the Scrum Master role because I've been doing this since 1993, basically, 1994. And I've learned through making lots and lots of mistakes. And the idea that All we have to do is be a servant. Well, what does that mean to be a servant leader? Nobody ever really defined it. I actually wrote an essay a number of years ago on what it meant to not be a servant leader so that I could understand by contradiction what it was that I should be doing. I called it the top 10 scrum master crimes. And really, a lot of them really had to do with crimes because it's very easy for a scrum master to start to merge into making decisions for the team that the scrum master should not be making. Now, there are times when a scrum master should direct the team, should make decisions for the team if the team is not qualified to make certain decisions because they're just too new. But this idea of being a certain leader There's so much more to that. In my expansive view of the Scrum Master role, it is not a process role first. It's a people role. And to be an effective Scrum Master, you have to be an effective people person. I've worked with so many teams and coached Scrum Masters. Scrum Masters just did not like people. They weren't people persons. And the teams responded accordingly. So. A lot of the coaching that I do with my Scrum Masters is you've got to reach deep. You've got to be able to get into people's lives rather than hold them off, you know. And so a lot of it has to do with that.

Brian (07:10)
I love that. I wholeheartedly concur with that. I've talked on this podcast a little bit about how it seems like we've lost the focus of that first line of the Agile Manifesto, individuals and interactions over process and tools. And I mentioned when I go to Agile conferences sometimes, I feel like the majority of the talks that I see and hear are process and tools talks rather than know, individuals and interactions talks. And I can't agree more. I think that's really a focus for us as Scrum Masters is the individuals and interactions portion, the people portion. You know, our teams are made up of people and if we're not good with helping understand how people work together, we're kind of really missing the value of what it is we deliver to the teams, I think.

Gary (08:04)
And Brian, the people are all different. And to have a one size fits all because the scrum guy says do X, and Z. Well, that'll work for some people, but it will not work for others. And it may even build resentment within the team because they feel that they're being treated unfairly. The focus, the theme of my book and the reason I wrote the book.

Brian (08:06)
Right, exactly.

Gary (08:30)
is that I had seen so many teams that were floundering under Scrum Masters who really didn't understand their own role. And I came up from my experience, I defined four different categories that helped to elaborate what the Scrum Master should be if they want to be effective. And I labeled those as Sherpa, Shepherd, Sheepdog, and Diagnostician. I couldn't really think of a word. I started with an S for diagnosticians. But I have a strong medical background, so diagnostician really helped because the sherpa is the expert. And to be an effective scrum master, you have to be an expert, not at scrum, but at agile. We really want, I want my scrum masters to be agile masters. And as a coach, I'm constantly pushing them. How are you improving your craft? And what is involved in that craft? So you've got to be an expert.

Brian (08:58)
Hahaha.

Gary (09:26)
Now for a new scrum master, that's a contradiction in terms. You can't be an expert if you are just at the beginning of the journey. But there are things that you can do. And I discussed this. In order to from exposure, you can gain experience. And from experience, you can generate expertise. And so that's the first one. If ultimately you need to be a master of Agile. Secondly, a Sherpa and then a... a Sherpa and then a Shepherd, you have to be able to guide the team. And you can't guide somebody if you haven't been through that path before. So this is where the issue of longevity, education, and just exposure and experience with different teams on different projects. This is where the maturity comes and you start to develop a depth of understanding. But then there's the hardest part, the hardest persona of the scrum master is the sheepdog. This is where you are the protector of the team. And so many scrum masters fold in this area because a threat will come either from management or from within the team or somebody outside the team like a product owner. And the scrum master doesn't understand how to protect his or her own team. I'll share a little war story with you that is in the book. I had a product owner who one morning came in and just started ripping through several of my team members. I don't know what happened at that point. I stepped between him and the team and I said, do not take another step forward. I was ready to defend my team physically. It didn't come to that. And later I learned the reason for why he was so upset. But if you're going to be a sheepdog and protect your team, it may require personal sacrifice. It may require professional sacrifice. And this is the area where so many scrum masters, they can't deal with that part because they don't have that confidence. So you've got the Sherpa who's the expert, the shepherd who is the guide. The sheepdog who's the protector and finally the diagnostician who is the healer. Things are going to go awry and you have to have a way of diagnosing what the root cause of the problem is. And this is where the issue of metrics and understanding your team members, building a rapport with your team members that quite often is extremely intimate. I have had team members, I have a series of questions I ask all my team members so that I understand their background and such and also things that I need to be aware of. And I will ask them, do you have any medical issues or other accommodations that we might need to consider for you? This is an issue of respect so that we don't put somebody in an uncomfortable situation. It's a strictly private conversation. I've had people share with me that they have a drug problem. that they're caring for an ailing parent, that they're going through a divorce, all kinds of different issues that come out. And we work out special signals so that if they're having an episode someday, they just give me that signal. And I know that I need to either give them space or give them some special consideration. This is what I mean by the people issue. You've got to get to the point where you allow people's lives to splash onto you and you get wet with their issues. And yet you still have to maintain your autonomy and separation in order to work with the whole team together. The Scrum Master role is extremely complex from my perspective because it involves people, as you say, individuals and their interactions. That's where we have to start.

Brian (13:33)
I agree. And that's a great call out to say, to talk about there, just the idea that, you these are, these are individuals, not, they're not robots, you know, like they're not AIs yet. These are human beings and they have lives outside of work. They have things that affect them. And if they're going through a divorce, like you said, then you think that might affect their work life? Well, of course it will. Cause they're a human, right? And that's gonna...

Gary (13:43)
Right. Yes.

Brian (13:57)
that's going to affect their, their mood that day. That's going to affect, you know, how productive they are. It's going to affect lots of things. And, and, you know, we, we've talked here on the podcast a little bit about making accommodations for people with different, neurodivergent traits like ADHD or, autism or other things like that. And, know, I've always loved the idea of, know, putting people in the best position to be successful, you know, trying to understand what is. unique about them, strengths and weaknesses, so that you can help them to be put in a position that they can shine, right? They can really contribute in their own unique way. And we have to allow for both those strengths and weaknesses. We have to help them with the weaknesses. We have to put them in a position to share their strengths.

Gary (14:49)
And this leads to a slightly different topic if I can move up a little bit. The scrum master role is an endangered species right now. And there's a reason for that. There's several reasons for that. One of which is what we've been talking about. So many scrum masters are not people persons. And as a result, the teams are not accomplishing what the organization needs. And therefore the scrum master is regarded as overhead.

Brian (14:52)
Yeah, please, please, please. Hmm, yeah.

Gary (15:19)
as ineffective. And frankly, that's correct. There are currently, if you look at the Scrum Alliance and Scrum.org, I got the figures from these companies as of the beginning of this year, there are about two million Scrum Masters in the world right They're not all equally effective, Many of them are PSN1s from Scrum.org and there are like 625,000 of those, that type of thing. And then you get 39,000 PSN2s and then you get a thousand or so PSN3s. You can see the drop off there, just huge drop off. And the certification issues lead people to think that they're a Scrum master. Scrum two days or? An online examination doesn't prepare you. It simply doesn't. We've not done a good job of helping people understand through these major certification roles. that this is a starting point, but it's not going to make you effective. And part of it is it's become commoditized. And so we have this issue of lots and lots of scrummasters, most of whom really are not people persons and most of whom don't understand how to deal with a team and build a team rather than just an assembly of individuals. I've taken over teams that have been floundering. I've done this multiple times. And on day one, it's a series of isolated individuals. That's the best that they could have. Because there was no cohesion that could be found. And that always takes me a lot of effort and a lot of time to figure out how can I find cohesion within the team. So it's exhausting. The Scrum Master rule is really exhausting at times. And if someone's not tired at the end of the day, they're not doing it right.

Brian (17:22)
Yeah, I really am in alignment with what you're saying here. And I've thought about this issue a lot as well, and just the idea that we seem to find ourselves in a situation where, as you said, there's a lot of people who have that certification. And as someone who gives people certifications, I have to take my own part in that. I have to accept my own role and what that plays in it. But I think that you're right to... The training is necessary, right? You have to understand the basics. You have to understand these things before you can do anything else. However, I think that the disservice that the industry has done is to make this proclamation that if someone is certified, that they are ready to lead. And that really is what a Scrum Master is, is a leader in the organization. They're a leader for the Scrum process in the organization. And that's just...

Gary (17:55)
Yes. Yes.

Brian (18:23)
not true, right? It just takes more ongoing mentoring and coaching for that person to get to a place where they are really a, you know, what we would call a change agent, right? They are there to, you I always like to use the term infect the organization. They're there to spread and infect this mindset, this philosophy. And if we don't understand it ourselves, if we're not really living that philosophy, If we want our team to be experimentation based and we don't experiment ourself and we don't kind of demonstrate to them what it looks like to experiment, to try things, to fail, to figure out why that didn't work and then apply a new change and say, let's try something different. If we don't demonstrate that, not just tell them, but demonstrate it, they're never going to get that. They're going to stay, as you said, a collection of individuals. And I think that's, to me, that seems to be one of the big issues today with Scrum Masters and with Scrum in general is just that we have, you know, in opposition to your book, ineffective Scrum Masters that aren't really helping people see what Scrum should be.

Gary (19:41)
Exactly. And you've touched on what I call the four E's, which are exposure, experience, expertise, all built through experimentation. And you use that word to experiment. We need to experiment. But experimentation takes courage. Now that is one of the Scrum values. But when you get a young person or a new Scrum master who's in a role in an organization that may have certain, let's say, unsafe environment and cultural factors. It's very difficult for most people to build that courage to say, we've got to change this and become agents of change. Now, obviously they can, they should be diplomatic. They should be respectful, but they should also be persistent. But being able to see that requires a vision. You have to be able to be able to look around and see where are the big problems that we have? Why should I rearrange the deck chairs on the Titanic if the ship is sinking?

Brian (20:41)
you

Gary (20:45)
And so having that vision, again, comes from maturity. And the Scrum Masters that I work with, I push them pretty hard because I want them to grow. And every one of them has thanked me. But they didn't thank me during while it was happening.

Brian (21:06)
Ha Yeah. Yeah, I can understand that. mean, we, you know, one of the analogies I'll use there is like, we, a lot of us that have gone through the process and become a trainer will say it was hell while we went through it, but we look back on it and think that was necessary. We needed to go through that. now that we've gone through it we're on the other side, that was a necessary component of becoming an effective trainer was really seeing it up close and personal and seeing how other people do it. So I completely get that.

Gary (21:31)
Exactly.

Brian (21:36)
I want to ask you a question here that I know this is a loaded question. I get this question all the time. But I thought it might be interesting to hear your perspective on this from the effective Scrum Master perspective. People constantly ask, well, what does a Scrum Master do all day? Because when you look at the Scrum Guide and you look at the things that we have as responsibilities, You know, the two main responsibilities we have that are ongoing is to make sure events happen and make sure that the time boxes are kept according to the Scrum Guide. But I try to tell people there's a lot that goes on between those events. It's not just about the events, right? There's a lot that we do. just help our audience. For those people who are listening and don't really have a clear picture of what a Scrum Master does, just give us some samples of what you see as activity that effective Scrum Masters would take on a regular basis.

Gary (22:30)
What an interesting qualitative question.

Brian (22:33)
Ha ha ha.

Gary (22:34)
And I say qualitative on purpose. What does a scrum master do? What a scrum master should do is listen, listen a lot, observe, even if you're remote and virtual. You should be monitoring the Slack channel. You should be having video sessions. You should be attending team discussions whenever you can, but not only to listen, but to be the last one to speak. This is a big issue. So a scrum master often is considered to be doing nothing. But what the scrum master is doing is listening, watching, being the last to speak so that he or she does not taint the conversation among the team members. And it's very easy for that to happen. They should be compiling. team metrics. And I have a very lengthy section in the book on metrics, not only velocity and burn down charts and that type of thing, but a number of other other metrics that I've developed over the years for my own teams. So that the Scrum Master and the team can understand their own performance. They should be training, obviously, as a Sherpa, as an expert. They should be conveying knowledge to the team and they should be teaching every time they're talking to somebody, they should be teaching someone. So it's not a prescribed set of activities in my estimation of what a scrum master does. And I'm going to I'm going to use an analogy here. And it's going to it's going to offend some people because they're going to say, that's a terrible analogy. Well, it's actually a good analogy if you take it as that. The scrum master is like a parent. and needs to nurture the family. How does a parent, what does a parent do? They listen, they observe, they teach, they guide. Sometimes they have to protect, sometimes they have to discipline. And these are all skills that make for a good effective scrum master. So as I say, it's a qualitative issue. But a person who cannot parent well, I'm not saying the team are children, I'm saying they're your family. You need to parent your family. And you need to, as an experienced person who hopefully has a bit more experience and exposure and wisdom. and has better insight into how the world works, even the world of the organization, the Scrum Master has to be able to convey that on a day-to-day, hour-to-hour basis. It is not a part-time job. It is a full-time, exhausting, boots-on-the-ground position that many people just cannot fill. It's sad, but not everybody can do everything. Coming back to the certifications again, job ads always want to know you need to have a CSM or a PSM. You need to have an ACSM, type of thing, advanced certified Scrum Master. These are proxies that companies use because they don't know what a Scrum Master does. They don't know how to qualify it. So they try to quantify it through a certification. And what they have are two million Scrum Masters. who are certified in the world. How many of those are really good? Not all of

Brian (26:06)
Right.

Gary (26:07)
So the reason that I dwell on this a little bit, Brian, is my book is there to help people understand. not only the limits, but the expanse of what they should do. And there are limits to what a scrum master should do, but there's also an expansive view of they need to do more than just be a servant leader and remove impediments. Those are important. That's not the end of it.

Brian (26:33)
I agree. It's kind of interesting because it's a delicate balance, right? Because it's sort of like, you know, there's not a recipe. There's not a clear, hey, here's the 10 things that you do every day. And just when you come in the morning, check this list off and do these things, right? There's not that. But I think that the other mistake that I see some Scrum Masters make sometimes is that they treat it as being a purely reactive kind of position where I'm going to sit back and wait for things. And then when something happens, then I'll, then I'll jump in and I'll do something based on what someone else has done, which I think is a mistake as well. We we're proactive. We were very proactive to, to make an impact and make a difference. And when we recognize something's needed, we, got to jump in there. We got to get in there and do something about it when it's needed. you wouldn't want to have a coach of a team who set back and just, you know,

Gary (27:26)
It is.

Brian (27:30)
waited for someone to come to them and ask them for questions. There's no strategy. There's no paying attention to fundamentals. All those things would kind of go out the window if that coach isn't more proactive with his approach towards his or her approach toward the team.

Gary (27:45)
Exactly. That's a wonderful analogy because I was a soccer coach as well. I'm a soccer player as well. And when I'm coaching youth or that type of thing, I have to teach them how to use this sideline, the touch line in order as a virtual defender. need to have been on the field to know how to teach them how to operate on the field. And if I can't get involved with them, if I just wait until they make a mistake, they're going to make a lot of mistakes.

Brian (27:48)
Hmm.

Gary (28:14)
And you've touched on this idea of the passive scrum master. Scrum master is not a passive role. I had a product owner, one of the best that I've ever worked with in my career. We were having a very heated conversation one day, as we often did. And he said, Evans, you're an activist scrum master. And I had never heard that before. And I reflected on it a little bit and I said, Chuck, you're right, I am. But not everybody has that kind of personality. So each scrimmaster has to identify where they may need to improve, maybe some of their assertiveness, some others need to learn how to hold back. It's a learning curve. It's a learning 24-hour-a-day learning session. We're all different. teams are different, the Scrum Masters are different. And as we get more experience and develop more expertise, we handle things differently as a result of that growth. And my role as a coach is to grow the Scrum Masters, to grow the teams. And I've loved it because I love working with people. So you get to work with people, you get to solve problems and you get to see tangible results in people's careers. What more could you ask?

Brian (29:36)
Right, right. I'm with you. I'm right there with you. I can't agree more. Well, this has been a great discussion. just want to, you know, we mentioned already your book is called The Effective Scrum Master. We're to put links in our show notes to that if people want to go and find that and just, but you can find it on Amazon. Gary K. Evans, The Effective Scrum Master. Gary, how can people find out if they want to get in touch with you or find out more about your work, how can they get in touch with

Gary (29:37)
Thank Well, appreciate that. I am currently putting up, there is a, we have a website. It's called effectivescrummaster.com. I'll repeat that. Effectivescrummaster.com. There's a sign up link there. It's the page is just under construction at this point. It's live, but people can go up and they can enter an email to be notified when we start to make changes. There'll be some free information there, some resources that they can download. We've got a plan on how we're going to roll this out, but that's just beginning. And so I hope that people will go and visit that and hopefully we'll be able to develop a relationship and they'll be able to reach out to me through that website. Again, effectivescrummaster.com.

Brian (30:51)
Awesome. Well, thank you so much, Gary, for making the time. It's been a really great conversation and I really appreciate you making the time to come on the show.

Gary (30:59)
Brian, this has been my privilege and I really appreciate it. Thank you so much.

Get ready for a special Thanksgiving episode where Brian Milner shares what he’s most grateful for this year and why a little reflection on gratitude can go a long way. It’s time to embrace the positives and celebrate the connections that keep us growing.

Overview

In this special Thanksgiving episode, Brian Milner takes a heartfelt pause to reflect on gratitude, expressing thanks for his listeners, cherished friendships, and the fresh ideas that continue to shape his Agile journey. He invites everyone to join him in acknowledging the positive aspects of their lives and to practice gratitude, especially during difficult times.

References and resources mentioned in the show:

Subscribe to the Agile Mentors Podcast
Join 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 [email protected]

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.

Auto-generated Transcript:

Brian (00:00)
Hey there, Agile Mentors. Yes, I'm not saying my typical opening because this isn't a typical episode. I don't want to make anything cheesy here. It is Thanksgiving. It is around Thanksgiving time here in the US. And traditionally, I've given a little message around this time that's just me. And I won't take a lot of your time here today.

But I do want to just kind of focus in a little bit on that concept of being thankful because I do think it's important for us to try to understand and be thankful for the things that we have in our life that maybe we don't always take time to kind of recognize. And this year has been a very kind of challenging years in some ways for our industry, for the profession, but it's also been exciting in some ways as well.

And rather than dwelling on just things that would be kind of hypercritical or negative, I think it's important for us to maybe focus in on some of those positive things. So I'll just give you a quick hit list here of things that I, I just wanted to think about about three specific things that I thought were things that I am extremely thankful for this year at this point in my life. and in my interactions with people.

The first and foremost, I'm not saving the best for last, I'm doing the best first. That's you, the listeners of this podcast. I can't thank you enough for tuning in and listening. You put out a podcast like this, you have no idea. It's kind of like you're shouting into the void. And you have no idea who is listening and who is not listening, what their desires are, what they want from you. That's why I beg you all the time for feedback, because I just want to know how it can be better for you.

I just want to know how I can make this a better use of your time. But I've had the pleasure this year of getting to go to several conferences and going to those conferences is always my chance to kind of talk to face to face some of the people who listen to this podcast. And it is such a thrill. it, just excites me to no end when I'm at those conferences and someone comes up to me and says, Hey, I listened to the podcast. I really liked the stuff you put out there on that. And it really makes an impact for me. Or, you know, I'll hear someone come up and say, Hey, I just found it. I started listening from episode one. I'm now on episode 10 and, it's all been really, really impactful. And I just really appreciate, what you're doing there. So I, I just want to say a huge thanks to you. I mean, we couldn't keep doing this if we didn't have listeners. So I just, I really appreciate you. I appreciate that you're on this journey with me.

We're kind of both learning together as we go through this because every episode I learn something from these guests that come through. And I know that you are as well. You're learning things as we go through these topics. So I just want to thank you for being along the ride with me. And especially thank you for those who have come up and introduced yourself and said hello to me over this past year. Really, really appreciate getting to meet you and learn a little bit more about you, about the things that you want and the things that you need. So thank you for being listeners. Thank you for being, for the people who send feedback and email us over our podcast at mountaingoatsoftware.com address. I really, really appreciate you. because we wouldn't be here without you.

Another thing I thought I was really, really thankful for this year, the kind of in line with that is just new friends. We do a lot of this stuff, or least I should say, I do a lot of this stuff as a trainer out of my home office and spend several days with people in classes. And I make a lot of new friends through those classes just from people that I connect with and people who stay in contact with me. So I'm highly appreciative of those people that are kind of still on my radar and people that have come through classes with me and have stayed connected with me. But I'm appreciative of the people that I've gotten to spend some quality time with at the different conferences I've been at this year.

There's been several conversations that I've had with people that have been so impactful to me, just really, really personal, sometimes emotional conversations I've had with individuals. And it just reminds you that it's human beings that are at the core of this, It's people. getting to know and understand people, I think, one of the joys of getting to do this kind of work. That you get to meet new people and get to hear their stories and learn how they see the world. So I'm really thankful for the new friends that have come into my life. through the course of the last year. And then I'm really thankful for new ideas.

The guests that have come through here have, you know, many of them have kind of given me new ways of seeing things, kind of seeing things through a new lens that has challenged me. And I'm always really grateful. when an assumption or an opinion I have is challenged, I don't think of that as being kind of an aggressive thing towards me. I think of it as, well, that's kind of pushing my boundaries a little bit. I thought that I knew and understood this in this way, but now someone's challenged me to look at this from a different perspective. I look at this from a different viewpoint. And I am just enormously thankful that as I've... grown in this profession as I've been doing this now for, gosh, I've been a software developer maybe 25 years now, I'm that old. But given that, there are still plenty of concepts and ideas that they're never ending.

There's never an end to the things that would challenge my assumptions or my beliefs about things and get me to really re-examine them. That doesn't mean I'm going to change all of them. But I tell people who come through the class, I don't have any problem with you challenging an idea. The idea isn't me. The idea is an idea. And I change ideas all the time. If I get presented with better information, if there's new data that comes out that says, hey, know that way we've been thinking about this, that's actually wrong, I embrace that. I welcome that. Because it's the reality. Right?

And I don't want to continue down the road that's false. So I just really, really appreciate that idea that these ideas are not stale. These aren't ideas, aren't things that would just go by the wayside. These are things that constantly challenge us and get us to look at things in a new light. This isn't an awards acceptance speech, so I'm not going to go through the list of specific people.

There's lots of people that I would thank and they know who they are. There's lots of people who work really hard for this podcast to work. And people like Mike Cohn who have mentored me and helped me to understand things that I would never have if I had not come in contact with them. So just really, really am thankful for all of those things.

And I encourage you, it may sound like a silly thing, But take five minutes, take 10 minutes and just sit down with a blank piece of paper and just write out, if you were gonna make your top 10, right? What are the top 10 things that this year that you're thankful for, right? You don't have to go through, you know, just the stereotypical things that you might put down, but you know, if you were to think back over the past year, what would be the things that you are most thankful for over the past year?

And as I said, I know it's been a hard year for a lot of people. But I think that when we are able to stop and do that and really understand, hey, here are the things that really have gone well. Here are the things I'm really thankful that I encountered or that happened to me in this last year. It really can have a dramatic impact on your outlook and how you see things and really what you look for moving forward, what you focus on moving forward.

So I just encourage you, it's a week for that. It's a time when we do that here in the US especially, but if you're somewhere international and maybe you have a Thanksgiving on a different part of the year or a different day, or maybe you don't have one in your country, I encourage you to just take time out to do it. I think you'll appreciate it. I think it'll make an impact for you. So that's really all I got for you today.

As I said, short little message, kind of traditional for us to do a little brief little Thanksgiving message here. again, I just want to thank you. Thank you for tuning in. Thank you for being with me on this journey, especially this past year.

And I'm excited. I can't wait to see where we go from this point forward. Who knows, right? We might do changes. We might try some new things. All kind of depends on what you guys want to see in here. So thank you so much for where we've come so far. And we'll call it. So. We won't do any of typical outro stuff I normally do, but you know what I normally say. So just kind of think that in your head.

Thanks, everybody. I really appreciate you listening to this special message. And next week, we'll be back with just a regular episode. You're going to really enjoy it. So talk to you next time on another episode of the Agile Mentors Podcast.

Curious if your product team is caught in common traps that limit success? Join Brian and David Pereira as they explore how to simplify workflows, make smarter bets with prioritization, and shift from output-driven thinking to delivering real value.

Overview

In this episode of the Agile Mentors Podcast, host Brian Milner chats with David Pereira, author of Untrapping Product Teams. Together, they dive into the common traps product teams face, the differences between project and product management, and practical strategies for prioritization.

David shares insights from his book, offering advice on building healthier backlogs, creating adaptable roadmaps, and moving beyond a feature-obsessed mindset to focus on delivering true value.

References and resources mentioned in the show:

David Pereira
Untrapping Product Teams by David Pereira
Certified Scrum Product Owner® Training
Advanced Certified Scrum Product Owner®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe 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 [email protected]

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.

David Pereira is a seasoned Product Leader with over 15 years of experience guiding Agile teams to deliver real value faster. As CEO of omoqo GmbH and a top writer on product management, David is passionate about helping teams overcome challenges, unlock their potential, and simplify their workflows to drive meaningful outcomes.

Auto-generated Transcript:

Brian (00:00)
Welcome back Agile Mentors. We are here for yet another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have Mr. David Pereira with us. Welcome in, David.

David Pereira (00:12)
Let's be here.

Brian (00:14)
Very excited to have David here with us. David is the author of a new book called, Untrapping Product Teams. So product owners, this is going to be a discussion that I know you're going to find very interesting. We're going to be talking about a lot of things that have to do with product teams and sort of the ins and outs of working with your products. So David, just for starters, what inspired you to write the book? What was the main problem you were trying to address when you sat down to write this?

David Pereira (00:42)
pain. I have worked as a product person for many companies throughout the years, different countries, different sides. And one thing that I realized is that there many things going wrong. And sometimes we just don't know that it's wrong and it hurts. Then when we realize the question is, what are we going to do about it? So I started writing about untrapped products. From this perspective,

Brian (00:43)
Ha ha ha ha.

David Pereira (01:12)
of there's something wrong, we might not see, but let's start from this and then maybe we can transform how we work for the better.

Brian (01:23)
Awesome. Yeah, that's a great take on it. Cause I agree. There's certain times when as a product owner, know I've, you you're kind of chugging along and things are going okay, but then something happens and it's sort of like, wow, this is painful. I don't know where it's, I can't put my finger on what's going wrong, but there's something happening here. And you you try to push through it and just get past it sometimes. And it's, that's not always the best strategy. I know you talk about there being sort of these dangerous traps that are kind of typical traps that product people fall into. Can you share any of those with us? What are some of the dangerous traps you identified here?

David Pereira (02:01)
Sure, there's the classic one called the gigantic backlog. So the team looked at it and we're talking about product owners, but sometimes product owners get demoted to backlog owners and they don't even notice that. So that's one of the most classic traps, but there's also another I call the calendar driven framework. You may think you work with agile, but then you realize that you only do what is in your calendar. So that digitates what you're doing and so on. And you fall prey to what I call as a meeting marathon.

Brian (02:38)
Yeah. I want to go back a little bit to your, to the big backlog kind of, idea there, because I, I know that's a issue I've talked with people about in class a lot. And, I just want to get your take on this. Cause I, one of the things, you know, we'll, we'll discuss in classes sometimes just the idea of having too big of a backlog and, and kind of wrestling with it and trying to get it in shape. But the question always comes up, you know, you what's the. the right number. We ask a question in class and say, how big is your backlog? And you'll see different reactions from people. Some people, less than 50, other people 250, other people 1,000 plus items. Is there a number? Is there a number that beyond which it's all of sudden now too big?

David Pereira (03:24)
Yeah, for sure. So for me, first is understanding what is the backlog about. It is a vehicle to drive whether when you look at the backlog, should be able to tell a story. You should know where you're heading to. But when you look there, if you see a 60 year old Christmas wishlist that has everything in but you cannot connect anything, that's when it starts smelling. So for me, a good backlog will have no more than I would say two, three things ahead of us. There might be some things that are directions that we will continue refine and get it better and so on. But if we would have something that takes us like six months of work to get it through, maybe we are doing project management.

Brian (04:12)
So that's an interesting distinction. if we're moving into product, how would you define that then if we're saying project management versus product management, how do you define that difference?

David Pereira (04:23)
So project management in general, we assume we know what needs to happen. So we start planning on when we do what and how long we're gonna invest in this and so on. Product management is more about starting what is value, what do we want to achieve? And then we start embracing the unknown, facing reality, learning from it. And then the backlog will emerge from our learnings. So it means we know where we want to land, but how we're gonna get there. We know where to start, but not the next 3, 4, 5 steps.

Brian (04:56)
Love that. So that gets us kind of into talking about road mapping a little bit because I know that's one of the things you talk about in your book and kind of the idea of trying to plan a little bit far in advance. So if we have a backlog, it's really more two to three sprints versus six months. Do you recommend the product owners roadmap for longer than two to three sprints or is the roadmap just a two to three sprint roadmap?

David Pereira (05:24)
Sure. So the roadmap for me, it is about a different flight level. So the backlog is the now. What are we doing right now in the next two sprints as we talked about? The roadmap, we're looking at what is the overarching goal we are pursuing. So that could be, for example, a milestone that we aim to achieve for the next two, three months. And then the backlog will march towards that. But for the roadmap, I think it's still important to have something like, what is the direction for six months that maybe we are considering. But the farther we go, the more I would say blurry it becomes. It's more like a direction and we can feel free to adapt that.

Brian (06:13)
So help me understand here, because one of the things I think that I hear a lot of questions about in class is, since 2020, the Scrum Guide has added this idea of a product goal. And we've always traditionally thought about having a vision for the product. So now we have sort of this nested nature of having a vision, a product goal. And of course, we've always had sprinkles. How do you see those things related? relating to some sort of road mapping.

David Pereira (06:45)
Let's take a company here as an example. I like looking at the SpaceX. What is the vision? The vision is something audacious, inspiring, that people can connect with. Might be very hard to achieve, but it gives us guidance. For SpaceX, would say two words, populate Mars. That's the vision. It's very far. And what would be a roadmap goal? For example, something they achieved already. It's a step to get closer to the vision. Build a reusable rocket. That's something they spent a lot of time doing, and that could be a roadmap item. Then when you go to the sprint ghost, it's just a smaller step towards that.

Brian (07:35)
Gotcha. Yeah, that's great way to put it. I like that idea and I appreciate you using kind of a real world example. I think that kind of drives it home for everybody. I think it's obviously one of the things we talk about quite a bit in Agile is that idea of that we don't have any problem with planning. Planning is a good thing. What we have a problem with is plans that are so concrete that they're inflexible. So when we... I've always thought as a product owner, when we try to create these roadmaps, the further we get out from today, the looser, the less defined it is, the more rough the idea is, and the less people should count on there being any date that's going to be met based off of that longer term horizon. Of course, there are exceptions to this. You mentioned SpaceX, mean, SpaceX has a multi-year goal. I mean, they have something that's kind of further out to the future. So I think that there are some exceptions that we probably could make in there. But I think you're right. Think about them in that steps as far as vision to product goal to sprinkle. One of the other things that I found kind of interesting in reading up and thinking about your book is you talk about the difference between coordinated and collaborative workflows. Can you define those? Tell us a little bit about what you meant by that, the difference between those two.

David Pereira (08:31)
Yeah, of course. I start with a question. When we are talking about coordinative development flow, step back and then reflect. Do you talk more about work than you do it? Or you just go and do work on it? If you feel like you are all the time talking about work, everyone is talking about it, you have so many meetings discussing and so on, but then you wonder who is doing the work, then there's a chance you are in the coordinative development flow. The collaborative development flow, it's a little bit chaotic. There are many things happening. Teams are looking at what can we do right now? What can we do next? They are adapting all the time and so on. Plans are actually means to an end. They are not reached. They point a direction. Teams may have a plan, but it's very simple. It is not a predictive thing. When you are in the coordinative development flow, things take long. For example, you may have a lot of ideas in the beginning, then that means you need to find the most promising idea, speculation. So you may use frameworks to have the best scoring and understand what is the idea most promising. Then you invest time and crafting high fidelity prototypes and so on. There's a lot of coordination back on Perf. But if you go to a collaborative, you say, all right, I have all of these ideas here. Which ideas are worth? That's the first question. Then you say, how do they meet our, for example, product vision? How do they relate to our strategy? How do they contribute to our goal? And if you don't have answers to that, you use your friend called trash bin. So you put the things in your trash bin and then you start moving forward. And you say, all right, how do I know this has desirability? It's viable from the business. How do I know we can do it? then start running experiment. And then some things you realize, actually customers don't need it, then you don't pursue. So that's why it looks like chaos because you don't know what will get to the end, because things will fall apart on the way because you learned they don't make sense. On the coordinate, you know what gets to the end. You just don't know if it's the right thing.

Brian (11:18)
That's a great point. And you're right. If we think of this from an experimental mindset, the product development game here as more experimentation, think you're right. There's going to be things that don't, the experiments that don't turn out the way we expected, just like there is in any kind of experimentation. that can be some of the most productive moments actually is when you have those experiments that turn out differently than you anticipated because that can lead you in areas that are surprising and new and have value that you might not have otherwise recognized, I think. So yeah, I love that. I think that's a great way to talk about it. It makes me think a lot about prioritization as well because I know that's a big area for us as product owners and... You know, someone sent me an article the other day that, that I share sometimes with people that's, it's a blog post that someone put out there. was like 127 different ways to prioritize your backlog. It's just, they're all methods, right? They're all the things that you probably, all of us have probably heard and, you know, things like Moscow and, and other things like that, that people are typically use, to prioritize their backlog or rice or. relative weighting or something like that. But one of the things that I find kind of interesting with that, and I want to get your take on this David, is sometimes when I will use something like relative weighting, for example, or rice, very much more of an analytical approach, right? And we're trying to try to analyze it based on several factors and see what the score comes out at the end, which one's higher than the other. but one of the interesting kind of a sideline effects that I've noticed in myself as a product owner is sometimes I'll find that I'll run that kind of a process on several features and I'll get to the end and you know, I've got three features and know, a feature, a, and C and, you know, I'll take a look at the results and look, you know, it looks like feature B is number one feature C is two and, and a is three and Sort of in my head, I kind of feel this dialogue happen where I think, huh, really B is number one. Wow. would have never thought that would have been the case. That's surprising. I can't believe B came out as number one, but maybe I answered those questions incorrectly. Maybe I should go back and change my answers in doing this analysis because that can't be right. B shouldn't be one. B should maybe be two or three. And I kind of call it the the gut instinct, you know, it's kind of that gut instinct moment where you look at the results and it feels wrong, right? And I know you talk in your book kind of about, you know, opinions without evidence and kind of the idea of, know, it made me kind of think about that scenario where sometimes you'll run it through some kind of a prioritization technique and there'll be a definitive answer, but you kind of have that instinctual moment that feels like maybe this is not right. How do you handle those moments, David? Do you have any problem overriding results or do you always take the results of some kind of a prioritization technique that you've tried to use?

David Pereira (14:44)
Mm-hmm. So prioritization is something quite interesting. What I see is many companies search for certainty. We need to ensure that we find what drives value. So we take some time analyzing that. The problem is that we start injecting a lot of speculation. We think what it's right, but we don't. What I see is prioritization is a bet. So I think about placing bets. Say, all right, so there are all of these cool ideas here. I try looking, for example, at potential. As of now, what do we know about it? How many customers would care about it? How much would they care about it? Can we deliver something of that? I say, all right, let's invest one day and see what we can learn about it. Then we can move to the next. And then we can invest maybe two days. And if we don't like what we learn, then we just stop. And if you like what we learned, then we say, let's invest another week. And then we keep going to the point we say, this looks cool. And then we can do something about it. So I say like, let's have a bias toward actions. We can face reality as fast as possible. Then we can learn what makes sense and what doesn't. And I give you a concrete example. When I started about the book, I was thinking, Does it make sense for me to write a book? How do I know that? I got invited to give a keynote. I said, I'm going to speak about something that I would write and I will see how it resonates. I gave this talk 10 times. And then what happens after each talk? Few people would come to me and say, Hey, I like this thing. I like this. I like this. And everything you didn't mention, I started questioning. And then what they like to explore. And after the 10th talk, someone said, when are you writing a book about it? said, aha, now it's coming. I said, I need you to do another experiment. I posted on LinkedIn. said, I'm writing a book. And I had in my mind, if at least 200 people show interest in that, I'm going to interview people to understand their challenge. So I did that. When I decided to write a book, I didn't write the book. I explored. where to write and so on and all of this. Because I was placing bets, small investments that give me information that I can use as evidence. And that's the same what I do with digital products. It is about learning from reality, not from a meeting room.

Brian (17:25)
I love that. Yeah. I think we've, I know that I've heard that language used quite often, the idea of making small bets or making bets on things, but it really is a revolution. And you're worried way to think about it. like your, your concept of, of thinking, is it worth a day? Right. Is it worth a day to do this? Is it worth me betting a day on, on trying to find out more information about this? is that really how you look at prioritization then is, is, is you prioritize it? Is it, is it kind of, Is it worth the effort to do what it's gonna take to do this thing and think of it that way as a bet?

David Pereira (18:01)
Yeah, in this direction, because for example, when we explore what is the potential outcome, how many users would care, how much do they care about it? I say, let's see if that is true or not. Let's start learning about it. Then we can have a better understanding of the expected result. Because the danger is when you start talking about these things, it just do a scoring, like a rise, eyes or something else. then you get false confidence. So I want to move away from the false confidence to get closer to reality because in the end of the day, we don't know what we don't know.

Brian (18:41)
Yeah, I think that's a really good point to make. I know I've run an experiment sometimes in classes where we'll have a couple of different ways of prioritization. I'll give them something complicated like relative weighting or rice. And then I'll give them something, you know, ultra simple, like stack ranking and, you know, have them compare and say how, what's the difference. I know you talking to your book about kind of how important it is to simplify the decision-making process. And so I'm just, what are some of your strategies for that, for trying to simplify that decision making process?

David Pereira (19:19)
So you need to know what is priority right now. So you can filter out things. For example, if your product is scaling, what matters most? Is it retention? Is it growth? Customer satisfaction? Which is the game you are playing? Because if you don't know the game you're playing, everything is a priority. Then you need to discuss everything. So that's the reason I like starting with what matters most. Because then you remove everything else. then you can look at, so if growth is what matters most, let's think about what will contribute to that. Then we go from this.

Brian (19:56)
Yeah, that's a great way to look at it. I think you're right. I it's the outcome that we're trying to drive, right? I mean, we're rebuilding features or we're proposing to build something so that we have this outcome. And if we're not really driving that outcome, then we're wasting our time. We're not really doing what we're trying to do. Yeah, that's a great point. I know one of the other points you talked about in your book is kind of this idea of periodically doing product health checks.

David Pereira (20:12)
Exactly.

Brian (20:23)
And that was kind of an interesting new concept for me. I not heard that really spelled out in any way. Can you help the listeners kind of understand what you mean by a product health check?

David Pereira (20:34)
For me, it's a falling. We may start doing things without challenging them. We don't know if they are good, we don't know if they are bad. We know how to do them. And then that becomes our routine, our habit. On Monday we do this, on Tuesday we do that, on Wednesday we do the other. And we keep doing, and they give some results. But the problem is, is it the right thing? So I like stepping back. and looking at a few aspects so we can say, where do we stand? And then you may uncover something that is, I'm not doing it or something that I'm doing that contributes to a bad result. I always ask teams, when was the last time you retired a feature? And sometimes I hear only crickets. And then I say, when was the last time? I say, we never retired a feature. Said, what is your definition of a good product? And some people tell me, well, a good product is the one you have all features you need. There's nothing else to add. We're not there yet. And then I asked them, can you open Google? How many features do you see in the homepage? For me a good product is the one you have nothing else to remove. It's a bit different. So when you have these health checks, you have the moment of challenging, having a different perspective. And then you have the chance of saying, I want to change. I want to do different. Then you can improve how you work.

Brian (22:10)
Yeah, that's a great way to look at it too, because you're right. we're, you know, I think about this oftentimes when I talk to people about, you know, kind of their vision or even their customers and users. And really, if you can't understand or you can't really define who it is you're targeting or what it is you're trying to achieve, we shouldn't be doing it, right? We should stop and understand those things first before we move forward. I know one of the other things that you'll you talk about in the book is kind the feature obsessed or feature focused mindset. And just kind of wondering, you what kind of practical advice could you give to different product owners, product managers that are struggling in some way with that feature focused mindset?

David Pereira (22:57)
Ask more questions. That's where I start. Whenever you come with a feature, you say, what is that for? What does it enable the user? What would be the other options? Let me give you an example. In one of the places I worked, we realized that we had trouble with signup. And then someone came with an idea. Of course we have a problem. Because, let me do this again. Of course we have a problem. Because... We have to create a login all the time. If we have social login, then it's amazing. And then we put the Google login there. And we said, with Google login, we will simplify the sign up process. Nothing happened. Sign up rate remained the same. Then I started interviewing people who came to our website, but didn't sign up. What I learned from them was, I don't understand your value proposition. And then you asked me to create a user, you're going to load me with emails. Why am I going to do that? I'm not going to do it. And then I realized that the friction was something else. The value proposition was unclear and they didn't want to give their data. So we could put whatever login method, it would not help. We started with the wrong question.

Brian (24:17)
Yeah, that's a great example. I appreciate you sharing that because I think that's a common problem I think we have in the product area is kind of we see a response or we see that something's not going the way that we thought. And I know I can have the inclination at least to jump to what I think is the reason behind it. without actually verifying that that's the reason behind it. And that's a great example, right? mean, hey, we thought if we add a sign up and do it through Google, that's going to remove friction. It'll make it easier for people to sign up and we'll get more signups. Well, not if they don't really understand what your value is and why would I come back to this site? Why do I want to get emails from you? I'm not clicking on the button to go through giving you my Google information if you haven't sold me. Right? Yeah. Yeah, that's a great point to make. Well, the only other thing I'd say is I know one of the kind of time-honored discussion topics here when we talk about this stuff is really people who focus more on the output and getting distracted by outputs versus really focusing on value. What kind of advice would you give to people who either don't really understand the difference or find themselves kind of slipping back into being more focused on output versus value.

David Pereira (25:53)
Talk about assumptions. We all assume something is gonna happen. Sometimes it's just in our subconscious. We need to bring to our conscious level. For example, we say, this feature is gonna be a success because, then come your assumption, because customers want, because customers will understand how to use it, because the business can collect value. These are assumptions. And then you can say, How can I test these assumptions before I invest time into creating the feature? Then you learn.

Brian (26:29)
Yeah, I agree. That's so important. Honestly, that's one of the biggest paradigm shifts I think I went through as a product owner is that kind of shift in understanding these things in my backlog, they're assumptions. They're not requirements. They're not things that have to happen. They are things that could possibly happen. And the idea is to determine if they're the right thing to happen or not. And if not, then we should move on. Well, this is awesome. I think the books, the topic of your book sounds really fascinating and I hope everyone goes to check that out. It's called, Untrapping Product Teams. And again, David Pereira is the author here. We're put links to all this into our show notes. So if you wanna click on that and find out more, we'll put you in the right place so you can find out more. just, I'll give you kind of a sampling here just so you kind of understand my... My own boss here, Mike Cohn, has a quote here about it that says it's his new favorite product management book. So it's just, he's got people like Marty Kagan, Martin Dalmigeon that's kind of weighed in on this. Petra Willie has given quotes about this. So there's lots of big names that have read this and given it good reviews and said this is a really important work in the product area. Really encourage you to check that out. David, I can't thank you enough. Thanks for making time to come on the show.

David Pereira (27:59)
Glad to be here.

What makes a team intelligent? Brian and Linda Rising explore the surprising factors that foster group intelligence, from psychological safety to diversity, backed by groundbreaking research from MIT and Google.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner sits down with Agile thought leader Linda Rising to explore the concept of group intelligence. They dive into what makes teams intelligent, discussing the importance of diversity, psychological safety, and social perceptiveness.

Using research from MIT and Google, Linda also highlights how storytelling and a growth mindset can enhance team dynamics, leading to more effective and innovative collaboration.

References and resources mentioned in the show:

Linda Rising
Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns & Linda Rising
MIT Center For Collective Intelligence
Project Aristotle
The Fearless Organization by Amy C. Edmonson
Amy Edmonson’s TED Talks
3 ways to better connect with your coworkers - Mark T. Rivera’s TED Talk
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Agile For Leaders
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe 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 [email protected]

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.

Linda Rising is an internationally recognized consultant, speaker, and author with a Ph.D. in object-based design metrics. Known for her expertise in agile development, retrospectives, and the intersection of neuroscience and software, Linda has authored five books and numerous articles. In 2020, she received the Lifetime Achievement Award from the World Agility Forum for her impactful contributions to the industry.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back here with you for another episode of the Agile Mentors Podcast. I am with you as I always am, Brian Milner. And I wanted to introduce you today to someone I think you're really gonna enjoy here on this episode. I have the one and only Linda Rising with me. Linda, thank you so much for coming on.

Linda Rising (00:09)
Okay. It is my pleasure, Brian. Thank you so much for inviting me. It's a beautiful day here in Nashville, Tennessee.

Brian (00:32)
In Nash Vegas, yes. I actually spent a couple years in Nash Vegas. So I know that area back in the day, back in the day, because I worked at Opryland. So that'll tell you how long ago it was. Yeah, back in the dark times, right? But Linda, for those, if anyone who might not be aware, Linda is an author. She is...

Linda Rising (00:33)
Yeah! wow okay

Brian (00:58)
really what people would call an agile luminary. She has been involved with this movement for quite a while and has really, I don't think it's too far of a stretch to say shaped the conversation around this a lot with her research and other things that she's provided. we wanted to have her on because she, well, because it's Linda Rising, right? We wanted to have her on for that, but. Recently, she spoke at the Scrum Gathering, the regional Scrum Gathering that took place in Stockholm, and her topic just sounded really fascinating. I thought it would be fascinating for us to talk about. It was a topic of group intelligence. So Linda, I'm sure there's a lot of people out there like me that when they heard that the first time thought, I have no idea what that means. What does group intelligence mean?

Linda Rising (01:43)
Yeah. Actually, normally when I do anything, give a keynote or an interview on a podcast or the interviewer or the person who's inviting me will say, what would you like to talk about? That's what you did. What would you like to talk about with the idea that I could come up with a list of things I was interested in that I wanted to talk about because I knew something about it.

Brian (02:09)
Yep, it's true.

Linda Rising (02:20)
But in this case, no, it was, want you to be the opening keynote for this amazing gathering in Stockholm. and by the way, we want you to talk about group intelligence. So. That was about a year ago and I thought to myself, I don't know anything about, well, maybe I do. Maybe I do know something about group intelligence. But I have spent the past year getting ready for that talk. It was just a few weeks ago and along the way, what I found was it pulled together the research around this topic. pulled together a lot of things that I have been thinking about and it is still not over. I had to give that talk, there was a date for that, but now there are little threads that, as you say, I'm following those down various rabbit holes because they're connected to other things that I'm interested in. So this turned out to be, even though I didn't pick it and I didn't know a whole lot about it, It's turned out to be a great introduction to a different way of thinking. So we know what intelligence is, I think. Don't you? Do you know you have an idea? And aren't you intelligent?

Brian (03:41)
That's so awesome. Well, that's a quite a loaded question, right?

Linda Rising (03:53)
Of course you are and and so are our listeners our listeners are intelligent and what's interesting is that the psychologists who measure that They don't really have a definition for intelligence. What they do is they can test for it So have you ever had you know an intelligence test You know, an IQ test. Have you? Have you ever had one?

Brian (04:25)
You know what, I don't think I ever have, but I know my wife has, my daughters have, I'm very familiar with them, but I can't point back to one to say, hey, I know what my score was.

Linda Rising (04:28)
I'll bet you have. Well, sometimes you're given that test at a particular point, maybe in high school, and they didn't tell you that it was an intelligence test. You just took it along with the other battery of tests that you were taking at the time. And maybe they didn't tell you, you have an IQ of 145. They didn't tell you how smart you were.

Brian (04:47)
Yeah.

Linda Rising (05:06)
but somebody, somewhere, somehow along the way, they did. They measured it. And that's without having a definition for whatever it is. So what that test does is it says you're pretty good at solving a bunch of problems. And that's what the test is.

Brian (05:17)
That's amazing.

Linda Rising (05:32)
it asks you to look at some math problems, logic problems, spatial problems, different kinds of problems, and you either solve them pretty well or not so well, and when they are finished with that, that score on that test says something about how well you do at solving those problems. And that's what they're calling intelligence.

Brian (06:03)
I think I see where you're going with this because to me, if we're going to try to be very precise with words on that, I would say that sounds more like education. If I know how to solve a particular kind of math problem, that's because I've been educated to learn that. It's not a measure of my...

Linda Rising (06:13)
Yeah. Yep, yep. And so those tests, yeah, those tests do have a bias. They're biased toward people who have a certain kind of education biased against people who maybe didn't have that kind of education. Also, it doesn't even begin to talk about music. Here I am in Music City. Doesn't talk about musical talent.

Brian (06:43)
Yeah

Linda Rising (06:46)
It doesn't talk about your ability to perform, say, some sports activity, whether you're going to be a great basketball player or a baseball player. There are a lot of things that intelligence tests don't even, they don't even think about. Now, it doesn't mean this isn't a valid exercise because those IQ tests have been around a long time and they do measure what they measure, they measure it very well. And they do correlate with a lot of performance activities. In fact, if you were hiring somebody, the absolute best thing, if you could just do one thing, would be to give them an IQ test. That correlates most strongly with any kind of performance on the job. So it's a valid test, even if it has some biases, some problems. So that's individual intelligence and we call that IQ. So now the question is, can you do that for a group or a team?

Brian (07:53)
Yeah.

Linda Rising (08:03)
Could you say this group, could we measure it somehow? And if so, would it have the same kind of validity? That is, if they do well on this test, would that mean they would do well in the workplace? If we had that, then could we use it to say, all right, this team. is really going to be great for whatever it is that we wanted them to do. Is that possible? So obviously the answer is yes, or I wouldn't be here talking about it. Yeah. So the research is fascinating and it would take a long time to actually go into it, but it was started at MIT. The organization is called the MIT Center for Collective Intelligence. and they have been doing this now for over a decade. So this is not brand new out of the box. We're not sure where this is going. This has been happening and has been happening successfully. They do have a test. They can give it to a group. And what they find is that if the group does well, that group will also do well on other, just like IQ, other kinds of things that the test measures. And so, yes, they can measure group intelligence.

Brian (09:38)
Very interesting. This is really fascinating. Yeah. It's fascinating. I'm going to interrupt you for just a moment because I know, and forgive me if I'm taking you off track with where you were intending to go. But I know, having heard some of your other talks in the past on agile mindset and what you've written about, I know there's kind of this fundamental idea of the fixed verse.

Linda Rising (09:39)
It is interesting. Yeah. No, no, no, it's okay.

Brian (10:05)
growth mindset and the idea of intelligence being not necessarily a thing you're born with, but really something that you have the potential to change and grow. And how does that translate then to the group environment and the group's intelligence?

Linda Rising (10:23)
Yeah, so that's a great lead in because the next part of it was, well, okay, so we have this test and we can give it to a group, but we'd like to tease out some attributes of teams to say, you know, the teams that do really well on this test, they all seem to have, and they found there were three things that characterized

Brian (10:26)
Yeah.

Linda Rising (10:52)
intelligent group. The first one was called social perceptiveness. That is, are the people on the group, are they able to relate to each other? If one of the persons in the groups having a struggle for some reason, are they able to pick up on that? It's kind of hard to say, well what is that social perceptiveness? and we can come back to that, but that's first on the list. The second attribute is that when they have any kind of a discussion, that everybody talks. And that's pretty easy to see, and I know that you've probably been on teams as I have, where really not everybody talked, where maybe mostly one or two

Brian (11:24)
Yeah. Okay.

Linda Rising (11:49)
You know the loud people they did all the talking and the rest of us We just kind of sat in the corner and we said well, you know, whatever Yeah We've been there. Well, have we have we have seen that and I don't know how you're gonna feel about the third one But we all are concerned about diversity

Brian (12:00)
Yeah. Yeah, for sure.

Linda Rising (12:17)
We know that diversity is an issue. All organizations are struggling with the best way to deal with that. But the third attribute has to do with the percentage of women on the team.

Brian (12:34)
Really?

Linda Rising (12:35)
So this isn't like 50-50. This doesn't mean that you should have some women. It means the more women you have, the better. Ooh. You wanna think about that one?

Brian (12:38)
Yeah. You know what? I would not argue with that one bit because all the women that I've had in my life have been the most intelligent people I have known. So I would wholeheartedly concur with that. We're just a bunch of knuckleheads, the guys are. So I completely...

Linda Rising (12:58)
Ha!

Brian (13:17)
You know, I'm having some fun, but you're right. I can see that, you know? Like, I could see how that would be a really distinguishing characteristics.

Linda Rising (13:22)
Wow! So the researchers say maybe it's really not a gender thing because women are very good at social perceptiveness. And maybe what this third attribute, and they did a lot of statistical analyses, you you have to really dig down into the statistics and we don't want to do that. Maybe this third attribute is really a reflection of the first. And then if you, and here we're going to come to your growth mindset, if you could work with the people on the team who were not women, but who were these nerdy guys, know, could you somehow have them grow, improve, get better at social perceptiveness, then that would have the same effect as having more women on the team. And that's kind of where they are right now is can you do this? Are they equivalent? Are they really measuring the same thing? But they know that somehow that's what you've got to have is this ability to read. It's called theory of mind. Read the minds of the people on the team and that typically You know, we're stereotyping here. Typically men are not as good. So can you, could you, can you grow that characteristic? Can you get better? Can you get better at that?

Brian (15:06)
Yeah, I'll take a slight little side trail here and say that that makes perfect sense to me because one of the things that I found when I was doing my research on neurodiversity and specifically autism was that there's a book out there that I think I've shared on the podcast before, but it's called Autism in Heels. And basically the point of the book is to really examine autism in women. And one of the key points that's made in the book is the fact that when you see statistics about autism, you'll find that there's a huge number, there's a disparity. There's a large number of men, of males that are diagnosed and a few, a smaller percentage of females. And it gives the impression when you look at the data that you might think, well, this is a male thing, right? It's something that happens much more often than male. But this book is making the point that really,

Linda Rising (16:02)
Yeah.

Brian (16:04)
the criteria that was set aside to designate whether someone was autistic or not was really geared towards how it presents in males. So women were vastly underdiagnosed and still are to this day vastly underdiagnosed. And one of the things that makes it difficult to diagnose them is women are better at masking their symptoms. very much, they adapt to the environment around them. They pick up on the people around them.

Linda Rising (16:18)
Yeah.

Brian (16:34)
and they will mask the things that maybe are naturally a part of them, but they've learned in other parts of life how to do that. And so they're applying that to their autism as well. So that makes perfect sense to me.

Linda Rising (16:43)
Yeah. Yep, exactly. And of course, if we want to talk about women who have this tendency or on the spectrum, we have to mention Temple Grandin, who is one of the most famous female autistics in the world. I she's done more to gain attention for this problem, and she's definitely female. yeah, it's not it's not a male thing. But you're right that what's happened is that the women have had a growth mindset and whatever they inherited or were born with, they've done a better job at learning how to adapt given what they had as a limitation, adapting to working with others and using that as a strength. So that means that possibly, We could do that kind of thing to improve our teams if we included men in, well, what would it be? Would it be a training program? Would it be just coaching? Maybe this could be the job for a coach can certainly watch. The behavior of the team can notice, for instance, for that second attribute, is the discussion.

Brian (17:54)
Ha Linda

Rising (18:10)
Does that involve everybody equally? That could be a first step. And to encourage the growth in that direction. So one of the experiments that was done to follow on with that was to try to get male members of the team who didn't do well, you can actually measure social perceptiveness. And you mentioned autism, one of the tests. for autism is called reading the mind in the eyes. And with that test, you can show that people are better than others. And so maybe this could help us identify people who might benefit from this experimental approach. And that is to have something like, you know, I'm a patterns fan. So a collection of patterns that we used to talk about back in the day was written by Joshua Kerievsky and it was for running a study group where you read a book together a chapter at a time and you talk about it. So in the experiment the hypothesis was that reading a book together would improve the theory of mind or the social perceptiveness if it were a book that was fiction.

Brian (19:37)
Huh.

Linda Rising (19:37)
It's a story. A story. There's a hero and a beautiful princess and an adventurer and a bad guy and a good guy. in reading that, you learn to identify with the characters. And you talk about it. What was the character feeling when the handsome prince ran in to rescue the what was he thinking?

Brian (19:39)
Yeah.

Linda Rising (20:05)
So in a structured study group situation like that, reading fiction together and the results so far are positive but not enormous. It does help. It does help.

Brian (20:20)
Yeah. Yeah, I can see that, because you're trying to collectively interpret and you're getting a peek into someone else's mind of how they might interpret a situation and that can help you to interpret other situations. Yeah, I can see that.

Linda Rising (20:23)
May not. Yeah! Yeah, especially if someone was not in the habit of doing that. There are a lot of people who say, I've never even stopped to think about how the other members of my team are feeling.

Brian (20:43)
Yeah.

Linda Rising (20:56)
So attached to all of this is an enormous project that Google also started called Project Aristotle. And their idea was we wanna know what the secret is, what makes great teams. And they looked at everything. They spent years. mean, Google collects data, data they've got. and statisticians and analysts, they got it. And they spent years collecting and analyzing. And the summary at the end of all that was they found nothing.

Brian (21:38)
Hahaha

Linda Rising (21:40)
Did you read that? Did you read about that study? Yeah.

Brian (21:44)
I I'm familiar with that study. I really like what they did. Because when you have that kind of data available to you across cultures, across business units, it was an ambitious kind of study. I'm really thankful that they did it because I think they had some good findings there that came out of that as well. you're right.

Linda Rising (21:52)
Yeah! Yeah. Yeah? Yeah, they didn't find anything.

Brian (22:12)
Right, they thought it was gonna be, you know, it's a skill, it's the right mix of skills that makes it a high performing team or expertise and none of that really had a bearing. Yeah. Yeah.

Linda Rising (22:15)
Get off! And what was interesting about all of this is it sort of all came together because the folks at Google kind of looked over and said, well, look at what these folks at MIT are doing. And they said, maybe we're just not looking at the right thing. And they had talked about this social perceptiveness and what is that anyway? And it was kind of serendipity at about this time. Amy Edmondson wrote a book called The Fearless Organization, and it was about something she called psychological safety. And it was bigger than what the folks at MIT had identified. This has, I am free, I feel safe. Well, that would mean that you could speak up in a discussion and that would make the discussion more, okay, now we would think about what, I mean, what she talked about kind of put a big blanket around all of it and said, hey, I think we might be all talking about this. And the folks at Google said, well, you know, that makes sense. Maybe that's what we're looking for. And how do we do it? How do we do this? So your listeners might wanna just wander out to the Google site because now Google's been very transparent about this. How do you make this work? How do you bring about this psychological safety? How do you get people feel free to talk and to discussion? How do you help people be aware? of what other people are feeling. And they've got a whole raft of suggestions for managers, suggestions for team members, for, you know, and they're really all singing the same song. It's about this awareness of others, feeling that you are safe and that thinking about what other people are thinking. can lead your team to behave in more intelligent way.

Brian (24:41)
That's so, that's awesome. Right, right.

Linda Rising (24:41)
It's kind like a miracle. It's like a miracle. It all just came together. They weren't planning that. know, here at MIT, going one direction, Google going another direction. Here's Amy Edmondson at Harvard, and that it all kind of came together.

Brian (24:48)
That's awesome. You came together now. Yeah, Amy Edmondson is definitely one of my heroes. we've tried to get her on. We tried to get her to come on, but I know that there's layers to get to people like that. so if anyone's listening and has an end to Amy Edmondson, tell her that this is a welcome, this is a psychologically safe podcast to come on. We'd love to have her, but yeah.

Linda Rising (25:07)
Yeah. Well, yeah. think she did go out and talk to Google. I think there's a Google talk about psychological safety. So they did have her come in and give them some ideas, some suggestions or yeah. And she's on to failure now because her book, After Fearless Organization, which was about psychological safety, the one that, in fact, I just finished it is about failure.

Brian (25:44)
Yeah. That,

Linda Rising (25:59)
and their case studies of failures and what can you do about failure and yeah but anyway so she she's on she's she's on to whatever but yeah.

Brian (26:07)
That's awesome. Yes, she does great research and it's it's chock full in her book So I highly recommend her writing to anyone who's listening if that if this interests you Yeah, definitely read Amy Edmondson's work. You'll really enjoy it

Linda Rising (26:14)
Yeah Yeah. So, and if you do, then the story is not over, it's still going, which is, not just Amy Edmondson, but there's a fellow named Kevin Dunbar. This is not Robin Dunbar who did the 150 is kind of the magic number. This is a different Dunbar, same last name, but he did a lot of studies about thinking and. especially in science, how do scientists think? And in particular, he was interested in failure. And you know that as a scientist, you propose some hypothesis and then you test it in an experiment and then you stand back and you do an analysis and you say, well, did this work out or not? And he found that some scientists don't... like it when things don't go well. What a surprise, huh?

Brian (27:26)
Yeah, right.

Linda Rising (27:28)
Yeah, and they just ignore it. They either pretend it didn't happen or they put it in a drawer saying, we'll come back and, you know, we'll look at it later. But some scientists do a really good job of accepting that failure, working with it, and building on it. saying, hey, this is something we didn't think about. Maybe we can, they, you know, and they're off and running. It doesn't slow them down at all. And it turns out that the scientists who have that characteristic, who are able to do that, are scientists in groups. and they're in groups that are intelligent. They're diverse and open. They let everybody speak. They think about what other people are thinking if they're discouraged or not with this bad result. So the characteristics of those groups of scientists who do well with failure is the same.

Brian (28:22)
you

Linda Rising (28:40)
as the groups that MIT identified, the groups that Google is trying to grow. And I think it's really what we want in Agile development. We want groups like that. Not just because we think, intelligence is what. No. We want groups that have that characteristic. We want groups that feel psychologically safe. We want groups that feel free.

Brian (28:54)
Yeah.

Linda Rising (29:08)
to express their ideas. We want groups of people who are aware of what other people are thinking. That's what we want.

Brian (29:16)
Yeah. Yeah, absolutely. That's so cool.

Linda Rising (29:18)
So they're all talking about the same thing. They may be using different words, but they are really, and one thing that we might wanna note right here is that all these different researchers made the same mistake in the beginning. And it's the same mistake organizations make. Is they thought in the beginning that what makes a smart team is smart people. Wrong. Not that you don't want smart people.

Brian (29:48)
Yeah. Right.

Linda Rising (29:53)
But that's just an okay thing to have. You can have a team of very smart people that doesn't have any of these other characteristics that is not intelligent as a group. So I think we really have to wake up and realize, first of all, that we're doing that, that we're valuing IQ or individual intelligence, smartness, you went to this school or you got that particular SAT score. It has nothing to do with that. It's not that there's no correlation, but it's weak, it's very weak. It's much better to have people who have these other characteristics.

Brian (30:33)
Yeah, let me just, yeah. Yeah, absolutely. Let me connect it just a second to maybe someone who's listening who's a Scrum Master or someone like that, right? You might hear this and think, those foolish leadership people, they make these kinds of mistakes. I wouldn't make that kind of mistake. I know better than this kind of thing, right? Well, how much emphasis are you placing on whether your team knows all the details of what they should be doing in Scrum versus... helping them to know and understand each other, communicate with each other, right? How much effort and energy are you putting into those things versus the facts, right? I think that's where it can hit home for us is, these other areas, I think are, as you said, really much stronger predictors of success. And I think as Agilist, that's where we should be pouring our attention into because that's what's going to make the most significant difference.

Linda Rising (31:40)
Yeah. And I think since software development and I've been in it for a long time has had this really strong emphasis on smartness. We like smart people. And it's not that that's a bad thing necessarily. It's that it's not enough. So as a mathematician, you could say necessary, but not sufficient. Not even close. and that all of these researchers all said the same thing, that we thought it was going to be about smart people. We thought it was about IQ, that teams of smart people would be smart. And you and I both know that's not true.

Brian (32:32)
Right, right, right. I've been on some teams with some very smart people that were horrible teams.

Linda Rising (32:35)
Yes. Yes, yes, exactly. And I guess without belaboring it or beating it up, what's happening to me right now is that in reading about all of these different research activities, more and more things start to bubble up. that sort of are like the glue that holds all of this together. And the one that just, it just happened yesterday has to do with brainstorming. So I've been on a ramp to not, you know, I'm against brainstorming because there's plenty of evidence that it doesn't work. They've done experiments, they've said, okay, here's a group of people and they're gonna get together and they're gonna come up with ideas. Okay, we know how many ideas they came up with and whether they're any good or not. And now let's just take individuals and tell them individually, you come up with ideas and then we'll just measure. And the results are always the same, the individuals do better. So I have come up with explanations for that and I'm like, okay, well here's what. Well, I was wrong. Because in the research, it just was like an accident. I just happened to discover it in one of the papers that the groups that are intelligent, the groups that are aware, the groups that embrace failure, the groups that do well also do better at brainstorming. Why is that? Well, because everybody feels free to talk. Everybody feels psychologically safe. Everybody's aware of how other people are feeling and that impacts how they come up with ideas or think about things that other people suggest. So as a group, they do superbly at brainstorming. So it's not the brainstorming, it's the group and how they...

Brian (34:43)
Yeah. Ha

Linda Rising (34:48)
get in a room together and discuss things and share ideas. And so, you know, I hate to say this is gonna be the answer to all our prayers. And of course we still don't, we're still working on, well, how do you do this? How do you make this happen? And I remember a story. It's in fact, it's in one of the documents, I'm trying to think now on the Google website. It's a story of a team.

Brian (34:58)
Hahaha Yeah.

Linda Rising (35:18)
where the team leader tells the other people on the team that he has a terminal illness. And when he did that, everybody else on the team realized that they didn't really know anything about this guy. And they in turn began to share, well, I'm also having some struggles and here's my story. And going through that. cause that team to move up a notch, if you will, to become more intelligent, to be more aware, to suddenly be a little more respectful of how the discussions were. It was just telling stories about what you're going through so that everyone will be aware of how you feel, what you think is gonna be your...

Brian (35:48)
Yeah.

Linda Rising (36:11)
future in the next six months that they didn't have any training or study groups or they just told stories.

Brian (36:26)
They got to know each other as humans. And it's amazing how often we forget that that's who we work with. At least right now, we work with other human beings. And I hope that never changes, because that's where the best ideas, that's where the best creativity comes from. And yeah, it's fascinating, but you're absolutely right. I can see that point.

Linda Rising (36:28)
Yes, exactly. think for me, this is all, it's been really a hopeful journey because in the beginning, I wasn't even sure how it would go. I didn't know anything about the intelligence of groups. And in the beginning, it was all, okay, here's what MIT is doing and reading through, I mean, there were a lot of papers that I slogged through and it wasn't until about halfway through that, I discovered. Project Aristotle and I saw, this really connects. And now all these other things start to bubble up that really make a lot of sense. And of course, that it fits. It fits with Agile. It fits with the Agile message that the big things like that cause you, especially if you've had any experience with Agile, to sort of wake up and say, how do I miss this?

Brian (37:50)
Ha ha.

Linda Rising (37:52)
I should have seen this and it's news to me. So, wow, we're all still learning, I guess, aren't we?

Brian (38:03)
Yeah, I mean, you get presented with something like that and think, I've kind of intuitively known this all along, but I didn't have words for it. And now, now there's a vocabulary that can describe it. And I agree, right? That's exactly what it is. So yeah, you're absolutely right. Well, Linda, this is, this is such a fascinating discussion. And, you know, it's, I had no idea where, you know, group intelligence would lead us, but that it's all just fascinating.

Linda Rising (38:09)
Yeah

Brian (38:32)
the different threads of the spider web and where this kind of ends up. So I know it led you in a lot of places with your research and everything else. I really, really appreciate you sharing that with us and helping us to try to understand a little bit of the journey you've been on and kind of discovering this over the past year or so is what you said.

Linda Rising (38:53)
Yep. And I was going to say, anybody, I know most people don't want to spend the time reading the original research papers, and I don't blame you, that does take a lot of, you know, have a lot of investment in that. But there are some, I would call them sort of lightweight. There's some excellent, excellent Harvard Business Review articles that do a very good job of talking about. what is happening at MIT, what is happening at Google, that kind of a high-level summary, like Harvard Business Review does that like nobody else. And of course, there are TED Talks that Amy Edmondson has given, and there are all the Google Talks, of course, are also out on YouTube. And she has been to Google as well, so you can go listen to what she has to say there. So if you want to dig into this for yourself, there's a lot that you can get without having to read the book or read all the research papers.

Brian (39:57)
Yeah, we'll try to link to as much of this as we can in the show notes of this. So anyone who's listening, if you want to go down one of these rabbit holes like we talked about, maybe we can point the direction and say, hey, try this one. So we'll also include in the show notes some links to some of Linda's work as well so that you can find out more about her and maybe read one of her books as well and see some of the

Linda Rising (40:11)
Yeah!

Brian (40:27)
some of the insights she's already brought to this Agile community. And if you like what you heard here, I know you'll like her books as well. So Linda, thank you so much for making your time. I know it's very busy. Thank you for coming on the show.

Linda Rising (40:41)
It's been my pleasure. Can we close with some good wishes, some thoughts and prayers for all the people who are in Western North Carolina or in Florida who have just been two horrible disasters and are going to be a long time recovering. And that includes my good friend and co-writer Mary Lynn Mans who's in Asheville, North Carolina. So fingers crossed, prayers, good thoughts.

Brian (41:11)
Absolutely. I wholeheartedly concur with you on that. So I agree. Well, thanks again, Linda.

Join us as we explore how Agile in Color is breaking down barriers in the Agile community and empowering people of color through mentorship, support, and leadership. Learn how you can be an ally and foster a more inclusive environment in your own Agile journey.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner is joined by Nosa Oyegun and Luria Lindauer from Agile in Color to discuss the importance of diversity, equity, and inclusion within the Agile community.

They dive into the mission of Agile in Color, barriers to entry and success for people of color in Agile, and the role of allies in fostering a more inclusive industry. The conversation also highlights the power of mentorship, vulnerability, and community support to drive meaningful change in organizations.

The episode concludes with a call to action for listeners to engage with Agile in Color and contribute to the movement for a more diverse Agile community.

References and resources mentioned in the show:

Nosa Oyegun
Louria Lindauer
Agile in Color
The Canary Code by Ludmila N. Praslova, PhD
Email For Details of Coaching with Mountain Goat Software
Subscribe to the Agile Mentors Podcast
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule

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 [email protected]

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.

Nosa Oyegun has over 15 years of experience, and is a seasoned Agile Coach passionate about empowering cross-functional teams, removing impediments, and championing customer-centric solutions. Skilled in Agile frameworks like Scrum and Kanban, she focuses on fostering collaboration, driving value delivery, and nurturing growth for individuals, teams, and executives.

Louria Lindauer is a dynamic enterprise strategist and coach with over 25 years of experience, known for transforming complex challenges into clear, actionable solutions. Certified in DEI strategy, Agility, and Emotional Intelligence Leadership, she helps leaders build vision, empathy, and bold organizational cultures where courageous truth and sustainable change thrive.

Auto-generated Transcript:

Brian (00:00)
Welcome in, Agile Mentors. We are back. We're here for another episode of the Agile Mentors podcast. And today, I have with me actually two guests. I know, you're shocked, right? I only ever really usually have one, but I have two. Two for the price of one today, right? I have with me Nosa Oyegun and Luria Lindauer. Welcome in, guys.

Nosa Oyegun (00:27)
Thank you. Thank you for having us.

Louria Lindauer (00:30)
Yes.

Brian (00:30)
Delighted, absolutely delighted to have you guys here. And I hope I said your names correctly. If I didn't, please correct me. OK, awesome. Well, for the listeners, I did get help before. just so you know. But we're here because both Nosa and Luria work for, or are associated with, I should say, associated with an organization called Agile in Color.

Nosa Oyegun (00:37)
You nailed it.

Louria Lindauer (00:38)
You did. You did it.

Brian (00:56)
And I've known several people that have been in and around and involved with that organization. And I just thought it would be a good idea to have them come on and tell us a little bit about it and kind of help us understand a little bit about the mission and purpose there, what they're trying to accomplish with Agile and Color. So let's start with that. Give us kind of a, if you had to describe it, why does Agile and Color exist?

Nosa Oyegun (01:24)
I would say Agile and Color exists for people who look like us, right? Now, does it include everybody? Yes, we do have members who do not necessarily look like us on the outside, but we all bleed red, right? And so it is a group of like-minded individuals who have come together and said, how do we support our community? How do we support those who are already in the industry? And how do we support those who are trying to get into the industry? Because one of the things that we've realized within the community is there are so many people who might want to get into the industry, but do not have the resources. And so we consider ourselves that resource hub to be able to allow and say, hey, why don't you reach out to this? Why don't you contact this? But that is the sole purpose of being able to mentor and be mentored, just like you always say, Brian.

Brian (02:15)
Love it, love it, thank you. Yeah, that's awesome, that's awesome. That's a great mission and a great purpose. I know, in today's world, I think there's a lot of confusion around kind of the diversity, equity, inclusion kind of whole topic area and maybe some controversy that may be unfounded and just kind of silly. I'm just kind of curious. I mentioned both your perspectives on this. Why do you feel like really that diversity, equity, inclusiveness, why do you feel like that's an important thing for Agilist, for Agile teams, for Agile organizations?

Louria Lindauer (02:48)
Hmm. Okay, so this is one of my loves. do a lot of push-packing inclusion. It's important for no matter who you look like for everyone. I'm sure you love a sport. What sport do you love? Okay, so you go with a group.

Brian (03:14)
gosh, football. Football's my sport.

Louria Lindauer (03:18)
Going with me to a sporting event, I'm not your people, right? But you wanna go with your people. You wanna go have some fun so you don't have to explain why the ball just went out of bounds and why he's down, is he hurt? And I'm asking all these goofy questions, right? And the reason it's so important is because we need diversity of thought. Because in any, like let's think of a group and let's take away the one dimensional just color, which it is very important. That is a important part. It's a part of who I am as a human being. We are multi-dimensional. I'm sure that you're just not Brian. I'm sure you're just like Brian with the glasses. There's so much that encompasses you. know, like me, I'm a mom, I'm a daughter. You know, I'm an agilism diversity, I include them so many different things. And to be able to have that diversity of thought allows us to have cross-functional teams. But the biggest thing is it's a sense of belonging. So I don't have to explain why maybe my hair is like this or the challenges that I embrace in an organization. There's systematic discriminations in almost all organizations. Because that's just where we, as we change, there's still things that were a certain way. And so now what's important is that we start to recognize those. And you may not see them. So like, I'll give you an example. If you came, well, I was gonna say to my dinner, but my family's very diverse. My dad is... white and Jewish. But anyway, if you go to where I am, you know, into my family and we were in a group, I'm the majority. And so we welcome you in. In the organizations, Aladi's organization, was the only, I have a background in South American, the only Black woman, period. And as we move higher, it becomes very lonely. And even CEOs become lonely because they're the only one.

Brian (04:47)
Hahaha.

Louria Lindauer (05:15)
And so when we get together, it's about leadership opportunities, but it's also about that sense of belonging. We can talk about things that other people may not understand. Because this is about people of color as well that come and we can share. It's so important to have a place where we can talk about the things we want to talk about, just like you want to talk about football facts without explaining to me all that stuff I don't understand.

Brian (05:40)
Right, right, that makes sense. Nosa, anything that you would add to that?

Nosa Oyegun (05:43)
would even say that the interesting part about it is, like Loria alluded to, is the fact that we all have the story. And so when we all get into the room, what's that shared story that doesn't create that imposter syndrome? Or just that life experience? I can look at Loria and say, hey, I'm having a bad hair day, and she knows what I'm talking about. And so it's the beauty of having that shared experience and being able to say, it's a safe space. You can talk about your fears and we can lock arms together and make this happen for you.

Brian (06:23)
Yeah, now this is so good. Yeah. Yeah, please.

Louria Lindauer (06:23)
And can I add one more thing is the beauty also, Nosa and I are very different also. So I learned from her. She has a totally different background from me. A lot of people think because we're all per se like black, we come from very different. I have a friend, she's Nigerian and she came here at a very young age and she did not understand why people were like almost, she felt targeted. as a Black person. She was like, what is going on with all of these isms and race? I don't get it. And so that very different experience opens up insights and perspectives that even happen with people of the same color because people know that people are different. We're all different. Yeah.

Brian (07:13)
That's really good. I mean, for the listeners here, I mean, I wanna be real, right? I want us to have some honest discussion here because I think you have to have honest discussion here when we talk about things like this. what you guys said, I think is a really important consideration because we all have our own. kind of biases that we may not even be aware of. And even saying that word, I know there's probably some people who are listening who think, OK, now you're calling me this. No, I'm not trying to place a label on anyone, right? If you can set that aside for a moment, set aside the triggering and just not allow yourself to go to that place for just a moment and just consider, right? The point you make is a great one that we tend to want to find likeness, right? We want to have someone we identify with that that person's like me, so they understand me. They know what I'm going through. They know my considerations. In the past, what I would hear a lot in organizations is this term about they're not a good culture fit, right? Somebody is not a good culture fit. And that kind of language can sometimes, you know, kind of belie something underneath it. It's like, they're just not like us. And, you know, that's the issue, right? That's not a problem that they're not like you. That's actually a strength, right? That's a good thing. You don't want everyone all thinking the same.

Nosa Oyegun (08:47)
Yeah. Exactly. Diversity matters.

Brian (09:01)
You want people who, yeah, that bring different perspectives, different paths, different cultures, that makes us better. So I really hope people consider that, right? And like I said, we all have sort of innate bias. That doesn't mean racism. That just means bias. Right, everyone. I mean, we talk about bias in product owner classes that, you know, like,

Louria Lindauer (09:08)
Yep. Okay. everyone.

Brian (09:30)
a sunk cost fallacy and things like that. That's a bias, you know, and we all have biases whether we recognize them or not. And I think part of the effort in this, from my perspective, is just trying to recognize and overcome those things in all of us, right? Trying to say, where is that boundary line for me? And how do I push past that, right?

Nosa Oyegun (09:32)
Mm-hmm.

Louria Lindauer (09:55)
I would also say there's an awareness that you, my lived experience may be different than yours. And if something happened to me and it didn't happen to you, that it doesn't make it real. So I don't think Brian, you will ever understand the pain of having a baby, but you might just say it's fine. No, it is not. It is you worst pain and you can't describe it. It's something that instead of, if someone feels

Nosa Oyegun (10:07)
Correct.

Louria Lindauer (10:24)
Like if you say something and I feel hurt by it, the always say impact supersedes intent is to listen. And now you become the student. This person also has to speak up and say why that is offensive. And the other person say, it's not really about you. It might be that I got ran over by a bike once and then you say something and it triggers a trauma in me. And so that, you know, when I say, tell people, and if I told no, this is I have to work 150 % as a black woman to, I still, have all these degrees and certifications and years and years. I won't tell my age, years and years, right? And I still, they're like, really? And the other thing, we're talking to a community of practice right now, Agilist, okay? It is how sometimes, how you're in an organization and they're like, there goes those agile people. I know we've all heard it. Like don't pretend like you have,

Brian (10:56)
Yeah. Yeah. Right.

Louria Lindauer (11:23)
point to you, you've heard it. And the engineering are like, man, here comes his out-y'all coach. It's that type of And if you could step into that, it's just a different context is that it's there. And biases are also, we all have them. And sometimes it is a meaning of safety because something happened to us. know, like my daughter is, she's a teenager, she always says like, teens are bad because she saw teenagers doing bad things.

Nosa Oyegun (11:34)
Absolutely.

Louria Lindauer (11:53)
I'm like, but you're a teenager. That's just a bias that she has. culture fit, I heard you talk about culture fit. Culture fit, sometimes, like Southwest did this. Southwest did where they wanted people who were open-minded and had an agile mindset. Okay? They wanted that leadership. If you came in with a fixed mindset, you didn't fit that culture. But however, what you're alluding to is sometimes people use culture fit. in another way. There's always a yin and a yang, right? And so it's the one that is not right where we're like, it's the culture of it. And, you know, and that's called like a halo bias where we look at people. You can have a HR person and they'll hire 15 new people. And I've had this and I'm in the room and I'm like, all these people, they have different skin colors, but they all are you. They all like they're, they're all introverts. They're all this. They're,

Nosa Oyegun (12:21)
way. Yep.

Brian (12:23)
Right. Yeah.

Louria Lindauer (12:49)
cultural values are the same. They care about labels, they care about power and all these things, they wanna be on time. I'm like, you just hired a bunch of yous. So there's no diversity. And so we still can do that. Diversity and equity inclusion is more than just outside and we look indifferent. Cause I can just hire a bunch of me's and you still won't go anywhere. You know what I mean? Yeah.

Nosa Oyegun (12:58)
Exactly. Exactly. Yeah.

Brian (13:13)
Right, right. Well, so I want to ask you guys this because there's a there's I did some research earlier this year and read this book called The Canary Code that was really focused more on neurodiversity and kind of inclusion programs for the neurodiverse. But one of the things that kind of resonated with me that they pulled from that book that was really something that they pulled from more racial diversity, equity, inclusion programs. was that they divided up to saying that what we're trying to identify is that there are barriers to entry and there's barriers to success. And that started to really resonate with me that there's barriers to just getting your foot in the door. And then there's the barriers that once I'm there, that prevent me from actually being successful. So how does Agile and Color really help in those situations? How do they help with barriers to entry and barriers to success?

Nosa Oyegun (13:52)
Absolutely. First thing I would say is just knowing who you are as an individual. Because it's one thing for us to say, hey, I'm an agilist and I'm in this group, okay, fine. But do I go back to the fact that my foundation, I do have the degrees that I need, the certifications that I need, the education that I need, the experience that I need, the community that I need, right? To thrive in this space that I'm trying to get into. because again, goes back to that imposter syndrome, right? You have an interview, you have a panel interview, and you have nobody in there that looks like you. And you wonder, okay, am I in the right space? Am I in the right place? You know, would they even hear? For example, a lawyer alluded to this. I am originally, my family was originally from Nigeria. A lot of times people joke and they say, no, so you don't have an accent. And I'm like, well, because, you know, but people expect. that if you're talking to a Nigerian or someone who was originally from Nigeria, they have a thick accent. Well, I don't. And actually sometimes don't understand people who do, believe it or not. And so, you you walk into a boardroom or you walk into a meeting and I have to literally program my mindset. so Agile in Color, one of the things we do again that being mentored and mentoring is saying, who are you? Right? Take away your...

Brian (15:16)
haha

Nosa Oyegun (15:34)
limitations, take away the fact that even you're an agilist, put that to the side. Who are you? You you're empowered to do great things. You're empowered to succeed. You're empowered to thrive in whatever organization you choose to go into. And so being able to, again, lock arms together and support each other and remind each other of who we are innately first, and then add on that layer of not only do you know your stuff, right, but you're also educated.

Louria Lindauer (15:40)
Okay.

Nosa Oyegun (16:02)
You're also learned and you're in a community. And that's where our group as a community of practice is really essential. Because when you start hearing other people's stories, know, there are times that we have meetings and we're like, this happened at work and this, this, this. And we're like, you're not the only one that didn't know that. And so again, just being able to come together, remember who we are, one. Two, realize that we do have the skill set to thrive in whatever organization. And then three, to say we have a community that is a safe space. And so Agile and College provides those three steps, right, and more. To say you can come together and meet other people. Yes, we may have been in the industry for years and decades, but I always joke about the fact that

Louria Lindauer (16:41)
Yes. Okay.

Nosa Oyegun (16:47)
Only people who are below six feet below ground level stop learning. We all learn every single day. Brian (16:54) Very true, very well said.

Louria Lindauer (16:54)
Yeah. And we also have some very specific programs, like she was talking about coaching and mentoring. I mentor, I'm professional coach. And also we have a coaching, you can be coached. And that's Noza was talking about, that who you are. So when someone is new, I mentor some very young Agilist. And we have them come in, we set them up with a mentor, and they walk through the program. And we're also in a transition where we're rebuilding a lot of things at Algencolor right now, especially with the change in agility right now. And teaching people how can we use the skills that we have as Algenlists and remarket ourselves. But then we walk. This we help them. I've helped them learn how to interview but a lot of it's self-confidence working on imposter syndrome And we do these one-on-one mentors and coaching. We also have something called colorful voices where I think it notes that she was at the one in new orleans was it Was in global scrum gathering and will be at one in munich in may 2025 And so we help people colorful voices is helping people who have never really maybe spoken, you know, they've never done a speech

Nosa Oyegun (17:52)
Yes.

Louria Lindauer (18:07)
And we help them figure out how do you do that and getting seen to help you through the door. And then we also, because I've had that journey of how do I move up and around? That's what the mentoring is so special about. How do we do that? And the frustration of, you know, some people really want to give up that that being down and you hit a ceiling, it can make you want to give up. it's like. When do we transition? So that coaching and mentoring is really deep and we created a strategy and a plan for people and we walked through, but we do coaching and mentoring because you have to do self and you also have to do techniques because you can have all the techniques in the world. But if you don't know your impact and how to be a leader, okay, thanks. I've been led by super smart with tech and they have no emotional intelligence. And it's like, no, thank you. Please don't do that to me.

Nosa Oyegun (18:56)
Yeah. Yeah. One more gathering that we host as well, share your story. And so we bring in like-minded individuals in the agile space and they could be anywhere from non-tech roles, right, to in the tech space, but have some agile component in there and different roles. So not just coaches. So we have product owners, we have developers, anyone. The beauty about that is you get to see someone.

Brian (18:58)
Hahaha. Okay.

Nosa Oyegun (19:24)
who may not have started on a traditional path or maybe has to share their story and their journey. And then what I love about Share Your Story is the person who shares then nominates the next person to share. And so that just builds that community of, yeah, I know somebody else who may have a different path, but has also been through something that is worth sharing. And so, yeah, so several opportunities.

Brian (19:39)
That's awesome.

Nosa Oyegun (19:53)
And again, like Luria alluded to is because we're in that transitional phase in the season right now with leadership and all the things, we're also looking outside the box because we have some organizations that are saying, Agile is no longer relevant. And we're like, hold on. If you have to make a decision, you have to think through the process. It is a process. It's a framework. It's not, you know, just established. And so being able to recreate and reinvent ourselves and say,

Brian (20:09)
You

Nosa Oyegun (20:22)
Hey, do we need to incorporate change in here? Do we need to incorporate AI in here? Do we need to incorporate something else that makes our role more relevant and makes each person more marketable within their organization? So those are things we're considering in this moment.

Brian (20:38)
Yeah, that's great. There's a lot there, I think, for anyone who's listening who thinks, hey, maybe this could be of help to me in some way, shape, or form. I think that's a great job of explaining some of the kinds of ways that maybe Agile and color can be helpful. And maybe that is part of that barriers to entry, right? Just helping people, giving them that friend. friend, right? The kind of support. They can say, hey, it's someone like me. I think your example, Luria, about giving birth is a great one, right? Because I can sympathize, I can hold your hand and bring you a towel. I can do all these things, but I can't know what it feels like. I can't understand it from the same perspective. And if you want sympathy, you're going to feel better. if you get it from someone who's gone through it, right? You're gonna respect that person's opinion more than you would mine, because all I have experienced is the same thing that you have if you haven't gone through it, you know? So that's a great example to kind of make for this. Kind of flip a little bit, because we talked a little bit about how this can help people in some of the programs you guys offer that would help individuals. But I know there's gonna be a lot, you know, There's a lot of people that look like me as well that are out there that hear this and think, you know what, I support this. I want to do what I can do. I, you know, we understand, like, I think there's a lot of us that understand, hey, no one's saying that we need to be the Superman to come in and solve the problem. But, you know, we can ally, we can come alongside and say,

Louria Lindauer (22:05)
Yeah

Brian (22:29)
How can I be supportive? How can I make an impact in this area as well? What can I do? So what would you say to those kind of people who aren't people of color, but would support Agile and Color and want to see it grow and succeed?

Louria Lindauer (22:43)
Bring it on down. We have someone actually on our core team, Matt Carlson. And we are going to have, as we're transitioning, allyship. How you can come in, how you can help. And as an ally, they also get help as well. We need allies, no matter where we are. And we'll have some allyship training as well of what does it mean to be an ally, because we've had that. in the past where we've helped allies with, I really want to help and how do I, how am I an ally? What is the best ways? What do I need to learn? And so it's very important that we have allies where there is with organizations or, you know, it's, it's about that complete circle. You know, we need all people to help, you know, it's like a family. And then we have, we have extended, you know, like there's, have the allies of, you know, agile in color. I remember When I was a kid, would walk down the street and then it was safe. Okay, so please people don't call the police on my parents. They're too old for that. while I was like nine years old, I could walk to the store, it safe. But along the way, there was people who were always watching me. They were on the porches and they'd be like, bring me something and bring me this. But they watched me all the way to the store. And I came back. Those were my allies, my family allies. So it takes a community, it takes a village to...

Nosa Oyegun (23:44)
You

Louria Lindauer (24:09)
create change and to do things. So we more than welcome allies. And Matt is an amazing ally. Also, the important part of allies is that they give a perspective that we may not see. I always say that sometimes when it is my issue, if it's really close to my heart, I look at people like a tree and I'm, you you can see my whole tree.

Nosa Oyegun (24:15)
AMAZING!

Louria Lindauer (24:34)
But if I'm on that issue, I see the veins in the leaves. Like I'm not on the branches. I'm all the way in the veins. And it's the only part I can see. And so sometimes we need those different perspectives to be able to get it like, never thought about that. And that has really helped us a lot with, did you think about this? Or maybe this as well. And we're like, yeah, we never thought about that. And so that helped we educate one another. What do you think, Nosy? Yeah.

Brian (25:00)
That's so awesome. That's so awesome. Help me then just I'll throw one last thing you guys direction. In thinking about kind of where we are today and we've come a ways but we have a ways to go still. What do you see as sort of the biggest challenges today, the biggest hurdles that we've yet to really

Nosa Oyegun (25:01)
Yeah, absolutely.

Brian (25:30)
overcome that's really holding this back.

Louria Lindauer (25:36)
What do you mean by this? This? do mean this?

Brian (25:38)
Well, holding diversity, equity, inclusion, holding people...

Louria Lindauer (25:42)
You can. That's a great.

Brian (25:44)
barriers in either sense of the word. what are we not doing very, especially in the agile world, like what are we not doing very well right now that we really need to do better?

Nosa Oyegun (25:57)
Now, Brian, how much time do you have? That's the question. So, yeah. So here's what I'll say. And this is the NOSA version because again, that experience of, we have a different experience based on our backgrounds, right? So, and I think Loretta alluded to it earlier saying, well, my background, remember people saying minority. I'm like, who you calling minority? I'm not minority because where I'm from, I'm not minority, right? And so when I hear...

Brian (26:00)
Hahaha!

Louria Lindauer (26:01)
I'll say we are out of this.

Brian (26:24)
Right.

Nosa Oyegun (26:26)
even the term people of color and I'm like we're all a color you know that and this is what I love about our t-shirt right because it's a spectrum right and so going back to your question there is beyond the outside beyond the exterior the question becomes how do we unify and support each other like truly genuinely support each other because everyone always brings something priceless to the table. There's a reason why we all have a unique thumbprint. What I'm great at and what I excel at and what my strengths are, most likely not Loria's strengths. And so if I bring my strengths to the table and I am vulnerable and bring my weaknesses to the table as well, and my weaknesses are Loria's strengths, then we lock arms together and we make this happen. And so two things I would highlight is one, being vulnerable to say, I really don't understand this. Can I get some support? Can I get some help? Can I get some partnership? And then two, that encouragement of not saying, why don't you know this? You've been in the industry for five years. You should know this by now. There's no need to shame each other. Neither is there a need to say, because Brian is of a different hue, he needs to be in the C-suite office and I need to be in the back. No, it needs to be, we all bleed red. let's get out of our mindsets about this whole external thing and let's begin to truly and genuinely support each other as humans. One of the things I love, friend of mine always says is she's like, let's just be human. Let's just be kind and let's be there for each other because at the end of the day, there's so much going on in our world, right? But if we can truly be human and truly say, how can I live in a space where I can support someone else? And then how can I be vulnerable as well, regardless of who am in my career path? We can make things happen.

Louria Lindauer (28:26)
I have to, I love that note. I love the vulnerability because it's really, it is so important in the agile world and it's sometimes harder for organizations. And it's really hard for the minority or a person of color to do that because they don't want us to do it. They don't, sometimes it's just hard to be yourself because You know, there was a time when being LGBTQ or black, was frowned upon. I couldn't wear my hair like this. She couldn't wear her hair like that to work. There was a time where my best friend's a guy, he couldn't wear a beer. You can wear a beer because you had to be clean shaven. And the biggest fear, and I love this question, is people don't want to change. People like the same old same old. I've seen Agile is so hardcore Agile and they come in with all their Agile speak and they're doing, and they're not listening to the team that's right in front of them. Yes.

Nosa Oyegun (29:17)
I job police.

Brian (29:19)
Yeah.

Louria Lindauer (29:20)
They don't see, they're not aware, they don't have group awareness of what is happening and the impact. They go to these classes and grade and they come back and they try to just push. You don't wanna push, you wanna pull. You want people to be coming towards you so they're pulling. They're like, okay, okay, okay. I don't wanna push all my stuff on them. I want them to be pulling me towards. And so one thing right now with diversity, people don't want to change. It feels safe. If I was the majority and you told me I had to change and I'm like, why? know, sometimes that's hard when you're comfortable. So people are like, But now, thank goodness, I can actually look at people who are not my same color and say, buckle up, buttercup, because now you get to feel what I feel because that's so important in the agile community. It is

Brian (30:10)
You

Louria Lindauer (30:17)
taking your experience as an Agilist today and how it feels and saying, this is my experience, I wonder if someone else feels like that. Really taking the time to do that. And I think we do it better in Agile communities where we do the doing and the being. I'm not saying all Agilists, okay, but when we really embrace, the being is so important because sometimes we're technically strong and we gotta get better at that leadership mindset of emotional intelligence.

Nosa Oyegun (30:34)
I'm going to go

Louria Lindauer (30:47)
and being able to say, we need to change. Because if we we're going to get left behind. But in the same thing, know that you might be hurting someone. And to be curious, we need to get more curious, less defensive, and listen. Like, shut up and listen. Just be quiet. Listen.

Nosa Oyegun (31:05)
Exactly. Yeah. I actually coin. No, I was going to just add this real quick. actually coined my role as an agile coach as a therapist. And it's interesting because my colleague and I joke about the fact because I have a master's degree in psychology and she says, see, I wish I did that. And I say this to Laura's point is a lot of times people just want to be heard. And in addition to that is not just being heard. But what are they not saying that they're really saying by being quiet?

Brian (31:08)
I was thinking that too, the whole time. Sorry, go ahead. Ha

Nosa Oyegun (31:36)
Listen for that as well.

Brian (31:36)
That's so good, that's so good. Yeah, and I was just gonna say that it sounds like maybe we just need to all start by listening a little bit better to each other and seeking first to listen rather than to be heard. And if we can do that, then it's so much easier to understand each other and understand and help each other, right?

Nosa Oyegun (32:00)
Absolutely.

Louria Lindauer (32:01)
Yeah, let's lock arms and then let's take action that is agreed upon between us. So sometimes in the lead is called I can leave from behind and doesn't and I'm leading from the front, but we're still there or we're leading side by side. And to listen that maybe Brian, you're the one I need to listen to for this moment. And I'm just still there supporting you. It doesn't matter. We're all leaders. So how do we so that we all get what we need because a lot of people, awareness is great. Please start there first. Please don't move into action if you're not aware. Like go back. But sometimes we just stick, we get stuck in awareness. It's time now for action and it doesn't have to be this huge thing. Sometimes just a mentoring program and a hiring process instead of hiring a bunch of people of color and then they're now in this environment that kind of is awful and then the retention rates. We see that all the time. But having a mentor when you come in to help you and also work on the actual change in the culture, because maybe it is kind of, you know, messed up because sometimes a lot of companies, and I know this isn't your company if you're watching this, they are about money. So that is they won't mess with this very toxic, awful environment. And I'm not talking about diversity. can conclude I'm talking about for everybody in there because it's a money, moneymaker. And so then it has this toxic environment. And so us as Agilent,

Nosa Oyegun (33:14)
Yes.

Louria Lindauer (33:28)
can't help. And that's why at Agile and Color, we're starting to transition to how we can use our skills in project management, change management, because our skills are all the ones that they use anyway. just start. If you're looking for a job and you're an Agile coach, look now for change management, else? Project manager. They just change. And then if you look in the thing, job descriptions. just.

Nosa Oyegun (33:36)
Exactly. Yeah, very fluid. Mm-hmm. Just changed the title.

Louria Lindauer (33:52)
hype up that resume with more change management and those type of things because they can't get rid of that we need to do things quicker and faster and be human. They'll never get rid of that.

Brian (34:04)
That's awesome. I love the phrase too that you said there earlier, just about like it's a time for action. And I think that's a great way for us to kind of wrap up. if the people out there, if you hear this and agree, hey, it's time, I'm ready to act. I'm ready to not just stand up by the sidelines. Then what we're gonna do is we're gonna put a link in our show notes that will put you in touch with Agilent Color. And I encourage you, if you're a person of color or if you are interested in being an ally in some way for Agile and Color, I encourage you to reach out to them. They're a great organization. I'm really happy to have you guys on to share some of that vision and to spread the awareness a little bit of it. I can't thank you enough. Thank you for making your time and coming by and speaking with us.

Nosa Oyegun (34:57)
Thank you for having us. Thank you for having us. And for the platform that you all do here, it's amazing just to see not just the topic, but the diversity of the topics as well, Brian. So thank you.

Louria Lindauer (34:58)
Thank you.

Brian (35:10)
Thank you so much.

Louria Lindauer (35:10)
Thank you.

Can Agile tools really teach you Agile practices, or are they just supporting players? Join Brian and Steve Spearman as they unpack the myths surrounding tools like Jira and discover why the process should always come before the tool.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner and Steve Spearman debunk common myths about Agile tools, with a special focus on Jira. They stress that tools are not a replacement for Agile principles, and the process should guide the choice of tools, not the reverse.

The conversation dives into how Agile tools can enhance transparency, why communication is key to effective Agile practices, and the importance of adapting tools to fit unique team workflows.

References and resources mentioned in the show:

Steve Spearman
#43: Cultivating Agile Team Culture in a Virtual World with Richard Cheng
#29: Influencing Up with Scott Dunn
#71: The World of DevOps with Carlos Nunez
Jira
Miro
Mural
Trello
SAFe
LeSS
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe 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 [email protected]

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.

Steve Spearman is a Certified Scrum Trainer® and Agile coach, passionate about helping teams thrive, drive business improvements, and master the art of managing change. With expertise in Agile training, scaled Agile, and leadership, Steve empowers organizations to navigate their Agile journeys smoothly and effectively.

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 good friend of mine, a mentor of mine, Mr. Steve Spearman is with me. Welcome to the podcast, Steve.

Steve (00:14)
Thank you, Brian. It's great to be here with you. Nice to see you.

Brian (00:17)
Nice to see you as well. Yeah, Steve helped me out when I was trying to become a CST and I got to learn a lot from him, watching him teach his classes. So he's a pro. He's a CST, he's a coach and trainer and if you're interested, I recommend his classes. I think he's an excellent trainer and would have no hesitation sending anyone to one of Steve's classes. We wanted to have Steve on because we had this topic that got, actually, this is a listener suggestion. So we're always happy to take listener suggestions. And this is one that one of you sent in saying that you wanted us to kind of dive into and discuss a little bit about myths that are out there about Agile tools. So Steve, what does that mean to you? are some of the, is there a main kind of myth that you? you've heard more often than others about Agile tools.

Steve (01:16)
I think, Brian, the one we hear all the time, right, is this one that essentially Jira is Agile, right? And we're like, well, Jira is a very popular tool for people to use with Agile. It's might or might not be like most of us who do this. That may not be our favorite, honestly, but it is very popular for some pretty good reasons. So that's, I think, the most common one. And then just the idea that somehow it gets to the confusion people have about being a methodology and stuff, right? That essentially, if you just would implement the tool, then you'd be doing Scrum well, right? And that would be the important thing when in fact, I think most of our recommendations would be a little bit the opposite of that, right? Which is to come up with your own approach to doing things in Scrum and then maybe figure out a tool that helps you with that.

Brian (02:06)
Yeah, I agree. I've heard that quite often. And I've encountered organizations in my career where I'll ask them if they're Agile or if they are familiar with or no Agile. yeah, we have JIRA. OK, well, not quite what I was asking, but I appreciate the sentiment. But yeah, I mean, I agree. There's probably some mixed reviews on that as a tool.

Steve (02:24)
Yeah.

Brian (02:36)
I mean, personally, I'll say I've used it to run, you know, Agile organizations before. I'm not a hater of it. I think it's fine. I think it works. I mean, I don't know what your opinion here is, Steve, but people often ask me if there's a tool I recommend to kind of run projects and. You know, my standard answer is there's not one that I think is better and outshines all the rest. I think they all have their strengths and weaknesses and you just kind of have to tweak and adjust them to make them match, you know, your process. But that's the key, right? Is that process over the tool.

Steve (03:17)
Yeah. I've, you know, Jira I think is popular for a lot of reasons. One is, usually it's about half the per seat cost of a lot of the other ones. And so that for a lot of companies right there, that's that's a pretty big factor thing. I liked about it. Maybe similar to your experience, Brian was that if you're a little bit more of a techie, it's pretty programmable. You can go in and you could tweak it and you can make it do all kinds of things. And so that's maybe it's strength and it's weakness that it takes a little more investment, but you can do quite a bit with.

Brian (03:47)
Yeah, I agree. It is pretty flexible. The main thing I try to tell people who use it and are asking about, this going to be viable? Will it work for our purposes? The main thing I think they have to understand is the history of it. The Jira is really a bug tracking software. Well, let me be clear. It was created as a bug tracking software, right? Right.

Steve (04:12)
Yeah, ticketing system in general, yeah.

Brian (04:15)
Right, a ticket system. And when you know that, and then you get into the nomenclature and you look at the layout of how everything is within it, that makes sense. can see, cause you know, like the standard thing there is an issue, right? There's different issue types, but the standard thing is an issue. Well, that's because it was meant to handle support issues.

Steve (04:35)
Yeah. And also the, you know, we commonly use the word tasks, of course, in Scrum, not an official thing, but a very common thing we talk about. And Jira speak is subtasks. And that's just history again, of, know, where it came from. And, you know, a long, long time ago, you had to have a plugin to Jira to do Agile. It was originally called, I believe, Grasshopper many, many years ago. And then they ended up just calling it like Jira Agile for a very long time. And then as...

Brian (04:57)
Yep.

Steve (05:04)
it became a bigger and bigger piece of their market, they just kind of wrapped it all up in JIRA now, I think.

Brian (05:09)
Yeah, we both been around long enough to have been part of those days. So I remember those very well. Yeah, I mean, like I said, I think JIRA will do a fine job for you if that's what you're with. wouldn't, you some organizations using it, I wouldn't say, by all means stop and use something else. I think you can make it work. I think you just have to look at it and say, all right, I understand this is based on this. So now I just need to configure it and adapt it. really for the process we want to do. And I know from my standpoint, I've used it multiple times where when you configure it the right way, it will handle things the way that you, at least from my perspective, the way I usually think is the right way to implement it with a team or an organization. So it works. I can make it work. It just takes some tweaking. I guess for mine, but yeah, it's not Agile. It's not being Agile just because you're using Jira.

Steve (06:11)
Yeah, and it's kind of the good and the bad thing about tools. think people like them because, you know, I can assign people tickets and things like that, you know, and so like, you know, people, it's clear who's got things and stuff. That's also a weakness though, too, because it, you might say, all I have to do is assign it in the tool and I don't have to talk to you now. I just say, look, you, I signed you this ticket or something. And that's not great from my perspective. And then the other one is that when you, when you, change states and things in the tool. That lets everybody know where things are, and that's good, and it gives you tons of reports and things, and people like those. But it's also less visual than a lot of us are, which back in the day, we liked sticky notes on a board. I that was the thing. That was the thing. And so what I'm leaning toward myself a little more these days is tools like Muro and Mural and so forth that are very visual, and they're often sticky note-based kind of things.

Brian (06:55)
Yeah.

Steve (07:09)
And that allows you to do a lot of the stuff we used to do physically, but they don't have the same reporting capabilities. And so that's where we get these trade-offs that I think we're going to see with these tools.

Brian (07:22)
Yeah, I agree. I agree. Yeah. I'm, I'm, I'm the same way. And in fact, you know, when I said that earlier, someone asked me what my favorite tool is, you know, I said, my default answer is usually I don't have a favorite, but, if they push me, what I'll tell them is my favorite is just no cards or post-it notes, you know, like that's really, that's really what I, I have found works best. But, yeah, something like Miro or mural, I think is a, is a great, kind of virtual replacement for that. Cause it's just so open. and you can configure it however you want. It's not going to pull a report for you. You have to understand that. But it is the equivalent of having a virtual wipe.

Steve (08:05)
Exactly. And that's just, it's kind of a halfway physical feeling thing for our virtual world, which I think is helpful. Another interesting thing that I haven't played with a lot myself is that I know now in Miro, a sticky note in Miro can now be tied directly to a ticket in Jira. And so effectively you could have like the backend framework of Jira with a pretty front end on top of it or something is kind of how that looks like to me. So

Brian (08:23)
wow.

Steve (08:32)
I think that's got some promise maybe to give us both that physical thing that some of us miss while still having that reporting structure that a lot of our companies kind of want.

Brian (08:41)
Yeah, that's awesome. Yeah, that speaks to what you were saying earlier about that it's highly configurable. can make it do a lot of things. You just have to get into the guts of it a little bit.

Steve (08:52)
You know, another thing about the tool market here, know, Brian, I was just looking this up, not like I knew this, but apparently it's a $5 billion market this year, Agile tool, and it is projected to go up to 13 in the next 10 or 12 years. So it's serious money. And this is why there are so many players now, right? I mean, the number of tools out there now is just, I've lost track of them. I know it's easily 20 plus tools out there. Now there are...

Brian (08:57)
Haha.

Steve (09:19)
Certainly the most common ones that we think about, Jira is probably number one. Asana comes up a lot. Rally is a long time one that comes up quite a bit. Interestingly, one of our biggest ones from years ago that did such great reporting out on the network for us and great Agile materials was version one. It was a super, super popular one.

Brian (09:43)
Yeah.

Steve (09:45)
And when you look now, they are a fairly small player percentage-wise in the market. So there's been a lot of shifting here. And of course, Microsoft shops tend to go toward Microsoft tools. And so there's that factor that goes on here, too. So it's not trivial to figure out which tool you would want to use here.

Brian (10:02)
Yeah, that often drives a lot of even discussion in the classes, I know, from people who say, what do you, you know, they'll bring up a term like feature and say, what's, how does Scrum define? Well, Scrum doesn't define what a feature is, you know, like that's, that's a term that comes from your tool. And, know, that your tool might have a definition for it, but you know, Scrum doesn't. So, yeah.

Steve (10:23)
One of the challenges I think is also that because scaled Agile has become such a big factor these days, almost all the tools have adopted their terminology. so terms like epics and features and things, most of these come from scaled Agile. And if you're doing scaled Agile, that's great, right? If you're not, it can be a little confusing. So for example, I think it was, Mike Cohn maybe, who said that epic, he famously defined as being a story too big to fit into a script. That was sort of the definition of an epic. And now in most of the tools, an epic is something giant that you have a handful of in three months or something. So yeah, there is some terminology confusion out there now as well.

Brian (11:16)
Yeah, which may have all come from just the tools. You hit on something a little bit earlier that I had as one of my kind of common myths here around tools. And that was that these Agile tools replace the need for just the typical communication that we have. Because as you said, I can assign something to someone else. that way, I don't have to talk to them. I just put it in their queue. And it's there. And I think that's a huge myth here with the Agile tools is, you know, my, my, my goal with any kind of tool, whether it's a software tool or whether it's a, a template or something that I'm using for a specific thing, like story mapping or whatever, my, my goal for any of those things is that it drives conversation, right? That it is an encourager of conversation, not that it is something that takes away from or detracts. from conversation and communication. So I think that's a big myth sometimes is that people, even if it's unspoken, right, there's just sort of with some people an assumption that because the tool communicates and because the tool can communicate between people, I don't have to actually talk to anyone. And that's that couldn't be further from the truth to do Scrum well.

Steve (12:33)
I think it gets us to another subtle thing in the scrum that you know scrum that could say more clearly maybe than it does. But that is shown as a good pattern in our pattern site, you know, the one called scrumplop.org. The idea that we should swarm as teams, you know, is something that I think a lot of us feel is a really important concept. And swarming is this kind of strange idea that says you know, don't give everybody their own work item and then just say disappear, go do it, you know, good luck. Instead, we try to work more closely like teams on the same items, divided up, work together closely. And this of course involves a lot of communication, a lot of needing to talk to each other. And so sometimes people say, well, can we just send out a Slack message or something, you know, every now and then and say, hey, you know, I'm done with mine. You can, but I think it's sort of missing the the really cool back and forth of a true swarming culture where it's like, hey, is anybody ready to pick up a piece of code and run the testing on this one? I'm gonna move on to the next one. Swarming was this idea of doing things in short cycles and gets into issues of test-driven development and things like this. so none of the tools really help you with that concept at all. And they may even hurt you with it little bit, in my opinion.

Brian (13:49)
Yeah, absolutely agree. And I'm absolutely on board with you. I think that's such a vital component of it. I tell people in classes, you know, I know sometimes people get a little frustrated with sports analogies, but I tell them, you know, Scrum is a sports analogy at its core. You know, it's a rugby thing. the other thing I kind of think about is if you've ever gone to see, and I know lots of us have done this in our life, but you've ever seen a kid sport kind of team sport. If you ever stand on the sidelines of a kid's soccer or most of you out there, most of the world would say football. But you know, if you ever stand on a side of a field like that, what the coaches are constantly yelling at the kids is talk to each other, right? Communicate, talk to each other. And they recognize, you you recognize in that kind of a team sport how important it is to, you know, call for the ball or or just let people know where you are or where you're going. And that same thing is what we want with our Scrum teams. We want people to be able to just constantly talk to each other. So you're right. I think sometimes the tool might actually get in the way of that communication and just could create some communication problems. Which tool are we talking on? Which tool do I look for for that kind of a conversation or whatever? And it just can get lost in the shuffle sometimes.

Steve (15:13)
You know, the rugby analogy is such a core one for us, but it's getting to be kind of old history now because the whole rugby analogy came out of this original lean paper, right? Long, long time ago. And the reason they chose rugby, you know, is one of the reasons they chose rugby. Rugby is such an interactive thing. So unlike American football where, you know, you run down the field and you can, you know, you can only throw the ball once and then you run and try not to get tackled. In rugby, you throw the ball back and forth constantly. Continuous interaction and basically the guys from Toyota said look we got to learn to treat our teams like rugby teams When they're on the field don't be on the sideline yelling throw it to Brian You know let them figure it out themselves, and that's the whole concept of a self-managing team Which you know is a really big concept for us in scrum and one that a lot of companies struggle with

Brian (15:54)
You By the way, if there was anything being yelled with my name on it from the sideline, would not be throw it to Brian. It would be don't throw it to Brian. That would be the response. Yeah, absolutely agree. What else, Steve? What other kind of myths have you heard or do you commonly hear about Agile tools?

Steve (16:24)
I think one of them is the idea that there is a right tool because there are real pros and cons to all the tools and some of them are much more advanced than others and yet some of them are a lot more expensive than others. Some of them are tuned for people who work in Microsoft shops. Some of them are tied to particular tools like GitHub or something like that. So figuring out the right tool is a non-trivial exercise, I guess is what I would say. And especially if you're going to wedge yourself to a tool, I think doing some prototyping, some research. The good news is the vast majority of them have free versions. You can go out and try. I often get asked things like, are you going to teach us Jira in this class or something? And the answer is no. No, I'm not. It's just one of 20 plus tools. But the other thing is that The good news is tools are a lot simpler than Scrum and Agile are. Scrum and Agile are tricky, they're subtle, they're hard to understand. They're a lot about humans and interactions and patterns and these tricky things. Tools are relatively straightforward and there are free videos on how to use Jira out there. There's a public version of it you can go get and it's true for the others too. So anybody who's really looking for a tool, that'd be my recommendation. Go out and... Find a few of popular ones, go check them out, get a free version, watch some videos. I don't think you'll probably find you a class for that.

Brian (17:54)
Yeah, I agree. I mean, and if you do, know, you know, again, don't want to make this sound like we're only talking about Jira, but I know for things like that, I've seen, you know, meetup groups that are dedicated to those purposes that you can find on like meetup.com or other things where you can, you know, maybe go once a month or so and learn something about it for free. So there's lots of stuff like that that's out there. But yeah, I absolutely agree that, you know, As I said, I don't recommend one specific tool. And I think the thing that's kind of really important there when you're selecting a tool is to know what your process is first. Don't get the tool to set your process, find what your process should be, and then find the tool that's going to fit with that. It's the whole individuals and interactions over processes and tools. We don't want the tool to drive what we do. And unfortunately, I've been a part of several organizations where, hey, we use this tool and the tool only works this way. So that's the way we work, whether it's right or wrong for us. And that's just a terrible way going about it.

Steve (19:03)
Yeah. And unfortunately, most of the tools do force you to some degree into their approach, right? Because there is a struggle, I'm sure, for toolmakers between you could make it completely general, like here's some sticky notes, just go do whatever with them, you know, which is kind of what you do with a Miro or a Miro board. But most of them have tried to make it more, you know, you do this and then you do this and then you do this and it kind of leads you through it. And that seems like it would be helpful, right? But at the same time, it means they've already decided that the right sequence is to do this and to do this and to do this. And so just got to watch out for when is the tool prescribing your approach and when is it there to facilitate your approach.

Brian (19:50)
Yeah, I agree. I'll tell you another one that I've heard quite often that I always kind of makes the hair on my spine kind of stand on end is when people seem to take this approach that the Agile tool itself is going to teach them how to become Agile. You know, it's kind of akin to the idea of because we have Jira, we're Agile or some, you know, fill in the blank or whatever tool it is that you would be using. But yeah, I've seen different teams or organizations that take that approach of, well, we're buying this software. And so we'll learn by using this software how to be Agile because it's an Agile tool. It's an Agile software. So everything we need will just be, we'll come by osmosis because we have this tool in place. yeah, I found that to be just a terrible approach. If you don't have some kind of a some guide, right? If you don't have somebody to guide you through that in any way, shape or form, then you're lost in the wilderness. You just don't have anyone to help you find your way. And the fact that you have a tool that could be useful doesn't mean it's going to teach you how to be useful, right? You have to know, knowing Agile is not knowing the tool.

Steve (21:11)
It's like, imagine going to a Ferrari dealer and deciding you're going to buy a Ferrari. And you've driven a Honda Civic, so you feel pretty comfortable with driving. And they give you a 10-minute overview of the dashboard of the Ferrari that you just purchased. And they say, I hear you're planning on racing professionally next month. Good luck with that.

Brian (21:17)
Right.

Steve (21:37)
And because I can sort of drive the car, I can therefore win races, you know, at the, no, right? No. So now we both are going to be a little biased here as trainers, obviously, but I think we pretty strongly feel like without somebody to help guide you through the subtleties of things like Scrum and Agile thinking, you may let the tools dictate and that's not the intent at all. It should be your team comes up with what makes your team be amazing.

Brian (21:48)
Right.

Steve (22:05)
And we own our own processes in Scrum, right? That's a key concept is that Scrum tries not to dictate processes and it wants you to continually evolve them. And so even the thinking that says there's a right way to do it is actually incorrect Agile thinking. so, yeah, tools are not gonna be a lot of

Brian (22:24)
Yeah, I agree. We might be a little biased because of what we do, but you know, I like your analogy. I'll give you another one. if you are just because you buy a parachute doesn't mean you know how to skydive, right? And no one would would buy a parachute and think, I know everything. Just I'll just use it and I'll learn how to do it because I'll jump out the plane and you know, I'll learn how to skydive. Well, no, you go through training. figure it out, you probably do a lot of tests and things, so that by the time you get up there, you know exactly what you're doing. you've gone through all the safety checks and all those other kind of things. Nobody would see those things as being synonymous, but somehow we do that in the Agile community sometimes, as we see the tool as synonymous with knowing Agile.

Steve (23:12)
It's a really good example, though I like the parachute. I have never parachuted because I find it terrifying. But if you were going to be a skydiver, this is an area where there is a high cost of failure. It's like one of these things where a certain kind of failure you can only do once because you won't have a second opportunity. And so one of the things that is kind of an integral idea in Agile thinking is that we like to make

Brian (23:18)
Neither have I. You

Steve (23:41)
experimentation and failure inexpensive. And so one of the whole concepts of why we often encourage things like short sprints and scrum is the idea that we want you to feel free to experiment with your processes and to make mistakes. And I'm sure many of you out there have heard the fail fast thing we say all the time, right? And all of this comes out of this mindset of making failure affordable and learning part of the culture. And so all of that is very different than any of these kind of instruction-based follow a tool sheet, follow a standard methodology of Agile or something. None of that is really the right thinking according to the way the Agile Scrum people see the world.

Brian (24:26)
Yeah, I agree. Any others that have crossed your path that you would call out?

Steve (24:33)
You know, it's really hard to avoid the thousand pound gorilla here, which is safe, because safe has so dictated the tools and things that you just have to think through that. I don't want to get us off into scaling, because that's obviously another very large conversation of its own. I have come to think of safe this way. that scaled Agile is as Agile as many large companies can tolerate. Which is to say, it's not my favorite, but it is very prevalent out there. And so, you know, in some cases, you're not going to have a choice, right? Your company will have dictated a thing, whether it's safe or whether it's whatever it is. And just be aware that that decision is also reasonably tightly tied to these tools and things because... You know, you can get a really nice lightweight tool like say Trello, which is, you know, even free sometimes still. And that can be perfectly acceptable in, you know, nice small scrum team environments. But if you're going to do, you know, giant, you know, release train planning exercises, and you want the ability to put all this stuff into tools, then that will constrain you to a certain class of tools. Now it's a lot of them these days, but just be aware that how you choose to approach this and how heavy of a method you use. will also impact your tool choices.

Brian (26:00)
Yeah, I agree. I don't want to get, I know we're not going to dive off into the pros and cons of safe, but the kind of picture in my head that I always think about with safe is it's kind of like one of those Swiss Army knives that has a million different blades and attachments and things in there. It's designed to solve any possible problem. that you could encounter in that arena. you know, just like when you use a Swiss Army knife, you don't open all of them up and say, all right, well, I got to try to use them all at once. You find the one that you need and you use that one. So I don't think it's a problem to have the choice to use these various things. And when I've talked to really, you know, lifelong, safe trainers that really are successful with this, I find a similar attitude from them that it's not intended for you to have to implement every component. It's intended for you to find the things that fix the problems that you're encountering and then implement those things. And if you start to encounter other new problems, well, there's other parts of the framework that you can implement then that will help solve those issues for you. And I think that's one of the mistakes people make with SAFe sometimes is that they just You know, they take the whole, it's all or nothing. And while Scrum does say, hey, you have to implement all of this or you don't get the benefits of it, SAFe, I don't believe says that. At least I haven't heard trainers say that who teach it. So, yeah, yeah.

Steve (27:43)
It's more like a smorgasbord effectively, right? know, if you know different choices and maybe it's worth saying a word about why that is compared to because Scrum tries so hard to be a minimalist framework that it's sort of like saying, you know, I could choose not to eat vegetables and you know, that could be a good choice for me and the answer is no, that's not a good choice for you it turns out. You know, so Scrum, because it tries to tell you so little, it's basically telling you the stuff that is basically essential. You you just can't get along without it. So it's a super minimalist framework. Some of you, I'm sure, are familiar with what happened in the last version of the Scrum Guide, where, you know, typically, like with SAFe, when they add a new one, it gets bigger and bigger and bigger over time, right? And they add more and more details. And that's what people love about SAFe, right? You can go open up a page. and click on a keyword and open up another massive page of exactly how to do everything. And Scrum has taken the exact opposite philosophy to make it the most minimal framework they could. And they actually went from 18 pages to 13 pages in the last version of the Scrum Guide, taking all of the advice out, basically. And so we're just looking at two very different philosophies here. So Scrum is a minimalist framework. SAFe is the... I guess the Swiss army knife, if you will. I would like to say one comment about a Swiss army knife. I used to carry those many years ago, but essentially you have every tool in them and none of them are great, right? So every one of them is basically a tuned down version of the tool. So yeah, there's a corkscrew in there. It's not a very good corkscrew. And yes, there's a screwdriver in there. It's not a very good screwdriver.

Brian (29:06)
Ha ha ha.

Steve (29:29)
So I think sometimes over time we start to learn that you should have the right tool for the right job and not try to get by with the Swiss Army.

Brian (29:38)
Yeah, always whenever I saw, you know, whenever I would see a Swiss Army knife that would have the the kind of saw component of it, I always think, you know, it's it's it's it's, you know, two inches, three inches long. What kind of tree am I going to saw through?

Steve (29:53)
you have to be desperate, right? This would be like, I'm cutting my parachute cord or something, but.

Brian (29:57)
Right, exactly. Exactly. Well, I'll throw one more and then we'll we can call this. But there's one that I've heard that I just thought was I don't hear this as often, but I have started to hear it more. And that's just sort of it's kind of an attitude. It's this attitude of, hey, we're having a problem with and seems specifically around transparency. Right. The team is not being transparent. We're not having much transparency into how the work is going on. And so sometimes I've heard people kind of take this attitude of, well, you know, we're gonna implement this tool. And so by default, we're gonna increase our transparency, because now we're using this tool. And I would caution people on that as well, say that that's not true at all. You know, it's the old phrase we used in computers, you know, way, way back when I was in elementary school was garbage in garbage out. And I think that applies to our tools as well, you know. We can get greater transparency through a tool, but it takes the right input. It takes the right effort. And you could still have the attitude of, I'm going to obscure the way that the work is really happening and do that through any tool. So the tool itself, I don't think it's going to do that. The tool could help you with it, but you have to deliberately seek that out.

Steve (31:21)
You know, I, it's such a mindset for me, this concept of things like transparency and how that relates to how we work as a team and swarming concepts and all these things kind of come together to make scrum a really an effective thing. And the problem sometimes is when you try to force things, it has the opposite effect. I'm, don't disagree with the scrum authors very often, but I very much do with what they did with the daily scrum, you know, and the daily scrum. used to have the three questions, And the three questions, you know, what did you do yesterday? What am I going to do today? You know, do I have any impediments? And then they made it longer. They added more words to it to try to clarify things, which was just more structure effectively. And then finally, in the last version of the Scrum Guide, they threw out the three questions. And I was really happy to see those go. because they sounded like a status report. And so guess what was happening to most organizations? They think of the Daily Scrum as a status report, which developers hate. And now as soon as there's this status call, then the managers are talking and they say, hey, did you hear there's a daily status call we can come to? And now they start coming to another meeting. And now you have completely destroyed the concept of this really simple meeting, which was effectively just to let team members coordinate their plans for the day. It's kind of a swarming based thing. And so it makes beautiful sense once you understand that, but it's misunderstood 90 % of the time because it just sounded like status.

Brian (32:55)
Now, but hey, pass the plate, because I'm a member of that church. I agree with you on that wholeheartedly. I've always said that, you know, I think it's just one of the things I try to tell people to come through classes. Hey, Scrum Masters, if you don't remember anything else about these events, right? If you forget, you know, six months from now, what the exact time box is on something, I'm not as concerned with that. Make sure you understand the purpose of each one. Make sure that you embed that and print that in your memory. I know what each of these meetings is there for, why we are meeting in that situation. And if you know that, then I don't care about the format. The format will flow from that, but we're accomplishing this purpose and we're gonna figure out the best way to do it.

Steve (33:42)
Yep, and we can even take that back to the tools and say, can make most tools work, right? As long as you get the freedom to use it as you, as a team, see fit. You know, one of the guys, the guy who created the kind of the opposite end of the spectrum scaling approach, Craig Larmann with LESS, he says, why do you need more than just a shared Google Doc to do everything? You know, why couldn't you just have your, you know, all your stuff up there in a spreadsheet and, know, good enough for what you needed to have visible and you can generate a few reports and maybe that's all you need and maybe you don't need a heavy tool. that, you know, so there's a spectrum of possibilities.

Brian (34:21)
Yeah, I mean, when teams started out, there weren't any tools, and that's what everyone was using, was things like that. So, yes, it's entirely possible. Very cheap. And you don't have to be a big organization. You don't have to have a massive budget for software. can use the tools available to you and get by very well. Well, this has been great. I really appreciate you taking the time, Steve. I love this discussion, and I hope that...

Steve (34:43)
Absolutely.

Brian (34:51)
For our listener who suggested this, that we kind of hit the nail on the head and gave you what you were hoping for in this one. But yeah, when it comes to Agile tools, Agile should drive the tool, not the other way around. The tool shouldn't drive how you do Agile. And I think that's kind of where I would sum it up. Any last thoughts?

Steve (35:10)
So if I was going to quote Craig Larvin one more time here, less is more sometimes. And so the concept of minimalism and being more about how you and your team work together and how your meetings work and how you respect each other and how you learn how to work effectively together, way more important than your tools. ideally, let your approaches dictate the tool. Try not to let the tool dictate your approaches.

Brian (35:40)
Awesome, yeah, completely agree. If you've been listening to Steve and feel like, I really clicked with that guy, I really resonate with the ways he's speaking on this stuff, I encourage you check out his course schedule. You can find that at the Scrum Alliance website and see what courses he's teaching and sign up for one. Because as I said, Steve's an excellent instructor. So Steve, thank you so much for coming on the podcast.

Steve (36:04)
Thanks, Brian. It's been a pleasure to be here with you.

How does Agile fit into the fast-paced, high-stakes world of game development? Clinton Keith, author of Agile Game Development, spills the secrets from his time working with some of the top studios in the industry and explains why adapting Agile to gaming is both a challenge and a game-changer.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner and Clinton Keith dive into the unique dynamics of Agile in the gaming industry. Clinton shares stories from his decades-long career in game development, explaining how Agile methodologies have evolved in the industry and why traditional approaches often fail.

They discuss the impact of deadlines, the influence of digital distribution, and how finding the "fun" in games is crucial for successful development. Clinton also provides valuable insights into modifying Agile practices to better fit the gaming world and the critical role leadership plays in fostering a productive Agile culture.

References and resources mentioned in the show:

Clinton Keith
Agile Game Development: Build, Play, Repeat by Clinton Keith
Mike Cohn’s Better User Stories Course
Accurate Agile Planning Course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe 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 [email protected]

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.

Clinton Keith is a seasoned game industry veteran turned Agile coach and author of Agile Game Development, 2nd Edition. With 25 years of experience as a programmer, CTO, and production director, Clinton now helps creative teams and studio leaders build better games through effective Scrum, Lean, and Kanban.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. Glad to have you back. We're here for another episode of the Agile Mentors podcast. I am with you as always, Brian Milner. Today, have a very special guest. A very special guest was the word I was looking for, but somehow it came out wrong. A very special guest that I'm very excited about having with us, Mr. Clinton Keith is with us.

Clinton Keith (00:17)
You got it right the first time.

Brian (00:23)
Welcome in, Clinton.

Clinton Keith (00:25)
Hey Brian, thank you so much for the invitation.

Brian (00:27)
Yeah, very, very psyched, very excited to have Clinton on. Clinton is a CST, but more importantly, he's the author of a book called Agile Game Development. And he has been in the video game industry and working with different video game makers and production houses and things for a long, long time. And he told me he's been a video game maker since the seventies. So I said, well, that's great. Cause I've been a video game player since the seventies. So I'm sure we could cross. and have some overlapping stories here. Me from the consumer side. I wanted to have Clinton on because he's got this unique perspective of really how Agile has developed and how Agile is kind of implemented and works well in the gaming industry. So let me start with just asking you, Clinton, when you work with gaming companies and they are interested curious about Agile, what is sort of the main holdup or the main objection that they present to you when they first start working with you?

Clinton Keith (01:37)
Well, it's changed. mean, I've been an independent trainer CST since 2008. And back then it was like, this agile stuff doesn't, know, this won't work for us or it won't work for our role playing game or massively multiplayer online game. might work for these small games. But I think since then, what you've seen is there's just such a lot of bad implementations. We call cargo cult implementations of Agile, where we think that standing around in a circle and answering three questions a day is going to result in some productivity fairy flying over our heads and sprinkling this methodology dust on us and wonderful things will happen, where there's a discipline and a change in culture. And so people have seen a lot of poor agile implementations. But at the same time, continuing on with more traditional approaches as games get larger, teams get larger, projects get bigger, that they're saving the worst failures on not adopting a more iterative approach to game development.

Brian (02:54)
Yeah. Yeah. Yeah, I mentioned that there's probably a lot of objection. There's a lot of the companies that kind of take that fixed scope, fixed schedule kind of approach to doing work and kind of think maybe Agile doesn't align to what we do or our industry or how we do things. Hopefully I'm not putting you on the spot too much, but do have any interesting stories or examples of things like that where you've worked with a company that maybe was just very, very resistant that you kind of, that they kind of turned around in the time you worked with them?

Clinton Keith (03:36)
Well, think one of the more clear examples and, and, know, I, being a project manager and someone who's a, started as a programmer and ran studios, you know, and we ended up shipping successful titles on schedule, on budget. that, when I work with teams that have true deadlines, you know, these are teams that, especially sports titles where. You know, if, you know, Madden football misses the launch of their next title at the beginning of the NFL season, they're going to lose half their sales as opposed to, you know, being told it's so called, have a deadline, but you know, that just to put pressure on the team. so when you have that kind of deadline, a do or die deadline, then it gets them serious about doing things like prioritizing scope.

Brian (04:11)
Yeah. Yeah.

Clinton Keith (04:30)
We're saying, it's like, hey, we have this new engine to render crowds in the stadium and this is going to be beautiful. And, and it's going to look like these are real stadiums filled with people. They're less willing to take that risk if it has to come out on that specific date. And so we prioritize scope by saying, Hey, we have 32 teams, you know, it be baseball or NFL or whatever. have so many stadiums, we have rosters, we have uniforms that have changed from year to year. Those are things that we have to get in. The things that are like a new technology for mud on the uniforms, well, we can take a different approach to that and say, those would be nice to have, but we're not going to bet our schedule on that. So those were the teams on what we call AAA games. They're games that have large staffs, huge budgets, hundreds of millions of dollars. They kind of learned those lessons early on and it really became proof that an agile approach of saying, prioritizing scope and managing scope and delivering things that work and that show increased value in terms of player fun on iteration, iteration basis was really the best approach to hitting those targets. Which again is really difficult for teams that really have those so -called hard deadlines. but was still with a fixed scope, that they want all those things and at the last minute, end up compromising quality, get those all the, to hit all those goals.

Brian (06:06)
I'm kind of curious about kind of the teaming aspect within the gaming industry because it seems like, and maybe I'm wrong here, so correct me if I'm wrong, but it seems like more than some of the other industries in software development that it's a little more of the mercenary kind of attitude of, you know, kind of have the gun for hire that you bring in or guns for hire that you bring in to do some project or some game and then... then when the project wraps, they're gone. People float from place to place. Is it tough to generate, have teams go through stages of formation in that kind of environment?

Clinton Keith (06:46)
Right. Yeah, no, it's less so with now that we had mobile games, these mobile platforms come out where a lot of most of the effort actually is maintaining and building a live product and growing it over time, where it's like, instead of saying, you know, on traditional large games, we're going to spend two years with no customers, no feedback. We're going to build this huge game and then launch it all at once on a disc or on a cartridge. and then cross our fingers. And with that approach, usually with game development, the traditional approach is to have a documentation phase, a planning phase, a design phase, and then a pre -production phase where we build all the mechanics. And then a production phase where we create all the levels, build the storyline, something that people can play through 20, 30 hours. And then at the end of it, alpha beta phase where we fix all the bugs, make it run fast, find, know, make it fun and polish it and then get it out the door. and in terms of staffing, like what you described was very, yeah, it was the big challenge because in pre -production we, you know, we might want 50 people, 30 people. but then when we're building all this content and building the worlds, then we're growing to a couple hundred people and then you ship it on the disk. What do you do with those 200 people that are sitting around? And that's still on large games. You know, I work with some teams that are over a thousand people developing the game. And they're trying to address that problem by having, you know, large publishers or acquiring studios. And they'll have up to half a dozen studios in various locations around the world working on that, especially on building those worlds in that, that production phase. But then that introduces the problem of communication and overhead and time zones. And yeah, it's a very challenging problem that when I started in the game industry, know, a AAA game took less than 10 people, you know, sitting in a single room.

Brian (08:53)
Yeah, kind of, it's such a different paradigm now than it was. And the industry has changed so much, it seems like to me because, well, like for instance, my oldest daughter is a pretty avid gamer now as well. And when we were helping her get settled for her second year of college, we had to replace her monitor, know, so she had something to play on. And we walked in the Best Buy and I tried to explain to her that, Best Buy used to be a mecca for gamers. I remember going there regularly to stroll through the shelves of the boxes and kind of see what was on sale. Now, I can't remember the last time that I bought a physical media for a game. It's all downloaded. How has that changed just the process of developing games? I'm sure that's, previously when you had to have the gold disk version or whatever that was released. I'm sure there was much tighter timeframes, right? Is it much different now with being able to update over longer periods of time?

Clinton Keith (10:03)
Well, just from an Agile perspective, it's gotten much better. You know, we introduced Agile to our studio back 20 years ago, over 20 years ago. And, you know, back then, really, the retailers dominated the industry so much in terms of you had to sell Walmart on the game you were proposing to make, which meant that you had to write the 300 page document that they would approve.

Brian (10:25)
Yeah.

Clinton Keith (10:32)
before you even knew it was fun. It's even worse with some of the larger first party companies that own the consoles, that they would say, well, we have a slot for making this type of game, so you have to stay within that slot. And at the end of it, we will determine how many cartridges that we will manufacture for your first release. And so it's very restrictive in terms of how much change we could introduce into the game over the course of development and say, well, the game that we're making is kind of boring. But that's the agreement that we made with Target or Walmart. And so we have to kind of stick with that game. Whereas now you can get early versions, like in Steam, for example, early release. And you can start to get metrics or that if you're a a game that's already out on a platform like iPhone, you can introduce the idea of a new mechanic to a limited number of users to say, it's like, hey, let's release a version of this mechanic to people in the state of New York and see, observe how they're playing it, measure how they're playing it, how many times they come back to it, and then use that information to tweak the next two week iteration or release dozens of different versions of our game you know, to millions of people and see which version that's out there in the wild is getting more response. So we have the ability to, you know, be much more agile and actually measuring what our customers, our players are doing with our game.

Brian (12:07)
That's so interesting. You spoke earlier about kind of like the AAA games with like sports games and how they have much tighter deadlines and they're, they kind of, there's a big, big hit to them if they miss that deadline. What about the opposite? What about the teams that don't have those harsh deadlines? And I would imagine there's an entirely different problem for the product owners of just good enough. how do you... How do those product owners determine, yeah, we have enough or this is in good enough shape that we can release it and we can patch things later?

Clinton Keith (12:44)
think one of the biggest problems you see when you don't have a deadline is this. There's this famous quote, I forget the exact wording of it, is that really tight deadlines, know, kind of restricted, know, restricted, to call it use the word resources, but in terms of money and schedule and things like that, or how many people you have working on it, really focuses you on delivering. And this is something that is a problem for AAA games with no serious deadline is that to say it's the, get these incredibly vast ideas that take years to really show the benefit. And I had this big light bulb moment in my career. I was, I was, I did a lot of racing games really in my career and I was on a game. that had a racing mechanic is based on a movie like what some of the Bourne movies where you have like a 15 minute racing mechanic, know, chasing in the middle of the movie. So late in the development of the game, we had a little bit of extra time and our publisher said, hey, can you throw in like a very short 15 minute car chasing and with police chasing you through an open city. Now that mechanic, police chasing you through an open city, used to take us years to develop with artificial intelligence, know, with police chasing you through crowded traffic streets. And even after years of development, it didn't quite work right. The police would crash into everything and drive on walls and we couldn't get the physics right. You know, we're on a PlayStation or Xbox. You know, you couldn't spend a lot of AI effort, artificial intelligence, on getting that just right. So, but we only had like a month. And so we're sitting around thinking, what can we do? How can we get police chasing us? And so we started asking ourselves questions that we never did ask in the past. Like, why do we have police? You know, why do we have police chasing you? And the answer was that, well, it's to make you drive fast. You know, if you didn't have police chasing you, you know, it's a boring game. And so all we did was we just, instead we just had

Brian (14:47)
Mm. Right.

Clinton Keith (15:02)
We just monitored how fast the player was driving. And if he was driving a little bit too slow, we'd start playing a siren sound. They kept driving slow. started playing flashing lights off the geometry of the buildings around you, blue and red. And then if you continue driving slow, we just played a video of you being arrested. And that took like a couple of days instead of a couple of years. And when we focus tested it, pretty much, half of everyone thought they were really being chased by the police. The other half said, I thought I was being chased by police, but when I looked in the rear view mirror, I didn't see any police. And so we just took out the rear view mirror, tested it the next night. Everyone thought they were being chased by police. And we're like, I guess, and it was actually a better result in the two years of trying to get artificial intelligence right. And so the big light bulb moment was, just like having,

Brian (15:53)
Yeah.

Clinton Keith (15:56)
a short deadline on showing something of value led to people making better choices from the player's perspective, not this challenge of, what can I do with artificial intelligence over the next two years? So I think that's part of the big challenge with these big, huge games of saying it's like, if there's not a payoff, if you can't see value, and this was an early lesson I learned,

Brian (16:11)
Yeah.

Clinton Keith (16:24)
working with Nintendo Japan was the guy that made Mario and Donkey Kong. We worked with him directly, Miyamoto. He always had this thing. It's like, find the fun fast, show the value of it. And it always stuck with me. And so when you have these short deadlines, you want to encourage the teams and the product owners is judge the game, not what you see in

Brian (16:40)
Yeah.

Clinton Keith (16:49)
with the potential in two years. Judge your vision of the two years against what you're seeing every other week and adjust your expectations. Don't fall in love with your vision.

Brian (16:59)
That's so interesting. So I kind of want to dig into this. This is an agile podcast, obviously. And we have lots of people from different walks of life and that they're implementing agile in different ways. And it's always interesting, I think, for people to hear how things kind of fit in other realms, right? In other kind of industries and how that changes a little bit industry by industry. So I'm kind of curious when you are talking about agile and Scrum and in a gaming game development environment, what are some typical kind of modifications that you recommend or that you've seen that are needed or work well that are specific to the gaming industry?

Clinton Keith (17:44)
So as I mentioned, a lot of teams, even Agile teams that are truly Agile, like the sports titles, we still have that separation of discovering what new mechanics we want to put into the game and then building all that content, your stadium. So let's use sports titles for example. Let's say we do alter how we draw or render the stadiums. And we're making much more beautiful, more detailed stadiums because we have a new platform that can draw 10 times as much like a next generation PlayStation or Xbox. So we still want to come out with the new sports title at the start of the season. So we'll, we'll do more of our risky exploration of stadiums and what it's going to take to, to render these stadiums. and how many polygons, how many triangles we're going to use to build these stadiums and how much it's going to cost. Because we do have 32 stadiums. We do have a budget. We do have so many artists that can build these stadiums. So we have to figure that out ahead of time. And then, you know, once we figure that out and say, all right, we have, you know, we've built an example stadium. This is an example of what we want to ship at the start of the season. Now we have to build all the other 31 stadiums to that quality. And we've judged the risk and the cost and the schedule and how many people we have to the artists to build those things. And then we go into that production pipeline with those studios. And that's where, you know, it's like the scrum every two weeks model doesn't quite work. know, a stadium might take. 21 .2 days to build. And it's a pipeline of handoffs of things. Somebody doing the concept art for the stadium and then building the geometry for the stadium and then lighting it, you know, and all the audio effects. And so it becomes more of a production factory pipeline where practices like Kanban and lean come into play. That still have those underlying values of getting things through the pipeline as quickly as possible, continually looking at how we can improve that pipeline. And then judging instead of how much we can get done every fixed time box is judging how long that stadium takes from concept to in -game and trying to refine that to get improvements in the quality of the stadiums and the productivity of that entire pipeline. which leads to, you know, things that we see in Scrum is disciplines talking to each other and improving how they work together.

Brian (20:32)
Yeah. I would imagine the culture, like there's potential culture clash kind of things here with Agile in the gaming industry. Like one of the things I was thinking about is, you find it's a little tougher to get buy -in on a concept like working at a sustainable pace? Is that something that's in the gaming industry, people... Because I've seen a lot of... I've been around some small companies that are working on gaming, and they seem to work all the time. It's like late nights, weekends, it's just like it's non -stop. Is that kind of a difficult concept in the gaming industry?

Clinton Keith (21:18)
Well, mean, the gaming industries had quite a few scandals in terms of crunch time. And a lot of that has to do with not seeing that actual game until the end. As I mentioned, it's like we have these in pre -agile development, still goes on quite a bit, is that, we write this big, huge document up front. We get the buy -off on the stakeholders. We go off and the engineers go off over here, the artists go off over here. And then towards the end of the game, when we finally get all the elements of a story together, we can first start to play it. Then we start to get it so instead of it crashing every two minutes, we're starting to get the game playable and we're out of time. We have to ship this game in three to six months. It's not fun. It's a disaster.

Brian (22:06)
Yeah.

Clinton Keith (22:13)
and then what, unfortunately what happens is we've, we put that accountability on the developers and say, well, now you, and, know, as, as a studio director, pre -agile, I was guilty of this as well as to say, Hey, we got it. We, we, we have no choice, but to come in here seven days a week, 10 to 12 hours a day. And, and as it, yeah, as a team we'll, we'll, you know, we'll, we'll get this thing done. And it destroyed. destroyed marriages, harmed families. I mean, I went through that. didn't see my, one of my newborns for the first three months of his life, pretty much, except when he was sleeping, when I came home late. And it simply doesn't, I mean, it's harmful primarily to the working life and these people that leave the game industry, but it's also harmful to the game is that, you do whatever it takes to get this

Brian (22:45)
Ha

Clinton Keith (23:12)
terrible game across the deadline that you were very passionate about in this first couple years of development. And we've seen disasters, even in recent history of games being released that, you know, it's just unplayable, but they had to get out for a deadline and they've spent hundreds of millions of dollars. And they've just felt like, well, nowadays we can patch games, you know, and, and, and, you know, it, it, it, it kills them from a financial point of view.

Brian (23:41)
Yeah. Yeah. It's so interesting. you know, I think this, to me, this is where it kind of, it is so relatable to, to anyone who's, who's trying to do this kind of work. Because I think there that we've all had scenarios and situations where, know, as an agile coach or trainer that we've, we've, you know, we've been up against a constraint of some kind. We've been up against something that is not really the way we would. hope would be the way that the organization would operate or that the team would be run. And we've had to make those compromises in order to continue the work and continue trying to move that organization forward. So I'm kind of curious, I know there's probably lots of people listening who are in those situations and maybe even kind of some self -doubt there about, hey, am I really? Am I really doing this the right way? And am I kind of a sellout and that I'm giving in to the management and how they're making us do this? Would you have any advice or anything that you would say to people in that position that could maybe help them kind of navigate that?

Clinton Keith (24:56)
I mean, yeah, think, I mean, a lot of it is, is, it's a tough question to answer because, you know, a lot of it is, I mean, I, I've been in that position myself where, yeah, I was promoted to studio director and my first studio. It's like, okay, now you're responsible for all these games, seven games in development. And, you know, I committed, I said, all right, we're going to stop doing stupid things. Which means like going to a team that's working very well and saying, this other team, they're in a bad place. So I'm going to take half of your team and move them over there. You know, the old Fred Brooks thing is just like, you know, it's like, Hey, you know, it's like, you know, we're going to double their staff, you know, which is going to make it even worse for them, but it's also going to harm you. We're going to stop doing those things because now I'm in charge. I've been through that. I've run individual games and I know the impact. of what that does. And so I wasn't in the job more than two weeks before the CEO came in and said, hey, we don't have enough money to pay payroll this Friday. And I went into a panic because I was like, I just got promoted to a studio that's going out of business. I go half the people are going to leave if they don't get paid this Friday. And he goes, well, just calm down, relax. You know, what we're going to do is we're going to get a loan because

Brian (26:10)
Yeah.

Clinton Keith (26:21)
but we have to accelerate this milestone payment. I need you to, we need to start a new team, an eighth game. And I was like, well, we don't have the people for it to start an eighth game. It says, well, you need to go out to the teams and take people from their teams and populate a whole new team so we can get this payment from this publisher who wants to start a game. And it was such a bad idea to do, but I couldn't go to the teams and say,

Brian (26:46)
You

Clinton Keith (26:49)
Hey, I need to take some of your staff so we don't go out of business. I just said, you know, it's like, Hey, we have to take some people off your team. And they're like, you very publicly said you weren't going to do stupid things and here you are. You know, so I think, you know, as part of it is it's, it's, it's the culture, it's the leadership. You know, I started about five, six years ago, starting to do leadership training. Yeah. And because it's like, you know what? I keep seeing these.

Brian (26:55)
Yeah.

Clinton Keith (27:19)
You know, the team's adopting these practices, but the leadership not knowing what to do with this transparency, with what to do when your game isn't fun early on, and how it's so hard to build an agile culture, but so easy to destroy overnight from leadership doing things like I did. So I built a leadership course that was like, I wish this was the training I had got. 20 years ago when I was put into this position to help navigate some of these issues and help these teams. I there's, I mean, there's, mean, occasionally see cultures that just kind of like beyond, you know, their, ability to recover just too late, you know, to make some of these, make some of these changes, because like I said, we have to get this title.

Brian (27:49)
Right.

Clinton Keith (28:15)
Out the door in three months. In fact, these days I just refuse to, I used, I refuse to train a team that's within six months of shipping a, having a big title to ship because it's like, yeah, that sounds great. You know, we'd love to do it, but you know, we're just in the trenches for the next six months.

Brian (28:35)
Yeah, that kind of heads down and then can't, how do you learn a new process, you know, while you're in heads down mode, right? Well, this is fascinating. And I, you know, I'm tempted to take more of your time. I just don't want to, I want to be respectful of your time and in our listeners time. So it's probably a good place for us to stop. I want to just point out to people, again, your book, Agile Games Development, where you talk about a lot of this stuff. If I'm reading this correctly, it was originally out in 2020, right? Is that correct? Second edition, second edition was 2020. So you've added some new stories and some new elements to it in 2020, right?

Clinton Keith (29:09)
The second edition, Well, I mean, it was between 2008 when the first edition came out, we had mobile. You know, it's like the iPhone came out and mobile came out and the entire industry turned upside down. So, and I just, we've just learned so much from working with all these studios and what they have discovered is just incredible. it's, mean, it's, I mean, the industry was very agile early on. You know, the console, the arcade developers used to like sneak out prototype versions and

Brian (29:22)
Yeah.

Clinton Keith (29:47)
count quarters they collected. When then the 90s and early 2000s, things got so huge, we went away from Agile. And so it was a difficult sell. But in the last, yeah, the last dozen years, it's been fantastic with all these platforms, all these new opportunities, all these new markets. It's almost as if we're not using the word Agile anymore. It's just the way to develop.

Brian (30:14)
That's awesome. Yeah, that's what Mike said sometimes. Mike Cohn, when we talk about this, he's like, that was my goal initially was to not have Agile be something we even had to name. It just would be software development. And that's just the way that would be the default in doing things. So it's good to hear that at least in some places that is the case, right? It does feel like that's more of the default. That's great.

Clinton Keith (30:38)
Well, it's no coincidence. Mike was our first coach 20 years ago and my mentor. And I think that I stole that quote from him and glad to see that it's, it's, it's coming true.

Brian (30:41)
Yeah You That's awesome. That's awesome. Well, we'll put all these links in the show notes for everybody. But again, the book is called Agile Game Development. And Clinton, I really appreciate you coming on. Thanks for taking your time and chatting with us.

Clinton Keith (31:02)
Thanks for the invite, Brian. Enjoyed it a lot.

In this episode of the Agile Mentors Podcast, Brian Milner chats with Murman about the value of attending Agile conferences, the importance of networking, and the impact of volunteering in the Agile community. They share personal stories, advice on making the most of conference experiences, and insights into how volunteering can open up new opportunities for personal and professional growth.

Overview

Brian Milner and Chris Murman dive into the world of Agile conferences, focusing on the upcoming Agile 2025 event and the benefits of attending. They discuss the evolving purpose of conferences, why networking and volunteering are crucial, and how approaching conferences with an open mind can lead to unexpected learning and connections.

Chris also shares his journey from attendee to conference chair, providing a behind-the-scenes look at what goes into creating a memorable conference experience. Whether you're a conference regular or considering attending your first one, this episode offers valuable perspectives on getting the most out of these unique events.

References and resources mentioned in the show:

Agile 2025
Chris Murman
Connect with Chris on LinkedIn
Agile Alliance Speaker Submission Tips Webinar
#105: Scrum Conferences & Neurodiversity with Brian Milner
Special Episode Scrum Gathering Denver 2022
Mountain Goat Software’s Accurate Agile Planning Course
Subscribe to the Agile Mentors Podcast
Join 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 [email protected]

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.

Chris Murman is the Agile 2025 Conference Chair with over 15 years of experience in product management and leadership, He has directed successful launches for top brands like Verizon, NBC Universal, and Chick-fil-A. As the Executive Director of Product at JP Morgan Chase, and leads 20 cross-functional teams, driving innovative financial solutions and spearheading AI/ML initiatives that save over 6,000 man-hours per quarter.

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, a very special friend is here with us, Mr. Chris Murman. Welcome in, Chris.

Chris (00:11)
What's up, Brian? I don't know that I'm a mentor, but I'm here anyways.

Brian (00:12)
You're definitely a mentor. In fact, we're going to explain to people why you are here in just a moment. Chris is an Agile coach extraordinaire. He has been in the community for quite a while. And he is a fellow Dallas native here with me. And we connect a little bit at the last year's Dallas conference here for Agile.

Chris (00:19)
Okay, okay, sure. Sure, sure.

Brian (00:40)
And one of the things that I noted in that conference was they announced the next one, which is coming up in Denver, end of July, beginning of August -ish, we'll put it that way. And he was announced as the chair of that conference. So Chris is actually going to be in charge or leading or behind the scenes for just about everything that's going to take place at that Agile 2025 conference in Denver. So I wanted to have Chris on to talk about that a little bit. Don't think of this as an ad. It's not an ad for it because what I wanted to kind of help people understand was kind of the why behind it. When I normally talk about the conference, it's maybe a month or two before. Well, now it's next summer. So you have some time to plan. And now is the right time to kind of put that kind of stuff in your calendar if it's something that you're thinking about doing. or even maybe thinking about maybe should you volunteer or something like that for it. So Chris, how did you get involved with this kind of thing? How did you get involved with helping out with the conferences? What made you decide to help out in any way, shape or form?

Chris (01:54)
Well, like many, when I first started the work, I I fell into Agile backwards just like everybody else did. None of us did this on purpose. It just came along and we just started doing it and then it became something to do. in the 2010s when Agile was riding high and I... I saw these conferences as really cool learning opportunities and connection opportunities. People that I knew from the, that you and I both know from the local area, from meetups, would tell me about these conferences. I was attending DFW Scrum the last time that Agile 20XX was in Dallas. I did not go, but. cause I, was too late for me to find out and it was kind of pricey. And so I was like, so like conferences are where you just go and meet people and then they're like, yeah, you should just kind of go. So as, as with many of us who are like, well, how do I pay for these conferences to go? just said, well, I'll submit to speak. And, I don't know about you, but my first few submissions were not great. I, I, I. People always laugh when I say this, but I would literally copy and paste the headline and the entire copy of blog posts that I thought would be really cool to talk about. Because I started my blog, that was kind of how Chris Murman .com is kind of how people first started meeting me because I would promote it on platforms and stuff. Agile Twitter used to be really fun back in those days too. So I would just copy and paste the entire blog post as my abstract. And of course, now knowing what I know, like that was, that's just the worst thing to do in the world. but I didn't know what else to do. So I fell flat on my face the first few years and started getting some advice and feedback and such, and started getting accepted to speak around 2016. Spoke at. Spoke at several conferences that year, spoke at several conferences in 2017. 2018 comes along and they're like, and I'm like, hey, how do I help out? Like this is really cool. I connected with the Agile Alliance community, that specific conference community very, very well. And I'm like, well, how can I help? And they're like, here's three or four people, email them until they say yes. And I'm not.

Brian (04:18)
Yeah. Hahaha.

Chris (04:34)
I just was annoying and said, no, I'm not kidding. I want to help. And I got to chair a track. You know, I chaired all kinds of tracks for the next few years. coming out of COVID, I got asked to be on the program team. which is just when people are like, what's the difference between leading a track and leading like the entire program? Think of it as like, The track is like one tiny, tiny sliver in the program team has to go really very narrow across everything to know where everything is. Not that I know every set. I still, I'm like, that was that session was the conference that year. But, so we just have to be more broad in what are the themes that we want to talk about? What are the things that we want to do? and, and, you know, when you join the program team, you know, one of these years it's going to be your year. And then when you. when you're a conference chair, that's your final year on the program team. And then you just go back to civilian life, I guess. I don't know, which is, don't, I don't ask Dana. I don't know what civilian life is on the side of the conference just yet, but I will very soon. So I don't know. It's a, that's a rambling answer, but it's for the most part, that's really how I got going was just, I just wanted to go. You know what I mean? I just wanted to be there. And the only way I could do it was to get a free ticket.

Brian (05:34)
Ha ha ha. Yeah. Yeah, yeah, that's a, well, that's a great answer. I mean, I, I think I'm kind of, I mean, I probably have a little bit, there was probably a few more years I submitted before I got accepted to speak at the Agile Conference, but I probably submitted three or four years before I got something accepted. And that's even after reviewing a few years and seeing what good and bad submissions were like, you know, and trying to understand that.

Chris (06:22)
Thank

Brian (06:25)
But we were talking a little bit beforehand about just the concept of a conference in today's world. I know that we've seen sort of a decline in people who are attending conferences a little bit. And I'm not really sure whether this is a momentary thing or an economy -based thing or what. But when people ask you why attend a conference, what What do you tell people?

Chris (06:55)
Well, there's many things that you can get out of a conference. That's the cool part about it is that you can attend the conference for many reasons. And I would say now in 2024, coming into next year, 25, I don't know that the reasons for attending the conference are the same as they used to be, right? Because when we first started coming, there's this like, I don't mean to sound pedantic or like over inflate myself, but there's a level of like fame in our community. We have a tiny, tiny community. So you can get agile famous a lot of different ways. Like now you can just be an influencer and write like Chris Stone is a perfect example of someone who just cranks out a ton of content that it's for the most part pretty good and get the following that way. And then people meet you that way.

Brian (07:27)
You Yeah, yeah.

Chris (07:53)
there were a lot of ways that you could meet people back then. you could really meet a ton of people there. You could make a ton of connections. So ultimately, I just really wanted to learn. I love learning and I love being connecting with other people. I did theater as a kid, was performing at church as a kid. I was just that person that was always on a stage. so speaking is just another extension of that. You being in a training room all the time, again, it's just a performance. You're just giving a performance where there's hopefully... a few nuggets of wisdom. When I realized that that's all that it was, well then I wanted to do it. You know, I don't think that, but I don't know that that's the same anymore. I don't, you know, I don't hear people say, I learned a ton at this conference every year, right? Because a lot of work, we're,

Brian (08:39)
Right. Yeah. Hmm.

Chris (08:59)
we're rehashing the ideas in a new way. We're trying to explore things in a new way, but we're really kind of taking many people feel like that we're just taking the same rock and turning it over and just getting seeing if we'll be surprised the next time we flip the rock over, right? Like there's only so many times you can flip that rock over before you don't find anything new anymore. So, I, it is interesting to think about why do we What is the purpose of a conference? You know, because do you want to be known so you can get paid, right? Or get a job? You know, there's a lot of people that want a job. So can you get a job by going to a conference? I don't know. I don't, there weren't a lot of jobs in 2023 to hand out. There were some to be had this year. If you attended the conference and were looking like there were several people that had things to talk about and interviews to be had.

Brian (09:28)
Yeah.

Chris (09:55)
some of the jobs are starting to come back. like, okay, well, do you go because you want a job or if you're learning, like, well, what do you want to learn that you can't just learn from watching YouTube or TikTok or, you know, attend like, as you know, training classes are also struggling in the community. like, what is what what is learning in 2024 2025 in the agile community? I think it's worth thinking about, you know what I mean?

Brian (10:23)
Yeah, no, I agree. And I think, from my perspective, I think it's changed a little bit. It's shifted a little bit over time. I think when I first started to go, there was an idea of, yes, I wanted to network and I wanted to understand and meet other people in the community. But as an introvert, I, you know, that kind of scares the crap out of me. And, you know, I can only do a little bit of that before I just feel like my battery is completely depleted. But, you know, when I think when I first went, I did have the idea that I wanted to learn. wanted to kind of be on the cutting edge. I wanted to hear the cutting edge thoughts of people who were out there. And, you know, now I think I still have that mentality when I go, I still want to hear, you know, I want someone to challenge me, you know, like that's, what I really want to hear from, from a speaker is tell me something about this. don't know, or tell me something that, you know, would challenge my, my existing way of thinking about this. so that I can go back and examine it and think, huh, I never really thought of it that way, but maybe that's true and maybe I need to re -examine that. But you know, that's kind of rare. That's not something that you get from just a lot of talks. I know one of the things I try to do when I give a talk is I wanna end with something that I would say, hey, what's the one thing you commit to changing as a result of this? Like what's the one big idea? What's the one... If you left this room and don't remember anything else, what's the one thing that you wanna just star or circle in your notebook and say, I'm gonna go find out more about that or I'm gonna do something about that. And that's where I try to kind of drive toward the whole talk. But I've been in others that, like you said, maybe a little bit more of a rehash of something I've heard before. But I've never left a conference without feeling challenged in some way, even if it's not, even if it's just from a one -on -one conversation that I've had with people, you know, I've been challenged about ideas and had to go back and re -examine and think through things. I'd say it's more, you know, now my balance has shifted. It is more networking now for me than it is that challenging thought, but I still want to find that nugget somewhere in there in the conference time.

Chris (12:41)
So what you said is really interesting and I want to hone in on the specific words you mentioned about challenged, right? the, I do want to, you know, before it sounds like I'm not poo -pooing the idea of conferences in any way, shape or form, but what Brian just mentioned is something that I tell the people all the time. I said it from the stage this year in Dallas, which is like, you get out of it, what you put into it. If you come in with a beginner's mind intending to be challenged, intending to have your assumptions questioned and said, maybe I didn't think about this the way that... I would say that that's probably the thing that I learned every time is that something that I thought was true or wasn't true may not, right?

Brian (13:11)
Yeah, yeah.

Chris (13:35)
You know that half of the conferences are new people every year, right? There's someone new to agile every every year there are there. Thousands of people new to it every year. That's the cool thing about it is that every year there are people that like I just got my CSM like holy cow. That's so like can you imagine showing up to a conference and everybody's like this sucks. I don't want to be here like you're not going to learn anything. I don't get anything out of it like what an awful experience for.

Brian (13:35)
Yeah. You

Chris (14:03)
someone that's new and excited and just wants to, like, there will be something you haven't heard before. But for the most part, the reason why I always get something is because I show up expecting to hear something I haven't heard before. The story won't come out exactly the way you think, right? Or,

Brian (14:09)
Yeah.

Chris (14:22)
the story that they tell, because a good conference is always a great idea plus you, right? It's your stories, your experiences, how this affected you that matters. So sharing your soul, bearing your soul requires the audience to kind of be like, want to be, I want to have someone, you know, kind of bear themselves to me. I want to hear someone be vulnerable.

Brian (14:45)
Yeah.

Chris (14:48)
And those are always the best sessions that you and I always have, is when someone is super vulnerable, super vulnerable with where they are. I thought this was the only way to do this. That's my favorite is when I hear a speaker say, I thought this was the only way to do this. There are so many roads up the mountain that we have for our work. There is not one way to do it. So find a new, come to find a new one. There's a technique that you've probably not tried before or done, or if you have, you didn't do it the way that they did before, that'll seem easier. that's the whole purpose of listening to these things, but it, it, it requires you to show up with more than just here's my tray, man. I have some agile, please. Right. Like that's, this is not a buffet, right? Like you have to like, go find it, right. Seeking positive intent means I have to go seek it. Right. I have to go seek information that I want to have.

Brian (15:21)
Yeah. Hahaha.

Chris (15:41)
and then go get it. Because if I don't, I'm just going to go, yeah, it's cool. I mean, I met some cool people, but I didn't really. OK, well, then you didn't show up with the mentality of being challenged. I challenge our friends, people that have been coming for years, I challenge them every year. You will get something if you want to. Right? If you don't get something, it's because you didn't want to get anything out of it.

Brian (16:01)
Right. I mean, I think we're all kind of guilty sometimes of setting our conference path, choosing the sessions and things that we go to based on things that maybe we already have some familiarity with. And that sounds interesting. yeah, I researched that a little bit. Let me see what they have to say about that. I've tried to intentionally now try to find things that I have no background in. I have no experience in because those are the things that are really going to push me. Those are the things that I don't really have. any knowledge of or forethought on and I'm gonna be taken to a different place. I remember I used to be, I used to get this like really anxious, nervous feeling when I would find out I was wrong about something. You know, I'd be in a conversation at a dinner table with someone and they'd say, well, actually, you know, that's not the way to do it. They'd start to do something else and I'd start to feel kind of anxious about that. But now, now I've like, that's swapped for me. Now when I hear that, when someone says, no, actually there's another way to think about that.

Chris (16:41)
you

Brian (16:57)
I start to get excited. Like it's actually excitement in me because I start to feel like, great, wow, I didn't, this is something new. This is something I had never heard before. And now this is the point where I can grow and break through, you know.

Chris (17:11)
Well, there's, I mean, and there's people that we all, if we've been in these communities before, we can all think of someone that always challenges us, right? Like I can't have a conversation with Michael Sahota without him challenging something that I thought, I just thought was true. And I'm like, no, it's not like, or it might be, but not always. So there's always someone that's just like,

Brian (17:20)
Yeah. Yeah.

Chris (17:37)
sit down so that I can break your mind real quick. And that's always fun. You know, another thing to think about is like, what we get out of the conference also dictates who's going to pay the bill, right? Because we hear in the community a lot, well, companies aren't paying for conferences anymore.

Brian (17:41)
Yeah Mm, yeah, yeah.

Chris (17:59)
That's not true for some aspects of IT. Like all the developer conferences, companies love footing the bill for that. The Microsoft conference, they love footing the bill for that because they send technologists there that come back smarter and can code better and more efficiently and whatever, right? Like better, faster, cheaper, all those things, right? Like they will get something out of it. So the... think the reason why we have to say what do you want at the conference is like, it's gonna kind of dictate who pays the bill. If the purpose of Brian and I who have been to this conference many times and have met so many of the cool people, that's the best part of me going every year is I get to see Matt Barkholm again. Like one of my favorite people in the world that I do not see other than over Zoom, right? Or any number of people, right? Any number of people.

Brian (18:47)
Hahaha.

Chris (18:56)
There's always someone new that I had spoken to online but never met in person. Someone that just, again, someone that just started the work and someone that's like, hey, I read something that you wrote about this years ago and it was really cool. That's cool, right? You won't get that if you don't go out and network and stuff. But here's the thing, if you're there for connections, companies aren't interested in footing the bill for connections. They're interested in footing the bill for...

Brian (19:23)
Right.

Chris (19:26)
learn something, improve something, come away with something. And if Agilent are going to the conferences and just like, I met some really cool people, what else? I met some cool people. All right, cool. I'm not paying next year for you to go to that, right? That's what a lot of companies are trying to do. So we have to sort of imagine like, if the goal is to get companies to pay for people to go again, well, then we need to... That's something that we've asked ourselves in the program team. Like what would get, like what is a program that companies will reimburse for? I think it's, and I don't know that we've got a strong answer either. Everybody's got, I think, there's a lot of I thinks and not a lot of I knows, right? I guess is a good way to think of it.

Brian (20:00)
Yeah. Yeah. Yeah. Well, the other thing I wanted to kind of, because you are, you know, kind of the ultimate volunteer for this upcoming conferences as the chair, you know, I've tried to tell the audience here from time to time about the kind of the benefits of volunteering and why I do it as a speaker, why I've done it in the past as a reviewer. It seems like there's just so many different ways to get involved for something like this so that you don't have to just sit on the sidelines. You can actually be a part of this. And that's a, for me, that's an easy way to have a quick in with the community because you're interacting with people prior to it. So when you show up, it's like, hey, I know you and I know you, because we've been talking and working together on this stuff for a while. So. What kind of case do you make to people for volunteering for a conference like this, like a big conference?

Chris (21:12)
It's so again, going back to like, what do want to get out of it? I think the purpose of volunteering is to kind of learn how the sausage is made to a degree. if someone's like, I'm not really interested in seeing how my sausage is made, then you don't belong in the agile community. Like this is the community of people that want to see

Brian (21:22)
Yeah.

Chris (21:32)
Sausage being stuffed into its casing and just cranked out right like this is this is the community for that like I won't use any more sausage metaphors that although I The the The funny thing about how Volunteering works is that?

Brian (21:41)
Hahaha

Chris (21:50)
You can volunteer in the slightest of ways, just a few hours a week reviewing. When you're like, well, I want to review, that's fine, but I want to be a track chair. Because people always want to be a part of deciding the content. This is what I've always wanted to hear about. This is what I've always wanted to hear about. And of course, then I always ask the question of, OK, well, then someone has to submit that idea. all right, it's one thing to say, want to hear about this. It's another thing to say, how do I get that content out of a group of submissions every year, which we get thousands every year at the conference. And we got thousands, right? Like, you know, for all of the online hubbub over the conference every year over who gets accepted and who doesn't, like thousands of people submit wanting to speak every year. regardless of how they feel about whether they, when they get the rejection letter or the acceptance letter, like thousands of people want to speak at this conference. It's cool. Like it's a cool thing to do, but not everybody is a speaker, right? You can be a purple shirt and volunteer. In fact, some of my favorite people in the community are lifelong purple shirters that have done it multiple years. There are people that do it for a couple of years and meet people and then and they move on to another role. mean, there's just a bunch of different ways that you could be involved in doing something that doesn't involve speaking or deciding who speaks. And also, I will say, it's also really hard to cull thousands of submissions. into something that makes sense for everybody else. Because then you have to go find keynote speakers. There are people that are invited to speak who are luminaries in the industry. And how do you meet those people? So all of that is really like the fact that I can say I can email. any number of people, I won't use the name so I don't offend the people that I don't use, but like I can email any number of them and they're like, yeah, Chris, Agile, Agile 20XX guy. I, it would be cool if they're like, I just like Chris and I want to be friends with them, but you know, that's not the way the world works. so I, you know, networking in ways that don't always show up in a job or whatever is just, I'm, I'm just here to.

Brian (24:00)
Hahaha Right. Right.

Chris (24:25)
find good content and show the community that and the rest kind of takes care of itself, you know?

Brian (24:32)
Yeah. I mean, I'll say to, you know, just to give people kind of an idea of my path with the agile conference, you know, I probably submitted four or five years before I got accepted. And a couple of those years spent as just a reviewer for, you know, a track or, you know, with a certain team, not as a chair, but just as a reviewer. there's a, there's a, if you want to do that, you can do that. Right? mean, it's pretty much, it's easy to get into that kind of a mode if that's something that you're interested in. And I tell people who want to speak like that to me was one of the biggest and best educations I could have had on learning about speaking was reviewing what other people wanted to speak about. Cause you know, there's kind of two parts to speaking. There's the... the marketing side of getting your thing selected, and then there's the actual talk. But the part of trying to come up with your idea of the talk and frame it and put it in an interesting way and learning how to structure your talk in a way that would be interesting for people to listen to, that's a skill in itself. And the best way I learned about that was just reading others, reading what other people were submitting to do and... Chris is right. mean, there's so many submissions that, you know, even as just a reviewer for one track, I was sad for all the ones that I knew would not get to be heard because there's so many good ideas. it's, know, Sophie's choice about how you try to decide which one of these two things or which one of these 10 things, you know, you've got one slot and 10 of them that are 10 or 20 that are just amazing. and you can only take one, you know? So it's difficult, but reading those submissions to me was a really great education.

Chris (26:33)
Yeah, if you think about it this way, we always enter the room to build the schedule with, there's X amount of slots that we have plus X number of alternates and such. we always, you try to look at it like, like you look at the whole schedule and say, okay, is there an aspect of our work that we missed? Well, we didn't really get a, we haven't gotten a retro talk yet. okay, well there was one over here. So, cause you know, you're trying to balance it for like there's meat and potatoes kinds of sessions and then there's like the big idea sort of sessions. Then there's the workshops that are very engaging and meant to create something.

Brian (27:16)
Yeah.

Chris (27:26)
you know, there's a lot of, again, there's a lot of roads up that mountain. I would say that the joy of speaking now, if I could, anybody that wants to do it, the best advice I would say is like, you need to want to speak so that you can be a better presenter and organizer of your thoughts. Because,

Brian (27:46)
Yeah.

Chris (27:49)
Really, the abstract and the basic, there is essentially a formula to filling out a submission to a conference. I, with CP Richardson, who's now on the board, I did a webinar last November on what makes a good submission. It's something that I've gotten super passionate about. Again, it's recorded, it's on the Agile Alliance site if you wanna find it. There is a formula that anybody can follow and get selected, right? I had some, I had several people reach out and say, I watched your video and I follow what you said. And then I got accepted to speak, which for the record, watching what I say will not get you accepted to speak. You can follow the formula. You can, you can follow the formula exactly and still not get it because there's only so many slots and it's really hard to get in. but.

Brian (28:26)
Ha

Chris (28:41)
Once you follow the formula, then it's just down to like, does the idea resonate with the community? And I can't, I can't give you a formula for that because I'm not in anybody's brain, but, you know, I, again, it's always a great top, a great idea. Plus your stories and experiences is what really defines what a good submission is. And so you have to get that straight before you type a single word out. But then once you go through the submission process and there's edits, feedback, all that kind of stuff. Then you got to get accepted. Once you get accepted, then you got to build the session. And we find that a lot of times it's a rare breed of someone that knows how to write a good submission and can put on a good show. Not everybody can do that. And of course, a good show is a relative term, right? You don't got to be big and bombastic and loud to be good, right? Brian's not that and Brian's great in a room, right? So you can...

Brian (29:16)
Yeah.

Chris (29:35)
you have to kind of construct it in a way that makes sense. So, but again, the cool part is, that because I had people help me, mostly because I just annoyed the hell out of them and saying, please, please give me, please give me some help. I just want to keep passing it along. So I mean, I still get people at 12 months a year, I get people saying, I have an idea and I'd love to run it by you that they hit me up on LinkedIn or whatnot. So.

Brian (30:04)
Yeah.

Chris (30:05)
It's just something that I care about now. I got so much better with organizing my ideas and writing them and presenting them that it's a gift that I want to just keep passing on to people. I guess this is because I didn't intend this to be the cross that I bared, it is regardless.

Brian (30:21)
Yeah Well, the only other advice I'd throw out to people, there was a shift that happened with me too, where I went from, I want to be a speaker, let me find a topic. There's a very big difference from having that attitude to living your life and saying, wow, I'm really passionate about this. I'd love to talk about this. If you find the topic first that you resonate with and connect with, then it's, you you're a little more personally connected when you submit. So it can be more painful if you don't get picked, you know, when that happens. But on the other hand, when you do get picked, man, you're so excited about giving that talk. It's not just that you got picked, but it's like, I can't wait to tell people about this, this thing. And to me, that's, that's the magic. Like when that happens, you, you, yeah, you can't, you're, you're, it's not even nervous. You're, just so excited to tell people what you've learned about.

Chris (31:21)
Yeah, another piece of advice I tell people is as you're reading things, it doesn't have to be a book. It could just be an article or a video that you watch. As I always say, when I'm reading a book on something that has nothing to do, like I don't really buy a ton of agile books anymore. I buy a lot of social psychology, social economics, behavioral economics is a lot of my favorites. like Daniel Pink books is a tried and true. I met Daniel Pink once and he's like, what is it with you agile people that just love what I do? And I'm like, I don't know. I just, I don't know. I'm like, we just read it. So, but I read these books with looking for a lens into my world, right? I always read stuff that has nothing to do with IT.

Brian (32:02)
Yeah Yeah.

Chris (32:16)
that or leading teams or whatever it is your world, whatever you think it is. Find something that has nothing to do with your world and then say, how does that identify or how does that relate to my work? That's my favorite thing. I read a book on many years ago on, it was called The Control Heuristic. It was like where control comes from as an idea and psychology and why. We struggle with it. And I immediately turned that into a leadership talk on why we're all control freaks and here's, know, and what, what do we, what do we do about the fact that we're all control freaks? Like, again, I didn't read a book and say, I'm going to do a topic on a book. It's like, no, how does that tie into dealing with executives when I'm trying to get them to release the purse strings or release some of the control of their work, right? comes in handy, right? So you have to be looking for how does that idea sit in our world and then sort of play with that idea a little.

Brian (33:22)
Yeah. Yeah, this has been awesome. I really appreciate you making the time for this, Chris. And for those people listening, just a quick little shout out again. Agile 2025 is happening in Denver. It is the week of July 28 through August 1. So mark your calendars. And if you're interested in volunteering, if you're interested in being a reviewer or one of the Purple Shirt people who help out, Purple Shirt people help out at the actual conference making it kind of flow, right? They make sure it actually works. Yeah, yeah, the talks would not happen without them. Actually, nothing would happen without them. Yeah.

Chris (33:54)
They're the lifeblood of the conference. Yes. Nothing would happen without them. Nothing would happen without them. Yeah, if you hit me up on LinkedIn, my name is just how it appears here on LinkedIn. Toss me your idea. Yes, will, and I said, I shot my mouth off about mentoring people through their talks. That means you too. I... hit me up. Like there's no excuse for you to not because the worst thing that happens is you get to come to the conference. So, yeah.

Brian (34:29)
There we go. So mark your calendars, make sure that you reserve those dates, like I said, just block it off. Even if you don't know whether you can get the money to do it right now, block the dates off, and you're gonna be much more likely to actually attend if you do that, because then you'll see it coming up, and they go, yeah, that's coming up, I should do that. So Chris, thanks again for coming on, I appreciate you making the time, and thanks for joining us.

Chris (34:56)
Yeah, thanks for having me, Brian.

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 Cohn
Essential Scrum by Ken Rubin
Agile & Scrum Glossary
#85: Effectively Managing Dependencies with Ken Rubin
Dependencies Are Killing Your Agile Flow at Scale by Ken Rubin
Creating a Software Engineering Culture by Karl Wiegers
Private Scrum & Agile Training
Agile For Leaders
Working on a Scrum Team Classes
Story Writing Workshop
Join the Agile Mentors Community
Subscribe 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 [email protected]

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 going to end up in the same place. And that means that Agile needs to be thought of more as a set of practices rather than we do Scrum or we do Kanban.

Brian (12:49)
Yeah. Yeah, I love that. And, and, you know, we've talked about the kind of that concept before of, you know, trying to fit the right practices in place. I know when even on this podcast, when we talked about scaling and then couple of those episodes, we talked about how, you know, it may be better for you to, to, find the unique collection of practices that fits your situation. because, know, a lot of these frameworks, they're designed to handle everything. They're designed to handle any possible scenario and.

Mike (13:14)
Mm -hmm.

Brian (13:18)
You're not going to encounter every possible scenario. You're going to encounter the ones that are only particular to you. Yeah.

Mike (13:24)
Yeah, absolutely. Yeah, I've thought that there's I don't want to do this. I've never taken the time to really run this as an initiative. But I felt like there are a core set of practices that kind of everybody should do be iterative, right? know, inspect and adapt, right? Those type of things. But then there's a set of practices that are good for startups, let's say there's another set of practices that are good for people in the banking industry. Right. And that everybody in the banking industry should be doing a certain set of practices, and those will differ a little bit than perhaps every company in the game industry. And so there's these set of practices out there that can be grouped, but they do also need to be kind of tailored and hand -chosen for your particular organization.

Brian (14:11)
Yeah, yeah, I like that kind of the idea like a template, right? I mean, like when you use the template on a software program, that's a starting place, but you're expected to kind of customize it a little bit to your specific needs. Yeah, I like that.

Mike (14:25)
Yeah, wouldn't it be great if you're a startup and somebody said, here are the 20 practices you really got to do if you're to be successful as a startup. Here are the 10 you should think about, and then the rest, see if you like them. Same thing, bank. the bank, might have 30 practices you start with. Ivar Jakobson, who's the inventor of use cases, part of the unified method back with Bucin Rumba. He's had an initiative going on the last handful of years where he talks about method prisons and that the practices are all kind of locked up in these methodology prisons like Scrum and Kanban and everything else. And he talks about like free the practices, right? Let the practices loose of these method prisons and let people just more readily select the set of practices that are best for them.

Brian (15:15)
Love it. Yeah, I love it. That's a great concept.

Mike (15:17)
Yeah, I think it's a great, it's a great approach. It's got some traction, but it's something that more people need to hear and do.

Brian (15:22)
Yeah, I think that there's also maybe some stuff mixed in there with what you were saying that I've heard from the heart of Agile people. There's a lot of good stuff that's overlapped there as well. So that's awesome.

Mike (15:32)
Absolutely. What's another secret you can reveal Brian?

Brian (15:37)
Sure. Now, this is a big one, but what I would say is maybe moving in a different direction, the idea of how important the culture is and just setting the right culture even more so than trying to get things like time boxes correct. I was talking with a friend of mine at a conference recently and one of the things we kind of discussed was that whole inspect and adapt process, how important that just getting that ingrained into the DNA of what the team does. And Mike, like you said earlier, if they have that inspect and adapt built into who they are, then the practices come. The practices will actually kind of coincide with those because they'll find the right things to do. Like you said, they'll end up at the same place, right? They'll end up at the things that really are important to them. But I've seen lots of places where they go straight to the rule book and want to implement all the rules as quickly and possibly as they can. If the teams don't understand, when something goes wrong, when something does not happen the way that we thought it should, then that's a target to inspect. and dig in and find out why it happened that way, and then find a new way of doing it. I've told the story in classes before that I've encountered multiple situations, scenarios where I've worked with teams where they'll be doing something that they've identified as a problem. They've said, hey, yeah, this is wrong, this doesn't work. well, that's what I'm saying.

Mike (17:26)
Why are they doing it then?

Brian (17:32)
They'll identify something and say, yeah, that's not good. We need to do something else. But then they'll stop and say, all right, so let's really, we want to find the right thing to do to replace that with. So let's take the next two months and really investigate, find, and then we'll come back and we'll change in two months over this new thing. And my advice to them is always, so you're gonna just intentionally do the wrong thing for two months? Right.

Mike (17:59)
for two more months.

Brian (18:01)
You know, like you should try one of the other possibilities because you could get lucky and that could be the first thing you try. You know, and oftentimes it is something that is better because your gut instinct is usually pretty good about that kind of stuff. So yeah, try it. Something's not going well, all right? Then we're not doing that again, right? We're gonna try something new, whatever that is, and we're gonna try something new and then we'll do the same thing at the end of the next sprint.

Mike (18:27)
Mm -hmm. Yep. One of my favorite comedians, this guy named Bob Newhart died early, he was earlier this year. And he has this one comedy routine that he does where he's a psychiatrist and somebody walks into his office and she describes some problem he has. And he's like, okay, I'm going to give you the advice. It boils down to two words. And she goes like, should I take notes? Should I write the two words down? It's like, nope, you'll remember them. And he just looks her really like stern in the eye and says, stop it.

Brian (18:54)
you You

Mike (18:59)
She has a phone question. He's like, just stop it, right? Whatever you're doing, just stop it. And which is like just hilarious, right? Imagining, you know, some psychiatrist or therapist giving the advice of just stop doing whatever it is you're doing. But it's so reminiscent of what I've seen with agile teams, right? And with what you're describing here, you know, we're doing the wrong thing. We need to change, but we're going to stall looking for the perfect answer instead of just stopping and figuring out something, right? Just try something different.

Brian (19:28)
Yeah. And if our culture is a culture of always inspecting and adapting, then like you said, we'll end up at the right place because when something's wrong, we'll change it. And we won't just sit on something that we, I don't know how many times I've seen the organizations where you talk to people and take them out for a beer and they'll say, well, here's the real problems. everyone knows what the problems are. So why not fix it? Why not change it?

Mike (19:41)
Mm -hmm. Yeah. It's hard. It's hard in a lot of organizations. You and I both do sessions where we'll talk to executives, right? And to me, it's a really fun, like 90 minute training session that we have because the way we deliberately set that up was to talk about the benefits of agile. So we get people kind of interested, right? you know, those benefits. But then we tell them why it's going to be hard and what they're as executives, what was leaders, what they're going to have to change. And what I find is when we do that, if the leader starts arguing with me, because I tell them, look, here's going be hard. You're going to have to change this. You're going have to stop doing this. If they start arguing with me, we'll change that behavior if we get those benefits, then we know we've got them hooked and they want to be agile. But if I say agile's great, here are hard things you're going to have to change personally. And they're like, yeah, that'd be hard. We probably wouldn't make those changes. I don't want to go anywhere near working with that company. They're not going to succeed. They don't have a culture that's going to make those changes. And so I love doing those executive sessions because we hear it's just so instant, it's instant feedback on whether this company has a chance of being successful or not.

Brian (21:06)
Love him. Is there another one on from your list,

Mike (21:10)
One that I want to add is a little bit more about not just having one team be successful, but if you're working to get a set of teams, your department, your group, something like that. I think it's really important to have a consistent vocabulary across teams. Because we're talking about this idea of continuous improvement. And if your team and my team are using words differently, how do we share ideas back and forth? And that sharing of ideas is really important. if we don't have a consistent vocabulary, think it's hard to do. I worked with a team a couple years ago. I worked with this team, and I'm there for like two or three days. I think I'm there on the second day. And they've been using the words sprint and iteration interchangeably, just both words. And I'm sure you've encountered that. It's kind of normal. I think it kind of depends on if you grew up in the Scrum world, you call them sprints. If you grew up more generically agile, you call them iterations. They're using both words. And the second day I'm in a meeting and somebody says, well, yeah, that's how we do it in a sprint, but it's totally different when we're in an iteration. And I'm like, huh? What's the difference? And the guy had a really great answer. He said, a sprint is when we're working overtime and iteration is when we're going at a sustainable pace. That actually, there's a lot of logic to that. It's kind of a cool idea. I could see that.

Brian (22:17)
Ha ha ha.

Mike (22:37)
But I could tell by looking around the room that others were surprised as well. They'd been using the words interchangeably too. They didn't know there was this specific meaning that, I don't know, three Algel coaches had decided three years ago, this is how we use the words. But it wasn't part of, to your word, moment ago, culture. It wasn't part of their culture. And so some teams were calling them sprints, some teams were calling them iterations, and it was just creating a lot of confusion. when we found out that there were different meanings and different rules for whether you were in a sprint or iteration. So.

Brian (23:08)
Yeah. It reminds me of a Dilbert cartoon I saw a while ago, or it's been several years now, it was about, were talking to their big dumb boss, right? And they were saying, yeah, we're in the middle of a project and we're about halfway through, but we need, you know, six more months to complete this. All right. What's the project you're working on? We're taking all of our website addresses and we are transforming them into URLs. Right. Yeah. It's yeah. Okay. Yeah. Obviously, the boss didn't know the difference, right?

Mike (23:37)
That's a nice project, right? That's my assignment next month. Yeah, the vocabulary just creates confusion. like how Ken Rubin, I mentioned him earlier, the author of Essential Scrum, my favorite book on Scrum. You've had him as a guest before. I love how he writes his books. He starts out, I just start out, I just plunge in. just like, just start writing. And I have an outline, but I just start writing. Ken sits down for seriously months, I think it is.

Brian (23:39)
Right. Right.

Mike (24:07)
and defines a glossary, right? Here's how I'm gonna use certain words. then he, man, if he says a word means a certain thing, he uses it that way every single time. And he has a wonderful, agile glossary on his website, inolution .com. And so he's like defined every kind of agile word you could look for. He's got it defined there. But that's how he starts, right? So he defines all these words. And then if he writes a book and he...

Brian (24:10)
Wow.

Mike (24:33)
wants to use the term sprint, he knows exactly how he's going to use it. That's an easy one, but he will define all those words so they're clear up front. We do these working on a Scrum team classes for companies, which is a of a private whole team training class. And some of the feedback we get is that it really helped them get their vocabulary consistent. It allowed them to talk about ways to improve that were challenging until they had a common vocabulary. What is a Scrum master? What are the responsibilities of a Scrum Master? And that's not just defining the word sprint, but it's defining a more complex word and saying, what does it really mean? But if you don't have agreement on what a Scrum Master is or who is on the team or things like that, it's really hard to talk about that across a larger group. And so that, to me, is one of the secrets to Agile success is that consistent vocabulary.

Brian (25:25)
Yeah, I'm glad you mentioned that class because one of the things that that that we do periodically when we are not here every time. One of things that we do when we have one of those classes is I'll meet with their with a company in advance and have a conversation about what is it that you really want to get out of this. And one of the most consistent things that I hear over and over again from companies that come to us is we want consistent vocabulary. We want a consistent language that people use across this so that When we say something, means the same thing across all our teams.

Mike (25:58)
I think it's become more of an issue the last, I don't know, five, 10 years or whatever it is because we've got so many people that know Agile by now, right? But of course, they were trained by different people. They were trained in different ways. And so they'll be coming to it and using terms slightly differently. I'm going give a little example here. Velocity, right? Velocity can really mean two different things to people. Velocity can mean the amount of forward progress you made. in a sprint, right? How much forward progress did we get? Instead, velocity could mean capacity to do work. How much work did we get done in the last sprint? And forward progress, capacity to do work are slightly different things, right? And if we don't have agreement on that term, we're going to get into those fights about, bugs count towards velocity, right? Well, if you're using velocity to mean capacity to do work, yeah, bugs should count. If you're using velocity to mean forward progress, no. Bugs shouldn't count. And defining velocity, having that conversation with the team, once you get that figured out, a whole set of problems go away. All those discussions about what gets points, they all go away instantly. But most teams don't think to have that conversation. And they will have some team members using velocity one way, others another way. Important to get that defined. It's not hard, but it's important to get that consistency. Brian, do you have another secret, or have we revealed all the secrets?

Brian (27:24)
Yeah, I got one more. I got one more. you might, you know, if you're listening this far, you may notice that I have a sickness. I picked all C words. I don't know why, but that's just what I had to do. But my last C word was communicate. And really just the idea here was, you know, if you've ever gone to see a youth sports team, you know, a kid's soccer, kids basketball, whatever, right? If you ever go to see any of those things, one of the things that you will hear over and over screamed from the sideline from the coaches is, talk to each other. And it's a really important part of learning how to play that sport is, hey, I've got a call for the ball. I've got to let everyone else know, hey, here's what I need. And I think that's an important part of Scrum as well. Scrum is a team sport. It's a...

Mike (28:02)
Haha.

Brian (28:19)
You know, I apologize to people in classes and say, apologize for the sports analogy, but scrum is a sports analogy. You know, it comes from rugby and, it's, it's intentionally there as a team sports so that people can, can recognize and look at that and say, yeah, we're not, we're not playing golf, right? We're, we're, playing this as a team altogether at the same time with the same goal. And so you got to talk to each other. You got to have communication. I know, you know,

Mike (28:24)
Yeah, itself,

Brian (28:47)
One of the main ways that we try to help that here at Mountain Goat is when we talk about things like user stories. That's a main tool that the teams will use in their communication back and forth between the business and the developers. And I know in your Better User Stories course, we go in detail about that. And we also have this thing that we do occasionally called a story writing workshop that's kind of more coaching, where we'll sit down with people and kind of

Mike (29:01)
Mm -hmm.

Brian (29:17)
actually work through stories that they're writing to help them effectively communicate what they're trying to get across to the developers. Any communication takes practice. Any relationship, the communication grows and gets better the more you do it.

Mike (29:36)
I think it's a good point about using user stories as an example, because one of the user story mistakes people make is to think that user stories exist to document an agreement. They don't. They exist to facilitate a conversation. And then the conversation is where we're going to figure out the specific needs and things like that. Yeah, maybe we could document that. It's got to be documented for various reasons. in many organizations, but the story itself is there's a reminder to have a conversation, right? It's not there to document an agreement, which is different from things that came before, like a use case or IEEE 830 document, right? Those did document agreements. User stories, they're there to make sure we talk.

Brian (30:13)
Right, right. Those were in essence contracts, right? I mean, they were, you shall do this, the system shall and whatever. But yeah, user stories, not that. I love the way that you put that and I've said that for years as well. It's a placeholder for the conversation.

Mike (30:28)
Well, let's add one more C then. didn't realize you were on a C theme here. So let's add one more secret to Agile success with a C. Crack the whip, right? Yell at your team, make them work harder, right? That's the secret to Agile success. I shouldn't say that because you'll pull that out as a little clip. crack the whip on your Agile team. That's how you get them successful, right?

Brian (30:30)
Hahaha! Hahaha. I can guarantee you that's gonna be the cold open here for our show. It's Mike Cone saying, the secret is cracking the whip. I love it. Well.

Mike (30:59)
So there was a great book by a guy named Carl Weigers on culture. is like creating a software engineering culture. And he has these little gray boxes in there. There are things not to do, right? Don't do this. But the boxes don't say don't do this, right? You have to have read like the intro to like, hey, don't do the things in the gray boxes. But he also has like anti -patterns in there. And I just remember being a, a, I think it was a director, VP at the company. And I showed it to one of the directors. I'm like, man, look at this. He's got guys highlighted all the things to do in the boxes here. And he was like, really? We should do that? Okay. And he was like, ready to go do these things. I was like, no, no, no, these are the things not to do. So you gotta be careful with things like crack the whip, right? It's, you know, a direct quote. It sounds pretty horrible. It's a joke. It's like, hopefully people understand. So.

Brian (31:42)
That's hilarious. Yeah, yeah, I think everyone who's, you know, listening to this would understand that, right? Would understand that that's a joke, but and just in case.

Mike (31:56)
As a guy who had the whip cracked on me as a young developer, I've always been a very much do not crack the whip. I'd rather I'm always after people's energy rather than their time. Right. It's kind of like we do four day work weeks, right? I'd rather have energy than time. And so, don't think cracking the whip is the way to succeed.

Brian (32:15)
Yeah, I'm in the same boat. remember having a boss once that used to take me into the server room to yell at me because he could raise his voice in there and nobody would hear it. So, that was fun. Right, right. Well, this has been great, Mike. I really appreciate you making time for this. And I think everyone's going to get a of good tips out of this.

Mike (32:23)
You I gotta remember that. Great, thanks for having me, Brian. Bye.

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 Dacy
Big 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 Hillegas
Accurate Agile Planning
Mountain Goat Software Certified Scrum and Agile Training Schedule
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Join the Agile Mentors Community
Subscribe 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 [email protected]

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 to say these days, but it's going to be very surprising if AI can just generate new ideas. It'll probably generate new ideas, but from what? I was working with a client yesterday that comes from more of the manufacturing world and he's really struggling with leadership agility. Like how do I lead and build a culture in a world for people who do the kind of work that we normally focus on with software engineering and development? He said he's a mechanical engineer and I kept using the word knowledge work, right? So the people who do our kind of work, the reason it's so complex, risky, uncertain, unpredictable and all those things is because it's kind of like knowledge and critical thinking and creative work. And he goes, but how is that different? I'm a mechanical engineer. How does that differ from software engineer? And I said, you know, it's a really good point. It's nothing about who's smarter than who, right? So I'm not trying to put anybody down on that. But in the world of mechanical engineering, you are bound by physics. are like you work in the space industry. Yeah, you're doing some cool things and you got to come up with new ways of doing things, but you still have to operate with. physics and astrophysics within those boundaries that we know about with space. But in software, and I sit down and start writing something, there's no boundaries. Like I can use any technology I want, can come up with any, I'm limited by my own skills and abilities. So why not let AI go help me get ideas? I'm not saying you got to write it all for you, because hey, I told one of the AI tools to write me an e -commerce site in Ruby on Rails. and it gave me all the scaffolding and if I would have taken that and start putting it in, then I can start elaborate. But how much time does that save me? How am gonna construct the file? So it kind of handles that architecture, but then I gotta put my critical thinking on it. I just feel like it's gonna make us, if we embrace it correctly, it's just gonna make us more efficient in that way.

Brian (14:22)
I agree. So what was one of the other skills that you had down that you thought of as being a new era kind of skill?

Lance Dacy (14:29)
So I'll just go through the four left real quick. I was thinking about cross -functional expertise and we can dive into some of those a little bit. Most Scrum teams we say, hey, you got to have cross -functional teams. And that doesn't mean everybody knows everything. It just means we have all the skills on the team to bring something usable by the end of the iteration. But I feel like cross -functional these days is no longer about coding. Like I know a front -end developer, back -end developer, database person, tester, UI, UX, architecture. These are more like understanding what we call now DevOps, cloud infrastructure, hardware, software integration, particularly in fields like, I work with some defense people, some aerospace engineering, writing code is like bare minimum anymore. So if you can do that, celebrate that, but you've got to move beyond that and start understanding these machines hardware, which leads me to my next one, which is continuous learning and adaptability. because the rate of change in software frameworks and tools we just talked about has accelerated. And if we're not keeping up with that and learning from that, you're gonna be left behind. So be agile in that regard. The last two I had on my list, one I'm just gonna brand it as cybersecurity.

Brian (15:47)
Yeah.

Lance Dacy (15:47)
cryptography, like I got a, went to school and for data science, you know, got my master's degree when just after COVID started, I had no idea what I was thinking, but it actually was pretty good because it was all online anyway. But I had to take a lot of cryptography classes way over my head, but at least I understand the terminology and the nomenclature, but that's going to be the key. is, and I've read somewhere, I can't remember the article, but there's like a shortage of 79 ,000 jobs in cryptography. So if you're looking and you're scared for the future, go start learning cryptography and security because these, you know, specifically zero trust architecture, these things that a lot of blockchains have been pioneering in the last couple of years, we're going to have to start locking these things down because every time we find a better way to do security, a hacker undoes that. And this was the cat and mouse game forever and ever. I don't think that will go away. So cybersecurity and more like risk management, you need to understand coding practices for that, as well as how the hardware, the protocols, how do these things talk to one another? And then the last one I just branded is more like... collaborative leadership and communication. need a stronger, you know, used to we would think of software coders sitting in a dark basement, just leave them alone and let them code. And I think we're getting to the direct opposite of that. They need to be leaders out talking to the people who need these systems, going back to that cross -functional expertise. you need to do better communication to the non -technical people so you understand what you're trying to accomplish and automate for those people in the world of cybersecurity and how software tools are changing. People get tired of the buzzwords, right? The technology jargon. So you're going to have to learn how to do that. And I think data scientists are going to be, they're kind of the first group that I've seen this happen. Like when we talk about data science and analytics and AI and Scrum, We've done a couple of podcasts on that. The issue is not just, I'm going to demonstrate what I've shown you, but now I'm going to partner with you and say what I think we should do next. Like I can model a data system ad infinitum, but my theory is I think I've done the best we can do. You can spend two more million dollars and we'll get this much or spend a thousand dollars. do this. And you have to partner with them on that. So those are kind of the five here. You mentioned the first one. So AI and automation, integration, things like that, cross -functional expertise. continuous learning and adaptability, the cryptography, cybersecurity realm, whatever you want to call it, and then collaborative, more collaborative leadership and communication. So those were the five gaps that I think if developers are scared and want to shore up their skills, those are kind of the five that I'm telling my teams to go look for.

Brian (18:38)
That's a great list. I throw a couple, I don't have a full list like you brought, but there's a couple of things that just popped in my head that I would throw into that list as well. One is what I'm just going to call teaming. Because I think there's a need, there's a real need in the marketplace today of people understanding how to do work in a team. Because regardless of what the work is, regardless of what the industry is or the

Lance Dacy (18:51)
Yeah.

Brian (19:07)
backdrop is, you know, most, most jobs, you work together with a group of people to accomplish something in some way, shape or form. That's part of the reasons why shows like The Office or movies like Office Space are so funny is because it's so bad in so many places that people don't really, we laugh at it because we all painfully are aware of how bad it is. Right? Right.

Lance Dacy (19:35)
It's real. We get it the mark.

Brian (19:38)
So being able to understand how a group of people actually do work together well to accomplish something. And I'm not talking about hokey kind of motivational, hey everybody, let's make sure we put on our happy faces today. Right, I'm not talking about that. I'm talking about just, we all go, know, the way I explained it in classes, do we think of teaming as sort of the way you would do golf on a team? where everybody goes and shoots their own 18 holes and then we total up the score? Or do you think of teaming more like it would be in football or basketball or soccer or something like that where everyone's on the field at the same time, we all have the same goal, we're all moving towards the same goal and we do whatever is needed to accomplish that goal. We have to work together. If you go to any youth sport in the world that's a team, what's the one thing that you'll hear people say, from a sideline over and over the coaches say to the team, you got to talk to each other. Right, communicate, talk to each other, call for the ball, right? And that's such an essential teaming kind of component of that, that I think that's one of the big things there is just being able to understand how to team.

Lance Dacy (20:37)
Communicate, yeah. Well, and if you don't know what you're supposed to do, ask somebody. So that's the, you know, I'm not going into psychological safety, but how many people feel safe in an organization going, I don't know how to do this because then you're like, my gosh, if I don't know how to do it, I'll get fired. I lose my job. do this. so cultures have to change as well. I don't have that on my list because this was more specific to contributing it as a team. But I think that's a really important call out. know, professional sports get a bad rap when we use analogies. I love them. because I love sports and I know some people don't play sports and I get that, but you at least have seen them. But that's a great example of five people, 11 people, eight people, whoever it is on the field together with one goal. How important is that? And how often do organizations do a good job at centering people around a one goal? Terrible. We do a terrible job at that. But that's out of the, developers, when I say collaborative leadership, they need to start pushing on those things. So that's, I guess we could call those soft skills. What would you call those, Brian?

Brian (21:53)
Well, actually that was gonna be my next thing was kind of more of these soft skills that I know a lot of people really hate that term and you can use whatever term you wanna. Right, I mean, that's one of them, right? But I mean, just being able to navigate conflict on a team.

Lance Dacy (22:01)
emotional intelligence. I've heard that. Yeah, fill in gaps when you don't have a skill. Go learn it. Solve, work the problem. You know, remember Apollo 13 is like one of my favorite movies. It was a really well done one. And Ed Harris is a great example in that, as he plays Gene Crantz, know, as Apollo 13 was having its issues.

Brian (22:17)
Yeah.

Lance Dacy (22:27)
and work the problem people, they don't know what they're doing. They're all smart people getting together, but they need something. They have to talk and collaborate. So I think that's a huge one. how do you learn to do that? You gotta go do it. You can't read a book and say, how do I get more collaborative? You gotta have, I call it attitude, aptitude, and drive. If you don't have the right attitude or tone when you work with people, They're going to shy away from you and not tell you everything you think. So you want to be approachable. You want to be, hey, bring me any problem you have. Let's talk about it. Like you want to be, that's what I call the right attitude to succeed. Aptitude obviously is your ability to learn something new and get up to speed. And then the drive to succeed. How many people have you worked with where they just do the bare minimum getting by just collecting their paycheck, you know? developers face that, right? So if you're one of those people, if you really want to shore up your skill, go figure out how to change your attitude or maybe you're in the wrong business. But how would you, you know, that's a good one to think about. How would you help fine tune those as a person? What could you go do to shore up your attitude, aptitude and drive? I'll put you on the spot, Brian. I'm sorry. you've done a lot of good talks recently on the neurodivergent and I know you've

Brian (23:38)
What?

Lance Dacy (23:44)
you know, the research that you've done on that, that's more of what I'm talking about here is finding your place in the world of every, you know, bring your gift and talent in whatever state it is, but how could you train yourself to be more approachable and have a better drive? What do you think?

Brian (23:59)
Yeah, well, so my biggest advice there is, I'll quote Ted Lasso who's quoting someone else, but right, be curious, not judgmental, right? That old phrase, which is not his, I forget where it comes from, I think it was, I don't wanna get it wrong. Right, right.

Lance Dacy (24:10)
We all knew something from Ted Lasso, right? You'll put it in the notes, I guess, later.

Brian (24:27)
But that phrase I think should be kind of a hallmark for how we approach things is with curiosity. Like why is it this way? Why is it working this way? And what's behind that rather than that's wrong or that's bad or that's whatever. Right, right. You know, someone does things a different way. Well, that's curious. I wonder why they do that that way. Is that the best way to do things? Let's discuss it. Let's analyze it.

Lance Dacy (24:42)
Or what are you making?

Brian (24:56)
I just want to briefly say too, when you mentioned the sports analogies things and how we get in trouble sometimes for using sports analogies, I say this in my classes, at its core, I can't really completely get away from sports analogies because Scrum is a sports analogy.

Lance Dacy (25:17)
In 1986, they used a professional example, team example, of how products were succeeding in 86. Sony, know, Honda, Canon, all of them, and that's what spawned that article for it, right?

Brian (25:23)
Right. And that article says, you know, the relay race approach to doing things is not the right way. That's a sports analogy, right? It's talking about relay races and handing the baton off between one runner and the other runner. And, you know, that's a sports analogy. And think in teaming, there's an inherent kind of, all right, we don't have to get into all the rules and regulations of the different sports. You don't have to follow them. But I think we can, like you said, I think we can all understand. that when you have a team on the field at the same time, there's a big difference between that and, like I said, golf, where I'm just gonna go shoot my 18 holes, right? But what somebody else is doing doesn't affect me, right? I mean, it affects me at the end of the day with the score, but it doesn't affect, if I'm on the fifth hole, I don't really need to even know what anybody else is doing because I'm just, I'm shooting the best 18 holes I can shoot, right?

Lance Dacy (26:08)
Do the best I can in my one skill. Yeah. And you do have a shared goal, right? We're trying to get the best score, but you're more limited. You can't help other people. Like what is the, it's the attitude I really think, I wish I had a better word for it, but when you walk out on the field, you either are there to do whatever you can to succeed within your capacity and have an attitude of, let's pick each other up. Everybody's going to have good and bad days. We know that. So somebody's going to show up on the team and be like, man, I'm sick or. I'm moving and I'm scattered all over the place and I'm going to be a little flighty this week. People pick each other up. Like, how do we learn to do that, Brian? How do we, how do we, how can we teach people, especially developers to contribute on their teams in that way? It's not about your skills. It's about your attitude, your aptitude and drive.

Brian (27:12)
Yeah, and I think what's at the core of that for a lot of teams and I had several conversations with the different agile conferences I went to this year with people about this. There's this cultural aspect that is so much more important than any of the details that we get into as far as meeting length and who attends and all that. It's just at its core, do you inspect and adapt? Right? Do you actually take time when you...

Lance Dacy (27:21)
Yep.

Brian (27:42)
And it sounds so simple, right? But how many times have you been involved with something at work where everyone knows it's the wrong way to do it, right? Everyone knows that's a terrible thing that's happening in our work. And we all can just kind of shrug our shoulders and say, well, I guess that's the way it has to be. Why? Why don't we inspect and say, why are we doing it that way? Is there another way we could do things? And then we try something different.

Lance Dacy (28:07)
Well, and pull it up because the other problem is the hierarchy of a traditional management driven organization is do I have the courage, you know, one of the scrum values courage to raise that flag and stand up for what's right or our fear of losing my job. And I'm going to encourage you developers out there. If you really want to do a great job, you're a great developer and you're not just trying to get by. I would challenge you like I had to learn a long time ago and say, if I do those things and I get fired, I don't want to work at that organization anyway. But that takes a lot more courage because you got a family and you got all this stuff. But you might have your answer if you start raising the flag. don't be an ass about it. Be an attitude, aptitude, and drive. But that's why I said number three on my list here was continuous learning and adaptability. You have to learn that.

Brian (28:54)
Yeah. Yeah. And I'll give you kind of a practical example here. So if you're working on a team and let's say that you need to get approval to do something, okay? If you have to get that approval and you know that approval is going to cause a delay because I've got to go get approval to do this. Well, be curious, ask the question, why do I need to have this approval? What's the purpose behind getting this approval? And if the answer, if there is a good answer, right? Well, we have to do that because compliance is really important with us and our safety or whatever. And if we don't do that, then we can have a catastrophic event. All right, there's a good reason to get approval. But if the reason comes back, well, because that's the way it always has been, we've always had to ask four layers of approval to get something done. Maybe then question it and say, hey, is there a... Can you help me understand the purpose of getting these four layers of approval? Is there really a need to get four layers of approval for this? What's the downside if I don't get approval for this? Is it catastrophic if I make a decision that maybe one of those four layers of approval disagrees with? Can it still be changed later? What I try to tell people is the speed you get from not having to go through those four layers of approval is far outweighing any kind of small mistake that that person might make. So that's kind of a practical example to say, be curious about it. Try to inspect and adapt. Why is it this way? Does it need to be this way? Is there a reason why we're doing it this way? And if there's not a good answer as to why, then I think it's not bad to question it.

Lance Dacy (30:39)
Yeah. And they're never going to say, well, we like ossified and calcified processes. Every time we have a problem, we add more checks and balances to them. We never remove them. And that's one of the bane of the team's existences these days is, yeah, we got to mitigate risk and we can't be haphazard, but that's why you got to shore up your skills on this automation and get better at problem solving, less coding and more problem solving. And I tell you what, Brian, we were going to wrap up at the end of the podcast with what I wanted to talk about is don't be scared about AI because I don't think, like I said, I don't want to use the word never or always, but I really think it's going to be hard for AI to learn and take our place in number one, emotional intelligence and empathy. you know, AI can certainly analyze patterns of what it's been for, but truly understanding emotions, nuance, and the complexities of human relationships, which is what we're talking about here. Tone AI don't, I don't think it'll ever really learn how to do that or well. All right. on top of that, be the ethical side of it, right? The cultural things and ethical, know, you could put boundaries on it. can give it rules. But I think humans have a really good, well, most humans have a good sense of that. So I think emotional intelligence and empathy, I creative problem solving and artistry. I kind of use the word artistry for developers as well, like writing code and architecting code and the hardware infrastructure and all that that goes into that. AI can generate the beginning, like AI can generate art. It can generate music if you heard some of these things. I mean, they're good. I see the art, I see the music, but it's all based on patterns. It lacks the ability to produce truly original works that stem from like live experiences and personal insights. So celebrate that and bring that to your job. And I think alongside that is complex thinking, know, strategic thinking, leadership, critical thinking, things like that. know, AI is effective at optimizing and analyzing data and helps us, you know, like COBOL used to read and write data faster than any other system. Humans can't keep up with that. Our processor is the bottleneck. So use that, offload that to something else. But your leadership requires abstract thinking and foresight and the ability to motivate people is something that AI really is not going to be able to do. So start shifting your focus from, you know, the things of data and analyzing. let the computer summarize that and then you put your critical thinking on it. And I think that's where you're going to find a better place for yourself as developers. You're going to be and need to be technologists, but that blurring of the line between DevOps and coding is coming and coming and coming. So you have to start learning the hardware that's running all this stuff and make higher level decisions and less of the lower level. So celebrate your emotional intelligence. your empathy, build those skills up, never lose sight of critical problem solving and artistry that you bring to the table and complex thinking and adaptability. Those are the things that you need to focus on, I think, as developers and embrace this AI to make you more efficient. That's my opinion.

Brian (33:59)
Yeah. And I'd say, you know, I just tag one last thing on that and it's to say, you know, with the new tools, with the new kind of AI stuff and things that come along, be curious, not judgmental. Ask about how I could use that to my advantage. You you mentioned the music kind of software. I think I know musicians who are using that kind of software to help them, but they see it more as a tool, not as, and now it'll do the job for me. just like I wouldn't go and put in into chat GBT, write me a whole book on something, right? Right, right. I'm not gonna go, if I'm a musician, I'm not gonna go say write a whole song and I'm gonna just take that lock, second barrel, here's everything that that put out and I'm not gonna alter their change. No, but I can get an idea, I can get a melody or a hook or something that I could use and then I can build upon that. So.

Lance Dacy (34:34)
And then just spin that over. Yeah. And those are always patterns, like every music you hear somebody, it could sound like another song. So you're not really violating ethics there. Like I used AI one time, you my son's learning how to do guitar and I play piano, but I was like, give me eight chord structures that are sad. I mean, there's a certain number of combinations and you listen to them and you're like, okay, now I can add a song under that. But I didn't have to sit around and pick forever and ever like they did, you know, in the old days, which I celebrate that. I think that's great. But why not have eight of them there? And I say, I like that one or don't give me eight more, you know, give me eight more.

Brian (35:13)
Sure. Right, right, right. So think of it more as a tool, right? Well, this has been great. think this is, hopefully we've given everyone a lot to think about here. And if there's one thing I kind of sum up, I hope that people look at it, maybe we're a little too Pollyanna about this, if that's a dated reference too, but naive. But I would say,

Lance Dacy (35:32)
Yeah.

Brian (35:57)
try to be more hopeful about these tools and say, can I use them to my advantage rather than how can I, how is it going to destroy it?

Lance Dacy (36:04)
Attitude, aptitude and drive. Have a great attitude, right? Say, hey, I'm going to embrace this stuff and not so much doom and gloom. Go figure out how you can use it to your advantage and you're going to separate yourself from everybody else. Totally agree with that.

Brian (36:07)
There we go. Love it. Well, Lance, thanks for coming on again. I appreciate you taking time.

Lance Dacy (36:21)
My pleasure. As always, I look forward to our next one, Brian. Y 'all have a great week.

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 Adzic
50% OFF Lizard Optimization by Gojko Adzic
Mismatch: How Inclusion Shapes Design by Kat Holmes
Trustworthy Online Experiments by Ron Kohavi
Advanced Certified Scrum Product Owner®
Subscribe to the Agile Mentors Podcast
Join 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 [email protected]

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 it's wrong to look at the percentages there. I think it's wrong to look at the percentages because then you get into the game of trying to justify economically helping 0 .1 % of the users. And that's never going to happen because what I like about this is an idea from Microsoft's Inclusive Design and the work of Kat Holmes who wrote a book called Mismatch on

Brian (13:52)
Okay.

Gojko (14:17)
assistive technologies and inclusive design for disabled people. And she talks about how it's never ever ever going to be economically justified to optimize a product to help certain disabilities because there's just not enough of them. And there's a lovely example from Microsoft where, Microsoft Inclusive Design Handbook where they talk about three types of,

Brian (14:34)
Yeah.

Gojko (14:44)
disabilities, one are permanent. So you have like people without an arm or something like that. And I'm going to kind of throw some numbers out now, order of magnitude stuff. I have these details in the book and there's kind of the micro -inclusive design handbook. Let's say at the moment, the 16 ,000 people in the U .S. without one arm or with a disabled arm. And then you have these kind of situational disabilities where because of an occupation like you have a bartender who needs to carry something all the time or a worker who does it, one arm is not available and they only have one arm to work on and this temporary like a mother carrying a child or something like that. So the other two groups are order of magnitude 20 -30 million. We're not, by making the software work well with one hand, we're not helping 16 ,000 people, we are helping 50 million people. But you don't know that you're helping 50 million people if you're just thinking about like 16 ,000. I think they have this kind of, one of the key ideas of inclusive design is solve for one, kind of help, design for one, but solve for many. So we are actually helping many, many people there. So think when you figure out that somebody is doing something really strange with your product, you're not helping just that one person.

Brian (15:45)
Right, right. Hmm.

Gojko (16:13)
you're helping a whole class of your users by making the software better, removing the obstacles to success. this is where I, you know, going back to the PowerPoint thing I mentioned, once we started removing obstacles for people to build the audios quickly, lots of other people started using the product and people started using the product in a different way. And I think this is a lovely example of what Bruce Torazzini talks about is the complexity paradox because He's a famous UX designer and he talks about how once you give people a product, their behavior changes as a result of having the product. So the UX research we've done before there is a product or there is a feature is not completely relevant, but it's a changed context because he talks about people have a certain amount of time to do a task. And then when they have a tool to complete the task faster, they can take on a more complicated task or they can take on an additional task or do something else. I think removing obstacles to use a success is really important. Not because we're helping 0 .1 % of people who we don't understand, but because we can then improve the product for everybody. And I think that's kind of the magic of lizard optimization in a sense, where if we find these things where somebody's really getting stuck. but if we help them not get stuck, then other people will use the product in a much better way. And I think this is, know, the name lizard optimization comes from this article by Scott Alexander, who talks about the lizard man's constant in research. And the article talks about his experiences with a survey that combined some demographic and psychological data. So they were looking at where you live and what your nationality is and what gender you are and then how you respond to certain psychological questions. he said, like there's about 4 % of the answers they could not account for. And one person wrote American is gender. Several people listed Martian as nationality and things like that. some of these, he says some of these things will be people who didn't really understand the question. they were distracted, they were doing something else, or they understood the question but they filled in the wrong box because, know, the thick thumbs and small screens, or they were kind of malicious and just, you know, wanted to see what happens. when you kind of add these people together, they're not an insignificant group. kind of, he says 4%. And if... we can help these people, at least some of these people, and say reduce churn by 1%. That can compound growth. Reducing churn, keeping people around for longer is an incredible way to kind of unlock growth. going back to what we were talking about, some people might be getting stuck because they don't understand the instructions. Some people might be getting stuck because they're using the product in a way you didn't expect. And some people might just like not have the mental capacity to use it the way you expected them to be used. But if we can help these people along, then normal users can use it much, easier. And you mentioned a smart fridge. I still remember there was this one wonderful bug report we had for my other product, which is a collaboration tool. we had a bug report a while ago. that the software doesn't work when it's loaded on a fridge. And it's like, well, it was never intended to be loaded on a fridge. I have no idea how you loaded it on a fridge. It's a mind mapping diagramming tool. It's intended to be used on large screens. Where does a fridge come in? And then we started talking to this person. This was before the whole kind of COVID and work from home disaster. The user was a busy mother and she was kind of trying to collaborate with her colleagues while making breakfast. breakfast for kids and kind of running around the kitchen she wasn't able to kind of pay attention to the laptop or a phone but her fridge had a screen so she loaded the software on the fridge and was able to kind of pay attention to collaboration there and you know we of course didn't optimize the software to run on fridges that's ridiculous but we realized that some people will be using it without a keyboard and without a mouse and then we kind of restructured the toolbar, we made it so that you can use it on devices that don't have a keyboard and then the whole tablet thing exploded and now you get completely different users that don't have keyboards and things like that. I think that's where I think is looking at percentages is a losing game because then you start saying, but 0 .1 % of people use this. But yeah, I think lizard optimization is about using these signals to improve the products for everybody.

Brian (21:30)
That's a great example. I love that example because you're absolutely right. You're not trying to necessarily solve that one problem because you don't anticipate there's going to be a lot of people who are going to want to run that software on a fridge. However, the takeaway you had from that of, we can do this for people who don't have a keyboard or a mouse. There's another way that they might operate this that could apply to lots of different devices and lots of different scenarios. Now we're talking about a much bigger audience. Now we're talking about opening this up to larger segments of the population. I love that. I think that's a great example. I know you talk about that there's kind of a process for this. Help us understand. You don't have to give away the whole candy story here from the book, but help us kind of understand in broad, terms what kind of process people follow to try to chase these things down.

Gojko (22:26)
So there's like a four step process that's crystallized for me. And the book is kind of more as a, like a proposal or a process. It's something that works for me and I'm hoping that other people will try it out like that. So it might not necessarily stay like that in a few years if we talk again. And I've narrowed it down to four steps and kind of the four steps start with letters L, Z, R and D. Lizard. And it's kind of so learn how people are misusing your products, zero in on one area, on one behavior change you want to improve, then remove obstacles to use a success and then double check that what you've done actually created the impact you expected to make. I think kind of when we look at people who follow their own logic or people who follow some lizard logic you don't really understand, by definition they're doing something strange. your idea of helping them might not necessarily be effective or it might not go all the way or it might. So double checking at the end that people are actually now doing what you expect them to do or doing something better is really, really, really important. And then using signals from that to improve the kind of feedback loop is critical. I had this one case where people were getting stuck on a payment format entering tax details and The form was reasonably well explained. There was an example in the forum how to enter your tax ID and people were constantly getting stuck. A small percentage of people was getting stuck on it. However, I don't want to lose a small percentage of people that want to pay me on the payment form. So I thought, well, how about if I remove that field from there? I speed it up for everybody and then I can guide them later into entering the tax details to generate an invoice. I thought that was a brilliant idea. tested it with a few users. Everybody loved it, so I released it. And then a week later, I realized that, yes, I've sold it for the people that were getting confused, but I've ended up confusing a totally different group of people that expects the tax fields there. So the net effect was negative. then I went back to the original form. so there's lots of these things where people don't necessarily behave the way you think they will.

Brian (24:38)
Hahaha.

Gojko (24:48)
Ron Kohavi has a wonderful book about that called Trustworthy Online Experiments. And he has data from Slack, from Microsoft, from Booking .com and... The numbers are depressive. on one hand, the numbers range from 10 to 30, 40 % success rate for people's ideas. And if leading companies like that do things that don't pan out two thirds of the time, then we have to be honest building our products and say, well, maybe this idea is going to work out, maybe not.

Brian (25:03)
Hahaha. Wow.

Gojko (25:30)
the more experimental the population is, the more risky that is. think monitoring and capturing weird user behaviors, capturing errors helps you understand that people are getting stuck. as you said, you don't want to follow everybody. There's going to be a lot of noise there. We need to extract signals from the noise. That's what the second step is about, focusing on one specific thing we want to improve. Then, try to remove obstacles and then double -checking that we've actually removed them. That's the four steps. And there's like a shorter version of all the four steps. It's easier to remember. It's listen alert, zooming, rescue them, and then double check at the end. that's again, LZRD.

Brian (26:13)
That's awesome. Yeah, I love the process and I love the kind of steps there. Are there tools that you recommend for this that are easier to try to determine these things or chase them down or are there tools that you find are more helpful?

Gojko (26:32)
So there's lots of tools today for things like A -B testing and looking at experiments and things that are very helpful to do this scale. And it's kind of especially useful for the last step. In terms of kind of focusing and things like that, the five stages of growth from the linear analytics are a good tool. Impact mapping is a good tool. Kind of any focusing product management technique that says, well, these are the business goals we're working on now, or these are the kind of user goals we're working on now. out of, know, 50 lizards we found last week, these three lizards seem to be kind of in that area. And for the first step, spotting when people are getting stuck, there's a bunch of tools that are interesting, like session recorders for web products. There's one from Microsoft called Clarity that's free. There's another called Full Story that's quite expensive. There's a couple of open source one, one is packaged within Matomo analytics application. There's a bunch of these other things. Any kind of observability or monitoring tool is also very useful for this because we can spot when people are getting stuck. One of the things I found particularly helpful is logging all user errors. When a user does something to cause an error condition in a product, the product of course tells them like, know, an error happened. But then... logging it and analyzing that information in the back is really critical. for something like that, people sometimes use web analytics tools or any kind of product analytics. I think what's going to be interesting in the next couple of years, and I think if people start doing this more, is we'll see. more like these technical exception analytics tracking tools mixed with this because most of the product analytics are showing people what they expect to see, not what they don't expect to see. And I'll just give you an example of this way. was really helpful. So I've mentioned the screen where people can upload the Word documents. Occasionally people would select weird file types. So they'll select images, they'll select, I don't know, what else.

Brian (28:31)
Yeah.

Gojko (28:49)
Sometimes I guess that's a result of, know, a fat finger press or somebody not selecting the right thing. I have a not insignificant percentage of users every day that try to upload Android package files into a text -to -speech reader. Android package files and application files, I don't know what the right way is to read out an Android application. My best guess is people are doing that. as a, you know, these things where you drop a USB in front of an office and somebody kind of mistakenly plugs it in. So maybe they're hoping that I'll know the Android application on my phone just because they've uploaded it. I don't know, but a small percentage of users was trying to upload files that had SRT and VTT extensions, which are subtitle files. And they were not supported, but

Brian (29:31)
Yeah.

Gojko (29:45)
I kept getting information that people are uploading those types of files. And then I said, well, this is interesting because it's a text to speech system. People are uploading subtitle files, there's text in, so why don't I just ignore the timestamps and read the text? I can do that. And I started supporting that. And then some people started complaining that, well, the voice is reading it slower than the subtitles. I said, well, yes, because...

Brian (30:11)
Ha

Gojko (30:12)
You know, you're uploading subtitles that were read by an actor in a movie. This is a voice that's reading it at their speed. And then we started talking and it turns out that these people were doing it for corporate educational videos where they have a video in English, they need it in French, German, Spanish and all the else, but they don't want to kind of re -edit the video. They just want an alternate audio track. Okay, I mean, I have the timestamps, we can speed up or slow down the audio, it's not a big deal. And we've done that and this was one of the most profitable features ever. Like a very small percentage of the users need it, but those that need it produce hundreds of thousands of audio files because they translate the corporate training videos. And now, you know, we're getting into that numbers game. If I said, you know, there's like 0 .1 % of people are uploading subtitle files.

Brian (30:58)
Yeah.

Gojko (31:07)
then it doesn't matter. if we start thinking about, this is potentially interesting use case, it creates growth on its own because then people find you. And I think my product was the first that was actually doing synchronous subtitles. Competitors are doing it now as well. But it opened the massive, massive market for us. And people, you know, I got there by monitoring user errors, by, you know, the fact that somebody uploaded a file that had an unsupported extension. That was our insight.

Brian (31:38)
Wow, that's really cool. That's a great story. This is fascinating stuff. And it makes me want to dive deeper into the book and read through it again. But I really appreciate you coming on and sharing this with us, Goiko. This is good stuff. Again, the book is called, Lizard Optimization, Unlock Product Growth by Engaging Long Tail Users. And if I'm right, we talked about this a little bit before. We're going to offer a discount to to the listeners,

Gojko (32:07)
Yes, we will give you a listen as a 50 % discount on the ebook. the ebook is available from Lean Pub. If you get it from the discount URL that I'll give you, then you'll get a 50 % discount immediately.

Brian (32:24)
Awesome. So we'll put that in our show notes. If you're interested in that, you can find the show notes. That's a great deal, 50 % off the book and it's good stuff. well, I just, I can't thank you enough. Thanks for making time and coming on and talking this through your book.

Gojko (32:40)
Thank you, it was lovely to chat to you.

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 Thompson
Scrum Inc.
Scrum.org
#68: The Pros and Cons and Real World Applications of SAFe with Mike Hall
#94: Connecting Teams and Leadership with Anthony Coppedge
Three Questions to Determine If an Organization Is Agile by Mike Cohn
Certified Scrum Product Owner® Training
Join the Agile Mentors Community
Subscribe 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 [email protected]

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 sprint. and realign our backlogs based on what we've just really happened. So it's using both, yeah.

Brian (13:55)
I love that. Yeah, taking the best of what these different practices offer,

Tess Thompson (14:04)
Absolutely.

Brian (14:06)
I love that. Well, one of the things that I wanted to talk to you about as well is sort of in working with scaling practices, I'm sure you already talked a little bit about how leadership has different ideas than the team level does. And the team level is kind of struggling with a certain layer of complexity. The leaders are struggling with another.

Tess Thompson (14:22)
Okay.

Brian (14:33)
I know there often appears to be sort of a disconnect between these two groups. I've talked to people who feel like they're speaking a different language. It's sort of like the leaders are, especially when teams, the team level will look and see, there's people in leadership who just, they want us to do Scrum, but then they want a lot of things in the same way that they always have, which is really hard for us to translate and put back into that old language. I'm just kind of curious your thought about that. Do you see leaders, the leadership layer as sort of speaking a different language than the team layer and how do you help them understand each other?

Tess Thompson (15:13)
Yeah, I mean, my most successful implementations is definitely when the leaders are on board. Leaders are really important to agility. We need their help and we need their support. What I always find super interesting is when I go into an engagement, I usually run an assessment, an agility assessment. And what I'm measuring is kind of where the organization is on culture, delivery, how well they're continuously improving or optimizing the system, how well they prioritize and how customer centric they are. Because I really believe agility is about those... It's those five dimensions, if you will, that you need to really focus on. And so I run this assessment and I always have them self -assess through a survey, interviews, and then observations. So often I see my assessments different than maybe how they self -assess and I'll compare both of them. But the leadership assesses so different than the teams do. And so at the end of the assessment, it's just interesting how different they are.

Brian (16:13)
Yeah.

Tess Thompson (16:21)
The teams are thinking they're delivering so well because they're getting all kinds of stuff done and leadership's like they're delivering, they're not delivering. And it's, like, how do we get so out of aligned it all the time at companies? Yeah.

Brian (16:35)
Yeah, yeah, we will do an assessment to it mountain goat. And one of the things that like became clear to me very early in doing that is that self perception versus, you know, perception of others is very different. And, you know, it was amazing to me, just like you said, to see things like the leadership might think that you have one opinion of something and the teams might have another or, you know, the other thing that I saw was was You know, like the Scrum Masters might think, yeah, our practices are great or they're going really well. And then you ask the developers and developers would say, no, it's horrible. We don't like the way this is working. so, you know, it kind of became apparent to me that you have to factor that human personal perception, right? We tend to be maybe individually more critical on ourselves, but

Tess Thompson (17:18)
Okay.

Brian (17:34)
you know, as a group, tend to give ourselves a little more grace in how we're performing, whereas others, when they look in from the outside, will kind of be more honest about it and say, it's not so great in this situation.

Tess Thompson (17:49)
But what I often find is they are delivering. The thing is they're delivering a bunch of things that the leadership doesn't even know about. So the leadership will have their priority list in their head of projects or things they want the teams to be delivering. But the team is getting hit with all kinds of other stuff that the leadership doesn't know about. So they are working hard and they're delivering. So in their head, they're doing it. It's just this.

Brian (17:56)
Yeah.

Tess Thompson (18:12)
the leader maybe not attending to a sprint review and really understanding what the teams got on their plate.

Brian (18:17)
Yeah, and that's kind of that transparency moment, right? mean, if they think they're not doing anything, they may be, they're just not seeing what they're doing and what they're actually spending their time on. And it's not that they aren't really working hard. As you said, they are working hard. It's just the work they're being asked to do is not really in align with what the leadership thinks the priorities should be.

Tess Thompson (18:22)
Yes. Absolutely, that's it. Yep. And then should the people be working on the stuff that they're working on? You know, is it the right thing? And often it may not be.

Brian (19:00)
Yeah. Yeah, I know I've had several instances where I've talked to people when I've been in working with teams where they will, the team level will say, you know, we have all the stuff that we're having to do in addition to the new work. And, you know, we know that that's just kind of a constraint we're under. The organization has asked us to do this as well. And, you know, my comment is always, well, Are you being really transparent about that when you get to something like a sprint review? Are you showing them where you're spending your time? Are you showing them kind of how much of this extra other work you're doing? And I've had situations where we've been in sprint reviews and we've shown them, for instance, like how much support time that they've had to spend. when the lead, right. And the leaders see that and think, my gosh, I didn't know they're spending 60 % of their time doing that kind of work. That's not good. We want them to do,

Tess Thompson (19:32)
right. Yep, eye -opening.

Brian (20:00)
new work. So I've had leaders who have actually spun up support teams when they've been confronted with that just because they didn't know what was going on.

Tess Thompson (20:09)
Yeah, absolutely. That is one of the things I love about sprint reviews is that transparency. And I have seen teams also go into sprint reviews thinking that they just want to show like some progress they made on an increment for a project and not talk about the support work that they did or some of the other buckets of work that come in. And I'm like, you. Part of transparency is seeing, hey, and it doesn't have to be that you show all the support tickets or anything like that. It's talk about something like 50 % of our time, of our capacity was spent on support tickets. Just throwing that in there to make sure leaders are aware.

Brian (20:45)
Yeah. Yeah. Yeah, I want to go back to something you said earlier too, because you were talking about when we first started about how one of the biggest issues is alignment on priorities. And I want to just dig under the surface in that a little bit, because when we talk about that alignment of priorities, are we talking about more of the product area? Are we talking more about just a general overall? What's our company's priority? What kind of priorities are they misaligned on?

Tess Thompson (21:08)
All, I would say all, all priorities are misaligned. So it's been an interesting move to, for me, to Scrum Inc. Because Scrum Inc's clientele is very much

Brian (21:21)
Right.

Tess Thompson (21:35)
scrum mostly outside of IT. So it's been really fun for me because my career and background was all in IT. So I've been learning so much about all these other different domains out there. And we're doing full transformations of an entire company is doing a version of scrum, right? Or scrum at scale so that they're aligned on priorities. And anyway, so it's very... It's all, all the work tends to be a little out of alignment. And going back to the support, I really like to work companies to help them really understand that almost all support, whether it is support in a field that's doing some kind of drilling or it's or it's IT support or it's HR support, you know, taking phone calls from the employees that it tends to all be tech debt. All support is really some form of tech debt. And so getting that message out there, how much time we're spending on and how much money we're spending on support helps companies, leaders to agree to fund some of these.

Brian (22:44)
Yeah.

Tess Thompson (22:57)
projects around reducing tech debt.

Brian (22:59)
Yeah. Yeah. And there's always the having to overcome the kind of more traditional viewpoint of projects and these things based around projects and scope schedule, that sort of thing. How do you help leaders understand kind of this is a new way of doing things and not that we can't talk about schedules, but

Tess Thompson (23:07) 
Okay.

Brian (23:29)
that we're kind of shifting our priorities a little bit, or we're trying to focus on what matters more than arbitrary dates. How do you have those conversations? How do leaders understand that?

Tess Thompson (23:38)
In some organizations it's easier than others. It depends how much the leader above those leaders is on board, to tell you the truth. So I feel like fundamentally they understand. And if we bring up two different priorities and it's two vice presidents, for example, and they're getting bonuses or something based on their performance in their area, we can see

Brian (23:50)
Yeah.

Tess Thompson (24:08)
They fundamentally will understand in a meeting together, they'll understand and then we'll leave and they'll still kind of do their own thing. But if I could get even though like the person, the CEO also, a person above them be like, nope, this is important. And for that person to see the two competing priorities and where there's a problem, I mean, it's really about if there's a problem, right? And then they'll agree and kind of one will give up a little bit on.

Brian (24:30)
Yeah.

Tess Thompson (24:37)
on their ambition towards getting their thing done, understanding that it's good for all of us, the whole company, we all, to get to work on maybe the other priority first.

Brian (24:50)
So a lot of negotiation involved, right? A lot of negotiation skills.

Tess Thompson (24:54)
Absolutely, and getting people in the same room so that they can have the conversation together. You know, it's not me talking to one and then going and talking to the other. I mean, there is some of that too, but then we have to get together here and decide. And yes, unfortunately, yeah, and yes, we will probably be working on these at the same time. However, if there comes into, you know, with an or,

Brian (25:10)
Yeah, it's amazing how much easier that is, right?

Tess Thompson (25:22)
With a large organization, when you've got hundreds of thousands of people, of course we're working on a ton of things at the same time. But when there is a conflict, like we need this skill set here and this, then we have to know which one is more important.

Brian (25:37)
Yeah. Yeah, and someone has to make that call, right? Someone has to be given that authority at some point. Well, this is fascinating stuff. I'm really interested in hearing your perspective of working with these organizations in today's world. So last little question here. From what you just see, especially most recently,

Tess Thompson (25:44)
Yep.

Brian (26:07)
from what you've seen in the organizations you've worked with. If you could just blanket, have one thing fixed before they start working with you, or one thing that they were in alignment with that would really give them a boost in their scaling before they start working with you, what would that be? What would be the thing that you think is most often missing in organizations before you work with them?

Tess Thompson (26:33)
Getting their goals, their strategy and starting to build out their backlog. based on those priorities. In fact, I usually do ask that. Start thinking about what are really your goals? What's your strategy to get there? And what kind of things are you doing to get there? What products are you creating? What services are you What projects you're creating for those products? Start thinking about that and start being a list together. And then when I get there, I'll help organize the list if you don't have it. But it's just starting to think about that ahead of time. Because what I see is leaders or people have multiple lists. They have a list over here of their projects. They have a list over here of stuff they're doing. They have all their emails that are coming in, their chats that are coming in, the phone that's coming in. And it's like, can we get it all kind of in one place so we can really look at it to make better decisions on really where we should be spending our time and our money?

Brian (27:14)
Yeah. Yeah, yeah, that's a great point. A friend of mine, David Hawks, used to say that organizations are swimming in a sea of opportunity. There's all these different things we could do and really trying to limit that scope and say, yeah, we could do all these things, but what makes the most sense for us to do? What's the most valuable thing for us to do?

Tess Thompson (27:58)
Yep, absolutely. And getting in touch with and constant feedback with your customer helps you figure that out. So many companies don't even, the people are like, have no, I always love when I get a group and I said, hey, let's name our customers. And they're sort of out of the line on who their customer is.

Brian (28:19)
Right, and if you don't know who it is you're trying to serve, how do you serve them? Yeah.

Tess Thompson (28:25)
Yeah, yeah. That's usually one of the first things I ask is, hey, who's your customer? Is it the shareholder? Is it this? Is it that? Let's agree. Yes, you will have multiple customers. Let's get it together and understand who are our customers. Let's all agree on that. Maybe even a priority on some of those customers to some degree.

Brian (28:30)
You Right, love that. Right. Yeah, yeah, this has been great. Well, I really appreciate you taking time out, Dr. Thompson, for coming on and helping us and to see things from your perspective. It's so great to talk to people that are, know, not just, you know, this isn't just theory or book learning. You're actually out there, you know, doing these in these large scale organizations and, you know, hearing from you what those real world problems are that you're seeing on a day to day basis.

Tess Thompson (29:18)
And I'm having amazing, amazing results. tell you, I'm, that's why I only had three hours of sleep last night and I'm still.

Brian (29:27)
Ha ha.

Tess Thompson (29:28)
woke up full of joy to be here with you today is I love what I do because I'm constantly getting phone calls after the factor during it and it's like, wow, this stuff really works. I'm like, yeah, it does. It really does.

Brian (29:41)
Amazing when that happens. Awesome. Well, thank you so much for coming on and I just appreciate you sharing your wisdom with us.

Tess Thompson (29:53)
Anytime. Thank you for having me.

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 Leybourn
Are Agile and Scrum Dead? By Mike Cohn
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe 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 [email protected]

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 aficionado of that stuff, right? If you occasionally go hiking or camping, I'm fairly certain that you've had some hikes or some camping trips that weren't that great, right? And you can probably recall them and think, wow, that was horrible. Well, imagine if that was your only experience, right? Imagine if that hike or that camping trip was your only experience. And you came back from that and someone said, you tried hiking or you tried camping. What did you think of hiking or camping? That sucked, it was horrible. I never wanna do that again. I don't know why these people are crazy, that do that stuff. I would never do that again. But if you really like it, you know that yeah, there could be some bad experiences, but there's some good experiences too. And if you plan a really nice hike and you've got good weather and everything else, it can be a really great experience. So to base someone's opinion on, well, my experience in one place was that it was terrible. Well, okay, come on, give it another shot, right? I mean, they're not all gonna be perfect. And if you see it in a couple of places, you'll probably understand, now I know what we were doing wrong in that other place because it's clear now, right? So that's one point here. And the other thing I wanted to say is one of the things that they talk about in their

Scott (15:17)
Right.

Brian (15:26)
268 % failure rate article where they announced their research, is they focus a lot on that their methodology does a better job with really clearly documenting requirements before development starts. So Scott already knows where I'm going with this, right? I think there's a fundamental misunderstanding before we even begin this, because what they're saying is,

Scott (15:42)
boy.

Brian (15:55)
Yeah, one of the things Agile fails at is clearly documenting all the requirements up front. And my response as an Agile trainer is, duh. Yeah, of course, because we don't try to do that. We actually look at that from a different standpoint and say, you're fooling yourself that you can document all the requirements up front. The example I use in class is, well, We're not manufacturing, right? We don't do manufacturing work. We're not churning out the same thing over and over again. If I was doing that, I could document all the requirements upfront, because I've done it before and I know what it takes to do it. We're closer to research and development. So let me take an extreme research and development situation for you. Imagine I'm inventing the cure to a certain kind of cancer, right? And you come to me before that and say, great. Well, we funded the project to cure that certain kind of cancer. Here's the budget. you know, let's get all the requirements documented upfront before you start inventing that cure to cancer. You'd look at me, I'd look at you like you were crazy because I don't know what all the requirements are going to be before I invent this new way of solving the cancer problem, right? I have to experiment. have to try, I have leads, I have ideas about things I would try and that I think have promise, but I've got to go through trials. I've got to go through tests. And the results of those experiments will then guide where I go next. So I think there's a fundamental fallacy in just the idea of trying to judge whether Agile is successful or not about whether it can capture requirements.

Scott (17:34)
Yeah, right. And for those who've been around, I'm going to double down on that one, Brian, because I've seen this pushback to, hey, we've got to capture all the requirements up front. But every time I ask a company, things change. company priorities change all the time. If anything, we're suffering from just chaotic, inconsistent, random. I remember an executive once said, I love Agile. I can change my mind all the time now. He meant it. So, and even before Agile, there were statistics that showed that the majority of requirements never see the light of day or are to use. So we already know outside of Agile, it's a fool's game, the customer will know it when they see it. That's why it's complex. I think you're right. We're not doing something like manufacturing. We're trying to experiment and figure those things out. So the idea of bad Agile missing out on requirements, it feels good to say we've captured everything upfront. But I remember my first full Scrum project on my own with the whole company and the CEO saying, you know, I need to see this by October. I'm like, well, you'll see, you'll see something backed over, right? I wouldn't say that now, but this same CEO is so dead set, like, no, it needs to hit the state. He fully changed the look and feel of the whole website application we're building twice during that project. To me, it just tells me like, let's not play the game. Like I can still scope it, but let's accept it's going to change. The other part, when you say about just bad and sense of practices, there's a poll I put on my LinkedIn profile. Somebody might have seen this if you follow me on LinkedIn, but I asked.

Brian (18:34)
Ha

Scott (19:00)
You know, is the two day CSM enough to get you the results, your organization you want to see now for those who don't know CSM, obviously the standard, you know, training that people take to understand scrum from the scrum Alliance. there's certainly a lot of other courses, Brian, I know you do the advanced CSM CSP, advanced CSP. And there's more beyond that, but people by and large stop at the CSM. The percentage of it last time I checked was like 99 % of all people trained by the scrum Alliance. taking the CSM and it drops off. The percentage of people when I asked out there in the marketplace, is the CSM enough to get you the results? 95 % said no. So one, for my listeners, I'm to be a little bit of tough love on you. We ourselves might be the ones to blame for this. If we stopped our learning then, if we didn't encourage others at our org to learn and keep pressing in, you don't have the tools you need to be successful. The CSM was not all theirs. There's a slew of Equipping and training out there much less coaching and getting support. So I think there's also some miss on bad Agile. Like we never learned enough. Let's just take the basics of well, we have multiple teams. Well, but yes, the CSM doesn't cover multi team and scaling, so you got to figure that out and you're figuring out based on what you have. done it before you have valid experience and the number of companies who aren't getting coaching anymore. Now they end up just trying to figure out a methodology themselves and that's not their strength. The strength might be in -flight software for airlines. I don't know, it's not methodologies. And they're gonna take their best guess influenced by who? I'm gonna guess the PMO. And now you get this muddy version that yeah, doesn't get results. So I second that on the requirements issue and I second that just the fact that Bad Agile could be our own equipping. I do wanna add on the point about experimentation, encourage those.

Brian (20:45)
Yeah.

Scott (20:48)
The metaphor you give about camping is really great. I see a lot of out there in the world for those who are out in the scene, the whole dating scene, and you might be like, these dating apps are terrible. They don't work. Okay. I'm not going to argue they don't work depending on how you use them what's going on out there. But again, what are your options? The world's shifted and here's where we are right now. There's things we can do to do that better, but to simply throw that out, it's like, well, or dieting. Yeah, I tried that diet. It doesn't work. Dieting doesn't work. Well,

Brian (20:59)
You

Scott (21:16)
There's a mindset that goes with that. And did you follow up correctly? Did you look into the research underneath that? Even recently, I'm going through my own personal work around like sleep and health. I'm going through Peter Tia's Outlive, which is a fabulous read. But those are both like, here's some data and science, but you need to kind of hack everybody's different. Here's some ideas, try them out, see it works. Same with Scrum. Try these things out. It's not like, I did Scrum and we didn't get amazing results out of the gate. Well, you keep experimenting. It's simply empiricism. So those could be things for those listening, come back to that, look at your education level, look at options and keep learning and growing and try those things out. Cause could be, we didn't do our best to bring that or even on Mountain Good for their friends who listening who've gone through the Mountain Good courses and you have access to agile mentors. There's a community forum, there's a chance to interact, ask questions, there's lean coffee, bring your questions. How many of us actually go and take advantage of those resources? There's tons of knowledge, information, but most of us are just too busy. to get smarter and apply that. So that could be an action for people listening. What's your own next steps to grow and make sure you're doing the best agile out there that you can and you have case studies that you can reference. Could be an opportunity.

Brian (22:24)
Yeah, such great points. I'll build on your analogy there, or what you talked about with sleep a little bit, and thinking about how, you know, this is one of things I love about Agile, because, you know, if it was, this will maybe highlight the difference between Agile and Scrum a little bit for everyone, if you don't really understand this, right? If I were to say to you, make sure you go to bed at 10, and get up at, you know, six every day, right? You get eight hours, that's eight hours, right? You get hours of sleep, but you gotta be in bed by 10 up at six. Well, some people would hear that go, well, that's ridiculous. That doesn't fit my schedule. I work better at late at night and I'm not an early morning person. And you probably just say that's terrible. That's a terrible idea. But if I said to you, make sure you get enough sleep, right? Then you can apply that and think, okay, well, for me, enough sleep is this. And I know what that means. I know what it means when I get enough sleep.

Scott (22:53)
Thank you.

Brian (23:23)
And for me, that means I'm going to bed by 11 or 12 or whatever. Like I know when I need to be in bed and I know when I need to wake up in the morning and that's enough sleep for me. Maybe it's seven hours for me. Maybe it's nine hours for me. Right. That's the difference to me between Agile and Scrum is that Agile, and that's why I take such offense at anything that would say, it's a failure. Well, it's a principle. And if you're going to take exception to it, which one? Which principle or value are you going to call out and say, this is the one I disagree with, this is one I don't think is valid? Because it's not telling you exactly how to do it. It's not telling you what a sustainable pace is, for example. It's not saying only work 40 hours a week. It's saying everyone should work at a sustainable pace, a pace they can maintain indefinitely. And if you disagree with that, if you're going to say, well, that's a failure,

Scott (24:05)
Right? Mm -hmm.

Brian (24:17)
I don't think people should be working at a sustainable pace. They should be working at an insustainable pace. Well, I'm going to have an issue with you, right? And I'm going to say, where's your research on that? Like, where would you say that that's, you know, how could you back that up? So that's why I take, I think I'm welcome to people with different ideas, but I want to see the data. I want to see you back it up. And even, you know, something like this project, I want to say, what questions did you ask? You know, if you're just taking a poll of software engineers, how did you phrase the questions? Were they leading in how you phrase them? That kind of stuff can be very, very important and make a big impact on your numbers. So without the data, it didn't happen.

Scott (25:01)
Absolutely. I think that, well, and to that point, Brian, and I'm going to push a little bit. This word agile might be the most misunderstood word of the last decade or two. I guarantee you. You can ask 10 people and get 10 different versions of the answers. So like, what are we talking about? Let's take a step back and like, it's sense making to have a conversation around that. So for example, I remember this person who supposedly walked in, this is just this year, walked into the

Brian (25:14)
I agree.

Scott (25:31)
They're, you know, the head of the PMO, they've been doing agile. came from a large manufacturing company. Everyone recognized the name. Now there's other company that got brought in. Let's do this right. And, you know, has all this agile experience. And I'm actually having a conversation. We're talking about planning and predictability and how to get the teams where we need to. And I mentioned this about Velocity and she said, Velocity has nothing to do with planning. And for those who don't know, one, reach out and talk to us, because we can help you do that. The second thing is, in my mind, I didn't even know how to answer. That is the thing we use for planning is how much does your team get done, and we'll extrapolate what they're going to get done by the certain date. But I remember just feeling like, and you're saying you're walking out with all this Agile experience, and you're heading up the PMO on how we roll out Agile. Thank goodness that CTOs are like,

Brian (25:56)
Right.

Scott (26:16)
It has everything to do with planning. And I'm like, thank goodness you straightened that out because I didn't want to say anything. And I'm going to add to that at the leadership level and management level, because management statistically is going to be your biggest inhibitors to continued agility and growth. Management in terms of how we work around here, which is essentially a culture, how we do things around here. That's going to be seven of your 10 reasons you get stuck. When I've polled and asked numerous groups, how much does your leadership understand about Agile on a scale of one to 10? And the numbers I'm constantly getting back are right around 3 .5 to four on a scale of one to 10, right? Which is bad. But here's the flip side is I say, okay, how much does your leadership and management think they understand about Agile? Well, then it basically doubles, right? And even I've people say like on scale of one to 10, they think they're at 12, right? So we have groups who are large influences of how this is going and the stakeholders and what they're asking who.

Brian (26:53)
Yeah.

Scott (27:13)
not only don't understand it, but think that they do. So if you're listening to this out there and you're kind of like, yeah, I agree. Yeah, so what do we need to do about this? And again, you have a lot of options, but if you let that hang over us in terms of that's gonna be your constraints, the true agility here, what we're trying out. And we just kind of accept that, yeah, they don't know anymore. It's almost like this gallows humor, ha ha, they don't get it. Yeah, but they're the ones who are like. asking for fixed scope, fixed date, don't understand about iterating, don't understand MVP, don't understand, like show up to the demos and see what we've done to give us feedback. So those are things that undergird this problem that that lack of understanding can be pervasive and yet people think that they do. And I'll go back to another leader who said they understood Agile, but when we went through the survey feedback to help them and work through that, his comment was, I'm tired of this deadline optional culture. Deadline optional. I guarantee that people don't feel like it's optional. If anything, they're feeling a lot of pressure. But when we miss dates, how they interpret it several layers above is like, they just don't care. This is all deadline optional. So I think there's a disconnect from leadership and management side and the knowledge and even those heading up the project management office that we need to kind of check ourselves. Have they gone to training? Do they know? You'd be amazed what that can do when they get on board and really support this. It clears up a lot of stuff at the team level.

Brian (28:26)
Yeah.

Scott (28:36)
But back to what said earlier, if all you did was send a few people to the two day course and that's it, yeah, you're probably gonna struggle.

Brian (28:44)
Yeah, and I support what you were saying about, need to take responsibility as trainers and as the Agile community that maybe this way was not the right way of doing this. And if there's one thing I might take a little bit of exception to now from how it's described in Scrum is, we talk about Scrum Masters being change agents. And I think that may have gotten a little overblown, right? Because I think in a lot of organizations, people look at it as these people who take a two day class are ready to lead our whole company in how we're doing this. And that was never the intention, right? I think the two day class is actually okay for someone to get kicked off and plugged in and being a scrum master on a team with support, right? If that's the only person, you only have two or three scrum masters that have all taken just a two day course and... no one has really a lot of experience, then it's probably not going to do very well. But if you have some base layer scrum masters who are new, and they have some coach layers that are more experienced, even if it's just one, even if you have that one senior person who hasn't just, you wouldn't do that with anything else. There's nowhere else in your company where you'd say, let's just hire a bunch of people who have never done this before and hope that it works.

Scott (30:07)
you

Brian (30:09)
You wouldn't do that with programmers, you wouldn't do with testers. You would have some, you want to have some senior people that can help guide and mentor and make sure that it's done the right way. But for some reason, you know, companies just kind of look at it as saying, no, I'll just hire a couple of scrum masters that are brand new and that'll solve it.

Scott (30:27)
Woo, I mean, can you imagine getting on a plane like, by the way, everyone, welcome on board. Our pilot's never flown before. I could do that, course. And not only that, we're trying to save money around here. So he's actually going to be concurrently helping fly three other planes at the same time, like while they're doing this work.

Brian (30:32)
But I passed the two day class. Yeah, because most of the flight, you're not doing anything, right? You're just sitting there. So we want to make sure they're still productive so he can fly three planes at once.

Scott (30:50)
That's a hard one be, exactly. That's yeah, which it's, it's, people might be laughing, but it's similar. Like we're trying to get pointy to point people, things change on that flight. And I see these teams, know, scrum master spread around. I remember a company scrum master on seven teams. Nevermind organizational change agent. This poor soul can't even have the meetings run. and someone bested me like, no, I know someone's on 12 teams as the scrum master. So if management doesn't understand the value of this person, and I like what you're saying. It's a tall order organization changes. And I like the idea of like lead improvement, but we kind of cut it at the knees. had one company this year and sadly we'd helped them get started. When we came back, kind of had some back -channel conversations with people that were disgruntled on the team. So thank goodness they had a safe place to come and ask questions. But the person rolling out Agile, it was kind of knighted to help do this. And she had been through the two day training, I think, but literally as they're giving feedback on what's working, not working, she basically said like, Stop complaining. This is the way we're doing things around here. I'm here to just kind of write the playbook. I think you're the person that should be spearheading how to improve every single sprint. And you're saying, we're done talking. We're complaining. I'm trying to formalize our process here. But basically, booted them out of the working group committee that was how we implement Agile. Now, those are two of the key Agilists there. So think we missed some of that when those examples happened. So my friends are listening. expect that people don't get it, expect that they're optimizing for their own concerns. And that's fine, but we don't stop there. We have to kind of work top down bottoms up on that. And there's lots of options and case studies and stories you can see. And certainly I'll just point again to a resource. If you look at Agile Mentors, there's plenty of experts who gonna, they've been on the interviews, been recorded, take a listen to those and hear some stories, help champion this. As a side note, Brian, just gonna add this in real quick. When we talk about Agile being dead or not, I think if we lead this company, like, I totally agree with Brian Scott, especially Scott. He really is very articulate and well -spoken. I think he's probably one of the best podcast interviewees ever. And they might say something like that, but they might come back and say, I agree with Brian Scott. Agile's not dead. We're just not doing it right. So what can we do about that? We'll look back and say, how are we implementing it? Is there a plan? Are we nudging people along? Expect them to kind of play these things out, but keep in mind, It's most of this company's is a multi -year journey to get those kinds of results, but I'm not going to go back as a takeaway from listeners podcasts and tell my management or leadership, we're not doing Agile right. We should do Agile right. For those who don't already know, they don't care. They don't care that we're doing Agile right. They don't even know what it is. We already talked about their scores. They don't know anyways. I'm not going to pitch any kind of change to what we're doing in terms of Agile being right or wrong. That misses. almost every single time for me. What I will pitch is, hey, leadership, you're frustrated that we're not delivering predictably. You're frustrated we're not getting more innovation. You're frustrated our quality is not where it needs to be. Yes, and here's some things we can do to get it there. Under the covers, what we're doing is improving the way we're doing Agile for more visibility, more clarity, better tracking, all that stuff. Your Scrum Master, whoever's leading this, doggone it, they cannot be just glorified JIRA admins. That's not gonna get you there. So take it back as a thing and think about how you're taking it back to them in terms of what matters for them, what's in it for them in business value. Pitch it that way. And you'd be surprised when you're like, if that's tied to the results, I'm listening. But not this we're doing as a right or wrong. So that could be part of reason it falls on its face when we do try to address the agile being dead is how you're presenting and working with your stakeholders and leadership.

Brian (34:37)
Yeah, and quite frankly, I don't care what you call it. If we need to make up a new name and your company has had such a bad experience with Agile, make up a new name for it. I mean, say, no, it's this new project. It's the, I don't know, tangerine process. And it's, yeah, you haven't heard of it? Well, boy, it's great. It's this tangerine thing. Right, it's the latest thing. Tomorrow there will be a book on it.

Scott (34:59)
That's the way you were saying. Yes.

Brian (35:07)
Amazon, the tangerine process as invented by. And here's my research study showing how it's better than Agile. Right, right, exactly. But you know, it's oftentimes there is kind of a problem with a name. And so like I said, I don't care what it's called. You know, I'll give a shout out here because I had some conversations at the know, couple of conferences that took place over this year. And I was talking with one of my friends, Michael Sahota. Scott (35:14) We interviewed three people and yes, we got the data.

Brian (35:37)
So shout out Michael if you, if anyone kind of points out, I he's listening, but if he's listening, shout out to you for this. But we were talking about kind of the problem with the training courses and you know, how we fixed that and everything. And, one of the things we were talking about is, you know, if we could, if we could distill it down, if we could just have people lead with one thing, if they could walk away from those courses really embedded with the concept of I'm going to inspect and adapt. I'm going to inspect what I did. and adapt and when something doesn't go well, I'm not just gonna say, nah, I'll just keep doing it the wrong way. No, if it doesn't go the way it needs to, stop, figure out why and then change and try something new. If I could just get a team to do that without knowing all the practices, all the other, right, I don't care if you call each other, know, Scrum Masters or whatever, if you can just get that, then I think you will. naturally evolve into what you need to be for that company. But you got to have that underlying mentality, culture of it's not acceptable when something goes wrong. We have to figure out why and change.

Scott (36:36)
Mm Absolutely, and I'm with you. I don't care what's called anyways. My reference is a colleague in Southern California, Ben Rodolitz, and he's very big. I just don't use those words anymore. to be honest, it could be actually confusing for people. If they don't know what Agile means and you're using words from Agile, they're going to think they're mapping to what reality is. They're misunderstanding. So maybe we do start with terminology. I'm with you. I'll see my friends. I don't care if you use agile scrum, whatever. I would just say, Hey, we're to try to do something, see how that goes. Well, we're visiting two weeks and take a look at what we got and get, we'd love some feedback. I mean, it's all the same stuff, but we're expecting to not do things right. And learn along the way and not stop. That's the whole process of it. So for some of you that are doing this and feeling like, I think agile's X, we're not seeing results. would, I would take a look and are you breaking any of those fundamentals to begin with? And I think we are quick to say, yeah, but we can't do X, Y, Z Scott. can't have dedicated teams.

Brian (37:37)
Yeah, yeah.

Scott (37:38)
We can't actually get the stakeholders into the sprint review. We don't got time for the retro. Well, then we're one, you're not doing that stuff right. But even if you just call it something else in the end, do something, inspect and adapt, right? Learn by experience, try something out. I hear too much of, I don't think that'll work here. Well, do some, find out, do something and see what you get from that. Worst case, you're going to learn. But a lot of people are like, you know, we can't do that. They won't go for that. And we never actually even tried. But I love what you're saying. Maybe. for those out there listening, try a refreshing thing of different words and then, or move away from the language that they think they know and don't fight that fight. Pick the fights you think you can win in advanced stuff to get results and get noticed. And Brian, you might've seen this too. I've seen company after company, when they actually see results, the stakeholders see results, business are real, they don't care what you're doing, do more of that. I've watched them just pivot and like rush in. So maybe we do step away from all these.

Brian (38:28)
Yeah.

Scott (38:34)
methodology wars and language issues and just get back to what gets results. Do more of that. Learn as you go and keep them learning, right? Like the brass tax.

Brian (38:44)
Yeah, absolutely. Well, I'm not surprised we went a little over, but I appreciate everyone. I hope we didn't eat into anyone's, know, screw up your walking schedule or anything if you're listening to this while you're walking. But, you know, when Scott and I get on a soapbox, you can just guarantee we're gonna be a little bit over. That's just how it goes.

Scott (38:49)
Next. You would love it.

Brian (39:09)
Well, Scott, I really appreciate you coming on, because I think this is a great episode. I really appreciate your views on this, and thank you for making the time.

Scott (39:17)
Yeah, you bet. And for those listening, honestly, put some feedback. We'd love to see what you think in terms of Agile is dead and continue that conversation. I do think it's gonna be an ongoing conversation. But again, thank you, Brian. My pleasure. Always happy to jump on here. Great to work with you guys.

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 DiBella
The 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 Clark
Short Answers to Big Questions About Agile Leaders by Mike Cohn
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mike Cohn’s Better User Stories Course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join 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 [email protected]

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 you doing it only to get people to see things your way?

Brian (12:28)
You Yeah.

Chris (12:54)
Or are you doing it to expand their perceptions and their realizations? Right. And again, there's often the assumption that if someone doesn't have authority, then they don't, or they can't have any influence. Right. And this goes back to with or without authority, but even with formal authority, it's still possible not to have any influence. Right. Influencing without authority begins with first identifying where that influence comes from. And then looking at how others perceive your level of influence. So. regardless of where that influence comes from, you still just need to build those relationships on that platform of trust and respect if you want to have those successful results achieved. It's tricky though, because depending on where that influence comes from, that's what's going to help to guide and even determine how those relationships and those bonds progress.

Brian (13:40)
So that kind of leads to the area of thinking about, if a Scrum Master is going to do that, we can kind of see how that fits in. And one of the things that I hear quite often with people in the classes is, especially when we come upon the section where we talk about Scrum Masters having an influence in the organization, that we have a responsibility to help the organization. understand Scrum and to get the benefits of Scrum. There's often a double take when that happens and the students in class think, well, I don't understand how can I do that? I'm not the CEO. I'm not a manager. I'm a Scrum master. How am I going to be able to change the culture? How am I going to be able to influence what the leadership thinks? about this stuff. What kind of advice would you give from that perspective?

Chris (14:42)
Well, much like I kind of take the leadership perspective, there's no one size fits all, right? To this and influence the same way. Sorry. Influencing is the same way. So there's different approaches that you can take to influencing, right? There's rational approaches where you kind of legitimize the use of like fact -based logic to influence others, right? And you could use within that rational influencing, you could use exchanging, right? As a form of bartering or trading where you do something for someone and they gives you something in return, right? Give and take. And that builds trust levels, but it's also an effective approach since each party is still committed to achieving that common goal. In addition to the rational, right? Again, different, different approaches that you can take social approaches, right? Think about the breakfast club, right? The movie, the breakfast club. Sure. Everybody who's listening to that. to this has seen that movie, right? To me, this is the perfect analogy for trying to influence somebody from a social perspective, because that movie just embodies the epitome of social approaches to influencing. If you think about it, you got five high school kids in detention from completely different backgrounds, right? And they're trying to outsmart their lesson inspiring principle. So they're essentially forced to have to work with one another to achieve that common goal. So when you socialize, That's essential when it comes to building that relationship and that trust, but that also helps to appeal to those relationships as those bonds are developed. Right. And then you kind of use consulting, which helps just to deliver like a collaborative working relationship that not only produces those results, but that also improves the dynamic and the relationships and the culture of the team and the organization. Right. And then if you add onto that, like in the movie, you know, that's just going to lead to the Alliance building, which kind of is like the creation of a team structure that'll enhance the growth and development of everyone involved. So I don't, you know, then there's also emotional approaches. There's what I call the dark side approach, which I don't recommend because it's, always think Darth Vader, right? The dark side, you, you lead by avoiding issues with your followers or your teams, right? You want to manipulate and you want to intimidate and you want to threaten, but those only serve the need of the person trying to get what they want. Right now.

Brian (16:42)
Hahaha

Chris (17:00)
Kind of be an effective way to get results, to get results. Sure. To influence others and build relationships. Absolutely not.

Brian (17:09)
Yeah, fear leads to anger, right? Right, exactly. Yeah, Chris, you are speaking my language, talking about breakfast club, 80s movies and Star Wars. I come on, this is my wheelhouse here. Yeah, no, I agree. it's, you have that great example. I'm gonna go into the analogy here.

Chris (17:12)
It does, know, resentment, you know, it's... huh. Bye!

Brian (17:38)
You have that great example with that principal or vice principal, whatever position he had, that he came in with the authority figure approach. I'm in charge, you are underneath me, you will do what I say during this time. And it wasn't, hey, let's get through this, let's figure out the best way to make the Saturday go by. It was very much, are in need of my My heavy -handed approach otherwise you're gonna go off the rails and You know, there was no respect there was no relationship there It was it was purely, you know prison guard kind of mentality and you know, there's a There's an example. I always think back to You know, I played football in my high school days. I didn't I played some football I didn't I didn't play all the way through high school, but I played some football. So if anyone happens to be from my high school, no, I did not play my whole high school career. I know that I'm admitting it. Okay. But I remember, you know, for most of my football career, which was very short, I had coaches that were all of one type, which was the screaming head, right? They were the person that would yell at you and chew you out and try to motivate you in that way.

Chris (18:35)
you

Brian (19:05)
but I had one coach and he was the last coach that I had who was the head coach of our team. And he was a very soft spoken, quiet man. And I remember him in one practice pulling me aside and saying, hey, look, you're gonna have to do it this way. You're not gonna be able to do it this way. It's not gonna work. If you wanna be successful with this, this is what you're gonna have to do. And I just remember in that moment that I... paid more attention in that moment to anything anyone had ever tried to coach me in the past. And I remember feeling earnestly this desire that I want to please this man. Like I really want this guy to think highly of me and I want to give him my best. over the years since that moment, I've thought back to it lot and thought, that's a clear contrast. since the majority are the other way, that that one person who took this different approach really had this different impression on me of, yeah, this is, and to me that was a great example of leadership.

Chris (20:17)
Yeah. It's funny. Like you mentioned that when you had that cool, calm and collected approach, right? But that can also kind of be taken the other direction. And the first thing I think about with that kind of approach in a negative way is, Bill Lumberg office space, right? Right. Yeah. If you guys can just come in and come in on Saturday or Sunday, blah, blah, blah. Right. So again, so like that type of leader and, know, to stand on the negative, cause I like to focus on negative stuff because it kind of gets people thinking about what not to do.

Brian (20:31)
Yeah. Okay? Yeah.

Chris (20:45)
So like that type of leader, you know, they focused on that power, that title to impose their will on others. Right? So like you had what sounded like an influential kind of perspective from that cool, common, collected tone. Bill Longberg was cool, common, collected, but he was just a jerk. I'll say it without swearing. He was just a jerk. Right. But it's when we're at moving into a position of leadership or someone who wants to influence others. Right. It's we look at people like that and they, it's.

Brian (21:02)
Yeah.

Chris (21:15)
They look to lead from a place of authoritarian status, right? Again, the, my way or the highway approach, but this may stand from two different schools of thought, right? Because either it's the only way they've been taught to lead others or it's to intimidate others into submission. And I'll be completely honest with this by my own admission, I was that type of leader when I took on my first leadership role. Right. I'm Gen X. I had observed this leadership mentality throughout my early career. And I just assume that that was the attitude that got others to follow direction and achieve results. And it wasn't until that I realized this approach was not in fact effective and that there didn't need to be a brutish mentality, but I just needed to transform my mindset and adapt to the individual needs of each person on my team so that I could figure out how to get the best and the most out of them. So it's a learning curve. I mean, you're not going to get it the first time you get put into a position of leadership or the first time that you're tasked to influence people, right? You're not going to know what to do. But our leaders that we grew up with are going to be a huge inspiration. And I always tell anybody, no matter what, you can be an authoritarian leader or you can be a transformation leader. You are a person of influence, no matter what you do. And I always say that anybody in a company can be a person of influence. But if you're tasked with that, if you, you're given that role, whether you want it or not, you are a person of influence and you're going to have an effect on someone's character or continued development. whether that's good or bad. It's up to us as we evolve and we mature and we grow and we develop to figure out the good from the bad and figure out how to move forward in a positive, more positive direction to get the best out of the people that we're now influencing and that we're leading.

Brian (22:54)
Yeah. Yeah. It's such an interesting dynamic because I think you're right. There's authority that people have sometimes that just is sort of a natural thing. This is a very loose analogy, but I know I've been involved with groups of people who are tasked with doing something kind of ad hoc things thrown together for volunteer things or whatever, kind of things where you're not really in an organizational structure. but a group of people come together to do something. Maybe it's in a class or whatever. you know, sometimes you have that one person in the group that, sort of starts a little bit to be the leader of the group. And I've been in the case where the person sort of takes leadership, right? Where they, kind of try to, to just grasp it and control it and tell people what to do. But I've also been in a situation where that person sort of just emerges and the rest of the team is not reluctant to follow them. They're actually thankful that they have someone that can lead and guide them. And there've been occasions when I've been in those situations where that one jerk in the group will speak and say, hey, well, who made you boss? again, I understand if the person really is being bossy. But I've been in situations where the person's not being bossy and someone has said that, and the rest of the group actually turns hostile on that person. Because they're like, what are you talking about? They're doing what we need someone to do. And they just naturally kind of float into that. So I always think about that when I think about when people ask, how am I going to influence this organization when I don't have any authority in the organization? Well, leadership isn't about a title. It's about a how you approach things, right?

Chris (24:53)
Not anymore. used to be about a title, but it's not in today's workplace. It's just not, you know, again, I grew up in a different time where it was pull up your big boy pants, do your job. You know, my boss could talk to me any way they wanted. I wasn't going to take offense to it. wasn't going to take three days off to have a safe space. You can edit that out if you want, but I, you know, I just, you know, but it kind of speak adding onto what you just said about that, right? You had somebody who wanted to take that charge, but you had somebody else who wanted to.

Brian (25:10)
Yep. No, no, no.

Chris (25:23)
you know, who made you boss, right? So how do you influence through tension and conflict? Right? Because if you have somebody who wants to take the reins, but you have somebody combating them, now you're going to, it's going to create, somebody outwardly speaks against that person, that's going to create that tension. Right? So, you know, it comes down to like, how do you influence others when you don't agree with their choices or how they approach things in an influential. approach, right? Particularly when it comes again to those cultural and those generational differences. Right. And this is going to sound harsh, but how do you influence people when you just don't like them? Right. We don't like everybody that we work with. Right. And you're going to have to work with these people. And if you expect to be a person of influence, you got to suck it up and you just got to figure out how to get the best and the most out of them. Right. So again, it's during those times, right? It's just important to identify why it is that you want to influence people in the first place.

Brian (25:59)
Yeah, yeah. Yeah, that's why I'm glad that like a scrum value is not like everyone on your team, right? I mean, it's respect and you should have respect for people even if they have a difference of opinion with you, which we were talking about this a little bit before we started, just the idea that, you know, we can exchange ideas and we can have a difference of opinion on ideas. That's not a problem, right? That's just trying to figure out the best idea. We're challenging the idea to see which one is the best approach. It's only when that becomes a personal thing, when it starts to become about the person, not the idea, that's when it's, well, that's when it turns into a destructive conflict.

Chris (27:04)
Yeah, it's, you I always like to say, think leadership or influence comes down to three simple words. Respect, empathy, compassion. If you can figure out how to master those three words, which I think it's virtually impossible to master them. But if you could figure out how to have some sort of ability to figure out how to use those words, you can lead anybody. Right? It doesn't matter. As long as you can have respect for them, show empathy, put yourself in their shoes for why they might be feeling a certain way. and have compassion for why they feel that way. Try to understand where they're coming from.

Brian (27:37)
That's awesome. I love that. Respect, empathy, compassion. I think that's a great place to end it. So Chris, thank you so much for coming on. I really appreciate you sharing your thoughts and wisdom with us on this. And just again, I'll mention this in the outro, but look for Chris's book that's out now, Leadership Survival Guide Quotes to Keep You from Going Extinct as a Leader. So Chris, thank you so much for coming on.

Chris (28:03)
Awesome, man, I appreciate you having me. It was fun.

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 Guistolise
Lucid
The Collaboration Style Quiz & Report
The Global Scrum Gathering
Advanced Certified ScrumMaster®
Certified ScrumMaster® Training and Scrum Certification
Advanced Certified Scrum Product Owner®
Certified Scrum Product Owner® Training
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe 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 [email protected]

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 some brain writing, spend some time in ideation. And you might even feel comfortable having a conversation with one person rather than if you have a giant group of people sending them into breakouts to have individual conversations. sending out thoughts about what's going to happen before the meeting or the event so that they've got that time to themselves to say, here's what I'm thinking about this topic. before throwing them into a room with a whole bunch of people and expect them to just go.

Brian (13:57)
Right, right. Yeah, no, I mean, of these three, yeah, that one sounds very close to what I would identify with for sure. And yeah, I mean, I think one of the characteristics I would kind of try to relay that home to everybody is I love when a collaboration session spills over across days because I love having the ability to go home and sleep on it

Jessica Guistolise (14:18)
Yes.

Brian (14:24)
you know, when I'm walking my dog or getting ready in the morning and the shower or something that that's when the brilliant idea will strike is when my brain is actually distracted and thinking of something else. That's when I can really think about things. And I, I feel like I need that time to sort of let it percolate and kind of, you know, seep in a little bit before I can come back and really contribute.

Jessica Guistolise (14:46)
Totally. One of the things that I really appreciate that we do at Lucid. So that meeting that I was talking about where I walked out and I went, I provided zero value in that meeting. We've got an open board for that for after. And there's an expectation that if you have ideas afterwards that you have the opportunity to come back to it the next day or the day after that. It's not, okay, we collaborated, close this. That's it, we're done. but you actually get the chance to do some of that asynchronous follow on day, day after kind of collaboration.

Brian (15:20)
Love that. Well, and two, Scrum Masters out there, hear that, listen to that, right? Think about that from that kind of a meeting. This is just a normal meeting, right? But we sometimes can get so structured into the idea of a retrospective being only at this time and this confines, and we have our time boxes and everything else. But yeah, if we can have some spillover time as well, pre or post, right? Just having that ability

Jessica Guistolise (15:30)
Hm.

Brian (15:49)
let people think through and contribute after the fact, that can really deliver some great results and allow you to include all these different collaboration styles. So then relational, expressive, introspective, these are kind of the three styles that you guys highlighted in your talk. All right. So let's say I'm a Scrum Master and I might identify with one of these. How does that help me? How does that help me to do my work with my

Jessica Guistolise (16:23)
Yeah, fantastic. So Brian, you immediately recognize your own sort of tendencies or collaborative tendencies, collaboration styles. But if you think about those you work with, do think you could kind of identify what different styles other people you work with on a regular basis might have?

Brian (16:43)
Yeah, I think so. mean, most people who are listening to this know my boss. I would, it's kind of funny. If I was going to try to pin Mike Cohn down in one of these three. Gosh, you know what's funny is I'm not sure because he sort of has a blend of all three.

Jessica Guistolise (17:08)
Well, that's absolutely like I mentioned, I'm sort of I'm a relational with an introspective kind of toe in introspection. And so I think there's a lot of people who are a little bit of a mix. And so the easiest thing to way to find out is to ask, share what these styles are, and ask what find out what's going on with your team, if they were to self identify, because it's easier to self identify, obviously, And then now you've got a great understanding of what's going on with the rest of your group. It was so fascinating to me when we did the conference talk, we had everybody self -identify and then collect in your self -identified group. So all of the expressives were together, all of the relationals were together and all of the introspectives were together. And then we had them do some work together and they were describing what helps them. to collaborate best. And the expressives were loud and they were right away writing all over the sheets of paper that we had for them. were, you I mean, it was like, it was a boisterous part of the room. The relationals immediately, hi, I don't think we've met yet. Let's get to know one another very quickly. You know, what do you love about your collaboration style? I mean, they really spent that time getting to know one another. And they were kind of coming to consensus before,

Brian (18:23)
Hahaha

Jessica Guistolise (18:35)
before writing anything on their page, because they were making sure that everyone was relating and getting their voice in. The introspectives, quiet, quiet, quiet part of the room, and they all had sticky notes and they were writing their ideas and then they were putting the ideas next to each other that might be similar, and then they started having conversations. So as a scrum master, as a facilitator, to know what your team's style is, is again, going to help you create the experience of inviting each one of those styles to collaborate in ways that best work for them. I mentioned introspectives, send out the agenda beforehand, make sure that they know the topics, have some silent brain writing time, because expressives are going to start putting their stickies out anyway, but allow that quiet moment to be there to accommodate those styles. You may put them into breakout rooms or have them meet with one other person. Especially if you've got like a larger collaborative of that, where you've got a bunch of people together, one -on -one first, then maybe four -on -one, know, one, two, four -all kinds of experiences are going to help those introspectives be able to bring their voice forward. You'll also have a moment of connection. Nobody likes icebreakers, so I think of them more as like relationship activities. If we're going to have a relationship activity, that feels way better than an icebreaker.

Brian (19:52)
Ha

Jessica Guistolise (20:00)
And spending time really allowing for, how are we feeling today? Let's bring some awareness to what's going on collectively as a group. All of that is helpful because then your relations, they've gotten their relationship moment. They feel connected to the people that they're working with, which means they're going to feel connected to the work that they're doing. So that connection before content allows the contact to be significantly improved. and expressives, give them the space to do it. mean, really allow them to be that voice in the room that jumps in and gets everyone excited. They bring people along. So building your events in ways that allow people to bring, be their best collaborative self is so helpful. The other thing that I think is really helpful trying to make sure you've got diversity of collaboration styles on your team. I'm a huge proponent of DEI and diversity and bringing together wildly different perspectives and ideas. And I just think that all of these interesting and complicated human problems that we're trying to solve need interesting, complicated humans and interesting, complicated teams.

Brian (21:20)
Hahaha

Jessica Guistolise (21:22)
And if you've only got introspectives on your team, there's going to be these relation, relationship type thoughts that are going to be missed and same with expressives. And so I think as you're building out a team, or if you have a team, just thinking about like, Ooh, do we have a diversity of collaboration on our team? And am I making sure that each one of those styles are cared

Brian (21:44)
Yeah. Yeah. I mean, like we, I know we talked about this quite a bit on our podcast. know, there are different neuro types, people think in different ways, people have different preferences and you're absolutely right. You know, what, what we need is people who see things from different angles. you know, if we all see things from the same perspective, then we're, don't have anything really to share. We all can just observe one thing and give our own perspective on it. But how much better is it if you have someone who's standing on the opposite side and says, wait a minute. There's actually another dimension to this that you guys aren't really able to see and bringing that to the table can make all the difference in the

Jessica Guistolise (22:20)
complete difference. And isn't it more fun? Everybody thought the same things that I did. Boy, the whole, it would just be boring. And it's a delight to see the ways in which other people see things and to go wander over and see their perspective. like you said, it brings more dimension to the things that we're working on.

Brian (22:45)
Yeah, and at the end of the day, we need some of that conflict. It's not all conflict is bad conflict, If I have a different viewpoint than you, then you're challenging my way of thinking and I'm challenging yours. And hopefully we end up at an endpoint that is a better endpoint because it's been challenged, because we haven't just accepted as rote what somebody thought.

Jessica Guistolise (23:14)
Absolutely. I'm totally agree. I think healthy conflict, healthy conflict and collaboration is, is helpful. I collab. I should have said in that moment, I don't collaborate like this. Can we get to know one another? And I probably would have met some folks in the organization that I, because it was, it was not people that I spend a lot of time with on a regular basis, I would have met people across the organization that I would have.

Brian (23:28)
Right.

Jessica Guistolise (23:43)
would have liked a number.

Brian (23:45)
Well, and I think it's amazing how powerful it is to have a name for something and be able to just kind of say, hey, this is what this means and this is what this is behind this. And if I know I am relational, then I know kind of what I need to be successful. I know what's gonna set me off. I know what's gonna be difficult for me. And I have a much higher likelihood of being productive in that kind of environment because I'm aware of those sorts of things. I think I know the way that you guys started was to try to get people to understand a little bit about where they were first before thinking about others. And I think that that was a genius way to approach that because I think you're right. You kind of know where you are on the map a little So yeah, we've talked about this a little bit when I kind of did my research and work on neurodiversity and different neuro types and stuff and how these different things relate. yeah, it's just like we were saying, right? You need different perspectives. You need different kind of approaches to problems if you're going to solve them and think in different ways when you approach issues. All right. If we understand there's relational, there's expressive, there's introspective, we kind of can pin where we are. We're starting to see where others are. How do I put this into practice? If I'm designing a retrospective, let's just say, and I know my team is made up of, I got five people, I got, you know, of three introspectives and two relationals on my team and no expressives. How's that gonna change how I prepare my

Jessica Guistolise (25:36)
yeah. Well, probably don't just have them start talking about it. I mean, so, you know, as you're thinking through the as you're thinking through the five stages of a retrospective, what you might do is like, okay, so if I'm going to open the retrospective, how might I open the retrospective in a way that's going to cater to my relational? That's an easy one to grab on to, right? Let's let's talk about

Brian (25:41)
No open discussion,

Jessica Guistolise (26:04)
What's something interesting that's in your wallet or your purse or just something that's gonna help the group begin to be in relationship with one another? You'll wanna have some quiet time. Allow them to spend some time on their own thinking about what happened over the course of the last week before you even start throwing things up. You might have just a five minute, close your eyes walk yourself through the last sprint and think about what were the big things that happened before even going into the writing. There's some really nice introspective time to chew on what happened, what's going on. You may put them, like I said, in small groups of two or three instead of having them come together to try to come up with experiments as a whole wide group right off the bat. So when When you figure out, here's the things that we want, here's the topics, here's what the data is telling us, and here's what we want to run an experiment on. Again, allow for that time to go back and really chew on. So we have this thing that we want to work on in the next iteration. So I'm going to spend some time thinking about maybe 10 different ways that we might experiment on that instead of having the whole group have that conversation right off the bat. So there's a whole bunch of different things you could do. to kind of unlock the collaboration in all of your team members.

Brian (27:37)
Yeah. Yeah. We were talking a little bit before our podcast about how we're music nuts and, you know, really get into that world. you know, the ideas crossed my mind. It's sort of like, you know, when you think about composing music or you think about a piece of music, right? If everything wasn't a major key, that would get boring. You know, we like to have minor keys on occasion or sometimes augments. augmented keys or different time signatures and different rhythms and things that kind of come to play in a piece of music. And sometimes we'll even shift those in the course of a single song. So if you think about a retrospective kind of in that or a facilitation session even larger than a retrospective, but just any facilitation session, right? You don't want it to get boring. You don't want to just cater to one thing. You want to be able to have some variety and that makes it interesting that keeps people's attention.

Jessica Guistolise (28:32)
Please. It does. mean, think about just even how you might shift things up in a daily scrum. Every day come to it, okay, so today we're gonna do an expressive scrum. Warn your introspectives that that's coming. Today we're gonna do a relational scrum, daily scrum. Think about how you might add these elements into your planning session, because that's a deeply collaborative session, and you wanna make sure that there's space for each one of your collaborative. collaboration style team members to have the ability to you I think everybody would be surprised how much more information comes when we feel comfortable collaborating in these different styles and There's edges in each of us right so helping to kind of Walk those edges I've I have been working really hard on trying to be more expressive I asked expressives. How do you do that? And really a lot of it is I don't hold my expresses, the things that I express tightly. They're just ideas and I'm willing to just throw them out. And so for me, that's an edge for me that I can walk up to. And so you can help your team members because they're not always gonna be on a team that has an understanding all of these styles exist. Although as a team member, I might say, hey, let's all talk about our collaboration styles real quick as a part of our working agreement. But you may find yourself on a team that doesn't have that same understanding of the collaboration styles. And so if you work on kind of moving that edge further and further, you're stepping into it a bit, then you're going to be more comfortable collaborating in multitudes of environments. And ladies and gentlemen, and all of those in between, We want to hear your voice. so doing the self work in some of that I think is also really important.

Brian (30:37)
Absolutely, yeah, I couldn't agree more. Well, I can't thank you enough, Jessica. Thank you for taking time out and coming in and explaining this to us. It's just, one of the joys of getting to do this kind of thing that I get to have these kinds of conversations with the Agile community and different members of our community. So thank you for making time and sharing your wisdom on this with everyone.

Jessica Guistolise (31:00)
Yeah, thanks, Brian. This has been an absolutely delightful conversation. And if people want more information on the collaboration styles, there is a report out there. And with the report, there is also a quiz you could take that says, wait a minute, what is my collaboration style? And you could have your whole team take the collaboration style quiz. And then you'd really have an understanding of where is everybody at? And how can we make sure that their voice is in the system?

Brian (31:22)
That's an awesome suggestion. We'll definitely put that in our show notes, too. So we'll make sure everyone can just find that in our show notes and not have to hunt for it or anything. But that's an awesome suggestion. Well, again, thanks, Jessica. I appreciate you coming on and speaking with us.

Jessica Guistolise (31:39)
Yeah, thank you so much for having me. It's been a delight.

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 McGowan
Heather’s Website
The Adaptation Advantage by Heather McGowan & Chris Shipley
The Empathy Advantage by Heather McGowan & Chris Shipley
The UpSwing by Robert Putnam
Agile Training for Teams & Leaders
Subscribe to the Agile Mentors Podcast
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join 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 [email protected]

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 and think of something where we didn't have a contextual reference. And then I found myself working in higher ed because I had a mentor who became president of university and he said, I want to create a new college focused on innovation. And I think you understand it better than anybody else. So I built a new college focused on innovation. From those two sides, I saw the supply and the demand side of talent. And what I saw happening, and this is what kind of led to my speaking career, is we're not preparing people to do the kind of work we need people to do. We're hiring people based on past skills and experience degrees. We've now like edged all the way up to skills -based hiring. But what that really is, is hiring somebody who can demonstrate that they can do something you need them to do. What happens when they get there three or four months later and you need them to do something that's never been done before? So we need to prepare more people to do work that's never been done before. And how do you do that? I think you look more at behaviors. And then how do you activate those behaviors? So what you look for in people is some level of skill, but also behaviors that will tell you what they'll do when they don't know what to do. And that is basically what culture is. Culture is collective behaviors. So that's how you screen for people. And then how do you set the conditions to activate those behaviors? What we've done in the past is hire the skills and exert some hustle culture. And that's going to rev the engine of productivity. We did that until we hit burnout and we're still hitting burnout and we're still hitting burnout and unhappiness and disengagement. So we went from hustle culture to going, we need more engagement. we need shared purpose. we need psychological safety. Well, what's behind all of that is we need humans who feel seen and heard. Somebody cares about me. I trust my leader. You set those conditions to people who have agency and they'll activate those behaviors for which you hired them. And so they have some of the skills you need. They're going to have to acquire so many more because you don't know the work they're going to be doing. So we got to focus on what I say is culture and then people who want to build their capacity.

Brian (14:29)
Yeah, yeah, I love that point. And I think you're absolutely right. I'm kind of so we've been building towards skill based kind of hiring instead of behavior based hiring. And we should be looking more at building people who have the right behaviors to learn and grow and change and adapt. So I'm kind of curious your take on this, because I know that in the past few years, especially, I don't know if you've seen this, think I've noticed this in multiple sections, but there seems to have been sort of this segment of management that has returned a little bit, kind of tried to turn the clock back and gone back to a little bit of Taylorism and kind of the idea of, you you need to push and drive your employees to work harder. And I even see that in some job postings and things about how, you know, there's sort of a rise more traditional project management, is really more based on pushing and driving than enabling. I'm just curious, what's your take? Why do you think that's resurfaced?

Heather (15:41)
I think we got a lot of fatigue coming out of COVID. I remember us doing the sort of the press tour and everything for the Empty Advantage last spring. one, I was talking to a group of CEOs and they said to me, you know what, we're just tired of caring. And because they were being honest with me. And I said, well, explain to what you mean. And they said, well, I get it. We have to be empathetic and we have to feel bad for people and expect less of them. And I said, there's compassion and you should have that instances. And there's empathy and they are not the same thing. When I'm talking about empathy, it's about understanding the people that you're hiring and what motivates them so you can help them become what I call self -propelled. Because you cannot get people to learn and adapt at the speed, scale and scope we're gonna need through just extrinsic pressure. And there's a return to that right now. I think it's some COVID fatigue of just, you know, exhausted because people did have to care a lot for their people. But you know what, we had higher levels We had higher levels of engagement. had higher levels of productivity at the height of the pandemic because we were caring. And that was a little care fatigue. so the care fatigue hits a little economic uncertainty. We've been waiting for a recession. Inflation's been sticky. It's harder to run your business tomorrow than it was yesterday. Again, all those things. But a return to kind of the beatings will continue until the morale improves has never worked. But there is certainly a push to try that now. And I get But you're not going to get the performance out of people that way. just don't believe it. A very small percentage of people that works on most of us work best when we feel like we can trust our boss. We have agency. We have high expectations. I mean, all the studies that I've seen, the best jobs people had with the highest level of performance were when they challenged themselves, they had respect, they had autonomy, and they had agency.

Brian (17:33)
Yeah, yeah, absolutely agree. It just, it fascinated me when I saw that kind of return and rear its ugly head again and think, and my thought was, we've tried this, you know, like this is, it's not that this hasn't been tested and tried, we've run this experiment and it failed and we've progressed into this new era. And I think sometimes there's a leadership kind of misunderstanding that we're just trying to be nice. Like people just want us to be nice. And it's just about being kind of more friendly and kind. And that's what all these management consultants want us to be. there's a purpose behind it. It's because it works. It's not because it just makes you a better person, though it does. But it actually is better for your business to do

Heather (18:21)
Yeah, I think what happened is we had such a long stretch of Taylorism that we presume that that is the model that works. had four years of caring and we had good performance. And that gets sort of conflated with where we work, which I think is a completely separate thing. I think we've got to return to, not return to, we've got to go forward and to say, what did we learn in those four years? What are the things that really worked? How did we really better performance out of people. Because at the end of the day, it's what you're to do. It's why you run your organization. We are in a capitalist society. You're going to run your organization getting the highest level of performance. Highest level of performance and productivity is getting the highest level of performance out of your people. Highest level of performance out of your people comes when you trust them, they have agency, you hire for the right behaviors, you set the right conditions, and you encourage them to do things they never thought they could do. And that's what comes out of all the studies.

Brian (19:11)
Yeah. Yeah. And I know you, you, you drawn kind of this, this really interesting connection, I think between performance and, and mental health and sort of the idea of, you know, that we, again, building on what we've said, right? If our organizations are where we're seeking community and we're feeling lonely, then that this does impact how we work. so it shouldn't be that far of a leap for people to understand how, Hey, if, if, our work environments are damaging people's mental health, that directly impacts performance.

Heather (19:47)
Yeah, and you just look at the studies like, know, the companies that are ranked best places to work, they're ranked best places to work by the employees, because the employees are happy there. And you know what? Their performance is something like 16 % higher than the companies that are on the list. So it's pretty clear. You're getting the performance when people are happy, not you're going to get the performance. You're going to be happy when you get the performance. It's the other way around. We're looking at it backwards.

Brian (20:12)
Yeah, I agree. And one of the stats that jumped out at me in your presentation was this stat about how big of a role your direct manager or leader has on your mental health, just in general and overall in life. So tell us a little bit about

Heather (20:32)
Yeah, there were three different studies I think I cited in the piece you're talking about. First, the employer has a greater influence on your mental health than your spouse, partner, or therapist if you have one.

Brian (20:46)
That's so, I just got a full stop there. Like that is so amazing to me. Your boss has more impact on your mental health than your spouse. That just blows my mind, sorry.

Heather (20:57)
And the greatest source of stress in your life is your job. And then there was another study, which I thought was fascinating, and it was looking at lower paid workers generally not highly educated. The relationship, this was a longitudinal study, and it was only like four or 500 people, but they looked at your relationship with your direct supervisor. If your direct supervisor treated you with respect, gave you agency, gave you autonomy, you trusted them, you went home and raised your children such that they had higher levels of economic, social, and financial success. So not only is your boss influencing your life, you're influencing the next generation and thereby the next workforce. So there's a lot more we should be doing preparing these leaders for having this what is now an awesome responsibility. It's a really profound responsibility. And it's because I think work has become so outsized in our lives. And it's going to be. It's going to continue to be.

Brian (21:58)
Yeah. Yeah. So no pressure, leaders, right? I mean, no pressure on the fact that not only are you concerned with your business and your employees, but the future generation of workers. Right.

Heather (22:09)
And we need to help those leaders. We need to help them put on a gas mask before they try to help anybody else.

Brian (22:14)
Yeah, absolutely, absolutely. So, you know, we're in this, first of all, I think this is this huge dichotomy of, you know, as we said, we're in the age of people feeling lonely at work. While when we look at our process kind of evolution, we're in a teaming phase of process. We value, especially here, you know, an Agilist and people who practice Scrum. We're all about teamwork. It's all about working together as a team. So I'm curious, kind of your take on that. Why do you feel like we still have this sense of loneliness, even though we're trying to move more and more of our process towards being collaborative and team -based?

Heather (22:58)
I think we forgot to know how to connect to each other. And we can't get it all from work, but since we're looking to get so much of it from work, we need to figure it out there. I mean, how many, you know, they found these studies that, you know, you're happier at work if you have a best friend at work. It used to be that people met their spouse or partner through church work, or I can't remember the third one. Now it's mostly online. So even though we're in work, we're not. forming our social circles around work as much anymore. And it's not really, because this started long before the pandemic, so it's not just that we're working remotely and that's why our social circles aren't happening there. I think we forgot how to connect with each other. We forgot to say, how are you and mean it, instead of just waiting for fine. We forgot to have conversations that had something other than to do than what we're doing. We just forgot how to be human and have meaningful connections. And I think when you start having conversations with people about that, like I was just in Prague last month for a talk, and there was another speaker. And we connected beforehand, we sort of knew each other, and his talk was on human connection, my talk was on the future work as human, because all my talks are bespoke to the audience and what they need. And so we coordinated our two talks. And then while I was there, in his talk, he talked about how both of his parents died suddenly, within like three months of each other. And it was a really impactful part of his talk and an impactful part of the most important conversations you have in his life, in your life, et cetera. And then when I was in Prague, I got a call that said my father was dying and I had to leave. And I messaged him. And now we message each other every single day to check in with each other. It was a catalyst for a human connection you don't normally have when you share a stage with someone for five minutes. But I'm noticing more and more that people are trying to do They're trying to make more meaningful and lasting connections that are, you know, we talk about speaking, but really we talk about how are you? What are you going through? How's your breathing going today? What do you have on store for the weekend? And I've done that with a number of speakers who've become close friends. And I think more and more folks need to be, feel comfortable just reaching out and doing that and having a real connection with folks that doesn't have to do with a product that's due or a deadline or a financial goal or what have you, but has to do with. What we all want is humans, which is ultimately connection.

Brian (25:14)
Yeah, boy, I can't agree more. Well, we're getting towards the end of our time. before we wrap, one thing I wanted to ask is, we have listeners here that are leaders. We have listeners that are involved in Scrum teams. We may have some Scrum masters and product owners that are listening. And they're hearing this, probably agreeing a lot with what they're hearing from you. So my question for you then is if you were to talk to that group, if there were some advice you could give them, tips you could give them to better prepare them for the future of work, for where we're headed, what kind of advice would you give people currently working on Teams?

Heather (26:02)
I think the most important thing to figure out, and some people take a lifetime doing it, some people are born doing it, is what do you really care about? What kind of impact do you want to have on the world? How do you like to work? What kind of problems do you like to work on or find or frame? Where do you like to work in the process? Because more self -awareness you have about what really drives you, because that's really your fuel source, the better you're going to be in whatever you do. We tend to tell people, funnel people into careers based on what they're told they're good at, or more likely what they're told they're not good instead of focusing on what gives them energy. Because if we're going to have to learn and adapt, and we are, then we ought to be learning adapting around something we're intrinsically motivated to do.

Brian (26:46)
That's awesome. Yeah, I agree. It sounds very close to, you know, Simon Sinek's kind of find your why basis there of just, you know, that being so important in what drives us. So couldn't agree more. That's that's awesome. Well, I want to be respectful of your time and our listeners time. So, Heather, I can't thank you enough. Every time I hear you talk, I feel like I've taken another leap and have more stuff to go research and and study based off of it. So.

Heather (26:53)
Sure.

Brian (27:15)
Thank you so much for taking some time here to talk with us on the podcast.

Heather (27:19)
Thank you. And I just want to close with one thing because I'm a belligerent optimist. So we have some hard problems ahead of us. We've got division, we've got technology, et cetera. But we have done more in one human lifetime to improve the human condition than all of human history. We've more people out of poverty. We've almost solved literacy. We've connected the globe. It's time for us, in the words of JFK, take longer strides and do hard things. We are up to and we are more than capable of this. So I'm really optimistic about the future that's ahead of us. I think we just have to face some of our challenges. So thank you very much for having me.

Brian (27:53)
Amen, amen. All right. Thanks so much, Heather. I appreciate you coming on.

Heather (27:58)
Thanks a lot for having me. Take care.

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’Keefe
Dart Frog Consulting
Path to CTC - Monthly Cohorts
#109 Leadership and Culture in DevOps with Claire Clark
Agile for Leaders
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe 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 [email protected]

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 now I have a say in the process. I have a say in the outcome. So it's not like people are trying to just be difficult. They just don't know any better, which brings us to one of the other organizational impediments, which is lack of training and understanding. Cause we can't just train the team. We have to, yeah, I mean, we don't have to train everyone in, you know, a CSM or anything like that. That's, that's not it. Right. But they need to understand the basics of how, how agile works. What are the values? What are the principles? What, what are the benefits of working in this manner? Right. It's, it's not about doing the thing, but it's how is this going to impact who is and how, how are things going to be better after you start working this way?

Brian (12:52)
Yeah. I've had a lot of conversations about this in the CSM class of just talking to different people and saying, you look at these agile manifesto values and principles and if we can't get an alignment on these things, right? If we can't look at these things and say, yeah, I agree. My philosophy is one of that's responding to change over following a plan. I believe that you should be more. able to respond to change, then you should be about following a plan. That's a fundamental kind of core value. And if my organization or if leaders in my organization, that's kind of the key here, right? If the leaders in the organization think, no, no, no, it's about following the plan. We have to establish this amazing plan and then follow the plan. Well, it doesn't really matter what we do at the team level because... somewhere up the chain of command, we're going to have to have that perfect plan that we try to execute on and the leadership is driving that. So we have a mismatch on just our core kind of understanding.

Lucy O'Keefe (14:26)
Exactly, exactly. So when I go into a new organization, one of the first things I do during my assessment phase, I actually go through every single one of the values and principles with leadership and with the teams. And I ask, which one of these are you doing well? And then we talk about that it's the minority usually. And then it's like, okay, what do we need to do to ensure that we are responding to change or following a plan or that we are... you know, focusing on working software instead of measuring something different. So we go through every single one of those because, as you said, that's where the value is. Understanding those values and principles, it's not about doing scrum, kanban, whatever it is. But if we are following those values and principles, then that's when we're truly going to be algebra and that's when we're going to see the benefits of working in this manner. It's not about the practice, but it's about your beliefs as an organization.

Brian (15:24)
Yeah, yeah, there's no practice that we're gonna put in place that's gonna solve it all, right? I mean, there's practices that can assist and help us, but the practice isn't the cure, right? The practice is just something that can assist. It's like having crutches, you know? The crutches aren't gonna heal you.

Lucy O'Keefe (15:30)
Not at all. A way to get there. Yeah. Exactly. Right. Yeah, yeah, yeah. The practice just a vehicle, but you have to do the work to get there for sure.

Brian (15:51)
Yeah, that's a great point.

Lucy O'Keefe (15:53)
Yeah, so I think those were the main ones that we talked about there. You know, of course, we only had an hour, so it wasn't, there wasn't a lot of time to talk about every single one. But I think that, you know, and you were there, of course, but a lot of people came up with their own impediments that they were seeing in their organizations. And I think a lot of them aligned to what we had to say as well, because I think it is pretty standard in organizations that are just starting out.

Brian (16:02)
Sure. Yeah.

Lucy O'Keefe (16:22)
that you are seeing a lot. I mean, not just starting out actually. I mean, I've seen an organization that they say they've been agile for years and they still have a lot of these issues. So it's pretty clear that the culture again is the biggest issue with being able to adopt Scrum correctly or adopt an agile way of working correctly.

Brian (16:43)
Yeah, and I think you hit the nail on the head with the fact that it's just, there's not the time always spent to try to get to the root cause. We're a culture of quick fixes. We want to find something that's going to put in place and take this pill, do whatever, and then it's just going to be solved and everything's going to be fine. But you know, it... For instance, we've used this analogy quite often, the idea of weight loss. There are things that can assist you with that. There are things that can give you help along the way, but there's not a silver bullet to do that other than changing the way that your lifestyle is. You have to change. And please, anyone who's listening, don't think I'm saying this because I have this perfect, because I don't. I'm very bad at this. But I know that the way that I change You know, my overall health is by changing the lifestyle, changing what I eat, changing, you know, my exercise patterns. And that's hard work. It's hard to change that kind of core value in my life, but that's what actually makes the impact. The other things are dressing around it. Right.

Lucy O'Keefe (17:58)
Yeah, that's what's gonna make you change. Exactly. I mean, think about people who go for, and just staying with the same topic, right? For some bariatric surgery, right? So a lot of times, like the doctor will say, I used to watch my 600 pound life, don't judge me, a little bit, just because it's kind of, it's interesting. And yeah, I mean, they'd have to lose weight before they had the surgery.

Brian (18:06)
Yeah, yeah. Hahaha.

Lucy O'Keefe (18:25)
And the majority of people after they had the surgery and kind of lost weight, they just went back and balloon back up because they didn't change their lifestyle. So as you said, yeah, it's great that these band -aids exist, but if you're not going to do the work yourself, then it's really not going to work. So what is the root cause in this case, right? We're eating badly and we're not exercising. So that's what we need to change and not just, you know, take a pill or do a fad diet or get a surgery that... It's not gonna work if we don't change our ways.

Brian (18:55)
Right, and just for the listeners too, I mean, Lucy and I are not medical professionals in any way. So, you know, we do not mean in any way to try to belittle, you know, treatments and therapies that people use for legitimate purposes and all that stuff. Please understand, right? Gotta make that disclaimer. But I think you're right. You know, like I know in my life, there's been times when I thought, there's some diet supplement or there's something else that, you know, is gonna...

Lucy O'Keefe (19:01)
No. No, no, no.

Brian (19:25)
be the thing that really cures this and changes it. But what I've experienced time after time is, no, you really just got to do the hard work. You got to go to the gym and you got to get up and you got to change what you eat and that kind of stuff. And that's what really makes the impact. Well, the same thing here with our organizations. There are practices and the things we can put in place. And there's always hot ones that will be the hot one of the day. I remember when DevOps was kind of the... And we just talked about DevOps in our last episode. It is an important thing. It is a very important thing, and it can give you a lot of boost. But it's a set of practices. And our last guest, when we talked about this, talked about how it's really more of a mindset. It really is more about how we have to change the way we see things. So even there, when we approach things like DevOps, yes, there are practices, there are tools we can put in place. But if we don't change kind of our approach to how we do things, then it won't matter. It's just another thing that we have to learn and put into the workflow.

Lucy O'Keefe (20:32)
Yeah, yeah, exactly. I mean, you know, the definition of insanity, right? Doing the same thing over and over and over again and getting the same results because that's what happens if you just keep putting band -aids on things, you're going to end up, you know, encountering the same issues over and over again. So if we don't have that mindset that we are going to make the change and the foundational change to ensure that everything works out, then, you know, then it's we're going to keep having the same issues and we're going to keep hearing this crime just doesn't work for us. Right.

Brian (20:37)
Ha ha ha.

Lucy O'Keefe (21:02)
So, yeah.

Brian (21:04)
There's something that also comes up in classes sometimes that I think one of the things that I found is that getting back to that transparency inspection adaptation, that if we as an organization really value that process and value the idea that, hey, we're going to be transparent about how we do things. We're going to not just ignore when there's a problem, but we're going to inspect it and get to the root cause. And then we're going to find a new way of doing things. that we can just latch onto that. That's a huge cultural change, right? And just kind of buying into those concepts. And what I found is in a lot of instances, I talked about this in the ACSM, a lot of instances, you can directly relate it back to a lack of one of those three things. Are we not being transparent? Are we not actually inspecting? Are we not actually adapting?

Lucy O'Keefe (21:57)
Yeah, yeah, yeah, those three pillars are definitely important. And I think that they're the foundation of what we are trying to do. And you're right, if we're not being transparent, inspecting and adapting, then we're not being agile, first of all, but that's something that needs to exist throughout the organization, not just within our work, within our teams, but are we being transparent in our relationships? Are we inspecting and adapting how we are dealing with our employees? Are we inspecting and adapting how we are budgeting? I mean, everything, right? We need to be... using that empiricism on a daily basis to ensure that we are headed in that direction. And if we do that, as you just said, the culture will shift organically when we're employing those three pillars, for sure.

Brian (22:42)
Yeah, absolutely agree. Well, let's, I want to meta this a little bit more here at the end, because I want to know kind of how it, how the fallout from this happened. So, so you, you have this idea, you work with Joe, you, you come up with this topic, you go, you present this. What kind of a follow -up did you get from this? Did you get a lot of good questions from people afterwards? How did the talk go? What did you, what, what, what kind of learnings did you take away from it after you gave the talk?

Lucy O'Keefe (22:47)
Yep. So I think it was received very well. There were quite a few people that came up to us afterwards and started asking questions to the point that I was actually late to a meeting after that. But anyway, I've had quite a few people reach out to me on LinkedIn, you know, talking about, we really loved your topic. And I actually, I got my reviews from it. And I think a lot of people appreciated that we had action items at the end.

Brian (23:22)
Hahaha.

Lucy O'Keefe (23:38)
So for those of you who are listening, we actually had an action plan where people could create an action plan on how they are going to start dealing with the organizational impediments in their organization. So a few people appreciated that. So it was pretty good, you know, pretty good feedback, I think, that we got from that. I would have loved for it to have been a little longer, so we could have gone a little deeper because it is, there is a lot that we can unpack. when we're talking about organizational impediments, one hour just isn't enough time for that, especially when you're trying to make it a more engaging session and not just talking at people. But I think if I had to do this again, I would probably try to do a little less and maybe go a little deeper instead of trying to talk about maybe so many things and barely touching the surface. But I think it was...

Brian (24:28)
Yeah.

Lucy O'Keefe (24:36)
I think it was pretty good. I know you're there, so you let me know.

Brian (24:38)
It was great. Yeah, no, it was great. And so, yeah, I hope you're encouraged by that. But yeah, it was a great talk. And like I said, I heard a lot of good comments from people afterwards. And I think that's pretty natural for us as speakers to kind of rethink afterward and say, maybe I could have done this a little bit different or I could have done this a different way. But, you know, it's tough. Like you said, you've got an hour. And within that hour, you're trying to work in some... interactivity, so it's not just you talking the whole time and you're trying to keep the group engaged. But then you get a lot of information and you just, I got to share all this stuff and I only have an hour to do it. Especially, as CSTs, we're used to talking for two days at a time. So, yeah, an hour is like, you know.

Lucy O'Keefe (25:26)
Exactly. So an hour is nothing. Yeah. Yeah.

Brian (25:32)
the break or something, but yeah, you're not used to trying to fit all that information down into a one hour stretch.

Lucy O'Keefe (25:40)
Yeah, and for me it's like I love answering questions. Like if I could do a talk and then do an hour of just answering questions, I think I'd be like really, really happy because I mean, even when I've, you know, taught with Mountain Goat and all that, you know, being able to answer questions at the end of class, that's like my favorite and I do that in my classes as well. So not being able to give time to actually answer, you know,

Brian (25:47)
Yeah.

Lucy O'Keefe (26:04)
questions from the people who are having the issues for me was very difficult not being able to do that because that's something that I enjoy. And, you know, but at the end of the day, I do love speaking. You know, I just, it's one of my passions now, which is kind of funny because I used to be really introverted. But yeah, I think, I know it was a really good experience. It was my first time speaking at the Scrum Gallery. I've spoken at smaller conferences before, but that was my first big one. So it was, it was great.

Brian (26:19)
Ha ha. Awesome.

Lucy O'Keefe (26:34)
I hope I'm able to do it again.

Brian (26:36)
Awesome. Well, it was great. It was a great talk. And I appreciate you coming on and sharing this information with us, because not everyone can come to the Scrum Gathering. And that's one of the reasons why we try to have some people come on that do speak at it, so we can share some of that information in these small little podcast windows. So. Well, Lucy, thank you again for coming on. I appreciate you sharing your talk with us and kind of the behind the scenes of it. And hopefully we can have you on again soon.

Lucy O'Keefe (27:11)
Thank you, Brian.

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 Clark
Sienso
#108 Adaptive Organizations with Ken Rickard
Mountain Goat Software’s Working on a Scrum Team
Join the Agile Mentors Community
Subscribe 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 [email protected]

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't come with the fundamental, the heartbeat, so to speak, inside that really embraces the principles behind some of these things. And it's that where the cultural side comes in that people really do not just read the words and say collaboration. They act it. They do it. They...

Brian (14:54)
Yeah.

Claire Clark (15:21)
you see them behaviors and I think sometimes with Agile and DevOps some of the principles or the value that you get out of them once people describe them they love it, they say it sounds great yeah we should do at DevOps we should do Agile but if they're missing that connection to the heart underneath the value is the principles. even if they sound great, if they don't exhibit the behaviors, that will affect the culture. And you often can see that in teams where, you know, the quote processes, quote tools, but then the behaviors are almost opposite to some of the values that underpin agile and underpin DevOps. And then, yeah, for me, I would say you've got to try to tackle both together.

Brian (16:08)
Yeah.

Claire Clark (16:13)
And you just won't really get the success and the team won't enjoy it. Yeah.

Brian (16:19)
Yeah. So I think one of the things I've seen too, when people implement DevOps is they kind of miss, it seems like they miss the heart of it, the point. If you had to sum it up, what would you say is the purpose? Why do we need DevOps? What is the purpose that the DevOps, a good DevOps team, what's really their driving purpose?

Claire Clark (16:29)
Yeah. You see it work really well with teams, the successful teams, when their focus is about continuous integration and delivery of functionality to customers as quick as they can, not, but without, you know, still with the quality and the stabilization. But they, they focus quite a lot on that optimizing that, you know, how soon can we break something down, prove it, test it. And get that out to the customer so the customer can realize the value. So for me in the, in the DevOps, it's where the teams really focused on making that, that channel of that functionality is seamless as possible and making it as efficient as possible so that, you know, it is from end to end, create the product and it's good to go as soon as possible. So. It's less about when you hear people talk about tooling. It's more when you hear them, the thinking shines through in what they're saying. In how can we get that sooner? How can we, how can we use the principles to get value to customers and prove what we're doing is right along the way.

Brian (18:05)
Yeah, and it overlaps perfectly with what we're trying to do in Agile with delivering value. And I love that kind of marriage that it seems to have there. How about from a leader's standpoint, what is important for leaders to understand? How can leaders better support DevOps in their organizations?

Claire Clark (18:28)
found that from a leadership perspective, and I've supported teams on this, is being open about how different it might feel and how different that might be in terms of where we're working. And having an initial discussion to check with people, their understanding of what DevOps is before you start going on that journey. So one exercise I did once was, just simply to ask everybody in the room before we started going on that kind of DevOps journey. What is DevOps? What do you believe it is? And the responses in one team alone was incredibly different. How they described it, someone said, it's someone's job over there. It's to do with, it's like that way. And then, yeah, described it as it.

Brian (19:18)
It's Jenkins.

Claire Clark (19:24)
It's nothing to do with me. I'm software engineer or I'm tester. It's more business and support type things. And I think doing that exercise at the start was really good to sort of understand and appreciate where we're actually starting on that journey and where even misconceptions have come in or where people have not had the opportunity to somebody to share and explain to them what. What in essence is DevOps? And, you know, same response again, a lot of names of toolings come up and, you know, there's this tool, this tool, this tool. And so with Agile, I tend to talk about things like there's the principles, the values, frameworks, and, you know, when we started to describe DevOps in a similar way to the team, they were able to relate that to that structure that you get with Agile. where I was saying, in essence, there's some principles behind this. There's some aims, some aspirations, some goals that we're going for. Just put the tooling aside for the moment. We can change the tools, whatever tool we want, but if we just focus on that. So I've sent her a lot of the discussion around that initially. And from there, that's when as a leader, you can start to then move on to some of the processing tooling. But I think you've got to really listen to the team. understand the challenges they've got in how they work now and what would it mean on a change management perspective to migrate to that kind of more DevOps way of working. So you've got to listen to your team. You've got to understand the products at hand that you're working with and support the team as much as you can on that, both from process tooling, but on that mindset. because of us, if you don't, what you end up with is a lot of friction in a team and a lot of friction against the thing like DevOps and pretty much what I think you saw in the industry when a lot of organizations moved from waterfall to agile. There was some people who, you know, they read about it. They loved it. They're on the journey. Let's try it. Let's go. I get it. And then there was some people where they just had that struggle that, that.

Brian (21:26)
Yeah.

Claire Clark (21:48)
What do you mean? So if I'm in traditional way of working, how does that translate to the new way? And you've got to take that time as a leader to allow people to have that open debate around it and support one another to really understand that fundamental side of it. And I think often a lot of organizations hear about DevOps or hear about Agile. And within a couple of months, that's it. The one agile in DevOps in get all the benefits. It sounds great. But as a leader of a software team where you're trying to introduce that you have to appreciate that every team's journey is different and approach it as needed. And that it might not be a quick five minute. If it definitely isn't to turn that around. And, and you can start getting some of the benefits incrementally along the way. I was like agile, I would say. And eventually you'll get the full benefits that people buy into when they hear about these amazing ways of working that will bring them so much better opportunity.

Brian (22:59)
Yeah, I think it's such a great point too, because like you said, if you have a misconception about what this is and what our purpose is, where our point is, we talk about individuals and interactions over processes and tools, and we look at that and we actually dissect it and start to think about it as an organization and decide, you know what? No, we really are more process than tools over individuals and interactions, then that's going to be a problem.

Claire Clark (23:26)
Yeah. Yeah.

Brian (23:28)
You know, that's gonna be, we're not gonna be successful because we don't have that cultural value that underpins kind of why we're doing things the way we are.

Claire Clark (23:40)
Yeah. Yeah. And, and exactly that, when you say about the, the interactions and then behaviors and so on in, in a team and then over, you know, processes and tools, it's, it's often that side of it. What in some organizations is the afterthought and you know, the tooling space, just get this tool and it'll help us with this. Then get the process on the tool so we can get the benefit from the tool. And then afterwards it's, let's help the people who are not on the journey with this, are struggling with the journey and so on. And, and I tend to think it's, focus on, on what their understanding is, the alignment, get that shared understanding. like what we do through our job as working, get the shared understanding. And then once you've got that alignment as to what it actually means in principle and. everybody can feels they can understand and appreciate that. That to me is where all the other aspects just become easier. But naturally it tends to be focused the other way around on get the benefit. We need to get the tool, we need to then get a process for the tool and then let's work out where everyone's happy or not.

Brian (25:01)
Right. So you've done these kind of transformations in multiple places. How have you traditionally tried to measure success? How do you know where you are in your journey of this DevOps transformation and what are you aiming for as a successful endpoint?

Claire Clark (25:20)
Yes, I often, I sort of built, maturity matrix on a lot of these things. So from agile and DevOps, and in there, I cover that human side of it. There'll be heavy side. And from a maturity perspective, I kind of benchmark it at the basics and then eventually it gets more mature and eventually it becomes self kind of, I guess, running and organizing and. There's certain behaviors and process, maturity that you expect to see at each kind of stage of that journey. So you might start off at the beginning, it's chaotic, there's that misalignment on what everyone thinks this is. and you know, you build on that over time and you just keep rechecking on that maturity kind of this and that score. Where are we at across all of those different things? And it's quite easy then to assess and say, was, was, was, we're getting better, but we're not a kind of self sufficient, systems running. Everything's quite independent kind of model. And then obviously you get to the point of utopia where it's smooth, it's running. We're constantly looking at how we can improve this. and we take action, self -action to do that. So I tend to like look across the horizon of agile and DevOps and team culture. and behaviors. And at that, that's where I kind of understand then what level we are at the moment, where, which areas in particular do we need the most support? And that then kind of shapes how I approach things with that team, the speed at which you maybe then try and bring some of that change in. But importantly, what actions I need to do to, to support that team on that journey of maturity. And like I said, each team different and some it's easier to move up through that maturity across all those pieces than it is for others. But you've just got constantly like with Agile and DevOps looking at how can you improve what you're doing now? And it is a journey you can always improve. And to get there, you've got to have that goal. You've got to have something to aim for. What does good look like? and have that as a common goal across the team. So we know what the North Star is, we know what we're aiming for, we know that, you know, we really, really are agile, really are doing boxing, getting benefits out of this. And then really be honest about where you are as a team and then work with that team to support them on listening to if they've got ideas and perhaps, and best practices in there that they've maybe done somewhere else before they want to apply. But... For me as a leader, the biggest thing I can do is all those learnings that I've got from all the different experiences is to bring that to that team, share that and say, I've seen an example like this before. This is what we've tried. How would we want to try that here? Because along my journey to success and like you said earlier, winning these awards and so on, it... It's been a challenge, you know, without doubt it's, it's, it's software development can be difficult. Developing teams and bringing changes into business is not easy. And along the way I've learned, you know, some really good practices. And I think as a leader, you've got to really be able to come in, appreciate the team and the scenario that you're in and work out the best path forward. And every path of every organization is different. but you can use your experience to work out how to navigate through that journey. I think the key thing to do as a leader is to appreciate that every team, every organization you work with has a different journey. But what you have learned along the way as a leader is where the wrong turns are, where you can get the most efficiency, where common problems are, but importantly, how you've managed to overcome them. How... You know, learning that is difficult, but using that and having that appreciation with the team to impart your experience and share that with them. Listen to them. And the biggest thing I ever says, I'm on this journey with you. I'm not here to do this journey at you. I'm here to help you on that journey. I can show you what a kind of good Northstar looks like, but I'm in this with you. I will support. We're in this together.

Brian (29:52)
Yeah.

Claire Clark (30:05)
And as a leader, I'll do what I can to help you on that journey with the experience I've got. I'll make it as easy as, as it can be. And so, yeah, I think that that's the key thing that I've kind of led from, I guess, in my leadership side of things is it's not you come into an organization and take them on an agile journey, take them on a DevOps journey. You're going on that journey with them.

Brian (30:32)
I love that. Yeah, that's a great point. That's such a great leadership point. Well, Claire, I can't thank you enough. This has been so eye opening and there's so much great information here. And easily could go on for another hour talking about this stuff. But thank you for taking your time and sharing your wisdom with us and with the group here at Agile Mentors.

Claire Clark (30:55)
Thank you. Thank you so much for having me on the podcast. Yeah, I've really enjoyed it.