Agile Mentors Podcast from Mountain Goat Software

#105: Scrum Conferences & Neurodiversity with Brian Milner

Join Brian as he delves into the powerful response to his talk on neurodiversity at the Global Scrum Gathering in New Orleans, which emphasized small but significant changes to make environments more accommodating.
Overview
In this episode, Brian shares his memorable experience at the Global Scrum Gathering in New Orleans, emphasizing the event's stellar organization and inclusive atmosphere. He reflects on the success of his talk on neurodiversity, which resonated deeply with attendees and sparked meaningful conversations.
Brian also underscores the importance of attending conferences for networking, learning, and expanding professional connections. Encouraging listener feedback and engagement, Brian hopes to inspire more inclusive practices within teams and the broader Agile community.
Tune in for insights on fostering inclusivity, the value of professional gatherings, and much more.
Listen Now to Discover:
[1:08] - Brian warmly welcomes listeners and invites you to join an engaging conversation about the value and insights gained from Agile conferences.
[2:45] - Brian kicks off with heartfelt gratitude to the behind-the-scenes teams whose hard work and dedication ensure these conferences run seamlessly and effortlessly.
[5:04] - Brian celebrates the often-overlooked joys of conferences, from hearing fresh voices and engaging in hallway conversations to making meaningful connections and sparking innovative ideas.
[9:57] - Brian highlights and commends the Scrum Gathering for its intentional efforts to accommodate and include attendees with neurodiversity and those with additional needs.
[14:15] - Brian shares that the goal of his talk was to demonstrate how small changes can create a more inclusive environment, such as playing neurodivergent-friendly music, dimming bright lights, and establishing quiet spaces.
[20:18] - Brian discusses the overwhelmingly positive response to his talk and expresses his hope that these inclusive practices will be adopted widely, transforming the way we all work with our teams.
[23:08] - Brian encourages listeners to attend future conferences to gain new insights, broaden their horizons, and forge valuable connections.
[24:20] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. If you’d like to continue this discussion, join the Agile Mentors Community.
[24:33] - We invite you to like and subscribe to the Agile Mentors Podcast and pass this episode along to a friend.
References and resources mentioned in the show:
Slide Deck From Brian’s Talk
#76: Navigating Neurodiversity for High-Performing Teams with Susan Fitzell
Scrum Alliance’s Global Scrum Gathering
AJR Brothers
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)
Agile Mentors, how the heck are you? How's your week going? Hope it's going pretty well for you. I wanted to spend some time with you on this week's episode because I just had an event that took place that was really, really a phenomenal event. And I wanna kind of share with you some personal insights that I had from it and just sort of give you a picture of what it's like. If you've never been to a conference before, Maybe I can entice you to maybe go to one. I think you'll benefit from it. And I think you'll kind of see your career maybe even go in new directions if you decide to go to one.
We just had the global Scrum gathering that took place in New Orleans. That was the 2024 conference. And the Scrum Alliance has changed things up a little bit. I don't know if people are familiar with this or if you're aware of this, but... Scrimmelines used to have two conferences every year. They used to have one that was somewhere in the US, and then they would have another one that was mostly in Europe. But now they've kind of switched up their strategy.
They're going to have one in the US one year. And then next year, it'll be somewhere else globally. So they're really leaning into that global title here for global Scrum gathering. Next year's, I believe they announced here at the end of our conference, is going to be at Munich. So still staying within Europe, but that's not always going to be the case. So there won't be one in the US next year. It'll be the first year that that happens. So every two years, if you're here in the US, you get a chance to attend. If you're somewhere else in the world, maybe there'll be one that appears in a location near you. And that might be a little bit more convenient for you to attend.
But I want to talk about this one that was in New Orleans. And I have to start by just, I want to say to all the support staff, to all the people who volunteered their time from. from the teams that helped set up the rooms to the program team that helped kind of put this all together and create the environment and select the talks and everything else. Phenomenal job. Just phenomenal job.
I couldn't have asked for it to have been run any better. I saw zero hiccups in my time there and just had a fabulous conference. It was a great time. Enjoyed the heck out of it. Enjoyed New Orleans. It's always great to realize I had not actually visited New Orleans prior to this of all the places. It's not very far from where I live, but for whatever reason, it was just one of those black holes in my map. It was one place I had never been to and it was a place I loved. I thought it was just amazing to meet some of the local people there. and to get a flavor of what it was like on Bourbon Street and Frenchman Street and some other parts of the town after the conference. It was just a really great experience. I was very pleased with the whole thing. And so I just want to make sure that that's out there, right?
There's a lot of volunteers that go into working for a conference. I've been a part of that group from time to time. I've reviewed different submissions. If you're not familiar with that process, Speakers at a conference submit their ideas. It's no guarantee anyone's going to get picked. In fact, it's a very, very small percentage. They end up getting picked. So it's a very tough process for the reviewers. And it takes a team of them. They have different tracks that they take submissions in. And they kind of have to whittle those down.
One of my friends who was on the team was describing to me, you might have one talk on, or you might think about a topic like daily scrums. And you might have five submissions on daily scrums that are all amazing talks. They all sound like they'd be incredible with great speakers. But somehow they have to whittle that down. They can't have five talks on Daily Scrums. They've got to limit it. And they've got to have talks on things that they feel the majority of the visitors are going to be interested in. So it's a thankless job that goes on behind the scenes.
And I just want to publicly thank them. I know I got to rub shoulders with several of the people on different aspects of the teams and just really, really appreciate all the work that you guys did to make it such a successful conference. I really always enjoy the scrum gathering conferences. I think they're, they're, they're a fun event. they, they always have a Monday mingle kind of activity.
That's always, something you, you write home about if you will, just something fun to do. this year we had a location was not very far from, the hotel so we could walk there. And just had lots of things that were going on there, food and drink and that sort of stuff. But it just gives you a nice kind of off campus place to unwind and interact with other people and kind of maybe meet some people that you wouldn't get a chance to otherwise. So I always appreciate some of those social events.
Even though I'm an introvert, I just enjoy having different space, kind of a different opportunity to do that sort of thing. And I just want to say, you know, the talks I heard this year were incredible. I heard some really good first time speakers that had never spoken before. And I love the fact that, you know, they're doing that, that they are expanding and it's not just the same crop of people that you hear every single conference. You know, it's a different set of people and it really depends on your topic. It depends on what it is you're trying to talk about.
So I was really thankful to get to hear some new voices there in our community. And the only thing that I wish I could change about that, and this is the same no matter what conference it is, every conference I have this issue, it always seems like the ones you want to go hear the most are if you're speaking, they're happening when you're speaking, or they're all grouped into the same time slot. And you'll get three or four talks that you really wanted to go to. And you got to pick.
You got to choose one of those that you can go to and kind of just plug in there. I'm not one that likes to bounce between the different rooms. I don't have any problem if someone does that. I don't have any problem if someone does that in my talk. But I just like to commit. And that's kind of the way I look at it, is when I come in there, I'm committed, I'm here, I'm giving my full attention.
I want to learn from this person. and leave with something I didn't know in advance. So really, really enjoyed that. There was a talk that was put on by women in Agile that was three new speakers that were three women who had not spoken before. Really enjoyed that and loved their approach. They have a mentor for each person that kind of helps them prepare and get ready for it. So that was awesome.
Really enjoyed listening to that. And just... I don't want to call out any specific talk because they were all so good. I will say there have been years in the past when I have had sort of slots where I've thought, there's not really one I want to hear in this slot. So maybe I've set out or I've done something else. That wasn't the case for this one.
Every slot had something I was like, I've really got to go hear that. I've got to hear that person talk or really want to hear about that topic. So just really enjoyed that.
Couple milestones, kind of, I noticed that happened here. One of my mentors and someone I've had in the podcast, David Hawks was there and he's kind of publicly announced this now that he's retiring, he's stepping back a little bit from doing this stuff and he gave his last conference talk. So it was neat to be there to see his last one. He's a really engaging speaker and always has really deep kind of... needy content for you to chew over that you leave thinking about. So it was kind of an honor to be there for the last thing that he did at a conference.
And the other thing to say is that I really kind of just enjoy the one -off conversations, the hallway conversations. There's breakfast and lunch every day. And when you do those, you sit down at a table, you've got to find a spot. And sometimes I'm just trying to find any open spot. But what I'm trying to do is find the table with people that I don't know, that I haven't met before, that I want to. maybe rub shoulders with and learn a little bit more about what they're doing their organizations.
So those are a great time that they're kind of built in naturally to try to meet some new people. And you know, I'll tell you, I wore a little thing at this conference before it broke on me, but I had a little pin that was kind of my emotional, no, it was my social meter. That's what it was. And it had like a high and a low ranking on it. And you know, I'd start out every day with it on the high ranking. I'm ready to go. I'm excited.
And as the day went on, it would kind of go a little bit further down. And by the end of the day, I was spent. I didn't really have any more I could give out. And I just wanted to wear that sort of a visual fair warning to people. If they saw me and they saw where my meter was, they could say, OK, Brian's kind of running low. Maybe. Maybe I'll wait till tomorrow and have that conversation.
Not that I'm going to be mean or rude to anyone, but just there are times when you just are all empty. You're just out, and you don't have anything more that you can give. And that's certainly the way I feel sometimes at the end of some of these long days. I've been known sometimes to just go up and spend time taking a nap in my room, maybe doing some emails or something, just something to give me a break to go away.
And that's sometimes something I need in these kind of big social environments. I do want to really, really congratulate the Scrum Alliance on one thing that I noticed particularly here in this conference. They clearly made an effort to make some accommodations for some different personality types, neuro types, and you know, I've shared with this podcast before that my talk here at the Scrum Gathering was on neurodiversity and how to be more inclusive of different neurotypes in your teams. I'll get to that talk in just a second.
But there were things that I had been studying and learning about that were small accommodations that people could make that helped some of these different neurotypes. And it was clear that the Scrum Alliance had deliberately made an effort to do that. One thing that I didn't know was going to happen until I got there, for every keynote presentation they had on their big video monitor, they had transcription.
So there was closed captioning of anything that was being said, which is a very important feature for some various neurodiversity types. And I was very, very pleased to see that. I just thought that was a good change that they made. Small change, not really anything big that they had to do to do that, but it makes a big difference for a segment of the population.
And I'm really thankful that they did that. The other thing that I noticed that they did was they had a quiet room. There was a room that was right in the mix of all the other conference rooms where presentations were going on that was a quiet room. It was dim lighting. They had some nice cushy soft like beanbag chairs that were in there. They actually had like some soft quiet like atmospheric kind of effect noises going on like waterfalls and that sort of thing. Rain rainfall, ocean waves, things that were very peaceful and quiet.
And they also had made available in that room earplugs for people. And for those that have noise sensitivities, sometimes you can walk into these conference rooms and I can say, I've been guilty of this as a speaker. I want to create an exciting atmosphere. So I blare the upbeat music as people are coming in just to get people in the right kind of excited mood.
Well, if I have noise sensitivities, that's going to not only not be exciting, it's going to be painful. And having the ability for someone to self -regulate that and say, I'm going to put my earplugs in for this, because it's just a louder place. It's a louder room. Even just listening to certain talks, you would hear a talk next door where a speaker would just their plan for their talk was much more interactive. So there'd be a lot of audience participation and shouting outs and clapping and laughing and that sort of stuff.
And it can be disruptive for the room next door. I don't fault any rooms for being more interactive or fun for the attendees, but you know, noise has a bleed through effect. And I was just happy that they thought that far ahead and said, you know, we're going to have some people here who might have that sensitivity to noise. And it doesn't cost very much for us to provide a handful of earplugs.
I don't know how many of them were taken, but I would imagine there wasn't a ton. They didn't run out, as far as I know. But having a place like that, I took advantage of the quiet room. I knew that it was a place where I could go and collect my thoughts. And I would sit down with my laptop and maybe just make some notes of things I wanted to make sure I captured. No one was going to interrupt me.
That was kind of the rule of the room. There was no talking in that room. So I could focus. I could come in there and do what I needed to do without disturbing anyone and really kind of recenter before I headed back out. There were some who used it for meditation and other things. And I have no problem with that. If that works for people, then I'm happy for them to do that.
For me, it was just a quiet space. And I just needed a quiet space, somewhere away from all the hustle and bustle, what was going on. So just kudos to the Scrum Alliance there for that. I think that they made a couple of really intentional moves there to be more inclusive. And I, for one, as part of that neurodivergent community, really, really appreciated it.
So thank you there to the Scrum Alliance. If anyone here is from the Scrum Alliance listening. Big kudos there for you on that. The other thing here is I do want to talk about my talk just briefly. And just to let you know that I did a lot of preparation for this talk. It really was the culmination of about a year's worth of research. I've done talks at other conferences before.
I tried to let people know that this one was different for me. This one was very different because it was very personal. I was gonna be sharing things about my own medical diagnosis. And that's just not something that's common that I have in conference talks. I don't normally go into a conference talk and say, hey, here's what I was diagnosed with.
So that made it very, very personal. But it's also something that is prevalent throughout my family. So I was sharing information from my family as well. Again, like I've said here on the podcast, I wouldn't share that if I didn't have permission. I don't volunteer that for others in my family. If they say that it's OK, then I will. If they don't, then I don't share that information. But it was very personal. And I was much more connected, I think, to the material. I really, really had a vested interest in the outcome.
You know, I wanted to show some real practical ways that people could make small changes and become more inclusive. So that was my goal. And one of the things I tried to do, if you attended my talk, you may not even recognize all these things, but I wanted to first teach by demonstration. I wanted to kind of have things in place that... that would show that you can make small changes to be more inclusive.
So just a couple of things I want to highlight here. One was a very, very, very subtle thing that I don't think anyone caught. But I did have music on that I turned down fairly quiet. I didn't want it to be that loud. I wanted to be loud enough for people to hear, but I didn't want it to be very loud. And I just had a playlist that was playing where I was playing one band in particular. I was playing a band called AJR.
Some of you may be familiar with them, some of you may not, but AJR is a trio of brothers who are neurodivergent and their music is very neurodivergent friendly. They've sort of been seen as kind of, I don't know how to put it, but... figureheads, I guess, of neurodivergent movement. There's lots of neurodivergent people who go to their concerts.
There's lots of commentary and stuff about how they're very open about that in their lyrics. So that was a slight little nod there. If anyone caught that, then congratulations. You caught the most subtle way that I did that. But that was one of the ways I was trying to make it a little bit more friendly. One of the other things I did, I turned down the lights in the room.
There was overhead cans that you would have kind of typical in any kind of conference room. But they also had some like a chandelier that was over the middle of it. There were kind of some circles. And I found the light control panel and found out I could turn off the cans that were in the room and just have the overhead kind of chandelier. And it really kind of brought the light level down. It wasn't dark. It wasn't... so dark that you couldn't see in the room or anything like that. It was still enough that you could see. No darker than you would find in maybe a restaurant, right?
But it was a lower level of light. And that was very intentional. I was trying to help people who had light sensitivities to not have to struggle or worry about that. So that was something I did intentionally. I. Probably the biggest thing I did was I set aside two tables at the back of the room that I call quiet tables. Most of the time you go to a conference, there's an expectation that you do some interactive kind of work there.
I had a lot of data to get out, so I couldn't do as much interactivity as I normally do in a talk. But I did have one big activity that I did kind of towards the back part of my talk. And I wanted to have a couple of tables that if people just were not comfortable, group participation. They didn't want to have to talk to others. They wanted to just come and show up and take in the information.
I wanted them to be able to do that. So I set aside two tables. I put a little sign on the table that said, this is a quiet table. If you sit here, please understand these seats are designated for people who don't want to be a part of group activities and would rather just sit quietly while we have any kind of a group activity. And I set those aside. And I.
As people were coming into the room, I saw people that were starting to sit at those tables and I walked over and I just wanted to check on the people that were some of the first people sitting there and saying, I don't want to interrupt you.
I just want to make sure that you've seen the sign so that you know what to expect here at this table. And I had these three wonderful women that were sitting at one of the tables and they responded very emphatically like, yes, no, we absolutely read that. We loved it and we felt like, hey, he gets us. And that just made my day. I was just so excited that they felt that way and they felt welcomed, right?
That's kind of what I was trying to do is create a welcoming atmosphere that nobody felt left out. Everybody felt included, normal. I did some other things too, like we put out some little badges that said, embrace neurodiversity, that people could put on their name badges, just to kind of raise awareness across the conference from that point on.
I also put little fidget toys at each spot that people could take with them. Just a small little fidget keychain kind of thing that people could have. Not anything terribly elaborate, but just a small little thing. So all these things were just ways I thought of in advance to try to make it a more welcoming environment for people to participate.
Getting to the talk itself, as a speaker, I'm pleased with how it went. It kind of went the way I'd hoped it would go. One small technical thing with a poll that I did at the beginning, but you know now I'm kind of insider baseballing this and I don't really Didn't really Contribute hugely in any negative way. I was able to call out the numbers and we just moved on right
That was not a major part of the presentation anyway So, you know, I'm I'm as pleased with how it went as I probably could have been for anything like that I I could tell things were resonating with people. I got nods.
I got verbal agreement from people in different parts of the talk. So, you know, and we stay within our time box. We met that the way we needed to. So that all went pretty well. But you don't really know until after. And it's after that really kind of made my conference for me because... not just immediately after, but for the remainder of that conference. I spoke on Tuesday. It went on, the conference was Monday, Tuesday and Wednesday.
So for the remainder of day on Tuesday, into the night on Tuesday, and then before I left on Wednesday, I just had random people that would come up to me at various points and thank me for giving the talk. I had one person tell me, thank you and said, I felt seen. And that just almost brought a tear to my eye. I was so excited to hear that.
And that was part of what I was really attempting to do there, is I wanted people to understand that there are differences in how people process things and how people's brains work. And hopefully we can take that back to our teams and change how we approach how we work with our teams. I'm not going to go too much into the detail of the talk. We will make the slides available here in our show notes. So if you want to see the slides like I gave the presentation, I gave it the presentation, we'll make that available for you.
There's no recording of it, unfortunately. The Scrim Alliance doesn't do that. They don't record them and then publish them later. Some conferences I know do. do that, but the Scrum Alliance is not one of them. But I will make the slides available to you if you want to dig into that more.
The other thing I'd say is if you really want to dig in the topic more, find my previous podcast episode, which we'll also put in the show notes. That was with Susan Fitzell. She is a specialist in that area and helped me to understand some things. And that was a kind of key episode. on that topic.
So those are some places I can point you to if you want to get into that, the heart of that, that topic area. But, you know, hearing those kinds of things, those personal kind of congratulations and just people who I didn't know who'd come up and say, you know, they felt seen and that just made the conference for me. I was so pleased that that was the case.
Because just as it was very personal for me, it was personal for them too. It connected to them on a very personal level. And I hope that that can make a change in our teams. I hope that that's something that some of those people who are in the room can take back and implement just one thing. One thing they can change in how they work with their teams. All in all, it was a great conference.
I really enjoyed it. And Scrum Alliance just put on a great conference this year. as they always do. They always put on a great conference. So thanks to my friends at Scrum Alliance for inviting me and having me there to speak. Thank you for all the volunteers who worked on it. Thank you to each person that I had a conversation with, especially the new friends that I didn't really know before the conference.
I... I really enjoy, and the ones that I haven't seen for a while that I kind of got to rub shoulders with there. Again, I really appreciate you coming up and saying hello. And I did have a few people from the podcast who came up and said, hey, listen to the podcast. That's always a pleasure when that happens.
It just helps me to know that, hey, this is actually resonating. This is making an impact for people. So. I heartily appreciate that. If you ever see me at a conference, please do. Don't hesitate. Come up and say hello and tell me that you listen to the podcast. You'll make my day if you do that. So that wraps up Scrum Gathering 2024, New Orleans.
I should say global Scrum Gathering. And if you didn't attend this year's, if you're in Europe, maybe consider attending the Munich one next year. I don't know where the following year is going to be in 2026, but it will be back here in the States somewhere. And we'll have to wait and find out where that's going to be.
On my calendar, the next conference I have coming up is an exciting one for me. It's Agile 2024 that's taking place in Dallas. So if you go to the Agile Alliance, agilealliance .org, you can find information about that conference and join me there. I'm going to be talking about conflict and how we can have conflict competent teams. So I'm excited to talk about that and dive into that topic with everyone in Agile 2024. So.
Just wanted to give you a brief recap of what happened there and what it was like, and give you an insider view of what it's like. If you haven't ever attended a conference, I encourage you to give it a shot, especially, you know, I'm based in the Dallas area.
If you happen to be in the Dallas area and you're on the fence about attending the conference there in July, you got no excuse. It's in your backyard, right? It's right there. You'll hear some amazing speakers. You'll widen your network.
You'll be surprised at kind of the connections you make and what you walk away with from a conference. So just highly encourage you to give it a shot. So that'll wrap us on this episode. It was just me, so I won't do a separate little closing thing. If you wanna give me any feedback on this, just reach out to me and send me an email podcast at mountaingoatsoftware .com and I'll get that.
Or you can go to our Agile Mentors Community and post in our discussion forum there. That's a place where you can interact with me. As always, like and subscribe, all that social jazz. Make sure that you... You keep this in your inbox. We always appreciate that. And as we always ask, tell a friend. If you liked the episode, if you liked any of our episodes, pass that on to a friend and let them know about this podcast that you found. That's it for this time. We'll see you again on another episode of the Agile Mentors Podcast.

#104: Mastering Product Ownership with Mike Cohn

