Agile Mentors Podcast from Mountain Goat Software

#131: Lessons from Modern Agile with Joshua Kerievsky

Is Agile still relevant in today’s fast-paced world? Brian and Joshua Kerievsky reveal the four game-changing principles of Modern Agile that prioritize safety, empowerment, and continuous value delivery.
Overview
In this episode, Brian Milner sits down with Joshua Kerievsky, a pioneer in the Agile community and the creator of Modern Agile.
They discuss how Agile practices have evolved, the critical role of safety and empowerment, and how to deliver value continuously in today’s fast-paced world. Don’t miss these insights into creating better teams, products, and results through simplicity and experimentation.
References and resources mentioned in the show:
Joshua Kerievsky
Industrial Logic
Joy of Agility by Joshua Kerievsky
Modern Agile
#33 Mob Programming with Woody Zuill
#51: The Secrets of Team Safety with Julie Chickering
Badass: Making Users Awesome by Kathy Sierra
The Power of Habit by Charles Duhigg
The Lean Startup by Eric Ries
Experimentation Matter: Unlocking the Potential of New Technologies for Innovation by Stefan H. Thomke
Agile For Leaders
Mike Cohn’s Better User Stories Course
Accurate Agile Planning Course
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 podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Joshua Kerievsky is the founder and CEO of Industrial Logic and author of Joy of Agility. An early pioneer of Extreme Programming, Lean Software Development, and Lean Startup, Joshua is passionate about helping people achieve genuine agility through principle-based approaches like Modern Agile.
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 here as I always am. I am Brian Milner and today I am joined by Joshua Kerievsky and really excited to have Joshua here with us. Welcome in Joshua.
Joshua Kerievsky (00:16)
Thank you so much, Brian. Happy to be here.
Brian (00:19)
Very excited for Joshua to be here. Joshua's been around for a while. He's been doing this for a long time. He said, you know, when we were talking before, and he's been involved with Agile before, it was called Agile. And, you know, that probably tells you all you need to know there. But a couple other things here about him, just so that you kind of can place him a little bit. His company is Industrial Logic, Inc. and he's the CEO and founder of that company. He has a book called Joy of Agility that's out there that I highly recommend. It's a really great book. And he's also closely associated with something that maybe you've been aware of, maybe you've heard of, maybe you haven't, but something called Modern Agile. And that's what I thought we'd focus on here for our discussion is really to try to understand a little bit about it. especially for those of you, maybe you haven't heard of it, haven't been around it before. So... Why don't we start there, Joshua? Tell us a little bit about what was the need that was trying to be filled with something like modern Agile.
Joshua Kerievsky (01:19)
Well, it goes back to a conference I attended in Prague back in around 2015. And I was giving a speech, a keynote speech there, and that ended. And then I went and said, well, I'm going to go join the OpenSpace. And I was just looking at what people were talking about at the OpenSpace. And at that point in time, I had already been experimenting with a ton of stuff that just kind of different from what we had been doing 10 years earlier or even later than that. I mean, just this was new things that we were doing, whether it was continuous deployment or ideas from lean startup or ideas from the Poppendiecks and lean concepts applied to agility or just a lot of things that were just different. And none of the sessions I was seeing in the open space seemed to be talking about any of that stuff, like giving up story points or moving away from sprints until continuous flow. just nothing was being talked about. So I just said, well, I'm going to host a session, and I'll call it, I don't know, a modern Agile. And so that's as far as I got in terms of thinking about the name. I just wanted to run a session where we could talk about, there's a lot of new things we're doing that kind of display some of the older ideas. And they're very useful, I found. So the session ended up getting a lot of attention. 60, 70 people showed up there. So we had a big group. And it was well received. People were fascinated by the stuff that they weren't aware of. And so I then repeated this open space event in Berkeley. Like a month later, was Agile Open Door Cal in Berkeley was running and did it again. And again, there was tremendous interest. in this, so much so that I decided to write a blog and wrote the blog and started getting more conversations happening. And that sort of began the movement of describing this thing called Modern Agile. And it took a few twists and turns in the beginning, but it wasn't sort of, I guess, if anything, I felt like Agile needed to be a little more simple. in terms of what we were explaining, because it was starting to get very complex with frameworks, enterprise frameworks coming along like safe and just too many moving parts. And so what ended up happening is I wrote some things and people started to notice, there's kind of like four things there that are really valuable. One of them was The names changed a little bit over time. But anyway, what ended up was four principles emerged. And that really became modern Agile.
Brian (03:58)
That's awesome. just for listeners here, I've pitched attending conferences in the past. If you've listened to this podcast, you've heard me say that, and I'll create things come out of that. And here's an example, right? This is something that was open space discussion. Open space, if you're not familiar with that, at conferences, can, if there's an open space day or a couple of days, then anyone can present any topic they want. And whoever shows up is who shows up. And this one got a lot of attention. And a movement grew from this open space topic, which is awesome. So let's talk. You mentioned there's four principles here. And I like the distinction here we're making also between the frameworks and the practices versus the cultural aspects or the philosophy behind it. And returning to those roots a little bit more from what Agile originally was. So you mentioned there's kind of four areas of this. Let's walk our way through those. I know the first one, or one of the first ones here is make people awesome. So help us understand, what do you mean by make people awesome?
Joshua Kerievsky (04:59)
Probably the most controversial of principles, because you'll get people coming along saying, wait a minute, people are already awesome. What are you talking about? And it comes from my, I'm a big fan of Kathy Sierra. And her blog was incredible. And her book, she wrote a book called Badass, Making Users Awesome. And in her book, she was really wonderfully clear about
Brian (05:07)
You
Joshua Kerievsky (05:24)
that teams that build products ought to focus on the user of the products more than the product itself. In other words, she would say, don't try to create the world's best camera. Try to create the world's best photographers. Big subtle difference there. Like that is focusing so much on empowering the users, making them awesome at their work or whatever they're doing, whether it's art or accounting or whatever, whatever your product does, how can you give them something that elevates their skills, that gets them to a point of awesomeness faster? And that's what she was talking about. So I thought, what a wonderful message. And initially, I used language like make users awesome. you know, having been an entrepreneur myself and created products and sold them and You learn a heck of a lot when you make your own product. And we've made several products over the years at Industrial Logic, probably the most successful of which was our e-learning software. And that has taught me so many, so many lessons. One of them is you have to serve an ecosystem of people. You can't just make your main user awesome. What about the person who's buying the software? How do you make them awesome in terms of helping them buy something that's going to get used? If they buy your e-learning and they never use it, they've wasted a lot of money. So we've got to make sure that their reputation is intact because they made an excellent investment and it got used and it got into valuable, it created value in the company. So how do I make the buyer awesome? How do I make the person that like rolls out the licenses to people awesome? How do I make their experience awesome? How do I make my colleagues awesome so that we love what we're doing and really enjoy working together? So it kind of morphed from make users awesome to make people awesome. And it's so expanded. If anything, we set the bar higher. And all of the principles of modern agile are like unachievable. They're all kind of high bars, right? But they're the goal that we go towards. So that really is it. It's about creating
Brian (07:23)
Ha
Joshua Kerievsky (07:35)
you know, wonderful, you know, the in Great Britain, they use awesome kind of sarcastically sometimes, right? They'll say, well, that's awesome. You know, and so for them, it would be brilliant. You know, I thought of making an English version. We have many translations of modern agile, and I thought of making an English version, which would be a proper British English version, make people brilliant. But it's meant to be to empower folks to give them something. And it's so it is.
Brian (07:43)
Ha You
Joshua Kerievsky (08:04)
It does have a product focus in the sense of we're typically building a system or a product that someone's going to use and it's going to give them skills they didn't have before or abilities they didn't have before that are going to be very valuable.
Brian (08:18)
Yeah, I love that. And there's a sort of a servant nature to that servant leaders, not servant leadership as much, but servant nature of I'm serving these people and how do I, how do I serve them in a way that really empowers them? Kind of reminds me of like, you know, the, the great principle with, with dev ops of just, know, if I can, if I can empower the developers to be able to do these things on their own. And so they don't need someone else to come and check the box and do everything for them. You're making them awesome. You're empowering them to be more than they were otherwise.
Joshua Kerievsky (08:54)
Yes, yes, absolutely. I I think we've seen a history in the software field of a lot of tools coming along and helping. It's not just tools, it's also methods as well. I mean, I'm entirely grateful to the Agile software development movement because it helped nudge everything towards a far better way of working and to make us more awesome at our craft. yeah, you have to have a North Star though. If you're going to build something, You have to know, what are we going for here? What are we shooting for? And with Cathy's influence, again, it's not so much make the greatest product in the world. It's, that focus on the users, the people who are going to be using the work, using the product.
Brian (09:34)
That's really good. Let's talk about the second one then on my list here, the make safety a prerequisite. What was the point here behind this principle?
Joshua Kerievsky (09:40)
Yes. So starting probably around 2011 or so, I could not stand going to the Agile Conference anymore. It had just become too commercial and too filled with just people hocking stuff. And it just was bothering me too much. I couldn't go. So I ended up going to South by Southwest, which is an
Brian (09:54)
You
Joshua Kerievsky (10:09)
Enormous conference tens of thousands of people show up So it'd be 20,000 30,000 40,000 people showing up for these for this event, which is musical film technology just it's just wild and I came across this book by Charles Duhigg called the power of habit. He was there that year and In that book. Well, first of all that particular year was 2012 that I went my first year there it poured The rain, it was every day, it was unusual for that time, but it was just like pouring rain. So what could you do? I bought some books and I was sitting there in my room reading them. And I'm reading this book, The Power of Habit, and I come across this chapter called The Ballad of Paul O'Neill. Now who the heck's Paul O'Neill? Well, it turns out Paul O'Neill is this incredible guy, a complete business maverick. He ended up becoming the treasury secretary under Bush and not. in 2000 for a short period of time, but that's another story. And he ran Alcoa for about 13 or 14 years. And so the Ballot of Paul O'Neill is very much about what he did at Alcoa to turn the company around. And in essence, you could say he made safety a prerequisite. That safety was his guiding light in turning that company around, which meant left people empowered to do all kinds of things. So it went way beyond safety, but started there. And it's an incredible story. I've written about it in Joy of Agility. I got so into Paul O'Neill that I ended up interviewing his main lieutenant. And then I got a chance to interview him a couple of times. the man's a genius. He passed away a few years back. Absolute genius. this concept of safety started to really pull at me in the sense that I felt, first of all, extreme programming, and I'm a big practitioner of extreme programming, brings a tremendous amount of safety to software development. It may not be as explicit in saying safety, safety, safety. When you look at extreme programming, doesn't really talk about safety, but it's implicit. And these days, Kent Beck's much more vocal about, you One of his missions is to make software development safer for geeks. But safety to me is almost like I found my home. Like safety was something that, what I learned through Paul O'Neill was that it's a doorway to excellence. And he transformed a hundred year old company with safety. I would complain about companies we were working with that were 25 years old and had an embedded culture. Like, how are we gonna change this company? But safety started to be this thing that I hadn't really thought enough about, and making it explicit opened up a lot of doors, right? And I became very interested in the work of Amy Edmondson, who's extremely famous today, but back then she was not so famous. And huge fan of hers. I, you know, I can email her and she'll email me back and she wrote a nice thing about my book. So. She has done some incredible work there. And so when we talk about safety in modern agile, it's psychological safety. It's financial safety. It's any of the safeties. There are many safeties that we could talk about. And it looks at all of them, right? It's brand safety, software safety in terms of security. you know, of the software and on and on and on. So make safety prerequisite is vast and big in terms of what we're trying to do there. Making it a prerequisite means it's not an afterthought and it's not a priority that shifts with the winds. It is permanent. It is something that we know we have to have in place. And it's very, very hard to achieve. Just like make people awesome is hard to achieve. Boy, is make safety a prerequisite difficult.
Brian (13:43)
Hmm. Yeah, I love Amy Edmondson's work as well. I'm just kind of curious. does the safety kind of inclusive of things like quality as well? Do you intend that to be part of what you mean by safety?
Joshua Kerievsky (14:11)
Well, mean, to the extent that it makes it safer to do good software development. So if bugs are happening all the time, you can't make people awesome, typically if you don't have quality. If you have really poor quality, nobody's being made awesome. They're experiencing all kinds of problems with your product. So make people awesome and make safety a prerequisite are very much tied together. That is, there is no real excellence without safety. You could think you're having an excellent experience, so that all of a sudden there's a major problem, and boy, are you unhappy. So they really go hand in hand. You could have the most incredible restaurant, and then one day you've got food poisoning happening. Great, no one's come to your restaurant. So you will not make anyone awesome if you don't make safety a prerequisite, and quality is part of that.
Brian (14:57)
Awesome. Well, let's move on to the next one then, because the next category is one that just resonates with me a lot. Experiment and learn rapidly. What was kind of the thought behind this one?
Joshua Kerievsky (15:06)
Yeah, and this is one where it that's shorthand, if you will, because you can only fit so many words on a wheel there. But it's important to know that that really means experiment rapidly and learn rapidly. And that comes a lot out of it in the influences of something like Lean Startup. I'm a huge fan of that book and of Eric's work, Eric Reese's work.
Brian (15:13)
Ha
Joshua Kerievsky (15:29)
And the fact that we can experiment rapidly and learn rapidly rather than just building everything and then learning slowly. Right? How can we do cheap experiments quickly to decide what's important to work on and what isn't? Let's not build stuff nobody wants. Let's find more time with our customers and understand their needs better so we can build the right things that make them awesome. In other words, and a lot of these are interconnected. In many respects, modern Agile is a Venn diagram. ideally want all four principles to be overlapping. And right there in that middle is where you really want to be. Not easy. But experimenting, learning rapidly, yeah. So challenge yourself to find ways to do quick, cheap, useful experiments. You can do lot of unuseful experiments. Amazon experienced that. There's a story in my book about how Amazon had to start just shepherding the experiments a little more and having some better criteria. Because you could do an endless array of experiments and not get anywhere. There's a wonderful book called Experimentation Matters by a Harvard business professor. Wonderful book as well. But I love experimentation and learning. And I see it as critical to building great products. So that's that principle there.
Brian (16:46)
Yeah, there's a real difference, I think, in organizations that put value on that learning process. if you see it as a valuable thing, that we invest time to gain knowledge, then that really can truly make an impact when you go forward. I know I've talked about this in classes sometimes where people will say, isn't it a little bit selfish from the organization to try to always just figure out what's going to sell the best? or what's going to work the best in advance of putting something out. My response is always, well, yes, there is a benefit to the business, but there's a benefit to the customer as well because they would rather you work on things that they care more about.
Joshua Kerievsky (17:24)
That's right. Yeah. I mean, we once put out an experimental product to a large automotive company. And we were really excited about it. We had a whole list of features we wanted to add to it. But we were like, you know what? Let's just get this primitive version kind of in their hands just to see what happens. it turned out that we learned very rapidly that they couldn't run the software at all. There was some proxy. that was preventing communication with our servers from their environment. So it was like, excellent. We learned really quickly that instead of those fancy new features we want to add to this thing, we're going to fix the proxy problem. And to me, that's the nature of evolutionary design is that we create something, get it out there quickly, and learn from it rapidly and evolve it. So it goes hand in hand with that as well.
Brian (18:11)
That's awesome. Well, there's one category left then, and that is deliver value continuously. So what was the genesis of that? Thinking about delivering value continuously.
Joshua Kerievsky (18:19)
So that was heavily influenced by my own journey into continuous delivery and continuous deployment and that whole world. We got into that very early. I was lucky enough to catch a video by Timothy Fritz, who he worked with Eric at IMBU. And he coined the term continuous deployment. And that video is actually no longer on the
Brian (18:43)
Ha
Joshua Kerievsky (18:44)
But this was something that I became enamored of was doing continuous deployment. And we started doing it at Industrial Logic with our own e-learning software back in about 2010. And by the time you get to like 2015, it's like, hey folks, there's this thing where you can do a little bit of work and ship it immediately to production in a very safe way, a safe deployment pipeline. It's friggin' awesome. But the principle doesn't just apply to that because this modern agile is not just about software development. It's how can I work in a way that gets value in front of people as fast as possible? So for example, if I'm working on a proposal, great, I'm not going to work for two weeks and then show you something. I'm going to put something together, a skeleton, I'm going to show it to you and say, what do you think? Does this add value? Where would we improve this? Blah, blah, Again, going hand in hand with evolutionary design. continuous delivery of value is something that is a way of working. With artists that I work with, they'll do a quick sketch or two or three sketches of something first before we start settling in on which one do we like the best and how do we want to craft and refine that. So there's a way of working in which you're delivering value much more finely grained and approaching continuously instead of in bigger batches.
Brian (20:05)
Yeah. I love the connection there between artists as well, because I've got a background in music, and I'm thinking about how when you go to write a song or create a new work like that, you start off with the roughest of demo tapes, and you move from there to increasingly more sophisticated versions of it until you finally have the finished product. But no one thinks that's strange or thinks that's weird in any way. But you're right. Sometimes there's this attitude or kind of I think in some organizations of, we can't let anyone see that until it's absolutely finished, until it's done.
Joshua Kerievsky (20:39)
Yeah, yeah, and that maybe that's that there's some fear there, you know, because they don't want to be thought of as, you know, being lesser because they put something rough in front of someone. Whereas I view it as a, you know, to me, it's a sign of weakness when you when you only send something polished because you haven't had the courage or the sense of safety to put something rough where we can make better decisions together early on. So. There's a lot of learning, I think, around that. But it's a challenging principle of its own, deliver value continuously. And people would say, well, what does value mean? Value is one of those words where it's unclear, because you could improve the internal design of a software system. Is that value? It probably is. But you've got to be able to quantify it or prove that it's going to help make things more graceful in terms of flowing features out. yeah, quantifying, communicating what the value is. is important. I'm also a big fan of maximizing the amount of work not done, as it says in the manifesto. So how can we do less and deliver more sooner? Our motto in industrial logic now is better software sooner. And a lot of these principles go straight into that. that drives it.
Brian (21:38)
Yeah. That's really great. Yeah, I love these four principles and I think that they really represent a lot. There's a lot that's baked into each one of these things. And I'm sure as you kind of put this together with the community and started to talk more about it, I'm sure there were some challenges. I'm sure people came up to you and said, well, what about and how about this? Is there anything now looking back on this that you'd say, gosh, we really... really didn't quite cover this or, know, this is maybe I could fudge it and squeeze it in this area, but you know, there's this other thing that I really think would be important to kind of mention here as well.
Joshua Kerievsky (22:28)
Well, you know, it's funny, because I thought I was going to write a book. I started collecting stories. I love telling stories, and I find stories to be a great way to help educate people. Not the only way, right? But as part of some of the workshops I give, you tell a story. Hopefully it's a story that's sticky, that sticks in the person's brain. And over the years, I collected stories like that, stories of agility. I thought I'd be writing a book about modern agile when I started writing Joy of Agility. Gradually, as I wrote more and more stories, they didn't quite fit into all those four principles. And I think the lesson I learned there was that I was starting to talk about what pure Agile means, the word Agile. What does it really mean to be Agile? Whereas modern Agile is really almost in the context of product development, of building services or products for people. Whereas Agile itself is even more pure. And so the... the book itself got into the difference between quickness and hurrying, which you can relate to this. You could say experiment and learn rapidly. Well, OK, maybe we shouldn't rush it. Don't rush. Be quick, but don't hurry is one of the mantras in Joy of Agility. So adapting, right? Adapting, we talk about adapting all the time. So to be agile, you need to be able to adapt quickly. These four principles in modern agile don't say anything about adapting.
Brian (23:46)
Ha
Joshua Kerievsky (23:48)
So that's kind of implied, but it's not there. So it's a different lens on agility. If anything, I'd say the make people awesome principles are not meant to. It created some dislike, I'd say, from some people. It could have been called empower people, potentially, although a lot of people really love make people awesome. I don't know so much what I'd change there. I'd say we have a .org. So it's a modernagile.org is a website. There's a pretty large Slack community, which, know, four or 5,000 people on that. We don't certify anyone in modern agile, so there's no certifications, but it's something that is neutral in the sense that whether you practice Scrum or Kanban or Safe or whatever, these principles can influence you. And, you know, but again, this all came out of like, when I went to that open space conference in Prague, I had no idea I was going to talk about modern agile. You know, it was not like a predetermined thing. It was just like, my God, they're not talking about the modern ways we're doing stuff. So, and I always encourage people to, you know, keep pushing the limits and keep modernizing. I said to my own company the other day, our wonderful ways of working that we've been doing now for years that have evolved, they're probably antiquated as of today. You know, with generative AI, what would we do differently? Let's have a perspective on our own work as it needs to be modernized constantly. So the term modern in modern agile means always be modernizing, always be looking. Okay, I've had people say, well, Josh, some things don't need to be modernized. There's things that are just evergreen. They're classic. I'm like, absolutely. I'm not changing evolutionary design anytime soon. I find it to be quite useful in so many contexts. So yes, there's the evergreen stuff. And then there's the stuff where you can, indeed, discover a better way. The manifesto itself says, we are discovering better ways of working. Great. Keep that going. Keep modernizing and looking for easier, simpler, quick, easy grace. as the dictionary definition of Agile says, how can we work with quick, easy grace? That's always going to be improving, hopefully.
Brian (26:12)
Love that, yeah. And you're right, I mean, think there's some, to some people I think that there's, I guess at times an attitude of, you this is all new stuff or this is a brand new concept and something they don't really see the connection backwards in time to how these things are all built on other ideas that have been progressive over the years. So the idea of, yeah, this is, you know, we're, we're not saying that certain ideas are bad because now we're trying to modernize them. We're just saying we're trying to apply that same principle forward into kind of the context of today, which I don't see anyone should have a problem with that.
Joshua Kerievsky (26:48)
That's right. That's right. Well, and if you are experimenting and learning rapidly with your own process, which I highly encourage, chances are the way you work today will be different than it was yesterday. You will be exploring, like we use discovery trees today. We didn't use them before. Years ago, no one knew what a story map was. There wasn't such a thing as a story map. Now we have story maps. There's constant improvement happening. And you've got to be open-minded and willing to try new things and drop old stuff. We thought sprints and iterations and extreme programming was absolutely fundamentally part of the way to work. Then we started experimenting with dropping them and turned out, wow, this is pretty cool. We like this. It works pretty darn well for our purposes. That came through experimentation. some of our experiments were terrible, just terrible. It's not an experiment if you already know the outcome. keep pushing the limits of what can make you happier and more joyful at work in terms of producing great stuff.
Brian (27:46)
Awesome. That's great stuff. Well, I can't thank you enough for coming on, Joshua. This is great stuff. just, you know, we'll put all the links to the books mentioned and everything else in our show notes for everybody. But as Joshua said, you can go to modernagile.org and find out more about this if you'd like to. You'll find information there about Joshua himself or his company again is Industrial Logic, Inc. And, you know, his book again, just to mention that, Joy of Agility. We were talking how some people get that title a little mixed up or whatever, but it's just the three words, joy of agility. So just look out for that book. I think you'll find it a rich resource for you. Joshua, thanks so much for coming on.
Joshua Kerievsky (28:25)
Thank you, Brian. Thanks to you. Thanks to Mountain Goat and the folks there. And I really appreciate chatting with you. It was really wonderful.