Join Brian and Mike Cohn as they dissect the vital roles and responsibilities of the product owner, from story mapping to stakeholder management. This episode is a treasure trove for anyone looking to sharpen their Agile skills and understand the nuanced demands of a product owner.
Overview
In this insightful episode, Brian and Mike Cohn explore the multifaceted role of product owners in Agile development, discussing everything from market analysis and vision creation to the nuts and bolts of sprint planning and retrospectives.
Emphasizing flexibility and adaptability, Brian and Mike offer a comprehensive look at how product owners can excel by focusing on strategic planning and fostering strong team dynamics. This episode is essential for product owners seeking to enhance their impact in Agile environments and drive successful outcomes.
Listen Now to Discover:
[1:07] - Brian welcomes special guest Mountain Goat Software and Agile Alliance founder Mike Cohn.
[1:31] - Brian introduces Mountain Goat Software’s What Happens When for a Product Owner, and Mike flips the script, setting Brian, as the creator, into the guest seat on this episode.
[3:16] - Join Brian as he explores the vital, behind-the-scenes efforts of product owners that set the stage for Scrum success, all before the first sprint begins.
[6:24] - Brian explains the dynamics of crafting a product vision, clarifying how much responsibility lies with the product owner and how much is shared with the team.
[7:46] - Brian offers expert guidance on the optimal timing for creating a story map within the Scrum process.
[9:46] - Brian and Mike explore the optimal quantity of backlog items to have ready before adding them to a sprint.
[13:45] - Join Brian as he explains the importance of setting a product goal in Scrum, detailing how it enhances functionality and guides the development process.
[17:03] - Brian invites you to download Mountain Goat Software’s What Happens When for Product Owners, a comprehensive guide designed to support your Scrum journey.
[17:43] - Brian explains how to effectively integrate road mapping into the Scrum process, ensuring it adds valuable foresight and preparation without causing shortsightedness.
[19:55] - Mike suggests a strategy for managing stakeholders who overemphasize the product roadmap, offering a creative approach to preserve the flexibility and adaptability that effective road mapping allows.
[22:48] - Brian delves into the critical role and strategies of effective sprint planning, essential for driving successful Scrum projects.
[24:20] - Brian offers his perspective on the significance and involvement of the product owner in the daily scrum, detailing their role and contributions.
[26:15] - Mike recounts a memorable story about receiving exceptionally impressive customer feedback at trustworthy.com, highlighting the impact of genuine client interactions.
[28:30] - Brian emphasizes that the product owner is an integral part of the team and its goals, underscoring their collaborative role rather than being separate.
[29:18] - Brian explores the crucial involvement of the product owner in the backlog refinement process, detailing their responsibilities and impact.
[30:48] - Brian explains why he views the sprint review as the product owner's event and offers strategies for executing it effectively.
[32:17] - Brian delves into the product owner's essential participation in the retrospective, emphasizing that their insights and experiences are crucial for the team's growth and improvement.
[34:10] - Brian outlines ways the product owner can proactively prepare for the next sprint, ensuring a smooth transition and effective planning.
[35:27] - Brian discusses a key pitfall that product owners should avoid to ensure success in their role.
[37:35] - Brian shares a big thank you to Mike for taking over this episode of the show.
[37:57] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email.
[38:08] - We invite you to like and subscribe to the Agile Mentors Podcast and share the episode with a friend who could benefit.
[38:56] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here.
References and resources mentioned in the show:
Mike Cohn
What Happens When For Product Owners
trustworthy.com
Subscribe to the Agile Mentors Podcast
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.
Auto-generated Transcript:
Brian (00:00)
Welcome in Agile Mentors, we are back. We are here for another episode of the Agile Mentors podcast. I'm here as always, Brian Milner, and today I have the big man back with me, the OG, we've got Mike Cohn in the house with us. Welcome in, Mike.
Mike (00:15)
Hey, Brian, thanks for having me back.
Brian (00:18)
Always happy to have Mike here. Always a pleasure to have him here and learn from his experience. And really, really grateful he's here. We wanted to have Mike on because we have something that we put together recently. Honestly, it's kind of been something we've been talking about we just haven't put together. We had a document that we had out there called What Happens When for Scrum Master. And we just didn't have one of those for a product owner. So I did some work there on the side on that and put it together. And we're getting that out for people so that you can find that and download it from our site. And we wanted Mike to come on to share his wisdom in that area as well, because a lot of this is stuff that I put together. But we wanted to get Mike's insights on these areas as well. Does that sound about right, Mike?
Mike (01:11)
That's what we agreed to do, but it's not what I'm going to do.
Brian (01:14)
Okay. Sounds good.
Mike (01:19)
I'm going to turn the tables on you, Brian, because it's your PDF. It's your document. You're the ideas behind this. So I kind of want to turn it around and take over. I'm going to kind of interview you, ask you things. I mean, I'll chime in with opinions here, of course. I can never shut my mouth long enough to not share an opinion. But it's your PDF. I want to ask you some questions about it, if that's OK with you. And I assume we'll have the link for this in the show notes for folks. They can get the.
Brian (01:41)
Sure, fair game. Yeah, absolutely. Yeah, they'll be in the show notes. Anyone can find this. If you want to download it now and follow along, just pause, you know, go find that in the show notes and you can follow along as we talk through this.
Mike (01:55)
Great. So Brian, you separated the document out into things that a product owner does. And of course, I mean, kind of naturally you did it by timeframe, right? Do this before you even go and do this every sprint, things like that. I want to talk to you about some of the stuff that we do before the project that a good product owner should do before a project. You had in there a couple of things like do market analysis and create a vision. You tell me more about what you would expect of a great product owner in that world.
Brian (02:25)
Yeah, that first bullet point, what I was trying to capture is that there's some behind the scenes kind of product, standard product work that we don't really account for in a scrum sense. Things like market analysis and trying to understand the competitive landscape. There's a whole discipline there of activity and work that goes on behind the scenes. And I think it's important to understand, that Scrum isn't in any way saying throw that out or that that's not needed, that is something that would come, in my opinion, before you even begin this kind of work. Scrum does not include in it a process that would say, let's verify that they should fund this product. Let's do a pitch. So the CEO of, you know, here's why you should have this product. That's what I was trying to capture in that first bullet point is just understand there are some standard kind of product development work that goes on that we're not, we're kind of skipping over a little bit.
Mike (03:36)
That's one of the things I've always loved about Scrum is that Scrum is silent, deliberately so on many topics. And occasionally I will have somebody that I'll meet and they'll say, Scrum doesn't say how we should do product envisioning, right? It doesn't say how we should do that. So I guess we don't do it. It's like, well, Scrum doesn't say that you should code, right? Nowhere in the Scrum guide does it say code your software product, right? Yet if you're doing a software product, somebody's coding, right? Somebody's doing something. And so I like that Scrum is deliberately silent on a lot of things like this because you're talking about doing this market analysis. I work with plenty of companies that are doing internal software. And if we're doing internal software, we're not going to do a market analysis, just kind of internal user needs analysis perhaps, but it's going to be very different. And so I do like that flexibility there.
Brian (04:13)
Hmm, yeah. Yeah. So that's a good point, though, is depending on the product, it is sort of more as needed or as it would fit. Like you said, if it's an internal product, it's going to look very different than if you're doing a public -facing one.
Mike (04:40)
I think for any of the steps that you've outlined, I think they can vary. I'm sure some are going to be the same for everybody, but I always think of it as commercial development, right? We're making Microsoft Word, right? I think of it as in -house development, right? We're making a payroll system to pay our employees or contract development are kind of the three big branches to me. And then things get very different within those three types of development. I'm thinking more product development there specifically, but of course we can be using this for non -product things.
Brian (05:10)
Well, and I do want to say that that second bullet point, they're talking about vision. That's where I honestly, from my perspective, that's where the product owner portion of this begins, right? Because that's sort of the first thing you need to do. And in fact, when we teach our CSPO class, this is, you know, if you've been through a CSPO class with us, you will recognize this order because that's exactly how we go through it in our CSPO class, very deliberately. You know, that
Mike (05:39)
I'm sorry, I was getting off there, but I was getting interested in something you're saying there. So product owner kind of starting with the vision. I know that the team can influence the vision, right? But where would you draw the line or how much of the vision is the product owners? Is it like, you know, I'm the product owner dictator. Here's my vision, shut up and build it.
Brian (06:02)
Yeah, I don't know that there's one answer there. I mean, I have seen in certain situations where it's more of a group effort. And that might be part of that earlier genesis of the product, where we go through an effort to define the vision with other key stakeholders, with leaders in the organization. I do think that there is sort of a separate activity that I would take with the team itself. So I might spend a deal of time with key stakeholders developing a vision, but then I might also then have a separate meeting with the team once that's established to say, you know, here's kind of what we're defining it as. Let's walk through this. Tell me if you agree, disagree, or how you might improve or change this. Just so that we, you know, part of our job as a product owner is to cast that vision. and help people get caught up in the excitement for what it is we're trying to do. So that's kind of the purpose there I see of doing that.
Mike (07:04)
Yeah. Yeah, the more excited we get people about it, the better off we're going to be throughout the course of the project. You also have some things in here about things to do before the first sprint about identifying users, possibly go into the persona level, but then also story mapping. I want to ask you about the story maps for a second. What's your guideline? Because somebody asked me this recently, I'm curious on your answer. What's your guideline for when we should create a story map? Do you do always, only at the start, only in the middle? What's your advice?
Brian (07:35)
Creating it, I always created at the start. I mean, my, just, and again, this is my experience, right? But what I have found to be useful is to do it at the beginning. And it's sort of right in that order, right? I've done the vision, I've talked, I figure out who my users are. And then I wanna know what the general big picture is for my product. I wanna be able to step back from a 50 ,000 foot view and say, all right, here's kind of the step by step of what we're gonna be doing. Because, you know, kind of like a product backlog, it's a living, breathing document. It's not done, you know, we do it once at the beginning of our product and then it's done set forever. It's constantly adapting and changing as we add new feature areas, as we, you know, understand differently how our users would interact with the product. We're going to adjust and change it. I want it to always reflect reality.
Mike (08:30)
Do you, so let's talk about reality there. I mean, I agree with that, but what I see is story maps that are hard to keep up to date. Are you seeing teams that really succeed at keeping them up to date all the time? I know the living breathing thing for like a couple months and then it's like the dusty old story map, right?
Brian (08:47)
Yeah, well, this is kind of one of the things where it was kind of hard for me to put this in a time frame because there's really two time frames that I would like this to appear in. Yes, I do think we should do it before the first sprint. And by the way, again, there, I would do this in multiple rounds with different sets of stakeholders. But then once it's established, I kind of would slide that into that quarterly kind of activity to say, we may not touch it every quarter, but every quarter I would want to...
Mike (09:03)
Sure.
Brian (09:16)
check in on it and just say, is this still accurate? Do we need to adjust it? Do we need to do anything different about it?
Mike (09:16)
Okay. see that. A couple of the things on the before the first spring here, you've got identify assumptions, possibly test some of those, and then create a product goal. And then the last couple of you got, you know, get enough of the backlog written to get started. And a sprinkle, how much of the backlog do you think a team should have to get going? I mean, I know it's probably not like seven and a half items, but you know, you're looking for, you know, one sprint, one or two sprints, eight sprints.
Brian (09:45)
Bye. Well, no, Mike nailed it. It's seven and a half. Seven and a half items. No, just kidding. Now we can start. No, yeah, I mean, it's, you know, that's why I use the term enough, right? What is enough? Well, you know what enough is, right? You kind of know what that is. There's a, you know, there's a goal that we have in general that we've, lots of us trainers and coaches have put out there to say,
Mike (09:52)
seven and a half backlog items. There we go. Once you've written seven and a half, we can get started.
Brian (10:14)
you want to aim for about two to three sprints worth of items that are in ready to go shape. They're ready to move into a sprint and start at any given time. I don't know that you need two to three sprints to start. Yeah, I mean, I think you need, I think there's sometimes a hesitancy in teams to get everything documented upfront. And I'm trying to help people kind of push past that to say, no, we don't need to have everything.
Mike (10:25)
That's a start.
Brian (10:42)
We just gotta have enough to start. And when I'm working with a team, I wanna get them into that first sprint as soon as possible because they're gonna learn much more from just doing it than they are from talking about it beforehand. That's why I've never been a real big fan of like a sprint zero or something like that because it just doesn't take a whole sprint to do everything that you need to do to get ready for your first sprint.
Mike (10:58)
Right. Yeah, I think you're right. I mean, to me, I always put it in terms of like, we're gambling our time, right? Is it worth gambling more of our valuable time writing more backlogs, or should we just play and get started? And if we're a company whose name is invoices are us, right? You know, should we go ahead and write some stories about the invoicing part of the system? Yeah, I bet we should. But if we're not sure that, I don't know what we're building, but if we're not sure invoice is going to be part of it, don't write anything about that on the backlog yet. Just put one big item, do invoices, right? Break it down when you get there. So.
Brian (11:36)
Yeah. Yeah, I mean, you typically know where you need to start. You know, there's a million things you could do. But when you have a big idea for a product and you're starting fresh and you're starting new with it, at least in my experience, again, I found like, I always know where I'm starting. And that's what I would encourage you to do is just get it out there, get it started. Even if you don't have all the different features and aspects of it thought through, that's OK.
Mike (11:44)
Right.
Brian (12:05)
You just want to start making progress so you learn.
Mike (12:08)
That reminds me of something I've shared with a lot of leadership teams that I've met with over the years, which is that I'll tell them that they're basically solving the wrong problem. And they're trying to answer the question of what should we build? What should the product be? And that's totally the wrong question. The right question is what should we build next? What's that next one or two steps that would tell you what the next four or five steps will be? And so simplify the question, not what are we building, but what are we building next? And I think you're right there.
Brian (12:26)
Yeah, yeah.
Mike (12:36)
one sprint worth is enough and put in the backlog if you need to write more backlog items. Go from there.
Brian (12:41)
Yeah. And I don't want anyone to hear us incorrectly here. I mean, part of the reason that we had them there to identify assumptions and try to test hypothesis is I don't want to open a, the silly example I always use in classes, I don't want to open a store that sells lip balms online and not test whether people want to buy lip balm online or not. There's some fundamental assumptions that you're going to have to test and know.
Mike (12:48)
Thank you.
Brian (13:11)
probably before you're gonna even get with a team and start getting up and running on this. And that should happen here.
Mike (13:16)
Yeah. I was with a company, this is years ago, they were in Boston, we finished the engagement, I'm walking next to my rental car, and one of the guys walks out with me, one of the like VPs, and he's like, I got a question for you. He says, how often should we cancel projects? And I said,
Brian (13:34)
Seven and a half.
Mike (13:35)
I don't know, seven and a half. I said, I don't know. So I don't know how often, but you should be canceling a fair number of projects. You get started, you find out it's going to take twice as long as you thought, or you get started, and it's not really going to deliver the value that you hoped for. So you stop. And he's like, I thought so. He said something like, I've been here, I think, eight years, we've never canceled a project. And it's like, OK, that's bad. You should get into these and find out your assumptions are wrong.
Brian (13:51)
Yeah. Wow. Yeah.
Mike (14:04)
I want to talk about your quarterly items on here. And you've got a couple, let me just kind of read some of these here. So you've got establish a product goal. That's a relatively new thing in Scrum. I mean, I still think of 2020 as relatively new, but as a old timer with Scrum, product goal is one of the newer enhancements. You've got doing the story writing workshop. So you're supporting what you said there. Talk to me about the product goal here.
Brian (14:19)
Yeah. Yeah, so I feel silly talking to Mike Cohen about what a product goal is. Product goals are just that neck, they're a milestone, right? And that's typically the way I talk about this in class is to say, especially when you're starting something new, you may not know everything that you're gonna do, but you know the next big thing that you need to accomplish. You know the next big mile marker that you're gonna hit in the life of your product.
Mike (14:56)
Mm -hmm.
Brian (14:59)
And that's what we want to establish with the product goal. Something that's going to take longer than a sprint, multiple sprints to do. I've got this in the quarterly section. And that's kind of how we tend to talk about it a lot here at Mountain Goat. But even in class, we'll even say quarterly -ish. Right, right, bigger than a sprint. And sometimes it'll be longer. Sometimes it'll be shorter. That's OK.
Mike (15:16)
It's the bigger than a sprint section, right?
Brian (15:25)
You just want to have that big thing that the team can keep their eyes on and kind of know, you know, here's, you got a sprint goal that tells us why what we're doing in this sprint is important and how my small task feeds into that. And you've got this product goal to say, how does the sprints work fit into this bigger picture of what we're trying to do? So you're making those...
Mike (15:47)
Yeah.
Brian (15:50)
connections consciously for the developers so that they are not just, hey, here's a laundry list of stuff to do, but here's the objective we're trying to accomplish.
Mike (16:01)
Yep. I think it's important to have something that's out there bigger than a sprint. A sprint is just, it's just kind of suboptimizing, right? I think about if you're climbing a mountain and a sprint is like, what's the highest thing I see and just always walk into the highest thing you see. Meanwhile, those are all false summits. The real summit is, you know, behind some valley, but you don't see it because you don't set out that bigger goal. And I like how you talked about it quarterly because if the goal's too big, if it's too far out there, we're not going to feel very motivated. about it. I had this the wackest example of this. I hope the guy's not listening. Actually, I hope he is. But he was told me he was on a project with the large particle collider. And he said his whole project won't be due for 40 years, right? I mean, I don't get it. But it's like they've got to run like 40 years worth of data before it's like totally done. And I just picture myself showing up for work on a 40 year project, right?
Brian (16:31)
Right. Yeah.
Mike (16:57)
I know you, you're going to be reading Dallas Cowboys news for the first 35 years, right? You know, sports news and you know.
Brian (17:04)
That's a 40 year project too.
Mike (17:07)
Well, you're not going to take it serious for 35 years. Then you're going to wake up and go, the deadline's only five years away. I better get to work on this. And then what I would do is realize, wow, I'll be retired after 40 years. So anyway, I've been silly. But I mean, you're on a project with a 40 -year deadline. How do you say motivated? And I think three months is a really good time where I can see a bigger impact than a sprint. But it's not so far.
Brian (17:15)
Right. Right, right, exactly. Yeah. Yeah.
Mike (17:34)
that that student syndrome kicks in and I feel, I don't really have to worry about it. Let's go to a long lunch. We'll get to work on it tomorrow. So I do like the quarter -ish approach there. You mentioned here a couple others here. These are probably straightforward, but manage and maintain the economics of your project, assess stakeholder relations, and road mapping. You want to talk about any of those, maybe road mapping especially?
Brian (17:46)
Yeah, yeah. Yeah, road mapping, I think, is an important aspect. I mean, it kind of goes along with that product goal. But I do get people who come through a product owner class that will say, I don't like this approach because it seems like it's all so short -sighted. And we're not really having the big picture of where we're going. And in my world, we have this year -long thing, or 10 year. I've worked with some teams that build automobiles and they're on a three -year release cycle. They're working on the model year that's three years ahead. I've worked with some teams that do aerospace kind of stuff and they're working on a space launch that's multi -years out in the future.
Mike (18:34)
Yeah.
Brian (18:43)
And when you ask them, how certain are you that you're really going to be working on this five years from now? Pretty darn certain, right? Because it's there. We're building toward that launch date's going to be there. So I think that that roadmap is an important step for a product owner. Now, I just want to be clear about this. When I say a roadmap, I'm not talking about setting hard and fast dates and saying, we're going to be here by this date. We're going to be there by this date.
Mike (18:50)
Yeah.
Brian (19:12)
It's okay for us to say, here's kind of where we feel things are gonna fall, but I really am a strong proponent of the forecasting method, like kind of looking ahead and seeing, you know, kind of based on yesterday's weather kind of thing, right? Here's what the weather was like at this time last year. So it's probably a good indicator of where we're gonna be at this season this year, that sort of thing. So I'm a proponent of the forecasting forward. And I think a roadmap can fall very well in line with that because we can slot things and say, here's kind of this quarter's, here's the next quarter kind of things that we're thinking that are gonna take place. And if one thing moves forward or backwards, one of those sections, that's not a big deal. It's not gonna change earth shatteringly the course of our product, but it does allow for preparation. And that's what I think is the most important thing that people lose sight of in sort of forecasting and projecting forward is why do we do this in the first place? Well, we do it most of the time because there's someone else who needs to get ready. They need to be prepared. They need to be ready when this is delivered to do XYZ. And that's what we're trying to accomplish with this. We can do that with forecasting.
Mike (20:32)
Yeah, I think you talk about taking those things seriously. And if we miss one, it's not the end of the world. Except there's always somebody in an organization who's going to say it is the end of the world. The danger for me with roadmaps is how serious people take them. They'll look at it and go, we got a roadmap. It says we're going to come out with this in 12 months. I bet we're going to do exactly these 12 things. And so that literalness to a roadmap.
Brian (20:50)
Yeah.
Mike (20:59)
is scary. I've only done this a couple of times, but I like the result is I put together roadmaps for with teams in a couple of organizations. And we kind of modeled them on the idea of the old, I don't know, 200 or 300 year ago, 400 year ago maps, right? And you would have like, you know, the. horrible map of what the world looked like, right? And there'd be Darby Dragons right on the edge of the map. And we actually did that on a roadmap, right? It had stacks of items are going to be delivered. You know, this, this six months, this six months. And then below there, we had just put a few things in kind of an unreadable font at Darby Dragons below there. Trying to reiterate that you can't take this that literally, but there often is somebody who's like, my annual bonus is tied to that box on the roadmap.
Brian (21:24)
I'm going to go ahead and close the video. Right. Well, you can see this in, you know, I'm not going to get on a tangent here on safe, but you even see this in safe when people do things like PI planning and they plan out the next quarter. One of the pitfalls that I think a lot of organizations fall into when they do that is that they see it as a commitment. That the team is making a commitment to getting all that work done in that PI, in that program increment. And that's not the way it's intended. It's intended as here's our loose plan. We know what we're going to do in the next sprint, but the other sprints are
Mike (21:48)
Right. Yep.
Brian (22:17)
more fluid and we'll adjust as we need to.
Mike (22:20)
Yeah, I've written so many times about a plan is not a commitment or commitment is not a guarantee, right? You know, I can make a commitment to this. I'm going to commit to do my best. We're going to commit to try to achieve these. But I love a Clint Eastwood quote, one of his movies. He said, if you want a guarantee, buy a toaster. Right. So. Those are the days when supposedly banks used to give you a toaster when you open a new account, right? That.
Brian (22:25)
Yeah, yeah. you can guarantee a toaster in today's world. Well, we joke in our family because my wife's grandparents have a, well, they're no longer with us, but they had a refrigerator that was from the 1950s that was sitting out in their barn that still worked perfectly. But we had, you know, our refrigerator is, you know, five years old and it's already breaking down and you have to consider replacing it. So, yeah, yeah.
Mike (22:49)
precede my day, but I... Wow. It's all the electronics in them, I think, right? So I want to move on to the sprint planning. So from the quarterly planning. So in sprint planning, you've got this broken out by what people do in the planning meeting daily during the sprint. So I want to start in the planning meeting. You're proposing a goal and work with developers to kind of improve that, answer questions about backlog items, and talk about your schedule as the product owner share your schedule. You want to elaborate on what you're thinking about with these sprint planning activities?
Brian (23:15)
Yeah, yeah. Yeah, I mean, so I think a goal is important for the sprint. I think that gets us all on the same page and it's kind of one of the teaming aspects of it. We want to all have our eyes on the prize of what it is we're trying to accomplish together so that we're not all just in different places working on different things. I think it's important that we're there in sprint planning to answering questions because that's when they come up. We're making our plan for when we're going to do something. So I think it's important that we're there to kind of help them plan how they're going to accomplish stuff.
Mike (23:59)
Yep.
Brian (24:08)
We're not telling them how to, but we're giving them the information they need to determine how. And then, you know, as far as our schedule is concerned, I think it's a great idea for a product owner in sprint planning to say, you know, here's the next two weeks of my calendar. Here's where I'm going to be out of the office these days. I'm going to be at a client site on these days, just so that people can prepare. If I'm a developer and I know I need to get approval from my product owner and I know they're going to be out for the next two days at a conference or something, well, that might... guide me in how I'm going to plan and arrange my work.
Mike (24:38)
Yep. Some of my favorite POs have been ones that have done something like said, look, between one and two o 'clock every day is total team time. I will never schedule a meeting. I'll always be available if you need me from one to two or one to three or eight to nine, whatever it is, but they'll have some sort of window there that is basically guaranteed access. Doesn't mean that's the only time they're available, but it's a guaranteed time, which is nice. I think it's nice.
Brian (25:04)
Yeah, I love that too.
Mike (25:06)
Talk to me about the daily scrums and what you'd expect out of a product owner during the daily standups.
Brian (25:08)
Ha ha ha. Yeah, daily scrums are kind of a controversial thing here for lots of reasons, but I mean, there's some who would say a product owner doesn't need to be at a daily scrum. I disagree. I think product owners do need to be there. I don't think they're required. Actually, if you want to ask me my opinion, the only people I think are required are the developers, because it's for them, it's by them. You can't have it if they're not there. If anyone else is not there, you can still have the meeting.
Mike (25:14)
Thank you.
Brian (25:38)
But the product owner, I think, is important to try to be at as many of these as they possibly can. Because just like in sprint planning, they're making a plan for what they're doing, here it's immediately before they're going to be doing this work. So it's the time when the rubber meets the road. And here's where they're going to have some real practical questions. And if you're not there to answer them, you could hold them up. You could delay them.
Mike (26:04)
Yeah.
Brian (26:05) I also, like you said, I like to use this as an opportunity to say, here's when I'm available today.
Mike (26:10)
I wake that product owners attend because of the message it helps sends as well. If the PO never goes, is this project important, right? Or team members start to think, we have to show up daily and say what we did yesterday, that that person never has to do this, you know? And we started to get some resentment towards them. So I strongly encourage product owners to attend. I'm like you, that don't require, but my requirement test is always, would I cancel the meeting if this person had a dentist appointment, right?
Brian (26:16)
Yeah.
Mike (26:41)
If the product owner had a dentist appointment in the morning of planning, I'd probably say, can we do it in the afternoon? My product owner can't make the daily scrum because I've got a dentist appointment? well. We're still doing the daily scrum. But you're right. If all of the teams, this will be silly, but if all of the team members were all having dentist appointments, yeah, we'd cancel the meeting. There'd be no point. So.
Brian (26:53)
Right. Yeah, the Scrum Master and Product Owner can't have a daily scrum, just the two of them.
Mike (27:07)
What should we make them do? Let's talk about what to do during the sprint. You talked about kind of ongoing research. So you don't want to do all the research upfront on this.
Brian (27:09)
Right, exactly. Right, no, it's a continual thing, right? I mean, if I'm working on my product and my competitor comes out with a killer feature that's starting to gain traction, I can't do that research upfront. That's something that becomes apparent as the product kind of goes along. So I think it's important that we keep in touch with what's going on in the real world with our product and the competitors.
Mike (27:43)
Mm -hmm. through the marketing, through the market. The thing you had next here was about connecting with customers to hear feedback. I want to share a story on this one because it literally just happened. I told you I was out of the office. I got back like 15 minutes before we wanted to do this recording. And I'd been gone all morning, so I talked to my wife for about five minutes. And she and I had come across some software recently that we're using that looks kind of interesting. It's things like, you know, when you die, who gets access to your Facebook?
Brian (27:57)
Yeah.
Mike (28:18)
password, right? And most of my friends are pretty shifty. So I don't want to give my Facebook password now because they'd probably go post weird things. But I want you know, when I die, I want that to happen, right? And so we're looking at various software that does those things like who do you notify when after you died?
Brian (28:19)
Yeah.
Mike (28:35)
And we signed up with this company. I'm actually going to share the name because I like them so much here in a minute, but let me say why I like them. My wife and I both had interactions with them by email about totally different things. One was a little bug that I came across and then something that I think she was asking about how does the future work. But here's what I love. They contacted her today and said, can we get on the phone with you and hear what you think about our product? They're a fairly new company, I believe. what you think about our product and what you think about how we've, in particular, have like the three tiers of service that we offer, right? You know, this feature, this feature. And I just love that they're doing that, right? Because not as many companies do that as they should, right? As they should. Because I love that company, so I'm gonna mention their name, trustworthy .com. Probably nobody listening needs them, but they are just this kind of like, you know, I don't wanna say like death planning, because they're not like playing your funeral, but it's like.
Brian (29:23)
Hahaha.
Mike (29:28)
Who gets your Facebook account? What bank accounts do you have? So your heirs can figure it out. Right. So, so.
Brian (29:34)
Yeah, yeah, that's great. No, I love having that mission if they're, they have good customer service. Yeah, definitely. Let's, let's mention them.
Mike (29:40)
Yeah, and my wife and I favorably disposed of them, and that just put me over the top with them literally a half hour ago. You talk about checking in with the Scrum Master, about how you as a product owner are doing, but also staying in touch with devs.
Brian (29:46)
That's awesome. Yeah. Yeah, I mean, I think that it's important for us to understand that we are not somehow separate from the team. We are part of the team. So we have the same goal as everyone else, and that's to deliver as much value as we can to our customers. We have a specific role, a responsibility to play in that. But I think checking in, partly I put that on there because. checking with a scrum master. That's something that we have on our scrum master sheet is to check in with a product owner. And I do think that those two need to kind of work hand in hand over the course of a sprint. And on an ongoing basis, kind of touch base to see how are things on your end? How are things on my end? And how can we help each other to kind of achieve our goals here?
Mike (30:24)
Yeah. Yeah, you often notice something about somebody else before they may notice it themselves, right? We've got a couple other meetings that I'll move on to. So let's talk about refinement. Can you share what your thoughts are for a product owner's responsibilities during refinement?
Brian (30:43)
Mmm. Yeah. Yeah, I mean, refinement, I always hesitate to even think about it as a meeting because it's kind of more of a series of activities. And you might have multiple meetings that would need to take place here. But yeah, I think that there's a lot of prep work that goes into. If I'm going to have the stakeholders come in and help me prioritize, I've got to prep a lot of that work. I've got to have the stuff that's ready to go prior to that meeting. I can't just show up and go, let's see what we got in our backlog. And we'll just kind of wing it.
Mike (31:02)
Good point. if What do you think about this product owner? I don't know. Let me think now. Yeah. Did I write that one?
Brian (31:21)
Right. Right. I don't even know what that is. I don't know. Let me read it. Right. That's just going to waste everyone's time and frustrate people. So I think there's a lot of prep that goes into that and prepping to go into anything like estimation. Do we have the right sort of things that are going to be estimated? I don't want to waste my team's time estimating stuff that's maybe really a long way in the future. And I'm not going to look at it for a while. So, you know, I think there's a lot of prep time that goes into that. And I think that, you know, we're at the center, at the focal point of any kind of refinement activity. as a product owner. So that's going to be, I don't really know exactly how those meetings are going to play out for you, but I think that there is some configuration there that you got to plan for.
Mike (32:02)
I'm hearing your message. There is the old boy scout motto, be prepared, right? It's a new product owner motto, right? We'll, we'll steal it from the boy scouts. you have any, that's true. Just don't take away my Girl Scout cookies. So let's talk about the, the sprint review. what do you think a great product owner does then?
Brian (32:06)
Yes, yes. Yeah. Well, that's okay, because there's no more Boy Scouts. So you don't have to worry about that. Right. wow. So this is our event. I really think of this as the product owners event. Yeah, exactly. I think you're the emcee. I think you show up, you host it, you send out the invites for it. What I typically tell product owners is kick it off with kind of a look back at some things that have been done recently by the team. Here's some features that we developed in the past three to six sprints and maybe even show some statistics about the impact those things are making.
Mike (32:30)
you Showtime!
Brian (32:56)
on the product and the market, on the customers. Our customer satisfaction has gone from here to there as a result of releasing these features, those kinds of things. So I think that the meeting opens that way. Then we move into the demonstration of the work and what we've done in that sprint. And yes, I would turn that over in large part to the developers so that they can demonstrate. But then I think it circles back at the end to come back to the product owner to say, all right, let's take a peek ahead. Let's look ahead what's coming up in our product backlog. Here's what our... looking at as candidates for the next sprint. And I think that's really important. It gives the stakeholders a chance to speak up and say, hey, what about this thing that I had that was really important? I don't see that prioritized. I really need that in the next sprint. I want to have those conversations in advance, not after sprint planning, when it's sort of locked in. Yeah.
Mike (33:45)
Tell me about the retrospective. One of the things I noticed you had in there was that you want product owners to attend every retrospective. There's going to be pushback on that from some teams. What's your thought there?
Brian (33:59)
Yeah, my thought there is, again, kind of reiterating that point that we are on the team, we are a team member like anyone else. And again, we have different responsibilities. We have a named kind of set of accountabilities that we have that may differ from others. But I kind of consider it like this. If I'm on a, in the US, we'd say soccer team, but if I'm anywhere else in the world, I'd say football team. If I'm on that kind of a team and I'm the keeper, the goalkeeper. I've got a very unique role, right? I mean, there's a set of things I do that no one else does. I'm allowed to do things that nobody else is allowed to. I'm allowed to touch the ball with my hands. Nobody else is, right? But if there's a team meeting, you're not gonna have a team meeting without your goalkeeper. They're an important vital part of your team. And that's what this is. It's the team meeting to get together to say, how can we get better? How can we improve? What's going on? What's wrong? What's right? And what do we wanna focus on?
Mike (34:36)
Right. Yeah.
Brian (34:58)
So I think it's vital for a product owner to be at every one just because like I said, we're a team member.
Mike (35:04)
I agree. To me, it's always like, if you don't feel comfortable having your product owner at the retrospective, that's the first thing I want to talk about at the retrospective. Right? It would figure out why we're not comfortable with that so we can move past that. I do like here in the retrospective, you talked about having the product owner commit to making progress on the improvement items, which I think is important because sometimes it is product owners who have to improve. Right? So.
Brian (35:31) Yeah. Yeah, I mean, one of the things we'll talk about in class is how the product owner is a vital communication relay point. They are the, I call them kind of the, it slipped my mind. What's the stone that had the different languages on it from Rosetta Stone, sorry. They're kind of the Rosetta Stone, right? Because they speak tech with the developers. They speak. Mike (35:36) Mm -hmm. Rosetta.
Brian (35:57)
business with the stakeholders and they translate across those two groups. So I think, yeah, I think it's important that we're there to try to, if there's communication issues with us and the developers, this is the place to work it out, right? This is the place to say, what do you need from me so that it's more clear the next time I write stories.
Mike (36:02)
Yep. Yeah, that's a good point. What about for the next sprint? What should product owners do this sprint to be ready for the next one?
Brian (36:24)
Yeah, excuse me. Yeah, I think it's important that we really get a handle on what should be prioritized, that we have a good understanding of what's going to be coming up, that we have that idea of what our next proposed sprint goal might be, where we're focused on stuff. And as I said, I want to check in with my stakeholders, especially my key stakeholders, on that prioritization so that it's not a surprise to anyone. I don't want to. I don't want anything to be a surprise when it gets to sprint planning. By the time we circle back around in sprint planning, I want my developers to have looked at these things multiple times before they see it in sprint planning. We've had estimations. We've had discussions about these. So there could have been multiple times we've had conversations about these. So by the time we get to sprint planning, it's not the first time we're looking at these things.
Mike (37:00)
Yeah. Yeah, it should be a surprise.
Brian (37:15)
And that's kind of what I'm trying to allude to here is that there's a series of activities that just are kind of the glue between one sprint to the next sprint. And if we kind of drop that ball in any way, like I said, I can't show up at sprint planning and sort of just say, well, let's see what we got, guys. I have no idea what we're going to do, but let's just take a look. Yeah, I can't wing it.
Mike (37:30)
Right. Yeah, wing it. Yeah, that's not a good approach for things. Brian, you told me a lot of things that product owners should do. I want to twist it a little bit and ask you for one thing product owners should not do before the sprint, during the sprint, before the project, whatever. What's one thing, the one thing you would tell product owners to not do?
Brian (37:57)
Wow, that's such a great question. I think probably the number one thing that I would say is to understand the boundary between the what and the how, and really to try to stay out of the how. What I mean by that is we're in charge as product owners of the what side of the equation. What is it that we're going to be doing? What are we focused on? The developers are in charge of the how. How do we accomplish this? What's the best way to deliver this? And I... I know as a product owner in my past, I've always struggled with that balance of, yeah, but I've got a vision in my head of exactly the way I want it to play out. And I have to kind of rein myself back in a little bit and say, yeah, but kind of remind yourself that that's not really my role here. My role is not to explain exactly how the page is going to need to look and exactly how this feature plays out. If I have no really discernible reason that I have to have it one way over another, right? If there's not like a legal reason or compliance that I've got to do it one way, then I want to as much as possible stay out of the house so that the developers really get to exert their expertise.
Mike (38:59)
Right. Yeah, that's where they're going to be, they're going to be best at. I was describing it as that there's, there is a fine line between what and how, which is why people often will struggle with it. the way I think about it is like every time we dip into that, how at all product owners dip into that at all, they start to kind of take away degrees of freedom from the team. The team has less maneuvering room on how they're going to solve the problem. And great, take away one degree of freedom here and there. It's not going to be the end of the world. Take away too many, and you over -constrained the solution. The team doesn't engage as fully. All sorts of negative things, as you've touched on.
Brian (39:39)
Yeah.
Mike (39:40)
Brian, I want to thank you for letting me take over and turn the tables on you and ask you the question. Since you had made the PDF, I wanted to be the one asking you what your thoughts were on your great PDF that we have for folks. So I'll turn it back over to you. Let it be back to your show now.
Brian (39:41)
Hahaha I... Yeah, no, well, thank you very much. This has been a pleasure. It's been really fun to have to see what it's like on the other side of the table a little bit. So thanks for being willing to do it, Mike, and thanks for being willing to share your insights as we walked through this.

#103: Developer Relations and SQLMesh with Marisa Smith

Join Brian and Marisa Smith as they dive into the world of developer advocacy, the challenges of agile methodologies in data engineering, and the vital role of open-source communities. Discover how to better support and communicate with your developers in this insightful episode!
Overview
In this episode, Brian Milner interviews developer relations expert Marisa Smith to explore the vital role of developer advocates in bridging the gap between companies and their users.
Marisa shares her insights on the challenges of communicating with developers, emphasizing the need to create a welcoming environment for questions and feedback. She also discusses the unique difficulties developers face when implementing agile methodologies, particularly in the realm of data engineering.
They highlight the significance of open-source communities in fostering innovation and collaboration and provide a preview of Marisa's upcoming talk at Agile 2024 on enhancing data pipelines with SQLMesh.
Listen Now to Discover:
[1:08] - Join Brian in an engaging conversation with Dr. Marisa Smith, PhD, Developer Relations Expert, Developer Advocate, and Speaker.
[2:43] - Marisa Smith sheds light on the crucial role of a developer advocate, explaining how they bridge the gap between developers and the wider community.
[3:49] - Brian digs into common mistakes in how we communicate with developers and poses the question: what are we getting wrong in our interactions?
[5:57] - Marisa outlines the hurdles developers face in a Scrum team environment, shedding light on common obstacles.
[12:00] - Marisa explores the hurdles in developer communication, offering insights into improving dialogue and understanding.
[12:55] - Mountain Goat Software offers Working on a Scrum Team, a private class to help Scrum teams foster a team dynamic that supports the whole team, including bridging the gap in communicating with developer teams.
[15:00] - Marisa discusses how SQLMesh has empowered data engineers to streamline their tasks, sparking a sense of 'Marie Kondoing' their work.
[24:11] - Marisa emphasizes the vital importance of open-source developer communities for fostering innovation and teamwork.
[26:51] - Brian shares a big thank you to Marisa for joining him on the show.
[27:50] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email.
[27:54] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, such as CSM or CSPO. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here.
References and resources mentioned in the show:
Dr. Marisa Smith, PhD
Join the SQLMesh Community
Agile 2024
SQLMesh
Working on a Scrum Team
Subscribe to the Agile Mentors Podcast
Mountain Goat Software’s Private Training
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
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.
Marisa Smith is a Developer Relations expert who bridges the gap between the community and development teams, addressing problems and promoting open-source software. With a Ph.D. in Computational & Theoretical Physical Chemistry, she has a background in simulating radiation effects in water.
Auto-generated Transcript:
Brian (00:00)
Welcome in Agile Mentors. We're here for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have the one, the only Marisa Smith with us. Welcome in Marisa.
Marisa (00:13)
Hi, thank you so much for having me.
Brian (00:15)
Very excited to have Marisa with us. If you're not familiar with Marisa, her title is Developer Relations Expert. So right there, that's an episode, right? We could talk just about that. And we'll get into that a little bit more, but there's a lot of really interesting stuff here about Marisa. She has her PhD in theoretical and computational physical chemistry. So...
Marisa (00:41)
Yeah.
Brian (00:42)
Again, wow, right? I mean, this is amazing stuff. She's worked at Streamlet. She was their very first developer advocate there. And she has since, Streamlet's been acquired by Snowflake. And you founded Tobacco Data, is that right?
Marisa (01:07)
Uh, no, I, um, I am their first developer advocate at Tupiqium data. Yeah. No words.
Brian (01:11)
OK, gotcha. Sorry about that. Messed that up. So very, very interesting background. And one of the things that caught our notice, Marisa spoke last year at Agile 2023 and is speaking again this year at Agile 2024. So again, if you're going to come out, I highly recommend you attend her talk. Her talk is called Marie Kondo. your data pipelines with SQLMesh, which I think is really, really interesting. But I'm talking too much, and I want to turn it over to Marisa here. Help us understand developer relations expert and developer advocate. What does that mean?
Marisa (01:59)
Yeah, so I am, what I always say is that I am the person that connects your company to the people who use your product. And it just so happens that the companies that I work for are companies that work in the tech industry. They're building some sort of piece of the tech stack. So the people that use it, their customers are other developer, developers essentially, or technical people.
Brian (02:22)
Yeah, so you're an expert in the...
Marisa (02:27)
in the art of, in the art of like, how do we communicate with other developers? How do we pass that information back and forth between the developers that are making a product and the developers that use a product. And how do we make sure that, you know, we're getting, we're, we're getting the best out of our, out of our users and that they're getting the best out of the technology that we're trying to build for them.
Brian (02:49)
That is so, so interesting. And so I'm sure product owners are listening going, yeah, help me. Help me. I want to understand. How do I talk to developers? So gosh, there's so many directions we can go with this. What do you think people misunderstand most when they try to communicate with developers? What do we get wrong?
Marisa (02:55)
hahahaha Oh, wow, that's a great question. Let me think about this for a second. I think, I think from, from, from my perspective, as somebody who spends a lot of time, like running different communities, especially open source communities, I think that people get the wrong idea in that. Yes, these developers are your customer, but a lot of the time they have very limited time. They come in, they look at, you know, maybe your open source product or, uh, you know, your free version or something that they're trying to see if they can integrate this in their own stack. And I think people can. or companies can come at them a little bit too quickly, a little bit too salesy, right? And then that ends up driving them away. They're like, no, no, no, I'm really not interested in any of this. I'm just trying to figure out if this is the right technology. A lot of developers like to iterate. They try things out, right? And so I think if you come at them too early with, oh, here's our sales process. Here's this, this is how much this costs. It's like, no, no, no, I'm like... way early, I'm MVP POC type of thing, trying to see if I can understand, or if this works with my team, my workflow, my current pipeline, the other technologies that we use, you know, that, that type of thing. I think that's one of the biggest mistakes that you can make, especially when you're talking about open source, which is kind of like my bread and butter.
Brian (04:28)
Right, right. Yeah. And you know, the communication, especially, I mean, because we talk about Scrum and Agile here on the podcast, you know, that relationship between the business side of the house and the developer side of the house, it's almost like, you know, Romeo and Juliet and the two houses, you know, they speak different languages. They want different things. They see the world in a very different way.
Marisa (04:34)
Mm -hmm. Mm -hmm.
Brian (04:58)
And yet somehow these two groups have to figure out how are we going to work together to really deliver something that is valuable, right? So you work with a lot of developers. You talk with a lot of developers. And I know there's lots of different kind of practices and things that are out there that developers are using these days.
Marisa (05:09)
Yes. Yeah.
Brian (05:26)
When you talk to them about something like Scrum, or when that kind of process comes up, what are some of the chief complaints that you hear from developers when they talk about working on a Scrum team? What are they not like about it?
Marisa (05:44)
Ooh, interesting. Yeah, I would say. I would say, I mean, in the area that I'm working in right now, I'm working pretty deep in the data pipelines. So Tobico data runs these two open source projects, SQLMesh and SQL glot. And it's essentially your T of your ETL pipeline, right? We're using SQL, we understand SQL and we're transforming your SQL queries into these tables and we're helping you manage these pipelines as they evolve over time. And so, um, and so I think, you know, in this space, what happens is when you're talking about, you know, working with scrum teams and stuff like that, one of the pieces of agile is trying out new things and iterating. And that can actually be super difficult for a lot of like these data engineers and developers to do, because you have accountability at the end of the day, right? If you're changing up your data, you're mutating some, some SQL query that changes some model that changes your data pipeline downstream. And then all of a sudden. you know, you've pushed it to production and, uh -oh, this data is not what you expected. It's not what you had like originally tested for. And that's because, you know, teams have to work across many different, um, they have many different like iterations that they're working on and many different teams are, you know, making changes potentially simultaneously. And so I think that for, for developers, when you talk about scrum and you talk about agile, particularly if you're talking about like, adjusting tooling or trying out something new again, coming back to this fact that like, you know, they're just there to test things out. They have very limited time and that's because they get stressed out. It's like, well, I don't want to break production. We have to protect production, your production environment as much as possible. And, you know, part of agile and part of doing all these things is trying, trying these new tools, trying these new companies, trying these new methods. And you can get a lot of resistance from that because. they know this method works, they know that they have accountability and they know that production will be fine if they use this methodology that they've set up. Sometimes it can be a little bit of a matchstick thing in the back end.
Brian (07:47)
Yeah. Well, and I mean, just hearing you talk about that and thinking about it, I know one of the big friction points between the business side and the developer side is take SQLMesh. If that's something that my team has never worked with and I have someone on the team who is interested in that and wants to, thinks it might give us some benefits, There's friction there with the product side to say, product has all these things they want, and they want to push these things forward. But I think this bit of adding this to our stack is going to improve things. But how do I communicate that to the business to give us the time to do this? Because it's not directly leading to a feature, but it will improve things moving on. How do you? How do you balance it? How do you have that conversation with a product person or the business side of the house to really say, Hey, this is worthwhile.
Marisa (08:50)
Yeah. Yeah. Honestly, it's super difficult. And I think it's really a balance of, you know, having to have these engineers dedicate some time to new tooling and testing things out. And then once you have done that in their schedule, you know, I don't know how frequently you may want to do it like once a month or something like that, where they, you know, take a day and just review what new is out there. What else should we be looking at? What other tools, what other... You know, with, especially with the emergence of AI and all of that recently, that changes a mile a minute, I think. So, you know, keeping on top of that is, is, is a huge burden on these engineering teams. And so time needs to be dedicated for actually getting that kind of stuff done and the freedom to actually try these things out and do like just a minimum viable product, right? Just a tiny POC with like a little Tinkit data set. And then on, I think there's some.
Brian (09:23)
Ha ha.
Marisa (09:45)
there's some weight of this on the company that's developing these open source products or new tooling, that they have to start communicating and figuring out their business value as well. Because those developers cannot, with this little example, show all of the benefits that you would get. What cost savings do you get? What efficiency savings? What increase in productivity? All of that has to be done by the company and you need to have that ready. so that you can back up your developers that are trying out your product and your open source projects so that they have something to go off of. They're like, hey, look, I made this. It took one week or something like that. And I got it to a place where it's really good and look at all these cool features. And this will make us so much faster in our pipeline. And then here is the company's documentation or case study or whatever it is that says this should increase our productivity approximately this much. And... that these other big companies that are similar to us have this sort of success with it. And, you know, it, I think those two combined can really help alleviate these pressure that the developers feel and give them the time to actually try out new tools, which in many cases they love to do. They love to try new things. They love open source, right. And they will be your best advocates. If you spend the time talking to them, communicating with them and giving them the things that they need to be successful.
Brian (11:12)
Yeah, I would think that's kind of a, there's a duality to, I would imagine your role in speaking with them about your product, because in one case you have to sell them on, hey, look how beneficial this is. This is, you should add this to your stack. But on the other hand, you've got to equip them with the, the, uh, the sales pitch, I guess, that they can then make to their business to say, hey, you should allow us to do this. You should give us the, whether it's finances to do this or the time or the resources to do this, that, you know, it does benefit you as well. So that's gotta be a really difficult part of that communication is kind of, you know, getting people who are not really salespeople, you know, having been a developer, I know I kind of get, you know, the personality type. Uh, and you know, we, we don't want to have to talk to people. We want to be able to put our headphones on and get our work done. Uh, but now, now I'm in the position where if I want to do this thing, I know it is the right thing to do. I've got to convince others and that's not really my strong point. So how do you, how do you help them with that?
Marisa (12:24)
Mm -hmm. Yeah. Yeah, it's definitely a long road. I would say, you know, it's not done in a split second, especially when you're talking about larger companies, like any sort of fan company. They will take a lot of time to make this decision. So you have to be really committed, I think, to each person that you're talking to and each person that you're trying to help get moving with your product to really make them successful. And... For us, what we've been doing recently is we go in and we help them with that communication point, right? Like our developers know our tool the best. And so if there needs be, like we'll stop and we will actually go in and do a presentation to the wider team and be like, okay, you guys have set up this POC. You've tried it out. You really like it. Here are the benefits. Here are, you know, here's how we describe it. Here's how, you know, We have seen other companies succeed with this and we have some decks that are basically ready to go. So we can go in and actually help them with that communication stage as well.
Brian (13:34)
Yeah, that's awesome. Well, then let's, because this is fascinating, and I really enjoy kind of the idea of trying to be an advocate for the developers. But I'm curious as well, with your upcoming talk at Agile 2024, by the way, just I don't think I've said the date, but July 22nd through 26th in Dallas, Texas, go to. AgileAlliance .org. You can find out more information about it. I think I've told everyone here on the podcast, I'm speaking there as well. So come and see both of us in my hometown in Dallas. So Marie Kondo, your data pipelines with SQLMesh. Tell us what was the idea behind this, where you got the idea for this talk, and what it is you're trying to get across in it.
Marisa (14:18)
Thank you. Yeah, absolutely. Well, here's the story. One of our users, I was doing case studies for our, for us, because we need to understand our business value. We need to show people that like they can get this, these, you know, these cost savings, these productivity savings and things like that. So I've been doing interviews with some of the companies that currently use SQLMesh. And one of the, one of the interviewees, we were just chatting and he was like, oh, You know, he brought Marie Kondo up and he was like, yeah, like SQLMesh just brings me joy. It brings joy back to my data engineering. And I'm like, well, wait a minute. What, wait a minute. What do you mean? mean? like, oh yeah. Well, I mean, you know, we spend all of this time. Fretting Fretting about these data pipelines, getting the correct data down the pipeline, getting the business needs on the timeline that they need them, you know, updating your production value or your production environments with, with anything new that's been requested. And.
Brian (15:01)
you
Marisa (15:21)
there isn't really a proper process for data deployments, right? Like for code, you know, we have GitHub, we have Git, we have all these things, right? You make some changes, you save it, you test it out, you make some more changes, you save that, you test that out, right? Like all of these iterations, they create all these versions and these checkpoints. But on the data side of that, there is nothing. It's just like match disks and toothpicks that hold up some of these.
Brian (15:30)
Yeah. Hahaha.
Marisa (15:49)
some of these pipelines, right? And that's become the standard. I'm not saying that this is particular companies that are doing this or something like that. It's pretty much everybody. And all of this falls on top of your DevOps engineers or your data engineers that are a very small percentage of your company. And they're treading through this escalating technical debt, right? Every time you add a new table, every time you add a new dashboard, that's a new backend that they are managing, right? It becomes very stressful for them. And... This individual was saying that he had lost a lot of the joy out of his work and you spend how many hours a day working, right? This is a huge chunk of your life that it's just like, oh my God, I don't want to do this anymore. I don't want to make that change because the pipeline currently works. It's not broken. It's not broken. Don't change that type of thing, right? But this isn't what business is. This isn't what agile is. You're supposed to iterate. You're supposed to make these changes. You're supposed to investigate.
Brian (16:24)
Yeah. Right.
Marisa (16:42)
find new things and find new insights. And you can't do that unless you start changing things. And so he had said that once they started implementing SQLMesh with the different features that it has with this virtual data environments and these data versionings, and we have these data contracts that essentially allow you to turn, have checkpoints for your data and have essentially unit tests for your data. He was like, oh my gosh, now I can not have to worry about it. I can just try something, see if it works. And then if it doesn't, it doesn't matter because I can roll it back super easily and things like that. So that's really where the inspiration came from.
Brian (17:21)
That's awesome. Yeah, that's such a huge hole and it's such a needed kind of component to the stack, as you said, because, you know, I mean, you're right in kind of a programmer world. And, you know, if you're outside of the database world, there's all these tools you can use and put in place and test and see how things are going. But that fear that you have when you work in the database world where if I make the wrong error here, It could mess up all our data. It's not just that it's going to present it in the wrong way, but it could actually damage, which is a valuable asset. It's a hugely valuable asset, the data that the company has, maybe one of their most valuable assets. So yeah, that's an amazing tool. And...
Marisa (18:10)
Yeah. Cool. And these days, yeah.
Brian (18:16)
So this is also an open source project, right? So tell me how that's been interacting with the community on this and working in a corporate environment, but also it's an open source environment on this product that you're a developer advocate for.
Marisa (18:19)
Mm -hmm. Yep. Yeah. Well, I love it. I love open source. As I mentioned before, open source is kind of my bread and butter because Streamlit, you know, was essentially the other end. I've gone from the dashboard side, which Streamlit is basically a free open source dashboarding tool that's built just in Python, to the side of the tables that make that, and the SQL that makes those dashboards possible in the backend. And so this, it's something that I really love about my job because... I've been lucky enough to work with a bunch of tools that are super useful and that people really love, uh, and that they have that they, you know, people who co -founded it, that there are co -founders all came from huge fang companies, right? SQLMesh was basically born out of these data problems specifically to solve them because they had been literally experiencing them at these companies themselves. And they, you know, went out and were like, okay, what's the solution out there? And, you know, uh,
Brian (19:21)
Yeah.
Marisa (19:31)
There's this, there's another company called dbt. They were pretty much the first one on the scene. They've been around for like, I want to say like 10 or 15 years and they changed the space. Like they really did make some huge advancements. But the thing is, is they came at it from a completely different angle than we're trying to come at it because they came at it from the almost like the data science and data analytics side. And they weren't necessarily thinking about future, how big these data sets were going to get with.
Brian (19:52)
Yeah.
Marisa (19:58)
these different like Netflix, Airbnb and stuff like that, right? Their data sets are huge. They're parsing huge amounts of data. And, you know, in the current tools, the systems that you have, you have to refresh your entire data warehouse every time you want to make a change to production. If you have a terabyte worth of data that you're trying to refresh every single time you make a change, that literally, you're just, you're twiddling your thumbs. Your analysts are just like sitting around waiting anxiously to find out.
Brian (20:03)
Yeah.
Marisa (20:27)
you know, if those changes they just made to the sequel is actually viable and good, right? So, sorry, I think I lost. I think they lost the train of the question I got all passionate about.
Brian (20:32)
Yeah. No, no, no, that's fine. That's fine. No, I mean, I was just, I was asking about, you know, kind of the interactivity with the community on that and working with, you know, these open source projects, you know, you have volunteers, you have people who are giving up their time for free, basically to improve your product. That's got to come with a whole just mess of other considerations and concerns and how has that been?
Marisa (21:07)
Yeah, yeah, yeah. So that's been good. And where I had been going with that point was that I've been lucky enough to work with companies and tools that are super useful, that were developed out of pain points that other people have experienced. So that side of things has been really great. When you're trying to develop a community, I just try to make the most welcoming space so that people feel comfortable in asking any sorts of questions. Right? Because that is the only way that you kind of surface some of these things that might've been otherwise hiding. Right? If people are nervous to ask questions, then you're not going to really have a proper conversation around, Oh, well, wait a minute. How did you get to that point? Like what led you to use it this way or to do it this way or something like that. Um, and so, yeah, there's lots of considerations, but we've been lucky enough that the, you know, a lot of our users are very happy with it, but also are.
Brian (21:38)
Yeah.
Marisa (22:01)
because of that, they're very vocal and they are very happy to, you know, take that five, 10 minutes, fill that survey in or meet with me and talk through, you know, a case study or like how they found SQLMesh and how it's going and stuff like that. So I think that the real balance comes in as to how much time do you want to dedicate my time? Do you want to dedicate to doing these interviews and getting this feedback versus Like, oh, we've already got like a pretty large signal that the next feature they need is this. Like, let's just run and do that feature and get that out for them, as opposed to continuing to bog up their time with interview questions or survey questions and bog up my time with it as well. So I think that's more the balancing point is when do you start acting on the signals that you're starting to see from your community versus like just constantly collecting data?
Brian (22:56)
Yeah. And I love your point there about kind of creating that welcoming environment. It's very similar to what we talk about with just teams of the whole psychological safety kind of aspect of it. And if I feel like I can't say something without being made fun of or feel like I'm made to look stupid for my question, then you're right. I don't surface the things that I should, even if it's, you know, just, hey, I'm not sure how to do this and getting help for that kind of thing.
Marisa (23:22)
Mm -hmm. Yeah. And I mean, I feel like with open source communities as well, they're all online. And this is a, I like that psychological safety and I like to try and promote this friendly environment because there's no guarantee that the person on the other end even speaks English. They might be running it through a translator, right? Like you have no idea. So they need to have like that safe place that they can just be like, oh, Hey, I tried this, but I couldn't get it to work. Right. And then that's when you can start to expand and be like, Oh, okay. Well, actually this person is from.
Brian (23:39)
Yep.
Marisa (23:54)
I don't know, like France, they speak French, right? So you're trying to translate kind of back and forth, either in your head or with a tool. And it's kind of like, okay, well, what else can I do to help them? Right? It's like, oh, well, what they need is a more in -depth, like getting started guide, right? We need to add these steps in or put this little note in there that's like, hey, if you get tripped up and you get this error, that's because of this and this is how you fix it type of thing, right? So that you just kind of like fill in those gaps of knowledge.
Brian (24:23)
Yeah. I mean, there's probably so much that we could extract just from the remoteness of the team that you work with, because open source is an area where there is no office. It's not like we all come into the same place. And yet, it works. So for people who think it can't work if you're remote, well, open source is proof that it can. Yeah.
Marisa (24:37)
Yeah. Yeah, absolutely. And not because of that, our team is a hundred percent remote as well. Right. Like our entire Tobacco team works async, right. And we're only able to do that because of different tools and processes that we have put in place and, and that we do have this community and our community is a, is a Slack community. We actually, we could put a link in or something so that people can check it out if they were interested. But, but yeah. And, and that community isn't just about.
Brian (25:11)
Sure, sure, sure.
Marisa (25:16)
that specific tool. And I think that's also another thing that you want to surface when you're talking to developers is that this isn't just a space to ask questions about SQLMesh or SQLGlot, it's a space to talk in general. What are some of the best practices around evolving your data pipelines? What, you know, do you have any questions about your DevOps? Like, you know, what, what are people using for their cloud service provider? Why? Like, you know, did you switch from this to this and, you know, What was your thoughts around that? And, you know, what do people do with a dataset that is, you know, 300 rows and, and like 700 columns, like, how do you deal with this size of data? How do you want to, like, how do others mutate it? Like, do you incrementally load it? So just like try and load in the newest data. Do you only re when do you refresh these, like all these questions and all of this conversation needs to happen because we need to start deciding on a proper process and. DBT had started doing that and we're trying to continue this conversation.
Brian (26:16)
Yeah, I would imagine that's working with the product as well, that that's very beneficial to even product development. Because you can hear from them, even if it's not part of your product, but if you hear those questions about, hey, well, how have you handled this, or what do you do in this kind of scenario, I can imagine that would lead you to maybe new product ideas based off of some of those conversations. Yeah.
Marisa (26:43)
Oh, absolutely. 100%. I don't have like a specific example at the top of my head, but I definitely...
Brian (26:48)
Right. No, no, no. Yeah. Yeah, it could come from this. So it's community, right? I mean, it's just the importance of having that community and not just being, no, we can only talk about this one product here, but no, we're a supportive community and we help each other here. Yeah. Awesome. Well, this is fascinating. And I could talk with you about this for a long, long time. I'm looking forward to your talk.
Marisa (26:55)
Mm -hmm. Mm -hmm. Yeah. Yeah.
Brian (27:16)
So I haven't checked the schedule yet, but I'm gonna, hopefully it's not on one of those times when like, normally, I don't know if you find this as well, but it's like the ones that I start and think, oh, that's the one I really wanna go to, turns out to be the one where you're speaking or somebody who's a lifelong friend is talking at that time. You're like, I can't miss that person's. So I'm hoping that's not the case, cause I really wanna come and hear this talk and hear more about it.
Marisa (27:17)
Great, thank you. Yeah.
Brian (27:45)
Thank you for giving us your time and helping us to understand this, Marisa. I really appreciate you coming on.
Marisa (27:49)
What? Yeah. Thank you so much for having me.

#102: Communicating Agile Transformations with McCaul Baggett