#130: Be the Change: How to Drive Impact Without Authority with April K. Mills

Ready to spark real change in your organization? In this episode, Brian Milner sits down with April K. Mills, founder of Engine for Change, to reveal how anyone can become a powerful change agent—without waiting for permission. Learn how to drive meaningful change, navigate resistance, and reignite Agile practices with strategies that actually work.
Overview
In this inspiring episode of the Agile Mentors Podcast, Brian Milner talks with April K. Mills, CEO of Engine for Change and author of Everyone is a Change Agent, about what it truly means to lead change.
April explains how effective change agents focus on clearing obstacles rather than forcing compliance, and why fostering curiosity, empowerment, and collaboration is key to sustainable change.
From navigating corporate roadblocks to revitalizing Agile practices, April shares actionable insights and tactics to help you take control and make a lasting impact—whether you're in a small startup or a global enterprise.
References and resources mentioned in the show:
April K. Mills
Everyone is a Change Agent: A Guide to the Change Agent Essentials by April K. Mills
Change Tactics: 50 Ways Change Agents Boldly Escape the Status Quo by April K. Mills
Certified ScrumMaster® Training and Scrum Certification
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 podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
April K. Mills is an engineer-turned-change-evangelist and author of Everyone is a Change Agent and Change Tactics, empowers individuals and organizations to thrive through change using her proven Change Agent Essentials. With a passion for turning ideas into action, April helps people drive meaningful change with the time, title, and budget they already have.
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 April K. Mills with us. Welcome in April.
April K. Mills (00:11)
Thanks for having me.
Brian (00:13)
Very happy to have April with us. April is the founder and CEO of an organization called Engine for Change. That's engine-for-change.com. That's her website. She's also an author. There's a book that she put out called, Everyone is a Change Agent, a Guide to the Change Agent Essentials. And that's what we wanted to have her on to talk about today with a little bit about being a change agent. Now I shouldn't say from the outset, April is a request. We had a listener request for April to come on. And I always love that. I always try to push those people to the top of our list and get them on as soon as possible. And it was such an interesting topic. I thought this would be just a really great way to have a great topic to have early in 2025. So April, let's start with just trying to understand when we say change agent, how do you define that? What do you mean by change agent?
April K. Mills (01:09)
Yeah, a change agent is someone who takes action to bring about the change they want to see in the world. So rather than waiting for a boss or a corporate program or somebody from HR to come in and say, hey, let's improve this process, the change agent sees the need for a change and takes action. And the big thing I talk about in my books and my work is the difference between what typically happens when somebody sees a need for a change in an organization where they decide, I'm gonna go get a boss to go make everybody do my idea. I call that driving people. And I draw the contrast with that and driving change where you choose the change for yourself and you clear the obstacles for others to choose it too. And I love talking about that with Agile audiences especially because Agile is a change agent movement. of folks who want to drive change. I see a better way to create this product and I want to be part of it. And that's always what's drawn me into the agile space.
Brian (02:13)
Yeah, that's awesome. Yeah. And it is a big change, right? To think about the dynamics of someone kind of sitting back and saying, yeah, I see something that needs to be done. I see something that should be a different way, but you know, who am I to say anything about this? Who am I to do anything about versus the person who actually takes action and does things. So that kind of leads to a question about change agents. What kind of skills or traits do you think are really helpful or beneficial to someone to be a better change agent.
April K. Mills (02:46)
Well, the key is that difference between driving people and driving change. It's not what degree do you have, it's not how long have you been in the industry, it's not are you a people person, are you more focused on the data or some of those factors that we usually like to talk about. It really is, are you willing to take the step yourself first and clear those obstacles and encourage and invite people to join you? Or do you want somebody to make them obey you? And that choice is really the key for anybody to be a change agent. Because so many times we've seen people who might be able to convince the boss, hey, our team should be agile. And what happens, right? It goes on for about three months. The team gets frustrated. The boss gets angry. And then everybody starts to have a reaction when you bring it up, right? I'm sure plenty of the listeners have gone into an organization. If you're passionate about agile and you go, hey, have you guys heard about agile? And they go, ooh. And they make like a face. That's because they've encountered somebody who is driving people. And so that's the big focus I always try and talk with people about is can you show up with that willingness to let people join you and understand what their obstacles are to doing it.
Brian (03:57)
What are some kind of warning signs or signals you'd look for to kind of recognize whether I'm actually approaching this from a driving people perspective versus driving the change?
April K. Mills (04:08)
So a lot of times the key is how are you thinking about or talking about in your own head about the people around you or even yourself? We have a tendency to drive ourselves as well. So you can hear it in the language, right? I'm frustrated because so-and-so won't listen. I wish I could get more attention. It's all this sort of vague or... putting the action onto someone else and then complain the action isn't happening fast enough. You can hear it in the language. And so when someone's driving change, you don't hear that. hear, you know, I'm working on, I'm doing, the next thing is my action is I'm going to go talk with this person. I want to understand. I'm going to be curious. And you get this agency, this power coming back into your body almost, and then taking taking the next step from there. And so it's almost easy. You can almost say, well, how far outside your body would you put the power to make this change happen is a useful question to ask people. And if they say, well, it's in the CEO of the company, it's in the industry, it's in my tech lead, but it's certainly not me, well, then you're not a change agent.
Brian (05:20)
So that brings up a good point because I think I can try to channel what the listeners might be thinking here. I know that in times I've been in organizations where, yeah, you have the ideal, you have the thing that you think is the best thing to do. But because the power dynamics in the organization, you don't really have the power to make that change and you depend a little bit on others that have the power to to help affect it. And so there is a sort of an aspect of, I don't really have the capability or the power to cause this change to happen. How can I still stay with that mindset of driving change versus driving people when I know I need someone else's help?
April K. Mills (06:03)
Right. So that's a great conversation. And I've started to call it phase one Agile versus phase two Agile. I'm old enough in this space where when I first joined, a lot of Agile was team-based. Somebody on the team or several people on the team said, yeah, I want better. And these are the things that we can do as a team to deliver better. And let's do them together. And then the problem was the teams could do it, but they couldn't scale it. And they were like, if only we could get the senior leaders to pay attention to us, that would solve all our problems. And then you get phase two agile, which was executives buying agile implementations and forcing it down on people. There is one right way and we will do exactly this and you must conform and no other versions are allowed. And then we got the fractures and all of the fights about all of the different aspects. And so we tried it both ways, right? We tried it with the team effort and then we tried it with this thou shalt effort. And I think the key to actually making Agile work across organizations and deeper into organizations is to keep that energy from the team-based Agile to say, we're choosing something better, but it's that piece of driving change. What are the obstacles for others to choose it to? We didn't do that step. We went from my team does it, now the boss should make everybody else do what my team does. And I think that's where we got off track. in really scaling Agile into something that was sustainable and brought that joy and commitment and everyday wanting to show up and be better across the organization. So that's what I would encourage folks to do is not try to cheat that step of getting your fellow teams and larger systems to join you by finding somebody with the power to make them be like you.
Brian (07:50)
That's fascinating. I know that in some of these changes I've been involved with as well, there can be things that happen that kind of find yourself stalled a little bit, right? The initiative or the changes you're trying to affect just doesn't feel like it's going where it needs to go. What advice do you have for people who feel like they're in that place where they feel like they're kind of stalled out? in the change.
April K. Mills (08:16)
Yeah, so a lot of the things I talk about in that book you mentioned everyone is a change agent are different tactics you can use to overcome that. One of the key things that I talk about is what I call a change buffer, which is how can you make the rules where you're at different than those rules across the organization? I mean, let's take a simple example. Let's say there's five software teams in a business. Very simple example, right? And one is doing some practices and they'd love for those practices to spread. but they're not spreading as fast as they would hope. One of the ways to protect your change is to say, on our team, we will behave this way, declare it, make it what I call a policy buffer. So when one of those other four teams says, well, why are you doing it that way? You can point to the piece of paper and say, we've agreed to behave this way. Now, if you'd love to join us, we'd love to share that with you, but this team behaves this way. So then it's not every developer having to defend in effect the practices, which can get exhausting. But then you can start to ask them, what's your policy on your team? How do you do this? And get curious. Not in a, I'm trying to lure them in and trap them into my way of behaving, but in a, really want to understand, do they have a different measure that they're being exposed to? How can we help maybe get that measure off of them? Do they have a boss who's got a different standard for what quality looks like? Well, should we have a corporate conversation around, quality across the five teams should be the same. We don't tend to have those because we want to skip the step of coming into that alignment together and just have a policy somehow drop from the stars that aligns with my values. yeah, policy buffers are really big to protect a change and help it spread and have those curious conversations at the edges. Think of it like system integration, right? You can't just dictate, you have to understand and merge.
Brian (10:11)
Let's say we put in place a policy buffer like that on our team and our whole team agrees to doing something and we think this is the right way of doing things. And someone higher in the organization, some manager or leader finds out about this and says, no, I don't want that to happen. We've been trying to affect the change, right? And not push the individual. But now we do have the individual who's saying, you shall not do this. How do you overcome that when you're the change engine?
April K. Mills (10:38)
Yeah, so a lot of times you have to understand what are the assumptions that that leader is making and again get curious, right? Because if we focus not on the method but on the outcome, we should be able to get alignment faster. So rather than going into a boss and saying, method A is my choice, method B is yours, you know, it's a cage match, two will enter, one will leave. You instead want to show up and say, Well, I think we both agree we want to deliver quality products on time that customers love at the lowest possible production costs. Are we aligned on that or not? And if they say yes, then you say, okay, now let's just understand what are you asking for? And from my perspective as a person who has to implement that, here's how I think that impacts our ability to deliver quality products that customers love at the lowest possible production costs. And these methods that I'm using are doing this and here's my data or evidence. And so you in effect want to shift it where it's not me looking at you, but as people are probably going to see on this podcast, it's us next to each other. So if we instead frame it as me and the leader looking at the issue together, because we want to win together, we're not in competition. So again, it's about seeking to understand, removing those obstacles so that we can be aligned together to go there together.
Brian (11:57)
I love the idea of backtracking a little bit and finding that common ground and going from that space. I think that's a great approach. I know I've had success with that in my career too, of being able to find, well, we agree on this, right? And if we agree on this, now we're just talking about the best way of getting from where we are to there. And then it's less personal, then it's less about the person, it's more about the best strategy. And we're a little bit less... personally invested that we think it's a you know a personal affront or challenge if it's if it's more about the idea So I agree. I think that's a that's a great kind of approach to doing that How about the differences in just the the context of this if I'm a change I know you know I've been in some small organizations. I've been in some medium large-sized organizations and You know I think anyone who's been in large organizations would say Well, yeah, that's nice and easy when it's in a startup, right? If I'm in a startup, then yeah, everyone's wearing a lot of different hats and it's really easy to make change, but you know, the institutional kind of inertia that can take place in larger organizations, how do you overcome that as a change agent?
April K. Mills (13:00)
Yeah, well, I can speak to that from deep experience because my background started as a civilian nuclear engineer for the US Navy in a hundred year old shipyard. And I started six weeks before September 11th. So I came into a nuclear shipyard, a hundred years old, very staid in the way they did things, optimized for the shipyard and the world changed.
Brian (13:03)
Ha ha ha ha.
April K. Mills (13:25)
And I watched as that organization struggled to deal with the rate of change that was being imposed upon them. And a lot of the things that I talk about in everyone is a change agent came out of that experience of understanding what tactics worked, what didn't, what philosophy worked, what didn't to be able to empower people to make changes happen. And we made amazing changes happen in the shipyard. And then I went on and did 10 years with Intel Corporation, right? The chip maker and taught these things globally and saw people do amazing things within the company. Now it's true, if you don't get the main rudder of the company, you're not gonna steer it. But there's a lot of change you can make in an organization from where you're at. And I think that's the powerful, powerful thing. And so these tactics work at scale. They work for an individual, right? If you stop talking to yourself like, you know what you need to do? You have to do this or so and so is gonna get mad at you and you instead say, What's our obstacle for getting up early and going to the gym? And how can I clear that? And how can I choose to do that every day all the way up to a team, all the way up to an organization? I've seen these things work all the way through that scale. So I've used it in community projects to deliver an accessible playground in three and a half years when everybody said it would take five or 10. And these tactics have also been proven, although they weren't listed this way, in historical successes. If you think about when Admiral Rickover founded the nuclear Navy back in 1950, they went from approval to use nuclear power to USS Nautilus underway in five years. We can't deliver anything in five years anymore because we constantly are looking for who's going to make people, how are we going to force them? Can we keep them forced to do it? And with employee turnover, with system turnover, with the rate of change, I would argue this era of driving people has to end because it wasn't ever really effective, but it's getting less and less effective. And that's the name of my second book, which is Change Tactics, which is both you should change tactics and here are some change tactics to help people accelerate their results.
Brian (15:36)
That's awesome. Yeah, I mean, it gets really deep really quickly here too, because you start to think about even the way we manage our projects and the fact that a lot of more traditional project management is sort of, when we talk about this change agent approach, is sort of managing the people and trying to push and drive the people towards deadlines, some, not even an outcome, but a timeline. versus trying to affect the outcomes that we're trying to achieve as an end result instead. So it really is interconnected, isn't it, through even the way we set up our projects?
April K. Mills (16:13)
Yes, it totally is. And I have that in the book and in the classes I teach is where is the force? So I'm an engineer by training, right? So I'm constantly looking and thinking about where's the force in the system if it was a pump or a reactor plant or whatever. And you can see it to your point with the program management is your, are you spending most of your time trying to push people to do something? Or are you moving the form, fit and function of whatever the product is? If that's delivering code and integrating code, if that's a physical product, are you clearing the obstacle so that product moves forward faster? And you hear this and see this in stories of what's going on at SpaceX, right? When they're confronting something about, can't get a part for six months or I can't get a part for a year and it's gonna cost me $50,000, they're saying. Isn't it just sheet metal? How could we make that in two weeks with what we've got? Because they're not talking about you should be able to shrink that timeline. What are you doing? Why aren't you talking to the vendor enough? aren't you pushing on the vendor hard enough? They're saying, what is the physical thing we need and how fast can we get it? And it's allowing them to shrink product costs. It's allowing them to shrink durations. It's what Rickover did in the 50s. It's what Andy Grove did with Intel back when it was Intel delivers in the 80s and 90s. Focus on the product, focus on the physics, focus on the engineering, the mechanics to support the engineering, the operations to support the mechanics, and you'll deliver products faster. And at the heart of all of that is change agents because they're not trying to get somebody to obey. They want to get something amazing done.
Brian (17:50)
One of the things I found kind of in when I've worked with organizations and talked with organizations about kind of moving from point A to point B is the fact that you kind of need help. kind of need, know, a lot of times people will try to make these changes all on their own and they sort of take the weight of the world on their shoulders. I can't figure out why it's not working. How do you kind of co-opt others into your strategy?
April K. Mills (18:14)
Yeah, well, the best way is to share with them what you've learned about being a change agent. I've had countless folks who, know, one person will read my book or come to a class and they'll go back and try it and people will get curious because you show up differently. So a simple example that I give in the book is rather than sending a mandatory meeting, which we're all guilty of, right, we get an assignment. and we go into the global outlook calendar and we pick people and we make them mandatory and we order them to come to our meeting. We say, Brian gave me this assignment. You have to come. Brian said this is really important. Come to my meeting or else. And we do that. That's the default. And I encourage folks from a driving change perspective to instead, maybe Brian, you gave me that assignment, but my meeting notice would say, I've been asked by Brian to lead this. I'm excited to do that. Here's why I've chosen this as the thing I'm going to focus on. I've marked you all optional. I think you have the skills and capabilities that would be amazing on this team. And if you're as passionate as I am, I'd love you to partner with me. We're going to start meeting on Tuesday. If you're not the right one, feel free to tell me. But I'm moving forward on Tuesday with whoever's there. And I'm really grateful that I get to work in an organization with you. Now. Who's gonna come to, which meeting are you gonna come to? The April says Brian's gonna be mad at you if you don't, or the one where April's gonna go off and do something amazing, I don't wanna miss out. And anybody can do that because everybody send in meeting notices out to people. So the simplest actions have the most powerful results.
Brian (19:31)
Ha It really is a cultural change too, right? mean, that's a very different cultural kind of approach to it to say, hey, it's optional, but, you know, get on board with this idea. If this is something that you're excited about, I want you to be a part of this versus, hey, you've got to, that's your job. you know, I've been given the authority to, to demand that you be here and, and, and, you know, really want. So, so how do you. You know culture changes is obviously one of the hardest things to do in an organization. How do you start to if you're a change agent? How do you start to? Change the culture in the organization to be more in line with that
April K. Mills (20:25)
So my focus is always on the culture starts with one. So people will treat you the way you show up. And so show up as a change agent and the world will bend around you in reaction to it. Now I do have a chapter in the book where I talk about my son who's got special needs and he took a long time for him to walk. He had to walk with forearm crutches. And the first time we were really out in public, he was walking with his forearm crutches. And you could tell that people were really confused and concerned, right? It's different. He's a small child. He looks very fragile. And you had all these reactions from people about, well, you know, where's his mother? Cause I was watching him from a little ways away. I always joke, no one ever asked where's his father if a child is wandering off. But you know, they're watching him and you could tell there were people that wanted to either pick him up and do it for him. Take him someplace because he looks so fragile, let me help you. Or they were mad that he was off on his own and I wasn't hovering. And I use that story for the same thing here. Because when you go off and you say, let's make this optional, I'm passionate about it, I'm committed, and even if I'm alone in this room, I'm going to move this forward, people are going to look at you funny. Like my son with his forearm crutches because they're used to somebody walking off strong, demanding, creating space. But it doesn't mean that that's necessarily the best way to do it. And so you have to be comfortable being different. And I use the concept of change buffers to help people with that. A personal buffer might be like Richard Feynman, the noted physicist. I don't care what other people think. I'm going to be me, their concerns to the wind. A friendship buffer. I'm going to go off and do this. when somebody goes, April's crazy. I call my friend Brian and you go, you're not crazy. You're doing the right thing. Keep it up. Let's go for coffee, let's go for the beer, whatever. A leadership buffer, maybe you're my boss and you believe in this, you've seen it. I go off and do it, people give me a hard time. I go, hey, take it up with Brian, my boss. We do things this way in his group. Or back to that policy buffer. In my group, we drive change, not people. So when somebody shows up differently, folks go, you know, why are you doing that? it's just the way we work. And that's what I've built in organizations over the years. The people that were in The groups with me that were doing this, depending on how comfortable and how strong they felt, could either say, I'm different, live with it. Or they could say, we're different. Or the policy is different. Whatever they needed to feel strong enough to show up differently. Because when you show up differently, you get amazing results.
Brian (22:58)
Yeah. That's so, that's so awesome. I completely agree. What if people are listening to this and hearing all this and getting excited about it and thinking, yeah, this is, this sounds like something I want to participate in. is, it sounds like something I want to start to do. if someone feels inspired by this conversation and wants to be, become more of a change agent, uh, but they really just don't know where to start. What are some practical things that you would give them to say, here's, here's a good way to start to, to move down this path.
April K. Mills (23:27)
Yeah, well, the simplest one is that's why you write books, right? So my book is available. I self-published it on purpose to make it very affordable. So it's, think, $9.99. Everyone is a change agent. It's $14.99 for change tactics because I accidentally wrote a longer book than I intended. sorry. When I got the first copy, I'm like, oh, that's more than I thought it was. OK. But so both of those. So for, you know, the price of a meal.
Brian (23:44)
You
April K. Mills (23:54)
for one person these days with inflation, right? You can get two books that help you not only have the basis, but have some just simple tactics, almost like a recipe book you can use. And then later this spring, I'm rolling out with my Engine for Change Company, this Change Agent Essentials class, which is based on that content. I've been teaching it now for 10 years in corporations. As we were talking before we started, right, I'm a recovering hider in corporations, I guess. Now I'm coming out into the world. And so it's going to be available for folks if they want to take the class to get that more immersive experience. So I'm really excited to bring it to the world because it works. And I'm especially passionate about agile people using it because there's too much conversation around agile dying and we need better products delivered faster that customers love at the lowest possible costs. And I don't know a better way to get there. So we got to reclaim agile from the driving people.
Brian (24:47)
Yeah, I completely agree. you know, anyone who's been involved in Agile in any significant, you know, way I'm sure would probably agree that it's not that the core concepts in any way are, are less, valid or, or, or no longer practical or anything like that. It's just people have seen so much bad versions of things that now that that definition has been marred a little bit, I would say. And so now we, we, we have to kind of take Like you said, take back control of that a little bit and say, now here's what it really is, and here's why we do things this way. And I like your approach there. Find the common ground and say, here's, you know, we both believe in this. Well, what's the best way of doing that? You know, here's what we think.
April K. Mills (25:28)
Yeah. Yeah. Yeah. And I think it's going to be a really exciting time as we go into 2025. There's so much change happening, but so much of it is at that default of driving people. So there's a huge opportunity to show up differently, to create a ripple. That one person can create that ripple. You three people can support each other while they try these new things. By the time you get to five, you almost have critical mass, right? At least two of you will always be online at any one time to support each other. And you can grow it from there. And I've seen great, great things happen. And it really is an unleashing of energy. If people can remember the first feeling they had when they found Agile and it was like, yeah, that feels more like what a professional does. And that excitement and that energy, you can get back to that and you can get back to that by driving change.
Brian (26:24)
Love it, love it, this is awesome. Well, this has been a great conversation. I really appreciate you coming on. We're gonna put links to everything in our show notes for everyone so you can get to April's company and find out more about her classes and also find out more about her books there as well. So April, thank you so much for coming on.
April K. Mills (26:40)
Thanks for having me. It was an honor to be recommended.
Brian (26:43)
Well, and our honor to have you on as well. So thank you for our listeners and recommending people and thank you April for making the time for us.

#129: 2025: The Year Agile Meets AI and Hyper-Personalization with Lance Dacy

Curious about the future of Agile in 2025? Join Brian and Lance Dacy as they dive into the rise of AI, hyper-personalization, and how teams can balance innovation with customer focus. Plus, discover actionable insights to navigate a rapidly evolving landscape—don’t miss this forward-looking discussion!
Overview
In this episode of the Agile Mentors Podcast, Brian and Lance set their sights on 2025, exploring how AI is transforming Agile practices and reshaping customer engagement.
They discuss the shift from output to outcome metrics, the expansion of Agile beyond IT, and the critical role of leadership agility. With practical takeaways on fostering continuous learning and delivering real value, this episode equips teams and leaders to stay ahead in a fast-changing world.
References and resources mentioned in the show:
Lance Dacy
Accurate Agile Planning
Subscribe to the Agile Mentors Podcast
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
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 podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.
Auto-generated Transcript:
Brian (00:00)
Happy New Year's Agile Mentors. We are back and a very happy New Year's to everyone who's listening. Welcome back for another episode and another new year of the Agile Mentors podcast. I'm with you as always, Brian Milner, and we have our friend of the show for our annual kind of tradition now. We have Mr. Lance Dacey back with us. Welcome in, Lance.
Lance Dacy (00:23)
Thank you, Brian. Happy New Year to all of y'all. Happy to be setting this tradition. think it's two times now, so we'll just call it a tradition, but I love it. Thank you for having me.
Brian (00:32)
Very glad to have you here. The tradition we're referring to is that we like to take the first episode of the new year and just take a pause and kind of look ahead a little bit. What do we see coming up? What do we think this new year is going to be like? Obviously, it's a year of change. Here in the US, we'll have a new president that comes in. I'm not going to get into whether you like that or not, but it's new. It's going to be a change. There's going to be differences that take place. And I know there's a lot of differences and changes going on just in the way businesses operate and how things are run and lots of new technologies, lots of new trends. So we just thought we'd take a pause and kind of scan the horizon and maybe give you our take at least on what we're hearing and what we're seeing. And you can see if you agree with these or not. We'd love to hear from you in our discussion forum on the Agile Mentors Community afterwards if you have other thoughts or opinions on this. let's get into it. Let's start to talk about this. So Lance, I guess I'll start. I'll just turn it over to you and ask you that generalized question. Give me one point or one thing that you've been reading or seeing recently that you think is going to be a really important thing for us to kind of be prepared for or look out for here in 2025.
Lance Dacy (01:44)
Great question, Brian. There's so many things out there, and I thought we could start by looking back a little bit. if we're okay with that, just let's summarize, you what did we see happen in 2024? You mentioned, you know, 2025 is a year of change, absolutely, but 2024 was definitely a different kind of year as far as my experience is concerned and seeing a lot of industry trends that are just popping up out of nowhere. Now we are fans of agility, which means we embrace quick, efficient changes, but there's things going on in 2024 I never predicted
Brian (01:52)
Yeah, yeah.
Lance Dacy (02:19)
fast. And so I think we've got to reshape the way that we're thinking about these things. I think the topic of mind, one of the biggest shifts that I saw in 2024 that I think will continue in 2025 is AI. So that artificial intelligence is a big word that we keep lumping into a lot of things. And I just wanted to take a pause a little bit and say, I know everybody's got a little bit different experience about AI, but in particular, as it relates to product development and agile delivery, which is what this show is basically focused on, I thought we could look at some insights of what happened in 2024 with that. And so I think I call us babies at it right now. And I know that may be a bad term, but I have a lot of experience with AI and machine learning and things like that. But as far as the use of it, I feel like we're all a little bit more of babies on how to use it in the day-to-day work that we're trying to accomplish. And I think that comes with learning something. I embrace that. I don't mean that as a downplay, by the way, but that we're all babies. I'm just saying we're less mature about it. We're experimenting with a lot of things. And I don't think that some of the AI is all good. I I embrace it as a thing that's going to help us later on, but... I thought we could just share our experiences of how we've seen this thing manifest itself. I think tools like AI driven, I'm going to use the bad word JIRA, but in place of that, just use any product backlog management tool that you see. And I've seen a lot of organizations not just talk the game of, we use AI for our backlog management, but I'm talking about backlog prioritization, sprint planning capacity. And I believe what's happening is it frees teams up to do more of the... value driven work that we're going to see a lot more of in 2025. So what I mean by that is when we got automated testing and development, if you remember those days, it freed the developers up or the testers, should say, from doing less of the does this thing work to more of how does it feel using it as a human being, you know, automating that. So I've seen things like JIRA, with AI with JIRA and GitHub co-pilots, you know, reshaping the value creation in the teams and eliminating the need of having to do very low level tasks. So what is your thoughts on that and do you have any experiences of that as well?
Brian (04:36)
Yeah, for sure. There's a couple of things I've found that just kind of some stats I found from some different places. you know, listeners know I'm kind of like a data geek here. want to know where the data comes from and want to make sure it's a, yeah. Yeah. You want to make sure it's a solid source and it's not some questionable, you know, sketchy kind of, well, I asked 10 of my friends and here's the answer, you Right, right. Exactly.
Lance Dacy (04:48)
Good hand. I love that. or a FBI.
Brian (05:02)
But so there's a couple of things that came back. One was, I think Forrester is probably a pretty good source of information. They have some pretty good rigor to their process. And they have a thing that they put out every year. This one's just called the Developer Survey. And this is the one that they put out for 2024 that I'm quoting here. But a couple of stats from that that I found interesting. One was, 49 % of developers are expecting to use or are already using general AI assistance in their coding phase of software development, which, you know, maybe higher than most people might think. But it doesn't surprise me too much. I think that's probably kind of what I'm used to it. Understand saying, you know, an assistant co-pilot, that kind of thing. They're not saying 49 % have been replaced. They're saying 49 % are being assisted. by that and that seems about right. Maybe again, maybe a little higher than some might expect, but that seems like not too big of a shocker.
Lance Dacy (06:04)
Well, the animation too. So when you talk about assistance versus letting it run it, I saw a gentleman on LinkedIn, which is also a good. I wish we could interact more with our users on this call, because I'd love to hear their perspective. But I heard somebody say, let AI write my code. No, thank you. Code is like poetry. It has to be refined over time. It has humanistic qualities. And I was like, man, that's a really good point. But when I try to show my kids how to create a Ruby on Rails app to do an e-commerce site and I type it into chat GPT or whatever tool you use, I was amazed at how quickly it was able to put together. mean, you got to still know the file structures and things like that. But I don't know that developers are just going to say, I was going to write the whole thing. think they're, I think it's saving us keystrokes. I think we talked about that last time as well, but that's an interesting, interesting take.
Brian (06:50)
Yeah. Yeah. So I thought, I thought that was interesting. There was another, you know, I'm kind of, I'll move around between these two sources basically, but there's another source that I saw where there was a Harvard Business Review article. posted this on LinkedIn a while back, but it was a kind of the source of it was about a survey that they did to try to determine the impact on the job market. And one of the things they did was now their data was from July, 2021 to July, 2023. So this is a little bit older data, right? The survey was trying to say in analyzing the job postings on freelancer job sites specifically, and they tried to identify ones that might be affected by the advent of chat GPT, because that's the period where chat GPT really started to come onto the scene and started to become prevalent. And what they found was about a 21 % decrease in the weekly number of posts and what they call automation prone.
Lance Dacy (07:35)
Yeah.
Brian (07:47)
jobs compared to manually intensive jobs. They said riding jobs were affected the most 30.37 % decrease, followed up by software app and web development 20.62 % decrease and engineering 10.42 % decrease. But the interesting kind of thing is they found it kind of towards the end of that there was some increases and their kind of conclusion was that there was actually an increase in demand of the kinds of work that required human judgment and decision-making. And so that kind of ties back into what you were saying about let AI write my code whole, completely no, there's still a requirement for that human judgment and decision-making. I think this is why I'm not afraid of it, right? This is kind of, I don't want to make this an AI show, it's about the future in 2025, but when we had a...
Lance Dacy (08:17)
All right. Right.
Brian (08:40)
When we've had AI shows, that's one of the things I've said to the audience here is that I'm not so afraid of AI being sort of the doom and gloom of it's going to destroy profession or destroy. It's going to change it. But I don't think that's any different than any other. A great kind of analogy I make is when we started to have testing automation. It didn't do away with testers. This is just another tool that's going to be in our tool belt.
Lance Dacy (08:51)
Guy net.
Brian (09:05)
And I think our challenge is not to, you know, we're agilist, not to resist change, but to try to adapt, try to find ways that we can align and incorporate and get the most out of it. So, yeah.
Lance Dacy (09:17)
I think the most part of that though is, Brian, too, what most people fear. And I agree with you, we won't make it an AI show. just, we got a couple of points to make on this. But for the first time ever in human history, we now have something that might be more intelligent than us. And that is scary because there's some AI neural network engines that people can't explain how it's working anymore. They put it in place. And then it's like, we're not quite sure how it's doing all of this. And that's a scary thing, obviously, that can get out of control. We've never really had to face that. So we do have to be aware of that, but you know, let's go back and peel it back. Hey, we're, trying to plan a backlog with AI and we're trying to write a few Ruby on Rails code. I'm not letting it run my life yet. And one day it may already be doing that. I just don't even know it. I don't know. We won't get into that debate, but I think the thing is that we need to take pause of in the agile industry. is we embrace new technology as long as it's helping us deliver faster to our customers and save us time and efficiency. You know, I tell teams all the time, Agile is about delivering the highest business value items as early as possible with the least amount of cost friction, know, whatever word you want to use for that. Well, AI might help us do that, but I want to caution that. I think you and I were just talking about this. I wanted you to bring up that news story element that we were talking about. where people are just pushing content out there and kind of desensitizing us to is that important information or not? And I think AI needs to tag onto that. So I didn't know if you could share that real quick and then I want to share some metrics that I've seen some teams capture. There's a lot of teams now adopting these things called Dora metrics, which was created by a DevOps engineering group. And it's amazing to me now that we have real data to see, well, we have embraced AI.
Brian (10:45)
Sure.
Lance Dacy (10:59)
does do some things or not, I'd like to balance the good with the bad on that. But can you go over that new stuff that you were sharing with me?
Brian (11:05)
Yeah, no, it's just a conversation I've been having recently with people, they're friends of mine and kind of, you're probably feeling the same way about this in certain places, but the breaking news alerts that you get on your phone, you get those things all the time and I've had friends and I have discussions about maybe it's time to just turn them off. There's just so many breaking news alerts and that's kind of the issue, right? Is that there are so many that are now classified as
Lance Dacy (11:23)
Yeah.
Brian (11:31)
breaking news that you kind of look at that and say, this isn't really breaking news. You know, like if something really major happens, yeah, I want to know about that. I'd like to get an alert about something that's truly breaking news. the, you know, have major news sources, apps on my phone and get those breaking news alerts all the time. And some of them are just things that are minor, minor news that I would be much better served seeing in a summary and like a daily summary or even a weekly summary on some of the things. Right.
Lance Dacy (11:50)
Yeah. Or if at all, like you don't care about the sub undersecretary of Parks and Lighting in Minnetoca. You know, I don't know. It's just like, thank you for that information. But I totally agree that I feel like we're getting desensitized to a lot of these words, buzzwords, if you will. And we as humans are going to have to learn in this environment. And I'm trying to teach this with my kids as well, because they're the ones suffering the most from it.
Brian (12:04)
Right. Yeah.
Lance Dacy (12:22)
It's just inane information out there and you're filling your brains with the main things. So AI is great because it's allowing people to deliver more content, but is that content of substance or they just trying to market to you and get you, I forget the word you use for it, but, you know, keep you on a leash. Is that what you said? A small.
Brian (12:42)
Yeah, yeah. Yeah, that's, yeah, that's kind of what we were saying about this is that I think that the kind of conclusion that led me to is that I and I've seen this trend, I think in other areas as well, as I sort of feel like maybe with bigger companies, more than others in today's world, there seems to be a shift a little bit that, you know, for example, that that breaking news thing, it's not it's not something that benefits the customer, right? As the customer, I don't think there's a customer out there that says, I really love all these minor news stories appearing in my breaking newsfeed. But what it benefits is the company. It benefits the source because it keeps you engaged. It keeps you coming back and it keeps that ping to keep you engaged. And that's what they're trying to promote. That's good for the... Yeah, that's good for the company, but it's not good for the customer. I think that there may be, we may see some real kind of shifts I think happen in...
Lance Dacy (13:21)
Or me, it keeps me frustrated and I leave them.
Brian (13:34)
Some of those big companies maybe have moved too far in that way to favor their company's interest over the customer. And that leaves a door of opportunity, I think, for smaller companies to say, well, we're going to be all in on just what's best for the customer. And I think customers will appreciate that and will reward that because it's annoying otherwise.
Lance Dacy (13:54)
That's what I want to focus on because the last part of this AI conversation I want to have is I like a lot of what Gary Hamill, he's a management professor at a lot of different schools recently. He visits a lot of companies as well, but I really like the way he delivers his content and how he's more innovative and thought. I mean, I tell people all the time that management and leadership has not seen any innovation in 150 years. It's about time. that we start learning how to create cultures for human beings that are bringing gifts and talents every day to make things better for our customers. And Gary Hamill is a really good source if you're interested in those kinds of things. And so he emphasizes how AI has reshaped value creation by eliminating those low-level tasks that I think we all can embrace and are allowing agile teams to achieve unprecedented efficiency. Now... We are babies immature with this technology. So maybe these news organizations and the ones that we're going to kind of say, you're not doing a good job at it. It's not because they're bad. It's just we're learning how to use a new tool and hopefully customer feedback will change that. But I wanted to hit on these Dora metrics. Dora metrics are, I think they were created by DevOps research and assessment. That's what they kind of stand for. And there's four major categories. that Dora metrics measure as it relates to more of an engineering benchmark. Like how well are we, if you're an agile software development product company, Dora metrics are really good for you to look at. know, metrics can be misused, so be careful, but they're measuring outcomes. You know, what is our deployment frequency, which could be an output metric, because who knows if you're releasing the right things, but let's not get into that conversation. deployment frequency, lead time for changes, the change failure rate of your changes, and the meantime to recovery of those changes. I think those are really four good performance benchmarks. And they're starting to surface a lot in organizations that I work with. So you kind of use tools like Jellyfish or something to overlay over Jira. And all these tools are great, but these teams are using AI. And I found that we finally get some real data that says, how well is AI affecting those core metrics if you were measuring performance benchmarks of the software that you're delivering. And so this report that was created by the 2024 Accelerate State of DevOps report, they categorize organizations and performance clusters like elite, high, medium, and low. And based on their performance across these metrics that I just mentioned earlier, they're evaluating and guiding their software delivery practices. And so the impact of AI adoption was really cool to see on the DevOps Launchpad was a site that I saw this on, that the integration of AI into the development processes, as we were just talking about, has mixed effects on those door metrics. Can you believe that? So a 25 % increase in AI adoption correlated with a one and a half percent decrease in team throughput and a 72 % decrease in the stability of the product. Now these suggest that while AI, you know, offers productivity benefits maybe for the individuals or the teams, it has a, you know, it's introducing complexities that are affecting the software delivery performance. So I want our audience to pay attention to that.
Brian (16:59)
Wow. Wow.
Lance Dacy (17:21)
and start using some of these maybe to push back on managers and leaders that are just embracing this new tool and say, let's just push this on the teams. So that's the impact of AI adoption. And then if you look at platform engineering, so if you look at the implementation of an internal developer platforms, you know, that are helping developers deploy code faster, the adoption of AI led to an 8 % increase in individual productivity. and a 10 % increase at the team level. Now that's fantastic. But these gains were accompanied by an 8 % decrease in change throughput. So while the teams may be able to make changes, what I interpret that to mean is the customer is not seeing the changes. There's an 8 % decrease in the throughput all the way as a cycle time, if you will, all the way to the customer and a 14 % decrease in the stability of the product. So that indicates trade-offs. that we all need to be aware of that AI might be helping us performance wise, but it's not helping the customer a whole lot if we're destabilizing the platform. So I haven't dug into those metrics a lot, but I wanted to share that with the audience because if you do find yourself in a position where people are pushing this, you can try to go reference those and maybe give them some, I always call it pros and cons, right? There's no really right or wrong when you're an agile team trying to make a decision. You got to look at the pros and the cons and
Brian (18:23)
Yeah.
Lance Dacy (18:40)
We might accept a pro, multiple pros that come with some cons, but we all look at each other and say, that's the better decision for our customer. And we live with those cons, whatever they may be. So I wanted to talk about that because it centers on what you were just thinking with the news organization. just push, we got more productive at pushing content, but was it the right content or is it destabilizing what people are using? And you just have to be careful of that.
Brian (18:57)
Yeah. Yeah, no, I think those are excellent points. I think that's one of the things I see kind of for 2025 as well is that we're still so much in the empathy of how AI really plays into how a team operates and how development works that I don't think we can really say ultimately what's the right way or wrong way to do anything yet. I think it's good for teams to experiment. I don't think you should be afraid of experimenting and trying things. But it all comes back to the basic principle we say over and over as Agilist, inspect and adapt on it. Try something and identify what works about it and what doesn't work. And if that means that, we're using it too much and it's causing too much errors, we'll back off, find the right point, and move forward with that.
Lance Dacy (19:41)
Yeah. Or where companies are using it bad. Like I have a story that we won't get into here where a CEO or an executive of the company was mandating that they use AI to do something not so good for the customers. And you want to be able to push on that as well. So I'm sorry to interrupt you on that, but I was just like, man, that's something.
Brian (20:07)
Right. No.
Lance Dacy (20:11)
Sometimes, like we want to self-organize around the experimentation. We don't want it pushed in like management saying, need to use this because I want you more productive and managers be careful of doing that. Make sure you understand the pros and cons as much as you can before you dictate.
Brian (20:26)
Yeah. Something else you kind of said triggered something to me. I know the, I think that, well, not in a bad way, but it just, you know, the metrics I think that you mentioned were really good metrics. I liked the idea of kind of measuring, you know, things like, you know, the failure, the bug rate, you know, like how many defects and those kinds of things I think are good metrics. But they kind of,
Lance Dacy (20:31)
What? Okay.
Brian (20:49)
point out a certain difference that I think that's out there that I think the business community is wrestling with. And I hear these questions all the times in class, so I know it's prevalent out there. But we talk about building high performing teams. And just the difference between that word performing and productivity. There's sometimes I think confusion or false equivalency. between those two, that performance equals productivity. And I think a lot of the metrics sometimes we see that get measured or that we try to measure even, kind of expose that, as that's what's really the issue here, is that we're really trying to make that false equivalency between the two. It's not saying that performance has nothing to do with it, but
Lance Dacy (21:15)
Right.
Brian (21:32)
You know, this is the simplicity, the art of maximizing the amount of work not done is essential. You know, I'd rather have low productivity, but what we produce is high performing, is highly valuable, is something that matters, right? And I think that's kind of those kinds of statistics like you were bringing up, you know, what is our failure rate of things we put out there?
Lance Dacy (21:44)
Yeah.
Brian (21:54)
That is, I think, a performance metric to say, the old phrase, slow down to go faster. Right, right. Maybe the reason that our failure rate goes up and we're having problems with this is that we're trying to go too fast. And if we could back off, it ultimately makes you go faster if you have less bugs that you then have to go back and fix.
Lance Dacy (22:00)
Yeah, make hate, totally. Yeah.
Brian (22:19)
So it may be counterintuitive to certain organizations. Let's push them. Let's try to get everyone to go faster. But I think these new kind of metrics that you mentioned that we're trying to measure more and more, I think are starting to open people's eyes a little bit to the difference between those two words.
Lance Dacy (22:22)
I mean Well, in like the CrowdStrike situation, you know, that took down a lot of the airline systems, you know, I'm not saying they make, they didn't do a good job deploying and everything. All of us are victim of that kind of thing. But, know, to get us back on track a little bit, because you asked me the question, then I felt like I got us off on a tangent. know, 2024, obviously the rise of AI integration into
Brian (22:48)
Sure.
Lance Dacy (22:54)
the workflows that we experienced with Agile. And I just wanted to highlight, yeah, those are some great things, experiment with it. We're in our infancy. So there are a lot of things to discover that may not be so good. So start trying to put metrics in place. And I thought the Dora metrics, you know, as I've started discovering those, I'm a data guy and I'm like, yeah, as long as those are being tracked correctly, I think that's a good benchmark to kind of look at, hey, we're making a lot of changes in our software, but it's crashing the system. So change is good, crashing is bad. there's pros and cons, so we have to delegate that or figure that out. Now, the other one that you just mentioned, I thought I saw a great shift in 2024 from output related metrics to outcome oriented metrics. So the Scrum Alliance has a report, which we're all probably familiar with, especially you and I being certified Scrum trainers with, and we get a lot of data from them. But teams moved away from feature counts to measuring outcomes like
Brian (23:35)
Yeah. Yeah.
Lance Dacy (23:49)
customer satisfaction, user retention. You we teach this in our advanced certified Scrum Master workshops, the difference between output versus outcome metrics. And we've been doing that for five years. And I think it's really starting to take hold that management and leadership and maybe even teams are measuring the wrong thing. And I really saw the needle move in 2024 that people's eyes are opening that let's measure the outcomes of what we're doing. Sometimes that sacrifices individual productivity and performance for a greater outcome achieved at the organization or customer level. And we've been trying to articulate that for many years. And so I've seen a shift in that. And then also the rise of Agile beyond what I would generalize as IT. So Agile Alliance produced some information that I thought was interesting that Agile has expanded into health care or sectors like health care. education, human resources, HR, and those are typically what we would see the laggards, you know, back in the day, banking and healthcare and all those were the last people to adopt this progressive planning approach because of the way that they budget and finance and rightfully so. But those agile principles have been proven out far beyond software unpredictable type work and is going more into, you know, the different types of work environments and I think onto that is how it's getting involved more in leadership. So I don't know about you, but I've also seen people focusing more on building a culture of, I would like to call it leadership agility. So John Maxwell, you know, is a vocal person in the industry about leadership. And he underscored this idea that agile leadership. in driving transformation across non-technical domains. So not just a digital transformation, but non-technical domains is really taking hold in this idea of empowering cross-functional teams. You we've been saying this in technology for years, that the siloed development method is not good. Well, organizations are starting to see that not only in the tech sector, but why don't we put a marketing cross-functional team together with this other team? And that's what they talked about in 86. you know, in the new, new product development game. And I think I started to see the needle move a little bit more with leaders being more fascinated about leadership agility and driving culture change to meet the demands of cross-functional teams. And it could just be a by-product that technology has gotten easier to make these and focus on these things now, but psychological safety, know, sustainability and agile with, people having real goals and integrating.
Brian (25:59)
You
Lance Dacy (26:23)
What you see now is a lot of these eco-conscious practices coming in to product development, like the environmental, social, government's commitments as well, are making their way in there. So I want to just reflect on 2024. I don't know what you think. I'd love to interact with the audience too, but those are kind of the main things that I saw. And that will lead us into a good discussion of how we see that helping us in 2025. So what do you think about those?
Brian (26:49)
I One of the things I think that kind of stood out to me from what you talked about was the concept of how that plays in leadership. And I think you're absolutely right. think that is, I am hearing more of that in classes, people talking about that when they ask questions. You know, we've talked about for years that the fact that there can be sort of I don't know a better word to say but a glass ceiling sometimes in the organization for agile and how it spreads across and that leaders are often You know overlooked as far as getting trained in this kind of stuff and understanding it and I do see a rise in leaders trying to understand a little bit more about how can we You know incorporate this or even better, you know, how do we support? and nurture and foster this culture in our organization. So I think you're absolutely right. I think that is sort of a hidden or kind of a cheat code, if you will, for organizations to try to be more successful with the stuff we talk about is if you can have, it's not a top-down approach, but if you don't have the top on board, then they can really start to become a hindrance or a roadblock to the teams actually being successful with it. And so I agree. think that, you know, I'm hopeful that that shift is occurring. I'm seeing signs of that, you know, it's kind of always a little bit of a back and forth, you know, is it moving in that direction? Then I start to hear people say, no, we're having trouble. And the anecdotal little stories you hear makes you kind of not sure what the prevalence is, you know?
Lance Dacy (27:54)
Yeah Lose hope. You lose hope. I think, you know, the big takeaway for me for this as we talk about 2025 is it's going to be increasingly difficult and it has been increasingly difficult for any one individual company, product, service, whatever you want to call it, to differentiate yourself from other people. I've been telling my kids this forever.
Brian (28:18)
Right, right, exactly.
Lance Dacy (28:38)
that I feel I've seen a big shift from when I was back in early 90s, know, writing spreadsheets for people, they thought it was just unbelievable the work that I was doing because not everybody could do that. Well, everybody can do that now. So what I mean about differentiating yourself is, you know, AI is one of those things that you have to start prioritizing AI literacy because we've just talked about how immature we might be in some cases with this. But if we can ensure that our team members understand how to work effectively with those AI powered tools and letting AI be an active team participant, then I think we're going to start seeing even a greater problem with being able to differentiate yourself. So the main point I want to make for 2025 that I believe is going to be a real big focus is a is a hyper personalization of customer products. So there's a lot of companies out there that are really good. You just mentioned it with the news, right? Hey, I'm building your content, I'm keeping you engaged, but am I really serving you? Am I giving you your needs? And maybe it's okay if news organizations do that if you have a way to filter it and customize it. But really what I'm talking about is, and I'll go back to what Gary Hamill says about this. He says, the markets are crowded. And when you have the rise of AI and tools like Trello, Monday, and things like that, those are project management tools, right? Used to, you could be a better product company just if you would manage your work better. You know, you were using Scrum or Agile, you had an edge on everybody else. You could deploy faster and that was your secret sauce, right? But now that most people can do that now, what's your next up level in game? And he thinks it's going to be this hyper personalized customer solution and engagement.
Brian (30:06)
Right.
Lance Dacy (30:23)
where we need to invest in more customer discovery processes. You know how hard that is in teaching tech teams to do that? All we focus on is building the features, but how about we get better at customer discovery and really understand the tools that provide deep insights into their behavior so we can recognize that? know, several companies that I think are on the forefront of that, for those of you who are like, yeah, I'm concerned about that too. Where can we get better at that? I mean, go look at Amazon.
Brian (30:30)
Yeah.
Lance Dacy (30:51)
You know, Amazon uses highly sophisticated algorithms to analyze customer behavior, which enables them to produce product recommendations and help you buy things you didn't even know. You remember when we would teach like Kano analysis in a product owner class and they had six categories of features and one of those feature categories was an exciter or delighter feature. You know, the key to being a good differentiator is providing product and features that people didn't even know they needed. That's why customers are not always right, you know, on what they need. They're thinking about their reactive sense. And so how can we get better at predicting their behavior even more than they can and use AI and machine learning that allow for real-time adjustments? Because that used to take forever. You you think about Benjamin Graham's book on investing in the 1940s and 50s, trying to predict what the stock market is going to do is nearly impossible now. But can you imagine how he differentiated himself by doing all these algorithms by hand?
Brian (31:20)
Yeah.
Lance Dacy (31:48)
And so what I mean by that is we need to use AI and these tools to help do more predictive customer experiences. So Amazon does a good job. Netflix employs a lot of data analytics to help understand viewing habits. Starbucks does this. Spotify does it. So I really feel like in 2025, if you want something to focus on and you're a software product development company practicing agile, build literacy of AI tools with your team. Make sure we're using them the right way. Track the right. data, but more importantly, let's discover what our customers are doing and behaving and use the AI to help us decipher that information a lot easier so that we as humans can make a decision on where we spend the great scarce capacity of our teams building great products for them. And so there's a lot of things that go into that, but I feel like that's going to be the focus in 2025. That's what's going to separate the people that succeed even individually. How are you going to differentiate yourself from a market pool of people out there? You need to start learning how to use these tools and differentiate yourself. That's the for 2025.
Brian (32:52)
Yeah. No, that's a great point. I'll tag on and say that I know there's this, people probably have heard of this, there's a social media kind of trend of if you use chat GPT or something like that a lot to go to it and say, tell me some insights about myself that I may not know, just based on all my interactions with you. And that was a trend for a while for people to ask that and then. they were shocked in some of the things that would come out from chat GPT. Well, what I found in taking a couple of courses and things about AI is, it's really good at taking a large amount of data and then pulling out things that you may not be aware of. I think that's going to be something, the more data driven we are, obviously the better because we have facts behind it. And as you said, it has to be the right, we have to collect the right kind of data. you can take a big...
Lance Dacy (33:19)
Yep. Yes.
Brian (33:43)
source of data and feed it into an AI like ChatGPT and say, give me five hidden insights from this data. Yeah.
Lance Dacy (33:50)
Yeah, stuff you thought about, right? I think insights, that's the way to put it. And I used to have a saying being a data analytics guy for 20 years. Most people and organizations are data rich, but information poor. And I would like to change that word nowadays to insights poor because
Brian (34:09)
Yeah.
Lance Dacy (34:09)
We may have all the data and tracking data, there's no harm in that, know, storage is cheap these days. So go ahead and track it all. You can report on it infinite number of ways. And that's the secret sauce. And I think you just hit it on the head that, just go ahead and start tracking stuff. Let AI, you can't ever read that amount of data as a human being and decipher it. Let the machine do that. But then you can test it. You can say, do I really believe that or not? Because you have a humanistic experience that AI doesn't have. So we should embrace that.
Brian (34:40)
Yeah, I agree. Well, I mean, I hope people are hopeful. I'm hopeful. I know when I start a new year, I generally am hopeful because that's just the way I try to start new years. But I'm hopeful for some of these changes. think the tools that we have are just making things, some things that might have been more mundane, a little easier for us to do. And maybe that allows us to focus. Well, like the data I brought about at the very beginning, you the fact that there's a rise in, you know, postings and companies needing jobs that require human judgment and decision-making. I think that's where we're headed is, you know, that rise in human judgment and decision-making skill. And that's something that's at least at the moment, you know, our computers can't do for us. And it really does require, just like you talked about, understanding our customers. I can't put an AI out there to try to interview all my customers and get deep. Well, but not and get the kind of deep insights I want, right? Not to find out what the real problems are. It wouldn't know how to question it enough and dig deeper into different ways to truly figure those out. So it requires huge human judgment and decision-making. And I think that's where we...
Lance Dacy (35:35)
you could. Right.
Brian (35:51)
now bring the value is in that area.
Lance Dacy (35:53)
Well, and people hate change, right? So let's just end with this. know, most people, customers, you change things on the product. You put a new car design. We usually don't like it. So you want to hang in there and not get too distracted by noise with that. mean, remember when the first iPhone came out, you know, older generations like this is too complicated. I don't want to use it. And there is something to say for that. But eventually that's what we use and we learn how to adapt to it. So stay hyper competitive in 2025. Foster continuous learning for your team. So stay updated on industry trends. It'll lead time to experiment and invest in your team's learning. Prioritize collaboration and innovation. None of us are smarter than all of us together. Break down the silos. Encourage the cross-functional collaboration. And experimentation is going to be key. Leaders and managers in particular. must foster an environment where it's safe to not do so well. I tried something, it didn't work, and I'm sorry about that, but I learned from it and I'm going to try it this way next time. That's not a huge thing right now. We need to foster that. The last one, focus on delivering value. Keep the customer at the center of everything. Use metrics to measure your real world impact, not just the outputs. And I think that's how we can summarize everything that we talked about. Those are the three things if we had to take away. continuous learning, collaboration and innovation, and focus on delivering value. Good luck in 2025, right, Brian?
Brian (37:19)
Yeah, absolutely. Absolutely. That's awesome. Well, I hope this has been beneficial to folks. And Lance, I appreciate you keeping our tradition and helping us look forward into the new year. obviously, a very happy new year to you and your family. And thank you for coming back and joining us.
Lance Dacy (37:35)
Yeah, likewise to you, Brian. Glad to do it. Hope to see you all soon. Thank you all.

#128: Top Lessons from 2024’s Most Inspiring Episodes with Brian Miner

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 podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
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.

#127: Agile Strategies for Job Market Uncertainty with Mark Kilby

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 podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
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.

#126: Mastering the Scrum Master Role with Gary K. Evans

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 podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
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.

#125: Embracing Gratitude in Challenging Times with Brian Milner

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 podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
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.

#124: How to Avoid Common Product Team Pitfalls with David Pereira

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 podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
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.

#123: Unlocking Team Intelligence with Linda Rising

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 podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
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.

#122: Empowering Diversity with Nosa Oyegun & Louria Lindauer

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 podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
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.