Join Brian Milner and McCaul Baggett as they explore the power of empathy and storytelling in successful Agile transformations. Learn McCaul's five-step approach to effective communication and discover strategies to overcome common pitfalls in organizational change.
Overview
In this episode of the Agile Mentors Podcast, Brian Milner sits down with McCaul Baggett, Chief Agile Officer at CAVU, to discuss the intricacies of communicating change within organizations.
They delve into common pitfalls in Agile transformations and highlight the importance of empathy and storytelling in engaging teams. McCaul shares his five-step approach to effective communication, emphasizing the power of testimonials and spreading awareness.
Tune in to gain valuable insights and practical tools for navigating and leading successful Agile transformations.
Listen Now to Discover:
[1:10] - Join Brian as he welcomes McCaul Baggett, Chief Agile Officer at CAVU and a master of Agile transformation, to delve into the secrets of successful Agile transformation.
[3:15] - McCaul emphasizes the critical role of storytelling in engaging and guiding teams through the process of Agile transformation.
[5:57] - Brian addresses a common challenge in Agile transformations: navigating the unknown and its impact on team dynamics.
[8:01] - McCaul explains how effective communication and a compelling narrative can help teams grasp their value during a transformation.
[10:40] - McCaul advocates for going beyond the basic 'why' by incorporating testimonial narratives to create more meaningful connections.
[14:39] - Brian suggests using these tools to foster empathy, advocating for their use in both top-down and bottom-up approaches when initiating a transformation.
[16:29] - Dive into Mike Cohn's book, Succeeding with Agile, for practical advice on navigating your transformation. Discover strategies for communication, overcoming resistance, and other key aspects of Agile success.
[17:54] - Brian inquires about effective ways to connect with and engage resistant individuals within the team.
[22:49] - Join McCaul and Brian as they discuss the importance of creating specific best practices that suit the unique needs of this particular team and organization.
[28:07] - Brian shares a big thank you to McCaul for joining him on the show.
[28:33] - Join Brian in attending Agile conferences to connect with and learn from Agile experts and peers, fostering valuable discussions and insights.
[29:53] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, such as CSM or CSPO. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here.
[30:35] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email.
References and resources mentioned in the show:
McCaul Baggett
Communicating Change Made Easy with McCaul Bagget and Tom Bullock
Succeeding with Agile by Mike Cohn
Agile 2024
Subscribe to the Agile Mentors Podcast
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
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.
McCaul Baggett is the Chief Agile Officer at CAVU, specializing in Agile transformations and effective communication strategies. With a focus on empathy, storytelling, and practical tools, McCaul helps organizations navigate change and foster sustainable Agile practices.
Auto-generated Transcript:
Brian (00:00)
Welcome in Agile Mentors, we're back. This is another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have the one and only Mr. McCaul Baggett with us. Welcome in McCaul.
McCaul Baggett (00:13)
Hey, thanks Brian, really glad to be here.
Brian (00:15)
Very excited to have you. For those who aren't familiar with McCaul, McCaul is the chief agile officer at Cavu. He has been working in transformations for quite a long time doing some large-scale transformations at different organizations. One that he is allowed to publicly mention is John Deere, but there's others that he's been a part of as well. You know companies are funny that way. They don't always necessarily want you to publicize things for some reasons. I don't know why.
McCaul Baggett (00:43)
Yeah.
Brian (00:44)
We were joking about that earlier. But I wanted to have him call on because we were both at the Agile 2023 conference, and I saw him on the agenda, and it was one of those sessions I didn't get a chance to go to, unfortunately, but really thought it was an interesting topic. I wanted to have him come on and kind of chat with us a little bit about this. So his topic was about communicating change and communicating change in an easy way, you know, kind of making that an easy process. So let me start there with you, McCaul, on this is, what do people get wrong when they're going through a transformation and we make the decision to go through a big change in our organization? What are some of the common pitfalls organizations fall into when they make that decision?
McCaul Baggett (01:34)
Well, let me start by saying it wasn't me solely that was doing the talk. I did have some partners there with me. And if you look it up, you should definitely speak to them as well or look them up as well. Dana Dismukes is a transformation lead for Dell. Tom Bullock is the chief storyteller for Scrum Inc. And really the academics of the talk came out of Tom's brainchild. But through my work, I got a chance to apply it. And it was precisely because of this very issue, the ch- the- non-working approach that many organizations take to communicating about change. There's a tendency in a lot of change management structures to discuss the need for communication, but as Agilists, we don't inherently do a lot of study of the nature of communication. And so I would say probably the biggest, most common error that people in a transformation of any kind and most close to my experience in Agile transformations make in communicating about change is going about it from a way that is, from the perspective of trying to reassure their teams, their departments that this is something that has leadership endorsement by communicating from the top down. I mean, please forgive the hierarchical metaphor, but getting some senior leader to say, hey, this is gonna be great, you can do it, we're gonna do this. When in fact, the most effective way to communicate to someone, especially someone who's not fully bought in, is by telling them a story of someone who is like them, has experience like them that they can relate to. And that storytelling perspective is what we talk about in this talk, Communicating Change, maybe.
Brian (03:16)
Yeah, there's a lot just in there to unpack. I mean, just the idea, thinking about, I've talked with a lot of organizations and a lot of people have come through classes and stuff that I've talked with who are going through changes like this, but then they're not really even sure how much their leaders are on board with this. They just, they have some layer of management who says, yeah, this is what we're gonna do, but do the people at the top really feel that way? Do they even know what it is that we're doing?
McCaul Baggett (03:34)
Sure. I mean, that's even tougher. I would find it hard to even consider it a true transformation if you can't be sure your leaders are bought into it. But you're not wrong. It is stunning how often you get these folks that you run into and they say, my leadership may be willing to do this. I teach a lot of Scrum at Scale. And so we talk a lot about executive Metascrums and executive action teams and prescriptions about how involved the leader should be. And people will sort of stop and say, wait, you want a leader to meet about team obstacles every day? And I say, yeah, or however long those executives are willing to let their teams go without support to removing their obstacles. Like, what is it that they're doing that's more important than clearing the impediments for their teams? But that does tend to be the perspective is, I don't know if my leaders even bought into this change. That's tough.
Brian (04:34)
Yeah. Yeah, it is. And I think that speaks to some of the fundamental flaws, I think, that people have with transformations before you even get to communicating, right? Just do we know why we're here? Do we know what it is we're trying to do? Those kinds of things. I like to focus on the communication, though, here because communication is such a
McCaul Baggett (04:46)
Yeah, that's true.
Brian (04:56)
delicate beast. I mean, it just, you know, when you're trying to speak with another human, even if it's just within your team, you know, it's difficult because we're different personalities and we have different backgrounds and everything else, much less when you're talking about it over an entire organization. I would imagine, and you, I mean, correct me if I'm wrong on this, but I would imagine that one of the biggest sources of kind of consternation or, you know, anxiety I think when these kinds of things happen is the unknown, just not really understanding how do I fit in and what does this mean for me.
McCaul Baggett (05:33)
Yeah, I think you're absolutely right. Sometimes it's phrased that it's termed what's in it for me. And I think that's the wrong perspective to take. People aren't often necessarily, people are not always looking for some kind of payoff for the transformation. They don't need to know sort of what they get out of it. But I think that you really put your finger on a lot of the reason that we see trepidation with a transformation is because it implies that
Brian (05:38)
Mmm.
McCaul Baggett (06:00)
Business as it had been occurring before was not acceptable. What you'd been doing previously was not good enough. And now we need to get you to do it another way. That inherently sort of fundamentally starts with a position of questioning whether or not your position is stable. And that gets, you get some amygdala hijack stuff going on. You get the brain started worrying about existence, not just change. So you're right, contextualizing.
Brian (06:26)
Yeah.
McCaul Baggett (06:29)
your communication about this is really important. And I think taking a perspective of empathy and meeting especially resistance in a change environment, a changing environment, meeting resistance with an attempt to understand the perspective really fundamentally underpins any successful communication you're gonna have about change management in general, but communication in particular.
Brian (06:52)
What do you think about that, McCaul? I mean, if you're a leader in that kind of organization and you recognize this and you see, people are gonna, I'm gonna send people into a little bit of a panic, right? Because you're right, there's no way that I can hear that message, hey, we're gonna do things differently than the way that we've been doing them without kind of self-internalizing, well, that means that something I've been doing has not been acceptable, it's not been good enough, it's not been what the organization needs. How do you communicate that in a way to say, no, it's not you, right? It's kind of a process thing. It's not that you did anything wrong. It's that we found this is a better way of working.
McCaul Baggett (07:30)
Yeah, so I think starting with that fundamental basis of why this is occurring is really key. But even before you get to the communication about why, it's really important to figure out who it is you're speaking to. So going back to that sort of, that empathy piece, there is a need to get that communication about, okay, it's not that you did anything wrong. and here are the reasons why we're doing it, that is the message we're looking to communicate. But at a communication level, like understanding even how to begin that communication really requires us to take a step back so that we can consider the people we're telling that story to. So just to connect this to the topic that actually came up in the talk about how we do that communication, it's really fundamentally about, and just a quick aside about that talk. So in the Agile 2023 conference, we actually applied for a longer workshop, like 120 minutes, 160 minutes, one of the long time boxes. And they'd come back to us and said, why don't you do one of these 30-minute segments? So we really pared down a lot of the things that we wanted to say. And so to connect back to what really, what emerged was actually, it was actually probably a better talk than if we'd had a longer period of time to do it. We just, we had to cut everything until we could come back with just,
Brian (08:36)
Yeah. Hahaha. Mm.
McCaul Baggett (08:58)
the real good nuggets. And what stayed was this. In order to communicate effectively when you're going through any kind of change management process, first of all, having a change management process and a plan for how you're gonna manage that, that's your beginning. But to get a little bit more particular about how we communicate about that change, there is one technique which we agreed was probably the thing to focus on so that it would be most universally helpful. in any stage of a transformation that was going on. And that was creating a, finding a way to create a narrative, a personal narrative that could connect to the various people that you're trying to connect to, right? So to create a testimonial. And so we spent our time in that talk discussing how to really get a useful testimonial. And then once you've... got that how to do something useful with it. And we outline kind of five steps for how to think about this. Brian, tell me if I'm getting too deep or you kind of want to... Okay, cool. And I don't know that these are the only five steps. We try to make it easy to remember. The takeaways that we were trying to give were, you have to be first thoughtful about what it takes to make a compelling testimonial. So this is where I mean, you can't start with why.
Brian (10:00)
No, no, this is awesome. Go for it.
McCaul Baggett (10:21)
we're doing this, you have to start with who you're speaking to about why. Because the why shifts. If you're speaking to stakeholders, there's one why. And if you're speaking to the organization, to your employees, to the people that are doing the work, it's not that the why is different, but the way that you talk about it may be different. So once you know what it's going to take to make the testimonial, the next step would be to think about how you can work. how you can set yourself up ahead of time to maximize the potential to make an impact with your audience, to plan. how you're gonna get the story, the testimonial that's gonna resonate. Which is the story that I wanna tell? So fundamentally what we're doing here is we're assuming that, testimonial, this is only one way to communicate, but it's a fairly useful one universally. If you're going to try to get that testimonial, what are the questions that are gonna be useful to the who that you've identified ahead of time? What is the story you need to find to tell? Then step three is actually. having the conversation. So you've already done a lot of pre-work ahead of time before you even begin the process of the discussion. And then once you've started the discussion, once you've got it, using that testimonial, which is typically recorded kind of like this, grounding that in a way that doesn't sound overly positive and really connects with reality, and then using what you've got to spread that awareness as broadly as possible. So five steps. Know, think, get. ground and grow. I don't know if that's a useful mnemonic of any kind, but that's what we came up with.
Brian (11:59)
That's awesome. No, like I said, easy to remember. Just a few things to kind of keep in mind there. Yeah, I love the concept of telling it as a story, that we're not just, because that makes it much easier for me to see myself then fitting in there. Like we talked about earlier, right? If I have a fear of, oh my gosh, does this mean that I'm gonna lose my job? Does this mean that I'm gonna have to... McCaul Baggett (12:03) Yeah, just five steps.
Brian (12:24)
now do something that's very different from what I've been trained for or what I'm used to doing or what I wanna do as a career, telling it as a story can kind of allow me to see myself in the story.
McCaul Baggett (12:37)
You are exactly right. Not only does it allow you to do that, we as humans are wired to do that very thing. We do it all the time. In fact, when you're listening to a podcast like this, you'll often sort of have the sense that you're sitting at the table, thinking through, like you're literally exercising pathways in your brain as if you were participating in the conversation. And that direct involvement allows you to mitigate some of the inherent resistance that you. that you find, that amygdala hijack, that fight or flight response is not present because you're following along in a story, hopefully about a successful element of the transformation. So you really engage that piece right from the very beginning.
Brian (13:20)
Yeah, I love this and understand to the listeners as well, right? I mean, we're speaking at like a neuroscience level here and trying to understand that, you know, the preparation that needs to be made so that, uh, like McCaul is saying, there's not that amygdala hijack going on of just saying, uh, oh my gosh, I'm panicked. I can't get past this panic. Uh, you know, in my, that's going on in my head that has to be stripped away. That has to be. resolved so that now I can start to learn, now I can start to see and form, like you said, the new pathways. And that is, you know, physically what's going on. We're forming new connections in our brain to say, oh, I've never seen it this way, but let me try to make this connection and see it a different way.
McCaul Baggett (14:10)
Yeah, not only is it important to do that, we as humans, now I'm stepping a little far beyond my training, so I'll be careful. My understanding is that fight or flight response really lives in an entirely different system, in the limbic system of the brain, much earlier part of the brain. And in order to engage the neocortex at all, or in any significant way to create those
Brian (14:21)
Ha ha ha.
McCaul Baggett (14:39)
pathways to be able to see a perspective of the other than our own, we have to kind of dampen that limbic response, that fight or flight. Will I, won't I have a means to feed myself beyond this space? Am I safe before we can start to begin that conversation, to begin that connection with someone we want to connect to?
Brian (14:59)
Absolutely. And I think this applies not only, I mean, we started in kind of approaching this from sort of a high level top down, like you said earlier. But I think it applies even if you're a Scrum Master, or maybe you're part of a small group in the organization. Maybe you are in an organization that's not agile in any way, but you've gotten permission to have a pilot, to just have a pilot team.
McCaul Baggett (15:08)
Sure.
Brian (15:28)
and your desire is to grow this in the organization, or maybe they're doing it poorly and you wanted to have one pilot team that does it the right way so you can start to spread this out to other places. All this applies, I think, to you as well because you're gonna be communicating this and you're gonna encounter the same resistances, right? You're gonna have the same kind of skepticism. You're gonna have the same kind of possibility have someone have amygdala hijacks going on thinking, Oh my God, what's this guy doing? What's this woman doing? Why is she trying to make these big changes in the organization? Is she gonna try to change my job? Yeah, am I under threat? So while we started top down, I think it applies bottom up as well. They're all principles I think we have to think through before we even start to try to communicate with this.
McCaul Baggett (16:05)
Yeah, am I under threat? Oh, absolutely. I mean, any good scrum master is gonna be thinking and hopefully practicing their ability to deal with any tense conversation. And so that limbic engagement, that epinephrine and adrenaline start coursing through the brain. And you can see it in many people when you're looking at group dynamics, regardless of large or small group dynamics, but any group. that shutdown of the ability to really process new information and assimilate it, you have to start by working past the threat. You have to get people beyond that sort of defensive place before the conversation can even begin. Yeah, I agree.
Brian (17:01)
Yeah, yeah. Awesome. Well, in how we're talking about this, I kind of had this one scenario in mind I wanted to kind of run by you because I know I've encountered this before. I know, you know, I've encountered this in classes before. So I'm curious kind of how this communication approach would kind of adjust for this kind of individual. But what about the person who just sort of is crossing their arms
McCaul Baggett (17:11)
Sure, hit me.
Brian (17:28)
And they kind of take the approach of, ah, this is a fad. It's not so much as an active, hey, I'm gonna really counteract you and go against you to try to dispreview, but I'm just gonna, you know, I'm not budging. I'm gonna stay here, because I know this is a fad and it's gonna change eventually back to the way I wanna do things. So you do whatever you wanna do, but you know, I'm not gonna get on board with you because. I've seen lots of things come and go on this is just another
McCaul Baggett (17:59)
I think that takes a couple of forms. Certainly some of those, and particularly when I've been asked by an organization to come and do training, you get a lot more of those because, nope, they didn't raise their hand to come and join a public class or something. I think there's really two significant flavors of that engagement. One is, as you described, someone who's just sort of like passively waiting for this to sort of blow on by. And that's a lot more tricky than the one that's actively pushing back. By far, I prefer someone who's willing to stand up and say, this is not going to work here and here are the reasons why. Because to come into the space of someone who is not choosing that engagement is inherently threatening. So you've picked a very challenging person to get through to, um, because directly calling them out and being like, Hey, Brian, you've been really quiet. What do you think of what's going on? when they were not inclined to share that, sort of already starts to engage that, am I prepared to risk saying out loud what I think is gonna happen? And it also, it could inherit, it could just by the nature of asking them to speak out loud that they don't believe in what's going on around them, sets them apart from the rest of the group and could mean that makes them something of a target if they don't feel like their culture is a safe place to speak. So, That is your problem Often I have found that a testimonial based approach, one where you can tell someone's stories about someone in a similar position, not stories about why this is going to work from a leadership position, but a testimonial based communication campaign is one of the best ways to reach folks just like this. You don't need to directly address them. You don't need to confront them. It's fine. If you're not, if you're not buying this, that's okay. Why don't I tell you about where it's happened elsewhere? And frankly, that thing is one of the things that training in person used to be so great for, because you could stand away and kind of watch these people who weren't necessarily bought in, sit back and just study what was going on in front of them. It wasn't being forced on them. They could just sort of watch their teams and you'd do something silly like.
Brian (19:58)
Yeah.
McCaul Baggett (20:17)
play any number of the Agile games that are meant to demonstrate things like small batch processing or teaming, right? Team dynamics and that joy that human collaboration and competition can bring in a really small scale in a very short amount of time and like a magic trick you could be like was that fun? Was folding these paper airplanes and throwing them across the room fun? And they'd be like yeah it was fun it's paper airplanes whatever I'm not working and then you could take a step back and say okay Was it fun because you just love folding paper airplanes or was it fun because you were making connections with people that you don't get to do in your daily job? And just sort of, again, the story here is, look what's over there. Look what this says about the nature of communication. It's not testimonial based per se, but it is lighting that fire, that inspiration that I always loved about training. And it's not just in person, but it really... I do miss that about in-person training because you could really connect really well.
Brian (21:19)
Yeah, I mean, we're talking about communication in general and we can't escape the Agile Manifesto comment about it. It's best done in person face to face, right? So it doesn't mean you can't in another way, it just means it's best that way and it works easiest that way, right? Yeah, I completely agree. Yeah, I just wanted to just, go ahead.
McCaul Baggett (21:28)
That's right. That's right. I'm sorry. Not to go too far off topic, though, but to that very point, we see this request of many executives later, the return to the office movement being another form of, is that the best way to communicate? Yeah, it is. Is it the only way to communicate? Should we be seeking that to the detriment of our work forces at scale? And there are many reasons that people are choosing to encourage their. employees to come back to the office. But I think part of that is because leadership is also far easier in person. So we're missing some opportunities for leadership to understand how to lead remote teams and may have caused that sort of same challenge. Anyway, another topic.
Brian (22:23)
No, no, I agree. And I think that part of that as well is just kind of the general whole. I've talked about this a couple of times in the podcast where we, we seem to be stuck in a cycle of trying to find out what is the way to do something versus what is the way for this team, for this organization to do something. There's lots of data out there that we can get, can inform us. Just like if I'm a product owner. There's lots of data that can inform me about the market, but ultimately I've got to make the call about what's right for us to do next. Same thing with the organization, same thing with the team. What's going to work in this instance?
McCaul Baggett (23:03)
Absolutely. It's probably one of the biggest challenges that I think, uh, when we see transformations, not even transformations, when we see an agile, um, enthusiast really go off track and good. I did it for sure when I was a new scrum master. Like this is how the scrum guide says we're supposed to do things and we're not doing these particular things. We need to do scrum the right way. that sort of the willingness to take a step back and say, well, there are a lot of better practices. Is there a best practice in our case that is true? Actually, the challenge is not, is there a better practice in all cases? And almost certainly not, but there may be a better practice in our case, even a best practice in our case, but you have to be willing to let go of the dogma of this is the way it's meant to be, and instead seeking, seeking to be informed by these, yes, science-based studied practices. It is better to be in person, but let's not fire all our remote employees. Let's, let's figure out another way or let's make teams that can figure out other ways to do it.
Brian (24:11)
Yeah, absolutely. Yeah, we're in an interesting time, I think, as far as that's concerned, because like you said, it's the dogma, I think, of pragmatism and what's gonna work best in this scenario. Yeah, I struggle a lot in classes, even, when people will bring up certain topics, to ever say always, that this is always, it should always be this way.
McCaul Baggett (24:22)
Yes. Yes.
Brian (24:36)
Because I don't know, I frequently will say things like, my experience has been, what I have seen is this, but that's just my experience. And that's a limited set of experiences. You have to line that up against what you've experienced and what your organization is going through and say, hey, does this sound similar? Are we seeing those same things? Are we not seeing those same things? There are best practices. There are some things that we could say, yes, this... And a lot of situations will work best in this way, but not all. And that's where it takes experience. That's where it takes somebody who's been there before to know.
McCaul Baggett (25:16)
Well, yeah, and a lot of this grew up in a very particular environment, right? So Agile practices, many of the ones that we've adopted, grew up through software, and through software in North America. So one of the things that I've been passionate about, and one of the reasons that I've pursued the career that I have is because a lot of the Agile community looks like you and me, right? So if you take into account not only are these the, quote,
Brian (25:29)
Ha ha.
McCaul Baggett (25:43)
but it's for teams that tend to look like you and me, tend to live in North America, and tend to be working on software. And that's such a narrow area that we're foolish to assume that such a thing as best practices have been codified yet.
Brian (25:58)
Yeah, no, and please, for the listeners, don't get me wrong because if you listen to the show, you know I'm a geek for the data. And I love being able to have really hard scientific data that you can look at and say, hey, studies show that this is how you do this, but you gotta be cautious about asking, was that a rigorous scientific actual study or was this just an internet sampling?
McCaul Baggett (26:13)
Yes.
Brian (26:26)
That's not a scientific study. That's just kind of gathering people together and saying, hey, if this group of people who choose to respond to this, what do they think about something versus something else? But you're absolutely right. You have to understand the basis of where this comes from. And the basis of where we get a lot of our stuff is people who look like you and me, who have been working in the software industry for kind of the time we've been working in the software industry. So things have changed.
McCaul Baggett (26:50)
Yeah.
Brian (26:53)
cultures change, cultures bring different dynamics into things. And what works for my team of five, six developers based here in Dallas, Texas, is going to be very different from my team that I have five people in India and three people here, or even all the team is in India, or all the team is in Malaysia, or all the team is in Saudi Arabia or Ireland. I've worked with teams all over Israel.
McCaul Baggett (27:09)
Yes.
Brian (27:23)
You work with teams in different cultures and you have to understand what the playbook I used for that last team ain't gonna work for this next one because they're different people.
McCaul Baggett (27:32)
I heard the term coined radical pragmatism. It was, JJ Sutherland said it. And it was, it is precisely what we should be shooting for. Radical pragmatism informed by the best data, informed by the best science, and then immediately thrown away when it's not applicable to the situation we're in. Yes, these are the ladder, the rungs, the steps to head in the direction we need to be headed, probably, but let's evaluate them for ourselves and reevaluate.
Brian (28:02)
Yeah, if you're gonna go buy a car, you're gonna do your research, you're gonna figure out what gets the best gas mileage, blah, right, all this stuff. But then you're gonna get on the line, you're gonna test drive and go, I just like the way this feels. Ha, ha, ha.
McCaul Baggett (28:12)
That's right, test drive the car, yes, for sure.
Brian (28:16)
Awesome. Well, this has been a great conversation. I really have enjoyed having you on, McCaul. And yeah, thank you for kind of sharing kind of some of the wisdom in there from the talk. I know we, you know, the talk was not long and we have not long to kind of dissect stuff here in our podcast, but I appreciate you making time to share with us.
McCaul Baggett (28:36)
Absolutely, Brian, this is a pleasure. And if you ever need somebody to shoot the breeze with again, give me a call.
Brian (28:42)
I will take you up on that.
McCaul Baggett (28:43)
Thanks.

#101: Fostering Sustainable Change with Leor Herzfeld

Join Brian as he discusses the crucial elements of sustainable agility with Leor Herzfeld, Agile Coach and CEO of Integral Agile. Dive into the human side of sustainability and discover the 14 dimensions essential for creating a culture that truly engages.
Overview
In this episode of the Agile Mentors Podcast, Brian Milner sits down with Leor Herzfeld to unpack the concept of sustainable agility from a deeply human perspective.
They explore why external changes often fail and how a focus on individual health—encompassing safety, autonomy, mastery, purpose, and accountability—can lead to genuine, lasting transformation within organizations.
Leor shares practical tools for leaders looking to foster an environment that supports continuous agile practices and nurtures employee engagement. Listen in as they discuss how to achieve a resilient and thriving workplace.
Listen Now to Discover:
[1:01] - Join Brian as he explores the vital role of sustainability in Agile methodologies with expert guest, CEO of Integral Agile and author of the upcoming book Reimagine Transformation, Leor Herzfeld.
[2:09] - Leor delves into the meaning of human sustainability, explaining its significance and impact.
[4:33] - Brian discusses the inherent resistance to change, noting that even positive transformations require adjustments.
[5:22] - Leor poses the shift from thinking about only the holistic, healthy Agile culture and team to focusing on a healthy individual.
[7:14] - Brian and Leor explore what sustainability and sustainable pace practices entail in real-world scenarios.
[10:03] - Leor examines the reasons behind employees' lack of engagement in their organizations and work environments.
[11:49] - Leor discusses 14 key aspects of individual health that are essential for creating a sustainable and healthy environment at both individual and organizational levels.
[14:03] - Leor shares a tool to assess the Agile health of your team or organization.
[14:53] - Enhance your team's performance with Mountain Goat Software’s specialized private training, including exclusive classes for leaders that accommodate their busy schedules. Dive into training that promises to elevate your team and organizational health, ensuring success across the board. You can email the Mountain Goat Software team for detailed information.
[16:43] - Leor shares how he measures the sustainability and health of the teams and organizations he works with.
[18:46] - Brian highlights a frequent issue encountered in classes: Agile teams feeling unsupported by their organization's culture.
[22:27] - Leor delves into the evolving landscape of the Agile world, exploring how shifts can foster greater organizational support and, thereby, sustainable environments.
[28:58] - Brian shares a big thank you to Leor for joining him on the show.
[29:52] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, where we get right into the good stuff and have some deep discussions. We'd love to see you in one of Mountain Goat Software's classes. You can find the schedule here.
[30:17] - We invite you to subscribe to the Agile Mentors Podcast. If you have feedback or a great idea for an episode of the show, send us an email. We can’t wait to hear!
References and resources mentioned in the show:
Leor Herzfeld
Integral Agile
Integral Agile Health and Happiness Assessment
Reimagine Transformation by Leor Herzfeld, David Hersey, Ben Williams, and Julio Pizarro
Organizational Transformation: A Case Study For Creating A Cross-Functional Team Of Teams (Art) Aligned To A Value Stream
Drive: The Surprising Truth About What Motivates Us by Daniel Pink
Agile For Leaders
Mountain Goat Software’s Private Training
Subscribe to the Agile Mentors Podcast
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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.
Leor Herzfeld is an Agile Coach and creator of the Integral Agile Approach, combines his artistic and scientific expertise to drive transformative changes in the financial and educational sectors. He is dedicated to developing advanced collaboration tools that enhance organizational design and enable seamless workflows, drawing from his unique blend of artistic vision and scientific insight.
Auto-generated Transcript:
Brian (00:00)
Welcome in Agile Mentors. We're here for another episode of the Agile Mentors podcast. I am with you as always, Brian Milner. And with me today, I have Mr. Leor Herzfeld with us. Welcome in, Leor.
Leor Herzfeld (00:13)
Thank you, Brian. Happy to be here.
Brian (00:16)
Excited to have Leor with us. Leor is somebody who we kind of cross -passed at the Agile 2023 conference this last year. And he had a talk there that was really, really interesting. And we wanted to have him on for a while now to kind of share some of the insights from that talk with us here on the podcast. So his topic was called sustainable agility. But we were talking about this before he had. So Leor, I'll kind of turn this over to you. Help us understand, because it sounds like that's maybe, that might be a little misleading into what we're really talking about. So what are we really talking about?
Leor Herzfeld (00:56)
Well, yes, so it's misleading from the perspective of sustainability with regards to the buzzword that it is today, right? So we think about, you know, are we being ecologically responsible and so on and so forth. But in fact, this is sustainability from a more human perspective. So what happens typically when the coach or scrum master leaves the team? Oftentimes things fall apart, right? When that kind of protective presence leaves. the gains that were made tend to erode. Now, why is that the case? Often it's the case because whatever change they've put in place was external. It was a process -oriented change and it's not something that really penetrated into the hearts and minds of the people there.
Brian (01:44)
Yeah. Yeah. I make an argument there as well. Cause I know this is something that, uh, like Lisa Adkins will, will mention is that, you know, if that, if that coach that leaves and there's a vacuum and a hole, and now they're kind of lost, that coach didn't really do a great job because part of our role is to create that capability so that they don't depend on the coach. Right. Um, so yeah.
Leor Herzfeld (02:10)
Yeah, and you know, I'm going to go ahead and take the coaches side here, which is a rare point of view for me. Don't get me wrong. I love coaches and I love agile. But I often think, you know, sometimes coaches might be coming at the situation from, you know, a lack of empathy. You know, they're very process oriented and I've heard many coaches blame the client for, you know, not listening to them where.
Brian (02:16)
Hahaha.
Leor Herzfeld (02:36)
you know, as a coach myself, someone who's been a coach for 15 years, I've always felt like it's my responsibility to connect empathically with the person because what are we doing when we're coming in to bring in a massive change? And in essence, Agile is asking people to think backwards, right? It's thinking from the perspective, whether we're talking about, you know, the definition of success is no longer output, it's now outcome. or we're not going to do right to left planning, they're going to say, oh, when's something going to be done? And we're going to say, well, I don't have a baseline for how your teams are performing yet. So let me get back to you in about a month after we'll establish what the team's velocity and throughput is. And that's a terrifying thing for people to hear who are accustomed to doing things a particular way for five, 10, 15 years. So when coaches come in and they're just like, well, here's the process and it must be done this way, why aren't you listening to me? You know, that's where I sometimes take exception with how coaches approach it. I see it as a personal responsibility as a coach to understand the intrinsic motivations of every individual with whom I encounter and really help them get that I understand that you're taking a risk. I understand that you've spent, you've gotten where you are today in terms of your career. You've gotten here by doing these things. And I'm now asking you to throw that out the window and do things differently.
Brian (04:02)
Yeah, it's tough. I mean, the change in itself, anytime we go through change, it's hard and there's resistance to any kind of change that we encounter in our lives. You know, even changes that we would seek out, you know, like getting married or having a kid or anything like that, you know, like it's, we, we, we, uh, we enter into those changes very willingly, but it doesn't mean that every aspect of that change is something that we embrace wholeheartedly, you know, uh, There's adjustment periods and there's just something that you got to get used to when you go through those. And I agree with you. I think the organizations are the same way, the people in those organizations. So I love this approach. I love kind of thinking about it from the human perspective and kind of the impact it makes there. So let's go further into it. So if we're talking about kind of the human aspect of this, help us understand that a little bit more.
Leor Herzfeld (04:56)
Right. So this is something that, you know, that integral agile, this is my company, we've created the integral agile approach. It's intention. So when I say I'm having empathy for coaches here, agile talks about how important the mindset is. And they talk about how important it is to create a healthy agile culture. But if you Google how to create a healthy agile culture or how to cultivate a healthy mindset, there isn't anything that someone can have a look at. and say, oh, I'll just do that then. And the reasons for that are, of course, is it varies place by place. And it's ethereal, right? It's a very difficult thing to codify. We've tried to do that anyway. So the basis of the talk I gave at Agile 2023 was about, if we're talking about sustainable agility, the individuals. So Agile often talks about healthy teams. But I never hear it talking about healthy individuals. And is it possible to have a healthy team if the individuals who make them up are themselves not healthy?
Brian (06:05)
Yeah, that's a very, very good point. And by the way, I got to just stop down here because I got so excited with our topic that I kind of skipped over really giving Leor a proper introduction. I'd said that we cross paths from Agile 2023, but you just reminded me that I didn't really introduce you. Leor is the CEO of a company called Integral Agile. And their philosophy is trying to work to have Agile deliver the results that it promises, which is, again, we were talking a little bit before we started about how that's just not always the case. We see, in fact, it's often not the case. There's a lot of circumstances where organizations are just not getting the promise that they thought they were going to get with Agile. There is a book that is not out yet, but is coming out that Leor is going to have out in a bit called Reimagine. transformation. And so be on the lookout for that. That's going to be a really, really important book, I know. So sustainable from a human perspective, sustainable is the person healthy, is the person working in a way that they can kind of keep that up over a long period of time. There was an interesting thing I came across actually on this that I don't know if you've. encountered this or not, but I know when the whole agile concept of working at a sustainable pace, before that even came up, I think it was from the XP team, when they had originally started to deal with this whole concept of sustainability, their original kind of approach was about, when they started, they actually quoted it as something like, people shouldn't work more than 40 hours a week. And they started from that perspective of we got to limit all this because we're having all these people work nights and weekends. And so let's just say people shouldn't work more than 40 hours a week. But that adjusted over time and it changed it to sustainable because what they realized was, well, for some people, sustainable is less than 40 hours. For other people, it's more than 40 hours. So who are we to say, you know, Hey, this is what sustainable is for you. You've got to find your own sustainable pace.
Leor Herzfeld (08:31)
Yeah, and sustainable pace is a part of it. But you know, if we're talking about so you you, you also may have seen, you know, the Gallup State of Work poll that came out last year. And we've heard about quiet quitting. And, you know, you just have to see now, especially with with Gen Z coming into the marketplace, and, you know, they've got a completely different mindset and they have different expectations at work. They have expectations that are valid. They have expectations around psychological safety, diversity, equity, inclusion. There are things that organizations are struggling to adapt to because there's been this kind of like, you're going to come here and work and you hear people being called resources and that makes us cringe. But there's this old school mindset. And again, I really want to respond to this with empathy and not make like where we are in the world today. This is a slice of human history. And it's very easy to look at, you know, to try and make things wrong, whether it's like there's a mismatch in culture, you know, boomers versus Gen Z versus, you know, millennials, Gen X, whatever. We've got different cultures. We've got different mindsets and we need to figure out a way to come together. So something like... Let's not work 40 hours a week is important, right? But it's not sufficient to say, okay, well, we now have a healthy individual.
Brian (09:55)
Yeah. Yeah, there's a lot more that goes into it, right? There's, I mean, that is part of it, obviously, because you don't want to have burnout and everything else, but I love you bringing up the point about quiet quitting and engagement. You know, there's clearly, you know, lots of organizations deal with this issue of engagement and having a disengaged workforce and trying to have engagement initiatives and raise the level of engagement of employees and all that kind of stuff. So it's clearly a recognized problem. It's clearly something that organizations struggle with and have experimented and tried to find solutions to. So from your perspective, what do you think about that? Why do you feel like organizations are having such a big issue with engagement with their employees?
Leor Herzfeld (10:44)
I think people don't feel valued. They feel like they're fungible parts in the machine. But more so than that, they lack a connection to purpose. So most folks operating in an organization don't know what the organizational purpose is. And if they haven't done their own personal development work, they probably don't know what their own personal purpose is. So they're in there to get a paycheck. And there's this kind of adversarial relationship. I would think most people kind of hate work, right? And again, maybe this is me just being utopic, but I really feel like it doesn't have to be that way, right? And there's this idea of, you know, even in any, something like a retrospective, we don't have time to do the retrospective. So like, you know, oh my God, if we're gonna try to really get down to a human level and try to connect with our people and see what motivates them intrinsically, Like who has time to spend on that? But wow, if you spend the time on that, what do you get? What's your return on investment there? If you can actually help a person connect to what they're passionate about and then how what they're passionate about can contribute to the organizational purpose, which might mean changing their role, right? It's like sticky icky and people don't want to touch it.
Brian (12:08)
Yeah. Yeah. I mean, it's like, uh, you know, if you were in a professional athlete of some kind and you played whatever game your sport, you know, has, and you just went from game to game to game and never stopped in between to watch the game film or analyze your, your, you know, uh, swing or, you know, right. You got to have that, those moments to stop and be critical, uh, so that you can then say, all right, well, this didn't work as well as we should have, but. Let's try something new. Let's try a different way of approaching.
Leor Herzfeld (12:41)
Right. So this is what we came up with. I've got, you know, I'm curious to hear if anyone has any feedback, but so far these have felt, they've gotten pretty good feedback. So we came up with 14 dimensions of individual health that we feel need to be addressed in one way or another. So I've got safety. I love Daniel Pink. So we've got autonomy, mastery and purpose. Personal growth, right?
Brian (13:08)
Yep, I'm with you.
Leor Herzfeld (13:11)
Person needs to feel like they're learning something or they're gonna get bored. Career growth, if there's no path for them to grow in their career, then they're gonna look for work elsewhere. Diversity, equity, inclusion, belonging, right, very important. Play. Things don't have to be so damn serious all the time. We can have a little bit of fun at work, people. It's not dangerous. You need healthy relationships with your coworkers. Accountability.
Brian (13:31)
Ha ha ha.
Leor Herzfeld (13:41)
Um, and accountability is something that, that is not intrinsic to a lot of people. It's something that often needs to be taught and it's about showing up with integrity. Um, doing what you say you're going to do by when you're saying, by when you say you're going to do it, you know, being your word. And a lot of that comes from, and this is one of the reasons why I love scrum is it creates that accountability to the sprint goal. Hopefully in a way that is, you know, inspirational and not, um, command and control, um, mentoring. People need mentors. Achievement. This is another area where I feel modern Agile for very good reasons is missing something. So we look at performance at the team level. Absolutely makes sense. Let's not look at performance at the individual level. This can create an anti -pattern where we're now saying, well, you're better than you and that's not what this, but there needs to be some kind of an empirical feedback mechanism for an individual. understand how they're improving and that's not something I've seen thus far. Physical health, so there's your 40 hours a week and perhaps some other things and finally mental.
Brian (14:43)
Yeah. Yeah. Those are good. Yeah, I'm just trying to think through. And I don't think I can't, off the top of my head, I can't think of something I would add to that list. That's a really good list.
Leor Herzfeld (15:06)
I'm sure it'll grow. So the talk that I gave only had 12, so we've added two. So I'm sure it'll continue to grow. But like everything else, you know, perfect is the enemy of good. So, you know, what we've created here is, so we've got the list of 14 items, and then we've got this kind of shoe -hawry journey of, you know, are you even on the journey? So there's actually...
Brian (15:11)
Hahaha.
Leor Herzfeld (15:31)
tool for this on the Integral Agile website where you could go in and there's four questions for each one and if you answer at the first one, it's something like, let's take autonomy for example, the first one might say, I'm told what to do all the time. And then there's a journey from there. So it's not like you have safety or you don't have safety, you can have a little bit of safety, have a little bit of autonomy. So we created this beginner master, beginner practitioner master journey. And we've tried to set master it, you know, the objective is to get to the practitioner portion of it. We've tried to set master as like a really unattainable thing at work. Just to, you know, and if anyone gets there, it's amazing. But just to indicate that like our objective is to be practicing these things. We want general health, not expertise in every dimension.
Brian (16:11)
Ha ha. So is it kind of a, do you take kind of a survey approach with an organization that you have everyone in the organization kind of rate this and then get an overall score or how do you measure it?
Leor Herzfeld (16:32)
Yeah, yeah, that's a great question. So where I propose this for various different enterprises. You start, so this is applicable anywhere, right? This is applicable to leaders. This is not just applicable to team members. Leaders are feeling all of these things and oftentimes in more dire ways than team members might be. But if we were gonna deploy this across the organization to get a pulse on what's actually happening, we would do this on a team by team basis. So from an individual perspective, the results will be all over the place. Every team's answers are going to have some patterns. that align based on the team's individual culture. Then if we go to the team of teams area, again, so we're gonna see things, a little bit of difference, because different teams, one team might have a stronger scrum master, and therefore their culture is a little, they might feel more psychological safety or more autonomy. So that'll let you know, right? This gives you like a real big indicator of how agile you are, because agile teams will tend to score a little bit higher on some of these. on some of these results. Anything that's happening at the team of teams level that's consistent is telling you that you've got a systemic problem in that team of teams level. And then of course, you raise it from there to the organization or to the enterprise. So the hope is where you see in an organization something lacking, these are not terribly difficult things to remediate and the remediations for them may or may not be agile.
Brian (18:06)
Yeah, yeah, that's a great point. Yeah, I'm just, I'm fascinated by this concept and, and, and I, I like how you broke it down on different levels because you're absolutely right. I'm just sitting here trying to process it through as you're talking through it. And yeah, I can think of scenarios I've been in where we felt like the team has been great or we have a certain level of, like you said, safety or something within a team. But then we feel sort of like the organization is not listening to us or the organization has a different set of values. cultural values than the team does. That is something that I encounter quite a lot in classes too. I hear a lot of people who will say that, that our team is doing all that we can, but we feel like our organization is in a different place culturally and how do we make an impact there? How do we change that? So how would you handle that? What would you say to the teams like that, that feel like we're doing pretty well on our team, but our culture and our organization is just not. kind of in alignment with where we are.
Leor Herzfeld (19:13)
Yeah, so the trick with culture is it's very difficult to see. So this is another tool that we came up with something we call the Integral Cultural Map. So in any organization, in any given area in an organization, there's going to be one of three dominant cultures. There's going to be a risk averse, you know, rules and roles kind of a culture. Right. So that culture is going to be, you know, rife with red tape. making sure that we do things the right way. There's a process for the process for the process. And then the next kind of culture that we see is achievement oriented. This culture is gonna be very exciting. There's gonna be a lot of innovation going on. We're gonna be like results, results, results, bottom line. But the pitfall, so let me go back. Let me make sure that I talk about the healthy and unhealthy versions of these cultures. So the healthy element to the risk averse culture is obviously, you know,
Brian (19:46)
Right.
Leor Herzfeld (20:10)
we're gonna be very safe, lowercase s. So you're not gonna get a lot of dings by compliance in an environment like that. However, the rate of progress is probably gonna be pretty slow. And achieving oriented culture, very exciting, lots of great innovation, but the dark side to that might be very individualistic in terms of, you could have political infighting, you could have leaders,
Brian (20:14)
Yeah.
Leor Herzfeld (20:40)
not wanting to relinquish their own little fiefdom if it means, you know, if it's indicated that it makes sense from like some value stream mapping diagram, it makes sense to kind of break things up and create cross -functional teams. They'll say, no, no, no, I want to hold onto my teams. You know, so you'll get that as one of the dark sides of the achievement -oriented culture. And then you get what Agilists love is the people -centric culture. And that culture is going to be very much about ensuring that we have... health and morale. But the pitfall of that culture is it abandons achievement. So, you know, you might have people coming out of a meeting where everyone feels great about the conversation that took place, but nothing was actually accomplished. So there's a fourth level to this. And this is, I'm kind of like talking about something that's inside of integral theory. This is the levels portion of integral theory, if people are familiar. Then there's an integration of all three. And one of the things we try to espouse is, you need control, you need achievement, and you need morale. You have to have all three, but you don't necessarily have to have all three in every area of your enterprise. So if you have an objective that says, I want to make 10 million more dollars, but the culture of the area that is in control of achieving that objective is either we care about our people's morale or we care about making sure that nothing breaks, you're unlikely to meet that objective. So a different tool that we have that reveals these invisible cultural value schemes. And of course, the thing that creates the culture in any area of the enterprise is its immediate leader, which is why you'll see the enterprise itself might have, you know, let's say an achievement oriented culture, but then a particular organization might be very people oriented and another organization might be very, you know, rule, role, risk averse.
Brian (22:36)
Yeah. That's fascinating. Yeah, I mean, I see exactly what you mean. And I see how those things kind of interact with each other. So tell us a little bit about, because I know you have this book that's going to be coming out. And you described it really before we got on about how it's sort of your theory there at Integral Agile. So re -imagine transformation. What are you trying to capture? with this forthcoming book.
Leor Herzfeld (23:09)
So it's really taking this thing that we've worked on for the last five years, this integral Agile approach, and breaking it down into a series of tools that people can use. Again, Agile's been very good to me, and I like it very much. I think that it's a little bit sick right now. We've seen there's been like Capital One just declared, hey, we're good, let's get rid of our coaches and scrum masters. And... I, the shine is definitely, I don't want to go so far as to say it's become a dirty word because it hasn't, um, and the industry is still growing, but the, the luster has gone off it. And that's because it's failing to the deliver the results it promises. So after people have been through a transformation two, three, four times, I've dealt with this myself, right? I'm, I'm coming to a team and they've had, you know, three coaches before and they're like, well, it hasn't worked before. Why is it going to work with you? Um, and it's almost like, I used to joke, you know, it's like, um, bad, you know, significant other syndrome. Like the person, like you're dating someone and their last three significant others, you know, treated them like garbage and they're like, they've got that trauma built up. Um, so we're just trying to help everybody with this book. The reasons why agile fails when it fails is because it's only addressing half the problem. It's addressing what you can see. Um, so what we wanted to add into it is how do we take the elements that we can't see and how do we add them back in? not from a, this is an important thing, let's do this perspective, but literally in every single element of everything you do, how do you add it in if you're giving a one -to -one? How do you add it in during sprint planning or during backlog refinement? When you're thinking about OKRs, how can we think about it from these internal and external perspectives? And the thing that we've been challenged by, that we feel pretty good about now, but it took us a really long time to get here, is how can we describe these internal processes that quite frankly many business people have no appetite for whatsoever. How can we put it in a way where they will want to give it the attention it deserves? Because if it's not given the attention it deserves, these invisible blocks, whether they're cultural elements or values mismatches or, you know. people just hate their job, right? People are not aligned with purpose. How can we do this in a way that's visible, that's simple, and that people will actually want to buy? So that's the objective of...
Brian (25:47)
I think that's an awesome take because I know one of the things that we try to do in our classes and one of the things I hear from people who come through classes a lot is just, you know, there's a lot of discussion in sort of a lofty, high ideals, wouldn't this be great if things worked in this way? But, you know, a lot of times people don't really understand, all right, well, that's the way it should be in totality. But here's what I'm dealing with on a day -to -day basis. I've got OKRs. I've got all the stuff that I've got to do. How does that change what I do on a day -to -day basis? So I think that's really wonderful. I think that's a really needed aspect of that is, you know, kind of in the practicality, how does this play out on, you know, just what we typically do on a regular basis as a business.
Leor Herzfeld (26:38)
Yeah. I mean, if it's not practical, who cares? You know, I'm a giant nerd. I love getting into theorizing and thinking about all of these things at the end of all of that conversation. If I can't say, try this, here's the way to try it. If I can't explain a concept to you in 15 minutes in a way that you can use it, I failed.
Brian (26:41)
Right. Yeah. Yeah, I'm right there with you. Well, this is fascinating stuff. And we're going to put a lot of links in our show notes for this episode so that you can get in touch with Leor if you want to find out some more about this or maybe find out about the book that's coming out. Maybe get on a list to be able to buy that once it's available. Also, so you can get in touch with this company at Integral Agile. But this is fascinating stuff. I really appreciate Leor, you taking the time to come on and help us understand this a little bit.
Leor Herzfeld (27:36)
Yeah, I appreciate the opportunity to speak with you. And I'll also note that on our site, the majority of these elements are just right there. So a lot of the stuff, the models, the diagrams, how you can actually do these things, we wanted to give that away. So we're just looking to, in a general sense, well, now we're looking to bring Agile back from the brink. I mean, I hope it's not the brink, but we want this to work. And the reason why my company exists,
Brian (28:00)
Ha ha. Leor Herzfeld (28:06) is we want to make people's lives better. Our objective is to make people's lives better at work. The first time I ever worked with a Scrum team, the difference in the way they showed up at work, the way they spoke to each other, it was night and day. They're laughing, they're happy. And I think about it, a colleague of mine once said, I'm tired of doing this agile thing. I don't need to help whatever bank make an extra $5 million. And I'm like, dude, that's not what we're doing. I mean, sure, it's a knock -on effect of what we're doing, but every life that we touch where that person feels lighter, feels more able to express themselves, we spend the majority of our times at work. And if that time is misery, then you go home drained, dejected, and you bring that energy with you to your friends, to your family, to your children. If that time is something that, you know, okay, joyful, could be, I like to think so, but even just not painful, it has an effect. So that's what inspires me and that's why we're here.
Brian (29:15)
That's awesome. I'm right there with you. Completely agree. It is important. It is important how you show up and what you do at work. It's kind of one of the things I say to people sometimes is both things can be true at the same time. It's fine. Yes, we do help from a business perspective. We're helping people be more efficient with their business and get more from less. And... really achieve higher levels of success. But at the same time, we're also helping people to have more fun at work and to enjoy their time at work, not be miserable with their time at work.
Leor Herzfeld (29:54)
Yeah. Yeah. And that's, I mean, I, you know, that's a good point you're bringing up. I know we're just about out of time, but I, you know, I don't want the message to get lost that this is like some touchy feely kind of a thing. Um, this is the way, if you want that 300 % boost in throughput, you need this to get there. You're not going to do it by throwing new process at the situation.
Brian (30:17)
And I'm geeky enough to just have to repeat that phrase again. This is the way. All right. Well, thanks again, Leor. I appreciate you coming on. And we'll make sure people can get in touch with you.
Leor Herzfeld (30:22)
I love it. Awesome, thank you, Brian.

#100: Navigating the Future of Agile and Scrum with Lance Dacy & Scott Dunn

Join Brian for the 100th episode of the Agile Mentors Podcast as he dives into the future of Agile with fan favorites Scott Dunn and Lance Dacy. Listen in as they explore the evolving role of AI, the continuous need for leadership innovation, and the Agile community's journey towards greater accountability and effectiveness.
Overview
In the 100th episode, our expert panel celebrates by examining the latest trends and enduring challenges in the Agile industry.
They discuss the critical need for organizations to adapt and innovate, particularly through leadership and management strategies that foster high-performing teams.
This episode is a deep dive into how embracing change and technological advancement can propel the Agile industry forward, ensuring that organizations not only survive but thrive in an ever-evolving business landscape.
Listen Now to Discover:
[1:10] - Join Brian in a special celebration of the 100th episode of the Agile Mentors Podcast, featuring a look forward to future innovations in Agile!
[1:43] - Brian kicks off the landmark 100th episode with a forward-looking panel on Agile and Scrum's future, featuring experts Scott Dunn and Lance Dacy.
[4:01] - Listen in as Brian asks the panel to share their insights on emerging trends within Agile and Scrum, setting the stage for a thought-provoking conversation.
[4:15] - Lance highlights key trends including solutions for scaling challenges, the integration of AI in Scrum, and innovations in leadership and management.
[6:54] - Scott emphasizes the enduring impact of Agile and Scrum in driving organizational enhancements.
[11:36] - Lance underscores the critical need for leadership and management to adopt innovative approaches and acknowledge generational changes to effectively engage and support their teams.
[13:30] - Addressing the provocative statement that 'Agile is dead,' Brian explores its implications on the real-world demand for Agile compared to its perceived necessity.
[14:50] - Brian, along with Scott and Lance, urges the Agile community to recognize its shortcomings and learning experiences, which they believe may be contributing to negative perceptions of Agile, and how the community could approach it differently.
[24:10] - Brian encourages you to try out Goat Bot, Mountain Goat software’s Scrum & Agile AI tool. This free tool is trained to handle all your Agile and Scrum queries—start asking your questions today!
[25:58] - The panel explores the impact of AI on enhancing agility in organizational practices in estimating, development, and so much more.
[32:20] - Brian stresses the importance of using AI as a tool to support, not supplant, discussing ways it can improve rather than replace human efforts.
[43:23] - Brian shares a big thank you to Scott and Lance for joining him on the 100th episode of the show.
[43:44] - Brian thanks you, the listeners, for your support and shares his excitement for the future of the show, inviting you to send us your feedback or share your great ideas for episodes of the show. Just send us an email.
[44:57] - We invite you to like and subscribe to the Agile Mentors Podcast.
[45:16] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, such as CSM, or CSPO, or Better User Stories Course. We also have Advanced Certified ScrumMaster® and Advanced Certified Scrum Product Owner®, where we get right into the good stuff and have some deep discussions. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here.
References and resources mentioned in the show:
Scott Dunn
Lance Dacy
Goat Bot
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mike Cohn’s Better User Stories Course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
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.
Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum.
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)
Agile Mentors, welcome. This is our 100th episode. Can you believe it? We've been doing this for 100 episodes now. So first, before we even get into today's episode, I just wanna say huge, huge thank you to you. Thank you for listening. Thank you for giving us feedback. Thank you for giving us suggestions. We would not have made it to 100 without you, so. Huge thanks to you. And to celebrate, we're trying to do something different here for the 100th and not just let it go by and not mark this occasion. So what I wanted to do was to have some of our regulars, our favorites on together so that we could really kind of look ahead. So let me introduce our panel for today. First of all, I've got Mr. Scott done with us. So Scott, welcome.
Scott Dunn (01:00)
Thank you, Brian. Glad to be here. This is awesome. Congratulations. That's so cool.
Brian (01:04)
That, thank you, thank you, thank you very much. And then another favorite that we have on quite frequently is Lance Dacey is with us as well.
Lance Dacy (01:13)
Hey Brian, congratulations once again. I remember us just talking about this when you were starting out with podcasts and you look at 100. You do this every week, right? Is it a, has it been a hundred weeks? Wow.
Brian (01:22)
Yeah. Yeah, we do this every week. We missed a couple. Our listeners probably know there's been a couple of times in there we've taken some small breaks around holidays and other things. But yeah, this is going on just about every week since then.
Lance Dacy (01:38)
Well, congratulations. That's amazing.
Brian (01:40)
Thank you, thank you. Yeah, I'm amazed and as I said, very, very grateful. And it really hit home to me when I went to my first conference after doing this and people would come up and say, hey, I listen. That was really a cool moment. And I always tell people, hey, I'm speaking to other conferences, come and say hi. Come and say hi to me this year. So as I said, I wanted to have a panel so that we could talk about, we've been...
Scott Dunn (01:40)
Amazing.
Brian (02:10)
doing this for 100 episodes and lots has changed, lots have changed over the past year and a half, almost two years now that we've been doing this. We kicked off on, I think it was May 18th, 2022. So we're coming up on two years of doing this. And my thought was, what's gonna happen over the next 100 episodes? Like, where are we gonna be in the next two years? Where are we gonna be in the next five years? What kind of things are changing? What are we going to think about stuff over that time period? So I wanted to have a panel to kind of comment and discuss this with us and Where I wanted to start is maybe not where I think most people are going to think I'm going to go But I want to start with kind of the agile industry kind of the way things are going now for Coaches consultants scrum masters product owners So I'm gonna throw this as an open question and whichever of you wants to go first, go first. But what do you think we're seeing right now? What kind of trends are you seeing in that realm? And where do you think it's gonna, where do you think it's going?
Scott Dunn (03:26)
I nominate Lance to go first.
Lance Dacy (03:28)
Okay, here, obviously they're thinking about Scott. It looks like he's got something to say. Okay, well, that's a tough question because I think it still depends on the industry and the organization. It's all made up of people still. So there's still a lot of variables, I think, that affect the way that we do our jobs as transition coaches or business agility coaches or agile coaches, whatever you wanna call us. I think...
Brian (03:29)
Hahaha
Lance Dacy (03:59)
You know, I think there's still plenty of organizations out there that are struggling to bring their people together to deliver great products. And it's not because they don't want to, it's just lacking the skills and the frameworks and things to do that. So I still think that there's some organizations out there that benefit from saying, hey, let's just start from what we know and start doing this and then adapt to it as it changes. But I think a lot of times organizations, I think scaling is one of those big. problem child out there that people have kind of learned how to do this with smaller teams and smaller parts of the organization, but getting the whole organization to collaborate together. And of course, they look to another framework for that. And I'm kind of framework agnostic, especially when it comes to scaling, because I think at the end of the day, if you can't do it well in the small environment, it's going to be very difficult to do it well in the large environment. So the best thing you can do is kind of analyze your own situation. with like value stream mappings and cross-functional teams and things like that, and try to make sure that you're organizing yourselves and preventing waste as much as possible, I think is one of the big things. But I've also seen a kind of an uptick in, of course, these practices in agile being distributed over non-software domains. We've seen that for a long time, that's not necessarily a new thing, but I think it's gravitating more. to that. But I think the biggest one is really what we're talking about today is how is this AI stuff or what we have been talking about, how is that affecting this? And I think it's here quicker than we really think, or already here. And so trying to figure out how to handle, you know, data driven decision making based on that and, you know, using these tools to integrate. And then I think the last one that I would talk about is leadership and management. I think There's a specific type of environment and culture required for these people to thrive and collaborate and leadership and management has not seen a lot of innovation in the last 150 years. So, I find myself spending a lot of time coaching executives and mid-level managers on how to foster an environment that we can know how we practice psychological safety, empowering people and making it a great place to work, especially in this remote distributed environment. So I don't know if it's... All that's fairly new, but I think it's more prevalent than it was in the past. So I don't know, Scott, go ahead.
Scott Dunn (06:28)
No, that's good stuff. And I've only got 35 points I want to walk through. So one, I think we had all agreed that this idea of agile seems to be the common experience we're seeing as we're still coaching out there in organizations. They think that they've already done that. That's in the past. What's next? Or they settled in like, we're just hybrid. And it's not a. So help us move forward. It's like, no, we weren't done that. Here's this other thing. But the other things they're needing. And I like it, Lance. You kind of mentioned a couple of other words that people use, like organizational improvement, organizational chiasm, these ideas, like, hey, we're trying to get better. And I almost rather use those words because if I use a word they think they know, then we've kind of lost the fact that, you know, we're there. It strikes me, it's a little bit like marketing. They're just like, nope, marketing's done. And now we're doing this. And like, no, marketing's always learning, moving forward, growing. And I think we're gonna see this idea they realize, like, oh. Agile wasn't like a destination we check the boxes now they're on Scrum team. So that's one thing we're continuing to see. And the reason I'm saying that is the problems are still the same problems. We're talking earlier about capacity management, visibility, clear, you know, can execs see where we are in these larger initiatives? And the answer is like, no, they're still not doing those well. That speaks to whole org. And two quick stories on that is one, we're working with a company that decided like, yes, we're going to take this whole org approach.
Lance Dacy (07:27)
Yeah.
Scott Dunn (07:45)
And once they, within a few months, they'd gone from cycle time of 100 days down to 10. They had tripled their productivity. They went from one release every two weeks to seven in a day, right? But that's because the whole org is represented as they're rolling out, actually holistically. Let's contract that with a company we're just talking to this week. I was trying to describe getting a group together, it's representatives across other departments who have people who have authority, who have influence, finances, et cetera. they could not grasp the idea that there'd be a team working on improvement items across the org. It took several explanations, like I'm not talking at the team level. I'm talking about the team that's working across the org level. And what part of this comes back to is I think of the idea of I'm a manager. This is my own like awakening recently. If I'm a manager, let's say I'm the software engineering manager, I'm the director, my concern, this is my mistake earlier, my concern is not, are we doing ads all right? My concern is, is my boss getting what they want? If my boss wants clear reporting on where we're at the features, I don't care if it's Agile, waterfall hybrid doesn't matter. Did you show me a nice pretty report that gives them what they need? That's what I, that's what I do not wanna be called into her office on Friday about, right? So I keep mistaken, like they wanna do Agile, right? No, they wanna check the box and what they're accountable for and meet those expectations. And I know the higher up the or we go, the less they probably understand about Agile. At least that's the surveys that I'm running is like a... a 20, 30, 50% gap between what these people say their managers think they understand about Agile and what the people actually do in the work know that they understand Agile or not, which is always a large gap. A good example of that is remote. I'm not trying to kick a dead horse when it's down or whatever the saying is, but we've talked about remote a lot, but here's what we're seeing is, I think the basis of a lot of this return to office is simply, I don't know my people are working or not, I just need to see them.
Brian (09:30)
Hahaha.
Scott Dunn (09:41)
I can't tell, and I can't see them, I can't tell, and I get nervous, which really means I don't really have an understanding of fundamental aspects of how work is done using transparency, inspect and adapt, all that, right? And because I can't really, I don't really have mastery over that, I'm gonna need you in the office at least three times a week. Because I don't, I'm not really watching the work anyways, but at least I know you're showing up, and I'm accountable to make sure people are busy and working. That's, you know, I draw it down to its most rudimentary level. To me, it's a reflection of the capability of management. You mentioned that, Lance, about leadership. I think we're starting to see
Lance Dacy (09:41)
Right.
Brian (09:52)
Yeah.
Scott Dunn (10:11)
What we probably will see is this real cutting line of those who get it and trust their people and they work. And we've seen, you know, 10X, 100X on, on experts really let loose to do their best work and those who are simply like, you know, managed in that traditional sense and all the drawbacks and your loss of talent, all that. I think the companies will have to pay the price eventually. Thinking back to the time when people didn't really want to go ad drug because they thought it was a fad. And it didn't take but a few years, like, um, I could be wrong.
Brian (10:35)
Yep.
Scott Dunn (10:38)
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 gonna see that with remote work is made like the proving ground of do you really work this way or not as a manager? Do you get this or not? So those are some of the trends I see. I still see a lot of people still in the very fundamentals because they think these things are already understood and known and we're moving on to something next. There is no next. I think the pace of change out there is if you're not working this way as an organization, you're losing ground already. Like... while they're listening to the podcast.
Lance Dacy (11:08)
It's like the remote, you know, what you were just saying is like the remote is the automated test for your operating system at work is like, if it works like that, then we're likely doing some really good things. But you know, I remember, um, I'm going to show my age here though, but prior to my technology career, I worked at FedEx and I was in leadership and management, managing their third largest hub here in Fort Worth, Texas, uh, the air hub, you know, and FedEx did a great job teaching leadership and management and all that kind of stuff.
Brian (11:08)
Yeah.
Scott Dunn (11:14)
Thank you.
Lance Dacy (11:36)
And I remember them focusing on the idea that 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. They work radically different. You know, I'm going to categorize money as a gen X person. And I'm going to say we were taught to be very individualistic, climb the corporate ladder, you know, keep your pain to yourself, just grin and bear it, fight through it, do the best you can and be autonomous and don't rely on a lot of people. And, you know, don't trust anybody. You know, the latchkey kids, we just were independent. We learned how to do it all. And that's not necessarily bad. We needed to be managed a different way than these people now. I, and I've got four kids, so I see it. It's like, they're not going to tolerate this stuff. So you hit it on the head with that leadership. I mean, coverage, a broad spectrum, but, um, Mike gave a talk in Oh nine. I'll never forget this. When I first went to the scrum gathering in Orlando and Oh nine, and he was on a panel and he said it really succinctly. He said, I hope we don't call it agile or scrum anymore. It's just the way that we work.
Brian (12:36)
Yeah.
Lance Dacy (12:54)
And he was referencing object oriented programming. You know, he said, we don't call it object oriented programming anymore, it's just programming, you know, object one. And so it's like, yeah, we're not going to, let's not have this debate. We want to build the highest business value things as early as possible with the least amount of costs who can argue that that's not the right way to run an organization. So let's not debate it. Let's not use the buzzwords. Let's just do it.
Brian (13:01)
Right.
Scott Dunn (13:12)
Yes.
Brian (13:18)
Yeah, I agree. And it's, you know, kind of back to what Scott said, too, there is a marketing issue here, right? There is this kind of idea of people are so saturated with the terms that they've experienced them and they feel like, hey, I know that I know what that is, I don't need to be I don't need to learn any more about that. And now I'm just kind of moving forward when they don't really. And that's what drives all the people out there that are saying Agile is dead and all the Agile is dead speakers and all that stuff. It's not dead. And if you listen to them, they don't say it's dead. They just say, people don't understand what it is. And so they're doing it wrong. I think there's kind of this interesting dynamic going on. Right, because on one hand, I think we're at a time when
Scott Dunn (13:54)
Mm-hmm.
Brian (14:03)
businesses could benefit the most from doing things like Agile because they're gonna get the most with less by doing these kinds of approaches. However, at the same time, we're hearing stories of entire Agile departments being let go in different organizations. And we're seeing people who struggle after coming through classes and stuff finding work as a scrum master, even though there's a demand. There's high demand still for these kinds of things. So there's sort of this dichotomy that's going on of, I think there's a slump going on in the agile demand when the need for it is high. And maybe that's a marketing, right. Maybe that's a marketing thing that we haven't done a good job, but I wanna propose one other thing here and I wanna get your guys take on this.
Lance Dacy (14:51)
than ever.
Brian (15:02)
The people who say Agile is dead and they say that, we shouldn't be doing this because we should call it something else. Because no one understands what it is anymore. And that's why they say it's dead. I have generally thought of those, and I think many of us sometimes fault the leadership a little bit in this to say, they didn't invest enough to understand it. They didn't really support it, right? Kind of that mentality. But I think that as an Agile community, that we need to own up. Like, I think we just need to step forward and say, you know what, we have not always done it right. And there's been plenty, you know, I talked about this in the Scrum Master class. There's plenty of Scrum Masters out there who think that the job of being a Scrum Master is to schedule meetings. And that is it. And...
Scott Dunn (15:55)
Oh.
Brian (15:58)
You know, those people, you can understand why a company would say, I don't need that person. I don't need a person to do that. And then all of a sudden they're letting go all of their Scrum Masters because they think that's what a Scrum Master is. So I think we have to own up a little bit to say, we're partly responsible for this, right? We're partly responsible for the bad impression that Agile has and we just gotta own it and say, yes, that's true, but that's because we've made mistakes as well and we're learning.
Lance Dacy (16:17)
Thank you.
Brian (16:28)
And now we know better, right? Now we know what we're supposed to do. But the pretense that we maybe came into it with, saying, hey, we know everything and we know how to do this stuff, was what caused the downfall, I think. What do you think?
Scott Dunn (16:32)
Hmm.
Lance Dacy (16:44)
It's like the overlay though of saying here, here's how you do it, right? I think what we got wrong or not necessarily wrong, just we didn't know any better at the time is, I've worked with 20 companies and this way work, let's try it. And then if it doesn't work, we'll adapt it. Cause I think it's always been about that. But you know, just like any approach, you know, the effectiveness of that approach depends a lot on how it's implemented, supported, adapted, taught. And I feel like what we should just start focusing on, you know, it's hard to put this in one term, Maybe it's just like helping and facilitating the creation of high performing teams. Like that's an unarguable thing that you would want to have. What's happening is the organizations either whether they misunderstand the role or have a bad experience in the past with it because you can't say their experience is invalid, right? Everybody has their different experience and opinion and what they went through. And I acknowledge that. But if you think of any professional sports teams, what's happening in the organizations in this world?
Brian (17:20)
Yeah.
Lance Dacy (17:43)
is they're getting rid of the coach of the team. And what we have to do is start recognizing what does the coach really do is trying to make the team high performing. You know, in professional sports, it's to score points and win the game, right? Well, kind of trying to do the same thing here, you would never get rid of the coaching position saying, well, all they do is watch film and tell the team what they're doing wrong. No, I mean, Andy Reid, you know, the Kansas City Chiefs, they won the Super Bowl, arguably the best football team in the world, if that's what you're using as a bar. And...
Scott Dunn (17:46)
Thank you.
Brian (17:55)
No.
Scott Dunn (18:03)
Thank you.
Lance Dacy (18:12)
And so they've arrived, they're the best. Do we get rid of Andy Reid? No, they need him even more because they get complacent and they get this idea that we don't need to change anything. And I see plenty of teams like that. It's like, no, the coach has one of the hardest jobs in the world is to tell the best performing team in the world they can get better. And the organization sometimes is the wet blanket and suffocating the environment for which that team can perform.
Scott Dunn (18:16)
Thank you.
Lance Dacy (18:37)
And I feel like, you know, instead of whether you want to call it a scrum master and agile codes or whatever, it's almost hard to use those terms. Some of these people anymore, because they'll just sit there and argue with you about it, but let's just say I'm trying to coach a high performing team and how can you argue with that, you know?
Brian (18:50)
Yeah. Yeah, I don't think you can. Scott, what do you think?
Scott Dunn (18:53)
If I was to ask you, well, if I was to ask both of you, do traditional management, whoever's making hiring decisions, do they know what an agile coach is and what's in telling them that they're doing well or not? And I would argue the most don't. And I think that's why we see a lot of people, I mean, in the end, people follow the money. I don't call people for work and their own self-interest. So if I can just update my LinkedIn profile and change it to agile coach. and whoever interviews me can't tell a difference. And that means I get a salary bump and of course, or let's just tell it like it is. And I think your listeners, I know you to be good with this. If I can just take a two day class and I'm gonna get a 25% salary increase, whether or not I get it or not, let's not even go there. Like I passed the test, I've got the certification. And unfortunately, I think that's more the dynamics of any given market is like, oh, it jumps to the solution, right? I just, you know. hire these scrum masters and I've done the agile thing. And even though any of us would say like, that's much bigger than that, this agile coaching involved is much more than the two day class that you need, et cetera. But think about that. I'd look at the people that I've trained, which, you know, is thousands. How many companies actually came back and said, we need help as an agile coach? 20, 22 dozen, right? That we actually went in and did real transformation work. So that's them not asking. That's them like, no, we got it. I think that simplicity of understanding Do I take a solution or do I go through a mindset change? Well, taking the solutions is going to be easier. So I'm going to jump to that rather than like reflect, like, I think we need to change. Change is hard, we agree. So back to the point of like, are we to blame? I see some of that market dynamics, but we do that with diets. We do that with the career. Also Greg, we wouldn't just grab something easier than actually go through the change. So I do agree with you, but I think it's a good point. How we try to re-message that when the world already thinks I understand it. I think we're watching this happen. When I look at companies in that space,
Brian (20:30)
Yep.
Scott Dunn (20:42)
They are using different terms and phrases. I think that moves us away from, maybe that's an aspect of like, where to blame. The other interesting thing, Lance, you mentioned about the coach and we don't fire the coach. And I think that's the best example I go to is, look, I'm a business owner of a professional sports team. I'm watching the dollars and I don't wanna have to pay Andy Reid millions, but I know it gets results. And I don't wanna coach for the offensive line. I don't wanna coach for defensive, but the results are clear whether that works or not.
Brian (21:03)
Yeah.
Scott Dunn (21:08)
The other thing that's interesting is you watch some of these coaches, like when it changed in college football with name engine, name engine and likeness in terms of attracting students for different reasons. Like I can make money during college. I don't have to hope I make the pros. And how that changed the game significantly to where some coaches like, forget it. I don't want to play this game where they're now empowered to make their own decisions on where they want to go and not just sit on the bench. If I want to sit on the bench, the transfer portal. So you're watching dynamics play out on what does that mean to bring that change in? I do think in the end, there's probably a simple split on, there's an organization that needs to continuously improve and look for ways to do that. Not as one-off projects of, hey, let's do an improvement project here. But as a feeder backlog, but simply there's always ways to improve and stuff's always coming in and we're always working that as a layer of the way the organization runs. When I see a chief agility officer, some of these other roles, I think they get it. I think manufacturing systems get that with like lean thinking and like, That's just what we do. We're always looking for that. I don't think software engineering. And this organization get it. And to be honest, my friends, you can tell me if I'm off. I don't know if they got sold that truth of this is always going. It is not put all your engineers on the teams, hire a scrum master, change someone's title of product owner and you're good, right? But I think that's what they kind of thought it was. And then they're done, but that's a team level. It's not organization level and it just sits there. So I guess there is someone with the blame because maybe that's what they were taught and not the bigger picture as well.
Brian (22:25)
Yeah. Yeah.
Scott Dunn (22:35)
Perhaps.
Lance Dacy (22:36)
The rebranding is interesting the way you said that. I don't, you know, let's call it something other than Agilent or Scrum, whatever you were talking about. And that's what organizations do when things are broken, is they reorg. We're gonna just change the name of it. It's like following a diet plan and going, well, I don't like that it doesn't let me have sugar, so I'm just gonna call it something different. The constraint.
Brian (22:48)
Hmm. Yep, you're right.
Scott Dunn (22:50)
Yes, yes
Lance Dacy (23:02)
You know, the constraint is there to make you better. And I think that's what a lot of people don't get about, let's say the Scrum framework has a lot of constraints built in not to make it harder to do your work. And I will argue it's harder. Like I tell people all the time, this is a harder way to work. It's not an easier way because it requires all of us to come together. But you just said it so eloquently, Scott, I just thought about that, that they just, who cares what we call it.
Brian (23:03)
Yeah.
Scott Dunn (23:16)
Yes, for sure.
Lance Dacy
(23:26) the organization and the leadership is stuck by saying that at their level, all they gotta do is call it something different and now it's solved. All I gotta do is change the org chart on a spreadsheet. And I can't tell you how many organizations I work with where I'll get a note and say, well, we're going through a reorg right now, so we gotta hold off on this training or do this or do that. It's like, well, you just went through one, I've worked with companies that have been their coach for a very long time. It's like, how many of these are we gonna go through? What's the purpose? When are we going to start realizing that it's not who reports to who, it's who's doing the work and what's the environment and culture we've created for them. And I feel like leadership and management, I don't even care if it's software. Like Scott, you're saying software, we really don't get it. I'm not sure any company really, there's a few out there that I would say their leadership and management's working really well, but the operating system for the culture is broken. And, you know, we know that for a long time as agile coaches, but it's like, there's some benefits to be gained even while that's happening.
Brian (23:54)
Yeah.
Lance Dacy (24:24)
that we can get some efficiencies going here and they're still better off. But we've hit that next level, the problems are more complex now. People and it's leadership and it's hard to change those because they've been doing it for 150 years this way. You know?
Scott Dunn (24:34)
Yes.
Brian (24:34)
Yeah.
Scott Dunn (24:40)
Yes. Yeah.
Brian (24:41)
Yeah. Well, we can't leave the episode without talking about AI, at least a little bit, because I know you brought that up already. But yeah, we definitely need to think about AI in the future. And yeah, yeah. Because I know we talked about that a little bit when we were meeting here before we started to record. But just curious.
Scott Dunn (24:46)
Hahaha!
Lance Dacy (24:52)
leaders and managers.
Scott Dunn (24:54)
Yes.
Brian (25:06)
Where do you think that whole thing is going? What I should say is, how do you think it's going to affect agility? That's the big question.
Lance Dacy (25:17)
You want me to go again first, Scott, or is he going to flip flop?
Scott Dunn (25:20)
No, no, we're not flip-flopping. It's you, man. You got it. I'm not changing.
Brian (25:23)
Hahaha
Lance Dacy (25:23)
Okay. He has some reason to do this. You know, I feel like I'm walking into a trap here. Um, the way he's going to trap me. Um, well, and you know, we were kind of talking before we even, you know, started the podcast, but I was mentioning, you know, project management wise, you know, that I believe AI can bring a lot to just helping teams become more efficient and productive just at a superficial level by simply
Scott Dunn (25:28)
With pretty...
Brian (25:29)
No, that's a wrong answer, Lance.
Lance Dacy (25:50)
if we're talking about Scrum, let's say, because a lot of us practice Scrum and we teach it, you think about a sprint planning exercise and how often it's very difficult to just simply explain how to come up with your capacity for the next two weeks, and based on your skillset and the work needing to be done, are we sure and confident that the work we've committed in this next one, two, three, or four week period that we can actually get it done? as a cross-functional team within the constraint of getting something usable to the end user. I think a lot of people forget that as well. So I feel like automating things like sprint planning where you can feed in a profile of all of your different skill sets and their capacity. We no longer languish over this big spreadsheet that I used to use back 10, 12 years ago. There's a lot of better ways to do it nowadays, but I think eventually you just say, based on this team and what they've given me, here's how much work we can do. feed in the work and say here's the best sequence of the work. You know, the harder part is fitting, you know, utilization is not really a topic I want to get into because I think it's always misunderstood. But once you account for all of the slack time that you need to, you want to be as utilized as possible. I think using AI to help figure out what's the best path. Like I do an exercise in my class where I give them 10 backlog items and based on the different skills, capacity, and things that need to be done, what's the best fit? Right, so in data science, we talk about fitting the model. Why not use AI to help us be the best sequencing of the work with the highest value and the best way to use our capacity? So automatic task assignment, just like we do with calendars now, where people can feed in the work they need to do and it'll create the best calendar fit to maximize your workload. Automated code is coming, you know, we're already here. You know, automated. backlog creation, chat bots, AI driven testing. I think all of that is, if not here already around the corner, that's gonna affect, hopefully in a good way, the way that teams do that. Now, we can have a whole nother topic of how that affects product and marketing, because I think the biggest issue we have is getting closer to the user, and understanding and having empathy for them, because too often we get caught up in our own world that we're just...
Brian (28:03)
Yep.
Lance Dacy (28:10)
languishing through trying to get the work out. Well, why are we doing the work is the real reason and what's the best way we can get that work to the user that solves their problem. So I'll pause there. There's a hundred things I could go in. I had 35 bullet points. I have about 110, because I love this stuff, AI and data science and all that stuff. But Scott, I'd like to hear you had some good ideas in our pre-talk as well.
Scott Dunn (28:14)
Thank you. Thank you. Well, I appreciate you inviting me out to the Lance Dacey podcast. I just want to say thank you for that. Right when he drank his water too.
Brian (28:37)
Hahaha! Weird.
Lance Dacy (28:44)
Right. I can't respond. Let me take a scotch now that I can respond.
Brian (28:46)
Yeah.
Scott Dunn (28:49)
Yeah, he just needs to take a drink. He's ready to go. I know I love it. I love all the ideas in the Thoughtsland. So on my particular view, when we look at the companies we're helping, so we're Atlassian partners, so I'm watching what they're doing. And I mentioned about the fact that it can automatically do like acceptance criteria, you can ask. Anything about, take all the, what we used to call it, the tribal knowledge. It's gonna do that for you. I don't need to track down who's Lucy whomever. I'm just gonna ask it and it knows. I can say, give me a spreadsheet of the people involved with this. What's the background of this project? Any of that tribal knowledge is like, it's already there now. All that data sitting in Confluence, and Jira, et cetera, ability to create tickets. I'm not going and manually creating tickets anymore. I just say, create a ticket for this thing. So all those add up to lots of saving, time savings, all the manual stuff, anything that you just already know. And everyone hates making the tickets and doing so. it's going to take care of that stuff for you automatically. On the dev and engineering side, I'm seeing a lot around what seems to be promising, impossible, certainly code reviews, like there's a template of things that you know you're checking for in code reviews, readiness to go to production. Can it create these models and things? I think we'll wait to see. We're talking about the case tools, but I believe it will because it's not limitless on when we're creating basic applications. If you take your simplest thing like hello world, you know. or a basic screen that's only got five things or a login screen, there's only so many permutations what's gonna happen with that. And it can learn those things and do those things. Software engineering is your biggest cost for software companies, these engineers, and they're hard to find, and you got time zone issues and all these other things. Everyone's looking for ways to reduce cost right now. We've got issues of just getting the talent and the source, and you got parts of these engineers' work that they do not wanna be doing anyways. So I think you're gonna see a lot of those things put pressure on figuring that stuff out. But between the computing power that we're talking about, how much can be handled by those graphics chips and how much information is out there, I think you're gonna see real wins of measurable significance that's gonna be proven out and certainly driven by the business leaders themselves trying to find where can we reduce the cost with the promise of some of these things. But those are some that I've already seen. We're definitely watching, as I mentioned,
Brian (30:43)
Yeah.
Scott Dunn (31:12)
on the Scrum developer side, just saying like, what's happening out there? And just take a look and see what we can do. But you're gonna start finding the simpler solutions that are gonna be chipped away at first. I think about the self-driving cars. I remember thinking there's no way the car can handle all these, you know, what felt like limitless situations. It really isn't. There's only so many things happening on the roads and they have slowly learned to do that. I think it's gonna be the same on the engineering side as well.
Brian (31:31)
Yeah. Yeah, I mean, I agree with both of you. I kind of think that I've taken a stance on it, like in the past, I just see it as a tool. It's a more advanced tool and it can do some things better than we can right now. There's some things that does really well and there's some things that right now it's not very good at. And I think it's important to try to understand that, right? I'm not gonna, you know. I think I've come to a place where I would never say, I don't think it could do X, Y, Z, because I think that eventually it can. I think that there's gonna be things it can do. And it's just a matter of time before it can do pretty much anything that we could be doing right now. Even right now, one of the things it's really, really bad at is having ideas. It doesn't really...
Scott Dunn (32:10)
Right.
Brian (32:30)
brainstorm or it can give you ways of, it can give you some little tidbits and things that you can build upon. But having used it to help try to write a blog post or anything like that, well, here's an experiment, right? Go to any, your favorite AI and ask it for 10 business ideas based on whatever, just, Uh...
Lance Dacy (33:01)
Of course it's not going to be good at that.
Brian (33:03)
Well, no, it'll give you, it'll give you 10.
Scott Dunn (33:03)
There's a creativity problem right there. We have a problem with creativity. I see it.
Lance Dacy (33:07)
I'm just kidding, bro.
Brian (33:08)
Yeah, it'll give you 10, but then go back and ask it and do a new chat, ask it again. Do a new chat, ask it a third time. Compare the answers you got across all three. And what you'll see is it's a lot of reused stuff, right? And the reason that it's recycling it, the reason it's reusing it is because this is a large language model. This is pulling from what it's been trained on, right? It doesn't invent a new thing itself.
Lance Dacy (33:33)
Mm-hmm. Create new you
Brian (33:38)
Right, now again, I'm not saying that it can't do that in the future, but what we have today is not a creative source in that way. It has to have the training data, even image, kind of AI image generators, that's built on what it's trained on. So you can't train it to a point to say, give me a picture of something that you haven't been trained on, right? weird picture that you have nothing in your database to go back to and use as a reference. It can't do that because it can't imagine, right? Yeah.
Scott Dunn (34:18)
Yes, that's the key.
Lance Dacy (34:22)
I was working with a company, they do ads, helping people come up with ads. So a lot of marketing spend money out there, right? You can tell it what kind of market you want to go into, what your competitors are doing, and very quickly feed it some images, feed it a few websites, and it'll give you 100 different ads with the words and everything you want to take on it, and already give it a conversion score. Like...
Brian (34:44)
Yeah.
Lance Dacy (34:45)
this ad should get this amount. And it was amazing to me, because I kind of struggle with that anyway, as a business owner, creatively coming up with content and ads and things like that. Like we were talking about earlier, I don't think on this podcast, but like being a co-pilot, having the AI stuff be a co-pilot where we kind of use it as a tool. I think eventually it'll be vice versa, ironically, where we'll be the co-pilots. I think... You like personalized user experience, creativity type things like, you know, how we do AB testing and stuff. Why not let AI do a lot of that user research and spin up the code very easily and figure out click patterns and things like that. Like I could say, I need nine different designs for this one screen. I mean, that used to take weeks, if not months for a designer to sit and attend, I'm not trying to bash their field. I love working with them. And. They're very creative people, but I feel like that's going to be the next step with this AI is, hey, give me nine options. And then that designer spends less time creatively. They get better ideas sometimes. Maybe some of them don't like that. I don't know. I'm not a creative person like that. But I can see that helping me in saying, hey, I don't have to hire these nine marketing people or five marketing people. I can just say, hey, let's look at those things. So I think that user, that creativity, Brian, is what you were hitting on imagining things.
Brian (36:02)
Yeah.
Lance Dacy (36:03)
Yeah, give it a lot of data can give you options and then you can take that and come up with the ideas as a human, but yeah, eventually that'll all be taken over too, I think it's all taken over the world. T1000, here we come.
Brian (36:15)
I think you've got to have one of the concepts that's out there is referring to these as agents and having multiple agents that will carry out a different task for you. And I really think that's when I think about the future of this kind of stuff and how this would affect a typical software development team, that's what I see. We have hierarchies in our organizations that exist. And those are essentially different layers of agents, right?
Lance Dacy (36:23)
Yeah.
Brian (36:43)
And I think that that's what we're going to see with software development teams and other things is we'll have a deployed network of agents and these, these AI agents will speak to each other and they'll, they'll refine what each other do. Uh, right. And it makes it easier for us, but again, we've got to have the idea to generate it, to start it, right? It just, it can't do that on its own right now.
Lance Dacy (36:57)
make it easier for us.
Scott Dunn (37:03)
Cheers. There's definitely a few things where I've just been popping in, where I had to do some legal docs and I just went there and had it write them. They were great. Just fill in the blanks. I was waiting to get content back from someone about a speaker, maybe somebody to go about Mark Kilby on remote and waiting and waiting. I'm like, dog gone. I just wouldn't ask, you know, chat GPT tell me about Mark Kilby, what he does and grab that. And it did a great job. Put that out there. I didn't need, I didn't need someone else to do it. I didn't need to wait for that.
Brian (37:31)
Yeah.
Scott Dunn (37:34)
And I don't even look for creative art anymore. I simply say, give me this art. I do it in Creative Cloud. Give me that, and then you know, good enough's good enough. I move, because it's like you're touching on the delays on some of the things that can be the killer of that. I think in the same way back in the day, Sudhnyalanshi said that you're dating yourself. And I remember when I was younger, we just had electricity for the first, I'm just kidding. But think about the first time when you're telling people like, no, the computer could do that for you.
Lance Dacy (37:35)
I'll see you later.
Scott Dunn (38:02)
I feel like we're becoming a lot of companies now like, no, AI could do that for you because they just don't know. If they're working a certain way and they've been in that company for 20 years, they think, no, my job is to create the new insurance for them and then send that, no, you don't have to do all that. So I think it'll be a redistribution because for all of us to see here right now and say, I've let go of thinking there's limits to this and that's where I've come to last few weeks. And we're, and we're.
Lance Dacy (38:23)
Yeah.
Scott Dunn (38:26)
Well, I'm going to, I feel, I feel we're cutting edge. Your audience may say differently, Brian, but I feel like we're cutting. I feel like we're cutting edge. And if we're just coming to realization, there's not limits. Think about your traditional worker who's not necessarily a knowledge worker, they're just in the office. They have a certain role. It's been not too different over the last 10, 20 years. They have no idea. I probably could cut that. You mentioned Lance about the ads and I was seeing something recently that said that those AI ads can cut, can cut the design time by 90%.
Brian (38:31)
Yeah
Lance Dacy (38:46)
Yeah. I would totally agree. I mean, I tried it and you just like you were saying, waiting on delays to me is my biggest thing. Like the best thing we can do for an organization is a value stream mapping of some sort and say, where does the cycle times killing us? There's so much low hanging fruit there that you could turn that into millions of dollars. And if we were just quit articulating words for that, let's just go do it. I feel like that's what AI is gonna do for us. We were talking about the, Mike's
Brian (38:55)
now.
Lance Dacy (39:22)
written a book on user stories and all that. So I'm going to use that as an example, as a product backlog entry point to getting work done. And I think we were talking about this before the podcast. And I feel like eventually we're just going to have a user say, as a user, I need to be able to pay by MasterCard on this screen and make sure the error message says this. And if it is successful, do that. And we won't need programmers. The computer will take that. And it'll write the code for that. It'll deploy the code and it'll say, what do you think about that? And so when you talk about this with agile, but I don't know what we're gonna have these, we're just gonna have users that can now have software created for them. Just like I can an ad, you know, it's like, I'm gonna have this design created, but I speak to it in natural language. Who cares if it's C++, COBOL or JavaScript or Python or whatever, it doesn't matter anymore. The computer will decide. and write it, deploy it, and manage it, and take all the complexity out of it. That's eventually where I think we're headed.
Brian (40:23)
OK, I just want to state this out there for all the listeners. Make sure you at the right person on this. It's Lance Dacey who said that all the programmers are losing their jobs. All right, just make sure you get it right. That's who said it. Uh.
Lance Dacy (40:36)
Oh my gosh.
Scott Dunn (40:40)
Here's to seeing you all again.
Lance Dacy (40:41)
Did I really say all? I just said it's going to be a disruptor. I thought, but you know, I'm sorry. So just like I think you like your next designers, I think software programmers are just highly creative and great people. So I mean, no, uh, you know, no, just be on the lookout, find a way to contribute to the fact that your job.
Scott Dunn (40:45)
I heard everyone within the year. I think that's what I heard.
Brian (41:03)
Yeah. No, I mean, all teasing aside, I think that the developers who are using it now within their IDEs and locked into some of these tools that are available to have AI help them with code, they're ahead of the game. And people who are afraid of that stuff and saying, no, I'm not going to keep that at arm's length, we've seen this movie a million times. Right.
Scott Dunn (41:03)
Yeah. Yep. Yeah.
Lance Dacy (41:19)
Yeah. Yeah, played out over and over. It's like, you know what, Brian, two weeks ago, I don't know what the time is, I'm just being facetious right now, but a while ago, I would say that not true about programs because I say you will always need somebody programming the computer, but I've since now changed my mind thinking because I'm highly agile and I learned in that space and I drink my own champagne. That's not really true because I can go into chat, you know, I took, I'm a programmer myself, so I mean, no disdain about that, I remember in school, the first program I had to write was C++ about calculating the Easter Sunday date for a given year. And I had to write code to do that. And I tested that with my son over my shoulder, saying, I'm going to show you what ChatGPT can do. I said, write me a C++ program that calculates Easter Sunday for a given year. And I swear to you, in under a minute, all the code was there. Now, it didn't run. I had to take it and put it into an IDE and compile it and do all that stuff. But it worked. And it took me months to do that. So all I'm trying to say is it can help us be better. The creative side will always be there, but can you imagine not having to worry about code anymore? And you do more of prompting the computer instead of coding. That's really what I mean. I don't want to say their jobs are going away. I just think their jobs are going to be changed. They're going to be the next disruptor, just like I was talking about real estate agents and banking and all of us have been disrupted. But we gotta welcome it. Take it.
Brian (42:37)
Yeah.
Scott Dunn (42:40)
Yes. Brian (42:49) Yep. Yeah, right. Welcome to the party, pal. Yeah, no, I agree.
Lance Dacy (42:57)
Right!
Scott Dunn (42:59)
I feel like saying at this point, we should let all the listeners know that actually this podcast is AI generated and these are not actual people here.
Lance Dacy (43:07)
I'm not really sure.
Brian (43:10)
Yeah, this was done with the approval of these three people, but written by written by AI agents. No, no, it's absolutely not. These are real human beings. Well, guys, this has been a really interesting discussion. And I know we've gone a little bit long. But hey, it's the hundredth episode. Come on, cut us some slack, right? We got three of us here. We obviously are going to kind of diverge a little bit. So
Lance Dacy (43:15)
Good.
Brian (43:35)
Thank you guys so much for coming on and helping us to celebrate this 100th episode. I really appreciate it. So just want, you know, Scott, thank you.
Scott Dunn (43:45)
Thank you.
Brian (43:46)
And Lance, thank you as well.
Lance Dacy (43:48)
I'm about to say Lance, no thanks. Thank you, Greg and Brian. I always love being on here and Scott, great to see you. It's been too long.
Scott Dunn (43:49)
Yeah. Hahaha. Good job.
Brian (43:52)
Right.
Scott Dunn (43:56)
These two, yes, really enjoyed it.
Brian (43:57)
Awesome.

#99: AI & Agile Learning with Hunter Hillegas

Join Brian Milner and Hunter Hillegas as they unveil Goatbot, Mountain Goat Software's latest AI innovation designed to transform how we access and learn from Agile and Scrum resources. Tune in to hear Hunter delve into the intricate process of developing and testing this AI platform.
Overview
In this episode of the Agile Mentors Podcast, Brian and Hunter Hillegas, Mountain Goat Software’s CTO, dive deep into the capabilities of Goatbot, an AI-powered tool that makes accessibility of reliable Agile and Scrum knowledge easier.
Developed by Mountain Goat Software, Goatbot answers queries using the company’s extensive array of training materials, blog posts, and articles, ensuring that users receive precise and reliable information.
The discussion also covers the rapid advancements in AI technology, exploring its burgeoning role in coding and testing. Join Brian and Hunter as they explore how Goatbot was created, its impact on learning Agile methodologies, and the exciting future of AI in software development.
Listen Now to Discover:
[1:05] - Brian welcomes our beloved Chief Executive Officer at Mountain Goat Software, and creator of Goatbot, our Agile & Scrum AI, Hunter Hillegas.
[4:06] - Hunter explains how he and the team were able to make an AI platform to answer Scrum and Agile questions accurately every time.
[7:07] - Hunter talks about the experience of working with and developing AI from a long-term programmer's perspective.
[10:35] - Hunter and Brian share that Goatbot is available, accessible, and free on the Mountain Goat Software website.
[12:25] - Hunter walks through the process of creating Goatbot and some of the challenges the team faced to bring it to life.
[15:42] - Brian invites you to come on over and test out Goatbot, run it through its paces, and tell us what you think. Goatbot is free to use and specifically programmed to answer all your Agile and Scrum questions. Ask away!
[17:23] - As a technologist, Hunter talks about the parts of AI that are exciting and interesting in the tech world.
[19:05] - Brian points out the pace that AI technology is improving, underscoring its impact on setting new standards of improvement industry-wide.
[22:36] - Hunter shares his approach to integrating AI tools in his coding and testing processes, highlighting when they're beneficial and when they're not.
[28:46] - Brian shares a big thank you to Hunter for joining him on the show.
[29:30] - Brian shares the array of complimentary tools available at Mountain Goat Software, including Relative Weighting, as well as those tailored for users in the Agile Mentors Community, such as Planning Poker.
[30:41] - If you want to ask a question or provide feedback on Goatbot, email hello@mountaingoatsoftware.com
[31:06] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email.
[31:39] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software.
References and resources mentioned in the show:
Hunter Hillegas
Goatbot
Mountain Goat Software’s Free Tools
Mountain Goat Software’s Relative Weighting Tool
Mountain Goat Software’s Planning Poker
Mountain Goat Software
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.
Hunter Hillegas is CTO at Mountain Goat Software. With over 20 years in software development and a knack for creating high-quality digital solutions, he thrives at a company that values excellence in education and customer satisfaction, living in Santa Barbara with his wife and their distinctive Pitsky, Enzo.
Auto-generated Transcript:
Brian (00:00)
Welcome in Agile Mentors. We are back for another episode of the Agile Mentors Podcast. I am with you as always, Brian Milner. And today I have a very special guest, a coworker of mine, Mr. Hunter Hillegas is with us. Welcome in Hunter.
Hunter (00:17)
Hey Brian, thanks for having me.
Brian (00:19)
Absolutely. Hunter is our CTO. He is the guy who's all about technology. And anytime I have technology questions, this is who I go to. And he is very patient with me and helps me to understand things when I don't understand them. But we wanted to have Hunter on to talk about one thing in particular that we felt like maybe not everyone knows about yet. or maybe you've crossed paths with it, but really are kind of interested in the story behind it a little bit. That is Goatbot. If you don't know, actually, I shouldn't be answering this stuff. If you don't know what Goatbot is, Hunter, tell them what Goatbot is.
Hunter (00:54)
Yes. Sure, so as the listeners may know, Mountain Goat, Mike Cohn in particular, but also Brian and other contributors, we generate a lot of content, whether it's training material or blog posts, other articles. And for a long time, we've wanted to make that more accessible to people. There's just so much of it that that's always been a little bit of a challenge, even using search and other technologies. And like, A lot of other people, about I guess 18 months or so ago when ChatGPT launched, I became a lot more interested in large language models and got a better sense of what the state of the art was there. So Goatbot is our attempt to meld those two things together to try to solve that problem to make all of our content more accessible using some of that technology. So it is a tool that lets you ask questions about scrimmage topics and it will answer them based on all the stuff that we've written and trained on, etc.
Brian (02:06)
That's a great explanation. Yeah, that's what it is. That's the idea behind it. And I'm sure Hunter will back me up on this. I'll tell you, when we first started doing this, I was trying as much as I could to put it through the paces. And I think I may have even said this on other podcasts before, but my go -to question I used to ask any kind of LLM about Agile and Scrum, was to have it tell me the difference between a product owner and a product manager. And in fact, I would say specifically, what does Scrum say the difference is between these two things? And the answers I would typically get, they would just give me an answer. They would say, well, a product manager is this and a product owner is that.
Hunter (02:46)
Hmm.
Brian (03:00)
And I remember telling Hunter, this is wrong. It shouldn't say that, right? Because Scrum doesn't have a product manager. How are we able to handle those kind of one -off kind of exceptions in working with this?
Hunter (03:14)
Sure. So anybody that's used some of the more general tools like chat GPT is like I think the go -to example that probably most people are familiar with even though there are other chatbots out there. know that, you know, sometimes it will give you wrong answers. Sometimes it will give you sort of strange answers. It will do what they call hallucinate and make things up essentially, because it really wants to give you an answer, even if it doesn't know what the answer should be. And, you know, that was something that I was worried about when I started to prototype this. Like we are, we have a, I think, I hope. to say, a great reputation in terms of the stuff that we put out there. And the last thing that I wanted to do was to put that in danger in any way by having some kind of a tool that's spouting nonsense out there. So. That was important. And I didn't really know how well it was going to work when I started sort of prototyping this whole idea. And I had some doubts. But what I discovered was that if I gave the model very specific instructions about where it should be pulling. It's, uh, it's information from, i .e. please only use this information I'm giving you, um, that is, we know it's from our materials and not sort of maybe some random article that they found on the web somewhere. That's part of the larger trainings that be very specific. And if you don't know an answer, say, you don't know, you don't need to make anything up. Um, so those sorts of what they call system messages did a lot of tuning there. Um, and ended up with something that actually works. pretty well, I think. I mean, it exceeded my expectations once I started getting, once I got to the point where there was something where I felt like I should share it with the team, that it wasn't embarrassing. And I feel like, you know, the feedback internally was really good and the feedback that we've gotten from people that have been using it has been really good. So I'm happy with how it's going so far.
Brian (05:09)
Yeah, I've been really, really impressed. It's been just a really nice tool. It's done a good job. We initially had it sort of internal, like you said, and we put it through its paces. We had kind of widening circles of people that would test it out and try it and give us feedback. And Hunter kept tweaking and making adjustments to it. But I'll tell you, I don't know if I even told this to you, Hunter, but I was doing a... ACSM class a few weeks back. And one of the opening exercises we do in that class is to really kind of consider some of the other Agile frameworks that are out there, not just Scrum and see how they compare. And one of the ones I have on my list is one that doesn't get used very often. It's kind of one that died out, but it's called Crystal or Crystal Clear if you know that or you're familiar with that.
Hunter (06:00)
Mm -hmm.
Brian (06:07)
But I wanted to see what the Goatbot would say about it, so I asked it specifically, just give me an overview of what Crystal is. And I think I said specifically the Agile framework Crystal, just to make sure it wasn't anything strange. But the response that came back was, I don't have any information on that. I know about Scrum, and I can give you answers about that, but I just don't have any information on anything else. And I.
Hunter (06:21)
Right.
Brian (06:34)
Honestly, it really impressed me. Here's another thing that it could have made something up and said, oh, yeah, yeah, it's this. Or it could have pulled from some general database or something else out there. But it's tuned really well to only pull from our data. And I just think that's awesome.
Hunter (06:50)
One of the things that's been strange slash interesting for me as a long time programmer in all kinds of different technologies from the web to native applications to other things. is how different it is working with these LLMs and trying to get them to bend them to your will. There are instructions in the system message that in all capital letters say do not make anything up. And the fact that I'm having to program a computer, I'm doing scare quotes here, program a computer by telling it not to invent things is just so bizarre coming from a very two plus two equals four world of more traditional programming. But it's also been really exciting and interesting.
Brian (07:32)
Yeah. Yeah, it is kind of completely opposite from a programming perspective, right? Because we're so used to, oh, it's not going to do anything but exactly what you tell it to do. And it can't fill in gaps at all. And now the problem is it could fill in too many gaps or try to fill in too many gaps. Yeah.
Hunter (07:44)
Right. Right. Absolutely. And you can think even just beyond, you know, your example of a, of a, of a framework that's not in common use and probably not something that we've talked a lot about on the website and our own own materials. There's all kinds of other instructions that I had to put in. Cause I didn't want this thing sort of going far afield and, and, and, you know, coming up with a really wacky, potentially terrible answer, um, to some of these questions. And so, yeah, we're, you know, we, we do give it some very specific instructions on how it should behave.
Brian (08:21)
I tell people who come to the class that, you know, I can't a hundred percent guarantee. I can't a hundred percent say, yeah, it's always going to give you a hundred percent the right answer. But what I can tell you is I've, you know, we've all put it through its paces. We've all asked it things that we feel like, Hey, this is kind of tricky. I wonder what it would do with this. And, uh, you know, just my own personal perspective has been when I, when I ask it a question and it gives me an answer, it's, it's. damn close to what my answer would be. It's really close to what I would say on that matter.
Hunter (08:55)
Yeah, it's encouraging to hear that. And I've heard that from you and from Mike as well, and then also from customers that have been using it over the past, so whatever month and change or so it's been more publicly available that they are really happy with the output. And it's a great way for us to take advantage of all of this material that we've built up over all of these years that otherwise some of it probably would be. something from 10 years ago, still really relevant in a lot of cases, but maybe gathering justice. Cause it's not, you know, the top blog posts on the website or something. So some of this knowledge, it's a little bit more varied. We can resurface it with a tool like this.
Brian (09:33)
Now, this was something that we initially just had in the Agile mentors community, right?
Hunter (09:39)
That's how it started. And that was for a few reasons, mostly because, well, a couple of important reasons. One is that with these types of LLM things, there are costs associated with it in the sense that it does cost us per question effectively. And just we wanted to make sure that we understood what those costs were before that we just let it loose on the wider internet. So that was part of it. But also to get a sense of how people would react to it in those early weeks and months got a lot of feedback. feedback on the responses just to get a general sense of did people think that this was a good answer or not so good and use that to calibrate it because you know frankly if it underperformed where we wanted it to be that would be a good signal that we needed to do some more work on it or give it some more time to bake.
Brian (10:26)
Yeah. Yeah. And now we kind of have opened that up, and it's available to anyone. You can go to Mount Goat Software and look in our menus. And there in our tools, it's under Tools, right?
Hunter (10:41)
Yeah, so you can get to it from the Mountain Goat site. You can either go to it is in the navigation, I think right next to the podcast for those of you that are familiar with where to find that on the website. I think it's right next to it, at least for now. No matter what you can go to mountaingoatsoftware .com slash goat bot and that will take you to the right place. That's G -O -A -T -B -O -T. And it is free right now. So we've couched that with at least for a limited time. We are again, sort of experimenting with the model and where it's going to go. But you can sign up for an account today and use it for free and get put it through its paces. And we're pretty happy with what we've got so far. So please do do that. And hopefully it's useful and give us feedback if you find something that you think could be improved or or let us know if you worked out for you to like to hear those as well.
Brian (11:29)
Yeah, yeah, absolutely. And yeah, we kind of buried our lead here just to say that, yeah, it is free, right? We're not selling you on something. We don't have a package of things that we're not. Yes, we did originally have it in our Agile mentors community. But like Hunter said, there was a lot of reasons for that. We wanted to be safe with it. We wanted to have a smaller audience, see what kind of responses we got.
Hunter (11:38)
Right. Yes. Yeah.
Brian (11:58)
We'd hate to put something out there in the world and then have people say, you know what kind of crazy stuff this thing told me to do? So yeah, kind of a safer audience there to start with. But yeah, it's available to anyone for free. You can just go to our site and use it. And as Hunter said, yeah, please give us feedback. If there's anything that you want to just let us know that it was useful to you in any way, or maybe you used it for something unusual, we wouldn't have anticipated.
Hunter (12:04)
Right. Right. Hahaha.
Brian (12:27)
Yeah, let us know. We're trying to tweak it and make it as useful as we possibly can. What surprised you most in this work of putting this together? Did it go just as you expected or did it throw you for some loops along the way?
Hunter (12:42)
There were definitely some loops. I mean, I sort of alluded to the fact before that it's a little bit different of a mentality in terms of how you get it to do what you want. GoPod is actually a few technologies glued together. There's the content itself. So as you might imagine, we've got... all of this various content, whether it's transcripts from training courses and videos or blog posts that Mike has written or weekly tips, books, all kinds of stuff. So there's a ton of different content. It's all in these different places. So, you know, step one was creating a sort of pipeline that could take all of this content that's all in these different places and clean it up a little bit so that it didn't have, say, you know, editors notes in it and other things like that that don't make any sense. and then put that content into a vector database. So I'm sure that many listeners are familiar with more traditional relational databases. Vector databases are not new, but they have become a lot more popular with the rise of the LLM stuff. And basically a vector database will chunk up the various content and lets you query to figure out how content that is close to the query that you asked in a mathematical vector space. And so we use that when you... pose a query to go, but it will go and find relevant pieces of information related to your query that the LLM in this case we use GPT -4 as the model underneath our underneath go pot can take the content that was retrieved these sort of chunks of content that by themselves don't read very well, wouldn't be a very good answer. And it can use that to reformat it, to summarize, to put stuff together into a way that makes sense. Putting those pieces together was something that was new to me. I can't remember the last time I had used a vector database for anything. And the LLM bit was new for me as well. But despite the fact that it was new to me technologies, at least in those cases, the pieces of it coming together actually was simpler than I imagined for how well it worked even in its first incarnation. It kind of came together more quickly, the basic core of it came together more quickly than I thought that it would. There was then a lot of refining, especially around the prompting and the messaging stuff. But... These technologies, especially if you are a programmer, even if you don't have any background in machine learning or AI stuff, I think it's accessible and, in my opinion at least, fun to play with because it is kind of like a whole new world there. So I guess I'd say for those that are interested and maybe are worried that I don't know anything about these technologies, I would go check them out because I think you'll find that they're more accessible than you may think.
Brian (15:39)
Yeah, and they're getting better. I mean, the pace of their improvement is just so rapid. You know, you tried something, you know, two weeks ago, and then two weeks later, it's just a completely different experience because it's just incrementally, you know, nonstop getting better all the time. Gosh, I'm...
Hunter (15:45)
Yep. The models, I'm sorry to interrupt you, Brian, but yeah, I mean, I agree 100%. The models that we've been using have gotten faster and cheaper, I think two or three times in big step change moments since we started the project. I mean, that is a technology that's moving quickly.
Brian (16:13)
Yeah, yeah. No, I was just going to make a joke about the fact that I think we've quoted about two or three songs there, and I just did another one with getting better all the time. Yeah, so this is a fascinating topic, Gary, obviously, for a lot of people. And what I'm kind of curious here, because we're maybe about halfway through our time, and I'm just kind of curious if we shift gears a little bit. from talking about GoPot to talking about AI in general, because you've done a lot of work in this area, and you're obviously in technology, and you're an aficionado, a technologist. What have you seen most recently in this area? Where do you think this is headed? What kind of trends have you noticed recently?
Hunter (17:01)
Well, I mean, it's obviously an area of great interest for the development community. It also, it seems like in the last year, every product that we use as tools or whatever, they are talking about the AI features that they're adding. Um, and at least in my experience, you know, some of those are really interesting, you know, like we use zoom often for internal meetings and, you know, it has a feature now that can automatically summarize a meeting and you can ask it, you know, what were the follow -up items and stuff like that. That's great. There's also maybe a little bit of sort of round peg square hole with some of this. Like, I don't know if every tool in the world needs an AI feature, and there are definitely some where I seems a little bit useless. Um,
Brian (17:40)
Yeah.
Hunter (17:48)
I guess that's to be expected with something like this that's got so much interest. The things that I'm excited about, and it feels like it's still very much early days, but you can see the contours are what many people would refer to as agents. So basically, AI tools that are going to go out and do things on your behalf. So not just write me a blog post or summarize this email, but... You know, and the example that's often used in some of these demos is like book me a vacation. I personally, I want to pick the seat I'm sitting in. So I don't know if I'm going to do that, but, um, you know, when the, when the tools can get good enough to go out and do things for you. Right. So I don't know example of this podcast recording, uh, we, you sent me a link to the calendar tool. I found a time that was open, but in theory that could be completely automated away, right? My agent could talk to your agent and it could just find the time. And that would, we would just both be told like, Oh, you guys are recording.
Brian (18:21)
Yeah, me too.
Hunter (18:44)
You know, at X time, that sort of thing, right? And then going several steps beyond that. I think that's really interesting. People are starting to build those. The models need to get, I think, a good bit better before, you know, that really works well. But I can't wait to see where that goes in particular. I think that's gonna be a lot of fun.
Brian (19:05)
Yeah, I agree. I mean, like Zoom is a great example because we were even having conversations about this recently, just that there's a lot of criticism about how good and the quality of those summaries that take place after a meeting. But previously, when we encounter a technology tool like that, you'd see the product and you'd say, oh, it's either useful or it's not useful.
Hunter (19:18)
Mm -hmm. Mm -hmm.
Brian (19:34)
And it's kind of a binary one or zero. If it wasn't useful, then it really was about how that company implemented that feature. And they weren't going to do a massive overhaul of how it was implemented. It kind of is what it is. So we're kind of conditioned, I think, to have this response. Or at least if you're of a certain age, you're kind of conditioned to have this response of, hey, if it didn't work, it probably is not going to work. I can move on and find something else. But.
Hunter (19:43)
Right. Right.
Brian (20:03)
The pace of how this gets better is such that you try the Zoom tool, you look at the response and think, oh, that wasn't very useful. But you do it again in two weeks later. And all of a sudden, it's everything that you wanted it to be in the first pass. Because people have been saying, hey, this doesn't work, and I wish it was this way, and then the tool can update and modify. And it's crazy to think about, we have to get our heads wrapped around the pace of improvement is now vastly different.
Hunter (20:13)
Mm -hmm. It's it is definitely that's a very good point and it is different and you know, I know that there are some folks that you know, you take exception at calling these things AIs because they're not actually smart, right? How do how they work? They're not. They're not intelligent. But they are pretty impressive and they do unlock a whole lot of interesting new categories of stuff. And maybe you could have done some of these tasks before in other ways procedurally, but these can make some of those problems a lot easier to solve because of how they work. Now, I mean, I don't think I'd want ChatGPT to do my taxes, but...
Brian (21:12)
Yeah.
Hunter (21:14)
But it does have a lot of really interesting use cases. And you are absolutely right that these models are improving so quickly. And it is kind of like that little brain in there. And they can upgrade it with the latest version. And all of a sudden, it's just a little bit smarter. And again, I know some people take Umbridge as smart and intelligent. But I think you know what I mean.
Brian (21:34)
Yeah, no, and the funny thing there about, I mean, your example about doing your taxes is, you know, I laughed about that and thought, oh yeah, I'm kind of with you. I wouldn't want to have an AI do my taxes, but that's our opinion. There's probably others that would say, no, I'm fine with it doing it. If it's been trained and it's, you know, been programmed to do it a certain way, then yeah, that's fine. And I, you know, I'm aware of services that will do that with legal documents now that will create entire contracts and... wills and all sorts of stuff from a legal perspective. And that kind of leap, maybe that's the line for me. I look at that and say, oh, I could see that. Because it's a kind of a limited knowledge base. But taxes are kind of the same thing. They're, yeah.
Hunter (22:18)
I think it's doable. Yeah. I, I, I'm still at the stage with something like that where I'm in the trust, but verify mode. Like I, you know, it's, I would want to check it over and make sure it was correct, but I can easily see, you know, a little bit further down the road where a defined problem set like that, you can pretty much guarantee that it's going to, you know, give you a valid answer.
Brian (22:24)
Yeah. Yeah. Well, so I do want to dip our toe just a little bit in this other area too, because I know there's probably people wondering about this. You're in technology. You're at the levels where you're doing coding work. And I'm sure that you have made use or tried to make use of some of the tools that are out there now that assist and help with coding. What's your opinion of the current state of that art?
Hunter (22:56)
Mm. Yeah, no, great question. And I do use those tools. I'll use ChatGPT sometimes to work through a problem, or GitHub Copilot is the other tool that I use often. It's integrated into some of my other tools. I have found it useful in a bunch of different ways. I can find it useful to either... Help me write code that I 100 % could have written myself, no problem, but it would have just taken a little bit longer because I would have to go look something up and then remember some function name that I had forgotten. So like a script to reformat a CSV file or something like that, right? Not complicated, not breaking any new ground, something that I'm gonna use once and throw away. It's really good at that sort of thing and just creating something for me that I, you know, again, could have done myself easily, but it'll save me 10 minutes and I'll take it. I've also used it to help me understand a little bit. Maybe there's code in a language that I don't use very often or a framework I don't use. It's kind of like, what is happening here exactly? And having it try to explain it to me and walk through certain things. And that's also been useful for me, kind of just like I would talk to a colleague that might know a different area of a system better than I do, have a little bit of a back and forth. And that's been useful. I do not. do and at least right now would not feel comfortable with is like, I guess the equivalent of like copy and pasting code from Stack Overflow, right? So just taking huge chunks of code where I have no idea how it works or what it does and saying, it seems to give me the right answer, so I'm just gonna use it. That I wouldn't feel comfortable with in any context, whether it was AI generated or something that I found on a website someplace. So. I kind of treat it like, and others have said this too, but maybe like a pair program situation or like a junior programmer that might not have all of the experience, but is definitely very competent and can help with things. And I do find it saves me time. So I'm glad that it's there.
Brian (25:10)
Yeah, you know, it's funny because when you said that I wouldn't copy and paste, you know, things over, I kind of feel that same way. I'm not doing code, but I just didn't, you know, anything I would write or anything I would, uh, you know, kind of come up with in that way. Um, my, my kind of opinion is it hasn't really helped me as much with brainstorming type activities. I don't find it to be as, as creative.
Hunter (25:38)
Mm -hmm.
Brian (25:38)
To give me different ideas. But I do really, really enjoy how I can take a rough draft of something and then put it in and say, help me tweak this or help me make this better. It seems like it does a really good job with something like that.
Hunter (25:42)
Right. Yep, I'd spend my general experience as well. And it's, you know, I, I will take any tool assistance I can find here and there. And I do think even if I, even if it's not perfect, it's still an improvement and I can get some, maybe it'll make a suggestion for something I wouldn't have thought of or looking at it a slightly different way, which I find useful. So I'm happy to have it.
Brian (26:19)
Have you utilized it in any ways to test any of the code that you work on?
Hunter (26:24)
Oh. Yeah, that's a great question. For many programmers, writing tests can be kind of drudgery. And actually, I do find that it can be pretty good at writing certain kinds of tests for you. And actually, it's interesting if it struggles to write a test for something, it may be a sign that what you're trying to test needs to be refactored because it may not be, if it's not understandable enough or it's too
Brian (26:50)
Ha.
Hunter (26:55)
Big of chunks or whatever, that can also be an interesting indicator that maybe you need to go back and tweak that as well. But yes, I mean, I don't always enjoy writing automated tests, but they are very important. And so it is nice to have any kind of labor saving in that department. It's another area where I welcome.
Brian (27:17)
Yeah, you threw out the term refactor as well. I'm kind of curious there. If it does a good job of reformatting a couple of paragraphs, how good a job does it do with refactoring code?
Hunter (27:28)
It depends, like a lot of these things, but I definitely have thrown stuff in and said, hey, rewrite this function, tell me how you would do it. And there have been times where it will say, oh, well, you could, this is maybe a little verbose, you could compact this down, you could write this like this. In some cases, I originally wrote it in a certain way on purpose, because sometimes it'll generate code that is correct, but kind of hard to read. And there's a tension there between. something that's that future you will be able to read and understand versus the most compact terse code possible, right? So I don't always take its suggestions, but it can be good. Also it's good at finding, you know, silly programmer bugs off by one errors and those sorts of things that are really common. that we, the kinds of mistakes that we all make. Um, and so, yeah, another area where I'm happy to, to get a helping hand and just save me from banging my head into the wall, trying to figure out why this thing should work. And it turns out I just put a stomach hole in the wrong place. You know, something like that.
Brian (28:25)
Yeah, I'm always kind of careful with how I phrase this, but I know there's a lot of panic and there's a lot of concern about these things being able to replace the human element. And so I always try to preface this by saying, right now, the way the thing is right now. And the kind of examples we both gave, I think, are good examples to show that right now, it can't really do that. It can't really just completely wholesale.
Hunter (28:35)
Yeah. Yeah.
Brian (28:53)
Replace the human element in it. But I think that our examples are good examples of how it can be a beneficial tool to help create these things.
Hunter (29:05)
I definitely see it as a productivity enhancer. I don't think, at least none of the models that I've seen, none of the chat bots that I've seen, I have seen a couple of products that claim they're sort of an AI developer in a box. I have not seen any that are very good. I mean, I saw a chat GPT demo of a guy that drew a picture of an iPhone app on the piece of paper and it...
Brian (29:23)
Yeah.
Hunter (29:32)
Gave it the code for a working app, but OK, great, now I want to add another feature. And like, oh, well, you can't really, because it's a piece. So some of those demos are impressive for sure. But in terms of the kinds of things that working software developers are doing every day, I have not seen anything that could replace the people that I work with on my various teams.
Brian (29:40)
Ha ha ha. Yeah, I mean, who knows where it'll be a year from now or two years from now. But yeah, I think we can only kind of deal with the state of it today. And that's sort of the state of it today. Well, Hunter, I really appreciate you coming on. This has been a fascinating topic. Again, for those who want to check it out, the whole reason we wanted to have this is just to make sure people were aware of this Goatbot tool. And hey, if you want to give someone some thanks for it, this is your guy.
Hunter (29:57)
Right. Yep. Hahaha.
Brian (30:25)
You can, if you want to send something to hello at mountegoatsoftware .com, that's our general kind of email address for anything from Mountain Goat. So send something to hello at mountegoatsoftware .com and tell us what you think of it. Let us know what you think. And if you have suggestions, let us know, right?
Hunter (30:42)
We're very excited to hear your feedback. I appreciate the kind words, Brian. I will say GoPot would be nothing without all of the content that you guys write for. So I can't take all of that credit, but it is fun to kind of pull all these things together in a way that people seem to enjoy.
Brian (30:50)
Ha ha ha. Awesome. Well, thank you again for coming on.
Hunter. Hunter (30:59)
Thank you.

#98: Coaching the Coaches with Vinnie Gill

Join Brian and Agile coaching expert Vinnie Gills as they tackle the complexities of being an Agile coach and working with and among teams. Discover key strategies for overcoming conflicts and enhancing teamwork within the coaching community.
Overview
In this insightful episode, Brian and Vinnie Gill dive deep into the often overlooked challenges that arise in Agile coaching.
They discuss the common pain points and conflicts that can disrupt professional relationships and share effective strategies for creating a more cohesive and supportive coaching environment.
Listeners will gain valuable insights into recognizing and leveraging personal and collective strengths and weaknesses, ensuring that Agile coaches not only preach transformative practices but also embody them in their interactions. Tune in to learn how to foster strong, productive relationships within your Agile coaching community.
Listen Now to Discover:
[1:10] - Brian welcomes business agility coach and speaker Vinnie Gill.
[8:07] - Vinnie unpacks the reasons behind the high number of reports about challenging Agilists, highlighting the traits that contribute to their tough demeanor.
[10:12] - Vinnie emphasizes the critical importance of 'starting with why' to forge stronger and more effective working relationships.
[13:58] - Vinnie talks about the importance of coaches applying their own methods to themselves, sharing a real-life example of this practice in action.
[17:14] - Brian invites listeners to deepen their coaching skills by joining him or Lance Dacy in an Advanced Certified ScrumMaster®.
[18:49] - Vinnie explains the counterproductive coaching anti-archetypes she has encountered, shedding light on common pitfalls to avoid in coaching roles.
[20:03] - Brian describes how Mountain Goat Software approaches empathy as a team of individuals.
[22:15] - Discover how Vinnie takes empathy further by recommending the addition of compassion to enhance team interactions and support.
[23:43] - Explore with Brian the critical role of deliberately designing a team's social contract to enhance collaboration and team dynamics.
[27:00] - Vinnie delves into how understanding and leveraging both our strengths and weaknesses can lead to greater personal and professional growth.
[27:31] - Vinnie underscores the critical need for mental health and self-care among agile coaches to safeguard against burnout and maintain peak performance.
[31:28] - Brian shares a big thank you to Vinnie for joining him on the show.
[32:00] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, such as Advanced Certified ScrumMaster®. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here.
[32:20] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email.
References and resources mentioned in the show:
Vinnie Gill
Vinnie’s Agile 2023 Speech
#54 Unlocking Agile’s Power in the World of Data Science with Lance Dacy
#89: Transformational One-on-Ones with Avipaul Bhandari
Advanced Certified ScrumMaster®
Certified ScrumMaster® Training and Scrum Certification
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.
Vinnie Gill is an experienced agile coach with a diverse background that spans continents and industries—from mining and finance to education and the public sector. With over 20 years in project and business management roles and a commitment to transformative education and agile practices, she excels at leading organizational change and fostering growth at the enterprise level.
Auto-generated Transcript:
Brian (00:53.038)
Welcome in Agile Mentors. We are back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have the fabulous Vinnie Gill with us. Welcome in, Vinnie.
Vinnie (01:08.879)
Hi Brian, thank you for having me.
Brian (01:10.83)
Absolutely. I'm very excited to have you here. Vinnie is a business agility coach. She has really a lot of stuff that makes her unique and interesting. She's based out of Scotland, but has worked in Europe and Australia. She's kind of worked all over. She also has a background that comes from a little bit more of a project management background before she got involved with kind of the Scrum world. She's been in leadership. She's kind of done a lot of different things and she crossed our path because of last year's Agile conference. She had a really interesting talk there that we thought would be an interesting dynamic for us to talk about. So her topic was about working with Agile coaches and kind of what it's like to be around other Agile coaches and what kind of led you to that? that topic, Vinny, how did you get involved? What kind of sparked your interest in kind of the complicating factors of working with other agile coaches?
Vinnie (02:17.839)
So I guess, Brian, for me, why this topic, right? I guess I do have a lot of ideas. Like I am an ideas person, but I feel like this is the most authentic one that I can talk to. And I feel like the most connected topic that I'm able to speak. Funnily enough, when I do submit conference talks, I do submit more than one, but this one actually always keeps getting picked. So clearly I think... It is a hot topic. I've also built in a lot of humor as well in the talk because I think sometimes it's really good to take a look and laugh at yourself. But you're asking why this topic. So to answer your question, I feel that we also suffer the same symptoms from the people, the teams and leaders that we coach. So. while the topic may be working with other agile coaches, the drama, it is applicable to every single team.
Brian (03:23.054)
Yeah, it's kind of more just working with each other, right? Just anytime you work with other human beings, you kind of have some of these same issues. Yeah, I think that's a good point. Yeah, and you know, the conference talk thing, you know, it's such a crazy scatter shot kind of thing. You know, you're right. You know, we submit multiple topics. We submit multiple ideas of things that we're passionate about at the time. And you never know which one's going to get picked, if any. I always tell people that last year's Agile conference was the first one that I had gotten picked to speak at and I spoke with Mike and so I kind of had a cheat code, right? Because who's not going to pick a talk that has Mike Cohn in it? But it's kind of, you never know what people are going to find interesting or what they think is something that the... The attendees are going to find interesting in this day and age as well. Have you had some, I mean, I'm guessing that you've had some moments in working with other coaches or moments in working with teams that weren't, I guess as my British friends will say, we're less than ideal.
Vinnie (04:45.679)
Why Brian, that's very polite where you're putting it.
Brian (04:47.598)
I always get a kick out of that. There was a company I worked with that was in the UK and we had some problems that were going back and forth and that's the way they phrase things was, yeah, this situation is less than ideal. And that was their very polite way of saying, yeah, there's a problem.
Vinnie (05:09.871)
Right. Yes, I have. And obviously, I think we all have. Not I think. I know for sure we all have. But the thing is, we're always on the pedestal, right? Because we're this flag barrier of how we should be and how we should behave and how we should treat people. Because that's what we coach. Agile or agility isn't only about frameworks. Those are practices and to enable those, you need to have the behaviors, you need to have the mindset. And we coach these things. So the important thing, I guess, for us is to, how are we showing up for ourselves? How are we mirroring the behaviors that we are promoting?
Brian (06:01.806)
That's an excellent point. I mean, if we're trying to kind of teach this to others and say, hey, here's the agile manifesto and here's our values and principles and we should work as a team, but then we're working with other agile coaches and we're kind of working on our own and our own silos. And we're not really, we don't necessarily even get along with the other agile coaches that we have. that are around us, we're demonstrating what we really believe, right?
Vinnie (06:38.863)
Yeah, this is correct, right? It always starts with us. And I've always said this time and time again, you can't change other people. The only thing you can do is change yourself. So if you're pointing at one finger, there's four fingers pointing back at yourself, right? And it's very common with the people that I've worked with. If you, for example, work with a leader or a true story that you've asked, I've recently... and set up a Scrum Master Community of Practice. And I just said, you know, we're starting off this new Community of Practice. It's how we're going to be. Let's just focus on ourselves. Let's mirror the behaviors and the change that we want to be because this is all that we can control. And that's me learning the hard way through, you know, my years of... or your experience. And immediately after that it went, but what about the POs? The POs really need it. And I was like, did I not just say this? And you work with another leader and they go like, oh, I'm going to do this and I'm going to do that. But this person doesn't do this. And this is like, no, no, no, no, no. Just focus on yourself. Be clear on what you want to be. And if you want that behavior from somebody else, demonstrate that behavior.
Brian (08:01.678)
Such good advice, yeah, absolutely. Well, let's talk about some of the, because I know in your talk, you talked about some of the pain points that come along with just working with other Agile coaches. Are there any kind of unique pain points that you would think are specific to working with Agile coaches, or are these kind of all, would they kind of apply to any close working relationship?
Vinnie (08:25.743)
So I'm so glad you asked this question, Brian, because this talk, I've retired it for this year. I'm not submitting it to any conferences this year because it gets picked over my other talks. And I would like to do some other talks. I mean, I'm at version six or version seven of this talk. And for the agile conference that you watched, I did the extended version. Sometimes I have the Speedy Gonzales version.
Brian (08:54.798) Hahaha.
Vinnie (08:55.023)
But it is a talk that grows. No two talks are the same. And what I actually do is I collect metrics. So every time I do the talk, I'm collecting data. I'm collecting evidence. The first question I usually ask is, have you worked with a challenging Agilist? And the aggregate that I got from the last six talks, and I'm actually looking at it, is It's about 94%. 94 % says, yes, they have worked with a challenging Agilist, right? So an Agile team, Agile person, an Agile leader, a product person, right? And the small percentage that said that, you know, no, they haven't had any problems. They were mostly lone ranges. or they actually held the contract to deliver, which means they hired other people. So they had essay. So those are pretty high statistics. The other question that I ask is, in one word, describe what you find most difficult about working with them. And the word cloud that keeps coming up again and again, because the word cloud just zoots.
Brian (10:03.374)
Yeah.
Vinnie (10:20.143)
does its magic and has this, you know, the big word is actually ego, Brian. It's ego followed by don't want to change, controlling and fake.
Brian (10:38.638)
Yeah. Yeah. Yeah. Yeah. Who would have thought that Agilist have an ego, huh? Um, but yeah, fake, fake. That's that hurts. Right. I mean that, I mean, we're, we're trying to be transparent about things and, uh, yeah, I could completely see that, that, you know, that would be a huge pain point if we feel like the, the others who are on our side, on our team are, are being fake about things and not being transparent about stuff. That's, that's terrible.
Vinnie (11:07.183)
Yeah, and I suppose the kicker here is this is not what other people are saying about us. This is what we are saying about each other.
Brian (11:16.494)
Yeah. Yeah. Wow. OK. So yeah, there's some pain points. There's definitely some things there that we could do better that are less than ideal. And if that's given, if we have those kind of problems inherent in our relationships and our working relationships without their Agilist, I know you also talk about some kind of tools and techniques to make our coaching group a little bit more cohesive. So what have you found there? How have you found ways to kind of bring that coaching unit together?
Vinnie (11:59.823)
So what I did is I basically started with the why. Why is it important that we need to work with each other? And quite aptly, I pointed out that it's a hard job. You're going in there and you're trying to introduce a different way of working. And that's hard. You're taking those decisions. You're being passionate about it. You're having those challenging conversations. So ultimately, you know, it is complex. It can be highly political. I mean, it always is. And so it's really important to have somebody who has our backs. And that's the why, right? And then it goes on, you're up. And then the next one is to understand the system that you're in. What does your system of coaches look like? They're, you know, permanent. um, you know, different types of employment, so permanent contract consultant, and then you've got the different coach levels like team program enterprise, and then you've got the different management types, you know, that you're trying to integrate. So you've in some companies and I've been in companies like this where you have a mix of all kinds. And also you have, you know, some companies where you might just have a couple of agile coaches. So understanding the system and. who your colleagues are are really important. I predominantly am a contractor and sometimes I'm a consultant, but I always look to leverage the relationships that I already have on site. So if they're a product person, if they're a Scrum Master, they're all one of us. We're all each other, you know, even product people. And I know this is split between product people and not agile people and Kanban people are not. this and that, but hey, we're all after the same goal here, you know? So I don't buy this whole thing by creating factions. I'm all about how we can work together. So once you find out who's in the system, try and see how you can leverage each other and use what we all have to our advantage. You know, for example, some conversations is better coming from a permanent person. Some conversations is better coming.
Brian (13:58.126)
Yeah.
Vinnie (14:22.287)
from a person that's outside. So build those relationships, make friends.
Brian (14:28.59)
Yeah, yeah, I would think there's sort of an inherent flaw or not. I don't know if I would say flaw, but there's there's inherent crack that could could could present itself in this relationship because you know we all have our preferences for how things should go and while we all follow the same kind of values and principles, the practices are very, very different. And I might come in and have a certain particular stance I always take on estimation, for example, and say, this is the way I think people should estimate, and I've found success with this. And then if I have another consultant or Agile coach that's there who feels very strongly the other way, well, now we're presenting two different conflicting opinions. And I can see how that would be really confusing for the client, right? For the person we're trying to help.
Vinnie (15:30.927)
Absolutely correct, Brian. So my question to you is if you were a coach and two leaders had two different opinions, what would your advice be to them?
Brian (15:42.51)
Yeah, I mean, we'd have to discuss it. We'd have to analyze them. We'd have to sit down and say, you know, what are the pros and cons and, you know, try to reach some kind of consensus. Yeah.
Vinnie (15:50.895)
Exactly. So a lot of the things that I'm saying in my talk is not exactly rocket science. It's just that sometimes we do not take our own advice. We don't take our advice, but we also forget about ourselves as well. We tell our teams to have fun. I tell them to go play bowling. You know, we tell leadership to go have a nice away day. By the way, I believe we're all leaders just for the record.
Brian (16:01.742)
Yeah.
Brian (16:19.95)
Yeah.
Vinnie (16:21.135)
Um, but we don't have time to have fun ourselves, right? As almost like sometimes we're always very spread thin, like Vegemite, which is this Australian thing. Um, and sometimes we eat the burnt toast. You know, we save the, the burnt stuff for ourselves. We, we forget ourselves. We coach people to have empathy, but we appear to not have empathy for each other. Right. Um.
Brian (16:33.134)
Yeah.
Vinnie (16:51.183)
So these are some of the tips and tricks we ask people to have a social contract and review them. We don't do it ourselves.
Brian (17:03.438)
Let's talk about that a little bit. So when you say that you recommend people have a social contract, what kinds of things would you just say are run in the mill, typical kind of things that you would see in a social contract between Agile coaches?
Vinnie (17:19.535)
It would be more or less the same thing that you would see in a team, right? Be aligned, you know, how do you want to talk to the client or how do we want to talk to the people that we work with? Bullying, intimidating, be transparent, respect each other's skills, look out for each other's backs, right? And maybe live the behaviors that we coach. So these are some things that we could have in our ways of working. I recently delivered a two -day practitioner course, not only delivered, my colleague Suzanne and I, who is a big fan of yours, Brian. Hey, Suzanne.
Brian (18:07.886)
Well then big shout out to her and thank you so much for listening.
Vinnie (18:15.023)
And so, you know, we, we put together this two day product practitioner course, which we're so excited about because it's not only learning the theory, you actually get to put it into practice a wee bit by wee bit. So that's what's going on. And we'd worked very hard for two months to put this whole course together. And the day before we delivered it, Suzanne was like, let's have a social contract on how we're going to. run on these two days. And so we, we did it, you know, we had each other. It's like, okay, so during the break, if there's, you know, we're running long or we're running short, this is what we're going to do. We're going to stay back. We're going to do this. Okay. Can we have lunch at different times? Um, and you know, things like, um, have fun, you know, back each other up. If there's a difficult question.
Brian (19:12.174)
Yeah, that's so good. And it's, you know, there's some stuff I've been working on around conflict just in general in teams. And I think that applies here as well. Just kind of the idea of, you know, if we can state prior to us becoming bogged down in something that's dangerous, right? We can state from the outset, hey, when this kind of thing might occur, here's how we should handle it, right? Here's how we think we want to handle these kinds of things. But establishing that in advance, I think goes a long way so that when it happens, you're not caught off guard. You're not sort of sitting around going, well, gosh, now we're in the thick of it. How do we get out of this? No, we've talked about it. We have a plan. Here's how we do it.
Vinnie (19:57.903)
Exactly. Yes. So yeah. And some of the, some of the other tips and tricks that I cover, just in case you're, you're, you're, you're interested. I do talk about, um, you know, I'm big on us having empathy with each other. I interviewed some coaches and I have a list of, um, coach anti archetypes, you know? Um, and some of them are.
Brian (20:09.294)
Yeah.
Vinnie (20:23.855)
quite funny after after serving. It's like you may have the overwhelmed coach, the coach who doesn't listen, the framework coach, the know it all coach, the coach that takes the credit. And it's my favorite, the Oreo coach, which is now you see me now you don't.
Brian (20:40.462)
Love that.
Vinnie (20:42.287)
Right. But with this coach, anti archetypes, I. You remember I talked about the word cloud, right? And we might have seen that in ourselves. And when I usually show this list of coach archetypes, I bet they're basically saying, oh, you know, that's Jim and that's Sally and that's Alex and that's Brian. But the thing is we have been this person at some situation, right? We've probably been some of it or all of it.
Brian (20:52.75)
Yeah.
Vinnie (21:17.519)
and depending on the situation, because we're human as well, but the important thing is we catch ourselves and we notice what's happening. And sometimes we behave in different ways because there are other factors that are causing us to behave in this way.
Brian (21:35.566)
Yeah. Yeah, that's such a great point. We just had, you know, for, you know, Mountain Goat Software, we're a small team. We have a small kind of group of people. And once a year we get together to have our, our kind of, you know, in -person discussions and meetings. And one of the things we talked about there was just the fact that, you know, we, like any small team of people, right? Like any small group of people were human beings. And people have bad days from time to time. And when you have a bad day, you certainly kind of expect people to understand, hey, it's not the real me, that's the bad day me. Like there's just, yes, I don't always behave as I would hope to, but that's because I have bad days from time to time. And... I'm trying to reduce, you know, those and try to reduce the way I act, uh, you know, that might be disruptive to somebody else, but that empathy, like you said, I love that word as well. Having empathy for someone else to say, Hey, that's, they're not a bad person. They're just having a bad day. Um, you know, we talked about, we've talked about on this podcast before kind of, uh, the acting thing about intent versus action, you know, like, uh, you, we observe people's actions. You know, that person did this or said this to me. Uh, and we ascribe intent to that. You know, you see that someone does something and then you, you kind of think, well, that must've been because they don't like me or that must be because, uh, you know, they have it in for me. That's intent. And what we have to kind of step back from sometimes I think is, is, um, jumping to a conclusion of what the intent is. You know, like we see it, we observe the action, but do we give people the benefit of the doubt on their intent to say, I'm sure it's not because they have it in for me. I'm sure it's not because they just don't like me. Maybe it's because they're having a bad day. Maybe it's because somebody else just yelled at them. Maybe it's because, you know, a million things, right? But if you jumped to that negative intent to say, oh, no, no, no, it just must be that they hate me. You know?
Brian (24:02.51)
then you're not really giving them the same empathy that you want others to give you when you have a bad day.
Vinnie (24:10.575)
Exactly. And you're not even giving the same empathy that you coach people and teams that you work to have for each other. Right, Brian? So it's not one. Yeah. So onto that, it's like there is empathy, but there is one actually higher than empathy, which is compassion.
Brian (24:18.51)
Yeah, absolutely.
Brian (24:27.534)
Hmm.
Vinnie (24:29.103)
So that's high on the effort and high on the engagement. It's really hard. It's not about just being nice to somebody for a few hours, you know. It's actually following up with that person and seeing how they're doing and how they are caring about them genuinely. I always find this when somebody passes away, it's always like during that couple of weeks. So I'm really sorry. I'm really sorry. but people feel this years to come, every special holiday, every best season. So it's a lot more than a few hours. But Brian, I'm curious. You mentioned about Mountain Goat Team. You have a wee team. Sorry, I'm saying wee because wee means a little bit for it.
Brian (25:17.39)
No, you're in Scotland. You are allowed to use that term. I am not, but you are.
Vinnie (25:25.071)
Of course you are, why are you not allowed? You're absolutely allowed. Do you have a social contract or somehow your teams, how you want to be and how you work together?
Brian (25:38.094)
You know, that was one of the topics in our last meeting was kind of talking about the fact that we needed to be more deliberate about what that was. So my answer is that no, we don't have it yet, but that is an action item that we took out of our meeting was to deliberately capture that and make sure we're all aware of what that is. So, you know, it's one of those things where, like you said, sometimes you, you, It's definitely something that I would say to another company. If I come in, you should have working agreements, team agreements. But when you get to your own little team, you think, oh, we all kind of know what that is. No, you kind of need to be deliberate about it. I agree. Yeah.
Vinnie (26:25.647)
And it needs to be reviewed. So that's something that we all, we all, we all don't do, I guess. Some of the other stuff I talked about is like capability metrics, right? And I always, I always say this. I'd, I'd rather be somebody's shot of whiskey than everybody's cup of tea.
Brian (26:45.71)
I love that.
Vinnie (26:49.071)
I am not the right coach for some people or some teams. And I am absolutely the right coach for some people in some teams. So the important thing is, you know, how we work together. If I bring the listeners back to when we talk about the coaches in the system, starting with where we are at the moment, who was that best person to go to this area or work with that person? We all have our different skills. We all have our skills, skillsets and strengths, um, and things that we're not good at. And while we're on the subject, I know everyone says, if you have a weakness, you need to do better. Nah, that's not me. You know, for me, if I'm good at something, I can be better at something. Um, and if I'm not great at something, that's fine. You know, I'm not going to, um, spend my time or feels, you know, worry about it, you know, that I'm not, not so good at it. The important thing is I am aware that I'm not very great at this and there are other people more suited to this. So that's how I've been, um, I've basically been in the last few years. It's like, yeah, cool. Don't worry about it, right?
Brian (28:08.91)
Yeah. No, I love that. I think that's great. And I completely agree. It's, it's, uh, you know, of course we're, we're, we're agile people. We, we are trying to continually improve. Uh, you know, that we, we tell that to our teams and I, uh, I think that's something we take to heart and just how we live our lives. But you're, you're absolutely right. I completely agree that, you know, there are things I am stronger in. And there are things I'm weaker in and there's no real reason for me to have to really strain to try to do something I'm weak in when there's a better option. If I know there's somebody else who's really good at that. Well, I'll give you a great example. There's a, you know, one of our, our, uh, our trainers here that we work with, we have mentor of mine that I've worked with that have on the podcast regularly. Uh, Lance Dacey, uh, Lance is really. great at he actually went back to school and got a master's in data science and he knows that much better than I do. I know a little, you know, like I know I kind of know generals. I'm not I don't know a lot of specifics, but if we had someone come to us and say no, we really need someone who's who's really big in data science. Sure, there's no reason why I should have to strain to press in and try to cover up for something that I'm not as strong in as Lance is. So I agree with you. Kind of the old adage, know thyself. Know what you're strong in, know what you're weak in, and don't be ashamed. It's just who you are.
Vinnie (29:59.727)
Yeah, exactly. Right. Cause you're never going to be a data science expert and I'm not going to be a robotics expert. Right. So sometimes when I do have these conversations with people like, Oh, you know, you're weak in this place. And I was like, well, I knew enough, but you know, so be it. And they're like, Oh, that's really weird attitude. And I was like, yeah, like I'm good at these things. It can be better at these things. I'm not so great at these things, you know, let the other person.
Brian (30:08.398)
Right.
Vinnie (30:26.511)
do that because that's their passion. That's what they're interested in.
Brian (30:30.606)
Yeah, yeah, absolutely. Well, this has been great. I thank you so much for taking the time here. I know with time differences and stuff, you're in your evening and it's already weekend where you are. So thank you so much for taking your time and sharing your wisdom and knowledge with us here on the podcast.
Vinnie (30:53.263)
Thanks, Brian.
Brian (30:55.886)
Absolutely.

#97: Exploring Liquid Agility with Arlen Bankston

Join Brian as he and Arlen Bankston unveil the secrets of Liquid Agility in this episode of the Agile Mentors Podcast. Dive into how this innovative framework revolutionizes product management and fills the gaps in traditional Agile methodologies
Overview
In this episode Brian and Arlen Bankston delve into the intricacies of Liquid Agility, a comprehensive framework designed to enhance agile practices with its unique focus on prioritization, preparation, and outcome evaluation.
Arlen walks us through the JUICE framework, which categorizes work into distinct streams—innovation, iteration, and operation—and discusses strategies for refining projects and maximizing the impact of released features.
Whether you're a product owner, Scrum practitioner, or Agile enthusiast, this episode offers valuable insights into making agile methodologies more effective and adaptable to your needs. Tune in to transform your approach to product management and Agile practices with cutting-edge insights from Liquid Agility.
Listen Now to Discover:
[1:15] - Brian welcomes Scrum veteran, Certified Scrum Trainer®, partner at Grow-Lean LLC, author of HR and the Agile Organization, and creator of Liquid Agility.
[2:53] - Explore the concept of Liquid Agility with Arlen as he reveals how it enriches traditional Agile practices, adding layers of depth and adaptability to methodologies
[4:59] - Arlen discusses how Liquid Agility transforms prioritization, making it simpler to categorize tasks and put user needs first for more effective project management.
[7:45] - Brian sheds light on the elegant simplicity and balance that Liquid Agility brings to the table, streamlining processes without sacrificing depth.
[10:05] - Arlen delves into the nuances of his prioritization framework, giving a detailed walkthrough of the JUICE framework and its strategic benefits.
[14:30] - Deepen your understanding and work hands-on to practice and understand the craft of being a great product owner by taking a Certified Scrum Product Owner® (CSPO) or Advanced Certified Scrum Product Owner® with Mountain Goat Software. Plus, you’ll be automatically enrolled in Mike Cohn’s Agile Mentors Community, including twelve months of ongoing coaching and support. Find a complete list of our upcoming classes on the Mountain Goat Software's Certified Scrum and Agile Training Schedule.
[24:55] - Arlen outlines effective strategies for teams to evaluate and select the tools that best align with their specific needs and goals.
[27:59] - Arlen explains the essentials of readiness within the dynamic Liquid Agility framework, highlighting what true preparedness looks like in an Agile context.
[31:30] - Brian shares a big thank you to Arlen for joining him on the show.
[33:39] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, such as CSM or CSPO. We also have Advanced Certified ScrumMaster® and Advanced Certified Scrum Product Owner®, where we get right into the good stuff and have some deep discussions. We'd love to see you in one of Mountain Goat Software's classes. You can find the schedule here.
[34:12] - If you liked the episode, share with any product owner you think might benefit from the discussion today, too!
[34:30] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback or a great idea for an episode of the show? Great! Send us an email.
[34:46] - Catch Brian live and in person, and hear him speak at the upcoming 2024 Global Scrum Gathering in New Orleans and the Agile 2024 Conference in Dallas.
References and resources mentioned in the show:
Arlen Bankston
Grow-Lean, LLC
HR and the Agile Organization by Arlen Bankston
Liquid Agility
#3: What Makes a Great Product Owner? With Lance Dacy
#14: What does it mean to be Product-Centric? With Scott Dunn
#50: Exploring the Roles of Scrum Master and Product Owner with Lance Dacy
Certified Scrum Product Owner®
Advanced Certified Scrum Product Owner®
Mountain Goat Software
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast
2024 Global Scrum Gathering
Agile2024
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.
Arlen Bankston is one of the very first Certified Scrum Trainers®, a Scrum veteran, partner at Grow-Lean LLC, author of HR and the Agile Organization, and creator of Liquid Agility. Known for his thought leadership and dynamic, entertaining, and practical training style, Arlen has trained and mentored thousands of ScrumMasters, Product Owners, team members and executives.

#96: Mastering Asynchronous Work with Sumeet Moghe

Join Brian and Sumeet Moghe as they discuss transforming the focus and efficiency of Agile teams in our always-on world. Discover how to master asynchronous work to enhance decision-making and improve team dynamics.
Overview
On this episode of the Agile Mentors Podcast, Brian welcomes Sumeet Moghe, author of the Async First Playbook, in this enlightening episode as he explores the pivotal role of asynchronous work within Agile frameworks.
Sumeet shares his insights on fostering deep focus, enhancing decision-making, and pragmatically adapting Agile practices to meet unique team needs. Delve into the challenges and strategies for securing team buy-in, balancing synchronous with asynchronous tasks, and building cohesion in distributed teams.
This episode is packed with actionable advice on creating a supportive, safe, and productive environment through intentional communication and strategic face-to-face interactions. Tune in to reshape your team's approach to collaboration and productivity in the asynchronous era.
Listen Now to Discover:
[1:15] - Brian welcomes Sumeet Moghe, Transformation Specialist and Product Manager at Thoughtworks and author of The Asynch-First Playbook.
[2:18] - Dive into Sumeet's captivating journey to mastering asynchronous work, exploring how his deep-seated passion sparked innovative approaches in his professional life.
[5:11] - Brian expertly connects Agile principles to the unique challenges of asynchronous work, offering insightful solutions for today’s distributed work environments.
[7:32] - Sumeet unveils critical insights from his extensive experience in asynchronous work, offering valuable lessons for mastering remote collaboration.
[10:57] - Highlighting the challenges that conventional Agile practitioners encounter in asynchronous environments, Brian turns to Sumeet for practical solutions to address these issues constructively.
[16:26] - Are you ready to take your Asynchronous work to the next level? Consider taking Mountain Goat Software’s Advanced Certified ScrumMaster® (ACSM) class to dive deeper into facilitating and thriving with an asynchronous team. To learn more, check out the Mountain Goat Software Certified Scrum and Agile Training Schedule.
[19:28] - Sumeet outlines effective strategies for conducting Sprint Planning sessions with asynchronous teams, ensuring smooth collaboration and productivity across different time zones.
[24:32] - Sumeet addresses team building on asynchronous teams, highlighting and walking through the asynchronous application of the work of Amy Edmonson and Google’s Project Aristotle, developing psychological safety.
[32:52] - To foster deeper trust and reduce conflicts, Sumeet advises using the cost savings from asynchronous work to facilitate in-person team interactions.
[35:20] - Brian shares a big thank you to Sumeet for joining him on the show and bringing his unique experience to the conversation.
[36:10] - If you enjoyed this topic, we invite you to share the episode with a friend or on social media. And don’t forget to subscribe to the Agile Mentors Podcast on your podcast platform of choice.
[37:19] - Do you have feedback or a great idea for an episode of the show? Great! Send us an email.
[36:10] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software.
References and resources mentioned in the show:
Sumeet Moghe
The Asynch-First Playbook by Sumeet Moghe
Thoughtworks
Sumeet's Photography
The Fearless Organization by Amy Edmondson
Advanced Certified ScrumMaster® (ACSM)
Mountain Goat Software Certified Scrum and Agile Training Schedule
Mountain Goat Software
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.
Sumeet Gayathri Moghe is a product manager, and design nerd at Thoughtworks, and author of The Asynch-First Playbook. Sumeet has worked on building software products and improving teams’ engineering effectiveness over diverse environments, building an approach that is versatile and can be effectively adapted across various industries to meet diverse needs. When he’s not at work building software, you’ll find him discovering the world through a camera’s eyepiece, photographing wildlife and wilderness.