Start / Teknik / Agile Mentors Podcast

Agile Mentors Podcast

The Agile Mentors podcast is for agilists of all levels.

144 avsnitt • Längd: 35 min • Veckovis: Onsdag

Om podden

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

The podcast Agile Mentors Podcast is created by Brian Milner and Guests. The podcast and the artwork on this page are embedded on this page using the public podcast feed (RSS).

Avsnitt

#143: What Still Makes Teams Work (and Win) with Jim York

23 april 2025 | 33 min

What does soccer, soda, and software have in common? According to Jim York—everything. In this episode, he and Brian Milner break down what great teamwork really means, why shared goals matter more than job titles, and how understanding your team’s unique contribution can unlock better flow and results.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner sits down with veteran Agile coach and trainer Jim York for a deep dive into what makes real teamwork tick. They unpack what separates a group of coworkers from a high-functioning team, explore the role of shared goals in driving motivation, and walk through value stream thinking using vivid analogies from sports and soda cans alike.

Whether you're part of a Scrum team or leading cross-functional initiatives, this episode will help you think differently about collaboration, flow, and how teams can work better together.

References and resources mentioned in the show:

Jim York
Jim's Blog
Jim's Video Library
Lean Thinking: Banish Waste and Create Wealth in Your Corporation by James Womack & Daniel Jones
Liftoff Vision: Launching Agile Teams and Projects by Diana Larsen & Ainsley Nies
GoatBot
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Jim York is a business owner helping teams discover how to delight their customers. He uses systems thinking, agile and lean to co-create resilient, learning teams. As a coach, he works with his clients to help them grow in directions that matter to them to achieve their goals. Jim is a Certified Agile Coach®️, holding both the Certified Enterprise Coach and Certified Team Coach credentials; Certified Scrum Trainer®️; Agile Fluency®️ facilitator; LeSS Practitioner. In 2007, Jim co-foundered FoxHedge Ltd with his wife, Melissa York.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome in Agile Mentors. We're back here for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have the very distinguished gentleman, Mr. Jim York with us. Welcome in, Jim.

Jim York (00:12)
Well, thank you, Brian. Glad to be here.

Brian Milner (00:15)
Very excited to have Jim with us. We were just chatting before and Jim and I met years ago at a conference. We got introduced by a mutual friend, Mr. Kurt Peterson, who has been on the show. He came on a little bit earlier to talk about Kanban. And just for those people who aren't familiar with Jim, Jim is a co-founder of a company called Fox Hedge. And he has been an Agile coach, a Scrum trainer for quite a while now and I give him the title Luminary, kind of scrum luminary, thought leader, been around doing this for a while. I hope that doesn't sound insulting in any way, Jim, to call you that.

Jim York (00:55)
Nope, nope, just trying to shine my light and help others shine theirs. So that's what a coach does. So.

Brian Milner (01:00)
Awesome, Cool, well, we wanted to have Jim on because we had this topic that it's kind of a broad topic, but it's, I think, actually crucial to today's world. And that's just the broad topic of teamwork itself. So I'll start this way, Jim. I want to get your opinion. In today's world, with the changing kind of landscape with AI and everything else that we see that's kind of influencing how we work, has teamwork had its day? Is it time now for something new or is teamwork still the best way to build things?

Jim York (01:34)
Yeah, well, teams are universal. I think once you get more than one single individual and you get some task that requires more than what one person can do, it's inevitable. We've to work together. And so I don't see that going away. It might change a bit. But in many ways, think the things that we face today are, in many ways, things that we faced before. They might be showing up in a different way, but I think there's some universality. universality to teamwork. Brian Milner (02:03) Yeah, I agree. And so what do we mean by teamwork? Why don't we define that a little bit for everyone?

Jim York (02:09)
Yeah, I guess we have to step back and start looking at what's a team. If we talk about teamwork, there's this whole expression, teamwork makes the teamwork. So what's a team? And the classic definition of a team is it's a group of individuals working on a shared goal. And so it's kind of like built into the definition, we're working on a shared goal. So teamwork is that combined action.

Brian Milner (02:13)
Yeah. Yeah.

Jim York (02:32)
And so that's kind of the general concept. It's, you know, some of the parts, you know, is greater than the whole. And so it's taking that mix of experiences, knowledge, skills, and bringing them together and having that dynamic, that energy, and kind of focusing it in the same direction. You know, that's really what teamwork is about.

Brian Milner (02:55)
Yeah, it's good to clarify it, because I think the word team gets quite widely used in today's world. you'll hear people describe that, hey, that's my sales team. When you look at it and how they actually work together, there's not really a lot of teaming actually happening. It's just a group of individuals who have the same job and that. that format. I do think you're right. It's important to understand the difference between that kind of a team and what we're talking about here as a team.

Jim York (03:25)
Yeah, there are different kinds of teams and people in a sales team, even if they're not working with each other, the fact that they have a shared goal does create some sense of team. And there's different teamwork where everybody's providing kind of their unique thing. And then you have, I think like a team in a rowing, when you have like four people in a rowboat. they might have somebody who's steering the boat, you know, but they have the four people holding onto the oars and, you know, they're working at a similar cadence. You can say to a certain degree they're individuals. I don't know if they're fungible. I don't think they're necessarily fungible, but they're working together to accomplish that shared goal. know, the people in rowing, that's different from people on like a soccer team. You know, on a soccer team, you're... You got the whole pitch, you know, you're all over the place and the ball's moving around and there's this kind of coming together and going apart of various team members interacting at different places and at different times throughout the game. You're kind of acting dynamically to where the ball is and where the opponents are and where they are on the field. And so there's this creativity that occurs there that's kind of a different kind of creativity than you might see in a rowing type of competition.

Brian Milner (04:18)
Yeah.

Jim York (04:42)
But yeah, I think there are different kinds of teams, but I think that universal theme of being a group of individuals that are having that shared goal, I think that's the thing that's in common. It's not the nature of the work that some people might call agile versus predictive or planned work. mean, the concept of a team is more universal thing.

Brian Milner (04:43)
Yeah. Yeah. I like the example of kind of the crew, right? Of rowing and stuff. I think that's a good picture because you're right. I mean, it's very subtle, but there's a lot of combined movement. And if one person is off a little bit, it really affects how others are working. I've used the example sometimes in my classes as a contrast to think about like a golf team. You know, like the idea that you have the group of people who, again, I say this in classes. So anyone listening to this who's a golf expert, it really loves golf. Please, email in and tell me if I'm wrong about this. But this is what I say in my classes. You know, if you're on a golf team, it's a group of individuals who are each shooting their own 18 holes. But then at the end of the round, you just total up the score. And if you have the lowest lower score than another team, then you win, right? But it's, When I'm shooting my 18 holes, I'm not necessarily aware of what everyone else on my team has done or what they're doing at the same time. We don't play off each other, right? I don't take the first shot and then they take the second shot. It's all on me to do my best. And then hopefully everyone else has done their best and we just kind of see how it works out at the very last second. Yeah.

Jim York (06:17)
Yeah, so teams are different. know, teams are definitely different. And I think it's that idea of the shared goal that is the thing that kind of the glue that holds the team together and that shared goal that can be at various levels. I mean, it can be at this grand big picture level. You know, sometimes what's referred to as a product vision, it can be at a more discrete team level. Sometimes that's referred to as, you know, our our unique contribution to the product division. So that would be like our team mission. And then there's maybe, you know, a specific task. And so, you know, we might be working on a specific, very small, discrete task. And, you know, there's a potentially a group of people working on that thing. And, and, and those people have that shared goal of moving that task, you know, through a process to a completion state. And so there's, there's some variability here in the different kind of levels and Hopefully, there's some alignment between those different levels when you're talking about a team.

Brian Milner (07:14)
All right, so there's some different kinds of teams and it kind of is wide ranging in how we would describe it. There's different configurations, but we have a single purpose. We're working together towards a single purpose. That's kind of our unifying factor there. So then what makes teams work? What's the glue other than our purpose? How do we actually... Combine efforts, how do we play off each other's strengths? How does that happen?

Jim York (07:47)
Yeah, well, it depends, right? I mean, that's the classic consultant's answer. It depends. How do we play off of each other? If you're in an environment where you've got a known solution to a known problem and you're just executing steps in a plan, those dynamics are pretty well understood. People in that process can be trained to do different types of activities. They can gain experience in that.

Brian Milner (07:50)
Yeah.

Jim York (08:08)
That's a fairly predictable kind of process, but then there are others where it's emergent. And so we have to kind of figure it out on the fly as we go. And even those environments where it seems that we've got a pre-existing solution, there is a very clear variable there, and that's people. People show up different every day. I might have had a poor night's sleep, and people might think, well, Jim's normally fairly easy to work with, but wow, today he's... got a short temper or whatever it might be. And so we have to of figure out on the fly how we adapt to those variables. anything that has to do with people, you're going to have some variability. think stepping back, Brian, I think one of the things that is important to kind of understand or get a sense of what part of the system that we want to understand when we're talking about a team and they are dynamics, they actually are fitting within some sort of product ecosystem. And so where are the boundaries of what we mean by our shared purpose, our shared vision within that ecosystem? There's a classic book called Lean Thinking by James and Womack. And there's a really interesting example, simple diagram in the book of a value stream. And it's a value stream of a cola can. And it's kind of fascinating. You kind of see this very simple value stream in there and it starts with aluminum being, well, not the aluminum, but the bauxite actually being mined. And it goes through a reduction mill and then to a smelter. And then it goes through some hot rolling and cold rolling process. And so finally you get basically rolls of sheet aluminum that go to a can maker and the can maker is cutting the cans that are then formed into the cola can. You know, and that can maker is actually the middle of the value stream because all the things I've described so far are upstream. Downstream of the can maker, once they've made the cans, the cans go to a can warehouse somewhere and they sit there until a bottler says, hey, we need some cans because somebody's ordered some cola. And so, you know, the cans make their journey to the bottler and they get filled and then they get...

Brian Milner (10:01)
Hmm.

Jim York (10:17)
go to a bottling warehouse and of course there's transportation, there's trucks carrying these empty cans from the can maker to the bottler and then the filled cans from the bottler to the bottler warehouse and then ultimately they go to some wholesale operation and then to a retail store and then you and I perhaps will go into the store and buy a six pack of cola and we go home and we drink the cola. And so you see this very simple kind of journey, this little value stream. from the perspective of the can maker. And so, first time I encountered that value stream, I'm sitting there looking at the can maker and I'm asking myself the classic question that I ask my clients. One of the first questions I ask is, who's your customer? And so for the can maker, it can be very easy to look at that and go, well, it's the bottler because the bottler is the one who places the orders for the cans. So clearly the customer for the can maker is the bottler. Of course from a lean perspective we look further down the stream We were looking at the end of the stream to see you know, what's what's it all for? What's it all for? And if you look at the diagram you get to you know finally to the end of the stream and there's the home where the person's potentially sitting on their couch and enjoying you know that that cola and so you know if you think about all the different steps along the value stream from the mining to the to the smelting to the bottler and

Brian Milner (11:17)
Ha Yeah.

Jim York (11:38)
the can maker themselves, the retail store that's selling the cola. The thing that you would ask them that would be the glue that would hold them together for this would be what Diana Larsson and Ainsley Nees call in their lift off book, the product vision. And so the product vision is really kind of what's it all for? And the cool thing about a product vision is it's very concise, it's very succinct and everybody can hold it in their heads very easily because of that. It's typically one sentence. And so I'm going to speculate this because I'm not a, I'm not part of this value stream where Cola makes its journey to people in their homes. But I'm guessing the product vision for all of these various people along the value stream boils down to something along the lines of our customers enjoy a convenient, refreshing beverage. And so the cool thing about that simple statement is that

Brian Milner (12:23)
Mm-hmm.

Jim York (12:28)
If you were to go to the mine and ask a miner and say, some of this bauxite that you're mining, in the context of this soda, what's it all for? Now, they're probably mining bauxite for a variety of different customers and a variety of different products. But in the context of this particular value stream, they could look down to the end of the stream and say, it's all about that person sitting on their couch at the end of a long day who simply wants to have a convenient, refreshing beverage. And so that's what you know, this particular product vision is. And so that kind of calls into view a couple of things. One is context is important. So when we're talking about the product, we have to be very specific about what it is that we mean, who is that customer at the end of the stream, and what is the experience that we want them to have. And so this product vision is, as I said, very simple. our customers experience a convenient, refreshing beverage. Now, that makes it simple in terms of this particular value stream, but it also makes us aware that it's very complex for the miners because they've got to deal with competing interests from a whole lot of different customers. And so if they've got limited capacity, they may be trying to figure out, which customer do we satisfy? And so the usefulness of the product vision is being able to go to that mining company and say, do you find value in, do you want to support this activity of creating this experience for this customer with convenient refreshing beverage? And if they buy into that, if they agree with that, that's your leverage, that's your argument. why you should deliver against this value stream versus some other value stream. Now, you don't always win that argument, which is really what life is about, is we're always dealing with trade-offs and we're dealing with different options or opportunities. And so I think that's one aspect of this. But when we talk about the team in the context of a product vision, The team is huge. The team is absolutely huge because it's not just a can maker and the can maker team. It's also the bottler and the bottler team. It's maybe the truckers union that's providing transportation between these different things. the retail store. It's the retail warehouse. All of them potentially have their own concept of team. And in order to create value, it's not just what you do and provide to your next partner on the value stream. You have to really pay attention to the entire value stream because ultimately anything that doesn't come together in the right way at the right in the right place right time It puts it all at risk It puts it all at risk. So I think it's important that we kind of understand the product vision this highest level glue that holds us together and then at a more discrete level look at your team, for example the can maker and What is their unique contribution? In Liftoff, Diana Larsson and Ainsley Niece call this the team mission. And so what is the team's unique contribution to the product vision? And so for the can maker, it's also fairly simple. It's like, we make the cans. And they could flavor that a bit with, they use the latest technology and they use environment. sensitive manufacturing processes, know, they source things using sustainable, you know, approaches and the like. at the team mission level, we're getting a little bit more discreet in terms of what it is that that team is contributing to the greater whole. So think part of this is just kind of stepping back and thinking about what it means to be a team.

Brian Milner (16:12)
Hmm.

Jim York (16:24)
You know, are we talking about we're a team that's the collection of all of these things? At times that might be a useful way of thinking about it. At other times we need to kind put our heads down and focus on what our unique contribution is and make sure that we're doing the appropriate job there.

Brian Milner (16:24)
Hmm. Yeah, this is fascinating because so what I'm hearing is that really we have to expand our thinking a little bit about teams because teaming teams are, know, in one sense, the small group that you're working with on a on a regular basis, but it's there's a larger team concept as well of the entire value stream from end to end. All the people who are contributing, they all are are working towards that ultimate goal of, in your example, someone having a refreshing beverage at the end of their long, day at work? And how often do we actually realize that or look at that? Are the miners really even aware of the fact that they're contributing to that sort of a larger team goal? I think that's a great question.

Jim York (17:21)
Yeah, that's an excellent point. And what are the implications of either that awareness or lack of awareness? And I think this kind of comes to play when we think about what motivates teams. If all I know is that I'm mining bauxite, that might work for some folks. That's enough motivation. Sometimes people say my paycheck is enough motivation.

Brian Milner (17:44)
Ha ha.

Jim York (17:45)
But if you really understand what it's all about, that maybe ties into a bit of self-worth, that I'm a contributing member of society. It could also help you make the right decisions and perform the right actions if you know ultimately what this is gonna lead to. And sometimes that's a calculation that's done in terms of the quality. of the work that you're doing or the output that you're creating. For certain applications, the quality might have certain characteristics where the quality has turned up very, very high in some areas or maybe it's lower in other areas because it's good enough. And if you overbuild quality, you might be introducing some waste because it's not. It's not necessary for the job at hand. In other places, if you deliver below quality, you introduce some risk that the product is not going to be, or the ultimate customer experience is not going to be what it is. I don't know about you, but I've occasionally gotten one of these plastic soda bottles where they've made the plastic so thin for the soda bottle that the liquid is actually needed inside the bottle to maintain the structural integrity of the bottle.

Brian Milner (18:54)
Yeah.

Jim York (18:54)
And if I were that customer sitting on the couch at the end of a long hot day, let's imagine it's a white cloth couch and I'm drinking orange soda and I reach over to pick up the soda and my hand, you know, grasping around the soda bottle, all of sudden the soda bottle just collapses in my hand and orange soda goes all over me and the couch and everything else. mean, that's, you know, there's some quality characteristics, some specifications around that.

Brian Milner (19:02)
Ha ha ha.

Jim York (19:18)
container that that plastic container that has to integrate well into the rest of the process. It has to work with the bottler and it has to work with the consumer when they're actually using it. So it's understanding the whole can certainly help teams feel a sense of purpose and also can guide that decision making in those actions around it.

Brian Milner (19:30)
Yeah. Yeah, I think that's an important thing to keep in mind and remember because, you you mentioned, you know, some people would say paycheck is a motivator. And I, you know, I, I kind of subscribe to the Dan Pink kind of motivation philosophy that, know, that, can only do it so far that it is a motivator, but it is a motivator only to a certain point. Beyond that point, we need more. We need more to motivate what we're going to do. Cause you know, there's a million things out there that can give me a paycheck. I could work in a lot of different places, but I've chosen to do what I do for a reason. There's something that fulfills me from doing that, or I prefer it in some way to what my other options might be. I know I've heard people say this in classes before, the idea of how do you have a vision for somebody who builds clothes hangers? We have this talk about vision, this grand design. Big purpose. Well, how do you do that for someone who has clothes hangers? You know, like I get that, you know, there's not everything, every product in the world has, you know, a save the world kind of vision, right? But I think you can, in your example of kind of the mining thing, I think is a good example of this because you can connect it to that ultimate value. And when you connect to that ultimate value, it doesn't that motivate people more to think, hey, I'm helping someone who's had a hard day. I know what that's like. Have a hard day, sit down on your couch and you just want to relax a little bit. Yeah, I want to help that person. Like that, is something that that'll gets me out of bed, you know?

Jim York (21:06)
Mm-hmm. Yeah, and I think that does require you to think beyond what we often think of as being the team. Because to make it all come together and result in that ultimate product vision, that, you know, the person having the convenient refreshing beverage, in my example, you know, all of those different parts have to come together. And any one of them, if it doesn't happen, you know, that we don't have that value that's realized at the end of the value stream. And so having that connection to what it's really ultimately about is critically important. And understanding where you fit into that and what your value add work is, I think is critically important. And so we talked about like at high level product vision, we talked about this unique contribution of your team like the can maker, and so our team mission, we make the cans. And then we get to the practicalities of the task that's in flight, the work that we're doing right now. And I think that's a critical piece of this puzzle. What is it that's the thing that's being acted upon right now? The work in process or the work in flight. And depending on what the nature of that is, I think that drives a lot of... decisions and one of them is around, you know, who do we need? So who are the actual people, you know, that have the right skills, knowledge, experience in order to do that work? And also it informs our process and so, know, again, that process could be something where it's a known process and we're just, you know, turning the crank or it might be something where we're having to figure it out on the fly. Regardless of the nature of the work, there's going to be a workflow. When we're trying to get something done, the work is going to be flowing through some sort of process. And it's that flow that really intrigues me. we want to look at the flow, especially if speed matters. And why would speed matter? Sometimes speed matters because customers want what we are building yesterday. So they want it as soon as possible. So time to value is often what's considered there. If we're something new that hasn't existed before, sometimes we're also building quickly so we can get it in front of someone to get their reaction to see whether it's fit for purpose. So we might think of that as being time to feedback. But the flow itself is there's the workflow. And so work, the nature of it is a piece of work is something that maybe an individual can go work on. Other times there's a piece of work that requires more than one person to work on. So there's an element of collaboration with that. Even when it's an individual that can work on a piece of work, usually they've received something from somebody that allows them to start that piece of work. And when they're done with that piece of work, they're passing what they've done along to somebody else and that other person is picking up. So even if... there's an ability to work on a discrete task by yourself, there's still an interaction often on the front end of that and the back end of that. So work is still flowing and we have to figure out how to collaborate in such a way that the work that is not being held up in some queue somewhere where we're getting some bottlenecks and that they're constraints. so figuring out how do you enable the work to flow and how do you enable the people to flow? Years ago, I had an opportunity to coach soccer and on my team, I taught them, in addition to like skills, I taught them three concepts. And so the first one was, everybody on the team should know where the ball is. And so it seems pretty obvious, you should know where the ball is. But if you look at this from a team building software perspective, does everybody know where the ball is? You know, what is the work that's in flight and what's the current state of that? I mean, we use information radiators to try to help people understand where the ball is, but often I don't think we use them as effectively as we might. So I'm always challenging teams to figure out, you know, how do you use your communication systems, your information radiators to enable everyone in your ecosystem to understand, you know, what's the work in flight and what is its current state? And why do you need to know that?

Brian Milner (24:55)
Hmm. Yeah.

Jim York (25:24)
Well, if you know where the ball is, you can get a sense of what are the things that are in the way of that ball moving forward. So my second rule for the team was know where your obstacles are. And so in a soccer game, you're seeing your opponents. And so you might have a great plan on how you're going to advance the ball from where it is currently down the field towards the goal. But little problem with that. You've got people on the other team trying to keep you from getting there. So you're having to react real time in the moment to those obstacles. And so in addition to everybody on the team knowing where the ball is, everyone on the team needs to know where the obstacles are. And so when you have that information, and again, for a team building software, this is the kind of thing that should be readily available in some sort of information radiator, real time ability to see where the ball is and to see what's in the way. Why is that important? Well, if you know where the ball is and you know where the obstacles are, you can position yourself as a team member to be what I called the help. And so by the help, that's the one or two people on your soccer team that if you're the one with the ball, you know you can pass to them easily. You know, that they are constantly moving around and positioning themselves to be in the place where it's possible for you to get the ball to them. So who are those two people? Well, it changes depending on where the ball is. And so what the team has to do is kind of get a mental mob.

Brian Milner (26:41)
Ha ha.

Jim York (26:47)
in their heads of the actual position of people on the field and get a sense of if the ball's here and the obstacles are here, then I should put myself here. Now, it isn't for all the team members to position themselves to be the help because that would be crazy. Just as we see on Agile teams, when somebody picks up a task, the whole team typically doesn't swarm on that task. It would be too many people on the task.

Brian Milner (27:06)
haha

Jim York (27:16)
So who shows up to work the task? The right number of people with the right skills and knowledge. So how do they know to come? It's because the work is made visible. And so they come because they see that they're needed. How fast do they come? Ideally, they're there instantly. Now, why might they not be there instantly? Because they might be working on some other tasks. And so if this were to happen in soccer game, you would see the other opponent, you know, they would be... basically scoring goals against you right and left because when you try to pass the ball, you wouldn't have somebody there to receive the ball. So knowing where your help is, if you've got the ball and passing it to that person helps you continue the flow down towards the goal. So if you're not the person who has the ball and you're not one of those two people that are the help currently, What you're doing as another team member is you are. orienting yourself on the field so that you will be the help when it's needed. And so there's this constant movement of people down the field. And where this really brings it home, I'll use this example, and I'm coaching agile teams, is they'll talk about how all their work and stuff, and I'll use the example of the soccer game and the one ball, and they say, now let's imagine you put two balls in flight.

Brian Milner (28:16)
Hmm, that makes sense, yeah.

Jim York (28:36)
Can you optimally move those balls down the field towards your opponent's goal? And typically, there is a limit, right? How many balls can you put on the field? Two, three, 15? It's like, yeah, it really drives home the point of limiting the work in process. the teamwork is made more effective and efficient if we have some sense of where the work is, what is the nature of it so that people can come and go, I call this people flow. so we're looking at things like the, well, out of...

Brian Milner (29:05)
Yeah.

Jim York (29:09)
out of the concept of open space, the law of mobility. It's like within our organizations, within our teams, can we have people flow to where the work is needed and also have people flow away from the work when they're not needed? And so enabling that autonomy of the individual to be able to go where they need to go in order to optimize the flow is a...

Brian Milner (29:13)
Yeah, yeah.

Jim York (29:34)
is a key organizational design problem.

Brian Milner (29:37)
Yeah, yeah, this is fascinating stuff. mean, I love the analogy with the soccer teams and that I mean, I, that makes sense to me. I love kind of where you're going with this. If people are hearing this and thinking, well, I like to hear more about this stuff. We're going to put links in our show notes back to Jim's site on this because he's got a lot of blog posts. They're kind of around the same theme on this. And we'll link to those specific blog posts for you so that you can find them. But Jim, I want to be respectful of your time and our listeners' time. So thank you so much for taking your time out to share this with us.

Jim York (30:08)
Well, I've been very pleased to join you, Brian. Thank you for the opportunity.

Brian Milner (30:13)
Absolutely.

#142: Communication Patterns Keeping Your Team Stuck with Marsha Acker

16 april 2025 | 37 min

If your team keeps revisiting the same issues over and over again, Groundhog Day-style, this episode is for you. Leadership coach Marsha Acker shares why it happens, how to recognize hidden conversational patterns, and what to do when you feel stuck.

Overview

In this episode, Brian Milner sits down with executive team coach and author Marsha Acker to unpack one of the most frustrating challenges teams face: circular conversations that never seem to resolve. You know the ones; same issue, different day.

Marsha introduces a practical framework, structural dynamics, to help leaders and Scrum Masters decode what’s actually happening beneath the surface of their team’s conversations. From identifying communication patterns to creating space for dissent and inquiry, they explore how to break out of those conversational loops, build psychological safety, and foster real change.

Whether you're leading meetings or just stuck in too many of them, this episode will help you shift the dynamic for good.

References and resources mentioned in the show:

Marsha Acker
The Art and Science of Facilitation by Marsha Acker
Build Your Model for Leading Change: A guided workbook to catalyze clarity and confidence in leading yourself and others by Marsha Acker
#137: Stop Wasting Time with Guests Kate Megaw
#94: Connecting Teams and Leadership with Anthony Coppedge
Retrospectives Repair Guide
Better Retrospectives
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Marsha Acker is an executive coach, author, and the founder of TeamCatapult, where she helps leadership teams break out of communication ruts and lead real, lasting change. With two decades of experience guiding everyone from startups to Fortune 500s, Marsha specializes in transforming how teams talk, decide, and grow—one conversation at a time.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome back, Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have the honor of having Ms. Marcia Acker with us. So welcome in, Marcia.

Marsha Acker (00:12)
Hi Brian, it's good to be here.

Brian Milner (00:14)
Very very happy to have Marcia with us. Marcia is the CEO of a group called Team Catapult and she is a team coach. She does a lot of work with teams and leaders. She's an author. She's a speaker and we wanted to have her come on because of a book that she has out recently called Build Your Model for Leading Change. She also has another book called The Art and Science of Facilitation, which I'm sure is really appealing to a lot of people here as well. You know, as Scrum Masters, if you're a Scrum Master out there, we do a lot of facilitating. So that's probably a really interesting pickup for you also. But we wanted to have Marsha on because we wanted to talk about an issue that I hear a lot about in classes. This is something that I hear a lot of questions around, and it can be a really big source of issues when you think about working together in close, tight units as a team. And that's how teams communicate. kind of the issues and problems that we have with communication amongst teams. So, you know, when we're talking about this, we're talking about teams not listening to each other, not understanding each other, misunderstanding someone's motives, something like that. And one of the things I know that I've seen a lot, I've encountered this a lot, and this is one of the things that I know you talk about quite a bit in your book, is this kind of loop that we get in a little bit, right? We have these conversations where... It just feels like we're stuck in a loop. We're saying the same things over and over again. it's like, I in Groundhog Day? Am I reliving the same thing we just went through? So let's start there and just say, why do you think that that happens? Why do you think that teams have this kind of Groundhog Day effect where you might have these conversations that just kind of keep popping up over and over again?

Marsha Acker (01:35)
Mm-hmm. It's a great question, Brian. think a number of years ago, I had a background in facilitation, but I got really interested in this particular question because I found not only in my own experience, I had multiple examples that I could give you of conversations that I felt like I'd have with somebody. then we would be, a week or two later, we'd be back talking about the same thing. And I'd think, I, you know, from my perspective, I thought we resolved that. So, so why are we talking about it again? And then I noticed in my work with teams that they would do the same thing. So, you know, I'd be in a session with a team, I'd help them facilitate a decision. They'd make the decision and then I'd be back with them a month later and the same topic would be up. And I'm I just found myself confused. So I think, I think there are many reasons why that happens. But if I were to, If I were to create a theme for that, think there's a couple of big themes that I see play out. I think there are many places on our teams today where we stay at the surface level of the conversation. Like we get super focused on what we're talking about. So whether it's the tool that we're using, the features that are gonna be in the next release, like we get so super focused on it. And then we're hyper. aware of time boxes. So we want to make sure we talk about the thing, get the decision, and we want to do it in 30 minutes or less. I saw a post on LinkedIn the other day where someone was advocating that there shouldn't be any meeting that would need to go past 25 minutes. And I thought, see it really differently because I think while there are places where we absolutely do need to maybe just quickly exchange information or keep things moving along, or we just want to hear briefly from people. I think if we're advocating that every meeting should only take 25 minutes, we are likely going to have those Groundhog Day conversations because it doesn't give us the space to get to the real topic. So I think that's where we spend a lot of time talking about the thing, the topic, and we really don't create enough time to drop down into focus on are we really, there space here for me to share what I really think or do you just want me to show up here in this meeting that you're running? You clearly have maybe your own agenda. You feel like you've already got the decision made. And so you'd really like my role to be to just receive your information and go off and do it. So I think there's a complexity here of

Brian Milner (04:27)
Yeah.

Marsha Acker (04:32)
What's the topic we're talking about? Is it the real topic that we need to talk about? Or is there, is it sort of the mask for what we might be able to drop into a deeper conversation to have? Are we being super focused on a time box? And are we creating enough range in our meetings that we've got spaces where we are efficient and fast and very deliberate about the conversation and then other spaces where, you know, those topics that keep returning. They're great places to go, there's data here for us. I think of them as yellow flags. there's something here for us to explore further. So let's take this topic and let's carve out a little bit more time for it. I'm curious what you see.

Brian Milner (05:15)
Yeah. No, that's a great observation. And I think you're right. It is a frustration. Looking back over my career and looking back through corporate meetings and things I've been a part of, there is frustration with someone who's coming in and not really having a meeting planned and not really having an agenda. But I think there is another kind of side issue there that can cause a lot of misunderstanding about

Marsha Acker (05:33)
Yeah.

Brian Milner (05:44)
what we're trying to achieve and that's the purpose. If we're here for a certain topic, I can understand that, but then what is it that's expected of me in this meeting? Am I here to just receive information? Is this a knowledge dump or a status update from someone else? is this, we have an issue and we need to talk through it and fully understand it.

Marsha Acker (05:47)
Yeah. Mm-hmm. Yeah.

Brian Milner (06:13)
And I think sometimes that's what I've kind of seen is that there's this mismatch of, well, I thought I was here for this. And now it's clear that you don't really want my opinion. You just want to tell me what it is. And so now I'm refocused or the opposite. I thought I was here just to receive information, but now I'm realizing that you really need me to dig in and give you my educated advice on this. Well, I wasn't prepared to do that.

Marsha Acker (06:20)
Yeah. Yeah. Yeah. I think this notion, and I see it happen a lot with Agile teams, like somewhere in our professional careers, and I think there's very good reason for, like we get rewarded for, know, from the time we're in very early school all the way through the end of school, we get rewarded for having answers. And then we end up in the workplace and we find ourselves in collaborative spaces. And so I think there's this belief that, you know, someone who's calling the meeting, they will have a little bit of this internal story that if I come with only questions and no solutions, then what value am I adding? Like that's, how am I useful to this organization? I've actually had people say to me, why would this organization hire me to come in and ask other people questions?

Brian Milner (07:28)
Wow.

Marsha Acker (07:29)
And so I think that's really, I love giving voice to that because I do think that there's a narrative that sits in our organizations that I, and a little bit of a fear. Like if I come to a meeting and I'm asking people to collaborate or I'm truly asking them open ended questions and I want to hear what they have to say and we're going to listen to, you know, I talk a lot about wanting to create this collective intelligence. And I think it takes a while to access that in a group of people. that it requires us to be able to suspend this idea that we're not adding value if we're asking questions and to reframe our value as helping to tap into a collective. And you can certainly have a point of view or a perspective, but if you're really wanting to tap into that intelligence, then I think it requires something different of us if we're the meeting host or the meeting leader. I think the other thing that will happen too is depending on who's in charge, like senior architects or somebody senior in the team can also get caught in that trap. Like, well, I'm supposed to come with answers. And I think we can come with ideas. But if we're really wanting to collaborate, and then this gets to your point about why are we gathering? Because sometimes I think there will be places where somebody has already made the decision and they're not asking for input on the decision.

Brian Milner (08:42)
Yeah.

Marsha Acker (08:50)
but they're wanting to share the decision that's been made and enroll people in the decision that's been made and invite them into collaborating on actually how that's gonna get implemented. But we're not opening this conversation up for what's been decided about architecture, what's been decided about what's going into a release. So I think this clarity and intentionality like you talk about around purpose, why am I here? What do you want from me? It's huge. And I think it's really tied to also some of our thinking about how are we adding value.

Brian Milner (09:23)
Yeah. The comment about, know, people not feeling like they're adding value if they're just asking questions that, kind of, maybe it's just for my recent experience with coaching and everything, but to me that, that just, it's so contrary, you know, to, to my way of thinking now, I guess I would say in that, you know, when I've been a part of discussion, when I've been part of a meeting, that I've looking back, that I feel like has gone really well.

Marsha Acker (09:26) .
Mm-hmm.

Brian Milner (09:48)
Uh, or, or a person that I feel like has really contributed to the meeting. Oftentimes it, it is that person who is asking questions that get us to think in a different way to get us to consider from a different perspective. So, you know, that that's why it feels a little strange to think about it. I agree with you. I agree that that's, you know, the attitude of some people or that's the way they see, you know, how I contribute to a meeting, but it just feels like it's such the opposite of that. That might be the most valuable thing we could do is to get people to see things from a different perspective or consider maybe things they haven't considered about this issue.

Marsha Acker (10:25)
Yeah, I think it's one of the first mindset shifts in a transition from being a contributor to maybe managing or leading, whether it's you're just leading a team or whether you're leading a whole organization. I think this idea of where does value come from and what's my role in the value creation, it's a shift, I think, for us. I love when people can get to a place of thinking about creating containers in organizations where people get to be their best. And then it does, your thinking does shift from, what's the piece of content that I can contribute to? What's the question that would really unlock different perspectives? And I think the other piece about that is what's the question that would elicit a... I talk about it being opposed, but you know, a contrarian perspective or point of view, because I think that's the other thing that can keep us in these circular conversations is when what we're really thinking doesn't get said. So if I don't feel like I can tell you in the room what I'm really thinking, I'll tell everybody else offline.

Brian Milner (11:34)
Right. The meeting after the meeting, right? Yeah. Yeah. And that, course, gets to the heart of psychological safety and kind of those dynamics within a team. We started this off talking about kind of this feeling of getting stuck. And so I want to kind of come back to that a little bit and say, I want to ask you, what are some of the causes of that? Why do we find ourselves trapped in these loops?

Marsha Acker (11:36)
Yes. You Mm.

Brian Milner (11:59)
that just, know, whatever we decide doesn't actually do anything or we find ourselves right back in the same place. Why do these, what's causing this?

Marsha Acker (12:08)
Yeah, well, let's play around with a bit of a framework to help us think about what's happening in the conversation. Yeah. So there is a theory of structural dynamics. It comes from work of David Cantor. And what it allows us to do is sort of think about being able to code the conversation that we're happening. And by code, I mean it helps us focus not on the topic. So whatever the topic might be. It doesn't matter. It helps us focus on how we're engaging in that conversation more of the how. And so there are four actions. Everything that we say could actually be coded into one of four actions, which I think is really kind of fascinating. So you just made a move by taking us back and pointing to the topic about stuck conversations, right? So what keeps us stuck? And that's a move because you're pointing in a direction. So moves kind of set direction in the conversation. I could make a new move and say, you know, let's talk about, yeah, where we might meet at a conference sometime, Brian. But that's a totally different topic. So moves set direction in a conversation. The second action is a follow, which gets behind and supports. So I followed your move by saying, yes, that's great. Let's do that. Here's, and then.

Brian Milner (13:12)
Right. Yeah.

Marsha Acker (13:26)
And then a bit of a new move from me, let me introduce a language for thinking about that. So you made a move, I followed, and then brought in another move. So now we're starting to, by being able to name actions, we're starting to get a sense of patterns. So there's two more actions, the action of a pose. So a pose offers like really clear pushback. It says, no, hang on, stop. Let's not go off the bridge or. I really disagree with this piece about what you're saying. So it offers a clear pushback or constraint to what's been said. And then the fourth action is a bystand. And a bystand is a morally neutral comment that names what's happening in the conversation. So I could bystand on myself in a conversation and say, you know, I'm really feeling engaged by the dialogue, or I might say I'm really confused. or if we're noticing a pattern, somebody might say, I notice we're getting stuck. So a bystand is a way for people to name what's happening or bridge competing ideas. But the other thing, the benefit of the bystand is that sometimes it also slows down the conversation. So to your question about what gets us stuck, it's really helpful if we can separate. what we're talking about and start to briefly look at how we're talking because what gets us stuck in conversations is when one or more of those actions is missing over the course of time. So we need all four of them to be voiced. One of the biggest problems in our stuck conversations is that a pose goes offline. Not in every team. There will be teams for whom a pose is stronger. But in my experience in American business, for sure, a pose is often the thing that is missing or it goes offline. So the way it will play out, there's a couple of different patterns. One will be what we call serial moving. And those are teams. Like a meeting with serial moving will have lots of fast pace. So somebody says this. then we're talking about this topic, now we're talking about this. And it will, like, you'll have a feeling like we accomplished a lot, but then you walk out at the end of the session and you go. So we talked about, exactly, we talked about this, this and this, and I don't know what we decided.

Brian Milner (15:52)
What just happened, right?

Marsha Acker (15:58)
So people that leave those kinds of meetings, they'll have this sort of false sense of, yeah, we got somewhere when we really didn't, we didn't close things out. So serial moving can be a pattern that can keep us stuck because we don't close things. There can be another pattern where there's a lot of move and follow. We call it courteous compliance. Another word for it would just, I forget the other label that we can give to it, but there's the sense that somebody makes a move and everybody else just says, sure, fine. So it's lacking the energy of the dynamics that you would get if the other actions were active and being voiced. And then there's a pattern where we might have too much bystand. So in a team that starts to complain about why did we use this tool or, know, I'm noticing nobody's using Slack or I'm noticing, you know, when we, when something gets posted in Slack, nobody acknowledges it. So if you find yourself in a meeting where, people are sharing a lot of context or perspective, maybe we can, I call it a hall of mirrors. Like we've got lots of perspective, but what's needed is for somebody to really make a move and say, all right, so given that now, what do we want to do about it? So what's really fascinating about those, we can also get locked in a move and a pose, a really strong advocacy or argument. And what's needed in that kind of argument is we need more follow and bystand. But what I find fascinating, so a pattern that I see play out over and over again will be one of two, the serial moving or the courteous compliance. So we've got a lot of moves or we've got move and follow.

Brian Milner (17:25)
Yeah.

Marsha Acker (17:45)
And if I'm someone in the meeting that either doesn't feel like my voice is welcomed or that it would be a career limiting move to oppose you, what I'll do is start to use one of the other actions in place of my oppose. So if it's not okay for me to push back and say, Brian, I don't want to talk about that, or I disagree, I think we're going off track, then what I might start doing is just making new moves.

Brian Milner (18:02)
Hmm.

Marsha Acker (18:15)
So rather than say to you, hey, Brian, I don't want to do that, you'll be talking about something, and now I'm introducing another topic. Hey, can we talk about where we're going for lunch next week? Or can we talk about the meaning behind that word over there that we were using last week? we don't do it intentionally. It comes for really good reason.

Brian Milner (18:36)
Right.

Marsha Acker (18:39)
We will all have our own reasons about why we do or don't do that. But I think some of the greatest work to do in teams is to talk about those four actions, to normalize them, and to invite them.

Brian Milner (18:52)
I love this. what kind of fascinated me, caught my attention the most about what you were saying is when I saw these, and kind of reading up here and reading through your work prior to our discussion, those four modes, when I read it, the first time it seemed to make sense, move, follow, oppose, bystand. But when I saw bystand, it really did seem, my first initial gut response was, yeah. That makes sense. There are bystanders that are happening in meetings that just do nothing. They just kind of sit back and they're not going to be, you know, they're not going to get in the way of the flow of something. But the way you described it is really fascinating because it's not a passive thing. It is an active participation.

Marsha Acker (19:35)
Yeah. Yeah. Yeah. Actually, if somebody is, well, I love that you're naming that because I get asked that question all the time. So again, American business trends. So if you step into the mind of someone who believes that I'm really only adding value if I'm bringing ideas and the way we would code that would be often you're making moves. So people will tend to value. making moves and opposes because a lot of times that's what the culture values. If you're in an organization that says, bring me problems, bring me solutions, you will find a cultural pattern in there of people showing up and making moves and opposes throughout their whole meeting. It'll be a stuck pattern. It'll be overused actions. But if we think about, so bystand could be questions, asking powerful questions. what's that mean to us falls along the line of bringing inquiry into the conversation. And so it gives us a way to balance advocacy and inquiry. But bystand is, bystand and follow are active. If somebody was not saying anything in the conversation, we wouldn't know, we wouldn't be able to code them because they're not speaking. And those four relate to speech acts. So, We have to speak in order for it to be coded as something. But those people who are sitting back often have some of the best bystands. Like if you were to tap that person on the shoulder and say, hey, I would love to know what you see right now in the conversation, they'd probably be able to tell you.

Brian Milner (20:57)
Yeah. Yeah. Yeah. I love this. And, you know, one of the things we teach in our advanced Scrum Masterclass is having people kind of understand how to deal with conflict in their teams and stuff. And we talk about the Thomas Killman kind of five responses to conflict. And I'm seeing a lot of overlap here in these modes too of, some of these things sound like a certain response to conflict in certain ways as well. But before we run out of time, I want to...

Marsha Acker (21:30)
Mm. Yeah.

Brian Milner (21:43)
I want to make sure that we get to, if we're in this situation, what are some steps, what are some things we can do to break that chain and not just have the same conversation again next week.

Marsha Acker (21:48)
Yeah. Yeah. So I would love for people to just think about using those four actions, especially if you work with a team on a fairly frequent basis, right? You will likely, even as I describe those, you will likely start to be able to identify what's the pattern that might be showing up. So I think the first step is can you identify or create a hypothesis for yourself about what might our structural pattern be? So do I hear like really clear poses? You know, do we make a lot of moves? So if you can find the actions that are predominant in your conversation, that's really the first step. And then the second step, there are a couple of different things to counteract each of them. So if move is really strong and it's coming from certain people, designing your facilitated session or even inviting participants to other participants to be the ones to make the move. So inviting others to speak first is one way to do it. limiting the number of moves that people can make. So sometimes if I'm working with a team that has that pattern, I'll give them some kind of, I'll give them a poker chip or I'll give them a card that says move on it. And I will limit everybody to one move per meeting. So structurally, I'm asking people to start to constrain their own moves. And then asking them to then step into, know, if somebody makes a move, staying with it long enough. as, so as a facilitator, you might say, if you noticed that you've got multiple moves on the table, you might just say, Hey, we've got four topics. This, this, this, and this, which is the one that we want to dive into first. So that's another way of just prompting a group to follow a move that they've made. And I think if you're noticing, you don't have a pose. You. chances are that is not going to come naturally. So I think you've really got to design questions that surface it. asking for what are the risks or who sees this differently. A lot of times if I'm leading a session, I will ask people, where did I get it wrong or what do I have wrong?

Brian Milner (23:47)
Yeah.

Marsha Acker (24:12)
What am I missing? What might I not be seen? So those are all ways for me to prompt. And I think if you've got some hierarchy in the room or differentials about that, that's really got to come from the person who's sort of holding some of that positional power maybe.

Brian Milner (24:29)
Yeah, I love that because there's there's sort of a maybe it's an American culture thing. I don't know. But but I know in the business world I've experienced if you call a meeting if it's your meeting there there's sort of an expectation that you're in control, you know, you know, it feels like there's there's sort of a you're not invited to say something like, what am I missing?

Marsha Acker (24:52)
Yeah. Yep.

Brian Milner (24:53)
because that's sort of admitting that you weren't prepared for this meeting. But I agree completely with you, that's not really the case. It's just saying, I can't know everything, so what don't I know about this, I should.

Marsha Acker (25:09)
Yeah. And it's hard. That can be a hard question. And I often say to people, don't ask the question. Don't elicit a pose if you're not really ready to hear it. It can be hard when somebody says, I think it's a two-ee. I totally disagree with the direction that we're going. Because if I, as the person who's asked the question and now receiving that feedback, If it starts to show on my face or I disconnect from it, what's gonna happen is that gets registered across everybody in that room. And that'll be the last time anybody steps up to answer that kind of question.

Brian Milner (25:36)
Right. Yeah, I love as well when you were talking about, you know, the actions and maybe having tokens or stuff for people to have actions. think I don't, I'm sure this is maybe part of the intention of this as well, but I love the side effect of that, that yes, I'm limiting people who would be controlling to not, not take control of the entire meeting, but once they've spent theirs, now I'm in a situation where the people who maybe wouldn't be those people that would normally step up. They're the only ones who have that ability left. So you have that side benefit of I'm kind of making space for the quieter voices in this group to have a chance to speak up. And I think that's a really important thing in these kind of meetings too.

Marsha Acker (26:35)
Yeah, when we find ourselves in stuck patterns, there will be very good reason for, or the Groundhog Day conversation. There will be a pattern to the structure of that conversation that keeps repeating itself. And a lot of times what will be happening is somebody will make a move and very often the person that follows them will be the same person every time. So if Marsha speaks and then Brian follows and that's a pattern that gets set up. every single time. All it does is reinforce me to make more moves because I know you're going to be right behind me. And then over time, we're really unconscious, I think about it, as a structural pattern. But the rest of the team will start to fall back and be like, well, they seem to have it. There's no need. No need. So yes, what we're trying to do is change the behavior by looking at structure and finding ways to invite it.

Brian Milner (27:34)
That's awesome. This is fascinating. I want to be respectful of your time and everyone's time listening, I could go on for another hour in this conversation. This is just really fascinating stuff for me. And I want to point out to everyone again, if this is fascinating to you, we're going to put all the links to this stuff in our show notes so that you can easily just click on that and find it. But just to call it out again.

Marsha Acker (27:41)
You

Brian Milner (27:55)
Marcia has a couple of books out there that are in this topic area that could be really useful to you. One is the art and science of facilitation. And the one that I kind of took a deep dive into is called Build Your Model for Leading Change, which by the way, there's a subtitle of this, a guided workbook to catalyze clarity and confidence and leading yourself and others. And I just, would underline the workbook. Right? Because I think it's true. It is something to kind of work your way through. And it's not just a beach read. Yeah. Yeah.

Marsha Acker (28:27)
No, it's not. I like to think of it as a Sunday morning, maybe with a cup of coffee and a little bit of quiet space.

Brian Milner (28:36)
Yeah, love that. I love that picture. Well, Marsha, I can't thank you enough. You know, we've been kind of trading schedules and trying to align this to get Marsha on for a while. And, you know, when that kind of thing happens, for whatever reason, it always seems to be like, when the person comes on, it's like, wow, that was worth it. I'm really, really glad we went through that because this was a great conversation. So thanks so much. Thanks so much for sharing your research and wisdom here on this.

Marsha Acker (28:56)
I appreciate it.

Brian Milner (29:02)
and for coming on the show.

Marsha Acker (29:04)
Thank you for having me. It was great.

#141: Cooking Up a Killer Retrospective with Brian Milner

9 april 2025 | 30 min

Tired of “What went well?” and “What didn’t”? Brian Milner is here to help you cook up retrospectives that actually get your team thinking, collaborating, and improving. From creative themes to actionable frameworks, this is your behind-the-scenes guide to better retros.

Overview

Do your retrospectives feel more “check-the-box” than game-changing? Brian Milner shares his full recipe for planning and facilitating retrospectives that actually matter.

Whether your team is stuck in repetition, tuning out, or phoning it in, Brian’s step-by-step approach will show you how to bring structure, creativity, and energy back into the room.

Brian walks you through the five essential components of a retrospective, including how to match formats to your team’s personality, align activities with Agile's three pillars (transparency, inspection, and adaptation), and spark meaningful change with every session.

References and resources mentioned in the show:

Stranger Things Retrospective Download
Agile Retrospectives by Esther Derby & Diana Larsen
Retromat
Blog: Overcoming Four Common Problems with Retrospectives by Mike Cohn
Blog: Does a Scrum Team Need a Retrospective Every Sprint? By Mike Cohn
#139 The Retrospective Reset with Cort Sharp
Retrospectives Repair Guide
Better Retrospectives
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Auto-generated Transcript:

Brian Milner (00:00)
Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast, like we always do. And I'm with you as always, Brian Milner. Today we have with us, me, just me. Now, before you get frustrated with that or think we're copping out in some way, this is intentional. I wanted to have an episode to myself because and working through all this stuff around retrospectives, I thought that it might be good to take an episode here. And I kind of thought of it sort of like a cooking episode, right?

Like if you watch a cooking show, you know, Gordon Ramsay show or something, they'll walk you through how they make something. And it's from start to finish. They show you the ingredients. They show you how everything's put together. And then you see this beautiful dish at the end. Well, I've often compared the way that you can format a retrospective to a little bit like a meal, because a meal has different courses in it. And a retrospective should have these themed areas or repeatable sections of it. And so I thought of it a little bit like making a meal.

So I thought I'd just walk you through a little bit step by step. what I'm thinking here and how I would go about doing it. this is, you know, we're cooking up something special here. It's a kind of a recipe here that's, you know, equal parts creative and effective. It's a way to try to keep your retrospectives interesting, but also keep them to be solid and where you can have an actual outcome that comes from this.

And you actually make definitive changes here with your team as a result. So there's a couple of retrospective courses that I have coming out where I go into detail about all these things, but I wanted to take an episode where I could walk you through and just have you kind of peer over my shoulder a little bit about how I might do this if I was going to create a retrospective for a team.

So first starters, I think we have to understand that there is a menu to follow, right? And I kind of use this menu metaphor because one of the great things about when you go out and you have a meal at a nice restaurant is there's a repeatable pattern to it. You kind of expect that they're gonna bring you a drink first and then maybe you have, if it's a really fancy restaurant, maybe you have appetizers first or hors d'oeuvres even before appetizers, then you maybe have appetizers or not. Then you have a main course and maybe you have a salad even before the main course and then you have a a meal, and then you have some kind of a dessert afterwards, maybe even some kind of a cocktail at the end of the meal or coffee at the end of the meal.

But there's sort of a pattern to it. And regardless of what restaurant you go to, you kind of repeat that same pattern. Now, I know that there's times you'll be, this is where the metaphor kind of breaks down a little bit, I get it. You may not have the same pieces every time. And what we're going to be talking about here as a retrospective pattern is that, yes, you should sort of follow the same pattern.

You can't really get to, let's say, dessert. You can't just skip and go to dessert, right? You've got to go through this journey of the other sections so that you can end up at dessert and really fully appreciate it, right, and get the most out of it.

So that's where this metaphor is a little bit of a, starts to break down a little tiny bit. But. I want to talk about here first why retrospectives matter and why they often go stale. I think they often go stale for a lot of reasons, but one of the chief reasons I've encountered when I work with teams is that the Scrum Master on the team really only has a small amount of formats and styles that they have to work with. They have a small little set in their toolbox. And they may even rotate through a few of them. But at the end of the day, it's kind of a small toolbox. There's only a few tools in there. And if I'm a team, if I'm a member of that team, you can imagine how I might get bored.

And I might think this is not really worthwhile if I'm showing up every single time and I'm hearing the same exact questions. What did I do? What do we do well? What do we not do so well? Do I have any roadblocks? If I'm just asked that same thing every time, then I might not feel like this is a very worthwhile thing. Or I might get to the point where I feel like, gosh, I've answered the same question, you know, three sprints in a row. I just, got nothing more for you Scrum Master. I just, I can't dig any deeper.

I've given you everything and it just feels like this is the, you know, groundhog day. We're doing the same thing over and over again, but nothing's really changing. So. I think it's important that we be able to switch things up, but it's not change just for change sake. That's why I think that having a structure of some kind can give you that pattern to fall back on that can make it effective, but then also can provide variety, can make it something that changes over time as you do this with your team. Doesn't mean that you can't ever repeat a format that you've used. I don't think that's a bad thing.

I just wouldn't want to repeat the same, just handful, small little number of them over and over again. That's going to get repetitive and it's going to make people a little frustrated. The other thing is I think you have to match these to the personality of your team. Your team might be more outgoing or they might be more introverted. You might have people who prefer activities or little more, you know, kind of quiet activities or some that are more verbal, you know, require more discussion. That's really an individual thing for your team.

So I think you have to think as you go through this, what's going to work for these people, right? For this set of individuals that I am working with. You know, I always say there's kind of a first commandment for Scrum Masters, know thy team. And I think that's really something that's important for us to grasp onto is we have to know our team. can't coach to the average.

Right? We have to coach to the individual, to what we have on our team, because your team is unique. That set of individuals has never come together anywhere else in the world. Right? Those personalities. And what you want is to find out how to make that set of people work well together. Right? How do they work best together? Not how does every other team in the world work best or how does the average team work best? How does your team work best? Right? So with all of this is sort of setting this and saying that there should be a pattern.

I do want to give the hat tip here and say that the Esther Derby Dinah Larson book on retrospectives is one I strongly recommend. In fact, pretty much my whole career as a trainer, I have said, when people say if there's one book, if I'm to be a Scrum Master, if there's one book that you would say would be really impactful to me from pretty much day one, I have pointed to that book. It's called Agile Retrospectives, Esther Derby, Dinah Larson. And in that book, they lay out a pattern of kind of five phases that go through it.

I'm going to distill it down because to me, it's sort of the three middle ones that are the most important. I will talk about the two on the ends here as well and kind of put that on top of these three. But sometimes I find people find it easier if they just remember what I'm gonna teach you here about the three that are in the middle. So in Scrum Master classes, we will talk often about how there's these three pillars of the Agile process or three pillars of empiricism. Empiricism says that we learn through experience. Well, I always say in class, it's not enough to just do the wrong thing over and over again. I gain a lot of experience by doing the wrong thing over and over, but I don't learn from it.

And the three pillars are what's needed to make sure you learn from them. And I'm sure you've heard these before, but if you haven't, transparency, inspection, adaptation. Those are the three. Transparency meaning we're not going to be clouded about how we do the work. We're going to be very transparent, open about it. We're going to try to reveal how we work best as much as possible. Inspection, that we're going to actually take time and pause and try to figure out not just what happened, that would be transparency, right?

What's the reality of what just happened? But inspecting says, why did this happen? Right? What's the root cause of it? I don't want to just deal with the symptoms, right? If we just try to cure the symptoms over and over again, we still have the same disease, we still have the same illness, and we're not really getting to the root cause.

So inspection says, we're going to take time out to actually get to the root cause. And then adaptation, the last one, is probably the most important step here, because if you figure out what's wrong, but you don't ever do anything about it, well, we're doomed to have the same exact discussion again. So adaptation says, now that you know what the problem is, what are you going to try different? We may not even know exactly what the right thing to do is, but we got to try something. What we know for certain is what we did didn't work.

That's the one thing we absolutely can't do again, is exactly what we did. We've got to try something new so that we move on, right? So that we find out more information and get closer to whatever our final solution is. So transparency, inspection, adaptation, those three actually serve as a good guideline or three phases you can think about for your retrospectives.

There needs to be a transparency phase where you try to figure out what happened this last sprint. there needs to be an inspection phase where now that we know what happened, we got to ask the question, why did it happen? And we need to get to the root cause of why it happened. Now that we know what that is, then we have to move on to adaptation to say, what are we going to do about it? How are we going to take this knowledge we just gained and actually make a change? So we need activities around all three.

And what I'm saying here to you is that can serve as your menu. I can do lots of different activities that would match these three areas. Now, I do, again, want to go back to the Esther Derby, Dinah Larson book, because their five phases adds one on the beginning, one on the end, which I actually do think are very helpful. The first one is kind of opening the retrospective. It's a way of trying to just start to get voices in the room. And this is something I will often do as well. Just a quick, quick exercise to just get people to start talking.

And that's one of the ways you can start to get a quieter group to get involved is throw them something really easy to respond to right out of the gate. And then the last one is to close the retrospective. Closing the retrospective is a great way to then try to sum it all up and say, well, here's the takeaways, here's the things we're going to do about it, and we're going to move forward from here.

Opening the retrospective to that introduction can also then review what you talked about at the end of the last. retrospective. You can say, here are the things that we decided, and let's talk about what's been done about them before you start to inspect the current retrospective. So given that, right, I know I'm going fast here, but you can rewind and listen back to this if you need to.

But if you think about that, that you have these kind of phased approaches, and think of it like a menu, right? There's different courses to my menu. Well, I'm not going to serve the same meal every time. That would be boring. So I got to find out different things I can serve for each course of my retrospective. Now, here's where it gets interesting, right?

Because there are lots of tools out there. And there's a website that I often recommend called RetroMAT. RetroMAT is a great site where you can go to, and it has those five phases. You can kind of scroll through different exercises for each of the five phases. they sort of have, you you can kind of mix and match and create your own menu based off of that.

And doing that is absolutely free. Now they have paid things there as well. They're not a sponsor. I don't get any kickbacks or anything from them. But they have some paid activities as well as far as having things like Mural and Miro templates that you can use if you want to do that as well. So there's lots of things you can do there to thank them for what they put together. But there are times when Maybe you're trying to fit this to your team specifically, or you've grown tired of the exercises that you're used to, and you want to find some new dynamic to add into your retrospective.

So what I'm going to do is kind of walk you through what I would do if I wanted to take some kind of a theme and create a new retrospective that's themed around a certain topic. Now I will say that this theme is gonna go just in one of our sections. So it's not going to go throughout it. I'm not gonna be that creative here with you on it, because I don't think you need to be. I don't think you need to have this, it's not like a theme to party, right? You can just take the theme and use it in one of the sections. So what would I do for something like this?

Well, I'd start with, as I said, some way to kind of open the retrospective. And I like to have little quick activities as I said, that just get voices in the room. an example of things I've done in the past. Ask the team a quick question like, if this last sprint were a song title, what song title would you use to describe this last sprint? And people can use whatever kind of music they like, right? It doesn't matter.

They can just call it any songs that they're familiar with. Or do movie titles. I've had a lot of fun in the past doing that with teams where I'll say, hey, shout out a movie title that might represent this last sprint. You just want to find something quick that people can shout out like one or two word answers, right? Or a small sentence in the case of a song title or movie title or something like that.

But something that they can tie it into, right? And it doesn't have to be anything that makes perfect sense, right? It can be kind of crazy. It can be... You know, if this last sprint were a flavor of Starburst or, you know, an color, what color would it be and why? And just have people, you know, shout out whatever they think the answer would be.

They might have to be a little creative with their answers when they do that. But that's okay. You're just giving them an opportunity to have a few voices start to enter the conversation. Don't force anyone, right? Don't force anyone to shout out, but give them an opportunity to. So I'm going to open the retrospective with some kind of fun, quick exercise like that.

Probably won't take more than five minutes, okay? Then I want to move into that transparency section. And the way I frame transparency is what actually happened this last sprint?

What was the reality of what happened this last sprint? So here's where I'm going to inject a themed kind of approach. And I just, I go through a couple of examples in our courses where I talk about doing this, but I picked a different one here for this podcast episode that I've put together right before this recording to try to walk you through a little bit of how I did this.

So I tried to pick something that was a little more relevant to today. I know that this is popular and people are looking forward to the next season, which is about to come out. sometime soon, I know they've been shooting it, but I picked the theme, Stranger Things. And I just thought, what if my team, you know, had, I knew there were some people on my team really into Stranger Things, or what if I just knew they were aware of it, they knew what it was, and I wanted to have a theme built around this.

So here's how easy it is to do this. I went to chat GPT, and I asked it to give me some, you know, putting together a retrospective that I want to theme it around stranger things. And give me some major themes from Stranger Things that might align to Some different ways of collecting information around what actually happened this last sprint. And. They gave me a long list of different things.

And I read through these and kind of tweaked them, talked back and forth with it a little bit, kind of refined. And I distilled it down to five sort of themes or categories I thought would be fun and would kind of challenge the group to think along different lines of thought. So here's what I came up with with Chat GPT's help. My first category. I called running up that hill.

And what I put for the prompt for this one is what felt like an uphill battle this sprint? Now just think about that, right? In traditional sprints, there's lots of things that are just, I'm essentially asking what was the obstacles?

What were the hurdles in this sprint? But I'm getting them to think about it in little different way by saying, what was an uphill battle in this sprint? And even that subtle rewording, of that prompt can trigger people's brains to work in a different way and get them to think along different lines. If I just ask over and over again, you know, what was a blocker of this sprint or what blockers do we encounter this sprint? If I use those same words over and over, I get sort of immunized against them and I can't really think about anything new.

But just phrasing it that little slightly different way, what felt like an uphill battle this sprint I think can really trigger some new ways of thinking. So that was my first category. The second one that I came up with, big theme here in Stranger Things, was the upside down. And I related it this way to say, what is completely upside down right now?

What is the opposite of what it should be right now? Now here, I'm trying to get them to think about things that are not really going well, right? Things that are going the opposite direction that they should, and it's upside down from what should be the normal. Right? And again, we're just thinking along this theme of stranger things and I'm tricking their brains a little bit into thinking along a different line, right? To examine it from a different point of view. My third category that I thought would be fun was I titled Vecna's Curse.

And what I prompted here for this one was what haunted the team this sprint or kept coming back up to bite us. And The idea here is to get them to think about things that were maybe decisions we wish we had made differently. These could have been decisions in the past. It didn't have to be a decision from this sprint. But what are those things that we felt kind of like was like Vecna's curse?

It was just something that kept rearing its ugly head. And it was just a struggle for us to get around. My fourth one, just to have a little fun. I call the fourth one Surfer Boy Pizza. And what I put as a prompt on this one was, where did we bring the chill? Where did we bring the creative spin to a tough solution during the sprint? So here I'm wanting to celebrate good things, right?

And I'm asking that in a funny way. So it brings some humor to it, puts them in a better mood, and also gets them to think along a maybe a little bit of a different line in this area to think, all right, well, what do we get really creative about? What do we have to be really creative about in this sprint? What kind of tough solutions did we really conquer? Did we really nail in this sprint?

And I'm just theming around that loose theme of that surfer boy pizza from the last season. And then the last one, I couldn't have categories here without mentioning Hellfire Club. So the last one was Hellfire Club. And the prompt I put for it was, where could we bring more of kind of that Hellfire Club vibe, planning, teamwork, shared adventure, right? Just the fun.

Where could we put more of that vibe into our team and to how we operate? Now, this is getting them to think about something that might otherwise be a little bit of a uncomfortable thing to think about, right? Because Now we're getting into interpersonal dynamics. We're getting into how the team actually works and fits together. And that's why I chose this theme, because I wanted it to be just kind of a, even maybe a sneaky back doorway of getting their brains to start to examine, yeah, what would have made this more fun?

Or what would have made this, how could we have, I've asked often in retrospectives, what would it take for us to be the team that everyone else wishes they were on? Well, That's what I'm asking here, essentially. So I've got my five themes. And I even then went forward and created and kind of get some images for each one of those, like icons for each one of those things.

Just created a board and mural for this and put each of those things up. Had a big block space next to each one where people could put Post-it notes. So what I would do here in the retrospective is I'd introduce this. I'd give them the prompts for each of the section and say, all right, let's take a few minutes. Everyone can add Post-its to any of these sections, but try to think through several of them and put several of them up here on the screen or physical board if we're in the same space. But take a few moments here to think through each category and see if there's anything that you can think of that you would add to each area.

So we take, I don't know, five, 10 minutes to do that. normally time that, I just see when it starts to slow down. And there's generally a point there where you can kind of intuitively feel it and feel like, you know, the group's ready to move on. So whenever that time comes, I'll call a halt to it and I'll say, all right, now that we've done this, I want us to try to narrow down what's on the board. So let's give you each three votes.

And I do this usually with dot voting or something along that line. where they have three dots they can place on three different sticky notes across all five categories. And what I tell them is find the three that are the most important of all the things here, what are the three that are most important and put your vote on those top three. And by doing this, having the team vote on it, then we surface the most important three out of the entire group, right? It's not to say we ignore the others, but we're going to try, we can't focus on everything in our time that we have.

So, whether our top three, and then I start with the first one, right? So right now, all we've done is kind of the introduction of the sprint. We've done a transparency section. Now we move into the inspection. Now there's lots of different things you can do here, but what I put together for this retrospective was taking them through sort of a five whys activity.

So I would take that first one, I'd have them examine it and look at it and say, all right, let's ask the question why five times for this one. Why did this happen? whatever they answer, then we say, all right, well, why did that happen then? And we ask why, it doesn't have to technically be five times, but you need to ask it enough to where you get down to something that you can say, yeah, that's definitely the root cause, right? That's what's underneath all this. All that followed it, all that came afterwards was all stuff that came as a result of us making that decision.

So once we have our root cause, we can repeat that again for the other two. if we have time, but if we're starting to run out of time, I kind of watch my time box there. And once I realize we need to move into solutioning, then we'll move on into the adaptation portion. In adaptation, we just take each single one, and we kind of repeat this process of getting possible answers across the team.

So for the number one issue that you guys identified, here's our root cause. Let's take some post-its here. or let's take some suggestions of what we might possibly do to counteract this in the next sprint. So we get those things that come up. Then we'll talk through each one, and we'll try to build consensus as a team as to the most important step to take. So for each item, I want what's the one most important thing to do. So we'll identify that, again, as time allows, I want to at least do the most important thing.

If we have time for more than that, great, we'll get to the second and third. But I think it's so important to just, whatever the biggest, most important thing is, make sure you have an action item for that thing. And here's where I just caution you. It doesn't have to be, hey, we've knocked it out. We've cleared it. We've solved it in the next sprint. It just has to be that we've taken a step towards solving it, right? What's the old phrase, a journey of a thousand miles starts with a single step. Well, the same thing goes for our teams.

And this is oftentimes why teams get stuck, is they just feel paralyzed. Hey, there's nothing we can do about this. It's such a huge issue. Well, that's not true. What's the next step you can take? So take the next step.

Make sure that the team understands what it is. And make sure we understand who is going to be responsible for that. And do that for as many as you can get through. Then get to the closing the retrospective part of it. Kind of wrap up. Remind them, here's the journey we've taken, here's what we've uncovered, and here's what we're gonna do differently for next time.

And now those items, they should go straight into your next sprint backlog, not product backlog, sprint backlog, right? They don't need to be prioritized because the product owner has been with you, they should have been with you in this meeting, it's the entire Scrum team. So the product owner has weighed in as well. This has been a team collective decision. So now those items should go into your sprint backlog, and you should do something about them in this next sprint. That's the whole concept of the Kaizen comes first, right?

The good change should happen before we do anything else so we can get the benefit of it over a longer period of time. So that's kind of the idea here. And I wanted to give you that kind of really quick flyby to help you kind of see how to go about doing something like this, right? And I just picked one theme. I just picked Stranger Things because I thought it would be fun to work on. I thought it would be a fun kind of theme. And it might be fun for a team I was working with. But maybe that's not something that aligns to your team.

Maybe your team has a bunch of people who are really into cricket. Well, do a cricket-themed one. Maybe you have a team that's around the Academy Awards time. And everyone's talking about, and now people don't do this as much anymore, but. Maybe they're all talking about who's going to Oscars this year or something. Well, do an Oscar-themed one. Or it can be around anything. Do it around award shows in general. It doesn't have to be just Oscars, but do it around any kind of award show. And you can pick up different themes.

Again, if you're stuck, ask your favorite large language model and see what it comes up with. It's not all going to be gems that comes from that, but you can pick and choose and refine it, which is exactly what I did with my five themes for this. So I hope you see how easy it is to do that. It doesn't have to be complicated. You don't have to be extremely creative to do this.

You can make use of the tools that you have available to you. And as a Scrum Master, you can keep this fresh. You can tailor this to the team that you have. What is your team really into?

What's the theme that they would really resonate with? Choose that. Go with that. Create a theme around that and see what they think about it. Afterwards, ask them, hey, did this work all right? Did you like this? I hope that's been useful to you. If you like this and you want to hear more like this, come to our website to mountngoatsoftware.com and check out our courses that we're launching actually this week, Better Retrospectives and the Retrospective Repair Guide. Those are the two that we really want to have you kind of think about.

Come to our site, find out more about them. Better Retrospectives is all about just the expert level retrospectives course really gets into the heart of a lot of these issues at a very, very deep level. The retrospectives repair guide is taking the 10 most asked questions that we have about retrospectives at Mountain Goat Software and giving you really deep dives on how to solution those, how to problem solve those top 10 issues. And the great news for you is if you're listening to this in real time, right, when we've launched this, We're launching this as a two-for-one special. We'll not have that special again. So it's $99 that you get both of those courses. You don't have to pick and choose from them. You can give $99.

They're prerecorded. You can watch them at your own pace. This is for people who want this knowledge, who want these answers. And I know when I was a Scrum Master starting out, there was a lot of, I followed a kind of the pattern that Mike established with his sprint repair guide. I bought that when I was coming up as a scrum master because I needed answers to some of the questions that he had in that scrum repair guide. Well, take a look at the 10 that we have for our retrospective repair guide. Maybe you'll find one of those things that's really tripping you up and maybe just getting the answer to one of those is going to be worth the money for you. I encourage you to go to our site, check it out.

Don't miss this. It's a limited time cart that's opened. It's only going to be open for a week. So if you're listening to this when we launch it, don't delay, don't wait until next week. If you hear this next week, then you're running out of time. So make sure that you take advantage of the time that you have here so that you can get these two courses, two for the price of one here at our launch.

Again, we won't do that again. So I hope you found this to be useful. It's just a little taste of the kind of thing that's in those courses for you. And if retrospectives are something that you're struggling with, or if retrospectives are something that you just feel like, man, it really could be more. It really could deliver more for my team. Check out these two courses. I really think they're gonna help a lot of teams out there. That's why we put them together. So that'll wrap it up. I hope you've enjoyed this and we'll talk to you next time. on another episode of the Agile Mentors Podcast.

#140: The Power of Emotional Delight in Product Design with Dr. Nesrine Changuel

2 april 2025 | 36 min

What do Spotify, Google Meet, and your expense report tool have in common? They could all delight your users—if you design for more than just function. In this episode, Dr. Nesrine Changuel breaks down the emotional motivators that transform average products into unforgettable ones.

Overview

What separates a good product from a great one? According to Dr. Nesrine Changuel, it's not just meeting functional needs—it's creating emotional delight. In this episode of the Agile Mentors Podcast, Brian Milner sits down with Nesrine, a former product leader at Google, Spotify, and Microsoft, to explore how emotional connection is the secret sauce behind the world’s most beloved products.

They dive into Nesrine’s “Delight Framework,” reveal how seemingly mundane tools (like time-tracking software or toothbrush apps!) can create joy, and explain why delight isn’t a nice-to-have—it’s a competitive edge. Whether you're a product owner, product manager, or just want to build better user experiences, this episode will change how you think about your backlog forever.

References and resources mentioned in the show:

Dr. Nesrine Changuel
Product Delight by Dr. Nesrine Changuel
Blog: What is a Product? by Mike Cohn
#116: Turning Weird User Actions into Big Wins with Gojko Adzic
#124: How to Avoid Common Product Team Pitfalls with David Pereira
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Dr. Nesrine Changuel is a product coach, advisor, and speaker with over a decade of senior product management experience at Google, Spotify, and Microsoft, where she led major consumer products like Chrome, Meet, Spotify, and Skype. She holds a Master’s in Electrical Engineering and a PhD in Media Processing and Telecommunications and is based in Paris.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome back Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always Brian Milner and today I have a very special guest with me. I have Dr. Nesrine Changuel with me. Welcome in Nesrine.

Nesrine (00:14)
Hi, Brian. Thanks for having me.

Brian Milner (00:16)
I'm very excited to have Nesreen with us. I think this is going to be a really, really great episode for all of you product owners out there or product specialists, anybody who works in the product area. I think you're going to find this really interesting and you're going to want to bookmark this one. Maybe even come back to this a little bit. Nesreen is a coach, a speaker, particularly in the product area. She has previously worked at Google. She's worked at Spotify, at Microsoft, so no stranger to large enterprise, very high profile products that she's worked on in the past. She has a book coming out in May, so look for this book. It's called Product Delight. And that's really what we're going to be focusing on here is the concept of eliciting or generating kind of an emotional response to our product. I guess I'll start by, did you stumble upon this? What drew your interest to people's emotional response to products?

Nesrine (01:19)
Yes, so maybe I can share the story how I came to this topic and how I became so vocal about it. So in addition to being a product manager and leader over the last decade, I was always and I always enjoyed being a speaker. So I always wanted to go on stage and share insight. This is probably coming from my research background, because when I used to be a researcher, I traveled the world to go and present my research work and When I became a product manager, I kept this habit with me. So I always been on stage and I spoke about different topics like product discovery, product operation, different topics. Until one day I got reached out by a conference organizer and he said, Hey, Nisri, we want you on stage, but we have an idea for a topic for you. I'm not that used. Usually I come up with idea myself, but I said, okay, what do want me to talk about? And he said, Hey, Nusreen, you have been working for Spotify, for Microsoft, for Google Chrome and Google Meet, and we all admire those products and we consider them very successful products. What if you come and tell us what's the common thing that probably is there any common thing that made those products successful? Being an insider, being within those company, could you share with us something that you consider in common between those products? To be honest with you, I found it challenging at the same time interesting as an exercise. I was not, by the way, able at that time to answer the question, what's in common? So I sat down and I did the exercise myself and I started to think what was really in common? What made Skype Skype? What made Spotify Spotify and those Google products so successful? And I came to the following conclusion. I found that what made those products so successful is that they don't only solve for functional needs, but they also solve for emotional needs. So when we use a particular product, we use it for a certain functional need, but we also use it for an emotional need. And without even knowing that I have been doing it for more than 12 years, I came to the conclusion that, my God, during all those years, I have been focusing so much into users need from both angle, functional and emotional. So I came on stage and I spoke about that topic and from that day, I started to give it a name. I'm calling it emotional connection. I'm calling it product delight. And I'm here to share more about it as well.

Brian Milner (03:50)
That's awesome, yeah. I mean, I think we do hear a lot and we focus a lot on that functional kind of need, the way you differentiate there. think that's a good differentiation, functional and emotional kind of needs or motivators there. yeah, I mean, I've always heard, know, kind of that kind of general product advice is, you know, find the things that... people really, really have as huge needs, the things they would pay someone to do for them. And that's the key to success is finding those huge needs. But we're actually going beyond that to say, yeah, those are important. It's not to say that we should skip that, but it's when there's the emotional connection to a feature or to something that we do that really the light bulb kind of comes on for our customers. Is that kind of what your research is leading to?

Nesrine (04:40)
you're getting it right. Don't get me wrong. Of course you have to honor the functional needs and serve the functional feature, but the delight or the emotional connection happens when you go beyond exactly how you said it. Let me explain. If you serve only functional needs, you know what you get? You get satisfied users because they are asking for something and they are satisfied about what they are receiving. Now,

Brian Milner (04:41)
Okay, okay. Haha.

Nesrine (05:05)
If you surprise them by going beyond, by anticipating their need, by exceeding their expectation, you're not only satisfying them, you're surprising them in a positive way and delight is the combination of surprise and joy. Actually, the theoretical definition of delight is a combination of two emotions, surprise and joy. So going beyond, anticipate need and exceed expectation. is what we should aim for in addition to the functional needs.

Brian Milner (05:35)
That's awesome. Yeah, I use this example sometimes in, we use this example in the agile world to talk about, you know, the part of the agile manifesto that says customer collaboration over contract negotiation. And, you know, there's an example I use from my past where I used to work at a company that was very contract driven. And, you know, the thing that I always used to kind of take away from that was the very best we could ever do or hope to do. was to meet our customers' expectations. We could never, ever exceed it because we were only doing exactly what they told us to do. So I think this is a really important distinction here to make that just meeting the customer's needs, just meeting the minimal customer satisfaction bar, that's not going to keep you with loyal customers. That's not going to have repeat customers, or they're not going to tell their friends about, you know. That product did exactly what I hoped it would do. But it didn't really surprise me. It didn't really go beyond that. I know you talked about, because I've read your blog and a little bit of the discussion about this. So I know you talk about in the blog kind of the connection to Kano analysis. And I've always thought that's a really great way to try to determine things to target and go after. So talk to us a little bit about that, about Kano analysis and kind of what that uncovers and how that connects to what your research has shown.

Nesrine (06:51)
Yes. I love Kano by the way. I, I mean, that's one of the framework I have been considering throughout most of my product career. But this framework comes with a limitation and let me explain. So first of all, for those who are not very familiar with Kano, Kano is a visualization or categorization, let's call it. It's a categorization framework that allows to categorize features among different categories. One of them is must have. So these are the things that absolutely have to be in the product. Other that are performances, which are the more you have, the more satisfied users are, the less they less satisfied they are. And of course there are the delighters and delighters are those feature that when they are in the product, users are surprisingly happy. And when they are not, are not even the satisfaction is not even impacted. So the limitation of Kano is that it doesn't tell you how to achieve delight. Let me explain. I think we live in a world that everyone agree that we should delight our users. I mean, this, this concept is now globalized and everyone is talking about delighting users. The issue is that we don't know how to delight them. So we know category, there's a category that called delight, but we don't know how to. So the, the framework that I'm introducing and I'm calling it the delight framework is the framework that allows to first identify. So it's usually, represented into three steps. The first step is to start by identifying the emotional and functional motivators. So let me give you an example. I've been working at Spotify for about four years and as a Spotify user, imagine yourself, you are a Spotify user. You do have, of course, functional motivators. What could be the functional motivators? Listening to music, listening to podcasts, maybe listening to an audiobook. So all those are functional motivators. Now, what could be the emotional motivators as a Spotify user? It could be feeling less lonely. It could be feeling more productive because when you're working you need to listen to something. It could be about changing your mood. It could be about feeling connected. So all those are emotional motivators that drive users to use a product like Spotify. So what I encourage every product manager or every product team to do at first is to dig into identifying, of course, the functional need. And everyone is good, by the way, in identifying the functional needs. But also, while doing that exercise, pay attention to what could be the emotional motivators. So that's step number one is about listing the functional and the emotional motivators. Once you have those, Now we get to the second part of the framework, which is look at your backlog. And I guess you have a very busy backlog and take those features one by one and see for this particular feature, which motivator am I solving for among the functional ones and among the emotional ones as well. So the delight grid, for example, is a visualization tool that I came and created in order to allow product teams to visualize their backlog and see how many of my features are only solving for functional motivators. In that case, we call that category low delight. How many of my features are only solving for emotional motivators? These are very rare, but the best example I would call is, for example, I'm having an Apple watch and one month ago it was New Year Eve and at midnight I get fireworks popping out of my

Brian Milner (10:35)
Ha

Nesrine (10:36)
Apple watch and it was a happy new year there's nothing functional in there but it's all about creating some smile I call this surface delight and then how many of your features are solving for both functional and emotional motivators and I call this deep delight so maybe I deviated a bit from your question compared to canoe but it's actually about adding this dimension of connecting features to the real motivators of the users.

Brian Milner (11:07)
No, maybe a little bit, but you connected it to where we end up going anyway. So I think that's a great connection there. And by the way, for anyone listening, we'll link to all of this so that you can find this and follow up. But I like that differentiation between surface delight and deep delight. I know some of the examples that I've heard used kind of frequently in looking at Kano analysis and kind of trying to find those delighters. And that is kind of the area that it specifies there in Canoe, right? You're trying to find those things that are not expected, but when people find that they're there, they like that it's there, but they don't expect it's there. So if it's not there, there's no negative response that it's not there, but there's a positive response if it's there because they like seeing it. And my boss, Mike Cohn, tells this story about this

Nesrine (11:59)
Yes.

Brian Milner (12:03)
There's a hotel in California that became famous because at the pool, they have a phone that's by the pool that's the Popsicle Hotline. And you can pick up the phone and you can order a Popsicle to be brought to the pool. And it's the kind of thing where you're not going to go search for a hotel. Does this hotel have a Popsicle Hotline? I'm only going to stay at hotels with Popsicle Hotlines. It's not that kind of a normal feature. It's a delight feature because when you see it and you find out it's there, it's like, that's really cool. And it can be the kind of thing that says, yeah, I want to search that hotel out again next time I'm in this area because I really thought that was a nice little attention to detail and it was fun. But I think what I'm hearing from you is that might be more of what we would classify as a surface delight. It's not really meeting a deep need.

Nesrine (12:35)
Yes.

Brian Milner (12:56)
But it's fun, it's exciting, it's not expected, but it doesn't really cross that threshold into, but it also meets kind of functional delights. Is that kind of what you're saying there? Okay. Okay.

Nesrine (13:08)
Yes, actually I heard about that hotel story just to tell you how much viral it went. It came to me. So actually you get it correct that I consider that as surface delight and I have nothing against by the way, surface delight. You can add surface delight. The issue is you can end up doing only surface delight and that's not enough. So the idea is to do a combination and I do have two stories to share with you just to compliment on this hotel story. One is personal and one is professional. Brian Milner (13:21) Yeah. Okay.

Nesrine (13:37)
The personal one just happened to me a month ago. I went to Sweden and I went to Stockholm. That's where I worked for eight years. And I went there for business and I decided to meet some friends and some ex-colleagues. So we all gathered and went to a restaurant, a very nice restaurant in Sweden. And came the time where we had to say goodbye and to pay. And I guess you can feel it immediately when it's about paying and we are a large group and you start to get that anxiety about who's paying what and what did I order? What did I drink? What? I mean, I honestly hate that moment, especially in a large group where you don't necessarily have a lot of affinity with us. Like, should we split in 10? Should we pay each one paying its piece anyway? So that was a moment of frustration, of anxiety.

Brian Milner (14:09)
right. Yeah.

Nesrine (14:28)
And I loved how the restaurant solved it for it. You know how they solve for it? I mean, maybe it exists in the U.S., but for me, that's something I never seen before. The waiter came with a QR code on a piece of paper and you scan the QR code. And when you scan your QR code, you get the list of items that got purchased by the table. And all you have is to pick, and that happens automatically real time. Everyone is picking at the same time. You pick the things from the list and you pay. for the things that you order. You can even tip on the bottom. You can give feedback. Everything happened on that QR code. And you can guess how much that anxiety could be removed. So that's the personal story I wanted to share. The second story, which is more professional, I want to share how we try to improve experience at Google Chrome. So I've been the product manager at Google Chrome.

Brian Milner (15:13)
Yeah.

Nesrine (15:25)
And we started from the observation that people do have plenty of open tabs. I guess you are one of them, especially on mobile. Like on mobile, you go and check how many open tabs you do have on Chrome and you realize that they are have, we realized at least out of numbers, out of data that people do have plenty of open tabs. So it started as

Brian Milner (15:32)
You

Nesrine (15:47)
technical issue. Of course, the more tab you have, the heavier the app is, the slower the app could be, et cetera. So we wanted to reduce the number of unnecessary open tabs in Chrome. So we interviewed users and we started to check with them, why do they even leave their tabs open? So some of them leave tabs because they consider them as a reminder. I mean, if tab is open, it means that you need to finish a task there. Some people really leave tabs just for ignorance. mean, they moved from a tab to another and they completely forget about them. Actually, we realized that the fact of leaving tab open, the reason for leaving tab could be completely different from a person to another. And the other interesting observation, and when I say identify emotional motivators, you will realize that people feel a bit ashamed when they show to us that they do have plenty of open tabs. Some of them would say, sorry, I usually don't even have so many open tabs. It's only now. And I'm like, it's okay. But the point is, if you have this mindset of trying to track the emotional insight from your users, you will take note. And the note was anxiety, feeling ashamed, blah, blah, blah, blah, blah. And that was in introduction for in...

Brian Milner (16:42)
You Yeah, right.

Nesrine (17:04)
improving the tab management experience later on in Chrome.

Brian Milner (17:07)
That's actually a really good parallel, though. I think that's a good example because it reminds me, too, even going back, I remember one of the things, and I'm going way back here, but I remember one of the things about Gmail that was kind of a selling point initially was the concept there of you don't have to worry about maintaining an inbox. keep all your mails and search. And you can search through your mails and find whatever it is. And I remember prior to that, most people would use something like Outlook or something like that to have their mail, there was always this constant struggle of, I've got to keep it down. I've got to delete things. I've got to categorize things. And Google had this different approach of, don't worry about it. Just leave it. And that's a good, I think, example as well of kind of that emotional response of,

Nesrine (17:48)
Yes.

Brian Milner (17:56)
Gosh, I'm kind of anxious. I feel bad that my inbox is so big. And I know that's bad, but Google comes along and says, don't worry about it. You're not bad. It's OK. Yeah.

Nesrine (18:05)
Yeah, yeah. And by the way, I think Gmail is filled with plenty of deep delight features. One of them I can quickly highlight is, you know, when you send an email, we're saying attached file and the file is not there. And when you try to hit send, you get that pop up like a be careful or like a mind, there is no attached file inside. These are for me like very attached to the fact that You don't want to feel ashamed. You don't want to look stupid later on saying, Hey, sorry, I forgot the file. Here's the file. That's, that's a great example. And the other example that come to mind again in Gmail, you know, that smart compose when you're trying to answer an email and you can just hit tab, tab, tab to complete the sentence. I mean, the functional need is to write an email. The emotional need is to get it in a relaxed way. And the combination would allow for something like.

Brian Milner (18:49)
Yeah.

Nesrine (19:00)
Smart Compose.

Brian Milner (19:01)
That's awesome. Yeah, so I guess that leads to the question though, when we're talking about something like Spotify, mean, music intrinsically is emotional anyway, right? It's something that you have an emotional connection to and you feel a certain way when you hear music. But if my product is a, I don't know, expense reporting software, right?

Nesrine (19:23)
Mm-hmm.

Brian Milner (19:25)
I can just hear people out there kind of asking, know, and kind of thinking to themselves, yeah, but my product, right, my product is not that kind of, it doesn't elicit that kind of emotional response in people the same way music would. So does this apply to me as well? So how would you answer those people who feel like my products might be a little bit more bland or boring and don't really intrinsically have an emotional connection to them?

Nesrine (19:47)
Mm-hmm. So my answer is that if your product is boring, then it's even more priority now to focus on emotional connection. But let me elaborate. So that's one of the reflections that came to my mind while writing the book. So while writing the book, I wanted the book to be a storytelling book. So I was writing a lot of my stories, stories from Skype at the time, Spotify and all the Google product. But at some point I said, hey, hey, Nisreen, you need to get more insight from other people and other experiences. So I get to interview product leaders from completely different industries and completely different domain. I interviewed leaders from B2B like Atlassian or Intuit and so many other companies that I don't have so much insight from. I even interviewed people from hardware, like I interviewed someone from Dyson and I was, hey, what makes Dyson so emotionally attractive for me? Cause I love my Dyson vacuum cleaner. But let me get to your point because when I interviewed someone from Intuit, that person told me something super interesting. She told me that at some point she was working at a tool called Tsheet. And Tsheet is a tool that allows you to enter your time report. There is nothing more boring than that. I think I'm picking the one that you're looking for here because it's, it's as a user. The only reason I would use this tool is to report my time so I can get paid.

Brian Milner (21:06)
Hmm. Right. Yeah.

Nesrine (21:19)
There is nothing exciting, nothing emotional. And what I got out of that product leader who used to be the head of product at the time, she told me that they were completely aware about the fact that the product is not that attractive. And instead of living with that observation, they did all what they could do to make it even more attractive. So they added some fun. They made the messaging less aggressive and less about enter your time. report but rather into more playful and even the images are more playful. When you press the enter time report you get the congratulation and some confetti if needed. So they explicitly turned and that's a strategy. They turned that boring moment into something even more attractive and they had to do that otherwise the experience will keep on becoming more more boring and the perception of users toward the product will be even less, more and more gray, I would say.

Brian Milner (22:22)
Yeah, yeah, just that little dopamine kind of kick, right? Just that little bit of chemical reaction in your brain can make a huge difference. That's awesome. That's a great story and a great answer to that question. So I'm curious, we're talking about trying to find these things and trying to see, your matrix here, it thinks about the emotional motivators, the functional motivators, and trying to find those things that kind of cross both planes.

Nesrine (22:24)
Yep.

Brian Milner (22:52)
How do you verify at the end? Because if you're lining your features up and think, I think this solves this emotional thing. I think this solves this functional thing. Is there a way to follow up to ensure that it actually is doing that? How do you follow up to make sure it's really doing what you thought it would do?

Nesrine (23:09)
Yes, so let's imagine you did the exercise well, you filled in the delight grade and you observed that you do have plenty of low delights, which is most of the cases by the way. The very first thing I recommend is to see opportunities for moving or transforming these features into deep delight. And in the book, for example, I talk about the nine delighters. Nine delighters are ways that could be sometimes cheap even to introduce. in order to make those low delight features into more deep delight. This could be, for example, through personalization. We love when the features are personalized, and that's one of the reasons, for example, why Spotify is so successful, is through features like Discover Weekly or RAPT or these kinds of super personalization related features. It could be through seasonality. That's, for me, the cheapest and the most delightful feature you can or aspect of feature you can add to your product. So for example, when I worked at Google Meet, I've been working at the background replace features. So we have been, of course, introducing static image. We have been introducing video backgrounds as well. But from time to time, we always use seasonality to introduce what we call seasonal background. So when it's Easter, we introduce Easter background. When it's Christmas, we introduce Christmas background. Guess what? Even like for Olympic game, we introduce Olympic game background. When it's the Earth Day, we introduced Earth Day background. So there is always an opportunity to introduce some seasonality to the product. And guess what? We relate to those, especially if the product is global. We relate like last, when was it? Like last Wednesday. It was the new year, the Chinese new year. And I was checking when is exactly the exact date for the new year, the Chinese new day. And I put that and you know what happened in Chrome? It got these dragons and those like the celebration within the product, like within Chrome. These of course are surface delight, but you know what? Why not? You see? So there are some tools. Some of them are not that...

Brian Milner (25:17)
Right.

Nesrine (25:22)
expensive to introduce to the product. Some would require a bit more thoughtful and thought into it, but there are ways that I detail in the book in order to introduce more delight. And then if you want to validate through metrics, and I guess that's your question where it's heading to, then the good news, and that's something that I discovered recently because there's been a study that was conducted by McKinsey. And you know what they studied? They studied the impact of emotional connection on product adoption. So they actually studied over, I don't know how many industries die, like tourism, IT, energy, whatever. And they interviewed more than 100,000 users or whatever. So the conclusion that they found out of that very interesting study is that emotionally connected users will get you more twice as more revenue, twice as more referral, and twice as more retention compared to satisfied users. I'm not talking about the non-satisfied. So if you take two groups of users, those that you satisfy their needs and those that you go beyond and they are emotionally connected, those that are emotionally connected get you twice revenue, referral and retention.

Brian Milner (26:19)
Hmm.

Nesrine (26:43)
So this is just to highlight that for people who say, no, but this is the cherry on the top. This is just like the extra. It's not the extra, it's the way to stand out. I don't know any company that is standing out nowadays without investing into emotional connection, none.

Brian Milner (26:54)
Yeah. That's a really good point. Yeah, I mean, the example that comes to my mind when you talked about seasonality and other things like that, know, I love my, you know, they're not a sponsor, Oral-B toothbrush, you know, the electronic toothbrush, and you know, there's an app with it and it keeps track of, you know, did you get all the areas of your teeth and did you hold it there long enough and... One of the things I always love about it is when it gets to December, the opening screen when you open up the app starts having snowfall. It's kind of a funny little emotional response, but you look at that and you think, that's cool. Yeah, it is kind of that season where now it's time to get ready for Christmas and it's that special. It's only this month that it's going to be like that. It's going to go away at the end of the month.

Nesrine (27:45)
Yes.

Brian Milner (27:49)
feel little sad when it's gone, it's back to normal. But it's such a silly little thing. Does that make any difference in really brushing my teeth at all? Does it change how well I brush my Not really. It's just a fun little thing that when it pops up there. And think how little that took from someone to do that. It's a little animation that they just pop up on a loading screen. But that little tiny bit, think, again, maybe a little bit surface.

Nesrine (28:10)
Yes.

Brian Milner (28:16)
but it takes something that would have been routine. It takes something that would have been kind of boring otherwise, and it just added a little bit of fun to it, you know? And I think you're right, that emotional connection is really, really important in situations like that, yeah.

Nesrine (28:21)
Yes. Yes. Yes, yeah. And the thing that I'm very vocal about nowadays is the fact that this emotional connection is actually not a new topic. It's something that has been extremely popular among marketers. For example, if you think about the best marketing campaign, they are all very emotional. The most successful marketing campaign are. If you think about designers, there are plenty of resources about emotional design. There is a great book by Don Norman. It was called emotional design. Aaron Walter as well wrote something called Designing for Emotion. But you know, the problem is that among engineers and among product manager, we don't talk that much about that. And you know what happened when we are not informed about this topic? There is a gap between the language of marketers, designers, and the engineers and product manager. And that gap doesn't allow things to succeed. I'm trying to educate the engineers and the product world towards this well-known domain outside of the product in order to have this consistency and start making real impactful products.

Brian Milner (29:40)
Yeah, yeah, this is such a really deep topic and it just encourages me, think, even more to recommend the book there. It's not out yet, time of this recording it's not out, but it's going to be in May of 2025. That's when this book is coming out. And I know it's gonna have a lot of really good information in it. Again, the book is gonna be called Product Delight. by Nesrine Changuel, Dr. Nesrine Changuel. I should make sure I say that. But I really appreciate you coming on because this is fascinating stuff. And I think the product managers, the product owners that are listening here are going to find this really fascinating. So I appreciate you sharing your time and your insights with us, Nesrine.

Nesrine (30:26)
Thank you, it's my pleasure. I love talking about this topic.

Brian Milner (30:29)
Ha

#139: The Retrospective Reset with Cort Sharp

26 mars 2025 | 40 min

Retrospectives shouldn’t suck the energy out of your team—or get skipped entirely. In this episode, Brian and Cort share how to fix the most common retro fails and announce two brand-new tools to help you run retros that actually work.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner and Cort Sharp break down why retrospectives are more than just a “Scrum box to check.” They’re the powerhouse behind continuous team improvement. From battling retro fatigue and quiet-room energy to creating psychologically safe environments and tying retrospectives to real results, they cover it all.

Plus, Brian reveals the launch of two new on-demand courses—Better Retrospectives and The Retrospectives Repair Guide—designed to help teams stop skipping and start optimizing their retros. Whether you're a Scrum Master, coach, or facilitator, this episode is your practical guide to making retrospectives worth everyone’s time again.

References and resources mentioned in the show:

Cort Sharp
Blog: Retrospectives With a Quiet Team
Blog: Does a Scrum Team Need a Retrospective Every Sprint
Mike Cohn’s Better User Stories Course
Scrum Repair Guide
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Cort Sharp is the Scrum Master of the producing team and the Agile Mentors Community Manager. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome in Agile Mentors. Welcome back for another episode of Agile Mentors podcast. I'm with you as always, Brian Milner, but today we're gonna have a continuation of something we tried, a little experiment we tried a few weeks back here. I've got Mr. Court Sharp back with us. Welcome back in court.

Cort Sharp (00:18)
Hey, Brian, thanks for having me on again. I had lot of fun last time I was on here and it was a great discussion. So thanks for bringing me back.

Brian Milner (00:21)
Yeah. Yeah, it's, oh, absolutely. Yeah, know, got a lot of people said, hey, we kind of like that court guy. Kind of like hearing from court. So we wanted to have court back, you know, because you guys told us that you liked him. And we also wanted to have him back because we just thought this format kind of worked for various reasons. And last time we kind of hit on some things that were kind of more hot button issues of the day. things that have been flowing through social media or other things around Agile. But we wanted to have a little bit more of a focus for today's episode. And we're going to focus really on the topic of retrospectives. And maybe make a little announcement here along the way as we go along. But we're actually going to switch roles here a little bit. I'm going to kind of pass the ball over to Court. And I'm going let Court drive this, just like he did in the last episode. Ball's in your court. Ha ha, get it?

Cort Sharp (01:18)
Ha ha, court, there you go. Well thanks, Brian. Once again, I love coming on here, I love chatting with you. And like you said, yeah, we're gonna be talking about retrospectives today, mostly because I have been struggling with answering questions about retrospectives. I think this is one of the more common meetings within Scrum that just gets skipped over, just people don't find value in it.

Brian Milner (01:42)
Yeah.

Cort Sharp (01:43)
or people just struggle with understanding why we have retrospectives. And sometimes I get a little slipped up and I struggle with answering the questions about why do we do this? So can you give me some clarification? Why do we have retrospectives? Why do they matter?

Brian Milner (01:58)
Yeah. Yeah. I mean, it's a great question. And I think everyone should, should, you know, want to know that answer. If you're doing this, you one of things I say in class all the time is, you know, it's important to know the purpose behind the meetings that we have in scrum. If you don't know the purpose, then, you know, that, how are we gonna, how are we gonna have a successful meeting? How are we gonna get the most out of it? so yeah, it's, it's a funny kind of meeting, because all the other meetings and scrum are, are really, around one ultimate purpose and that's building the increment. This is not, right? This is sort of a timeout. It's an intentional kind of timeout to step away and say, all right, now that we've done that, how did it go? What kind of happened along the way? I think it's a vitally important meeting. And when I hear people sometimes say, is it okay to skip it or should we do it once ever so often? you know, again, I try to be pragmatic and say, you know, I don't, I don't know any possible situation out there, but, you know, I would tell you, I would advise you not to, I don't think that's the right path to go. I know scrum doesn't teach to do that. I think it's really, really important because it is that, that moment of let's pause for a little bit. Let's figure out what we need to do differently and then let's actually take a step to do it. There's actually an interesting little background for this. So I'm going to take a little side trip here. Retrospectives actually come from an idea that has been around for a while that actually started kind of in lean manufacturing, some of the things that came out of Japan. There was actually a phrase that they would use on the assembly line at the auto assembly plants there in Japan. They referred to this concept of Kaizen. Kaizen was kind of a, I don't speak Japanese, but what I understand is the word loosely kind of translates to good change. And they had this concept there on the assembly line floor that anyone who was on the floor had access to the big red button that could stop the entire thing. They could stop the entire assembly line, which you know, on an auto assembly plant, that's a huge deal to stop the entire production. And they were very deliberate about it and said, no, we want everyone to have access to that because the phrase they use was the Kaizen comes first. And what they instructed the employees was if you along the way, as you're doing your job, if you see something that we could change that would make it more efficient, that would be a better way of doing this, then we want you to hit the red button because we want to implement whatever that change is as soon as possible. The sooner we implement the change, the longer we have as a benefit, like an investment. The earlier I invest, the more I get as a return. So the same thing here, the earlier I invest in this good change, the longer I have to have a return from it. So that phrase, the Kaizen comes first, is sort of a central thing that we think about here with retrospectives. It's identifying those good changes. there's actually even an intention behind it that it doesn't go on the product backlog. It goes in the next sprint backlog. Because we don't want to have any even inkling of deprioritizing something that comes out of a retrospective. It's that Kaizen portion. So we want to make sure that comes first. So yeah, it absolutely is going to go into the next sprint. Whatever we decide is the most important thing, we're going to make an impact on it in the next sprint. So that's why I think that it's the most important thing for us is it's the engine that really drives continual improvement. And without it, I think teams stagnate. I think they just get kind of stuck in a rut. problems that we have, we just continually repeat. if we don't have the time to stop an exam.

Cort Sharp (06:00)
Yeah. All right. So I kind of got one bigger idea from there. And for whatever reason, when you were like, we gave everyone the red button to stop the assembly line. And that's kind of, we're stopping, we're pausing, we're inspecting, and then we're going to come up with a plan to adapt. Whatever reason, this phrase stuck in my head, it just popped out to me. But it sounds like we're giving power to the people.

Brian Milner (06:06)
Okay.

Cort Sharp (06:26)
where we're, you know, the team has the power, the people have the power to say, whoa, let's stop here. Let's hang on a second. Let's take some time and let's figure out a better way to move forward. And from that, I just think of sports. I think of sports teams. We're in the middle of March Madness as we're recording this right now. And I can pretty much guarantee you that every single one of those teams who's advancing on past, I think round one is going on right now, so passing on through round one, they're probably watching some film on their opponents. They're trying to see, what are they gonna do? What are some plays? How can we kind of counteract it? But more often than not, I would wager, I'm not a gambling man, but I'd wager, that they're looking at their own film and they're trying to see what did we do well in this game that got us the win? What can we improve? so that we could maybe have a little bit more of a bigger margin of victory. And what is it that we should probably stop doing? What is there that wasn't working out? Maybe our pick and rolls were not good, maybe we weren't executing well on those, or not to get too into basketball terms there, but maybe we should stop shooting so many threes or something like that. I don't know, right? But yeah, that's, yeah.

Brian Milner (07:42)
I think you're right. I think you're absolutely right that, you know, sometimes we think this retrospective thing is maybe, is this just a weird thing that we do in software development? No, this happens in a lot of professions. There's a lot of different professions out there that take time to analyze. And by the way, I'll throw this out there as well, because you mentioned kind of sports. Sometimes people will, I've encountered teams at times that think, You know what, we're good enough. We don't need to do this anymore. This is really only for teams when they're starting. We don't need to have retrospectives once we've become mature. Well, to them, I'd say, well, then why do championship teams continue to watch their film? Right? If a team won the Super Bowl last year, don't you think that they still go through training camp and get ready for the season? Yeah, they absolutely do. But they're on top of their game. So if they think it's necessary when they're on top of their game, is there really a moment that we would be so on top of our game that we have nothing left to learn and get better at? I'd say no. I think that there's always something that we can get better at. And I think that's a great analogy to kind of drive that home.

Cort Sharp (08:54)
Yeah, awesome. I totally agree with you there. Even just outside of the team sports world, I come from a more individual sport background. And it's so important to take some time and just reflect on, how did I perform? How was my performance, even on an individual level, so that I can take some action steps throughout this next period of training or work or whatever it is that I'm doing so that I can make the next next performance or the next time I race or the next time I get out there on the court or on the field or whatever. That's how I can make that next time better than this last time. So awesome. Thanks for clarifying. Thanks for.

Brian Milner (09:28)
Yeah. Well, yeah, yeah, no, no, it's a great question. I think this is, probably time for us to kind of let the cat out of the bag here a little bit and just say, one of the reasons we wanted to focus on it for the episode is, drum roll, we kind of have a couple of courses coming out. here that we're going to offer at Mountain Goat Software that you can take around retrospectives. They're on demand videos that I worked on. They're two different separate courses. And we just thought this was an area that really needed some focus and attention and we were getting lots of questions around it. So we always try to listen to what you guys are telling us. And what we were hearing was, this is where you wanted us to focus. yeah, not a lot of details that I'm going to say right out of the gate. But yeah, we do want to kind of announce that those are coming here very, very soon.

Cort Sharp (10:22)
Yeah, so if I heard you right, I think you said this, but there's two courses coming out, right? Okay, cool. We're letting that out of the bag.

Brian Milner (10:28)
That's correct, yeah, two. right, right. I mean, you might think, one course I can understand, but two? Yeah, there's so much material that there was too much for one. And people could not consume all that in one go. And so we created two and kind of found different aims, different goals for both of them. to target what people were really asking for. So yeah, there are two separate courses. One that's going to be called Better Retrospectives, and another one that's called Retrospectives Repair Guide. So yeah, you can sell just from the names, kind of taking two different approaches here on focusing on retros.

Cort Sharp (11:07)
That's so awesome to hear that we have two separate types of courses that solve kind of two problems. So what were the reasons why you decided or Mountain Goat decided, hey, we probably need to make these to help solve some pain points. What were those pain points and what are these common struggles that you're seeing?

Brian Milner (11:19)
Yeah. Yeah, completely fair question, right? I mean, why didn't we do one on sprint planning? Or why didn't we do one on daily scrums or whatever, right? Well, maybe we will in the future. I think the kind of genesis of this idea or why we decided to focus on it was we periodically survey users. We watch what people do when they come to the site, what they search for. And one of our top search terms and one of the top search areas that we've seen over the years, really, it's been consistent, is around retrospectives. So we know that's an area people want to know more about and want to get help with. So that gave us the first little inkling that this might be something to focus on. That led us to doing just a free open webinar that we did. I hosted that, I put together a presentation to give some tips around it and help people, just a short little presentation, but wanted to just give some really quick tips people could apply. And we had over a thousand people sign up for that. not, I shouldn't say that. We had over a thousand people attend that. just, lots of people sign up and don't come, but. We had over thousand people who showed up and attended to hear that. And that kind of blew us away. think, wow, this is really, know, people made time in their day to come and listen to this, you know, short little webinar on it. There's interest here. And with a thousand people, we didn't have nearly enough time there on that webinar to answer everyone's questions and get through everything that was coming at us. But, you know, we love data. So. We pulled all that data from all the questions that had been submitted and people had presented to us and grouped them, categorized them, tried to sort them through and try to find what's the biggest kind of pressure, pain points that people are having that they wanna know answers to. And that's what led us to really create these courses is there were reoccurring themes, right? There was a kind of set of things that are common amongst people. common issues, common problems that people are having, common root causes of those problems. And we just thought, this is doable. It's not an impossible thing to fix. There are actually practical, real ways of solving these things. And we wanted to give people solutions to the things they wanted to hear about. So that's why we decided to focus on retrospectives.

Cort Sharp (13:50)
Awesome, sweet. That's still crazy to hear. I knew that you had a thousand people or a little over a thousand people attend that live stream, I think is what you did, right? Because it was like a YouTube live stream or something like that. That's still mind blowing to me that there was that much turnout and...

Brian Milner (14:09)
Actually, I just wanna say, I don't know that it actually even was on YouTube. That's what makes it even more kind of impressive to me is people had to like get a link and go into it. So it wasn't just, hey, I'm flipping through YouTube on my lunch break and it turned up. It was people who deliberately said, no, I'm making an appointment to go to that. Yeah.

Cort Sharp (14:29)
Man, that's even, yeah, that's crazier to me too. That's awesome. That tells me, yeah, there's a ton of demand for this, right? So can you give me just a brief overview without oversharing or sharing a little too much about what each course kind of offers and what problems they're working to solve or we're solving within each course?

Brian Milner (14:31)
Yeah. Sure. Yeah, I guess it's probably important to know the strategy of both of them and why there's two. As I said, there's just a lot of material, so it was too much to fit into one. But I tried to follow the pattern in creating these that we've established at Mountain Goat with previous classes. So the first one that I put together, we titled Better Retrospectives. And that's following the pattern that we've done with other things like better user stories. So better retrospectives, the focus is sort of the expert deep dive on retrospectives. We go deep on the meaning behind things and kind of facilitation techniques that are useful to do, patterns you can use in creating a retrospective, ways you can create brand new. themes for your retrospective that no one's ever done before in the past because it's yours. It's something you created on your own. And just kind of all the ins and outs of how to really make a retrospective work and be productive, produce things that actually make differences on your team. So that was better retrospectives. But we wanted to then address head on those most common questions that people have. Again, try to follow the pattern that we've established with some previous things here at Mountain Goat. Mike has a course that I took years ago called Scrum Repair Guide. And it was about the most common problems that Scrum teams have. so I follow that pattern here. And the second course is called Retrospective's Repair Guide. And what we did was we took those highest volume asked questions, the most common questions we got from that webinar. got just the top 10 and said, these are the biggies. These are the big ones that people are asking about that really want to know the answer to. And we put together a repair guide course for it so that people can maybe consume that in a little bit different way. If I'm having one big problem right now and I need an answer to that, or maybe I have two or three problems, I'm not having all the problems, but I need an answer. I need help with this big thing that's going on with my team. We wanted to get that to them as soon as possible. So the retrospective repair guide is that ability for someone to look at our list of top 10 questions. And you'll probably find three or four of them on there that you'd say, oh, yeah, that's one I've experienced. Yeah, that's one we're having right now. And then you can just kind of to the chase and get right to where it is that you need to get help. And then practically go and make those changes immediately. So better retrospectives. The expert course, Deep Dive on Retrospectives, makes you an expert at delivering them and working with them. Retrospectives Repair Guide, more for those finding the solutions to the problems you're having right now.

Cort Sharp (17:37)
Awesome. I want to kind of double click a little bit into the retrospective repair guide. Man, tongue twister, right? The retro repair guide. Can you share just like one or two, maybe three of those questions that are answered or some of those bigger questions that were asked that are answered and that you give a solution to and a very clear solution to within that course?

Brian Milner (17:43)
Yeah, it is a little. Yeah. Yeah. Yeah, absolutely. just know for each one of these, it's not a, the answer is, here's a sentence. Each one of these, we go really deep on how to answer that and strategies. And I give you multiple things that you can do. Because a lot of these maybe even have multiple root causes to them that could be causing them. And there could be something different you might need to do to solve that for your team. But you know, Like one of the biggest questions that we heard, probably the most popular question that we got was, how do you handle retrospectives when you have a quiet team? When you have a team of people that are a little more introverted or shy, not uncommon with a group of software developers. So how do you get them a little bit out of their shell or how do you get them to just feel safe enough there to actually contribute? That was a big one. Um, you know, a big one for our, our day and age is how do you handle retrospectives when you have people that are remote? Uh, you know, do you have an entirely remote team? Do you have people that are, uh, you know, parked your team? Part of your team is, is in-house part of your team is remote. Uh, how do you, how do you handle that split? Um, that was another big one. Um, you know, how do you handle it when you're, you have a team that just hates retrospectives? Um, you know, how do you, how do you, uh, How do you get your team to start really making progress, real progress, from the things that you talk about in your retrospectives? So these are just a couple of them. we really thought that these, for each one of them, as I went through each one of them, I thought, yeah, this is a big one. This is one I get questions about all the time in class. So there was none of them that I looked at and thought, this is a filler. Am I going to make it to 10? No, mean, it was hard to limit it to 10, you know? But yeah, we limited it to 10 and all of them are really, really important ones.

Cort Sharp (19:47)
You Yeah, nothing but heavy hitters here. Nothing but bangers. Here you go. Yeah, that's it. Awesome. OK, well, thanks for the overview. Thanks for introducing these courses. That last question there, what do I do? How do I manage a team within my retrospectives when they hate going to retrospectives or despise that? That'd be super useful for me. Man, I might buy this course right now.

Brian Milner (19:55)
Yeah, yeah. Yeah. Ha Yeah.

Cort Sharp (20:23)
But I would like to, we strive to have some pragmatic approaches. We strive to provide practical, immediately useful tips on this podcast. I know that's a big point for this podcast that you really work on and you really focus on. Do you have any just practical, immediately useful tips? Let's start out, I guess. This might be a little teaser, a little preview. You might repeat something that you gave out into the Retro's course there, the Retro Repair Guide. With quiet teams, can you just share something that I can immediately take away and go off if I have a really quiet team and it's like pulling teeth to get them to talk and participate in Retro's? Can you give me just some useful tips or something that I can go away with?

Brian Milner (21:08)
Yeah.

Cort Sharp (21:13)
after listening to this episode and go off and use with my team to help my quiet team be a little more active and a little more beneficial. Show them that, this retro is for you. What can I do to work with my quiet team here?

Brian Milner (21:29)
Yeah, yeah, no, mean, how can I tease the number one thing without giving any kind of advice on it, right? And no, I mean, we're doing this because we want to get this information out route. We want to help teams to be successful with this. So no, I don't mind at all going into some things that might help there on it. There'll be much more in the course because I just have more time to do that. I think that the number one thing when you have a quiet team is trying to understand the why behind it. So for starters, I think it's important for us to understand that there are different personality types. I mentioned things like introvertedness. There are people who are more introverted than others. And if that's a of a spectrum in itself. There are people who are extremely introverted, and there's people who are only mildly introverted. Not to mention, one of my favorite topics, thinking about kind of different neurodivergent traits and how they interact and participate and things of that nature. So all that's to say, that I think the number one thing that we have to do is know our team. We have to understand who is in the room. Because I think we make the mistake a lot of the times of, I'm gonna just put together a retrospective. Let me go find out what that guy on YouTube said about doing a retrospective. yeah, that was a fun little theme that he came up with. Let me go put that in place. But that may not match at all. the personality of your team. It may not match the way that they prefer to interact. If I have a team full of introverts, I'm not gonna do a big role play kind of exercise in my retrospectives, because everyone's gonna be uncomfortable and everyone's gonna shut down. They're gonna go into defensive kind of stance, right? So I think that's the number one thing I'd say is, first of all, just understand and respect. respect the differences there in personalities to understand that they're not broken or in need of repair in any way. If they are quieter, that's just who they are. That's just how they're made. So I think that's part of it, right? I think part is that you have to understand your team. But there are other possible root causes here as well. One of the biggest is they could be quiet because they don't feel safe to actually speak in that room. That's a huge one, right? And it's so important. If they come into that room and they are fearful that what they say in that room is going to be reported outside the room to someone else, or they're going to be made fun of in that room for voicing their opinion or belittled in some way for it, well, That's a killer to a retrospective. If there's not that sense of safety in the room, doesn't matter how brilliant your pattern is for the retrospective or what great idea you came up with for it. If I don't feel like this is a safe space where I can speak up and not be made fun of or not fear retribution for something I've said, I'm not gonna speak up. whether I'm an extrovert or an introvert. It doesn't really matter my personality type at that point because the fear is what's driving everyone in that room. So I think you have to maybe even gauge the team. Maybe even ask them in an anonymous poll. I've done this before by just giving slips of paper and everyone puts in a hat. And you can do something like a safety check where you say, give me a number from one to five. five being the highest and one being the lowest, how safe do you feel today in this room to speak honestly without fear of retribution or being made fun of, that sort of thing? And it could very much surprise you what the answer is. That's actually an activity that I repeat periodically when I have a team because I want to chart it. I want to see where they are now. I want to see if it goes up or down. If there's some kind of a change, how does that affect it? We had, we lost a team member or two team members and we had new people come on. Safety is going to drop because we have new people. God forbid if we have somebody who's an outsider who insists on coming into it. I try my best to keep them out, but hey, if my boss says, well, I'm overruling you, I'm coming in. Well, are you gonna quit immediately because that happens? Probably not. What can you do? Make it transparent, the effect. You can say, hey, we periodically take these safety checks. So here today, I took another safety check. Our normal average is 4.2. Today, it dropped to 2.1. Why do you think that happened? It's data. So I think safety is another big reason.

Cort Sharp (26:13)
Right. Right.

Brian Milner (26:18)
So let's, personality type, gotta understand personality type, gotta make sure the environment's safe. And by the way, kind of corollary to that is not only that it's safe, but that their opinion matters. So if they speak up and say things and no one pays attention to them, no one listens to them, well again, you're telling them your idea doesn't matter, learn this lesson, next time don't speak up, right?

Cort Sharp (26:30)
Mm-hmm.

Brian Milner (26:44)
So they've got to have a safe space. And then I think you've got to match your activities to your team. You've got to find ways of connecting to them that will feel comfortable for them, that make them feel. I say this all the time in classes, facilitation, the root word in facilitation is facilis. It's a Latin word. means to make easy. So we're facilitating a retrospective. Make it easy. If your team doesn't want to role play, and you've got an activity that's a role play thing, then that's not easy. That's difficult for who they are. But if your team, another kind of difference, are they verbal processors? Do they need to talk things out to find a solution? Or do they need quiet space? that they need introspective time to find solutions. If that's the case, well, maybe I start with something like quiet writing. I don't even have an activity where they're talking to each other at the beginning. So I think that's third thing I'd throw out there is to say, Once you know your team, make sure you are matching the format, matching what you come up with for that retrospective to the personality of your team. It's hard, right? Someone can't walk in off the street and deliver a great retrospective to a team they don't know. But the good news is you know your team, right? You work with them all the time. You're the expert on this.

Cort Sharp (28:08)
you Yeah, yeah, as a more introverted person, nothing sounds worse to me than trying to, to do any kind of role playing, putting myself in some position that I just don't normally put myself into and I'm not comfortable with right that that is not my jam. That is not my thing.

Brian Milner (28:27)
Yeah. Yeah, and can you blame it when, if that happens, can you blame the team for saying they hate the retrospectives and that they don't want to do them anymore? Yeah.

Cort Sharp (28:39)
No, not at all. Not at all. If my scrum master came to me and said, right, we're going to, Brian, you're acting as this person, Court, you're acting as this, and we're going to reenact little Romeo and Juliet, bring that into there in this. And it's like, what? No, this isn't valuable.

Brian Milner (28:47)
You Right. Yeah, it's one thing to say, we're going to pretend to be each other and talk through. But it's another thing to say, pretend you are a peanut. you're like, that kind of thing. When you're an employee, you're like, god, really? I have to be a peanut now? Great, great. Yeah, no, this is fun. It's that kind of thing that if you don't, maybe your team would enjoy that kind of thing. If so, then match it to them.

Cort Sharp (29:10)
Yeah. Yeah.

Brian Milner (29:19)
They're not in that mode. No, no, no, no, no, no.

Cort Sharp (29:23)
Yep. Well, awesome. think I have a couple more questions for you here. Should be relatively quickly, right? Thanks for giving a little preview and giving some practical advice for what we can do to help our more quiet teams. But I want to take a step back. I know we double clicked into that one course, but I just want to take a step back a little bit. how do I decide which courses is right for me?

Brian Milner (29:28)
Yeah, yeah. Yeah.

Cort Sharp (29:48)
Do you have any guidelines for that? Any advice for if I'm interested in both courses, but I don't know which one would be a little more beneficial for me? How do I make that choice?

Brian Milner (29:58)
Yeah, that would be an extremely difficult decision to make because you have to really know these courses intimately, think, to make that, or maybe not intimately, but you probably have to dive a little bit deeper into what the agenda is for each one to kind of know the answer. But here's the good thing. When we're launching these, I can tell you this as well. We're going to be launching it as sort of a two for one. So. The good news is when we, know, for the initial launch of this, that's going to be the bonus for being in the first group is you don't have to decide. You'll get them both and you can then, you know, choose on your own. can dip in and see, you know, if one's better for you than the other, great. But you can consume it any way you want. And, you know, I'm just really excited for people to get to see the stuff and to hear it. I think there's some. there's some stuff that's really gonna help people in it.

Cort Sharp (30:47)
Awesome, great. Helping my decision fatigue there, Brian. That's great. Wonderful. One less choice that I have to make. Well, great. Awesome. That's kind all the questions that I have for you. Are there any kind of key takeaways or anything that you want to single out about retrospectives as a whole or anything about these courses that are going to be offered here anytime soon or anything like that?

Brian Milner (30:50)
Yeah, exactly. Exactly. Yeah, I wanted to do this kind of an episode about this because, you know, I feel like the listeners here to our podcast, you guys know me, you know, the kind of stuff that I talk about. And, you know, I wanted you to be the ones who kind of heard this and knew about it first. I think it's going to be really beneficial and it's going to really kind of turbo charge a lot of teams. We talked about why retrospectives are important. Well, as I said, it's the engine for that continual improvement. If you don't have it, then the team stagnates. If you do have it and they buy in and this is, they're really all in on that Kaizen continual. improvement, know, Kaizen comes first mindset that kind of comes along with it. Then they look forward to this meeting. It's not just, know, something to check the box at the very end of our sprint, but it's actually, you know, when are we going to have that retrospective? I've got some stuff I want to talk about and that's our time now. You know, we can shut out the rest of the world. We can shut out, you know, everyone who's not here in our team. And now we can focus on us. You know, the question I often ask the teams when I do this is, do retrospectives is, what would it take for us to be the team everyone else wishes they were on? And, you know, that's really what you can accomplish through a retrospective is you can be that team, everyone else in the group and the organization looks at and goes, man, I wish I was on that team. That team's the, that team looks like a great team to be on. You know, I know there's, we're not given a lot of details here because this isn't We're not opening sales to this at the time that you hear this, when this podcast comes out. This is just a preview. I wanted to announce it here in the podcast first and let you guys know about it. Stay tuned. We're gonna have some stuff coming out soon. You can come to our website, mountaingoatsoftware.com and you'll find more information about this. But stay tuned here to the podcast as well. We're going to talk about some other things around podcasts in the next few weeks. we'll let you know when it's going to be open. I'll tell you as well, this is going to be a limited time thing. It's not something that we're launching and then kind of keeping open forever. This is something that we're going to launch. And there's a window for you to actually purchase this. receive both these at the same time. We'll talk about pricing and all that other stuff later down the road. But I just wanted you guys to know that these two things were coming. And hopefully, that gets you excited. And you can start now saying, hey, boss, there's something I'm going to be asking you for here for the training budget or something somewhere along the way. So stay tuned. We'll have more information here about it in the coming weeks.

Cort Sharp (33:51)
Yeah So we're starting the hype train now. Hype train is starting to pull out of the station. And the next station it comes into, it's only going to be there for a limited time. So make sure you get on board and get on with this. Because these sound like really awesome classes. And they sound like a really great way to either elevate where you're at already or where I'm at already for retrospectives and whatever techniques I'm using. I know we didn't talk much or really at all.

Brian Milner (34:01)
Yeah, exactly.

Cort Sharp (34:26)
other than the title of the Better Retrospectives course. But having been through the Better User Stories course, that really elevated my ability to write and facilitate user story work or story writing workshops. But it allowed me to be more effective on the user stories front. if it's anything following that trend line, which it sounds like it kind of is, that Better Retrospectives course sounds like a fantastic way to elevate.

Brian Milner (34:46)
Yeah.

Cort Sharp (34:53)
my ability to not only facilitate, but also just get more value out of retrospectives. And then the retro repair guide. Awesome starting point. Sounds like it's a great spot if I'm struggling with anything. Really, really common. Well, not really common. The biggest questions, biggest problems that are seen throughout retrospectives. Great starting point in order to. help myself grow and get up there. And the fact that I don't have to choose between the two, that's fantastic to me. makes me really excited.

Brian Milner (35:25)
Yeah. Bonus, right? Yeah. Well, and I do want to throw out there as well. know, the pattern here, I'm copying Mike, right? This is what Mike Kona has done previously. And I'm with you, Court. When I took the Better User Stories course, you know, I really wanted to go deep on user stories. I wanted to understand them at a level that I just didn't previously. And I wanted to know the ins and outs. I was ready to go deep on it. And I agree with you. did the same thing for me. It helped me to really fully understand kind of what this method is and how to get the most out of it. So that was my idea when I wanted to copy that into the retrospectives. I wanted the same thing. I wanted people who were at that point where they're ready to go deep. Here it is, right? It's ready for you. And retrospectives, the repair guide as well, I was a consumer of Mike's Scrum Repair Guide before I joined Mountain Goats, you know, when I was a Scrum Master on a team. And I remember when I saw that course and I saw the list of things that, you know, he was going to talk about in that course. There were two or three of them on that list that I just said, yeah, star that one, star this one, like that. I need that answer. I just remember that feeling of, I really need the answer to this. So my thought at that time was, whatever this is, It's worth it because I don't know how to do this on my team right now. We're having this problem and I need it fixed. So I need guidance on how to do this. And I know there's people out there that are gonna feel that way about some of these topics they're gonna see that we have in the repair guide. So all that's just to say, it's from the point of view of someone who benefited from that pattern, you know, from Mike and other courses. And I'm hopefully going to be able to do that for people here with retrospectives as well.

Cort Sharp (37:15)
Well, I'm excited. So a couple action points for anyone else who's interested in this. Stay tuned, right? Stay tuned for future episodes on the podcast. Keep an eye out on stuff. Can they visit mountainghostsoftware.com right now and sign up for a list or anything or get any pre-emails or anything like that or not quite yet?

Brian Milner (37:33)
I don't think there's anything that you can do at the moment. mean, if you're on our email list, I think that's probably the best thing you can do. You sign up for our email list. You can do that pretty easily at mountandgoatsoftware.com. And that'll keep you informed when we send out our newsletters. We're gonna have information on it there as well. But it's kind of like, you you get those emails sometimes that just say nothing right now, but, so nothing right now, but, you know, kind of just... File this away, know this is, you in the next few weeks, you're gonna hear more about this and then it'll be that limited window that you can actually, you know, take advantage of it.

Cort Sharp (38:07)
Awesome. Yeah, so keep listening in, keep an eye out, and we'll keep giving you some practical approaches, practical tips that you can use to go into your next retrospective. Maybe your team isn't the quiet team, but maybe they're the ones that just don't really like retros. know, Brian, thanks for helping me out with my quiet teams, or any time that I interact with quiet teams, and even the ones that are a little more just passive and don't.

Brian Milner (38:28)
Nah.

Cort Sharp (38:34)
don't really see the value in retros. Thanks for sharing those tips and for helping me out with all the teams that I work with. So I appreciate that. Thank you.

Brian Milner (38:42)
Yeah, absolutely. If you can't tell, I'm really excited about it. I can't wait for people to start diving into this stuff. more than anything, I can't wait for it to start to make a difference in teams.

Cort Sharp (38:53)
I'm excited, Brian. I can't wait. I'm stoked.

Brian Milner (38:54)
you

#138: The Bad Meeting Hangover with Julie Chickering

19 mars 2025 | 39 min

Ever left a meeting feeling more drained than before it started? That’s the dreaded meeting hangover. Brian Milner and Julie Chickering dive into why bad meetings have lasting effects—and what facilitators AND participants can do to make them better.

Overview

Bad meetings don’t just waste time, they drain energy, morale, and engagement long after they’re over.

In this episode of the Agile Mentors Podcast, Brian and Julie Chickering unpack the concept of "meeting hangovers"—the lingering negative effects of ineffective meetings. They explore why bad meetings happen, the shared responsibility of facilitators and participants, and practical strategies for turning the tide. From fostering accountability to knowing when to walk it off, this conversation will help you rethink how meetings impact team dynamics and productivity.

References and resources mentioned in the show:

Julie Chickering
#137 Stop Wasting Time with Guests Kate Megaw
HBR The Hidden Toll of Meeting Hangovers by Brent N. Reed, et al.
When: The Scientific Secrets of Perfect Timing by Daniel H. Pink
Remotely Productive by Alex Pukinskis
Working on a Scrum Team Class
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Julie Chickering is the brains and brawn behind JC Agile Consulting, believes that Lean and Agile practices are packed with potential — to enable positive culture change, business agility, and breakthrough results. Julie is a past president and board member of the Agile Project Management Network (APLN), a Certified Scrum Trainer (CST), PMI Agile Certified Practitioner (PMI-ACP), as well as a traditional Project Management Professional (PMP).

Auto-generated Transcript:

Brian Milner (00:00)
Welcome back Agile Mentors. We're here for another episode of Agile Mentors podcast. I'm with you as always Brian Milner and haven't got to say this for a while. So I'm happy to say again, welcome back to the show, the fabulous Julie Chickering. Welcome back, Julie.

Julie (00:15)
Thanks, Brian. Glad to be here.

Brian Milner (00:17)
Yeah, very excited to have Julie back. Julie is a friend of the show. We've had her on multiple times and it's been too long. We just need to have you on more often again. So thank you for making the time and coming back. We wanted to have Julie on sort of as a little bit of a continuation from our last episode that we had with Kate McGaw. You we talked a little bit about facilitation there and there was a lot that we talked about initially to set that up to talk about

Julie (00:30)
Sure.

Brian Milner (00:44)
just the fact that there's an epidemic of bad meetings. There's kind of a harmful thing happening where it's extremely prevalent that meetings are going poorly. There's not a lot of attention that's given to this. There's not a lot of focus in a lot of organizations because it's such a prevalent issue. of our meetings being so bad. And Julie pointed out to me this Harvard Business Review article that sort of became a touchstone, I think, for what we wanted to talk about. It's called the hidden toll of meeting hangovers. And we'll link to this in the show notes. But the idea behind the article was just to say, they quoted a stat early on saying that they did a study and found that more than a quarter, 28 % of meetings left employees with lingering negative effects, such as impaired engagement and productivity. And so that's what they were referring to this sort of this meeting hangover, that bad meetings take a toll beyond just the lost time in the meeting. And that's kind of what we were talking about more with Kate is, you know, yeah, we want to make our meetings better, but there is sort of this ongoing lingering that, you know, from my reading of this and what I've experienced, kind of compounds, you know? One bad meeting then can lead to another bad meeting and another one and that feeling of anxiety and disconnectedness and like I said here, impaired engagement and productivity, those kind of grow and get worse and worse the longer that you have these bad meetings. So Julie, I'll just start with you and say, you know, when you read this article, what was it? What was it that really stood out to you, that jumped out to you, that made you think this was an important kind of area of focus?

Julie (02:27)
First of all, I love the title because I can relate to it. So when you're having a hangover, you just feel terrible, right? And this person that they talk about first, Jacob, about like, he was so frustrated when he left the meeting. So the introductory story when he was so frustrated when he left the meeting, he canceled his one-on-one right after because he knew he couldn't concentrate. And then he was just like so upset. for the rest of the day and talking about how he just didn't even want to work on the project anymore. So just this, I just got this physical sensation reading this around how it feels when you're in a meeting that's ineffective. And we've all been there and I could just like feel it in my body when I read this story. And I also feel like once you know what I, what an ineffective meeting feels like, the ineffective one is more noticeable and draining. yeah, so and then this this lingering effect of morale and just wasted, just wasted opportunity. And it feels like

Brian Milner (03:32)
Yeah. Yeah.

Julie (03:47)
in the corporate world, this is the norm. That we just have meeting after meeting after meeting that's just sucking the life force out of everyone. And then we wonder why nothing gets done.

Brian Milner (04:00)
Yeah, I mean, this article is packed with statistics and it's tempting for me to just kind of read them all off to you. I'm not going to do that. But there's a couple of things that kind of jump out to me. they talk about how around half of people have this feeling of that as a result of the hangover from the meeting, that they have negative or harmful impacts on their interactions with coworkers. They feel more disconnected from their team. and they want to spend more time alone based on the fact that, I went through this really kind of, there's no other way to say it, traumatic experience of having this really harmful, bad meeting. they connect the dots by saying, people will leave these meetings and oftentimes they will then go commiserate with coworkers and say, share their frustrations, which is helpful, it's good. But it also, you know, they noted here, this can kind of spread some feeling of negativity or hopelessness, you know, that it's always going to be this way. You know, yeah, I had a meeting like that as well. Boy, I guess this place is doomed. It's always going to feel like this. And so they have this kind of ongoing, as I said, compounding almost nature of it that one bad thing leads to another leads to another leads to another. And pretty soon you've got this really harmful, negative work environment and it's not necessarily something that's just happened. It's just the repetition of going through those things lead to this ongoing negative psychological impact in the organization.

Julie (05:28)
Yeah, I'm just smiling because I can just think of some meetings that I used to have a leader that would always show up late. Always show up late. We'd be halfway through the topic and then he would show up and we'd have to stop what we were doing and go circle back and just speed and you could just feel. the whole mood of the meeting change. We were actually making progress and we have to stop and we have to go all the way over. And this is constant. So what we would do afterwards is then have meetings after the meetings to complain about the leader doing that. The more adult thing would have been of course to say to the leader, when you do this,

Brian Milner (06:15)
Yeah.

Julie (06:22)
This is the outcome.

Brian Milner (06:25)
Yeah. So, so that's kind of, you know, what we want to talk about a little bit in here as well is, in the last episode, we, focused a lot on facilitation and the idea that, Hey, there's a lot of responsibility to the meeting organizer, whoever's facilitating this to not have it be this negative kind of environment. And I don't disagree with any of that, that we talked about in the last episode. I think there is a lot of that, that is true, but I think it's, it's. important for participants to not look at that as, it's all the facilitator then, right? I'm just a participant, I'm showing up and it's your job to get all this stuff out of me. And if the meeting goes poorly, that's entirely your fault. And I think it's important for us to recognize, no, if I'm a participant, if I accept that meeting invite and I'm here, I have a role to play. I have a contribution to be made and I can have, you

Julie (07:14)
Right.

Brian Milner (07:19)
as kind of Pollyanna-ish as it sounds, I can have a negative impact or a positive impact on this meeting. And I think that's an important kind of responsibility to take a hold of.

Julie (07:25)
you Yeah, I agree. And I think about that in a couple of ways. So actually, in both Scrum Master and Product Owner class, I remind them at the end of every meeting to ask two questions. The next time we have this kind of meeting, what would you want to do differently? But you gotta ask the question. And if you ask the question and nobody says anything, then they can't feel victim to a poorly run meeting. But you gotta be able to listen. You gotta be able to listen to it. Doesn't mean you have to say yes in the moment. It could be that you would follow up after, but just ask the question. What would you wanna do differently the next time we have this type of meeting And then ask them, what did they like?

Brian Milner (07:48)
Yeah. That's good.

Julie (08:11)
I used to do it the other way around. I don't know if I told you this story before or not, but do you remember Daniel Pink did the he was our keynote speaker at the Scrum Gathering, our conference a few years ago when he talked about. OK, when he talked about timing. OK, so something he said is like, yes, he said, as people, if there's two, if there's good news and bad news to always start with the bad news first. And end with the good news, because as people, we remember the last thing we talked about it.

Brian Milner (08:20)
Absolutely. Yeah. Yeah.

Julie (08:40)
So if I say to you, okay, the next time we have this type of meeting, what would you want to do differently? And nobody says anything. Okay. What did you like? And then they leave going, we actually got something done. Unless of course we didn't get anything done.

Brian Milner (08:57)
That's awesome. Yeah. I mean, I think about like how in classes, a lot of times when we talk about forecasting and estimation, you know, I make a little joke. It's not really a joke. It's the truth. But when I present, I've learned over the years when I present information to stakeholders about timings, I, know, if, if I do calculations and it says it's going to take between five and six sprints to do something, I've learned to say the maximum amount of time it will take is six sprints. there's a chance it could come in as soon as it's five sprints and yeah. Yeah. I mean, I learned to do that because what I say in classes, I've learned a lot of people stop listening after the first one. And I think actually though, I may be wrong. It may be more what you're saying that, you know, we, we remember the last thing that we hear. but it may be a combination, right? Cause if, if I hear the low number first and I I'm happy with that, I stopped listening and I don't want to hear the bad news.

Julie (09:27)
Brilliant!

Brian Milner (09:50)
So if I say the bad news first, it could take as long as this, but there's a chance it could come in earlier, then I'm leaving them with the good news that it could be this, you know, as soon as this, but they've set their expectation that, you know, it could take as long as, you know, the bad news that I gave them initially. So I don't know, maybe there's a combination of that there as well. But yeah, I agree with what Daniel Pink says about that. And timings do make a big, difference for sure. and how we present things.

Julie (10:18)
Okay, so a key though in that is that you can only ask those questions if you're staying within the time box and you've allocated time to actually ask the question. And like some of these things that came up as the root causes of like poor time management, like running over or stuff like that. If you're running over, nobody's going to really want to take the opportunity to give you feedback. So what do you think about, so what you talked with Kate a lot about when we talking about here is the role of the facilitator. And I think we should talk about what people can do if they are feeling like they're the victim of the lack of facilitation or poor facilitation. So what do think about that?

Brian Milner (10:52)
Yeah. Yeah. Yeah, I mean, I think we have several roles to play, right? I I agree. If I'm not the facilitator, then it's important for me to come into that meeting, well, knowing what the expectation is. know, like if I'm coming into a meeting as a participant, I don't think it's responsible. to show up to the meeting. And I've shown up to meetings like this, showing up with the attitude that, hey, it's not my meeting. It's the other person's meeting. You got me. I'm here. But now it's on you to get out of me, whatever it is that you're hoping to get. And maybe I put in very little prep work for it. So there is some kind of interplay here between the facilitator and the participant. Because you could say, well, that's the facilitator's responsibility to help you understand. Yes, it is. That's, this is what I'm trying to say is I, I think it's a mistake to shirk that responsibility entirely and say, I'm not the facilitator. Don't look at me. Right. If, if they didn't ask me to prepare or, or, you know, here's what I need you to, to, come prepared to talk about. Well, then I've got a bad facilitator and you know, we're just, we're hopelessly going to be in a bad meeting. No, when I get the invite, you know, Kate said last week, you know,

Julie (12:17)
Mm-hmm.

Brian Milner (12:22)
You can decline invitations to meetings. You don't have to accept every meeting invite that you get. But if you do accept it, I think that there's an accepting of responsibility there to say, all right, I'm going to be a participant in this meeting. What do you need from me? And in advance, making sure you talk to that meeting organizer and saying, hey, I agree. This is probably a good thing for us to meet about, but I want to prepare. I want to know that I can come to this meeting armed with information that's going to be helpful to others and I can play my part. So meeting facilitator, meeting organizer, what did you have in mind for me in this meeting? What is it that you were hoping to get from me in this meeting so that I can show up prepared? And that small little question, I think, does several things, right? mean, one, it says, to the facilitator, do you know what it is that you want from this person? If they come back at you and say, I don't know, I just thought maybe you needed, well, if they say, you know, we just thought maybe you needed to be in the loop or whatever, well, I might come back at that and say, that sounds like an email, you know?

Julie (13:31)
Yeah, I'm also thinking though there's the flip side of then people, there's two different things. I want to go back to how I can also help. what also struck me when you were saying that is that I think there's also this cultural part of am I being excluded? That, you know, that sense of They're not inviting me. A lot of times people don't need to be there. What you're afraid if you're not there, does that mean something? Does it mean you're being cut out? You're not important? There's that whole ego part. Yeah.

Brian Milner (14:04)
Yeah. Right. Sure, mean, especially if there's a decision to be made, right? You could feel like, they don't want my voice in that decision. And I think that that's a legitimate concern. If I'm responsible for an area and decisions are gonna be made in the meeting and I'm left out of that invitation, I might have a concern and say, if there's gonna be a decision made around this, I probably should have an input. Is there reason why you didn't want my input in this meeting? And, you know, even asking that question can sometimes just trigger, well, this is lower level things. This is not really at the level that you weigh in on. Usually we didn't want to waste your time, you know, something like that. You might find out it has nothing to do with the fact that they didn't want your opinion. It was more of, we were trying to be conscious of your time and, and, and didn't think that this was the kind of thing that you would need to weigh in on. So you might have a micromanaging kind of problem there that you need to address as well.

Julie (15:11)
Yeah, this is all people's stuff. It's what makes it fun.

Brian Milner (15:14)
Yeah. I want to, want to just, I'm sorry. I don't want to mean to interrupt you, but there's one thing I've been thinking about this whole time as well, because we've been talking about bad meetings and bad meeting hangovers. And I think initially the first thought that kind of comes to our heads about that is facilitation and maybe the meeting not being organized well. But I think there's another thing that makes a meeting a bad meeting that it's important to call out as well.

Julie (15:37)
Mm.

Brian Milner (15:40)
I'll just give you an example. I remember there was a job I took the very first day of the job. It my first day on the job. We had a meeting with some of the other leaders in that organization, and I got called into this, and they introduced me. Hey, this is Brian. I remember them saying, he's the new whatever, whatever the last guy was that had my position. OK, he's the new whoever. And we got into discussion about upcoming things, the status of different projects and other things. in the middle of that meeting, there became a shouting match and there were F bombs dropped left and right. And I remember walking out of that meeting going, what the hell did I get myself into? You know? so what I'm trying to call out there is there are sometimes bad meetings. It's not about the facilitation or the order or the agenda or anything else. There's sometimes bad meetings because we don't bring kind of the

Julie (16:15)
Mm-hmm.

Brian Milner (16:29)
best parts of ourselves to the meeting. We bring the worst parts of ourselves to the meeting. And sometimes we don't censor that and we don't let those, we don't kind of, I don't know how to put it. We're not engaging civilly, right? And I know that sometimes when I've been in those and I've had multiple of those kinds of meetings like that, that I would say, yeah, that was a bad meeting. But it wasn't because the facilitator did a bad job. It's because the participants were kind of letting their inner demons manifest through themselves in the meeting and they weren't really treating everyone with respect. They were very disrespectful to their coworkers. And I think that that's maybe more common than we care to admit.

Julie (17:05)
Mm-hmm. Yes, when you're sharing that to me, that goes back to meeting working agreements. like, what can I, so if we go back to, if you're in a situation where you're in a bad meeting, even if the facilitator is doing the best that they can, there's things that you can do. So to me, if we've had, and I know you were brand new, but you said that that was not. uncommon. If we had meeting working agreements and you let out an F-bomb and that was against the meeting agreements that anyone else in the room can say, you just broke one of our, you can, you, anyone can call people on that behavior. shouldn't have to be just the facilitator because the facilitator might be like just trying to run through, okay, now what am I going to do? It might be needing to just take a little breath to figure out what do, right? But I can imagine if that was the norm in that environment that people got that disrespectful in the meeting that when people left, there was a hangover effect. Like you kind of was like, what am I doing?

Brian Milner (18:07)
Right.

Julie (18:27)
What's happening here? What's going on? What did I sign up for on day one? This is day one. What's day two going to be like? Are we holding back? Right. Here's the new guy. Let's be on our good behavior. We'll only drop three F bombs instead of four. So, at, I was very fortunate that at,

Brian Milner (18:27)
Right. Right. Right. Yeah. Yeah, they were on their best behavior, right? Guess I was new. Yeah.

Julie (18:50)
rally software, just, this was norm. It was normal to learn, everyone learned how to facilitate and be good participants and all that, except it was really quite funny at our coaches events because we had to have the working agreement that the facilitator actually got to choose how to facilitate, but we didn't get to facilitate the facilitators. But anyway, I have started recommending Alex Bukinski's book, remotely productive. took a lot of what Jean taught us and help is helping people apply that remotely. So like chapter four is how to help in a bad meeting. So if you're a participant and it's going bad, how can you help get back on track in a respectful way? So not being, not being a jerk about it. But even, so he just even gives examples of things like. when somebody makes a recommendation. like noticing when people agree on an action and you type it into chat. It doesn't have to be the facilitator who types it into chat. Like as a participant, you can go, okay, the action was or a decision was made noting decisions, decision, write the decision down, but helping the facilitator be like, we would talk about that. Actually, I forgot until I just started speaking out about it that often, especially in

Brian Milner (19:54)
Yeah. Yeah.

Julie (20:11)
big significant meetings, would have a scribe, a facilitator and a scribe. So this is what he's talking about actually is somebody scribing.

Brian Milner (20:22)
Yeah, yeah, that's a very important component because if we just shout things out and no one's really capturing what the next steps are, those are going to get lost. And we could have to repeat this meeting because we just didn't really follow up in any way. We didn't take any action. So I agree. That's an important component of it is at least designating that it doesn't have to be one person, but just designating that, hey, here's the expectation. Here's what we're going to do. Yeah.

Julie (20:49)
Um, yeah. So there's a bunch of really good tips in here and like the Kindle version's 1499 or something. So I've been telling people like, if you can have just one meeting that sucks less, you're going to get your 1499 back. So if you could have one less meeting hangover, you're to get your 1499 back, think for sure.

Brian Milner (20:49)
That's a great tip. Yeah. Yeah, absolutely. I should clarify with my story earlier that I'm a big boy. It wasn't the language that bothered me. It was directed at someone else, like kind of F-U, that kind of thing. That's a very different dynamic than just saying, those effing suppliers, I sure hate that. That's fine. Or maybe more fine for others than some, but.

Julie (21:21)
Mm-hmm. Right.

Brian Milner (21:38)
That didn't bother me, was more just that the attitude behind it was a negative one towards someone else. But yeah, that's a great tip there, just understanding that when I'm a participant there, when I show up, that I have a role to play in it as well. There's things I can do and if there's not notes being taken, then I can maybe step up and do that. Hey, someone said we're going to need to do this? All right, let me put that in the chat. Remember, this is what needs to happen.

Julie (22:05)
Yeah, and he gives nice, some like a template here on when we're making decisions like data, diagnosis, direction, do next. So he's given a nice, he gives a lot of really great tools. I'm really, and like liking it quite a bit. back to your, your example that is, in the, the behavior part. was a lack of respect versus really the content. Yeah, I get that. The conflict that's going on.

Brian Milner (22:42)
Yeah. The tip from the book you just mentioned kind of aligns also to something that's in this article, the Harvard Business Review article. One of the things it says is they have some tips in this as well. And one of the things they say is demand accountability every time. And I think that's a good kind of takeaway as well is they're specifically talking about these action items, things that we would do as a result. As a participant, think it's important to, I like that language, demand accountability. If we have this meeting, all right, what is it that you're hoping to get out of this? I'm showing up, I'm here, what do you need from me? What are we gonna do as a result of this? Any participant can ask that. Any participant can say, so that we don't just waste this time, what are we going to do next?

Julie (23:11)
Mm-hmm.

Brian Milner (23:29)
I think you demand accountability when you do that.

Julie (23:33)
Yeah, and I would say too, the first thing we should ask is what's the purpose of this meeting? And so if you go up to turn agendas into action plans, Jean taught us is you have a purpose statement. And then actually she taught us that what are the questions we need to answer in order to meet the purpose? Those are our agenda topics. When we've answered those questions, we're complete with this meeting. And then like where the

Brian Milner (23:39)
Yes. Yeah. Yeah.

Julie (24:01)
come back down here to make every minute count. Don't run over. Alex also gives some nice gentle waves of doing like we would say time check. We have 10 more minutes left. You could just put that in chat time check. We have 10 more minutes left. You don't have to be the facilitator to be like time check. So I do like that. He's helping people think about what they can do versus just being victim to

Brian Milner (24:05)
Yeah.

Julie (24:29)
the lack of facilitation.

Brian Milner (24:31)
Yeah. And as a participant, I can, I can check in at the start of the meeting and say, all right, just, want to, I want to, have a time box check here. Our meeting is scheduled from this time to this time. That's our time box, right? We can't, is there, or I have something right after this. just so you know, here's my time box. can't go further than this. and you know, I think as a participant, it's.

Julie (24:46)
Hmm.

Brian Milner (24:56)
you can have those same effects just like you said, hey, time box check, it's this, we got this much time left. And as a facilitator, I know I've reached the end of our time boxes sometimes when we haven't really gotten as far as I had hoped, but I've been okay saying this was a good start. This was a good start to what it is we need to decide. Obviously this is gonna take more time. We are at our time box, so we're gonna have to wrap this meeting up, but we'll schedule follow-ups and we'll take it from here. If I'm entering a meeting where I need a decision by the end of that time box, then by all means, make sure people are aware of that from the start. If I'm a participant or if I'm the facilitator, we're here together, but we all need to understand that we need to leave this with a decision on this.

Julie (25:37)
Yeah. So the other thing, Kia, I believe, around the decision is, and also be clear about how we're going to make the decision. So is this going to be a collaborative decision? We're all going to vote? Or are we getting, everyone going to give their opinion? Somebody else is going to make the decision? And then we'll check, like, how are we, how is the decision going to be made? So that's not a surprise as well.

Brian Milner (25:50)
Yeah, yeah, yeah. Yeah, yeah, extremely important. I know when I talk about in our product owner classes about doing things like buy a feature as a way to prioritize, one of the things I always try to say to the stakeholders is, hey, we're going to play by a feature, but this is no promise that this is going to be what the final prioritization is. You're helping me to prioritize, but I want to set the expectation. I have to take into account your opinions and other people's opinions and market factors and lots of other things. So make sure we're on the same page. We need to understand this is a component of the decision. I will make the final decision outside of this meeting, but I really appreciate the input and I need your input to help me make the decision.

Julie (26:32)
Right. Yeah, love that example. So moving down when they say press paw, how to recover how to press.

Brian Milner (26:55)
Yeah, yeah, yeah. If you find yourself having a hangover from one of these bad meetings, yeah.

Julie (27:01)
Well, even if it's a great meeting, I am a fan of Adam Grant and I can't like pull up the where he said it. And he said it someplace that the studies show that people actually need like 10 minutes between topics. So if you're going to finish a meeting, you should have at least 10 minutes before the next meeting to be able to.

Brian Milner (27:19)
Yeah.

Julie (27:27)
focus and reframe. So I also feel like sometimes these meetings are bad because people are rushing from meeting to meeting. They don't have time to take a bio break or get a bite to eat. So now they're hungry and all that kind of stuff. But we do this to people on a regular basis.

Brian Milner (27:46)
Yeah, yeah. But, and I agree with that. if it's a good meeting or a bad meeting, I'll find myself, because I work from home exclusively. Well, I shouldn't say exclusively. Sometimes I'll go and work on site with different companies. But when I'm working from home, I'll leave the meeting of something I've just talked about and I'll have to go get more tea or something. And there's a little decompression of, wow, let me kind of throw that off, right? Let me take a deep breath. And now I can reset and I'm ready for whatever the next thing is. But I find I do that kind of naturally and I can't imagine not doing it. I can't imagine kind of going one thing to the other all the time and never having that break. That would kill me. Yeah.

Julie (28:31)
It happens all the time. It happens all the time. back to meeting working agreements. That's another one that I suggest is people don't start like at the top or the bottom of the hour. Like they offset it a bit to build in breaks. But when you're setting that time box, you got to set, you got to leave space in your agenda time. You have to leave space in your time, your meeting time to close your meeting properly.

Brian Milner (28:59)
Yeah. Yeah.

Julie (29:01)
We don't think about how much time that takes either. So it all adds up for sure.

Brian Milner (29:09)
I like the idea too that they have in here of walking it off. I know just in my work history, kind of like the example I gave you, there have been times when I've been through meetings where I feel like, yeah, I just got to get this off of me. And I have taken... remember, know, in certain circumstances, I'm not a smoker at all, but I, I had, I've always had developers that smoke in some way, shape or form. I, I wouldn't be uncommon for me to go and just stand outside with them while they smoke. or I'll walk down to the corner and get a drink or something and come back. there's something about taking that walk, getting outside the office. or if I'm here working at home, you know, maybe I'll even just go take the dog for a quick walk around the block. And by the time I come back, that's such a good way to. just kind of let whatever that is go away and reset. Now I'm ready to do what I need to do next, but it all goes to know, eliminating that hangover effect that I might have that came from a bad meeting.

Julie (30:12)
Yeah, so another facilitation tip around that, especially if you've just done a big meeting, if you can, walk it off with someone else. But do it in a debrief way, like what did you learn? And so we would talk about walking the walls. If we're physically together, we have stuff all over, like grab a friend.

Brian Milner (30:21)
Mmm. Yeah.

Julie (30:34)
or grab something you don't usually talk to and then walk the walls, so to speak. So at the end of class when I do have enough time, I like them in their breakout rooms to just debrief each other. Like what are a few things you want to try and remember? Because we all remember different things. So there's different ways you can do it. The way they talk about walking it off is it

Brian Milner (30:38)
Yeah.

Julie (31:01)
to avoid the hangover, but hopefully we're gonna switch the culture and people are gonna have good meetings and they're gonna wanna talk about positive stuff at the end. I mean, there's both ways of thinking about that physically, I think.

Brian Milner (31:13)
Yeah. Yeah, I agree. Well, I hope people have gotten a lot of this. You know, we kind of debated, we do this? Should we talk about this? It's so close to kind of the last topic, but I do kind of see it as a part one and part two. You know, there is a part one of that that is, bad meetings sometimes are very much a cause and effect of not facilitating well. But I would hate for people to entirely think, well, it's just the facilitator. there are only one person in the room. And if all the other people think that's not really my responsibility and I don't really have a part to play in this, then the facilitator can only do so much.

Julie (31:45)
Yeah. Yeah, and depending on what type of meeting it is, like really big, significant, like quarterly planning meetings, then the facilitator needs to do more work, in my opinion, to set everybody up for success. So depending on the size, the length, the... Some meetings need more structure than others, but I agree that as participants, you gotta have accountability to and how it's going and do I need to be here? What's the purpose? If the purpose isn't introduced, then you would ask kindly, what's the purpose of the meeting? What are we trying to accomplish here? I'm just wondering, I'm just checking in. just, not like, the hell am doing here?

Brian Milner (32:38)
Right, right.

Julie (32:39)
was to make sure that I'm, you know, whatever. But I do like what Kate said. don't know. You should be able to ask the questions. You should be able to decline all of that. So here's what I'm thinking now, Brian. Another thing people could do, though, is if they start to pay attention to the cost.

Brian Milner (32:44)
Yeah.

Julie (33:05)
of being in meetings just through their own health and well-being, then yes, they can be proactive. They can learn a few tips from Alex, but then maybe they, even if they're not the Scrum Master or someone who would normally be assigned to becoming a facilitator, maybe they can get some of the facilitator training because... The training that Kate was talking about really is applicable to any kind of role. It doesn't have to be the scrum master or product owner or team lead or manager. It's really applicable to all people. And then the other thing too, if it's something that say you're in the developer level role, even if you're a business analyst, quality, whatever, quality engineer, whatever, and you wanna become a facilitator. get the training and see if you like it. Then you can kind of be stealth-like in there with, and I feel like that's some of the things Alex is trying to teach people as well. If you're going to be the facilitator or the participant, that there's ways that you can make a difference in a positive way.

Brian Milner (33:59)
Yeah. Yeah. Absolutely agree. agree. Well, this has been a great conversation. We got to have you on more often. So I apologize it's been so long, but I really appreciate you taking the time and bringing this topic up. And it's a great, great focus for us, I think. thanks for bringing it, Julie.

Julie (34:21)
Beautiful. Well, I don't have a meeting hangover, do you?

Brian Milner (34:36)
I do not. I feel great. I don't need to walk anything off right now. Awesome. There we go. I'm right there with you. All right. Thanks, Julie.

Julie (34:39)
Me either. I'll just go back to drinking tea. Okay. right. Thank you. Yep.

#137: Stop Wasting Time with Guests Kate Megaw

12 mars 2025 | 36 min

In this episode, Kate Megaw joins Brian Milner to share simple but powerful techniques that can turn those soul-sucking meetings into dynamic, action-driven conversations. If you're ready to make meetings worth attending, this one’s for you!

Overview

Brian Milner and Kate Megaw uncover the secrets to running highly effective and engaging meetings. They tackle common facilitation pitfalls, the staggering amount of time wasted in ineffective meetings, and how simple tweaks can transform team collaboration.

Kate shares practical strategies for keeping participants engaged, fostering psychological safety, and ensuring meetings lead to real action—because no one has time for another pointless meeting.

References and resources mentioned in the show:

Kate Megaw
ARCLight Agile
Katanu
Katanu’s Facilitator Certification Course
Katanu Resources
#44: Transformations Take People with Anu Smalley
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Kate Megaw is the Founder and CEO of ARCLight Agile, specializing in helping organizations create empowered, high-performing teams through agility and collaboration. A dynamic Certified Scrum Trainer (CST), Certified Team Coach (CTC), and Project Management Professional (PMP), Kate is a sought-after speaker known for sparking ‘aha’ moments that drive real transformation.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome in Agile Mentors. We're back here for another episode of the Agile Mentors Podcast. I'm here as I always am, Brian Milner. I'm with you as your host. But today I have the one and only, amazing Kate McGaw is with us. Kate, thank you for coming on.

Kate Megaw (00:17)
Thank you for having me.

Brian Milner (00:19)
Absolutely. If there's some of you out there that aren't familiar with Kate, she is a CST, a Scrum trainer like myself. She's also a certified team coach. And she also has the other side of things, the dark side. She's a PMP. So she has that project management kind of background that she brings to the table as well, which I think is awesome. She's a CEO of a company called Arclight Agile. And she's a co-founder of one of our favorites here that's come on the show, Anu. But they team up together. So it's Kate and Anu. And so their company is Katanu. I love it. love it. So why we decided to have Kate on is because Kate and Anu both have done a lot of work around facilitation. And we did have a user request.

Kate Megaw (00:57)
That's it.

Brian Milner (01:09)
to have an episode where we focused on facilitation. And listeners of the show know there's nothing I love more than being able to fulfill listener requests here and try to do those as soon as possible. So let's dive in. Let's talk about facilitation. It's a funny word. There's lots of different misconceptions and things about it, I'm sure. What do you find people misunderstand most about facilitation?

Kate Megaw (01:34)
think one of the key misunderstandings around facilitation is that you're part of the meeting, you're part of the event, you're actively involved. And when you're facilitating, you're actually, taking a step back because you are accountable for making sure that everyone is speaking and that we're keeping an eye on the agenda and things like that. And if you are actively involved in the discussion, You can't be doing that because you're missing body language. You're missing people who need to talk and who aren't talking. So I think one of the main misconceptions is, or that people forget is a facilitator is neutral. So if, for example, you have a scrum master facilitating a retrospective and they need to be actively involved in the retrospective, they should be inviting somebody else in to facilitate it. and I think We're beginning to see a lot more interest in it now because it's one of these key things. If it's done badly, people generally will notice. If it's done well, hopefully you don't notice that much other than, you know what, that meeting was very efficient. We achieved the goal and I feel as though it was worth my time. One of the things I like to say to people at the end of a meeting is the fist of five, how worth your time was this meeting? And I'm looking for fives or fours. If we're getting threes, twos and ones, we've not facilitated it well, or the meeting didn't achieve its agenda and things like that. think a lot of the statistics around facilitation that have come out recently, and you and I were talking about these briefly before we started that the average at the Microsoft trend index shows us that average time spent in meetings by employees at the moment is 21 and a half hours a week, which is an increase, I know, an increase of 252 % since the pre-pandemic. So.

Brian Milner (03:36)
That's incredible. Yeah, I mean, that's more than half of a work week, right? I mean, we're spending more than half our work week in just locked in meetings. So you're right. We had this conversation beforehand and you were telling me that stat and it just kind of floored me that we're spending that much time in meetings. But it was the next one you told me that really floored me. And it's a combination of these two, I think, that people need to really grasp onto. So tell them what you told me next.

Kate Megaw (03:49)
Mm hmm. Yep. Yep. Yeah. So the next one is that the Harvard Business Review indicates their research, 67 % of meetings are considered by executives to be failures. So if we look at the financial impact of that, and this is something I didn't share with you, but the financial impact of that is for a company, imagine you have a company with 100 employees, unproductive meetings are wasting upward of $1.7 million a year. If you have a thousand employees, increase that number. it's one of these things that it is not difficult to do. It is just understanding why we need someone in the facilitator role. And the basics around the basic facilitation, the basic getting ready for the meeting, facilitating during the meeting and properly closing the meeting. takes those unsuccessful numbers up to successful numbers where you're getting those fives and people are sort of, yep, that meeting totally achieved the purpose and the outcome and it finished early. So I've got 20 minutes back before my next meeting.

Brian Milner (05:24)
Yeah, it's so incredible that combination of those two stats. I thinking that we're spending over half our time in meetings and that 67 % of them are failures, we're having a lot of them and we're not doing them well, clearly.

Kate Megaw (05:36)
Absolutely. I think with, I don't know with Zoom, well, I think with Zoom, it's got easier to have meetings. So we're probably having meetings where we don't need to have meetings. That's one of my favorite things to ask is, does this need to be a meeting? Or are you just going to talk at me and roll data out? In which case, send it to me in email. Don't tie me up for a meeting.

Brian Milner (05:44)
Yep.

Kate Megaw (06:02)
Because so many meetings are a waste of time that a lot of people are spending meetings multitasking. So we're taking an hour for a meeting that we could do in 25 minutes if people were 100 % engaged and following the agenda and things like that.

Brian Milner (06:22)
Yeah, yeah, that's so fascinating. it seems like such a, it's hard to believe that there's not more of that skill in just basic business training, right? Because if we're having all those meetings, then it would seem natural that there would be more segments that would say, you know, a little facilitation skill for, you know, a, you know, bachelor's in business, you know, like that might be a little helpful, right?

Kate Megaw (06:41)
Yep. Mm-hmm. Yeah, absolutely. And it's a small investment for something that will make a huge difference. I mean, one of the things Anu and I have been working on is the mnemonic of ready, reach, and wrap in order to make sure we have effective meetings. And the ready part of it is setting the foundation. So before you even get to your meeting, this is ahead of time. You're understanding, okay, what are the Rs? What are the roles and responsibilities? So if I'm facilitating, then who are the decision makers? Who is mandatory? Who's required to be there? Who are the, you can come if you want. Let's stop doing meetings to 30 people and expecting 30 people to show up. So we've got to understand the roles and responsibilities. The other, the E for the ready is expectations and engagement.

Brian Milner (07:29)
Ha ha ha.

Kate Megaw (07:41)
So if the expectations are that this is an interactive meeting, we're using Lucid or Mural or Mira, whatever tool we're using, it's going to be collaborative, webcams are going to be on, multitasking is going to be at a minimum, everyone knows going into that meeting what the expectations are. And then the A again is the agenda and the alignment. The agenda should be very clearly saying these are the items that the D is making sure where we have defined the purpose and the outcome. So every meeting, we need to know what the purpose of the meeting is, what the outcome of the meeting is, and they should be included in the agenda. We shouldn't be accepting meetings. Imagine the power of being able to decline a meeting if it didn't have an agenda in it. And if you think about it, why do we attend meetings?

Brian Milner (08:27)
Ha Yeah.

Kate Megaw (08:33)
with no agenda and people turn up to the meeting and said, okay, so what's this meeting for? Pretty sure we've all got better things to be doing. So make sure for every meeting we have a defined purpose and outcome. And then the why is making sure we as facilitators have your logistics ready. If it's Zoom, if we're using a remote whiteboard, do people need to practice it? Do we need to set up an environment? Do we need to make sure webcams are on? All that type of thing. So a huge amount of meetings would be better if we did nothing other than better planning with the roles, responsibilities, the expectations, the agenda, the defining the outcome and the logistics. If we just did that.

Brian Milner (09:09)
Yeah.

Kate Megaw (09:23)
I bet we're going to see the amount of productive meetings increase considerably.

Brian Milner (09:29)
Yeah, there's so much transfer here too as well, just to the normal scrum meetings that we have because, you know, one of the things I'll talk about lot in class is just to say, you know, you can't just expect to show up to something like Sprint Planning and have it go smoothly. You have to put in some work beforehand and get ready for it. Same thing with like a Sprint Review. You got to put in some work beforehand and make sure you know who's going when and who's speaking, you know, that speaking order and all that stuff.

Kate Megaw (09:42)
Yeah.

Brian Milner (09:55)
goes miles in making those more successful meetings. But the other thing that really interested me in that is you talk a little bit about purpose and that we don't really understand the purpose of the meetings. And that's something that's really stuck out to me is when I talk to people who don't like their Scrum meetings, it feels like 90 % that is just Brian math, but it feels like 90 % of the time, right? Feels like this. It feels like 90 % of the time.

Kate Megaw (10:04)
Mm-hmm.

Brian Milner (10:20)
that the people who have a problem with those meetings don't know the purpose of the meeting and that's really the root cause of it, right? If they knew why we were here, then the meeting makes sense. Now I understand what we're trying to do.

Kate Megaw (10:26)
Yep, absolutely. And I think one of the interesting things, I would love to repeat these numbers around the Scrum events, because I think by default, the Scrum events do have a purpose. They do have an outcome. We know what the roles and responsibilities are. We know what the expectations for engagement are. So I think the Scrum events are much more productive than your average event.

Brian Milner (10:41)
Yeah.

Kate Megaw (10:59)
But I do feel if we don't have well-facilitated Scrum events, that's where we get our criticism, or, this meeting was a waste of time. Okay, well, let's look at our facilitation and see, it an error in planning or was it an error in expectations? But it always surprises me when people say, well, Scrum's just so many meetings. And I'm so... No, we should have fewer meetings and if they're well facilitated, we need all of those meetings. So it's not as though we're having a meeting for meeting sake, which I think is unfortunately something we can't say for our non-scrum events.

Brian Milner (11:43)
Yeah, yeah, I mean, I go so far as to say, if you don't understand the purpose of it, don't show up. I mean, there's really no need to be there if you don't know what we're trying to get out of it. One other little side correlation there too, because this kind of ties in a little bit to some of the stuff I did this last year in kind of studying a little bit about neurodivergency and different neuro types and that kind of thing. And one of the things I found really fascinating was certain neurodivergent types,

Kate Megaw (11:48)
Mm-hmm. Mm-hmm. Mm-hmm.

Brian Milner (12:12)
really need to have an agenda in advance. And if they don't, then it just raises their anxiety level. they're just, you even not, you know, neurodivergent types, just regular, normal, you know, neurotypical people. There are those that just don't respond well when you're just throwing out a blank slate and saying, give us your best idea, right? They need time to process and think in advance and

Kate Megaw (12:15)
Yeah. Mm-hmm. Yep. Yep. Mm-hmm. Yep.

Brian Milner (12:38)
And so yeah, if we could send out that just the day before, it's not that much work. It's just one day earlier, right? It's actually the same amount of work. It's just doing it a day earlier. Right.

Kate Megaw (12:45)
Absolutely. Absolutely. It's just better organized. Yeah. I mean, I even on my team meetings, I know some members of my team want to know, because I always like to start them with segue questions and some of my team completely fine. Ask them a question, favorite food or you want to have any sort of segue question and they're fine with it. But I have my thinkers who want to think about it ahead of time. So I think it's important when we're facilitating any event that we understand the audience. How many of the audience are going to want to maybe read a document ahead of time? How many of the audience are, you know what, they can think on the feet, I can throw anything at them, but there are others that do need the preparation. yeah, I think that the planning that we do, if we can do it just slightly ahead. And then things like when we get into the meeting, of the mnemonic that we use for actually facilitating during the meeting is the mnemonic of reach, which is we're guiding the process. The very first thing we do when we go into the meeting is we review the agenda and open the meeting. So here's the agenda. I've got the agenda visible. mean, what the agenda that we use in classes. Is the to do doing and done. I use that for all my meetings. I've got that up on the virtual board and the topics of the meeting are moving across to doing and done because then our visual people can see how we're doing. But the reviewing, at the start of every meeting we said, OK, let's just review the agenda. Let's just remind everyone this is the purpose and this is the desired outcomes. And if the right people are not in the meeting. There's no point having a meeting that we cannot achieve the purpose and the outcomes because we don't have the right people. So, I mean, I always say open it, open it with a segue question and things like that, but level set on the agenda. And then the middle part of the meeting is the bit that people are familiar with, which is the gathering ideas. It's exploring. It's the A is the assessing, making sure we've got the collaboration and the discussion and the...

Brian Milner (14:39)
Yeah. Yeah.

Kate Megaw (15:07)
The C is our concluding, are we doing dot voting or is somebody else who makes the final decision? But the H is the one that we often forget at the end, which is let's highlight the action items from the meeting. Let's make sure we know what it is, who's accountable for it, when it's going to be done by, and then close the meeting. mean, you...

Brian Milner (15:18)
Hmm.

Kate Megaw (15:33)
you and I will both close out our classes. Maybe we use one word, maybe we use, give us a statement, all sorts of different things, but we forget to close out meetings. go, time's up. Okay. Bye everyone. And we've not reviewed the, this is what we're going to do for next time. And we've not formally closed the meeting, even if it's as simple as one word, but we've got to open and close it. Sorry. Passionate about that. No.

Brian Milner (15:44)
You You mean that's not how you close out a class? I've been closing classes like that for years. No, I'm just kidding. Yeah, exactly. Ding, sorry.

Kate Megaw (16:03)
Yes, sorry, time's up, clunk. Yeah, sorry, dog's barking, dog needs to go out. So, but yeah.

Brian Milner (16:11)
Exactly. Yeah. Yeah, no. And there was something I came across just in trying to put together materials for classes where we have little segments on facilitation in it. Because I think sometimes there's a lot of focus on the different various techniques, like fist to five or thumbs up or whatever. There's different kind of techniques. I'm not trying to belittle those. Those are things we need to know. But.

Kate Megaw (16:21)
Mm-hmm. Mm-hmm. Mm-hmm.

Brian Milner (16:36)
One of the things I came across was that the root word of this thing is this Latin word, facilius. stands or it means literally to make easy. And I've always had that kind of in the back of my mind when I'm a facilitator is like, what are they trying to do? And whatever they're trying to do, just, my job is just to make that as easy as possible, right? You know, it's always difficult when you're trying to make a decision and you have no direction about how that decision is going to be made.

Kate Megaw (16:46)
Yeah.

Brian Milner (17:05)
But a good facilitator can give the structure to it and say, no, no, no, it's OK, I got you. We're going to go through this little journey together, and we're going to end in this other side, and you're going to have something to take away from it.

Kate Megaw (17:16)
Yeah, we're going to have heard everyone's voices as we go through. We're not going to let one person dominate the conversation. We're going to use techniques like, that's a great point. Can we also check in on the other side of the table? Let's hear some counter points here. It's pulling people in, it's summarizing. So if I'm hearing you correctly, Brian, you're saying A, B, C, D. It's all of that going into it. And I think one of the other... big has when we teach facilitation is the facilitator is not the scribe. So people say, well, I'm the project manager or I'm the facilitator. need to be taking all the meeting notes. And I'm like, well, what direction is your head pointing when you're taking notes? And it's down at a piece of paper. So you're not seeing who's yawning because you're tired and you need to take a break. You're not seeing people who are confused or wanting to talk and things like that. sort of either you turn on the AI tool and have the AI tool summarize the meeting for you. Do check it before you submit, it out or B have everyone in the meeting as a grown ass adult. They can take their own agenda items. mean, their own action items, have an area on your virtual board or in the room you're having the meeting in that is action items. And again, what is it?

Brian Milner (18:18)
Sure.

Kate Megaw (18:36)
Who's gonna be doing it? When's it gonna be done by? And I think one of the key criticisms of meetings is, and you'll hear this as well, particularly by retrospectives is, well, nothing changes. And I'm sort of, well, who has the action item? well, there isn't an action item. And I'm sort of, at the end of every meeting, we should be doing the mnemonic we use here is rap. The first thing is retrospect.

Brian Milner (18:53)
you

Kate Megaw (19:04)
How was this meeting? We talked about the fist of five. Give me one word. Anything we need to do differently next time. And then the A is make sure we have all of these action items assigned to someone. And then the P is the one we forget about. Tracking that progress. How are we going to hold each other accountable for making sure that something changes as a result of the meeting? So.

Brian Milner (19:22)
Mm-hmm.

Kate Megaw (19:31)
If we're doing retrospectives, if the team is voting whatever technique they're using to choose the one thing they want to do differently, how do we make it visible? Do we put it on our scrum board somewhere? Do we talk about it every day as part of after we've done daily scrum? How are we doing with the communication techniques that we wanted to try and do differently going forward? We've got to have that visibility. Otherwise nothing changes.

Brian Milner (19:57)
Yeah, yeah, that's so awesome. I completely agree. And that's something that I think you're right is missing, not just from retrospectives, but just a lot of meetings in general. We don't really understand, all right, well, what's the takeaway? What's the thing we need to do as a result of this to make this not a waste of our time, to make this something that was a useful, not the 67 % that were failures, but something that actually leads to success. I want to.

Kate Megaw (19:59)
Mm-hmm. Mm-hmm. Yep. Yeah, yes, so that we're not having the same meeting again next week and the week after and nothing's changing.

Brian Milner (20:30)
Exactly. Exactly. I want to ask you one question about facilitation. I've heard this a lot in regards to retrospectives, but probably it's more a facilitation thing than it is a retrospective thing. But I think probably the number one question we get from people about retrospectives is, how do you handle a quiet team? so I'm just kind of curious. When you talk about facilitating and working with individuals who are a little more introverted,

Kate Megaw (20:50)
Mm-hmm.

Brian Milner (20:57)
or just not as comfortable speaking out in public, are there special considerations or are there things that you do differently just to try to accommodate and make those people feel more comfortable when you're facilitating them?

Kate Megaw (21:09)
So yes, several things. So one, I will look at a theme. So do they have a team name and do I want to set up a mnemonic around the team name to gather the data? Are they a visual team? Do I want to do something like the sailboat that's interactive and people can add things to the board? Are they a movie buffs? Do I need to do a Star Wars themed retrospective? So I'll generally try and find something to connect the team. I've done it before where I'm working with airlines. Okay, what is it keeps our planes in the air? What is it that grounds our planes? What are the storm clouds we need to be aware of? What are causing bumps during the air? So all of that type of thing, it's a theme relevant to the team. And I generally will find that if I can start a team talking, I can keep them talking. So if... one of the ways that I will often start a retrospective is if the retrospective, if your last retrospective was a ride at Disney, what ride would it have been? and get them talking or give me one word that describes the last retro or in a scale of one to the, mean, the last sprint, give me one word that describes it or scale of one to 10. How well do you think we did at the last sprint? But I love to get people talking. If I'm in the office, I sort of adapted the Adam Weisbart's retrospective cookies and I'll use candy bars and I'll wrap questions around candy bars and the team grabs a candy bar and there is a question on it which they answer and then other people in the room will then answer as well. Maybe things like, what can I do to better support you as a scrum master? Or, What can we do to better support each other as team members? So I think it's getting people talking, making sure the big reminder for me is as a facilitator, if you did not write the Post-It note, you should not be reading the Post-It note and you should not be moving the Post-It note. The team owns the Post-It notes. Everyone should be adding their own Post-It notes, whether it's virtual or in person.

Brian Milner (23:07)
Yeah.

Kate Megaw (23:28)
They should be grouping their own Post-it notes. They should be moving them. And the other one, people always say, well, what happens if there's the elephant in the room and this thing on the board that nobody wants to talk about? And I'm said, well, often I will say, okay, I'm going to add, we're going to do something different for this round. This time, I'm going to ask you to introduce something you did not write on the board. And let's talk about, I'm going to ask you to choose a topic and we're going to talk about that. Just read it, you read it out.

Brian Milner (23:39)
Yeah.

Kate Megaw (23:58)
and then we'll have a discussion around it. So as a facilitator, I can uncover the elephants in the room without anyone feeling too uncomfortable.

Brian Milner (24:07)
Yeah, that's great stuff. of parallel to this, think is kind of, I know we've, I've heard you talk about this, but the sense of safety in the room and just that people feel safe to talk about that. Are there things we can do as facilitators to actually raise that sense of safety?

Kate Megaw (24:25)
There are absolutely, there's a lot of things we can do. And I, every now and then I will hear something and I will just cringe. And there's, well my team doesn't really like sharing. They're not honest in the retrospective until the CTO disconnects from the retrospective. And I'm sort of, okay, so maybe what do you think this is maybe telling us? I'm sort of retrospectives are Vegas rules. It is the team. I will do retrospectives even with non-scrum teams, but it is the team that is there. There are no visitors. It is the team only. The other thing that makes me cringe is, yes, well we sent out the minutes of the retrospective and I'm sort of, excuse me, the retrospective again, Vegas rules. What is the one thing we're going to do differently as a team in the next sprint? Okay, is everyone okay if I put this up on our scrum board so it's visible?

Brian Milner (25:07)
Ha

Kate Megaw (25:20)
Okay, that's the one thing we're taking away. But back to the question you were asking, one of the biggest signs of a lack of psychological safety is that the team just doesn't want to talk. They're worried that the minutes are going to be captured. Somebody, one of the leaders is in there and, well, everyone's fine with my leadership. They're completely open and honest in front of me. And I'm sort of, okay, let's try a retrospective then with you there.

Brian Milner (25:32)
Yeah.

Kate Megaw (25:50)
And then we'll also try retrospective without you there. And let's see which one is more comfortable because otherwise it's a, it's a colossal waste of time. If nothing's going to change, why are we wasting sort of 45 minutes to an hour or even doing it? So I think that the psychological safety is a key one, making sure it is the right people, making sure that minutes are not being captured. The other thing is. A lot of times people say, well, I need to capture it because I need to bring all of the information again next time. And I'm sort of, no, you're trashing the Post-it notes. You're trashing the mural board, whatever. You're starting from scratch next time. they're sort of, well, I'm going to lose all this information. I'm sort of, no, if it's important enough, it's going to come up again next time.

Brian Milner (26:23)
Yeah. Yeah. Yeah. And things change, right? mean, what the universe of things we might identify this sprint could be entirely different for next sprint. I've always loved, Jeff Sutherland had this phrase, he would say about it to say that, you have to remove that one big thing. And when you move that one big thing, then the system adjusts and you don't really know where the next bottleneck is going to come from until you remove that one big thing. Kate Megaw (26:58) Yeah.

Brian Milner (27:02)
So it's likely to be somewhere you wouldn't expect. so you can't just hang on to your number two issue from one retrospective and then say, well, next retrospective, we'll just do that and we can cut out having the conversation because we identified important things in this one.

Kate Megaw (27:14)
Yeah. And it anchors the tea. It stops the creativity. that's the other thing with retrospectives. I occasionally will work with a client and there's the, oh yes, we've been doing what's going well and what's not going so well every two weeks for six months. And I'm sort of, it's not really any wonder your team's bored out of their minds at retrospectives and nothing new is coming up. There's so many websites out there.

Brian Milner (27:41)
Yeah.

Kate Megaw (27:42)
that retrospective should never, in fact, no meeting should ever be boring because we should always be opening and closing a meeting in a creative way. Even if it's, mean, one of the things that we like to do in the morning of class is have music. So when people are joining, the energy is there so that we're getting that interaction and things like that. So people are starting on a high and then... I mean, you'll notice in the afternoons people begin to yawn, especially after lunch. Okay, you know what? It's been 65 minutes. Let's take a break. Let's do a segue question at break. So when we come back, show us something on your desk that tells us a bit about you. Or one of the ones I like is go stand up, go and look outside and come back and tell us something you saw outside. We have chickens. We have all sorts of things that people are saying. but it's encouraging them to get up and go get some oxygen in their system, take a break and then come back and then it's more engaging. But if as a facilitator, I'm not planning that type of thing, the energy is going to go down and I'm not going to achieve the purpose of my half day event or my one day class, whatever it is.

Brian Milner (28:56)
Yeah, it doesn't happen by accident. It's all very intentional. Well, this is fascinating. And we could have this conversation for another several hours, I'm sure. I just wanted to let everyone know that in case you were scrambling to write down these mnemonics and other things, we're going to link that in our show notes. So you can go to our show notes, and we'll put you over to Katanu team.

Kate Megaw (28:58)
No. Yep, absolutely. Yep.

Brian Milner (29:20)
Katanu, I keep on saying cat and Anu, trying to say it right way. Yeah, but we'll link you over them so you can get those three Rs for meetings and know kind of what each one of those little letters stands for in there.

Kate Megaw (29:24)
Yeah.

Brian Milner (29:33)
This has been really eye-opening for me and it just is a fascinating topic and it's so delightful just to hear the intentionality and how we can do simple things. They're not hard things, but simple things that make such a huge difference.

Kate Megaw (29:48)
Yeah, yeah, mean, that's the key. This is not rocket science. It's one or two simple things that helps us take that if we are going to spend 20 % or 20 hours a week, which is half of our time in meetings, let's at least make sure they're productive meetings so that we're not literally burning money by having unproductive meetings.

Brian Milner (30:12)
Yeah, absolutely. Well, I also forgot to mention here at the beginning, and we'll put this in the show notes as well, but Team Katanu also has a facilitation course. The Scrum Alliance has a certified Agile facilitator designation that you could obtain if you were interested in that. We'll link that off as well. But yeah, I couldn't recommend any better people for you to take that from than Kate in a new idea. We were saying that she had a, when she was younger, used to have the nickname Cat, and now everyone's calling her Cat from that. Well, thank you again for coming on and sharing your wisdom with us. I really appreciate it.

Kate Megaw (30:46)
Yep. Yep. Thank you very much for having me, Brian. And I look forward to hearing amazing facilitation stories from everyone once they've implemented some of this stuff.

Brian Milner (31:03)
Absolutely.

#136: The Future of Agile Coaching with Andreas Schliep

5 mars 2025 | 32 min

What’s next for Agile coaching? Brian Milner and Andreas Schliep dive into the shifting landscape of Agile coaching, the differences between Scrum Masters and Agile Coaches, and how to carve out a sustainable career in a changing industry.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner and Andreas Schliep explore the evolving role of Agile coaching, the challenges coaches face in today’s market, and the skills needed to thrive in a shifting industry.

They break down the differences between Scrum Masters and Agile Coaches, discuss how to develop a personal coaching style, and emphasize the importance of integrity and resilience. From navigating layoffs to redefining what it means to be an Agile leader, this conversation offers valuable insights for anyone looking to grow in their Agile career.

References and resources mentioned in the show:

Andreas Schliep
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Andreas Schliep is a Certified Scrum Trainer and executive partner at DasScrumTeam AG, helping organizations navigate complex projects with agile methodologies. A thought leader and co-author on Enterprise Scrum, he empowers teams—from startups to Fortune 500 companies—through high-impact coaching, training, and a passion for continuous learning.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome in Agile Mentors. We are back here for another episode of the Agile Mentors Podcast. I'm here as always, Brian Milner, and today I have someone we've been trying to get on here for a little bit, and I'm excited to have him here. Mr. Andreas Schliepp is with us. Andreas, thank you for being on.

Andreas Schliep (00:17)
Thank you for inviting me.

Brian Milner (00:19)
Yeah, very excited to have Andreas on here. Andreas has been in the community here for a long, time. He's been just really generous with his time and he's mentored a lot of people. He's a CST, a Scrum trainer. He's also a certified enterprise coach. So he has kind of those dual high level certifications with the Scrum Alliance. But he mentioned to me earlier, he's kind of always considered himself a Scrum trainer. But he's also a coach in this group called the Leadership Gift, or there's also another name here that they've used recently, Responsibility Immersion. So that might come to play in our conversation here because we wanted to talk about sort of the future of agile coaching and agile coaches in general. There's a lot of turmoil, there's a lot of upheaval and things that are shifting and changing every day in our profession. So I guess, you know, let's just dive into the topic here. Andreas, how do you see things currently? And, you know, in a broad sense, where do you see them going?

Andreas Schliep (01:18)
Yeah, so first of all, why am I concerned? So typically I say that I kind of, train coaches and I coach trainers. So most of my work is centered around the path of scrum masters and how they can kind of acquire the necessarily skills and insights to become actual coaches themselves. Or scrum coaches as I would prefer to say it. And that includes a lot of stuff like we want to equip them with facilitation, with training skills, with coaching skills, with systemic observations and other methods. And we've been doing that for a couple of years. And so of course we came across lots of good people, good coaches and good trainers, good consultants out there. And we kind of kept our community open. So it's not like people attend our classes and then we forget them or we only have closer relationships to our corporate customers. It's like we kind of managed to build some kind of little community. People keep coming back and we keep chatting about what's going on, what's happening in their environment. And as a mainly training focused company, one of the first effects that we notice is that our classes are getting emptier and emptier. So what's going on, especially advanced classes are not that well. So we still have some, well, yeah. basic attendance, but it's not as it used to be. well, a couple of years ago, we had like full classes and everything, and then COVID hit and we could say, okay, so COVID kind of reduced the demand for edutraining. And then the next crisis came and the next catastrophe and the next disaster. But there have also been some structural changes. I think that we are currently experiencing two effects that happen at the same time. So the one thing is that, well, Diana Larsen put it that way, Agile has won. So there's no doubt that organizations employ Agile methods and want to use Agile practices, some of them with, some of them without any clue about what that even means or what Agile thinking or Agile attitude behind it is, but still, there's no shortage on like the use of Agile or the, but there's also no shortage of the Agile basic training or educational videos, content or whatever. So people get lots of more resources than we used to get back then when we had like this one scrum book by Ken Schwabe. So read this and then you went out and said, how do I do that? So. And then came the second book by Mike Cohen and the third book and so on. had to, had all these puzzle pieces coming together where we needed to find our own way and build our proficiency. And now you get a flood of books and stuff going on, which is fine. So the one thing is that of course our profession is developing and it's kind of natural that you will notice some kind of within that. But there's another effect and this is one thing where we scrum trainers can kind of take responsibility for our own contribution. It's the fact that organizations can hire an unlimited number of low-level agile coaches nowadays. There's been no quality control. Anyone who went through a two-day CSM class could call themselves agile coaches and they got hired for lots of money and eventually produced nothing. some of them, some agile coaches or people who call themselves agile coaches even caused chaos. So, and the systems. that they were affecting started to kind of fix themselves and heal themselves from the Agile coaches by expelling those. So, and of course, maybe you have a third effect, which is sometimes it just doesn't work and you blame the Agile coaches. So if you just lay on your couch and you do nothing and your doctor tells you, you have to get moving, you have to get up and get moving and say, yeah, it's a bad doctor because... I still lie on my couch and my health is deteriorating and this doctor doesn't help me. He doesn't give me what I want. What do you want? Yeah, I want just, I would just want a pill that I can swallow that I'm healthy. It doesn't work that way. And then we had those people who were selling those pills, yeah, who were telling people, here we got a, we got a safe way that you can do this. All you need to do is implement this process, hire our consultants.

Brian Milner (05:26)
Yeah.

Andreas Schliep (05:43)
We kind of made all the thoughts and the heavy thinking ourselves beforehand and you just need to install it. Here's the roadmap, here's the process manual, here's the 300 page guide. Just do it this way. And this is also detrimental. now we have, I've been talking to many people, many great people, you've been laid off, who are looking for a new orientation.

Brian Milner (06:05)
Yeah, yeah, I agree. I mean, I think you laid that out really, really well because there's I think you're right. It's kind of a multi effect scenario. There's a lot of things affecting it. And I know I've had conversations with with friends and colleagues about this. And, you know, we've talked a lot about the I think more kind of the second thing that you're talking about, just that and It's sort of a chicken and egg thing because the industry has built up and spread agile concepts through offerings of usually two day classes. You and I both do those quite regularly. And I think we probably both would say that's a very valuable thing. to go through sort of that immersion kind of a couple of days to learn it and get a foundation in it. But there may have been sort of a misconception or it may have been sold incorrectly to say, now you're ready to lead an organization and transforming from zero to 60 in Agile. when you're not, right? I mean, you've got a good grounding. You're ready to begin learning with a team, but it's the first step. There's gotta be some sort of ongoing support system that when you come up against something that you don't really know how to handle, that you have someone to ask. You have somewhere to go to get help and get answers. Even the, you I work with Mike Cohn, I think he's a great trainer. But even a two day class with Mike Cohn, I don't think is gonna make anyone an expert that now you're ready to, you know, take on the huge challenge of cultural change within the organization, you know?

Andreas Schliep (07:53)
Yeah, yeah, it's like with anything agile, these classes are a starting point or a waypoint and not a designation. It's not the goal. So when I made my driving license, my driving instructor told me, and in Germany you have to spend lots of hours with your driving instructor. And my driving instructor told me gladly, now you can get to practice on your own. He was happy that he didn't have to co-practice with me any longer because I wasn't the best driver. So I actually aced the theory test, but the practical driving was a little more difficult and kind of probably was bad for the blood pressure of my driving instructor. yeah. And that way, but I never thought about this. So the idea was I get the permission or I get the next level to the next step. And the next step will be, I want to learn proper driving. And that's something that you need to do on your own. And with this understanding, we try to kind of provide a path for people to become better scrum masters and agile coaches by kind of revamping the CSP path, the scrum aligns and other things. A glorious project that also failed gloriously. I'm still not entirely sure why, but probably because the Scrum Alliance and many other people failed to understand the similarities between Agile Coach as a profession and the Scrum Master as a role. So they claimed that there were two different things. And I think that's also a structural issue in organizations.

Brian Milner (09:16)
Yeah.

Andreas Schliep (09:25)
that they see Scrum Masters and Edge of Coaches as different things. So the Scrum Masters work on the team level and they just know their Scrum and they facilitate the meetings and then they come up with nice cookies for the retrospective so that everybody on the team is happy. And occasionally they take one of the team members aside when they have some issues and help them go through that. That's totally fine, but the Edge of Coaches do the real stuff. release train engineers and the others, do the organizational thing and they don't bother with what's happening on the team level because they need to do the important things on the higher level. And with this attitude somehow fueled by some decisions by Scrum Alliance and other organizations like, yeah, in order to become a certified team coach or certified enterprise coach, you have to kind of prove that you're... had coached like 2000 hours or 2500 hours. But by the way, the scrum master worked. It doesn't count towards this coaching, which is totally ridiculous. So that means the misunderstanding of the role is a structural problem. Another structural problem is that the organizations that would need the most experienced scrum masters, they attract all the rookies.

Brian Milner (10:16)
you

Andreas Schliep (10:34)
because they don't even know what a good scrum master would cost like. They have those two day or even less day. I heard about a transformation at a large automobile builder in Germany. They had something like a half day class for scrum master training within the safe environment. And they wonder why they fail. They wonder why they're failing.

Brian Milner (10:53)
Ha

Andreas Schliep (10:54)
On the other hand, we have organizations, even here in Germany, they have great leadership and coaching concepts. So they develop the Scrum Masters. They have the finest Scrum Masters ever on such a high level that the teams actually don't need them because the teams also evolved by taking care and taking responsibility for themselves and paying attention to the work. So they're kind of over-coached. So like, I think it was at Rally 10 or 15 years ago. There was a period when the external rally coaches didn't get so many contracts. And so they went inside and coach all the software teams and rallies at Rally. And after three or four months, the software team said, please, please give us a timeout, give us a break. We over coach. It's just too much. We just want to do some work and maybe not get better for like a month or two before we, because it's

Brian Milner (11:42)
Yeah.

Andreas Schliep (11:47)
It's hard always to get better and even better and you're so excellent coaches, cut us some slack. So that's so, but this is the structure. So on the individual level, it's just the same as with any major shift in any kind of industry. If your current profession or your current job title doesn't fit any longer, focus on what you're good at and see that you

Brian Milner (11:54)
Yeah, yeah, yeah, right.

Andreas Schliep (12:13)
become excellent at that. So that's, it's an old formula. It's an old formula and it can be different things. So I know about some scrum trainers who go and went into software development again, because they said, actually, I'm passionate about software development. I can understand that. I have a developer background as well. So sometimes I'm not that unhappy about taking care of a website and other stuff. It's a nice distraction. But some are really great facilitators. But if they only go out with a label, agile coach, and do not let the facilitation skills and experience shine, then they might get a mis-hired. So we have great personal coaches in there. So people with various skill sets. And if you take a look at the agile coaching growth, we have Biomark, some of them others.

Brian Milner (12:37)
Right.

Andreas Schliep (13:00)
You see that it's a vast field. So you cannot expect anyone, maybe the two of us, but you cannot expect anyone to be, not even me, so anyone to be excellent in all these knowledge areas and to be such a light and catalyst in everything. So the idea is to find your own way how you can contribute best. and then collaborate with others in their fields. So for me, the most interesting areas in that field are training and facilitation. Because I think that's the main thing that agile coaches or scrum masters can shine in.

Brian Milner (13:41)
Yeah, I've always loved, know, Lisa Atkins has that kind of different aspects of a coaching stance. And one of the ones that she had there that I've always loved is the idea of having a signature presence. And I remember when I first kind of encountered that, was, when it kind of sunk in, it was a very freeing idea for me.

Andreas Schliep (13:49)
See you.

Brian Milner (14:01)
to, you know, kind of like you're describing there, there's so many different aspects that you could, you know, try to do and you could do well, but it's too much for any one person to do all of it. So that signature presence to me, one of the things that I really kind of took away from that was know what you're good at, right? I mean, there's something about you that you bring from your own personality and your history and and everything that's made you who you are that is unique. And when you can find what that is, then it's almost like prior to that recognition to me, I was almost even a little ashamed that that was where my strength was. And I felt like I had to make up on these other areas that I struggle with or I didn't do as well. But that concept to me,

Andreas Schliep (14:47)
Mm-hmm.

Brian Milner (14:52)
kind of help me see, no, there's something that's really unique about how you approach things. And if you recognize that, lean into it because nobody else can offer that, right? Nobody else brings that to the table because that's uniquely you.

Andreas Schliep (15:06)
Yeah. Yeah. I have to admit, well, we're both with Scrum Alliance and I've been with Scrum Alliance for more than 20 years now. But some of the biggest insights about Scrum and the role of Scrum Master were some things that I actually learned by looking through the Scrum.org certification parts. So just out of curiosity, I started digging into the... Professional Scrum Master Series by Scrum.psm1. Okay, PSM1 is a walking part, so that's no big deal. 50 minutes without preparation, A's are done. Okay, next thing, PSM2, was a little more chilling. Okay, there are some different concepts in the way they address Scrum. And I completely faded PSM3. So that's interesting. So I should have known that. And the point is that...

Brian Milner (15:52)
Huh. Yeah.

Andreas Schliep (15:58)
There are differences in the message and the Scrum Master and the Scrum.org framing of Scrum is far more of a leader. So they take far more responsibilities. They are much closer to a sports team coach actually, even taking care of the crew and even throwing people out of the team if necessary. Then the fluffy Scrum Master social worker thing. with no real responsibility always in the background that we appear to propagate sometimes that I even have propagated lots of times. And I see this in my own style as well. So I'm rather strong at the facilitation part and working from the side of the background of people. But sometimes I see, and I think that's a big challenge for many agile coaching scrummers out there.

Brian Milner (16:32)
Yeah.

Andreas Schliep (16:48)
When it comes to the situation where I should take the lead, I'm still reluctant when I say, okay, yeah, somehow I don't want to step under the feet of others. I want to give them room. I want to be in my facilitator stance because I love that stance and that's my personal brand or whatever. The calm way and listening to people and integrating all voices. But all of a sudden, I encounter situations where say, my voice first. So, yeah. So let's do it that way. this week, I kind of stopped the client workshop in the middle. I said, so yeah, what is that? here you booked me for the entire day, but I noticed that you're very upset about important stakeholders missing.

Brian Milner (17:19)
Yeah.

Andreas Schliep (17:39)
I also noticed that you don't see the point in reiterating some other concepts that I prepared. you could use these methods and then talk to your stakeholders, but you rather want me in this room with your stakeholders and have this discussion together. So let's just stop this now. And I offer you a gift. I will come back for another half of days. So we stop this half day. You can use your time for something else. I can use my time for something else. And then I come back, but only if you have your manager in here. So if you bring your boss, I will come for another half day and then we finish this and deal with these questions. And they were kind of impressed that I was offering them. But where's the point? I needed to change the mode. I couldn't stay and I think this is something

Brian Milner (18:20)
you Yeah.

Andreas Schliep (18:29)
which is another great opportunity for Scrum Masters or agricultural coaches to say, what if I stepped into this leadership role?

Brian Milner (18:37)
Yeah. Yeah, that's a great kind of approach to it. And I know we've had some similar things at Mountain Goat as well, where we've worked with some clients and you kind of show up and you start to get into the things. Or even sometimes in the kind of just pre-work calls where you're trying to arrange things and talk through what is it you want to get out of this. And you sort of get that feedback and understanding that this is really just checking a box, right? They wanna check the box that they did this, but really making the change. No, they really don't wanna make the change. They really don't wanna have to change what they do on a day-to-day basis. you kind of are, as a coach or a trainer, you kind of get to that decision point where you have to say, at what point do I call this out? At what point do I say, you know what? You're gonna waste your money. Right? mean, I can come and do this. I can take your check. I can go away, but it's not going to make any difference. And you're not ready for it yet. and, that's, that's always a really hard decision. When you get to that point, when you realize, you know what? It's not serving your needs for me to, move forward here. You know, it's, it's, you're not going to be happy with me.

Andreas Schliep (19:48)
Yeah. I think it's important to maintain the personal integrity. the whole point about resilience is that you kind of are able to change while you maintain your own identity. So the path that you are trying to. And this change can mean a lot of things. So if someone would tell me, you've got to stop with Scrum now because Scrum is now forbidden everywhere. I would kind of dig into the facilitation. So I joined the IAF, the International Association for Facilitators. I don't have a credential there yet, but this is something if I would go into more facilitation gigs, this would be very interesting for me. I also became a coach in the responsibility program with Christopher Avery. First of all, I think that was a nice addition to my training or to my work with leaders. But then I also discovered that this is kind of navigation aid for myself. So whenever I do something, I start with what do I want? So what do I want? How do I want the situation to evolve? What is the outcome that I want to achieve? And how am I blocking myself from that? So what is kind of my inner blocker that prevents me from getting what I want?

Brian Milner (21:03)
Yeah.

Andreas Schliep (21:04)
So I could also talk about external blockers, but these external blockers are sometimes just things on my path that I choose to say, okay, I can't go there because there's this blocker. And when I found these two things, so what do I really want and what is blocking me? I can go and make a decision. I can confront myself. And with this ability, I'm pretty sure that I'm able to respond to any kind of situation. So, and... whether I pursue the facilitator part further or whether I go into the coaching way. I love to work with groups so that just the one-on-one coaching is not so interesting for me. But these are kind of independent from what I'm doing now, but also based on what I'm doing now. So I can derive lots of good skills and insights and approaches from what I did as a scrum trainer so far, what I have done as a scrum trainer.

Brian Milner (21:58)
Yeah. Well, I think when I'm hearing and tell me if I'm misquoting this or saying it or misunderstanding, but it feels like there's sort of an element here that, you know, I think a lot of us sometimes, have some kind of a title that we've earned. and we, we sort of inherit from that, set of, activities or things that we feel empowered to do. based on that title. And what it sounds like I'm hearing from you is it should kind of be the reverse. You should think about what you do well and the titles may come and go. They may change the descriptors that people use to describe what you do, it might change, but what you love to do with the activity, what you're good at, that can shift and change a little bit and don't be so concerned with the title.

Andreas Schliep (22:45)
Yeah, so edge-hired coaches still can keep this kind of title for the tribe to identify a peer group. And I've also joined edge-hired coach camps even as a scrum trainer. because this identification is important to say, okay, I know a couple of people who have different skills or different things who are some more similar to me, but I don't think we should stick to Agile Coach as a job title and only look for Agile Coach offers. But rather go out and see what's out there, what opportunities do we see. Apply for weird stuff. So at the beginning of this year, I applied as a facilitator for United Nations volunteer program and even made an extra language proficiency exam before that because I had to kind of prove that I'm at least at level C1. for this job. I just did it because it was there because this opportunity came through the International Association for Facilitators. I just said, okay, I don't know. They didn't even throw me back. I don't have anything, but I just, I want to apply for this. I want to get this material together. I want to show that I'm potentially able to do this. I will be far too expensive with my current rate, but yeah. And I think anyone currently in the situation as an edge on coach being laid off or looking for another job should kind of step back and go through these steps. So what do I want? What are the activities that I'm really passionate about?

Brian Milner (24:13)
Yeah.

Andreas Schliep (24:13)
And the answer might be surprising. So sometimes, it's actually coding. Maybe we'll get back to the basics.

Brian Milner (24:19)
Yeah, yeah, you're right. I've known a lot of people or I've known several people, I guess I should say, that have kind of maybe migrated backwards. If you think of it in that way, I don't know that's backwards, but migrated to their roots a little bit more, you know, and maybe left training, but went back to doing, you know, managing software teams or even coding just because they enjoy it. And I think that's a great thing if that's...

Andreas Schliep (24:41)
Yeah.

Brian Milner (24:45)
brings them happiness, you know?

Andreas Schliep (24:47)
Yeah, you know, when the whole agile thing started, they came up with a little website and the website says something like, we're discovering better ways to sort fire customers or so. I don't have a probably and helping others to do it. And if even if you go back or if you go to actually start working as a developer again. You still bring the edge of spirit and you still bring the ideas and methods of collaboration. It's going to be so helpful in your environment. Especially with new technologies, AI stuff and remote work and all these things kicking in. Everything looks like it's making your work more difficult. Massive layers like even media firing developers now, not only edge of coaches. So we have... so many disruptions to deal with. And I think that, well, kind of resilient HR coaching tribe stance is helpful in whatever role you fulfill afterwards.

Brian Milner (25:43)
That's really good. Yeah. Well, this has been great. I really enjoyed the conversation. Sometimes you're not really quite sure where we're going to end up and where we're going to travel, but I've really enjoyed all the directions we've taken here, Andreas. So I can't thank you enough. Thank you for making time and coming on and sharing your experience and wisdom with everyone.

Andreas Schliep (26:00)
Mm-hmm. Yeah, was great fun and thanks for the opportunity and I hope that this will help some people find little more guidance, least a little more confidence if they don't find guidance yet.

Brian Milner (26:13)
Yeah, I agree. Thank you very much.

Andreas Schliep (26:15)
Thank you.

#135: Leading Without Authority with Pete Behrens

26 februari 2025 | 34 min

In this episode, Brian Milner and Pete Behrens explore the difference between managing and leading, the critical role of middle management in transformation, and how anyone—at any level—can drive real change in their organization.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner sits down with leadership expert Pete Behrens to unpack what it truly means to be an Agile leader.

They dive into the difference between leadership by authority and leadership by respect, the importance of competency in leadership roles, and why middle managers often hold the key to lasting organizational change.

Pete shares insights on how leaders can navigate cultural shifts, manage organizational tensions, and empower teams to operate effectively in today’s fast-moving world. Whether you're a Scrum Master, Product Owner, or executive leader, this episode is packed with actionable strategies for leveling up your leadership impact.

References and resources mentioned in the show:

Pete Behrens
Agile For Leaders
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Pete Behrens is a leadership coach and Agile pioneer, shaping organizational agility for over 20 years—long before scaling frameworks took center stage. As the creator of the Scrum Alliance® Certified Enterprise Coach (CEC) and Certified Agile Leadership (CAL) programs, he continues to empower leaders worldwide through Agile Leadership Journey™, a global network dedicated to leadership growth and culture transformation.

Auto-generated Transcript:

Brian Milner (00:00)
Well, welcome back Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have the one and only Mr. Pete Barron's with us. Pete, welcome in.

Pete Behrens (00:15)
Thank you, Brian, for the invitation and happy to be here.

Brian Milner (00:17)
Very, very excited to have Pete with us. If you're not familiar with Pete's work, you're in for a treat. Pete has been doing this for a long time and he has been really a foundational person in some of the things that the Scrum Alliance has done over the years as far as being involved with the coaching program and the leadership program and helping to design and put that together. His main focus has been in leadership. for several years now. And that's why we wanted to have Pete on, is to have him talk a little bit about Agile leadership. Because in today's world, in the context of a lot of the things that are shifting and changing in our day and age, I know that there's just a lot to consider in the area of Agile leadership. why don't we start, and I know this is kind of a softball, you probably get this question a lot, how do you define that? How do you define, is Agile leadership different than leadership, or is it... Is it essentially the same thing?

Pete Behrens (01:12)
Yeah, good, good starting question. So think of leadership as, you know, the ability or capability of influencing others towards a common goal. Right. That's that's what we look at as a behavior, a capability. Some people confuse that with being a leader. And that's actually different. We think of that as being, you know, having a title of authority. Right. So if you think about influence, there's really two aspects. One is I actually have a title that gives me the authority or I have respect. that allows me to do that regardless of title. So we do that a lot with leaders to actually kind of reset some of that and think about, right, this is a capability anybody at any level, any title can do as somebody. Now, the agile, you know, part of that, obviously, you you and I live in an agile industry and world. Why? Because things are changing, right? Things are changing faster than we've seen. Things are more complex. software has created endless possibilities of paths. And we like to use the metaphor of fog. So think of your operating in the fog. You need to sense and respond to make appropriate decisions. It's no longer available to us to kind of leverage the plan, follow the plan. And so Agile is simply a capability of leadership to operate in that complex, fast-changing world.

Brian Milner (02:31)
Love that. Yeah, I love that analogy. mean, I think about like all the times I've done cross country road trips and you drive into a fog bank, you're a lot more alert. You have to be really on point the whole time versus, you know, driving out in middle of Arizona somewhere where you can see, you know, the next five miles ahead, maybe relax a little bit more behind the wheel. That's a great analogy. So if we have to be kind of There's a difference here between being, I'm a leader in the organization because they've given me a job title and I'm a leader because I'm recognized as a leader. I'm recognized as such. What kind of characteristics, qualities come with that recognition? How do people, what differentiates somebody who is a recognized leader in an organization from someone who's not?

Pete Behrens (03:14)
Yeah, you know, certainly title is a recognition, right? So it's one way, you know, people and it's in effect, probably the most desired way to become a leader is I want the title. you may have seen this. I know I did when I was, you know, I was a director of engineering, VP of engineering before I became, you know, a coach and consultants. And a lot of times I'd get people coming to me and say, Pete, I want that job. I want that leadership position. I want to be the tech lead. I want to be the development manager. I'm like, well, prove it to me. They're like, well, no, can't until you give me the title. And one of the things we've realized over time as we've been studying leadership and developing leadership programs is people who receive a title before they develop competency actually are worse leaders because they end up depending on the title to influence. And leaders who develop the capability and now where do you get this? You develop respect. How do you get respect?

Brian Milner (03:47)
Yeah.

Pete Behrens (04:11)
you develop respect through expertise, right? This is some combination of education and experience that people are willing and choosing to follow your lead. And this is the basis of where most people kind of get into leadership is they've developed a certain respect in the organization. Others are willing to follow them. And so that's a typical starting point, a typical entry into leadership. One of the things we also help leaders understand is that's also a trap. And I'll just pause there to let you reflect on it. We can go into that rabbit hole if you'd like to.

Brian Milner (04:48)
Yeah, no, let's talk about that because you're right. There's a lot of times when you see someone in an organization that they've been there, they don't necessarily have to have been there for a long time, but they've been there and they've developed the respect of their peers. They're the best programmer on the team. So the organization recognizes that, recognizes that others in the organization see them as being exceptional. So they elevate them. Now they're no longer just programmer where they did an exceptional job. Now they are manager of of the programming team and they've been elevated simply because they were the best among the bunch. Is that the right thing to do?

Pete Behrens (05:22)
Right. Well, it's definitely a common thing to do. And it's not it's not the wrong thing to do. I think the mistake a lot of organizations make and you know, you can go back to Marshall Goldsmith, who wrote the book What Got You Here Won't Get You There. And what he's alluding to is exactly that. The skills you need to get into leadership aren't the skills you need in leadership. And so the trap that that leaders fall into is, okay, and this is my path. And maybe your path as well is I'm the best engineer. I'm the best salesperson, marketing person, whatever that is. I'm now coming into leadership. What is your comfort? Well, your comfort is in the work itself. And so all this new stuff about working with people and projects and project management and people management culture and, and other things are very uncomfortable. So I go back to my comfort zone and that's when I start to micromanage. start to redo other people's work. I start to get too detailed into the weeds and I'm not doing the job of leadership, which is really influencing others down this path. And this is one of those traps that many leaders fall into is we get these steps up to leadership, but then we're not properly educated and provided the tools we need to do that job. I think the studies we've seen of only about a third of leaders get proper education, mentoring or coaching to be a leader. And the way we look at this is, is, you know, hiring anybody into an organization from the outside world. You would never hire somebody without a detailed resume that outlines every bit of education, every bit of experience. And then you're matching against 30 applicants or 100 applicants picking the best one. Yet every day. We're promoting people with zero expertise, zero education in leadership into those positions, and it's just It's really silly and it's really backwards. And yes, we want to give them opportunities, but we also need to help them. And that's what we're not seeing, is we're not seeing that help.

Brian Milner (07:20)
Yeah, yeah, I mean, I'm old enough. I know that I remember in my dad's day and age, you know, it was not uncommon for any large organization to have a leadership training program within the organization. You would be recognized as being exceptional. You would be put forward and then you'd enter the leadership training program of the organization that would help you to elevate and become an effective leader. And we don't see that. as much anymore. You just kind of are elevated and hey, kids, you're on your own.

Pete Behrens (07:51)
Well, and what they're teaching is management, not leadership. And I think one of things we differentiate with leadership is we manage things like projects. We manage programs. We manage technology. We can manage documents and even HR programs, things like that. We lead people. And so, yes, there are a number of things that organizations, HR programs, et cetera, do to kind of help. Oh, you need to do a one-on-one. or you need to do basic communication. Like there is some, but it's not the things we realize help elevate. You know, we separate this concept of vertical development from horizontal development. we often teach or organizations often teach the horizontal. That's the skills. OK, so you need to communicate. You need to delegate. You need to empower. But we're not teaching what we call the vertical development. And so what they're doing is their mindset is stuck in this kind of one stage. They got all this like this toolbox, but they don't know how to use the tools. And what we're trying to do is help them understand and give them a bigger toolbox to help them understand how to use these tools effectively to be better leaders. And that's a much different problem. It gets into self-awareness. gets into my focus as a leader from shifting in terms of the system and what I'm focused on and what my goals are. as well as just the time horizon I work in and how tactical, strategic or visionary am I. Those are harder things to teach, yet that's where leadership starts to emerge.

Brian Milner (09:29)
Yeah, well, it makes me think back to what you were saying about the person that would come to you and say, I want to be promoted. I want to be put into this next position. And your response of, me, kind of help me see that. I know you're right. There's a lot of times when people will look at things and say, I need the title or I'll be a leader when I am called this or when I'm put in this position. But what I'm hearing from you and what I hope everyone's hearing as well is, this starts far before that. If you're going to be on that road to being a leader, then it's actually something that you begin wherever you're at. And these are skills you can start to build over a lifetime to venture into that vertical area as you describe it. Does that sound correct?

Pete Behrens (10:10)
Exactly, exactly. And, you know, one of the things that, you know, I want to, you know, maybe warn the listener on here, we get a lot of people who come through and we work with a lot of, you know, agile coaches or leaders who want to become a coach or, you know, we have change agents, right? People who are, you know, their focus is change in the organization, right? This is where you see a lot of scrum coaches and things like that. And one of the things that we've realized over time is this notion of individual as change agent is incredibly challenging. And for the most part, we, the way we visualize or we talk about this to leaders is it's like, you know, you start singing a song and everybody looks at you like, okay, he's crazy. Like he went to like this evangelical school. He drank this Kool-Aid and he's coming back and he's like, yeah, yeah, that's just Tom or that's just Susie. And, and nobody listens to him. And we see this over and over again. And, and You know, one of the things we talk about is we've got to shift that solo into a chorus, right? So the construct of leadership, we think of often as an individual sport, but truly the only way change really starts to take hold in an organization, and that's where we're starting to shift from me to we, is how do we catalyze that choir to start singing? That's when organizations start to excel. And that's one of the things that when I'm starting to work with leadership teams, we start to understand this isn't just something we teach individuals. This is something we've got to collectively act on. mean, you think about any sports team and European football or US football or hockey or whatever that is. Those teams are are are awesome because of that choir element, because they all sing in the same tune, because they're all practicing all the time together. That's the other part of leadership that I want us to kind of focus on as we kind of take this journey. This isn't a solo sport.

Brian Milner (12:07)
That's such an important point. I can't agree with you more. just the concept there that I hope people kind of pick up on is, yeah, I mean, the Scrum Guide has for years talked about change agent and the Scrum Master being a change agent, but the kind of maybe indirect association from that was, you know, it's your job to take it on yourself to go and do this thing where You're right, it's too big of a job for one person to do this kind of thing by themselves. We have to have help, you have to have compatriots, you have to have someone who comes alongside you, because like you said, otherwise you're singing by yourself and everyone's looking at you like, what's that guy singing?

Pete Behrens (12:48)
Yeah, unless you're Satya Nadella, know, or somebody who has that capability on top of the org. And we actually see change happen, from people like Satya Nadella is kind of a rare example, I think, in our world and how he shaped Microsoft. But we actually see more change happening from the middle. You know, when we're teaching organizations and working with them, one of the things that I often

Brian Milner (12:51)
Yeah.

Pete Behrens (13:15)
I'm speaking to is the middle tier, you know, it's it's the frozen middle. It's the the between the rock and the hard place. They often feel the most pressure because it's the pressure from above, but the incapability of delivering below. But I try to help turn it around for them. And I say, you're the only one in the organization who feel the pain, but have access to the top layer for change. And and when it comes to organizational change. We actually find more change happening from the middle than we do from the top. Just because the top is so risky and they already have so much power, they don't really need or want change so much. They want to push it. But oftentimes that change happens from the middle.

Brian Milner (13:54)
Well, I know we've all seen the surveys and studies and things that talk about, you know, agile transformations and change movements and stuff and organizations that have identified leadership as being a kind of a ceiling or some kind of a blockage to real change taking place. So I guess what I'm hearing from you a little bit is don't let that become a blocker for us if we're not the top leadership, that doesn't need to be something that we need to look at and say, that's out of my hands. I can't do anything about it. We actually do have a role to play to that in the middle or other layers of our organization that we can affect the change through the leadership. Is that right?

Pete Behrens (14:35)
It's a perfect, perfect point. something we try to iterate all the time. Yes. You know, the number one thing we hear when we're working with organizations is I wish my manager could hear this, right? Because they are feeling constrained. They are feeling bound by certain rules and policies and governance and, you know, all the things that feel like our constraints. And that is true. And, you know, the only one who has access to these constraints is leaders. You know, we often describe, I call it the two games we play. You know, we get the agile and you get involved in a lot of these agile transformations. So we get the agile game played at the team layer. And maybe we get a little at the program layer, you know, if you've got some some cross team kind of coordination going on. And then we have the leaders and they play a different game, different rules, a different ruleset. And and then they've got the conflict, right? That's happening between these two layers. And I see this so often. right in the organization. Again, it's that middle tier who sees both games, has access to both games. And I think a lot of the problem we have in our agile community is we don't speak leadership. We don't speak the language leaders speak. I've been working, I worked with the organization and I talked to, know, this is like the CFO and the chief risk officer and, you know, the CIO. And I had a comment that came out and he said, Pete, For about three years, I've heard Agile blah, blah, blah. And I just didn't get it. And now I'm starting to understand the value because what we've learned how to do is speak leadership, risk, right? What is the risk in the approaches we're taking that are or aren't Agile? And what are the pros and cons of that risk? know, oftentimes our Agile evangelists. put agile on the good side and traditional on a bad side. And that's not true at all. Agile lives in kind of what I'd call a peak. Aristotle called this the golden mean, right? There's a peak. And on one side, there's a deficit of agility, and that is too much planning, too much rigidity, too much bureaucracy. But there's an excess agility. And this is where a lot of our coaches land. It's like hippie agile. Hey, man, what are you going to be done? I don't know, man. We're agile. Hang with us. hear that and they're like, I don't accept that. And so yeah, we've kind of swung right across this hillset down from deficit to excess and leaders aren't buying that. And I think that's been some of the downside of our agile community, our agile messaging. We've never broken through that ceiling of leadership.

Brian Milner (17:12)
Yeah, by the way, just I'm going to interject this a couple of times throughout, but if you like what you're hearing here from Pete, you can find out more from his site, agileleadershipjourney.com. Pete does a lot of classes and coaching and teaching and other things. And there's a lot that you can connect with Pete on through that site. And we'll put this in the show notes so you don't have to scramble to write this down. You can get back to this later. So I love that. that explanation, though. And it kind of resonates with me in a way, because I know one of the things I've talked about when I talk to product owners is the idea that product owners sort of serve as translators between the two worlds a little bit, right? Because they have to speak with developers who speak in very tech-speak kind of language. They have to speak to stakeholders who speak in very business-speak kind of language. Are product owners kind of that function? Are we losing the as product owners in doing that? Or is it not really a product owner thing? It's just more of an entire Scrum leadership thing.

Pete Behrens (18:13)
Well, yeah, take the word Scrum out. It is a leadership thing. Product owners are leaders, right? They are leading product. And again, the role of product ownership is a role of influencing others towards common goals. And I used to teach product ownership. was a certified Scrum teacher and taught product ownership, Scrum Mastership. I found product ownership to be the most challenging role ever because

Brian Milner (18:16)
Yeah.

Pete Behrens (18:39)
you're essentially optimizing for a solution that doesn't exist. So you have all these stakeholders who have all these needs and there's no possible way to meet the demand. And so the role of product ownership is how do I find the optimal across this dimension? so it kind of gets us into this world of, in business, there are often no right answers. Should we do strategy A or B? Well, it depends. You know, we're often as leaders chasing answers when there isn't one. I often talk about this as managing tension. And if we can kind of switch our mindset from there is an answer to this is a tension that will never go away and give you an example of this, like product owners struggle between tech debt and features. Well, that's something that will never go away. No matter how much we work on tech debt, no matter how much work on features, they will always be there. This is a tension that We simply need to learn how to manage. It's never a solution we can come up with. The same is true with strategy and tactics. Should a product owner be more tactical, live with the team, or should they be more strategic and sit with the stakeholders? Yes. The answer is yes. And again, this is not something a product owner will ever solve, but it is something that they can learn to manage. And you start to shift this mindset. And all of a sudden, my role as leader

Brian Milner (19:50)
Ha

Pete Behrens (20:01)
starts to change. We had one product owner speaking of that that I was working with years and years ago. And she said, Pete, I feel like a tennis ball getting whacked around the court by my stakeholders, you know, and she'd go talk to the state. I need this. Bam. You know, and she got to talk to the team. we can't do this. Bam. And another thing, bam. And she's like, just I can't survive this. And so we talked and we said, OK, let's let's think about your role different. And what she did, she ended up doing is she brought the stakeholders together and she said, OK, stakeholders, you guys can never agree. I'm forming a meeting that you must come to and you must fight each other for the feature prioritization. And if you don't come to the meeting, you're likely not to get prioritized. So that incents you to come. And number two, you got to convince your peers that that's more important than their need. And it just completely changed her association of her role from this. I'm the tennis ball to. Now I'm managing the court and they're all hitting balls back and forth at each other. And she's facilitating, you know, and that's just kind of one of those switch of mindsets where I can start to change my association, my work and get out of this, this sense of, there's an answer and I can figure it out to how do I manage this tension?

Brian Milner (21:11)
Yeah, 100%. Yeah. I mean, we believe in working in teams as a Scrum team. Why wouldn't we believe in working in a team of stakeholders as well? Right? Yeah, this is such great stuff. So I'll throw out another really loaded term at you because I know that whenever the term, whenever we talk about leadership, whenever we talk about agile leadership, or just leadership in general, you got to talk about culture. You got to talk about the idea of culture and changing culture and affecting culture and

Pete Behrens (21:19)
Yes, exactly.

Brian Milner (21:38)
You know, year people talk about, culture's a whole ball game, culture's everything. And other people who say, no, we focus too much on culture. It needs to be more about tactics and actually how we carry things out. And if you just do that, then the culture will follow. What's your take? Are we focused too much on culture? Is culture something that people care too much about? Or are we not focused enough on it?

Pete Behrens (22:01)
You know, I think as a as a word, just as like words like servant leadership or words like agile to get they get used and abused and people get tired of them. So I do agree culture as a word has is tired. But if you look underneath, what is culture representing? One of the terms we like to use is, you know, culture is like a shadow. It's simply reflecting something about us that we can't touch or change directly, but we can influence it. And people feel it like they feel the shadow of culture. They can sense it. And this is where, you know, again, we get into these tensions. You know, this culture is one of the things I use is culture's attention, not attention, but a tension like this, this fighting between sides. And, know, one of these is empowerment or alignment. You know, do we do things together like. Let's take a safe approach and everybody's in the same framework and the same process and the same RTE and the same rhythm. you we have the same rules and we use the same methods for estimating and that's alignment. But we know that taking alignment too far becomes routine and rigid and a death march and, all those negative sides of being in that heavy rhythm. But then we go the other way. Well, let's empower, let's Spotify, like everybody their own ruleset and they can just follow on principles and And then we know we take that too far and we've had this kind of wild chaos and people like, what's going on? And every team's different and we can't align. And this is like one of those elements of culture. You what we talk about is culture is that representation of that tension we're feeling. And it might be about speed and quality. You know, it might be about this empowerment alignment, but it's there. And whether we talk about it or not, it exists. And it influences. We like to use the metaphor of culture is the opposite side of the coin to leadership. And so we can choose to ignore it, but it is going to influence or it does influence us every day. I don't believe while the term is overused, I don't believe our focus on it is enough. And we've shown over and over again when we work with organizations that when leaders put a spotlight on some aspect, of that tension that's happening to your culture, they improve the system. And whether that's tension between leaders and employees, whether that's tension between quality and speed, whether that's tension between, you know, giving autonomy and freedom to doing things together, we can improve that system. And so what we try to help leaders understand is you need to make this part of your understanding and your focus, because if you don't, it will take care of you.

Brian Milner (24:42)
Yeah, yeah. Well, if I'm part of that, I mean, we talked about that, you know, people in the middle have kind of the biggest impact or you can have the biggest impact. That's where a lot of change takes place. If I'm in that middle and I recognize the culture of my organization is not what it should be, you know, we're not really in align with some of this stuff and we're definitely out of alignment with several of these things. What can I do? I can't make an edict across the organization, but how can I start to make that change if I'm in that middle section?

Pete Behrens (25:13)
Yeah, we had a leader that went through a number of our programs for a few years. you know, we have both educational programs, but we also have coaching programs and development programs that can kind of work on developing leaders. He moved to another company and for two years he sought to bring about what he knew to be a better way. Right. He saw the gaps. He saw the tension. He's like, I got it. I know this. But again, single voice. Everybody's looking at him crazy. He hires another person who's been through our programs to help him on his team as an agile coach. Now they got to. OK, now they're starting to sing together. It's a duet. And, know, from him for his perspective, simply it was these these conversation after conversation after conversation, the tenacity, you know, to to to say, give this a shot now. From that, we've been able to provide some more education to some of the HR, some of the senior leaders in this organization. And all of a sudden, the cascade, the dominoes start to fall. And they start to think, now I see what you've been saying all along. And so my message here is everybody can be a catalyst. Everybody can influence. But you're correct in the fact that it is not easy. What we try to help some of these catalysts, these one offs do is simply activate a second step, activate another voice that can help you bring about, you know, a message of change. And that's enough. And I think a lot of leaders get stuck because they like, I can't run a transformation. I can't get focused on this change of metrics or policies or governance. And you're right. You will never probably have access to some of those levers unless you move up the chain enough. But you can influence one other person. You can influence a few people. You can influence one class or, you know, bring someone in to help change our voice. So that's what we try to aim for some of these change agents.

Brian Milner (27:12)
Yeah, I love that. It's kind of the cascading effect, right? I mean, if you spark that one spark into something else, well, as long as that continues, that chain continues, it can spread. It's the old, if I tell two friends and they tell two friends, then this thing is going to work. Yeah, I love that. And that's a great practical thing too, right? mean, because I think a lot of people in that middle start to feel frozen and feel like, What can I do? I can't do anything. I think that's a great point. If you can just affect that cascade into one other area, one other person, one other department, then that's all it takes for it to start to get rolling. I love that. Well, this has been a great conversation. And it's never long enough. And this one, we could go on for another several hours on this one. If you really like this, I'm

Pete Behrens (27:38)
It's hard.

Brian Milner (27:58)
I'm going to encourage you again to visit Pete's site, agileleadershipjourney.com. There's a lot of resources for you there. You can get connected to Pete. And there's a lot of things you can move forward with in your agile leadership journey from Pete. So I can't thank you enough. Thanks, Pete, for taking the time out and sharing your wisdom with us.

Pete Behrens (28:16)
Thank you, Brian. Appreciate the conversation.

#134: How Leaders Can Reduce Burnout and Boost Performance with Marcus Lagré

12 februari 2025 | 28 min

Is workplace stress just about long hours? Not quite. Brian and Marcus Lagré unpack the real equation behind stress—how pressure, complexity, and security interact—and why your team’s performance depends on getting the balance right.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner sits down with Marcus Lagré, product organization coach and author of The Stress Equation, to break down the science of workplace stress.

They explore the differences between mental and emotional stress, how pressure and complexity impact teams, and why security in the workplace is a game-changer for performance. Marcus shares research-backed insights on interruptions, stress contagion, and how leaders can create an environment where teams thrive without burning out.

References and resources mentioned in the show:

Marcus Lagré
The Stress Equation by Marcus Lagré
Certified ScrumMaster® Training and Scrum Certification
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Marcus Lagré is an author, speaker, and consultant with 20 years of experience in software development, from small-team Scrum to massive 50+ team LeSS transformations. Creator of The Stress Equation, he helps organizations tackle workplace stress systematically, ensuring teams thrive under pressure without burning out.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm here as I usually am, Brian Milner. And today we have with us a really special guest, Marcus LeGray is with us. Welcome in, Marcus.

Marcus Lagre (00:13)
Thanks, Brian, pleasure to be here.

Brian Milner (00:15)
We were saying before that I'm actually kind of butchering or Americanizing his last name.

Marcus Lagre (00:20)
Nah, Americanizing, yes, but butchering, no. I wouldn't say that.

Brian Milner (00:24)
So I'm gonna give you a chance to set the record straight. Why don't you tell us the actually the correct pronunciation? Because I probably can't do it.

Marcus Lagre (00:31)
Well, my... I would say La Gré, but that's with a Swedish southern accent and not even most Swedes do that, so...

Brian Milner (00:34)
Okay. OK. Do the Swedish people look on people in the South like we do here in America? Like they're kind of more laid back and slower and... That's funny. OK. Well, we have Marcus on because, first of all, Marcus is a product organization coach. He's an author. He's a speaker.

Marcus Lagre (00:48)
Yeah, yeah, I would I would say so I would I would say so yeah

Brian Milner (01:03)
And he has a really great book that we wanted to kind of dive into the topic of here. Because in this day and age, this is a really important topic, but his book is called The Stress Equation. So you can kind of see where we might be going there with that. Well, so let's dive in. Let's talk about that a little bit. And I think probably a good place to start would be, how would you define then stress, when you, if we're talking about stress and the stress equation, how do you define stress?

Marcus Lagre (01:30)
I usually use the definition of stress because I let's start like this. I think that most people have like a too narrow perspective of what stress is. Like most people probably see it as working long hours and you know, spending a lot of time at work, but it doesn't necessarily have to. And there's this definition of stress from the Oxford English Dictionary that I found really well that stress is the result of, of, of, emotional or mental strain due to adverse or demanding circumstances. So yeah, so there's differences there. And I think that most people, if you're not in a very toxic environment, you don't suffer from emotional stress a lot at work, but mental strain is probably what we're looking at most often.

Brian Milner (02:04)
Yeah. Okay. Yeah, I mean, I, you know, I wouldn't discount that entirely. I think that there's probably a lot of people out there that have the emotional strain of a bad boss or manager or something like that, right? But yeah, hopefully, you know, hopefully you're right that the majority might not be, you know, dealing with that. It might be more of the mental side of this. So what is mental stress then? What is a mental strain?

Marcus Lagre (02:38)
Well, mental strain is usually diversified by saying like emotional strain is like the stress from being like in a toxic environment, for example, which is more common than it should be. But mental strain is more of the when you have too much of a mental load, like you're trying to solve a complex problem, like you have high cognitive load in order to solve it, or you need to

Brian Milner (02:48)
Hmm.

Marcus Lagre (03:03)
Well, it's also related to cognitive load that you have a lot of context switching. So you need to change information in your working memory quite often and a lot. And that can lead to mental strain. And the problem with mental strain, as I see it in white collar worker or knowledge workers, is that most of us are, we like mental challenges. We like puzzles, we like solving problems. So we're not great at identifying when a mental challenge becomes a mental strain for us. We're used to just pushing on. we try to just, you know, it's just something that I haven't figured out yet. If I push myself just a little harder, I'll crack it. Yeah.

Brian Milner (03:42)
Yeah. Yeah, that's great. Yeah, I mean, I think you're right. We do like puzzles. We do like challenges. I I know one of the popular things here in the US is the escape room kind of thing. I don't know if you guys have that there as well, but we actually pay people in our free time to give us puzzles and challenges that for fun, we'll go and put ourselves under some mental duress and try to figure out. So I think you're right. there is part of us that really wants to do that. Well, if that's true, then the other side of that is, shouldn't we all be under some kind of mental stress then, since work is challenging and complex and hopefully.

Marcus Lagre (04:20)
Well, yeah, I mean, not all stress is bad. So I usually say that the stress that we feel at work usually comes from two different sources. So this is the equation. Like the mental strain comes from the complexity that we need to, now that we need to handle. Either the complexity of the problem that we need to solve, or if we're working in, the complexity could also be like the frustration of working in an inefficient organization. That could be part of the complexity.

Brian Milner (04:23)
Yeah.

Marcus Lagre (04:46)
So I usually say that pressure is our sense of urgency. The pressure comes from our sense of urgency in order to finish the work that we're, the task that we have at hand or whatever it is that we're trying to solve. And the complexity is whatever makes it harder for us to actually finish that work. So to relate back to what you were saying, shouldn't we be under some kind of stress? Yes, we should. If we don't have any sense of urgency, we're probably not delivering at all. And if there's zero complexity in what we're doing, That should probably be an automated task long ago. We will probably suffer from severe boredom if there's zero complexity in what we're doing.

Brian Milner (05:25)
Yeah, I always, you know, this comes up sometimes in classes where, I think, you know, I want to find those people who are under zero pressure at work, because I've never been in that situation. I've never had any kind of boss or organization that was like, just take as long as you need. It doesn't matter. There's always some pressure and some places it's more than others and some places it's extreme. But yeah, I think you're right. There's a right amount of pressure. that can be applied.

Marcus Lagre (05:48)
And there's also constructive stress. I usually diversify like constructive stress is when you try to achieve something because if you're under a lot of pressure solving something very complex, there's also pleasure in actually solving it. So there's some kind of release in the end. But if you're constantly under a lot of pressure or...

Brian Milner (05:51)
Hmm.

Marcus Lagre (06:09)
I usually say that the pressure usually comes from things like how we set deadlines, how we handle our backlog. So if you have two short deadlines, then you're under negative stress or unconstructive stress, or we have an ever-expanding backlog. We can never finish everything in this backlog. have no way of saying no to things. They just keep piling on. That's unconstructive stress, but...

Brian Milner (06:30)
Yeah.

Marcus Lagre (06:34)
A sense of urgency to reach like a goal? That's more of positive kind of stress.

Brian Milner (06:39)
Yeah. Yeah. I I've heard, my boss, Mike Cohn talk about before how scrum has just the right amount of pressure that it's, it's not, you know, it's, it's not the kind of, when we think about commitment and stuff inside of a sprint, it's not the kind of thing of, you're going to lose your job if you don't make this sprint commitment. But it is kind of, you know, my, my word is on the line. My name is on the line. And if I don't deliver. I'm letting down my team, I'm letting down those around me. So that's way he describes it. It's kind of just the right amount of pressure that's kind of baked into the way Scrum works. I've always liked that. I've always thought that's kind of a good take on that. So we're kind of in these pressure cookers a little bit, right? We've got pressure and sometimes more than others and we do need some kind of pressure. So we have some sense of urgency in what we're doing. How does this align with our Agile Manifesto kind of ideal of working at a sustainable pace? Is the pressure going to crack us under trying to keep a sustainable pace? And what if we don't have any say over the amount of pressure we have?

Marcus Lagre (07:46)
Well, if you don't have any say, then I usually say that the pressure isn't a force of nature, that it usually stems from someone's decisions. And if we don't have a say in it, then we can't influence that pressure really as a team maybe. But from a leadership perspective, if you put unlimited pressure on the team, you're gonna see decreasing results anyway. It's not... constructive, you're going to burn your people, you're going to lose, worst case, lose them from the company, either because they change jobs or because they burn out and they have to go on sick leave. So and that's going to cost you in the end. But also that you're going to see either a lot more well, as I said, either a lot of people leaving or people doing quite quitting. That's that's what's going to be because once caring about your own performance becomes dangerous, people are gonna put in the bare minimum. That's the people you're gonna keep.

Brian Milner (08:41)
Yeah. Yeah. I'm sure there's lots of research baked into this and you've probably crossed a lot of different studies and things that have kind of jumped out at you. And to me, that's always one of the things that's the most interesting when I dive into a topic like this and go really, you know, kind of knee deep into it. what, was there any kind of research that you stumbled upon as you were preparing for this or, you know, creating this book? that really kind of surprised you or that you found extremely interesting? Any studies out there around the effects of stress that kind of shocked you even maybe?

Marcus Lagre (09:18)
I wouldn't say shocked, but one thing that surprised me was that there was this study that showed, because I talk in the book about complexity, and I mentioned earlier that if you need to change the information in your working memory a lot, that leads to mental strain. But there were actually studies that showed that interruptions in work does not lower the quality of the work. It does, however, increase the sense of stress. But it doesn't necessarily lower the quality of work, which was something that I was absolutely convinced it would. However, there was a correlation between how far if you got interrupted, if it was on topic, so to speak, so that you didn't have to throw everything out of your working memory, then the quality level was still on par with what you would have seen if you weren't interrupted. However,

Brian Milner (09:48)
Yeah.

Marcus Lagre (10:06)
if it was something that was diametrically different to what you were actually doing, then yes, the quality would also drop. But I actually thought there would be like a clear correlation between interruptions and lower quality of work. And it wasn't.

Brian Milner (10:20)
Yeah. So it's not, I mean, what I'm hearing is it's not necessarily the interruption itself. It's the content of the interruption. And if the interruption is, you know, taking you wildly off track from your thought process, that's higher stress kind of a reaction to it. And that leads to more problems. But if it's, if it's an interruption that's near in the same area of what it is you're working on and thinking about, then it's not as hard to get back to it. Less stress, less, let's kind of end result effect, right?

Marcus Lagre (10:52)
Yeah, there's less mental strain in that scenario. However, you do often feel like you're less efficient, that you get less joy out of what you're doing if you get constantly interrupted, and that the workload is heavier than it actually is. So there's negative sides to getting interrupted a lot, but as long as it's sort of on topic, as you say, it's not really that harmful.

Brian Milner (10:54)
Okay. Yeah. Well, I know you do a lot of work with organizations and with leaders and organizations. And I know one of the difficult things, difficult kind of parts of having these conversations with leadership is trying to help them to understand the importance and kind of the impact and why this is important in a business sense to them. Not just that, you know, the way I phrase it in classes, it's not just that it makes you a better person, right? which there's value in that. not negating that being a good person is bad. I'm just saying from a business sense, oftentimes leaders want more than just saying, yeah, I'm a better human by doing that, but is it better for the business? So how do you have that conversation with leaders, with organizations to say, this is actually an important thing to focus on. This makes an impact on your business.

Marcus Lagre (12:07)
usually the challenge is to get leaders to understand that they are also affected by this. Because a lot of the challenges I see in organizations is that I come in and I usually do like an analysis of the organizations, ask around, do interviews and analyze everything. And what I come up with is rarely news to the leadership. They have seen the same thing. The problem is that they never had the time to just sit down and figure things out because they're constantly rushing between meetings. They're constantly rushing to do various budgets, updates, stuff like this, just keeping the mill going. So I usually say that they're too operationally occupied to take a look at the strategic goals and the strategic direction that they need to be going in for the business to run smoothly over a period of time. And so I usually tell them that the most important thing that you can get yourself is like an hour, at least every week that you just sit on your rear end and just contemplate things. I usually use a different word than rear end when I tell them this, just to drive the point home. But yeah, they need to find time. where they can just like no phone, no computer, just sit down for an hour and let whatever enters your head, enter your head because otherwise you will never figure this out. And you don't have to pay people like me premium to come in and tell you things that you are actually clever enough to figure out yourself.

Brian Milner (13:41)
Right, right. Yeah, so that's so interesting. So it's hard to convince them that stress plays a big impact on their work. I hadn't really thought of it from that perspective, but that's a great point to make. If you can help them understand the impact it has on their work, maybe it's an easier conversation than to say the impact it has on your teams or on your employees' work. Yeah.

Marcus Lagre (14:06)
I have never, mean, stress is contagious and it ripples down. If you have a really stressed out management, you're gonna have stress in the rest of the organization as well, like on the floor and in your teams. That's just a given, I would say.

Brian Milner (14:11)
Yeah. Yeah. All right. Well, so I'm following along. I think this is good. So we're talking about how you kind of explain this a little bit more to leaders and help them understand the impact. What about when you get one of those leaders who's just, and I know I've had these before where they're kind of more old school and they look at things and think, you know, you... Well, on your graph of pressure, right? They're much more leaning towards the higher pressure side to place on employees because they take that attitude of, you know, the old phrase that we all hate, work expands to fill the time allowed or whatever that thing is, right? How do you convince that person that, you know, there's an okay amount, but you're kind of really skewing it to the high end and this is now going to have an adverse effect?

Marcus Lagre (15:00)
yeah, yeah,

Brian Milner (15:12)
on what you're ultimately trying to do.

Marcus Lagre (15:14)
My usual angle of attack is to address the complexity of the part of the equation. I probably can't get them to understand or accept that they're applying too much pressure, but what they're actually trying to achieve is to get more output. I mean, that's the goal of their actions. And so I try to get them to understand the complexity that their teams are working under and try to get them to understand that you need to reduce this in order to free up more time and mental bandwidth for output. And that's usually a better way forward than trying to get them to accept that you only get so far with a whip. Once you've whipped one time too many, people are going to just stop caring.

Brian Milner (16:02)
Yeah. Yeah, you can't come back and use that tool over and over again. It's going to have kind of the opposite effect that you're hoping it will have eventually, right?

Marcus Lagre (16:14)
People are going to start telling you about problems, for example, because these people are usually the same people who don't want to hear about problems. Don't tell me about problems, tell me your solutions kind of attitude. And I usually get them to understand that you have absolutely no idea what the problems of this organization is, because people are afraid to tell you.

Brian Milner (16:22)
Yeah. Right. Yeah, that's such a huge point, I think, for leaders to kind of soak in and understand. If you have that culture, if you are generating that culture of fear in the organization of, don't come to me with problems, only come to me with solutions, then you're right. You're absolutely right. You're closing yourself off. And you're kind of establishing the norm that if there is an issue, The last thing to do is to raise it, to let people know about it, live with it, right? Just kind of exist with a status quo. If there's a problem, then you just have to learn to live with the problem.

Marcus Lagre (17:09)
Live with the problem or game the system so the problem isn't apparent.

Brian Milner (17:13)
Right, right. So back to the equation then. So your equation here, pressure times complexity over security. I don't know what we've talked much about security so far. So how does that come into play when you calculate this kind of pressure equation, stress equation?

Marcus Lagre (17:25)
Bye! Yeah, well, we kind of touched on it now, like with leaders who act in a way that lowers the security or the sense of security. So I define security as the freedom from fear at work. And psychological safety is one part of that. But it's also that you feel that you have... I'm sort of reluctant to use the words servant leadership anymore because there's sort of... sort of become a tainted word in some ways. People see it as a passive leadership style, which is not really, I don't quite agree with that, but security is in essence that you are able to take high pressure and high complexity if you feel that you have the management in your back, that you're taking it on as a team, that you're not alone with all of that pressure and all of that complexity, but you have people around you who you can rely on and ask for help. If you have that, then your security is higher and then you can take more pressure, you can take more complexity without burning out.

Brian Milner (18:32)
Yeah, yeah, that makes complete sense because if I have the kind of that sense of security that I'm not at risk, I don't feel like I'm being put in a position to fail so that I'm now in danger, but I've been given difficult problems because I have been trusted to conquer them. I've been trusted and empowered to kind of overcome them. That's such a different approach and mindset from an employee standpoint than, my gosh, I got to do this or I'm going to get fired.

Marcus Lagre (19:05)
Exactly, there's probably, management has probably let me know that we understand, we're handing you like a really tough thing to solve. if you need anything, if you need any resources, if you need any extra help, just ask us for it and we'll solve it. And in that situation, you're a lot more likely to... be able to get into that without burning out simply because you know that I have the management backing me up.

Brian Milner (19:37)
if I'm one of those employees who's under a high pressure environment, and I don't really feel like I have the power or authority to make that change, what can I do about it?

Marcus Lagre (19:50)
I mean, the thing that you can do is to change what I usually, one of the reasons why I wrote this book is that stress is one of the leading causes of mental illness and sick leave in our line of work, which is software. So if something is the leading cause of a problem, it's probably systemic, it's not individual. So one of the most important thing, that you can do is to identify what in the system is causing the stress in me, because ultimately stress is a subjective feeling. it manifests itself in people, but you can get the tools to identify what in the system is causing the stress in me. that can be quite a relief to not put that... I mean, put additional pressure on yourself by thinking that you're the one who's bad at your job or you're the one who don't have the correct coping mechanisms for the situation. The situation might actually be insane.

Brian Milner (20:51)
Yeah. Yeah, it's that subjective nature, I think, that is kind of a variable that I would throw into this equation. It's sort of like, I know one of the things I found really fascinating in kind of the earlier history of Agile and the idea of a sustainable pace was originally there was kind of talk about saying, using words like, no one should work more than 40 hours a week. But then that got changed to sustainable pace because of the realization that for some people 40 hours was too much and for other people 40 hours was not enough. And so that idea of sustainable pace was, it's individual, it's different to different people and that's part of what we got to do is know ourselves enough to know, hey, I'm kind of slipping beyond that point where I can sustain this indefinitely.

Marcus Lagre (21:37)
Yeah, and I think that's one of the myths that I want to bust a little bit is that, you know, it's not about 40 hours. It's not about the hours. I mean, there are some people who can work 60, 80 hours without burning out. So it's not the hours. It's something else. You know, so it's the end of the... Maybe it's the pressure that we have too much pressure. Maybe it's that we have too high complexity in combination with pressure. Maybe it's that we are in a toxic environment. So it's like how much mental energy do I need to handle the context that I'm in? That's.

Brian Milner (22:13)
It's almost like there needs to be kind of this balance between those three things that you've got to, one thing might go a little higher, but the others then have to drop a little bit so that it kind of equals out, right?

Marcus Lagre (22:22)
Yeah. That's what I, like, I always say that if you want to put high pressure on your teams, on your organization, you have to reduce the complexity because you can't do both at the same time. Those are the two variables that increases the stress. But then as we mentioned, like feeling of security is the lowering factor. So you always do well working with

Brian Milner (22:38)
Yeah.

Marcus Lagre (22:46)
the sense of security within your teams and working with your culture and making sure that toxic behavior is simply not acceptable in this organization, for example. And so that's always, you always get a reduced level of stress from that kind of work. But as I said, if you have high complexity and you put too high pressure on something, it's gonna break sooner or later. You're either gonna break your people or you're gonna break your product. because you're going to reduce the quality of the work because you have to stress through everything. And quite frankly, I don't care about your product. You're free to break it if you want to, but breaking people, that's just not okay.

Brian Milner (23:18)
Ha ha. Yeah, now we're back to being a good human, right? mean, these are humans. They're not AI programs, at least not yet. And they have lives. the more that you, like you're talking about, the more that you increase that pressure on them or decrease their sense of security, the less complexity they can handle. And you know, You have diminishing returns on your employees, on their productivity.

Marcus Lagre (23:48)
It is unsound business.

Brian Milner (23:50)
Yeah, yeah, absolutely. Well, this is fascinating. I really appreciate you coming on and talking about this. Again, for anyone listening, if this topic is interesting to you, highly recommend you check out the book, The Stress Equation by Marcus Le Gray, even though that's not actually the way to say the name. it's L-A-G-R-E, just so everyone knows. I don't want you to struggle searching for it if you're looking for it. We will put the links to it in the show notes for this episode so that you don't miss out if you're trying to contact Marcus or you want to know more about the book. We'll make sure you find a way to do it. So Marcus, I really appreciate you coming on. This has been a fascinating topic and I appreciate you sharing your wisdom, your research and your knowledge on this with us.

Marcus Lagre (24:31)
The pleasure was all mine, Brian.

#133: Trending Agile: Scrum Masters, AI, and the Future of Agile

5 februari 2025 | 37 min

The Agile Alliance partners with PMI—what does it mean for Agile’s future? Plus, how AI is reshaping Scrum Master roles and why honesty (even when it stings) is the key to career growth. Brian Milner and Cort Sharp tackle these hot topics in a no-holds-barred discussion.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner and Cort Sharp dive into the recent Agile Alliance-PMI partnership and its potential impact on the Agile community.

They also explore AI’s growing influence on Scrum Master roles—will it replace them or elevate their value? Finally, they tackle a tricky but crucial topic: when to speak up in the workplace, balancing honesty with career preservation.

If you want to stay ahead in Agile’s evolving landscape, this is a must-listen!

References and resources mentioned in the show:

#32: Scrum in High School Sports with Cort Sharp
#82: The Intersection of AI and Agile with Emilia Breton
#129: 2025: The Year Agile Meets AI and Hyper-Personalization with Lance Dacy
#132: Can Nice Guys Finish First? with Scott Dunn
Mike Cohn’s Better User Stories Course
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Auto-generated Transcript:

Brian Milner (00:00)
Welcome in. Welcome back, everybody. This is the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today, we're going to do something a little different. We're in this mode right now. We've kind of been open to some suggestions recently about maybe we should try some experiments and try some different things. And so today's going to be one of those little experiments. We have someone that's going to be with us, Mr. Cort Sharp. So welcome in, Cort.

Cort (00:23)
Hey Brian, thanks for having me on.

Brian Milner (00:26)
Absolutely. Cort is our community manager for the Agile Mentors community. And Cort and I do classes together a lot. He is often the producer in the classes. So we see each other a lot. We talk a lot. Cort's also a certified Scrum professional. So he's been doing this and has encountered Scrum in some kind of unusual circumstances as well. He's a high school swim coach. There's an episode that we talked about that. way back so that anyone wants to dig that out, they can go back and find that and learn a little bit more about it. But we just thought it would be good to have maybe periodically a little check in about maybe some stories that have come up in the news about Agile or things that have been flashing through social media feeds or anything like that. know, Cort and I are a little bit different age groups, a little bit, more than a little bit. And I'm sure the of things that cross court's radar may be a little bit different than the things that cross mine. And we just thought maybe it would be an interesting kind of thing to have a little discussion, the two of us, about some of these major burning issues and things that people are talking about on LinkedIn and Twitter and, I'm sorry, X, anywhere else. I'm going to kind of... Give the reins over to court here a little bit, because I know he's pulled some things that he wants to talk about, and we'll just kind of see where we go.

Cort (01:40)
Awesome, yeah, thanks Brian. Not just X and LinkedIn, we're also looking through Instagram, YouTube Shorts, where the cool kids hang out, I guess is. That's at least what my swimmers tell me.

Brian Milner (01:50)
Okay, okay I Got it I got a yeah, I you know, I had to learn a lot about an Instagram with my daughters and I still don't get it. just I mean I have fun flipping through stuff but I don't I could never like get a following there because I just don't understand how to Do all the but that's old guy talking. So

Cort (02:11)
It's a weird place, Brian. I don't blame you. It's totally good. But I've seen a few things come across my feed, and we've kind of had lighter versions of this conversation, whether it's in classes or just kind of on the side or something like that. So we just kind of thought, hey, let's sit down and actually go into depth about this, because I'm curious what your thoughts are on some of these things. And I don't know.

Brian Milner (02:14)
Yeah

Cort (02:35)
Hopefully I'm able to add into the conversation a little bit more than just here's a young guy yelling at a cloud instead of an old guy yelling at a cloud, right? No, I hope not. But let's come out and I'm gonna come out swinging at you. So the biggest news bite that I have found over the last couple of months or the last month-ish is that the Agile Alliance and PMI

Brian Milner (02:37)
Ha ha. young guy and old guy yelling at each other. That's not what anyone wants to hear. Yeah. Yeah.

Cort (03:02)
have entered, have announced that they're entering a partnership. We don't really know a ton about what that partnership looks like, but it is presumed that the Agile Alliance will be hosting some kind of content through PMI or PMI will be hosting some kind of content that the Agile Alliance has created. So I'm just curious, like, what are your thoughts on that? Do you think it's a good move, bad move, any kind of potential impacts that you see? It's a big one.

Brian Milner (03:30)
Yeah, way to start with a softball that we just, yeah, mean, it's obviously a hot button topic right now. I've heard lots, I've read lots of opinions of people on different kind of forums and discussion boards and things where people are talking about kind of, what does this mean? That kind of thing. And so here's kind of,

Cort (03:34)
Hahaha

Brian Milner (03:57)
Here's kind of what I've heard from both sides, right? The people who are kind of anti feel like this is maybe a little bit of a betrayal. And I think that the reasoning behind that kind of feels like maybe historically or somewhere maybe further into the past, the PMI may have been a little bit of an antagonist towards the Agile movement, or some people feel that way. I'm not saying this is my opinion, but this is what I've heard. Some people might feel that way. And so they feel like, would you attach your name to something like that? But I've also heard from people who are pro and have said, look, the basics of the deal are that it's not going to change anything for the Agile Alliance other than the name. It's officially the PMI Agile Alliance. But other than that, what I've heard from people who are board members that have posted

Cort (04:43)
Sure, yeah.

Brian Milner (04:50)
from the Agile Alliance have said, it's just nothing more than our name is now different. We're autonomous. We can still do the things we've always done. And we feel like the connection to this larger organization will enable us and help us. And I know the Agile Alliance has gone through some tough times, as a lot of us in the industry have, with the conferences. At least I know the conferences last year was kind of not what people have hoped, and not just the Agile Alliance conference, but other conferences have had down attendance and other things. Maybe just a sign of the times, I don't know. But personally, I kind of look at it and I got to preface this. got to, before we talk about anything else, right? Because now we're going to get into opinion. But I would just say, let me preface by saying the opinions you are about to hear. are not the official opinions of Mountain Goat Software. They are just the opinions of the individuals that you will be listening to. So this is just one guy's opinion, right? I think I would just say I get it from both sides. I understand. I see kind of the concern. From the people who are pro and they say, look, it's just the name, I don't know why anyone would freak out about that. It's just a, we're just putting letters PMI in front of our name. hear that, but I've also heard other people counter that to be like, yeah, but it would be like Greenpeace saying, you know, we're now Exxon Greenpeace, you know? And I don't think, I think that's quite, you know, a huge overstatement. I don't think that's the same thing at all. And I, you know, I recognize that the PMI has, you know, they've adapted. anyone who thinks that they're the same way that they've always been, I think is wrong. I think that they have incorporated over time more and more agile ideas into their certifications and other things. they certainly, I feel like they've recognized the agile sort of the future and they've tried to invest more heavily. I think this is a sign of that as well. They're trying to invest a little bit more into agile because they see it as, you this is the future of project management. You know. But they also see it as one of the paths. It's one way of doing project work. And it's not the only way. There are other ways that are good as well. I don't know that I disagree with that. Depends on the project. It depends on what it is you're trying to do. But we talk about this in class. If I know what it is that we're going to make, I know exactly how to make it, the customer knows what they want, and we're not changing anything along the way, then

Cort (07:02)
Yeah. Yeah.

Brian Milner (07:16)
Agile may not be the right way. But if any of those things are not true, then I think Agile is the right way. end of the world, no. I don't see it as the end of the world. I don't see it as the sky's falling. I think it is a sign of the times. I think it is sort of a benchmark kind of thing to say, wow, things have reached this point where they've joined forces. I think that's not an indication of either side bending a huge amount, but that both sides have bent and met in the middle. And that's kind of my opinion on it. The sky's not falling, but I don't really know how it will change things moving forward. They tell us it's not going to really. We'll see.

Cort (07:58)
I think I agree with a lot of what you're saying. And that's what I've seen as well amongst the social media spheres. Kind of a lot of discourse of, this is really bad, or, this is not as bad as you think it's going to be, or, this is actually really good. Because I think one point that I agree with a little bit more so is, in principle, at face value, This might not be what the Agile Alliance was founded on or anything that goes, or I wouldn't say anything, but it doesn't align with the foundational values of the Agile Alliance. But in the long run, I think this might be pretty beneficial for Agile as a whole, because PMI is massive. They have a huge reach, very big name recognition, and for them to acknowledge, not only acknowledge, but acknowledge in this way and bring in Agile into this space within their reach, I don't see a ton of harm that could really be brought to it purely on the basis of our reach, PMI's reach is significantly larger than the Agile alliances. So it just helps Agile grow a little bit more so and get a little further reach. Do you agree with that? you disagree? Thoughts on that?

Brian Milner (09:14)
Yeah, I mean, I've heard Mike say this before, where he says, you we talk about partnerships, you know, who's bringing more to the table? Is the Agile Alliance funneling more attention, eyeballs to the PMI by this Alliance, or is the Agile Alliance getting more eyeballs and more attention because of the audience of the PMI? I would think it's the Agile Alliance is getting more. Like you said, I think the PMI is a huge behemoth, pretty highly recognizable. their certifications have been out. They're kind of one of the first of those kinds of certifications that existed out there. And I just think that they're probably bringing more to the table to the Agile Alliance than the Agile Alliance is bringing to them.

Cort (09:56)
Yeah, yeah, the Agile Alliance is kind of getting the better end of the deal, so to speak, as far as exposure goes.

Brian Milner (10:00)
Yeah, but I think time will tell. I think that's really what I would say to anyone is just don't freak out too much yet. You need to just wait and see what will happen. When the moves happen, if something happens, it's like all of a sudden now the Agile Alliance can't in any way talk about how traditional waterfall is not a great way of doing things. Well, now I would raise the alarm and say, OK, well, now you see the compromise. But if that doesn't happen, if it truly is, as I've been hearing, it's just a naming, we're autonomous, I don't see the grave harm.

Cort (10:33)
Right, right. Right. I think one thing that's kind of overlooked or maybe just a little glazed over that people didn't pay too much attention to is they didn't announce this as a merger. They announced this as a partnership. So to me, when I hear partnership, hear two entities working independently with a common goal of whatever it may be.

Brian Milner (10:54)
Yep. Yep. Yeah, a little insider baseball on that because I have heard some discussions around that as well. And just what I've heard is, there is a trickiness there because the agile Alliance is a nonprofit organization. And so from a for-profit organization, you cannot acquire a nonprofit organization unless that nonprofit organization changes and becomes a for-profit entity.

Cort (11:28)
in for profit. Yeah.

Brian Milner (11:31)
I'm not a lawyer. I don't know any of that kind of insider, the legalese that's around that. But I've heard a little bit of conversation around the fact that it might have been an acquisition had they been a for-profit company. But since they were a nonprofit, it's a partnership. So that may be the case or not. I don't know.

Cort (11:50)
So that brings up just a question to me then. A lot of times when companies merge, they tend to merge as either an industry or a sector is kind of starting to go down, trickle down a little bit. And they merge as a method of of like bulking up, strengthening where they can, trying to... that they acquire, they merge in order to withstand the rough times. Do you think that that might be what's at play here? Where just from a business perspective, this is kind of the business smart move for both entities, both organizations, so that they can withstand, I think I saw somewhere like a 35 % reduction in middle management positions, postings or something like that, right?

Brian Milner (12:31)
Yeah. Yeah, absolutely. mean, I think, the, the past few years have been kind of difficult economically. please don't think I'm being political and saying that at all. I'm just, yeah, I can only state what I've, I've seen and heard from other people in the industry. And I've, you know, I've heard about people talking about less job postings, those going down. I've heard about, know, trainers and coaches and other things. you know, losing percentages of their students or their coaching engagements or other things. So I've just heard that it's been, and we've kind of experienced some of that as well, decline a little bit. I don't think it's that one of those two entities had a decline. I think they both are kind of recognizing this is a tough economic climate and strength in numbers. You know, if we can support each other and maybe that's the path forward is that we kind of combine forces and combine and conquer a little bit. So I think you're right. I think that may have forced it and it's just the opportunity presented itself.

Cort (13:37)
Just kind of a contextual thing where the context of kind of where we're at right now. That's really what drove it. Yeah, I can see that. could totally see that. Awesome. Well, let's jump over to our next kind of topic right now. Everyone's favorite topic right now, AI, right? We've talked about it substantially. But kind of with that whole idea of

Brian Milner (13:52)
Sure. Yeah. Yep. Yeah.

Cort (14:03)
or that little note that we had there of these mid-level management positions, we're not seeing them rise in open positions. We're kind of seeing them get squeezed down a little bit. We're seeing them reduced. And a lot of that is attributed to AI, where a lot of these mid-level management positions are tasks that can be done by AI, because a lot of it is kind of this data analysis stuff and what do we move forward with? Relating it to Scrum specifically with AI being on the rise and Scrum Master roles appearing to be bringing less value as a result, because I think you've seen it, I've seen it a lot. A lot of my friends are talking about it. I've seen it a lot on social media. Actually one Instagram reel that sticks out to me right now is someone was like, hey, do you want to get into tech without having to learn how to code, be a scrum master. It's super easy. You just take a two day course and you're going to make $110,000 a year or whatever. And it's like, you know, little tongue in cheek, but at the same time, I think there's some truth to what that real was saying. Um, however, with that, I think a lot of scrum masters are being shoehorned into roles or have been shoehorned into roles of. Logging meetings. creating meetings, facilitating those meetings and then entering in the next one and saying, Hey, everyone has to show up here and, you need a story point this. I need point values for this bug before we start working on anything. and a lot of that seems to be replaced with AI or at least is able to be replaced with AI. So Scrum Masters now are in a position where they have to drive more value. where, where do you think Scrum Masters? in their role can bring more value? And do you know of any resources that are either widely available, freely available, available at a lower cost to help Scrum Masters learn how to actually bring more value to their role?

Brian Milner (16:04)
Yeah. Well, the first thing I'll start off in saying is, you know, one of the great things about living in today's world is there is so there's such a wealth of information that's free. You know, I can learn how to do, I can learn how to cook anything in the world by just finding the video on social media and not all of a sudden, you know, I've got everything I need to make a great dish. I may not taste the same as the person who did it, but you know, I can learn how to do pretty much anything. I can Google, you know, how to You know change out my doorbell, which is one thing I did over the holidays You know like that's the kind of thing that there's a full video showing exactly it step-by-step Here's how to do everything and and I think that you know for Us a scrum masters. There's there are some skills. I think that are gonna be More and more relevant more and more needed and I think you just have to put yourself in the frame of reference of what would AI do a good job of? this is such a answer because if my job as a scrum master is to just schedule meetings, well, then yeah, I'm in trouble because an AI can do that really easily. And you don't even need AI for that. All you just need is to have people enter when they're available. There's dozens of websites where you can do that. do that. My D &D group does that to try to find the nights we can play. It's easy to do that, and you don't need any AI for it. So if you reduce what a scrum master is down to something as simplistic as let's schedule meetings, well, then yeah, you're in danger. I think what's going to happen is that more and more, it's going to be the soft skill kind of things that are going to differentiate the Scrum Master profession. I think that AI is going to have a hard time with managing interpersonal relationships. It's going to have a hard time helping the team navigate through conflict. It's going to have a hard time picking up on details, how safe does the team feel, how well are they working together. AI can do certain things really well, but there's a reasoning that's not there now. I don't know if that's coming. I don't know if that's tomorrow, if that's 10 years from now, or a year from now, or six months. But I know that now, even though they say thinking or other things like that, it's not really thinking. It's just digging up more data. And it can process a large amount of data and give you some insights from it. That is something that it does well. but it can't intuit, you know? It doesn't have emotional intelligence. And yeah.

Cort (18:47)
Yeah. Yeah, think one spot or one really good definition of where AI is fantastic that I read recently is AI is absolutely incredible when there is a set of very clear specific rules. So the book that was reading that said that they use chess, example, right? Where chess has a very, as a set of very specific rules. and AI can beat any grandmaster easy. Really just like chess.com can beat any grandmaster at this point, right? Because it's able to analyze potential outcomes based on a set of rules and a scenario that it's given in. Whereas a lot of humans, we think, or a lot of human chess grandmasters, they think in a way of like, here's one specific strategy that has worked in this scenario. I'm going to go that down that route. So AI can inference, so to speak, they're going to go down this route because that's what has happened in the past. And based on that set of rules that has happened in the past, here we go. So I think you're entirely right with those softer skills where you're interacting in a space that has some guidelines, but not necessarily a set of clearly defined rules is where AI is going to struggle right now. Absolutely. Yeah, totally.

Brian Milner (20:07)
Yeah, I'll tell you, Cort, too, one of the things that I'm really interested in, and I've talked to you about this and some other people, I'm really interested to see how AI, especially for coding, because more and more coders are taking advantage of coding assistants. And there are some stories out there and some companies that are more and more reducing the reliance on a person to code and using more AI to do coding. Some claim that they can do it all with AI. I would be really suspicious if there's no human involved at all. But what I'm really curious about is how does it change the process? If you are using an AI coding assistant, Does that change any other part of your process? How do you verify that the code that the AI has produced is correct? Is there a pairing? Is there a peer review of that that the team does? I suspect that there's practices and things like that that are popping up all over the place that just haven't been codified yet. There hasn't been a white paper that says, here's what you do. to try to ensure that it matches well with the rest of the code or here's how you know that it matches your standards or other things. I suspect that there's plenty of those kind of things out there and I'm just kind of waiting to hear those reports.

Cort (21:25)
Right? Yeah. Yeah, think, gosh, was, was Mark Zuckerberg was on the Joe Rogan podcast not too long ago. and he was saying like, yeah, by the end of 2025, Facebook is already doing it or Metta is already doing this. Sorry. Metta is already doing this where they're starting to replace their mid-level programmers, their mid-level developers with AI. And Zuckerberg was saying like, it's expensive right out of the gate.

Brian Milner (21:54)
Yeah.

Cort (21:59)
Right. It's going to be a lot of time, but we see the value in this long-term. so I wonder if, if that white paper is going to come from either meta or alphabet or one of those ones, right.

Brian Milner (22:09)
Yeah. Well, the domino effect of this is also going to be fascinating to watch because you said that they're talking about mid-level. I've heard a lot more about junior level being replaced, Like the entry level kind of stuff. And so, okay, let's say you do that, right? And you're hanging on to your senior people who have the experience. What happens when they move on? Right? When those senior people are gone, you haven't had anyone coming up the pipeline because you replaced it with AI for the junior stuff. And you're depending on more senior, more skilled advanced people to verify, to go through and fix the issues that AI is producing. They're going to be gone. They're going to retire. You know? So I don't know how that, that will be my first question to someone like Zuckerberg about that.

Cort (22:54)
Right? Yeah. Yeah.

Brian Milner (23:02)
when they said something like that is, what's your continuity plan for moving up programmers into more senior skill level? How are you going to build that into your long-term process if you're going to replace junior and mid-level people with AI? That's going to be a train wreck that's going to happen at some point.

Cort (23:27)
I, cause a lot of times we talk about in courses or I've heard it a few times and I totally agree with this and subscribe to this idea that the goal of a scrub master is to work themselves out of a job. So I wonder if it's that kind of same kind of mentality that these bigger tech companies have with AI of, know, AI is going to work a developer out of a job or a developer is going to work themselves out of a job through AI being able to. code better than them, faster than them, be more precise, stuff like that. However, caveat to that, Mike was the one that said the goal of a scrum master or a good scrum master should be to work themselves out of a job, comma, I've never seen that happen. So Mike has never seen that happen, right? I don't think you've ever seen that happen. I've never seen that happen. I don't think anyone's really ever seen that happen. I don't think any scrum master has successfully done that.

Brian Milner (24:10)
Right.

Cort (24:20)
so I wonder if it's going to get to that, that kind of same point where it's like a developer will never work them themselves out of a job. It's just the cost of entry to a good developer job or to a developer job as a human. Just got up a little bit more, right? Where, where those senior positions are the only ones open. So you gotta create whatever experiences you can. Right.

Brian Milner (24:42)
mean, should, in reality, it should be like any other tool that people use to do a job. And it should be the kind of thing where, hey, now we have calculators, and I don't have to manually do the computations on my own. Does that mean that I don't need the reasoning and logic of knowing which computations to make? No. Someone still needs to know how to do that kind of thing. And I think that's how it shifts a little bit is. I don't know that it ever, I shouldn't say that ever. think it's, my, I'm not an AI expert, but my experience dabbling with this kind of stuff and reading articles and talking to people in the industry is that it's not there yet. It's, it's, it's good. It does a good job at, you know, being an assistant level, co-pilot level, that kind of thing, but it's not.

Cort (25:29)
Mm-hmm.

Brian Milner (25:32)
hey, let's fire our 10 developers because now we've got an AI that will do exactly what they did. It still takes reasoning and logic to know which path to go down, to ask it what to do. And I think that's just how it shifts a little bit is now there's a tool that does the more mundane part of that, but we still need the information, the logic, the reasoning to design it.

Cort (25:44)
Right. Right. Right. Yeah, totally. This this reminds me a lot of your conversation that you had with Lance. It's the first episode of twenty twenty five. You and Lance sat down and talked about AI and hyper hyper personalization. AI being used as a tool, which you and Lance discussed fairly thoroughly. You guys went into a little bit of depth about that. It's a tool that delivers value, but where do you think it's delivering value to, or who do you think it's delivering value to? Is it developers, the company as a whole, customers? Where do you see that value stream starting? And do you think it could eventually get to somewhere else, deliver value elsewhere?

Brian Milner (26:17)
Yeah. I mean, it's kind of like to me asking like, how do you, where do you see streets and roads and highways deliver value? know, like it's, there's a million places they deliver value. There's a million industries. There's a million different things that they do. And I kind of see AI, you know, as a much, much, much more advanced version of that. But just to say, they're, Does it deliver value to customers? Yes, it delivers value to customers. It might make their lives easier or make it more simple to get to what they need. Does it deliver value to the organization? Sure, it delivers to the companies because it's going to help reduce time to market and speed and maybe cost as well. Although cost, we'll see. That's kind of an interesting thing because, you know,

Cort (27:26)
huh.

Brian Milner (27:33)
You read lot of articles about how OpenAI is not profitable yet. And it's taking a huge amount of data, a huge amount of data centers, a huge amount of energy. So that runway runs out at some point. And even charging $200 a pop for their pro model a month, it's not profitable. I mean, they say that membership level is not profitable right now.

Cort (27:46)
Right. Right. Yeah. Right. Right.

Brian Milner (27:59)
So that doesn't continue forever. At some point, that money runs out. And when that does, how does it get paid for? So will it reduce costs by that point when that runway runs out and the consumers of the AI product have to pay the real cost of what it takes to run it? I don't know. Hopefully, it goes down by then.

Cort (28:18)
Yeah. Yeah. In that same episode with you and Lance, you talk a lot about AI as a tool, right? And it's not something that you are scared of personally because it is a tool and you view it as a tool and an aid to you being more productive. I'm just curious your thoughts on, let's take it back over to our scrum masters, right? So. someone starting out as a Scrum Master role or recently got put into a Scrum Master role, how do you think that AI can be used as a tool to aid Scrum Masters? Do you think it should take over kind of backlog prioritization so that Scrum Masters can focus a little more on those interpersonal connections? Do you think it should take over managing meetings or running meeting ceremonies so that Scrum Masters can focus on more important things?

Brian Milner (29:10)
I kind of, the hair on the back of my neck goes up a little bit or I cringe a little bit about the words take over. Because I'm not sure there's anything I would say that it should take over right now. I think that there are some things that it can assist with and do a better job. Like it can, you can offload the manual portion of doing that to the AI. But you know, yeah. We've talked about scheduling meetings. That's an easy thing for something like AI to do. And it does a good job. One of my favorite things that I've learned is you can dump a bunch of data into it and then ask a big open-ended question like, what are maybe some insights from this data that I'm missing? What are some key?

Cort (29:37)
Right.

Brian Milner (29:54)
takeaways that I should have from this mass of data that you sort through. And that's a really good job of interpreting that kind of thing for us. So I think it's those kind of things that, from a Scrum Master perspective, I think you can probably use it to do a lot of things like charting out velocity and tracking other trends in our velocity.

Cort (30:00)
Right.

Brian Milner (30:15)
or the trends in other data maybe that I collect for my team that I'm not aware of. I think it starts to fail a lot in the creative areas. I'll just give you a practical example from my standpoint. I spoke at couple of conferences. I try to speak at conferences on occasion. And when you do that, you have to submit papers of saying, here's what I want to talk about. I cannot use AI and go to it right now and say, hey,

Cort (30:34)
No,

Brian Milner (30:37)
I want to speak at conferences next year about AI or about Agile and Scrum kind of topics. What are some ideas? What are some things I can talk about? It's not going to give me anything that's worth anything if I ask that question. But if I already have the idea, it can help me flesh out the idea. It can help me kind of with the way I present the idea. But the idea is mine, right?

Cort (30:49)
Right.

Brian Milner (31:03)
And I kind of think that's the thing is from a Scrum Master perspective, use it for the things that would take a lot of manual time to do. But you have to know your stuff to know that you need that thing.

Cort (31:12)
huh. OK, so yeah, just speaking out loud here, use an AI as like, hey, I'm noodling on this idea to get a little more engagement in our daily standups. Walk me through how this would go, or something like that.

Brian Milner (31:34)
Yeah, I mean, there's some particulars there. you probably want to prompt it to say, you know, I want you to act as an agile expert. Ask me all the questions that you need to ask me about why my daily scrums are failing and help me figure out, you know, three next steps I could take to try to improve the daily scrum of my team. That would be the kind of prompt I would enter. and kind of hear what the question, let it ask you questions, let it refine it a little bit, and it'll give you some things to try. Now, maybe only one of those things is worthwhile, but if you have one of them that's worthwhile, it's worthwhile.

Cort (32:10)
Yeah, yeah, absolutely. Right, totally. Cool. Let's step away from AI real quick. I got one more question for you. And this can be like a, yep, we'll wrap it up after this one. One more question for you. And this was actually from the last episode with Scott, where the whole idea of it was you need to be nice by being honest, realistic, and I put in quotation marks, mean. Just being nice by being

Brian Milner (32:16)
All right, then we got to wrap up.

Cort (32:35)
Brutally honest, I guess in a good way of putting it when So again as the younger guy in this conversation as the one who doesn't quite have as much experience in having potentially career altering conversations as I like to call them When should I bring those up when should I be that kind of mean nice guy? Is it any time that I have my my foot in the door of? the CEO or someone who has a little more pull? Is it, should I only do it when I'm prompted or is there some other time that I should be bringing up these topics that are probably important, but you know, not the nice guy way of bringing them up.

Brian Milner (33:13)
Yeah, we were talking about the thing that I mentioned about the scenario where the guy found himself in the elevator with the CEO. And yeah, I do think there's an important kind of thing to keep in mind there where, you know, businesses are gonna expect you to kind of follow the chain of command a little bit. so, you know, I think you've got to balance that in with this. I'm not saying that you should... hey, everything that you think might be wrong in the company, go schedule a meeting with your CEO and go run and tell them. Like that's gonna make everyone between you and the CEO really mad and your CEO really mad, right? You gotta follow your chain of command a little bit. If I have a manager, I wanna be always kind of frank and honest with my manager so that they know they can trust me, that I'm gonna tell them.

Cort (33:49)
Yeah, yeah.

Brian Milner (34:02)
the reality and there it's just how blunt are you? How much do you soften when you say those things and try to say it in a polite way rather than saying, this sucks. You have to be able to play that game a little bit. But I I think you should always be honest with the people in your immediate chain of command.

Cort (34:13)
Right, right.

Brian Milner (34:24)
you, there's no, you know, definitive line about when you overstep that and go above and beyond. You kind of have to interpret that yourself. You can't do it too often, but if there are times when you feel like something is vital and it could actually have a real negative impact on your business, then, know, occasionally maybe it is okay to then go out of your chain of command and say, I just think this is really vital. And I think the company needs to know this. So I've kind of gone out of the normal chain of command. You're going to make the chain of command mad when you do that. So you have to weigh that and say, is it worth it? Do I feel like I can defend that I went outside the chain of command in this instance? that people won't see it as I'm always going outside the chain of command, but this was important enough to do it.

Cort (35:10)
Sure. Right. Okay. Awesome. Well, thanks, Brian. Thanks for getting that last one in there. Yeah.

Brian Milner (35:18)
Yeah. Yeah. Yeah, yeah, no, this has been fun. And we'll do this more often. We'll have some check-ins and try some more experience experiments. All right.

Cort (35:30)
Awesome. Well, thanks for having me on. Thanks for letting me ask these questions. thanks for a great conversation. I appreciate it. Yeah.

Brian Milner (35:33)
Yeah. Yeah. Thanks, Cort.

#132: Can Nice Guys Finish First? with Scott Dunn

29 januari 2025 | 33 min

Can being "nice" at work actually hold you back? Join Brian and Scott Dunn as they unravel the myths around workplace "niceness," explore the balance between kindness and assertiveness, and reveal how honest communication can earn you respect—and maybe even that long-overdue promotion.

Overview

In this episode of the Agile Mentors Podcast, Brian and Scott dig deep into the question: Do nice guys (or gals) really finish last at work?

They discuss the critical balance between being accommodating and assertive, why conflict can be a tool for growth, and how emotional intelligence plays into team dynamics.

With stories, tips, and the psychological truths behind professional success, this episode is a must-listen for anyone looking to navigate workplace interactions while staying true to themselves.

References and resources mentioned in the show:

Scott Dunn
Bill of Assertive Rights
Elements of Agile
Radical Candor
Advanced Certified ScrumMaster®
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back and we're here for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today we have friend of the show, buddy of the show, Scott Dunn is back with us. Welcome in Scott.

Scott (00:13)
Hey Brian, great to be back as always. Love it.

Brian (00:17)
Love to have Scott on as always and if you've listened to some of the past episodes with him then you know why. If not, I encourage you to check it out after this episode. We wanted to have Scott on earlier this year just to talk about some things that might be percolating in a few people's heads with the turn of the year and kind of as you start to prepare and look forward and maybe even look back a little bit in things. And particularly deal with an issue around how people show up at work and Scott was saying to me earlier, kind of this phrase about, nice guys finish last? Do they finish first? Do they finish last? Can you be nice? Can you be nice at work and be promoted? Can you be nice at work and move upwards? Or do you have to not be nice?

Scott (01:03)
you

Brian (01:11)
in order to do that. So tell me a little bit about kind of the genesis of the idea from you, Scott. What have you been hearing or what's been crossing your path?

Scott (01:17)
Yeah, and I'm so glad we had a chance to talk about this because it's recent. So the first thing that sparked my thought on this, so granted in the leadership class, we talk about being a balance of accommodative and assertive, and I'll usually refer to a... a document called the Bill of Assertive Rights. And I was reading another book this week and actually it referenced the same thing. I thought, switching fast forward a few days and I'm doing an assessment with a company that's asked for help because they're not, they're struggling with quality, they're struggling with predictability. And I know what the leaders goals are for the efforts. And so now I'm meeting with all the team members to do an actual formal assessment for baseline. Now, and this assessment, you're going to go through, I don't know, 30, 40 questions. So it's not lightweight. It's trying to be tactical, like, Is the team well formed? Is the backlog in good shape? Do you have a roadmap? Are the leaders supporting the change? I mean, whether company level, product level, team level, and we even added some advanced questions. And the fascinating thing is over a course of all these questions, the answer was essentially, we're okay at that, right? If you ask them, are they doing this practice or not, they'd say, somewhat. And it didn't matter if it was the most basic thing at the team level or the most advanced thing at the corporate level, everything was okay. So when you look at the dashboard at the end, in our normal red, yellow, the whole thing was yellow. And so I just paused and said, you know, I've never seen this before. I said, yeah, I joke with them a little bit about that, but I said, you know, my friends kind of think about it. It actually doesn't make sense that you would be okay at the fundamental beginning things and also okay at advanced high level things. So it's usually progressive, right? You get the basics down like the satiric change curve. That's kind of what we're following. So now... And then what came out later in the conversations is that someone said basically, we're afraid to say things that are hard to hear. He used the word judgment. Like we don't want to kind of stand in judgment of others, but essentially saying something that someone's not going to hear, whether it's true or not, because they had nothing green, nothing red. So not doing well. And then the last thing that really got me triggered, you know, really start diving into this is this new year and people are getting this promotions and things going on at some of the companies. And there was a story of this one guy, like, I've worked here eight years and never been promoted. And yet everyone loves this person. Everyone likes this person. And I'm hopping on social media and someone asked that question, literally, like, give me an example of when nice guys finish last. And the guy said the same thing. He said, I am the one everyone goes to for help. I'm always ready to help. I'll do anything anyone needs. Everyone likes me. They all praise me. And I haven't been promoted in like 13 years. So partly for our own careers, partly for, you know, being a change agent, et cetera, I thought it'd be worth, you know, just having to... It's a great conversation topic,

Brian (03:51)
Yeah, well, I'll confirm part of that, or at least a couple of crossovers there with what you said, because there's an assessment kind of thing that we do at Mountain Good as well called Elements of Agile. And one of the things we learned early on in doing that was you would pull the data from the survey, from actually asking them. But then before we present it back, we always have a coach who kind of does interviews as well, and then manually can shift and adjust things. And one of the things I've learned as being one of those coaches who does that is if there's something that's negative that's said, if there's, you know, we give like a five point scale, you know, five is really great, one is terrible, and you know, what number is it? If it's a little bit over into the negative side, you never get anything that's like all the way over at one, right? Nobody ever comes back to you and says, that's terrible.

Scott (04:44)
you

Brian (04:46)
but they will say, that's a three or that's a two. If it's a two, that's severe. That's kind of what I've learned is two is severe, three is bad. And you kind of have to shift those things over one notch to say, people are, their niceness are entering into this and they don't want it to be, they don't want it to look too bad. They don't know how it's gonna reflect on them. They don't know how it's gonna reflect on others. And so they don't want it to look

Scott (04:50)
Yeah. Okay. Yes.

Brian (05:15)
too bad, so they tend to like skew it a little bit towards the positive. Yeah.

Scott (05:20)
Yes, and the thing I think is good from that so one I keep coming back to you know self preservation this world kind of wired for this and someone was mentioning recently It's you know, shouldn't say people are selfish. We should say they have self in the center So if I'm gonna I'm just with you like if I'm gonna give feedback I'm honestly just pass facts or for those listening. I think it's totally fine say well Is it really worth it for me to say something that I'm going to have to end up explaining if a manager figures out that was me that said it because I'm the only one working on that project or whatever, right? In some ways, you're like, no, it's not worth it. I'll just kind of gently say it's not going great. Like you said, it's almost like that bell curve you got shifted over because, the professor's like, there's only, I'll only give out two A's each semester because that's truly exceptional. And so it moves it. It's a little like that. But then when you and I were talking earlier, you mentioned that conflict quadrants. And I thought that was really great because I think that's a clear structure that people could refer to as well. It's kind think about how they have interactions not just at work, but seriously in our other relationships. thought I was looking at like, man, this is so fitting. So I just thought that was a good tool to share as well.

Brian (06:18)
Yeah, it's interesting to see how that kind of affects people and how that affects their answers and how it affects how they're reporting. And there's a crossover here as well, because I know if you've listened to this podcast for a while, last year I did a talk on conflict management and kind of how to navigate that a little bit from a team lead or a Scrum Master kind of perspective. And it's a very sticky area that I think there's not enough training and there's not enough kind of education in. And one of the kind of interesting things that comes out from that, or came out from that conversation was, well, a couple things. One is that conflict, oftentimes we attempt to avoid it entirely, but that's a big mistake. Conflict is actually necessary for growth and if there's not any conflict then you get the kind of bad situation of we never question each other, we never challenge each other. There's a story about how that was actually something that happened at Chernobyl. A lot of the research kind of pointed to that's actually part of the root cause of why that happened is that they were all experts in their field and so they had such respect for each other that they didn't question each other when something was gonna go wrong. And so they miss this kind of basic tenet of, no, if I see something that's not, doesn't look right, I should speak up. And it may cause conflict, but it's necessary. It's necessary for us to be better.

Scott (07:44)
Right. Absolutely. And that quadrant that the Thomas Kilman model is so great because, for me, well, two things was one, I love it that they can say, hi, be highly assertive. You can still be highly cooperative. And that's that collaborative environment. So if we're really trying to create solutions, whether that's at work or in our relationships, then you're gonna have to assert, you be assertive and not that I'm gonna raise my voice, but I should share what I think or my opinion or if I disagree. And I think some of that when I was coming back down to it is there's still a tendency for people to feel like I need to be in the goodwill of others, right? So from the, you know, the 10, the bill of assertive rights, the 10 assertive rights, that's one of them. Like I need to be independent of the goodwill of others so I can be honest. I'm not trying to be, we can do this respectfully and winsomely and not be a jerk. But you have to let go of, if I say something I don't like, that would be bad. Or if I say something that makes someone happy, right? And I used to struggle with that. I don't want them to be sad. I don't want them to be upset, right? So now back to that quadrant, I'm not asserting myself and I'm obviously not helping them, so I'm just avoiding. And I'm avoiding the situation. It's the elephant in the room in these meetings. And now everyone's almost like, as a culture, we're kind of in cahoots. We all agree we're not gonna say anything, which makes it even tougher for anyone else not to kind of stand up and do just what you're saying, which I think is absolutely true. Speaking of that, so.

Brian (09:07)
Yeah, well, and just to clarify, too, I mean, you're talking about the Thomas Killen model. If people aren't familiar with that, basically, it's five different responses that people typically have to conflict in one way, form. When they encounter conflict, it's competing, collaborating, avoiding, compromising, or accommodating. those are kind of the, there are variances between anything like that. There's going to be some gray levels between them. Those are kind of the basic points. And I was telling Scott earlier, one of the things we talk about in our ACSM is when we present this information is that you kind of have to get out of your head the idea that any of these are bad. For example, the competing approach to things, the competing approach says, my relationship with the person is not as important as my stance on whatever this issue is. I cannot budge from my position. And I will jeopardize the relationship if that's what's required. That's a competing approach. And you initially read that and think, that's wrong. Nobody should take that kind of approach to a conflict. And in general, that should be our default kind of approach to conflict. But there are times when that's the right approach. When someone says something that's completely out of bounds, completely out of line, I'm going to take a competing approach. And there are times when people need to

Scott (10:08)
Mm-hmm. you Okay.

Brian (10:30)
to be presented with that for their own good. That they kind of recognize, wow, this is so important that he's willing to kind of not have a relationship with me anymore if this continues. And that's important, I think. Yeah.

Scott (10:41)
Yes. yeah, and I think that those examples of the people that get promoted, someone else had referenced and said essentially, it's you telling the, you know, I won't say the ugly truth, but. The thing that no one else is saying, your ability to say what no one else is saying to someone in leadership or management earns their trust. So at some level, whoever is the leadership whisperer, telling the truth on some of these things, and there was only one slot that's gonna influence and lead us to be promoted into, right? I've gotta know, if I'm wise as a senior exec, I gotta have the wisdom to know that I know lots of people probably just tell me what I wanna hear. I'm looking for the person who tells me maybe what I don't wanna hear.

Brian (10:58)
Ha

Scott (11:24)
It does it in nice way again though. From that standpoint, I can see why some of those people get promoted and some don't because you're so nice they actually don't trust you. Because you're not, to your point, I'm not willing to have conflict. I'm not willing to gamble what you might think of me for the sake of the betterment of everyone else. So there's some part where I think it's good. My takeaway looking at some of this is come back around to say, all right, check yourself when you have these conversations, just do that mental pause and say, Are you truly acting independent of what they might think? You know, do you have their best sensors or harder? Are you okay if they might respond a certain way? But it's almost like check that I'm outcome independent. So I'm being straight up and honest with them. Cause in this case, doing this assessment, try to work with the team, like, well, how hard is it to help the team or help anyone else who's actually not being honest about where things are? I don't have anything to work with now, right? Or like, yeah, I got to just take what they say is not great and then slide it down. So I recognize. And honestly, it's actually bad, but for all of us and the change, not just for our careers, but as change leaders anyways, checking that we're comfortable doing that. think growing that comfort, know, comfortability we can do. And I think it's just great for the career. And I see people getting promoted in these opportunities. Absolutely worth it.

Brian (12:37)
Well, there's one other story I want to share here that kind of is, this is a story from my past, one of the jobs I worked at. There was a project that we worked on that a lot of people probably will identify with this. The managers in the organization had set a deadline for it without talking to the people who actually were going to do it. from the, yeah, right. And from the very start, my developers that,

Scott (12:56)
No.

Brian (13:01)
that worked with me there on it were saying, this is impossible. It's not just that this is a little bit off, it's completely impossible. There's no way that we're going to do this. But the managers were like, well, you'll get it done. You'll get it done. And so they went forward and publicized the schedule and went all the way up to the top of the company. And the CEO knew that that was the timeline. And well, the CEO found himself in an elevator with one of my developers at one point.

Scott (13:17)
Board.

Brian (13:30)
just to ask him, hey, how's that project going? And my developer kind of sighed a little bit and said, well, you do you want the truth? Do you want the picture that everyone's painting? And he was like, well, obviously, I always want the truth. And so he told him, and he had a phrase that he used there that has stuck with me to this day. And that is, he said, bad news is not like wine. It doesn't get better with age.

Scott (13:40)
Wow. Yeah.

Brian (13:57)
And I think that's an important thing to keep in mind is that when there's something wrong, when there's something that's not right, the sooner we can identify it and shed light on it, the faster we can do something about it, the more options we have to do something about it. And the closer it is to when it's due or when we're supposed to have that thing happen or whatever, the less that we can do about it. So I'll even give a shout out. know. I can't imagine he's listening, but.

Scott (13:58)
Ooh. Yeah. Mm-hmm. Yeah.

Brian (14:25)
But that was a guy named Dave Ellet. So Dave, if you're listening, it's still stuck with me to this day. But that's a great phrase. And I think it's really apparent here. mean, being a nice guy, it's nicer, I think, to make sure that people understand the truth than it is to let the deception go on.

Scott (14:29)
Ha ha. Yeah, so two things on that Brian is one totally agree with you It might be hard to deliver some of this news But if you fast forward how much harder it will be for them when they have no time to make adjustments for the customer or the DNA Right and I'll tell them that right especially the product owner class You do me no favors by giving me like a week or two to tell the customer actually No, tell me now six months out that there might be some concerns, right? That's a lot easier. It's not easy, but man. It gets a lot worse That's one. I love way there's the example does not get better with age. The other thing is I think on a personal level, those who are not maybe saying what should be said or needs to be said or giving people that kind of, you know, honest feedback, you know, would you rather know now or in your performance review that there's a problem to not tell them that is in some ways what I was feeling for me is I'm actually now trying to control the optics I've seen. So it's actually a weird, it can be seen as a weird way of like, I'm just being selfish. So I'm actually not a nice guy. I'm a guy with these covert contracts about I want you to think this of me, so therefore I'm actually telling you the truth as your own coworker or peer about something that's really important you should know about, or my manager. I'm actually making sure that I, you know, take me first and take care of myself, but actually in a very short-term way out of fear versus a good worker would tell the truth and as I'm saying, probably he has more career opportunities by being one of the few people that. is a truth-telling organization like your developer and with the elevator to CEO because think about what CEO thinks of him now as well as what CEO now thinks about all the other one else is saying like, no, we're on track, we're on track, right? Those just probably reversed opinion in his ideas in his head about who he can trust to tell the truth about where things are going in these critical projects. So great example, great example.

Brian (16:29)
Yeah. Yeah. Well, and I think that gets to kind of the heart of this topic too. mean, you think you're talking about, you know, can you be nice? And if you're nice, is it possible to be recognized and still move ahead? And to me, think there's, this is where it starts to get really deeply psychological because I think you have to question what is your definition of nice? You know?

Scott (16:47)
Hmm.

Brian (16:53)
Because I think some people have a misaligned definition of what it means to be nice. I don't think it's nice to allow the deception to go on. I think that's not nice. I think that's something that, you know what I mean? You don't appreciate, like you said, as a product owner, as the leader in the organization, that's not nice to them to let that go on. And we might sit back and say, I'm not going to...

Scott (17:14)
No.

Brian (17:20)
I'm not going to raise red flags. I'm not going to be the squeaky wheel. I'm going to be the guy who just gets by because I'm a nice guy. We're using guy, but please understand. It's just a term. It's just a phrase that applies to women as much as it does men. So I'm not saying the gender specific thing here. Please, please forgive us for that. But just that that's kind of the concept behind it is I don't want to make waves. I want to be the nice person in this organization. I want to be seen as nice.

Scott (17:40)
Yeah. Yeah.

Brian (17:45)
your definition of nice might need to be readjusted.

Scott (17:48)
Yeah, huge point. think that kind of those words matter. And I think if someone would look at what they like, re-evaluate what you think is going to get you where you want to go, as well as what you would want from others as a teammate. then, and then for me, what I have to do is I have to backtrack and say, so why did you not say anything in the meeting? There's a time way back when I was working with the manager in the meeting that he was very supportive of what his colleague was sharing and the idea of someone she's presenting it to the other peers and the VP, everyone liked it except for one person who spoke out. because that one person, you know, the VP put the whole thing on hold afterwards. just asked that manager said, I thought you liked her idea. He said, yeah, no, I liked her idea a lot. So when the other person says something, why, why didn't you say something back? Right. And said, you stand up for what you thought was a good idea. What she was saying. But was the same idea of like, don't want to make any waves. But he said later, goes, that was the most important question I had to be asked about. I do need to speak out. I do need to be assertive in these meetings and say what my view is too, not just what they say, go along to get along. Like, and now we're just letting, you know, projects and this should go off track, right? No one's calling it for what it is.

Brian (18:52)
Ha Right. Yeah. So I think it's possible.

Scott (18:57)
So I think, yeah, that part.

Brian (18:59)
Sorry, I was just gonna say, I think it's perfectly possible to be assertive at certain points and take strong stances on certain things, but not compromise your niceness. I don't think that makes you a mean person. It may not make you everyone's favorite person every moment of the day, but it's nicer. People respect people who are honest.

Scott (19:25)
That's a good word, respect. Right. Right. Yeah. I wish there was a secondary word and we can be friendly in these other things. and I love what you said. Like it may be nice to not tell the, you know, you think it's nice, but people should know those things that they're not hearing. And that part's not nice. I think that aspect of maybe self-preservation to the detriment of others and then re-examining why, why do I feel like I need to do that? You know, for me, that was probably at work as well. Right. Is it, what was one person said? Harm versus hurt. This might hurt them in the moment, but it doesn't harm. So the shot to the dentist, the needle, that does hurt, but it's not harming them. Sugar tastes great, doesn't hurt at all, but it harms you. So kind of maybe reflect back on what does it mean to have your peers, your colleagues, your company's best interest at heart, and then what keeps us from that, right? And what are we looking out for? Are we that risk anyways? Yeah. In any case, I like that tool. I'm glad you brought that up.

Brian (20:19)
Yeah, I think there's also, I think it's important to say, know, like this with a lot of things, there's a balance. And we probably, know Scott, you probably have had this as well, but I've had a couple of people I've worked with throughout my career who just, they weren't concerned about being the nice person. They were much more of the outspoken and they would say things very bluntly when something was not going.

Scott (20:25)
Mm-hmm. You

Brian (20:43)
in a good direction. I think that's where NICE enters the equation, right? NICE is not letting it go, but NICE is being able to cushion a little bit what it is you're saying so that it's not just a slap across the face, but it's more of just maybe we want to reconsider that. Maybe we want to think about that, or have we thought of, or have we considered what the implication might be in this area. That's a much more digestible way of taking in that kind of news than it is to just say, well, that sucks, or that's going to be terrible, or you're going to fail miserably at that. And I've had people I've worked with who that's the kind of way that they respond.

Scott (21:14)
Yeah, right. Yeah, almost like a judgmental view of that. It comes across and I think some people maybe miss that. I know there's a big, you know, space on emotional IQ or EQ. I think that that's really valid and kind of checking yourself on that. I think some people don't read those. signals or they'll say like, well, someone needs to say it. Well, you didn't have to say it like that though, because we, I think we all want to be effective. So if we're not careful, then you, might be true, but they're not hearing you now. So you're still not effective in what you want to do, which is communicate that concern. So there is some part and that's what I like about radical candor. We do want empathy and we do want to care. So what you're kind of touching on, which I think is really great. If you take it that away, then we're just going to, we could actually make things even worse. So it's not a license. partly I see happen a lot and maybe you've been in these meetings and my friends listening, you know, you probably have too, where something said that you can tell there's a lot more underneath that, like that person's just mad, right? You can just tell bitterness or resentment or something's coming out. And again, other people can read that and it's not helpful. One, probably doesn't help you get your idea across, but two, it's just not helpful for you or to carry that around. So for me, I'm always trying to catch it like, is there emotion underneath this, if so? You gotta deal with that. Like you might need to wait to say this until there's not, you don't feel that emotion coming across. Cause then those things get said like you'd said under the guise of, I'm just trying to be honest with them. But look, that was a lot more that wasn't necessary and there's emotion. We've all sometimes worked at places with people that maybe wrote us the wrong way, or you've been a certain job for a long time and it can kind of bubble out in those meetings. So again, a great opportunity to kind of check and say, Where's my emotional bandwidth as I go and have this conversation? And I think also, what do you want? What do you want from the outcome of these things? Some we can control, some we can't. I might want to raise, but I'm not in control of that. But I'm in control of what time I show up, what I'm reading for work, being ready for meetings. I'm in control of that, and hopefully those things could come. So also, I know it's near the beginning of the year, get opportunity on goals and being clear about what you want. Because I think if we don't have a true north for ourself, it's easy to be what everyone else wants at the workplace. We don't actually have a sense of self anyway. So yeah, sure. I'll do whatever you want for me. And it's not even maybe, you know, maybe helping me move forward as well or maybe I'm sacrificing. So that's good timing for that as well for folks who are into doing goals or you have your, you know, 2025 roadmap in front of you. It might be a personal growth area. think it's good for everyone to take a look at at least.

Brian (23:44)
Yeah, and I think it's good to we propose this kind of can you get ahead? And so there is kind of the the weird marriage here a little bit of of how leadership plays into this. And, know, there is a view of management or leadership sometimes that is one that is much more authoritarian. And so I've known people who feel like, well, if I'm going to get to that level, then I need to.

Scott (23:48)
Yeah. Mm-hmm.

Brian (24:09)
be able to demonstrate that a little bit more. And I think there's a misunderstanding there as well. I don't think that's really what's required or is what's helpful in a leadership kind of position. It's kind of that whole paradigm of, do you feel your job as the leader is to push everyone towards the goal? Or do you feel like the...

Scott (24:12)
Mm.

Brian (24:31)
the job is to clear everything out in front of them so that they can easily reach the goal. That's a big difference in management style that I think can be really reflective in whether they're seen as nice or not nice.

Scott (24:37)
Yeah. Yeah, right. It's funny you say that because I was just hearing this from someone else as well. Like, the amount of leaders out there who don't have clarity on their goals and vision. So to your point, now you made it doubly hard for my people to try to aim themselves towards these goals. You know, of essentially self-organized, self-leadership, work on themselves to get there. It's lot easier if we have the vision, the goals in front of us. That's one thing I like, I was talking to my team earlier today about OKRs can be pushed down or rolled out from the top, of course, because they're the ones with the goals and the vision, but boy, it's an enablement for people then to figure out how to do the things they need to do to get there. And without that, we're rid of a struggle. So... whether I'm showing up as a kind of leader. So now what I'm left with, there's not a vision to motivate and guide my people and support them as a servant leader to get there. Now we're just back down to tasks. And I think those tasks can come down to like authoritarian, I just need you to do this, take out, take care of that problem, fix this, put out that fire. And that's one, you gotta make sure they do it and do it right. Cause it's at that level, there's not a lot of space for creativity and freedom. And we're not building anything big or necessarily. And projects can even kind of break down into that. So I'm glad you're bringing that up on the leadership styles. We don't have to always show up and be domineering. I think I want to be the kind of leader that is more about we than I and you. pulling something together and coaching up, but without the vision guidance, that might be an opportunity. Whatever department people are in, you can always have that conversation. Or even for the people themselves, again, you can always work on that. But those leadership styles, I think, fold in really nicely, say, do we have a vision and goal to catalyze people towards? Or am I just left with, you know, compliance, task type, manager, I just got to make sure people doing the right thing and complete things when I told them they need to all that, like the old school way. I think there's still probably a lot of that.

Brian (26:35)
Yeah. Yeah. And don't get me wrong, I completely understand from a leader, from a manager perspective, there are some basic kind of things that I think we have responsibility for. If you have an employee, let's say, that's stealing from the company or something, you're not going to just approach that as, hey, well, I'm not going to push them about stealing. I'm just going to try to clear the obstacles from

Scott (26:58)
Ask them how they feel about the stealing.

Brian (27:00)
Right, right, right. mean, don't anyone listen to this and think that we're saying that there's not that basic responsibility. I think that that is still part of being that leader and being a manager in some way, or form. I used to have a manager and for a while I sold shirts outside of Phantom of the Opera as part of the merchandise career there for that. And my boss there had this philosophy style of just, hey, you do your job. And, we're friends. We're the time in between, we just hang out and have fun. But if you're not doing your job, then we have to have a conversation. And I think that's kind of the basis there is like, don't, don't put me in that position as the manager. It's not, you know, you're not respectful of me when that's the case. and sometimes that, that, that occurs and you know, sometimes people have to be fired and all those other kinds of things. I get that. but that's, I think you can. You know, I remember one specific person that I had to fire at one point that, you know, it was, I felt after the, the event that it was actually the kindest thing I could have done to that person because they needed that, that to happen to them. Believe me, I know it's not good to get fired. I understand that, but this person had enough going on in their life that they needed that kick to do something else because they were not going into a good place. And, I just think that sometimes that's.

Scott (28:03)
you

Brian (28:16)
That's the kindest thing to do.

Scott (28:18)
my goodness, my first boss that pulled me into his office to say my performance wasn't adequate. He was just, and he, promise you, he probably said it just the way I'm saying it to you. I thought I was gonna die. But it was, I really did. just like, my heart's, you my throat and mouth totally dry. But it was the best thing I did, because I went back and like.

Brian (28:27)
Yeah.

Scott (28:37)
Yeah, why the heck am I not getting as much done as everyone else? Because I literally was just like an office clerk typing in stuff and word. There's no real complexity to that. But it was what I would, because then I started paying attention. I never had to get talked to again like that. Thank goodness. But boy, was like you said, kind of thing you could have done. And again, I thought I was going to die. I didn't die. I needed to hear that feedback and then fix it. You mentioned something that also makes you think of what Google's research had found about that you need to know their best teams are ones that include the they know they have dependable team members. So the managers gotta say, look, if there's an issue on someone your team is not delivering when you need them to, then yeah, I need to step and help. That should be to be fixed. Google's saying the team members need that, but they also need meaning and impact, that their work makes a difference. Their work is bigger than it just has. So I think that's that nice combination of, I will step aside and address this assertively until that's not okay. that we got to perform this way. At the same time, I'm casting a vision about how this has impact bigger than just this team and you're part of something bigger than you show up in your code or your test or whatever. So I like that situational leadership that's going across. It's kind of reflected in their research as well. I'm glad you brought up that story. Thank you for management.

Brian (29:46)
Yeah, so I So I think I think it's uh, you know if I were to try to sum that I just I think You know when I'm asked a question, can you be nice or do nice guys finish last? I I don't think so. I mean, I don't think that you're gonna finish last just because you're being nice Depending on how you define nice You know, you can't you you have to be honest you have to be you know, entering those relationships in a healthy way. But that's not being not nice. That's that's just showing up and and giving your best to the job, I think. And if you do that in a respectful way and in a kind way, I think that makes you a nice person. And I don't think that person necessarily is going to finish last for those reasons. At least that's my opinion.

Scott (30:25)
Yeah. Well, I like that. And again, on your chart, I like the fact that main thing is be assertive. You have an opinion. Reminds you of the JavaScript, right? Assert. You're just saying it. Just saying it needs to be said. And some people might edit themselves to say, well, who am I? And I remember reading somewhere about, look, you have value in what you say because you exist. It doesn't have to be that you worked there for five years and you've got

Brian (30:54)
Yeah.

Scott (30:57)
you've written books, technical books, it could be that you're a thinking human being who is smart and knows stuff and has opinions. That's why we share what we share and not to edit ourselves out of that saying I shouldn't assert myself because of X or Y. anyways, a good conversation for the beginning of the year. And I like what you're rounding out that nice guys don't finish last. Maybe there's another word and maybe also there's a balance for these guys and girls as well.

Brian (31:23)
Yeah, I agree. Well, Scott, thanks for coming on. I appreciate you making the time and it's always great to have you on the show.

Scott (31:30)
My pleasure. lot of fun. Thanks, Brian.

#131: Lessons from Modern Agile with Joshua Kerievsky

22 januari 2025 | 32 min

Is Agile still relevant in today’s fast-paced world? Brian and Joshua Kerievsky reveal the four game-changing principles of Modern Agile that prioritize safety, empowerment, and continuous value delivery.

Overview

In this episode, Brian Milner sits down with Joshua Kerievsky, a pioneer in the Agile community and the creator of Modern Agile.

They discuss how Agile practices have evolved, the critical role of safety and empowerment, and how to deliver value continuously in today’s fast-paced world. Don’t miss these insights into creating better teams, products, and results through simplicity and experimentation.

References and resources mentioned in the show:

Joshua Kerievsky
Industrial Logic
Joy of Agility by Joshua Kerievsky
Modern Agile
#33 Mob Programming with Woody Zuill
#51: The Secrets of Team Safety with Julie Chickering
Badass: Making Users Awesome by Kathy Sierra
The Power of Habit by Charles Duhigg
The Lean Startup by Eric Ries
Experimentation Matter: Unlocking the Potential of New Technologies for Innovation by Stefan H. Thomke
Agile For Leaders
Mike Cohn’s Better User Stories Course
Accurate Agile Planning Course
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Joshua Kerievsky is the founder and CEO of Industrial Logic and author of Joy of Agility. An early pioneer of Extreme Programming, Lean Software Development, and Lean Startup, Joshua is passionate about helping people achieve genuine agility through principle-based approaches like Modern Agile.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back. And this is another episode of the Agile Mentors podcast. I'm here as I always am. I am Brian Milner and today I am joined by Joshua Kerievsky and really excited to have Joshua here with us. Welcome in Joshua.

Joshua Kerievsky (00:16)
Thank you so much, Brian. Happy to be here.

Brian (00:19)
Very excited for Joshua to be here. Joshua's been around for a while. He's been doing this for a long time. He said, you know, when we were talking before, and he's been involved with Agile before, it was called Agile. And, you know, that probably tells you all you need to know there. But a couple other things here about him, just so that you kind of can place him a little bit. His company is Industrial Logic, Inc. and he's the CEO and founder of that company. He has a book called Joy of Agility that's out there that I highly recommend. It's a really great book. And he's also closely associated with something that maybe you've been aware of, maybe you've heard of, maybe you haven't, but something called Modern Agile. And that's what I thought we'd focus on here for our discussion is really to try to understand a little bit about it. especially for those of you, maybe you haven't heard of it, haven't been around it before. So... Why don't we start there, Joshua? Tell us a little bit about what was the need that was trying to be filled with something like modern Agile.

Joshua Kerievsky (01:19)
Well, it goes back to a conference I attended in Prague back in around 2015. And I was giving a speech, a keynote speech there, and that ended. And then I went and said, well, I'm going to go join the OpenSpace. And I was just looking at what people were talking about at the OpenSpace. And at that point in time, I had already been experimenting with a ton of stuff that just kind of different from what we had been doing 10 years earlier or even later than that. I mean, just this was new things that we were doing, whether it was continuous deployment or ideas from lean startup or ideas from the Poppendiecks and lean concepts applied to agility or just a lot of things that were just different. And none of the sessions I was seeing in the open space seemed to be talking about any of that stuff, like giving up story points or moving away from sprints until continuous flow. just nothing was being talked about. So I just said, well, I'm going to host a session, and I'll call it, I don't know, a modern Agile. And so that's as far as I got in terms of thinking about the name. I just wanted to run a session where we could talk about, there's a lot of new things we're doing that kind of display some of the older ideas. And they're very useful, I found. So the session ended up getting a lot of attention. 60, 70 people showed up there. So we had a big group. And it was well received. People were fascinated by the stuff that they weren't aware of. And so I then repeated this open space event in Berkeley. Like a month later, was Agile Open Door Cal in Berkeley was running and did it again. And again, there was tremendous interest. in this, so much so that I decided to write a blog and wrote the blog and started getting more conversations happening. And that sort of began the movement of describing this thing called Modern Agile. And it took a few twists and turns in the beginning, but it wasn't sort of, I guess, if anything, I felt like Agile needed to be a little more simple. in terms of what we were explaining, because it was starting to get very complex with frameworks, enterprise frameworks coming along like safe and just too many moving parts. And so what ended up happening is I wrote some things and people started to notice, there's kind of like four things there that are really valuable. One of them was The names changed a little bit over time. But anyway, what ended up was four principles emerged. And that really became modern Agile.

Brian (03:58)
That's awesome. just for listeners here, I've pitched attending conferences in the past. If you've listened to this podcast, you've heard me say that, and I'll create things come out of that. And here's an example, right? This is something that was open space discussion. Open space, if you're not familiar with that, at conferences, can, if there's an open space day or a couple of days, then anyone can present any topic they want. And whoever shows up is who shows up. And this one got a lot of attention. And a movement grew from this open space topic, which is awesome. So let's talk. You mentioned there's four principles here. And I like the distinction here we're making also between the frameworks and the practices versus the cultural aspects or the philosophy behind it. And returning to those roots a little bit more from what Agile originally was. So you mentioned there's kind of four areas of this. Let's walk our way through those. I know the first one, or one of the first ones here is make people awesome. So help us understand, what do you mean by make people awesome?

Joshua Kerievsky (04:59)
Probably the most controversial of principles, because you'll get people coming along saying, wait a minute, people are already awesome. What are you talking about? And it comes from my, I'm a big fan of Kathy Sierra. And her blog was incredible. And her book, she wrote a book called Badass, Making Users Awesome. And in her book, she was really wonderfully clear about

Brian (05:07)
You

Joshua Kerievsky (05:24)
that teams that build products ought to focus on the user of the products more than the product itself. In other words, she would say, don't try to create the world's best camera. Try to create the world's best photographers. Big subtle difference there. Like that is focusing so much on empowering the users, making them awesome at their work or whatever they're doing, whether it's art or accounting or whatever, whatever your product does, how can you give them something that elevates their skills, that gets them to a point of awesomeness faster? And that's what she was talking about. So I thought, what a wonderful message. And initially, I used language like make users awesome. you know, having been an entrepreneur myself and created products and sold them and You learn a heck of a lot when you make your own product. And we've made several products over the years at Industrial Logic, probably the most successful of which was our e-learning software. And that has taught me so many, so many lessons. One of them is you have to serve an ecosystem of people. You can't just make your main user awesome. What about the person who's buying the software? How do you make them awesome in terms of helping them buy something that's going to get used? If they buy your e-learning and they never use it, they've wasted a lot of money. So we've got to make sure that their reputation is intact because they made an excellent investment and it got used and it got into valuable, it created value in the company. So how do I make the buyer awesome? How do I make the person that like rolls out the licenses to people awesome? How do I make their experience awesome? How do I make my colleagues awesome so that we love what we're doing and really enjoy working together? So it kind of morphed from make users awesome to make people awesome. And it's so expanded. If anything, we set the bar higher. And all of the principles of modern agile are like unachievable. They're all kind of high bars, right? But they're the goal that we go towards. So that really is it. It's about creating

Brian (07:23)
Ha

Joshua Kerievsky (07:35)
you know, wonderful, you know, the in Great Britain, they use awesome kind of sarcastically sometimes, right? They'll say, well, that's awesome. You know, and so for them, it would be brilliant. You know, I thought of making an English version. We have many translations of modern agile, and I thought of making an English version, which would be a proper British English version, make people brilliant. But it's meant to be to empower folks to give them something. And it's so it is.

Brian (07:43)
Ha You

Joshua Kerievsky (08:04)
It does have a product focus in the sense of we're typically building a system or a product that someone's going to use and it's going to give them skills they didn't have before or abilities they didn't have before that are going to be very valuable.

Brian (08:18)
Yeah, I love that. And there's a sort of a servant nature to that servant leaders, not servant leadership as much, but servant nature of I'm serving these people and how do I, how do I serve them in a way that really empowers them? Kind of reminds me of like, you know, the, the great principle with, with dev ops of just, know, if I can, if I can empower the developers to be able to do these things on their own. And so they don't need someone else to come and check the box and do everything for them. You're making them awesome. You're empowering them to be more than they were otherwise.

Joshua Kerievsky (08:54)
Yes, yes, absolutely. I I think we've seen a history in the software field of a lot of tools coming along and helping. It's not just tools, it's also methods as well. I mean, I'm entirely grateful to the Agile software development movement because it helped nudge everything towards a far better way of working and to make us more awesome at our craft. yeah, you have to have a North Star though. If you're going to build something, You have to know, what are we going for here? What are we shooting for? And with Cathy's influence, again, it's not so much make the greatest product in the world. It's, that focus on the users, the people who are going to be using the work, using the product.

Brian (09:34)
That's really good. Let's talk about the second one then on my list here, the make safety a prerequisite. What was the point here behind this principle?

Joshua Kerievsky (09:40)
Yes. So starting probably around 2011 or so, I could not stand going to the Agile Conference anymore. It had just become too commercial and too filled with just people hocking stuff. And it just was bothering me too much. I couldn't go. So I ended up going to South by Southwest, which is an

Brian (09:54)
You

Joshua Kerievsky (10:09)
Enormous conference tens of thousands of people show up So it'd be 20,000 30,000 40,000 people showing up for these for this event, which is musical film technology just it's just wild and I came across this book by Charles Duhigg called the power of habit. He was there that year and In that book. Well, first of all that particular year was 2012 that I went my first year there it poured The rain, it was every day, it was unusual for that time, but it was just like pouring rain. So what could you do? I bought some books and I was sitting there in my room reading them. And I'm reading this book, The Power of Habit, and I come across this chapter called The Ballad of Paul O'Neill. Now who the heck's Paul O'Neill? Well, it turns out Paul O'Neill is this incredible guy, a complete business maverick. He ended up becoming the treasury secretary under Bush and not. in 2000 for a short period of time, but that's another story. And he ran Alcoa for about 13 or 14 years. And so the Ballot of Paul O'Neill is very much about what he did at Alcoa to turn the company around. And in essence, you could say he made safety a prerequisite. That safety was his guiding light in turning that company around, which meant left people empowered to do all kinds of things. So it went way beyond safety, but started there. And it's an incredible story. I've written about it in Joy of Agility. I got so into Paul O'Neill that I ended up interviewing his main lieutenant. And then I got a chance to interview him a couple of times. the man's a genius. He passed away a few years back. Absolute genius. this concept of safety started to really pull at me in the sense that I felt, first of all, extreme programming, and I'm a big practitioner of extreme programming, brings a tremendous amount of safety to software development. It may not be as explicit in saying safety, safety, safety. When you look at extreme programming, doesn't really talk about safety, but it's implicit. And these days, Kent Beck's much more vocal about, you One of his missions is to make software development safer for geeks. But safety to me is almost like I found my home. Like safety was something that, what I learned through Paul O'Neill was that it's a doorway to excellence. And he transformed a hundred year old company with safety. I would complain about companies we were working with that were 25 years old and had an embedded culture. Like, how are we gonna change this company? But safety started to be this thing that I hadn't really thought enough about, and making it explicit opened up a lot of doors, right? And I became very interested in the work of Amy Edmondson, who's extremely famous today, but back then she was not so famous. And huge fan of hers. I, you know, I can email her and she'll email me back and she wrote a nice thing about my book. So. She has done some incredible work there. And so when we talk about safety in modern agile, it's psychological safety. It's financial safety. It's any of the safeties. There are many safeties that we could talk about. And it looks at all of them, right? It's brand safety, software safety in terms of security. you know, of the software and on and on and on. So make safety prerequisite is vast and big in terms of what we're trying to do there. Making it a prerequisite means it's not an afterthought and it's not a priority that shifts with the winds. It is permanent. It is something that we know we have to have in place. And it's very, very hard to achieve. Just like make people awesome is hard to achieve. Boy, is make safety a prerequisite difficult.

Brian (13:43)
Hmm. Yeah, I love Amy Edmondson's work as well. I'm just kind of curious. does the safety kind of inclusive of things like quality as well? Do you intend that to be part of what you mean by safety?

Joshua Kerievsky (14:11)
Well, mean, to the extent that it makes it safer to do good software development. So if bugs are happening all the time, you can't make people awesome, typically if you don't have quality. If you have really poor quality, nobody's being made awesome. They're experiencing all kinds of problems with your product. So make people awesome and make safety a prerequisite are very much tied together. That is, there is no real excellence without safety. You could think you're having an excellent experience, so that all of a sudden there's a major problem, and boy, are you unhappy. So they really go hand in hand. You could have the most incredible restaurant, and then one day you've got food poisoning happening. Great, no one's come to your restaurant. So you will not make anyone awesome if you don't make safety a prerequisite, and quality is part of that.

Brian (14:57)
Awesome. Well, let's move on to the next one then, because the next category is one that just resonates with me a lot. Experiment and learn rapidly. What was kind of the thought behind this one?

Joshua Kerievsky (15:06)
Yeah, and this is one where it that's shorthand, if you will, because you can only fit so many words on a wheel there. But it's important to know that that really means experiment rapidly and learn rapidly. And that comes a lot out of it in the influences of something like Lean Startup. I'm a huge fan of that book and of Eric's work, Eric Reese's work.

Brian (15:13)
Ha

Joshua Kerievsky (15:29)
And the fact that we can experiment rapidly and learn rapidly rather than just building everything and then learning slowly. Right? How can we do cheap experiments quickly to decide what's important to work on and what isn't? Let's not build stuff nobody wants. Let's find more time with our customers and understand their needs better so we can build the right things that make them awesome. In other words, and a lot of these are interconnected. In many respects, modern Agile is a Venn diagram. ideally want all four principles to be overlapping. And right there in that middle is where you really want to be. Not easy. But experimenting, learning rapidly, yeah. So challenge yourself to find ways to do quick, cheap, useful experiments. You can do lot of unuseful experiments. Amazon experienced that. There's a story in my book about how Amazon had to start just shepherding the experiments a little more and having some better criteria. Because you could do an endless array of experiments and not get anywhere. There's a wonderful book called Experimentation Matters by a Harvard business professor. Wonderful book as well. But I love experimentation and learning. And I see it as critical to building great products. So that's that principle there.

Brian (16:46)
Yeah, there's a real difference, I think, in organizations that put value on that learning process. if you see it as a valuable thing, that we invest time to gain knowledge, then that really can truly make an impact when you go forward. I know I've talked about this in classes sometimes where people will say, isn't it a little bit selfish from the organization to try to always just figure out what's going to sell the best? or what's going to work the best in advance of putting something out. My response is always, well, yes, there is a benefit to the business, but there's a benefit to the customer as well because they would rather you work on things that they care more about.

Joshua Kerievsky (17:24)
That's right. Yeah. I mean, we once put out an experimental product to a large automotive company. And we were really excited about it. We had a whole list of features we wanted to add to it. But we were like, you know what? Let's just get this primitive version kind of in their hands just to see what happens. it turned out that we learned very rapidly that they couldn't run the software at all. There was some proxy. that was preventing communication with our servers from their environment. So it was like, excellent. We learned really quickly that instead of those fancy new features we want to add to this thing, we're going to fix the proxy problem. And to me, that's the nature of evolutionary design is that we create something, get it out there quickly, and learn from it rapidly and evolve it. So it goes hand in hand with that as well.

Brian (18:11)
That's awesome. Well, there's one category left then, and that is deliver value continuously. So what was the genesis of that? Thinking about delivering value continuously.

Joshua Kerievsky (18:19)
So that was heavily influenced by my own journey into continuous delivery and continuous deployment and that whole world. We got into that very early. I was lucky enough to catch a video by Timothy Fritz, who he worked with Eric at IMBU. And he coined the term continuous deployment. And that video is actually no longer on the

Brian (18:43)
Ha

Joshua Kerievsky (18:44)
But this was something that I became enamored of was doing continuous deployment. And we started doing it at Industrial Logic with our own e-learning software back in about 2010. And by the time you get to like 2015, it's like, hey folks, there's this thing where you can do a little bit of work and ship it immediately to production in a very safe way, a safe deployment pipeline. It's friggin' awesome. But the principle doesn't just apply to that because this modern agile is not just about software development. It's how can I work in a way that gets value in front of people as fast as possible? So for example, if I'm working on a proposal, great, I'm not going to work for two weeks and then show you something. I'm going to put something together, a skeleton, I'm going to show it to you and say, what do you think? Does this add value? Where would we improve this? Blah, blah, Again, going hand in hand with evolutionary design. continuous delivery of value is something that is a way of working. With artists that I work with, they'll do a quick sketch or two or three sketches of something first before we start settling in on which one do we like the best and how do we want to craft and refine that. So there's a way of working in which you're delivering value much more finely grained and approaching continuously instead of in bigger batches.

Brian (20:05)
Yeah. I love the connection there between artists as well, because I've got a background in music, and I'm thinking about how when you go to write a song or create a new work like that, you start off with the roughest of demo tapes, and you move from there to increasingly more sophisticated versions of it until you finally have the finished product. But no one thinks that's strange or thinks that's weird in any way. But you're right. Sometimes there's this attitude or kind of I think in some organizations of, we can't let anyone see that until it's absolutely finished, until it's done.

Joshua Kerievsky (20:39)
Yeah, yeah, and that maybe that's that there's some fear there, you know, because they don't want to be thought of as, you know, being lesser because they put something rough in front of someone. Whereas I view it as a, you know, to me, it's a sign of weakness when you when you only send something polished because you haven't had the courage or the sense of safety to put something rough where we can make better decisions together early on. So. There's a lot of learning, I think, around that. But it's a challenging principle of its own, deliver value continuously. And people would say, well, what does value mean? Value is one of those words where it's unclear, because you could improve the internal design of a software system. Is that value? It probably is. But you've got to be able to quantify it or prove that it's going to help make things more graceful in terms of flowing features out. yeah, quantifying, communicating what the value is. is important. I'm also a big fan of maximizing the amount of work not done, as it says in the manifesto. So how can we do less and deliver more sooner? Our motto in industrial logic now is better software sooner. And a lot of these principles go straight into that. that drives it.

Brian (21:38)
Yeah. That's really great. Yeah, I love these four principles and I think that they really represent a lot. There's a lot that's baked into each one of these things. And I'm sure as you kind of put this together with the community and started to talk more about it, I'm sure there were some challenges. I'm sure people came up to you and said, well, what about and how about this? Is there anything now looking back on this that you'd say, gosh, we really... really didn't quite cover this or, know, this is maybe I could fudge it and squeeze it in this area, but you know, there's this other thing that I really think would be important to kind of mention here as well.

Joshua Kerievsky (22:28)
Well, you know, it's funny, because I thought I was going to write a book. I started collecting stories. I love telling stories, and I find stories to be a great way to help educate people. Not the only way, right? But as part of some of the workshops I give, you tell a story. Hopefully it's a story that's sticky, that sticks in the person's brain. And over the years, I collected stories like that, stories of agility. I thought I'd be writing a book about modern agile when I started writing Joy of Agility. Gradually, as I wrote more and more stories, they didn't quite fit into all those four principles. And I think the lesson I learned there was that I was starting to talk about what pure Agile means, the word Agile. What does it really mean to be Agile? Whereas modern Agile is really almost in the context of product development, of building services or products for people. Whereas Agile itself is even more pure. And so the... the book itself got into the difference between quickness and hurrying, which you can relate to this. You could say experiment and learn rapidly. Well, OK, maybe we shouldn't rush it. Don't rush. Be quick, but don't hurry is one of the mantras in Joy of Agility. So adapting, right? Adapting, we talk about adapting all the time. So to be agile, you need to be able to adapt quickly. These four principles in modern agile don't say anything about adapting.

Brian (23:46)
Ha

Joshua Kerievsky (23:48)
So that's kind of implied, but it's not there. So it's a different lens on agility. If anything, I'd say the make people awesome principles are not meant to. It created some dislike, I'd say, from some people. It could have been called empower people, potentially, although a lot of people really love make people awesome. I don't know so much what I'd change there. I'd say we have a .org. So it's a modernagile.org is a website. There's a pretty large Slack community, which, know, four or 5,000 people on that. We don't certify anyone in modern agile, so there's no certifications, but it's something that is neutral in the sense that whether you practice Scrum or Kanban or Safe or whatever, these principles can influence you. And, you know, but again, this all came out of like, when I went to that open space conference in Prague, I had no idea I was going to talk about modern agile. You know, it was not like a predetermined thing. It was just like, my God, they're not talking about the modern ways we're doing stuff. So, and I always encourage people to, you know, keep pushing the limits and keep modernizing. I said to my own company the other day, our wonderful ways of working that we've been doing now for years that have evolved, they're probably antiquated as of today. You know, with generative AI, what would we do differently? Let's have a perspective on our own work as it needs to be modernized constantly. So the term modern in modern agile means always be modernizing, always be looking. Okay, I've had people say, well, Josh, some things don't need to be modernized. There's things that are just evergreen. They're classic. I'm like, absolutely. I'm not changing evolutionary design anytime soon. I find it to be quite useful in so many contexts. So yes, there's the evergreen stuff. And then there's the stuff where you can, indeed, discover a better way. The manifesto itself says, we are discovering better ways of working. Great. Keep that going. Keep modernizing and looking for easier, simpler, quick, easy grace. as the dictionary definition of Agile says, how can we work with quick, easy grace? That's always going to be improving, hopefully.

Brian (26:12)
Love that, yeah. And you're right, I mean, think there's some, to some people I think that there's, I guess at times an attitude of, you this is all new stuff or this is a brand new concept and something they don't really see the connection backwards in time to how these things are all built on other ideas that have been progressive over the years. So the idea of, yeah, this is, you know, we're, we're not saying that certain ideas are bad because now we're trying to modernize them. We're just saying we're trying to apply that same principle forward into kind of the context of today, which I don't see anyone should have a problem with that.

Joshua Kerievsky (26:48)
That's right. That's right. Well, and if you are experimenting and learning rapidly with your own process, which I highly encourage, chances are the way you work today will be different than it was yesterday. You will be exploring, like we use discovery trees today. We didn't use them before. Years ago, no one knew what a story map was. There wasn't such a thing as a story map. Now we have story maps. There's constant improvement happening. And you've got to be open-minded and willing to try new things and drop old stuff. We thought sprints and iterations and extreme programming was absolutely fundamentally part of the way to work. Then we started experimenting with dropping them and turned out, wow, this is pretty cool. We like this. It works pretty darn well for our purposes. That came through experimentation. some of our experiments were terrible, just terrible. It's not an experiment if you already know the outcome. keep pushing the limits of what can make you happier and more joyful at work in terms of producing great stuff.

Brian (27:46)
Awesome. That's great stuff. Well, I can't thank you enough for coming on, Joshua. This is great stuff. just, you know, we'll put all the links to the books mentioned and everything else in our show notes for everybody. But as Joshua said, you can go to modernagile.org and find out more about this if you'd like to. You'll find information there about Joshua himself or his company again is Industrial Logic, Inc. And, you know, his book again, just to mention that, Joy of Agility. We were talking how some people get that title a little mixed up or whatever, but it's just the three words, joy of agility. So just look out for that book. I think you'll find it a rich resource for you. Joshua, thanks so much for coming on.

Joshua Kerievsky (28:25)
Thank you, Brian. Thanks to you. Thanks to Mountain Goat and the folks there. And I really appreciate chatting with you. It was really wonderful.

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

15 januari 2025 | 30 min

Ready to spark real change in your organization? In this episode, Brian Milner sits down with April K. Mills, founder of Engine for Change, to reveal how anyone can become a powerful change agent—without waiting for permission. Learn how to drive meaningful change, navigate resistance, and reignite Agile practices with strategies that actually work.

Overview

In this inspiring episode of the Agile Mentors Podcast, Brian Milner talks with April K. Mills, CEO of Engine for Change and author of Everyone is a Change Agent, about what it truly means to lead change.

April explains how effective change agents focus on clearing obstacles rather than forcing compliance, and why fostering curiosity, empowerment, and collaboration is key to sustainable change.

From navigating corporate roadblocks to revitalizing Agile practices, April shares actionable insights and tactics to help you take control and make a lasting impact—whether you're in a small startup or a global enterprise.

References and resources mentioned in the show:

April K. Mills
Everyone is a Change Agent: A Guide to the Change Agent Essentials by April K. Mills
Change Tactics: 50 Ways Change Agents Boldly Escape the Status Quo by April K. Mills
Certified ScrumMaster® Training and Scrum Certification
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

April K. Mills is an engineer-turned-change-evangelist and author of Everyone is a Change Agent and Change Tactics, empowers individuals and organizations to thrive through change using her proven Change Agent Essentials. With a passion for turning ideas into action, April helps people drive meaningful change with the time, title, and budget they already have.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have April K. Mills with us. Welcome in April.

April K. Mills (00:11)
Thanks for having me.

Brian (00:13)
Very happy to have April with us. April is the founder and CEO of an organization called Engine for Change. That's engine-for-change.com. That's her website. She's also an author. There's a book that she put out called, Everyone is a Change Agent, a Guide to the Change Agent Essentials. And that's what we wanted to have her on to talk about today with a little bit about being a change agent. Now I shouldn't say from the outset, April is a request. We had a listener request for April to come on. And I always love that. I always try to push those people to the top of our list and get them on as soon as possible. And it was such an interesting topic. I thought this would be just a really great way to have a great topic to have early in 2025. So April, let's start with just trying to understand when we say change agent, how do you define that? What do you mean by change agent?

April K. Mills (01:09)
Yeah, a change agent is someone who takes action to bring about the change they want to see in the world. So rather than waiting for a boss or a corporate program or somebody from HR to come in and say, hey, let's improve this process, the change agent sees the need for a change and takes action. And the big thing I talk about in my books and my work is the difference between what typically happens when somebody sees a need for a change in an organization where they decide, I'm gonna go get a boss to go make everybody do my idea. I call that driving people. And I draw the contrast with that and driving change where you choose the change for yourself and you clear the obstacles for others to choose it too. And I love talking about that with Agile audiences especially because Agile is a change agent movement. of folks who want to drive change. I see a better way to create this product and I want to be part of it. And that's always what's drawn me into the agile space.

Brian (02:13)
Yeah, that's awesome. Yeah. And it is a big change, right? To think about the dynamics of someone kind of sitting back and saying, yeah, I see something that needs to be done. I see something that should be a different way, but you know, who am I to say anything about this? Who am I to do anything about versus the person who actually takes action and does things. So that kind of leads to a question about change agents. What kind of skills or traits do you think are really helpful or beneficial to someone to be a better change agent.

April K. Mills (02:46)
Well, the key is that difference between driving people and driving change. It's not what degree do you have, it's not how long have you been in the industry, it's not are you a people person, are you more focused on the data or some of those factors that we usually like to talk about. It really is, are you willing to take the step yourself first and clear those obstacles and encourage and invite people to join you? Or do you want somebody to make them obey you? And that choice is really the key for anybody to be a change agent. Because so many times we've seen people who might be able to convince the boss, hey, our team should be agile. And what happens, right? It goes on for about three months. The team gets frustrated. The boss gets angry. And then everybody starts to have a reaction when you bring it up, right? I'm sure plenty of the listeners have gone into an organization. If you're passionate about agile and you go, hey, have you guys heard about agile? And they go, ooh. And they make like a face. That's because they've encountered somebody who is driving people. And so that's the big focus I always try and talk with people about is can you show up with that willingness to let people join you and understand what their obstacles are to doing it.

Brian (03:57)
What are some kind of warning signs or signals you'd look for to kind of recognize whether I'm actually approaching this from a driving people perspective versus driving the change?

April K. Mills (04:08)
So a lot of times the key is how are you thinking about or talking about in your own head about the people around you or even yourself? We have a tendency to drive ourselves as well. So you can hear it in the language, right? I'm frustrated because so-and-so won't listen. I wish I could get more attention. It's all this sort of vague or... putting the action onto someone else and then complain the action isn't happening fast enough. You can hear it in the language. And so when someone's driving change, you don't hear that. hear, you know, I'm working on, I'm doing, the next thing is my action is I'm going to go talk with this person. I want to understand. I'm going to be curious. And you get this agency, this power coming back into your body almost, and then taking taking the next step from there. And so it's almost easy. You can almost say, well, how far outside your body would you put the power to make this change happen is a useful question to ask people. And if they say, well, it's in the CEO of the company, it's in the industry, it's in my tech lead, but it's certainly not me, well, then you're not a change agent.

Brian (05:20)
So that brings up a good point because I think I can try to channel what the listeners might be thinking here. I know that in times I've been in organizations where, yeah, you have the ideal, you have the thing that you think is the best thing to do. But because the power dynamics in the organization, you don't really have the power to make that change and you depend a little bit on others that have the power to to help affect it. And so there is a sort of an aspect of, I don't really have the capability or the power to cause this change to happen. How can I still stay with that mindset of driving change versus driving people when I know I need someone else's help?

April K. Mills (06:03)
Right. So that's a great conversation. And I've started to call it phase one Agile versus phase two Agile. I'm old enough in this space where when I first joined, a lot of Agile was team-based. Somebody on the team or several people on the team said, yeah, I want better. And these are the things that we can do as a team to deliver better. And let's do them together. And then the problem was the teams could do it, but they couldn't scale it. And they were like, if only we could get the senior leaders to pay attention to us, that would solve all our problems. And then you get phase two agile, which was executives buying agile implementations and forcing it down on people. There is one right way and we will do exactly this and you must conform and no other versions are allowed. And then we got the fractures and all of the fights about all of the different aspects. And so we tried it both ways, right? We tried it with the team effort and then we tried it with this thou shalt effort. And I think the key to actually making Agile work across organizations and deeper into organizations is to keep that energy from the team-based Agile to say, we're choosing something better, but it's that piece of driving change. What are the obstacles for others to choose it to? We didn't do that step. We went from my team does it, now the boss should make everybody else do what my team does. And I think that's where we got off track. in really scaling Agile into something that was sustainable and brought that joy and commitment and everyday wanting to show up and be better across the organization. So that's what I would encourage folks to do is not try to cheat that step of getting your fellow teams and larger systems to join you by finding somebody with the power to make them be like you.

Brian (07:50)
That's fascinating. I know that in some of these changes I've been involved with as well, there can be things that happen that kind of find yourself stalled a little bit, right? The initiative or the changes you're trying to affect just doesn't feel like it's going where it needs to go. What advice do you have for people who feel like they're in that place where they feel like they're kind of stalled out? in the change.

April K. Mills (08:16)
Yeah, so a lot of the things I talk about in that book you mentioned everyone is a change agent are different tactics you can use to overcome that. One of the key things that I talk about is what I call a change buffer, which is how can you make the rules where you're at different than those rules across the organization? I mean, let's take a simple example. Let's say there's five software teams in a business. Very simple example, right? And one is doing some practices and they'd love for those practices to spread. but they're not spreading as fast as they would hope. One of the ways to protect your change is to say, on our team, we will behave this way, declare it, make it what I call a policy buffer. So when one of those other four teams says, well, why are you doing it that way? You can point to the piece of paper and say, we've agreed to behave this way. Now, if you'd love to join us, we'd love to share that with you, but this team behaves this way. So then it's not every developer having to defend in effect the practices, which can get exhausting. But then you can start to ask them, what's your policy on your team? How do you do this? And get curious. Not in a, I'm trying to lure them in and trap them into my way of behaving, but in a, really want to understand, do they have a different measure that they're being exposed to? How can we help maybe get that measure off of them? Do they have a boss who's got a different standard for what quality looks like? Well, should we have a corporate conversation around, quality across the five teams should be the same. We don't tend to have those because we want to skip the step of coming into that alignment together and just have a policy somehow drop from the stars that aligns with my values. yeah, policy buffers are really big to protect a change and help it spread and have those curious conversations at the edges. Think of it like system integration, right? You can't just dictate, you have to understand and merge.

Brian (10:11)
Let's say we put in place a policy buffer like that on our team and our whole team agrees to doing something and we think this is the right way of doing things. And someone higher in the organization, some manager or leader finds out about this and says, no, I don't want that to happen. We've been trying to affect the change, right? And not push the individual. But now we do have the individual who's saying, you shall not do this. How do you overcome that when you're the change engine?

April K. Mills (10:38)
Yeah, so a lot of times you have to understand what are the assumptions that that leader is making and again get curious, right? Because if we focus not on the method but on the outcome, we should be able to get alignment faster. So rather than going into a boss and saying, method A is my choice, method B is yours, you know, it's a cage match, two will enter, one will leave. You instead want to show up and say, Well, I think we both agree we want to deliver quality products on time that customers love at the lowest possible production costs. Are we aligned on that or not? And if they say yes, then you say, okay, now let's just understand what are you asking for? And from my perspective as a person who has to implement that, here's how I think that impacts our ability to deliver quality products that customers love at the lowest possible production costs. And these methods that I'm using are doing this and here's my data or evidence. And so you in effect want to shift it where it's not me looking at you, but as people are probably going to see on this podcast, it's us next to each other. So if we instead frame it as me and the leader looking at the issue together, because we want to win together, we're not in competition. So again, it's about seeking to understand, removing those obstacles so that we can be aligned together to go there together.

Brian (11:57)
I love the idea of backtracking a little bit and finding that common ground and going from that space. I think that's a great approach. I know I've had success with that in my career too, of being able to find, well, we agree on this, right? And if we agree on this, now we're just talking about the best way of getting from where we are to there. And then it's less personal, then it's less about the person, it's more about the best strategy. And we're a little bit less... personally invested that we think it's a you know a personal affront or challenge if it's if it's more about the idea So I agree. I think that's a that's a great kind of approach to doing that How about the differences in just the the context of this if I'm a change I know you know I've been in some small organizations. I've been in some medium large-sized organizations and You know I think anyone who's been in large organizations would say Well, yeah, that's nice and easy when it's in a startup, right? If I'm in a startup, then yeah, everyone's wearing a lot of different hats and it's really easy to make change, but you know, the institutional kind of inertia that can take place in larger organizations, how do you overcome that as a change agent?

April K. Mills (13:00)
Yeah, well, I can speak to that from deep experience because my background started as a civilian nuclear engineer for the US Navy in a hundred year old shipyard. And I started six weeks before September 11th. So I came into a nuclear shipyard, a hundred years old, very staid in the way they did things, optimized for the shipyard and the world changed.

Brian (13:03)
Ha ha ha ha.

April K. Mills (13:25)
And I watched as that organization struggled to deal with the rate of change that was being imposed upon them. And a lot of the things that I talk about in everyone is a change agent came out of that experience of understanding what tactics worked, what didn't, what philosophy worked, what didn't to be able to empower people to make changes happen. And we made amazing changes happen in the shipyard. And then I went on and did 10 years with Intel Corporation, right? The chip maker and taught these things globally and saw people do amazing things within the company. Now it's true, if you don't get the main rudder of the company, you're not gonna steer it. But there's a lot of change you can make in an organization from where you're at. And I think that's the powerful, powerful thing. And so these tactics work at scale. They work for an individual, right? If you stop talking to yourself like, you know what you need to do? You have to do this or so and so is gonna get mad at you and you instead say, What's our obstacle for getting up early and going to the gym? And how can I clear that? And how can I choose to do that every day all the way up to a team, all the way up to an organization? I've seen these things work all the way through that scale. So I've used it in community projects to deliver an accessible playground in three and a half years when everybody said it would take five or 10. And these tactics have also been proven, although they weren't listed this way, in historical successes. If you think about when Admiral Rickover founded the nuclear Navy back in 1950, they went from approval to use nuclear power to USS Nautilus underway in five years. We can't deliver anything in five years anymore because we constantly are looking for who's going to make people, how are we going to force them? Can we keep them forced to do it? And with employee turnover, with system turnover, with the rate of change, I would argue this era of driving people has to end because it wasn't ever really effective, but it's getting less and less effective. And that's the name of my second book, which is Change Tactics, which is both you should change tactics and here are some change tactics to help people accelerate their results.

Brian (15:36)
That's awesome. Yeah, I mean, it gets really deep really quickly here too, because you start to think about even the way we manage our projects and the fact that a lot of more traditional project management is sort of, when we talk about this change agent approach, is sort of managing the people and trying to push and drive the people towards deadlines, some, not even an outcome, but a timeline. versus trying to affect the outcomes that we're trying to achieve as an end result instead. So it really is interconnected, isn't it, through even the way we set up our projects?

April K. Mills (16:13)
Yes, it totally is. And I have that in the book and in the classes I teach is where is the force? So I'm an engineer by training, right? So I'm constantly looking and thinking about where's the force in the system if it was a pump or a reactor plant or whatever. And you can see it to your point with the program management is your, are you spending most of your time trying to push people to do something? Or are you moving the form, fit and function of whatever the product is? If that's delivering code and integrating code, if that's a physical product, are you clearing the obstacle so that product moves forward faster? And you hear this and see this in stories of what's going on at SpaceX, right? When they're confronting something about, can't get a part for six months or I can't get a part for a year and it's gonna cost me $50,000, they're saying. Isn't it just sheet metal? How could we make that in two weeks with what we've got? Because they're not talking about you should be able to shrink that timeline. What are you doing? Why aren't you talking to the vendor enough? aren't you pushing on the vendor hard enough? They're saying, what is the physical thing we need and how fast can we get it? And it's allowing them to shrink product costs. It's allowing them to shrink durations. It's what Rickover did in the 50s. It's what Andy Grove did with Intel back when it was Intel delivers in the 80s and 90s. Focus on the product, focus on the physics, focus on the engineering, the mechanics to support the engineering, the operations to support the mechanics, and you'll deliver products faster. And at the heart of all of that is change agents because they're not trying to get somebody to obey. They want to get something amazing done.

Brian (17:50)
One of the things I found kind of in when I've worked with organizations and talked with organizations about kind of moving from point A to point B is the fact that you kind of need help. kind of need, know, a lot of times people will try to make these changes all on their own and they sort of take the weight of the world on their shoulders. I can't figure out why it's not working. How do you kind of co-opt others into your strategy?

April K. Mills (18:14)
Yeah, well, the best way is to share with them what you've learned about being a change agent. I've had countless folks who, know, one person will read my book or come to a class and they'll go back and try it and people will get curious because you show up differently. So a simple example that I give in the book is rather than sending a mandatory meeting, which we're all guilty of, right, we get an assignment. and we go into the global outlook calendar and we pick people and we make them mandatory and we order them to come to our meeting. We say, Brian gave me this assignment. You have to come. Brian said this is really important. Come to my meeting or else. And we do that. That's the default. And I encourage folks from a driving change perspective to instead, maybe Brian, you gave me that assignment, but my meeting notice would say, I've been asked by Brian to lead this. I'm excited to do that. Here's why I've chosen this as the thing I'm going to focus on. I've marked you all optional. I think you have the skills and capabilities that would be amazing on this team. And if you're as passionate as I am, I'd love you to partner with me. We're going to start meeting on Tuesday. If you're not the right one, feel free to tell me. But I'm moving forward on Tuesday with whoever's there. And I'm really grateful that I get to work in an organization with you. Now. Who's gonna come to, which meeting are you gonna come to? The April says Brian's gonna be mad at you if you don't, or the one where April's gonna go off and do something amazing, I don't wanna miss out. And anybody can do that because everybody send in meeting notices out to people. So the simplest actions have the most powerful results.

Brian (19:31)
Ha It really is a cultural change too, right? mean, that's a very different cultural kind of approach to it to say, hey, it's optional, but, you know, get on board with this idea. If this is something that you're excited about, I want you to be a part of this versus, hey, you've got to, that's your job. you know, I've been given the authority to, to demand that you be here and, and, and, you know, really want. So, so how do you. You know culture changes is obviously one of the hardest things to do in an organization. How do you start to if you're a change agent? How do you start to? Change the culture in the organization to be more in line with that

April K. Mills (20:25)
So my focus is always on the culture starts with one. So people will treat you the way you show up. And so show up as a change agent and the world will bend around you in reaction to it. Now I do have a chapter in the book where I talk about my son who's got special needs and he took a long time for him to walk. He had to walk with forearm crutches. And the first time we were really out in public, he was walking with his forearm crutches. And you could tell that people were really confused and concerned, right? It's different. He's a small child. He looks very fragile. And you had all these reactions from people about, well, you know, where's his mother? Cause I was watching him from a little ways away. I always joke, no one ever asked where's his father if a child is wandering off. But you know, they're watching him and you could tell there were people that wanted to either pick him up and do it for him. Take him someplace because he looks so fragile, let me help you. Or they were mad that he was off on his own and I wasn't hovering. And I use that story for the same thing here. Because when you go off and you say, let's make this optional, I'm passionate about it, I'm committed, and even if I'm alone in this room, I'm going to move this forward, people are going to look at you funny. Like my son with his forearm crutches because they're used to somebody walking off strong, demanding, creating space. But it doesn't mean that that's necessarily the best way to do it. And so you have to be comfortable being different. And I use the concept of change buffers to help people with that. A personal buffer might be like Richard Feynman, the noted physicist. I don't care what other people think. I'm going to be me, their concerns to the wind. A friendship buffer. I'm going to go off and do this. when somebody goes, April's crazy. I call my friend Brian and you go, you're not crazy. You're doing the right thing. Keep it up. Let's go for coffee, let's go for the beer, whatever. A leadership buffer, maybe you're my boss and you believe in this, you've seen it. I go off and do it, people give me a hard time. I go, hey, take it up with Brian, my boss. We do things this way in his group. Or back to that policy buffer. In my group, we drive change, not people. So when somebody shows up differently, folks go, you know, why are you doing that? it's just the way we work. And that's what I've built in organizations over the years. The people that were in The groups with me that were doing this, depending on how comfortable and how strong they felt, could either say, I'm different, live with it. Or they could say, we're different. Or the policy is different. Whatever they needed to feel strong enough to show up differently. Because when you show up differently, you get amazing results.

Brian (22:58)
Yeah. That's so, that's so awesome. I completely agree. What if people are listening to this and hearing all this and getting excited about it and thinking, yeah, this is, this sounds like something I want to participate in. is, it sounds like something I want to start to do. if someone feels inspired by this conversation and wants to be, become more of a change agent, uh, but they really just don't know where to start. What are some practical things that you would give them to say, here's, here's a good way to start to, to move down this path.

April K. Mills (23:27)
Yeah, well, the simplest one is that's why you write books, right? So my book is available. I self-published it on purpose to make it very affordable. So it's, think, $9.99. Everyone is a change agent. It's $14.99 for change tactics because I accidentally wrote a longer book than I intended. sorry. When I got the first copy, I'm like, oh, that's more than I thought it was. OK. But so both of those. So for, you know, the price of a meal.

Brian (23:44)
You

April K. Mills (23:54)
for one person these days with inflation, right? You can get two books that help you not only have the basis, but have some just simple tactics, almost like a recipe book you can use. And then later this spring, I'm rolling out with my Engine for Change Company, this Change Agent Essentials class, which is based on that content. I've been teaching it now for 10 years in corporations. As we were talking before we started, right, I'm a recovering hider in corporations, I guess. Now I'm coming out into the world. And so it's going to be available for folks if they want to take the class to get that more immersive experience. So I'm really excited to bring it to the world because it works. And I'm especially passionate about agile people using it because there's too much conversation around agile dying and we need better products delivered faster that customers love at the lowest possible costs. And I don't know a better way to get there. So we got to reclaim agile from the driving people.

Brian (24:47)
Yeah, I completely agree. you know, anyone who's been involved in Agile in any significant, you know, way I'm sure would probably agree that it's not that the core concepts in any way are, are less, valid or, or, or no longer practical or anything like that. It's just people have seen so much bad versions of things that now that that definition has been marred a little bit, I would say. And so now we, we, we have to kind of take Like you said, take back control of that a little bit and say, now here's what it really is, and here's why we do things this way. And I like your approach there. Find the common ground and say, here's, you know, we both believe in this. Well, what's the best way of doing that? You know, here's what we think.

April K. Mills (25:28)
Yeah. Yeah. Yeah. And I think it's going to be a really exciting time as we go into 2025. There's so much change happening, but so much of it is at that default of driving people. So there's a huge opportunity to show up differently, to create a ripple. That one person can create that ripple. You three people can support each other while they try these new things. By the time you get to five, you almost have critical mass, right? At least two of you will always be online at any one time to support each other. And you can grow it from there. And I've seen great, great things happen. And it really is an unleashing of energy. If people can remember the first feeling they had when they found Agile and it was like, yeah, that feels more like what a professional does. And that excitement and that energy, you can get back to that and you can get back to that by driving change.

Brian (26:24)
Love it, love it, this is awesome. Well, this has been a great conversation. I really appreciate you coming on. We're gonna put links to everything in our show notes for everyone so you can get to April's company and find out more about her classes and also find out more about her books there as well. So April, thank you so much for coming on.

April K. Mills (26:40)
Thanks for having me. It was an honor to be recommended.

Brian (26:43)
Well, and our honor to have you on as well. So thank you for our listeners and recommending people and thank you April for making the time for us.

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

8 januari 2025 | 43 min

Curious about the future of Agile in 2025? Join Brian and Lance Dacy as they dive into the rise of AI, hyper-personalization, and how teams can balance innovation with customer focus. Plus, discover actionable insights to navigate a rapidly evolving landscape—don’t miss this forward-looking discussion!

Overview

In this episode of the Agile Mentors Podcast, Brian and Lance set their sights on 2025, exploring how AI is transforming Agile practices and reshaping customer engagement.

They discuss the shift from output to outcome metrics, the expansion of Agile beyond IT, and the critical role of leadership agility. With practical takeaways on fostering continuous learning and delivering real value, this episode equips teams and leaders to stay ahead in a fast-changing world.

References and resources mentioned in the show:

Lance Dacy
Accurate Agile Planning
Subscribe to the Agile Mentors Podcast
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

Auto-generated Transcript:

Brian (00:00)
Happy New Year's Agile Mentors. We are back and a very happy New Year's to everyone who's listening. Welcome back for another episode and another new year of the Agile Mentors podcast. I'm with you as always, Brian Milner, and we have our friend of the show for our annual kind of tradition now. We have Mr. Lance Dacey back with us. Welcome in, Lance.

Lance Dacy (00:23)
Thank you, Brian. Happy New Year to all of y'all. Happy to be setting this tradition. think it's two times now, so we'll just call it a tradition, but I love it. Thank you for having me.

Brian (00:32)
Very glad to have you here. The tradition we're referring to is that we like to take the first episode of the new year and just take a pause and kind of look ahead a little bit. What do we see coming up? What do we think this new year is going to be like? Obviously, it's a year of change. Here in the US, we'll have a new president that comes in. I'm not going to get into whether you like that or not, but it's new. It's going to be a change. There's going to be differences that take place. And I know there's a lot of differences and changes going on just in the way businesses operate and how things are run and lots of new technologies, lots of new trends. So we just thought we'd take a pause and kind of scan the horizon and maybe give you our take at least on what we're hearing and what we're seeing. And you can see if you agree with these or not. We'd love to hear from you in our discussion forum on the Agile Mentors Community afterwards if you have other thoughts or opinions on this. let's get into it. Let's start to talk about this. So Lance, I guess I'll start. I'll just turn it over to you and ask you that generalized question. Give me one point or one thing that you've been reading or seeing recently that you think is going to be a really important thing for us to kind of be prepared for or look out for here in 2025.

Lance Dacy (01:44)
Great question, Brian. There's so many things out there, and I thought we could start by looking back a little bit. if we're okay with that, just let's summarize, you what did we see happen in 2024? You mentioned, you know, 2025 is a year of change, absolutely, but 2024 was definitely a different kind of year as far as my experience is concerned and seeing a lot of industry trends that are just popping up out of nowhere. Now we are fans of agility, which means we embrace quick, efficient changes, but there's things going on in 2024 I never predicted

Brian (01:52)
Yeah, yeah.

Lance Dacy (02:19)
fast. And so I think we've got to reshape the way that we're thinking about these things. I think the topic of mind, one of the biggest shifts that I saw in 2024 that I think will continue in 2025 is AI. So that artificial intelligence is a big word that we keep lumping into a lot of things. And I just wanted to take a pause a little bit and say, I know everybody's got a little bit different experience about AI, but in particular, as it relates to product development and agile delivery, which is what this show is basically focused on, I thought we could look at some insights of what happened in 2024 with that. And so I think I call us babies at it right now. And I know that may be a bad term, but I have a lot of experience with AI and machine learning and things like that. But as far as the use of it, I feel like we're all a little bit more of babies on how to use it in the day-to-day work that we're trying to accomplish. And I think that comes with learning something. I embrace that. I don't mean that as a downplay, by the way, but that we're all babies. I'm just saying we're less mature about it. We're experimenting with a lot of things. And I don't think that some of the AI is all good. I I embrace it as a thing that's going to help us later on, but... I thought we could just share our experiences of how we've seen this thing manifest itself. I think tools like AI driven, I'm going to use the bad word JIRA, but in place of that, just use any product backlog management tool that you see. And I've seen a lot of organizations not just talk the game of, we use AI for our backlog management, but I'm talking about backlog prioritization, sprint planning capacity. And I believe what's happening is it frees teams up to do more of the... value driven work that we're going to see a lot more of in 2025. So what I mean by that is when we got automated testing and development, if you remember those days, it freed the developers up or the testers, should say, from doing less of the does this thing work to more of how does it feel using it as a human being, you know, automating that. So I've seen things like JIRA, with AI with JIRA and GitHub co-pilots, you know, reshaping the value creation in the teams and eliminating the need of having to do very low level tasks. So what is your thoughts on that and do you have any experiences of that as well?

Brian (04:36)
Yeah, for sure. There's a couple of things I've found that just kind of some stats I found from some different places. you know, listeners know I'm kind of like a data geek here. want to know where the data comes from and want to make sure it's a, yeah. Yeah. You want to make sure it's a solid source and it's not some questionable, you know, sketchy kind of, well, I asked 10 of my friends and here's the answer, you Right, right. Exactly.

Lance Dacy (04:48)
Good hand. I love that. or a FBI.

Brian (05:02)
But so there's a couple of things that came back. One was, I think Forrester is probably a pretty good source of information. They have some pretty good rigor to their process. And they have a thing that they put out every year. This one's just called the Developer Survey. And this is the one that they put out for 2024 that I'm quoting here. But a couple of stats from that that I found interesting. One was, 49 % of developers are expecting to use or are already using general AI assistance in their coding phase of software development, which, you know, maybe higher than most people might think. But it doesn't surprise me too much. I think that's probably kind of what I'm used to it. Understand saying, you know, an assistant co-pilot, that kind of thing. They're not saying 49 % have been replaced. They're saying 49 % are being assisted. by that and that seems about right. Maybe again, maybe a little higher than some might expect, but that seems like not too big of a shocker.

Lance Dacy (06:04)
Well, the animation too. So when you talk about assistance versus letting it run it, I saw a gentleman on LinkedIn, which is also a good. I wish we could interact more with our users on this call, because I'd love to hear their perspective. But I heard somebody say, let AI write my code. No, thank you. Code is like poetry. It has to be refined over time. It has humanistic qualities. And I was like, man, that's a really good point. But when I try to show my kids how to create a Ruby on Rails app to do an e-commerce site and I type it into chat GPT or whatever tool you use, I was amazed at how quickly it was able to put together. mean, you got to still know the file structures and things like that. But I don't know that developers are just going to say, I was going to write the whole thing. think they're, I think it's saving us keystrokes. I think we talked about that last time as well, but that's an interesting, interesting take.

Brian (06:50)
Yeah. Yeah. So I thought, I thought that was interesting. There was another, you know, I'm kind of, I'll move around between these two sources basically, but there's another source that I saw where there was a Harvard Business Review article. posted this on LinkedIn a while back, but it was a kind of the source of it was about a survey that they did to try to determine the impact on the job market. And one of the things they did was now their data was from July, 2021 to July, 2023. So this is a little bit older data, right? The survey was trying to say in analyzing the job postings on freelancer job sites specifically, and they tried to identify ones that might be affected by the advent of chat GPT, because that's the period where chat GPT really started to come onto the scene and started to become prevalent. And what they found was about a 21 % decrease in the weekly number of posts and what they call automation prone.

Lance Dacy (07:35)
Yeah.

Brian (07:47)
jobs compared to manually intensive jobs. They said riding jobs were affected the most 30.37 % decrease, followed up by software app and web development 20.62 % decrease and engineering 10.42 % decrease. But the interesting kind of thing is they found it kind of towards the end of that there was some increases and their kind of conclusion was that there was actually an increase in demand of the kinds of work that required human judgment and decision-making. And so that kind of ties back into what you were saying about let AI write my code whole, completely no, there's still a requirement for that human judgment and decision-making. I think this is why I'm not afraid of it, right? This is kind of, I don't want to make this an AI show, it's about the future in 2025, but when we had a...

Lance Dacy (08:17)
All right. Right.

Brian (08:40)
When we've had AI shows, that's one of the things I've said to the audience here is that I'm not so afraid of AI being sort of the doom and gloom of it's going to destroy profession or destroy. It's going to change it. But I don't think that's any different than any other. A great kind of analogy I make is when we started to have testing automation. It didn't do away with testers. This is just another tool that's going to be in our tool belt.

Lance Dacy (08:51)
Guy net.

Brian (09:05)
And I think our challenge is not to, you know, we're agilist, not to resist change, but to try to adapt, try to find ways that we can align and incorporate and get the most out of it. So, yeah.

Lance Dacy (09:17)
I think the most part of that though is, Brian, too, what most people fear. And I agree with you, we won't make it an AI show. just, we got a couple of points to make on this. But for the first time ever in human history, we now have something that might be more intelligent than us. And that is scary because there's some AI neural network engines that people can't explain how it's working anymore. They put it in place. And then it's like, we're not quite sure how it's doing all of this. And that's a scary thing, obviously, that can get out of control. We've never really had to face that. So we do have to be aware of that, but you know, let's go back and peel it back. Hey, we're, trying to plan a backlog with AI and we're trying to write a few Ruby on Rails code. I'm not letting it run my life yet. And one day it may already be doing that. I just don't even know it. I don't know. We won't get into that debate, but I think the thing is that we need to take pause of in the agile industry. is we embrace new technology as long as it's helping us deliver faster to our customers and save us time and efficiency. You know, I tell teams all the time, Agile is about delivering the highest business value items as early as possible with the least amount of cost friction, know, whatever word you want to use for that. Well, AI might help us do that, but I want to caution that. I think you and I were just talking about this. I wanted you to bring up that news story element that we were talking about. where people are just pushing content out there and kind of desensitizing us to is that important information or not? And I think AI needs to tag onto that. So I didn't know if you could share that real quick and then I want to share some metrics that I've seen some teams capture. There's a lot of teams now adopting these things called Dora metrics, which was created by a DevOps engineering group. And it's amazing to me now that we have real data to see, well, we have embraced AI.

Brian (10:45)
Sure.

Lance Dacy (10:59)
does do some things or not, I'd like to balance the good with the bad on that. But can you go over that new stuff that you were sharing with me?

Brian (11:05)
Yeah, no, it's just a conversation I've been having recently with people, they're friends of mine and kind of, you're probably feeling the same way about this in certain places, but the breaking news alerts that you get on your phone, you get those things all the time and I've had friends and I have discussions about maybe it's time to just turn them off. There's just so many breaking news alerts and that's kind of the issue, right? Is that there are so many that are now classified as

Lance Dacy (11:23)
Yeah.

Brian (11:31)
breaking news that you kind of look at that and say, this isn't really breaking news. You know, like if something really major happens, yeah, I want to know about that. I'd like to get an alert about something that's truly breaking news. the, you know, have major news sources, apps on my phone and get those breaking news alerts all the time. And some of them are just things that are minor, minor news that I would be much better served seeing in a summary and like a daily summary or even a weekly summary on some of the things. Right.

Lance Dacy (11:50)
Yeah. Or if at all, like you don't care about the sub undersecretary of Parks and Lighting in Minnetoca. You know, I don't know. It's just like, thank you for that information. But I totally agree that I feel like we're getting desensitized to a lot of these words, buzzwords, if you will. And we as humans are going to have to learn in this environment. And I'm trying to teach this with my kids as well, because they're the ones suffering the most from it.

Brian (12:04)
Right. Yeah.

Lance Dacy (12:22)
It's just inane information out there and you're filling your brains with the main things. So AI is great because it's allowing people to deliver more content, but is that content of substance or they just trying to market to you and get you, I forget the word you use for it, but, you know, keep you on a leash. Is that what you said? A small.

Brian (12:42)
Yeah, yeah. Yeah, that's, yeah, that's kind of what we were saying about this is that I think that the kind of conclusion that led me to is that I and I've seen this trend, I think in other areas as well, as I sort of feel like maybe with bigger companies, more than others in today's world, there seems to be a shift a little bit that, you know, for example, that that breaking news thing, it's not it's not something that benefits the customer, right? As the customer, I don't think there's a customer out there that says, I really love all these minor news stories appearing in my breaking newsfeed. But what it benefits is the company. It benefits the source because it keeps you engaged. It keeps you coming back and it keeps that ping to keep you engaged. And that's what they're trying to promote. That's good for the... Yeah, that's good for the company, but it's not good for the customer. I think that there may be, we may see some real kind of shifts I think happen in...

Lance Dacy (13:21)
Or me, it keeps me frustrated and I leave them.

Brian (13:34)
Some of those big companies maybe have moved too far in that way to favor their company's interest over the customer. And that leaves a door of opportunity, I think, for smaller companies to say, well, we're going to be all in on just what's best for the customer. And I think customers will appreciate that and will reward that because it's annoying otherwise.

Lance Dacy (13:54)
That's what I want to focus on because the last part of this AI conversation I want to have is I like a lot of what Gary Hamill, he's a management professor at a lot of different schools recently. He visits a lot of companies as well, but I really like the way he delivers his content and how he's more innovative and thought. I mean, I tell people all the time that management and leadership has not seen any innovation in 150 years. It's about time. that we start learning how to create cultures for human beings that are bringing gifts and talents every day to make things better for our customers. And Gary Hamill is a really good source if you're interested in those kinds of things. And so he emphasizes how AI has reshaped value creation by eliminating those low-level tasks that I think we all can embrace and are allowing agile teams to achieve unprecedented efficiency. Now... We are babies immature with this technology. So maybe these news organizations and the ones that we're going to kind of say, you're not doing a good job at it. It's not because they're bad. It's just we're learning how to use a new tool and hopefully customer feedback will change that. But I wanted to hit on these Dora metrics. Dora metrics are, I think they were created by DevOps research and assessment. That's what they kind of stand for. And there's four major categories. that Dora metrics measure as it relates to more of an engineering benchmark. Like how well are we, if you're an agile software development product company, Dora metrics are really good for you to look at. know, metrics can be misused, so be careful, but they're measuring outcomes. You know, what is our deployment frequency, which could be an output metric, because who knows if you're releasing the right things, but let's not get into that conversation. deployment frequency, lead time for changes, the change failure rate of your changes, and the meantime to recovery of those changes. I think those are really four good performance benchmarks. And they're starting to surface a lot in organizations that I work with. So you kind of use tools like Jellyfish or something to overlay over Jira. And all these tools are great, but these teams are using AI. And I found that we finally get some real data that says, how well is AI affecting those core metrics if you were measuring performance benchmarks of the software that you're delivering. And so this report that was created by the 2024 Accelerate State of DevOps report, they categorize organizations and performance clusters like elite, high, medium, and low. And based on their performance across these metrics that I just mentioned earlier, they're evaluating and guiding their software delivery practices. And so the impact of AI adoption was really cool to see on the DevOps Launchpad was a site that I saw this on, that the integration of AI into the development processes, as we were just talking about, has mixed effects on those door metrics. Can you believe that? So a 25 % increase in AI adoption correlated with a one and a half percent decrease in team throughput and a 72 % decrease in the stability of the product. Now these suggest that while AI, you know, offers productivity benefits maybe for the individuals or the teams, it has a, you know, it's introducing complexities that are affecting the software delivery performance. So I want our audience to pay attention to that.

Brian (16:59)
Wow. Wow.

Lance Dacy (17:21)
and start using some of these maybe to push back on managers and leaders that are just embracing this new tool and say, let's just push this on the teams. So that's the impact of AI adoption. And then if you look at platform engineering, so if you look at the implementation of an internal developer platforms, you know, that are helping developers deploy code faster, the adoption of AI led to an 8 % increase in individual productivity. and a 10 % increase at the team level. Now that's fantastic. But these gains were accompanied by an 8 % decrease in change throughput. So while the teams may be able to make changes, what I interpret that to mean is the customer is not seeing the changes. There's an 8 % decrease in the throughput all the way as a cycle time, if you will, all the way to the customer and a 14 % decrease in the stability of the product. So that indicates trade-offs. that we all need to be aware of that AI might be helping us performance wise, but it's not helping the customer a whole lot if we're destabilizing the platform. So I haven't dug into those metrics a lot, but I wanted to share that with the audience because if you do find yourself in a position where people are pushing this, you can try to go reference those and maybe give them some, I always call it pros and cons, right? There's no really right or wrong when you're an agile team trying to make a decision. You got to look at the pros and the cons and

Brian (18:23)
Yeah.

Lance Dacy (18:40)
We might accept a pro, multiple pros that come with some cons, but we all look at each other and say, that's the better decision for our customer. And we live with those cons, whatever they may be. So I wanted to talk about that because it centers on what you were just thinking with the news organization. just push, we got more productive at pushing content, but was it the right content or is it destabilizing what people are using? And you just have to be careful of that.

Brian (18:57)
Yeah. Yeah, no, I think those are excellent points. I think that's one of the things I see kind of for 2025 as well is that we're still so much in the empathy of how AI really plays into how a team operates and how development works that I don't think we can really say ultimately what's the right way or wrong way to do anything yet. I think it's good for teams to experiment. I don't think you should be afraid of experimenting and trying things. But it all comes back to the basic principle we say over and over as Agilist, inspect and adapt on it. Try something and identify what works about it and what doesn't work. And if that means that, we're using it too much and it's causing too much errors, we'll back off, find the right point, and move forward with that.

Lance Dacy (19:41)
Yeah. Or where companies are using it bad. Like I have a story that we won't get into here where a CEO or an executive of the company was mandating that they use AI to do something not so good for the customers. And you want to be able to push on that as well. So I'm sorry to interrupt you on that, but I was just like, man, that's something.

Brian (20:07)
Right. No.

Lance Dacy (20:11)
Sometimes, like we want to self-organize around the experimentation. We don't want it pushed in like management saying, need to use this because I want you more productive and managers be careful of doing that. Make sure you understand the pros and cons as much as you can before you dictate.

Brian (20:26)
Yeah. Something else you kind of said triggered something to me. I know the, I think that, well, not in a bad way, but it just, you know, the metrics I think that you mentioned were really good metrics. I liked the idea of kind of measuring, you know, things like, you know, the failure, the bug rate, you know, like how many defects and those kinds of things I think are good metrics. But they kind of,

Lance Dacy (20:31)
What? Okay.

Brian (20:49)
point out a certain difference that I think that's out there that I think the business community is wrestling with. And I hear these questions all the times in class, so I know it's prevalent out there. But we talk about building high performing teams. And just the difference between that word performing and productivity. There's sometimes I think confusion or false equivalency. between those two, that performance equals productivity. And I think a lot of the metrics sometimes we see that get measured or that we try to measure even, kind of expose that, as that's what's really the issue here, is that we're really trying to make that false equivalency between the two. It's not saying that performance has nothing to do with it, but

Lance Dacy (21:15)
Right.

Brian (21:32)
You know, this is the simplicity, the art of maximizing the amount of work not done is essential. You know, I'd rather have low productivity, but what we produce is high performing, is highly valuable, is something that matters, right? And I think that's kind of those kinds of statistics like you were bringing up, you know, what is our failure rate of things we put out there?

Lance Dacy (21:44)
Yeah.

Brian (21:54)
That is, I think, a performance metric to say, the old phrase, slow down to go faster. Right, right. Maybe the reason that our failure rate goes up and we're having problems with this is that we're trying to go too fast. And if we could back off, it ultimately makes you go faster if you have less bugs that you then have to go back and fix.

Lance Dacy (22:00)
Yeah, make hate, totally. Yeah.

Brian (22:19)
So it may be counterintuitive to certain organizations. Let's push them. Let's try to get everyone to go faster. But I think these new kind of metrics that you mentioned that we're trying to measure more and more, I think are starting to open people's eyes a little bit to the difference between those two words.

Lance Dacy (22:22)
I mean Well, in like the CrowdStrike situation, you know, that took down a lot of the airline systems, you know, I'm not saying they make, they didn't do a good job deploying and everything. All of us are victim of that kind of thing. But, know, to get us back on track a little bit, because you asked me the question, then I felt like I got us off on a tangent. know, 2024, obviously the rise of AI integration into

Brian (22:48)
Sure.

Lance Dacy (22:54)
the workflows that we experienced with Agile. And I just wanted to highlight, yeah, those are some great things, experiment with it. We're in our infancy. So there are a lot of things to discover that may not be so good. So start trying to put metrics in place. And I thought the Dora metrics, you know, as I've started discovering those, I'm a data guy and I'm like, yeah, as long as those are being tracked correctly, I think that's a good benchmark to kind of look at, hey, we're making a lot of changes in our software, but it's crashing the system. So change is good, crashing is bad. there's pros and cons, so we have to delegate that or figure that out. Now, the other one that you just mentioned, I thought I saw a great shift in 2024 from output related metrics to outcome oriented metrics. So the Scrum Alliance has a report, which we're all probably familiar with, especially you and I being certified Scrum trainers with, and we get a lot of data from them. But teams moved away from feature counts to measuring outcomes like

Brian (23:35)
Yeah. Yeah.

Lance Dacy (23:49)
customer satisfaction, user retention. You we teach this in our advanced certified Scrum Master workshops, the difference between output versus outcome metrics. And we've been doing that for five years. And I think it's really starting to take hold that management and leadership and maybe even teams are measuring the wrong thing. And I really saw the needle move in 2024 that people's eyes are opening that let's measure the outcomes of what we're doing. Sometimes that sacrifices individual productivity and performance for a greater outcome achieved at the organization or customer level. And we've been trying to articulate that for many years. And so I've seen a shift in that. And then also the rise of Agile beyond what I would generalize as IT. So Agile Alliance produced some information that I thought was interesting that Agile has expanded into health care or sectors like health care. education, human resources, HR, and those are typically what we would see the laggards, you know, back in the day, banking and healthcare and all those were the last people to adopt this progressive planning approach because of the way that they budget and finance and rightfully so. But those agile principles have been proven out far beyond software unpredictable type work and is going more into, you know, the different types of work environments and I think onto that is how it's getting involved more in leadership. So I don't know about you, but I've also seen people focusing more on building a culture of, I would like to call it leadership agility. So John Maxwell, you know, is a vocal person in the industry about leadership. And he underscored this idea that agile leadership. in driving transformation across non-technical domains. So not just a digital transformation, but non-technical domains is really taking hold in this idea of empowering cross-functional teams. You we've been saying this in technology for years, that the siloed development method is not good. Well, organizations are starting to see that not only in the tech sector, but why don't we put a marketing cross-functional team together with this other team? And that's what they talked about in 86. you know, in the new, new product development game. And I think I started to see the needle move a little bit more with leaders being more fascinated about leadership agility and driving culture change to meet the demands of cross-functional teams. And it could just be a by-product that technology has gotten easier to make these and focus on these things now, but psychological safety, know, sustainability and agile with, people having real goals and integrating.

Brian (25:59)
You

Lance Dacy (26:23)
What you see now is a lot of these eco-conscious practices coming in to product development, like the environmental, social, government's commitments as well, are making their way in there. So I want to just reflect on 2024. I don't know what you think. I'd love to interact with the audience too, but those are kind of the main things that I saw. And that will lead us into a good discussion of how we see that helping us in 2025. So what do you think about those?

Brian (26:49)
I One of the things I think that kind of stood out to me from what you talked about was the concept of how that plays in leadership. And I think you're absolutely right. think that is, I am hearing more of that in classes, people talking about that when they ask questions. You know, we've talked about for years that the fact that there can be sort of I don't know a better word to say but a glass ceiling sometimes in the organization for agile and how it spreads across and that leaders are often You know overlooked as far as getting trained in this kind of stuff and understanding it and I do see a rise in leaders trying to understand a little bit more about how can we You know incorporate this or even better, you know, how do we support? and nurture and foster this culture in our organization. So I think you're absolutely right. I think that is sort of a hidden or kind of a cheat code, if you will, for organizations to try to be more successful with the stuff we talk about is if you can have, it's not a top-down approach, but if you don't have the top on board, then they can really start to become a hindrance or a roadblock to the teams actually being successful with it. And so I agree. think that, you know, I'm hopeful that that shift is occurring. I'm seeing signs of that, you know, it's kind of always a little bit of a back and forth, you know, is it moving in that direction? Then I start to hear people say, no, we're having trouble. And the anecdotal little stories you hear makes you kind of not sure what the prevalence is, you know?

Lance Dacy (27:54)
Yeah Lose hope. You lose hope. I think, you know, the big takeaway for me for this as we talk about 2025 is it's going to be increasingly difficult and it has been increasingly difficult for any one individual company, product, service, whatever you want to call it, to differentiate yourself from other people. I've been telling my kids this forever.

Brian (28:18)
Right, right, exactly.

Lance Dacy (28:38)
that I feel I've seen a big shift from when I was back in early 90s, know, writing spreadsheets for people, they thought it was just unbelievable the work that I was doing because not everybody could do that. Well, everybody can do that now. So what I mean about differentiating yourself is, you know, AI is one of those things that you have to start prioritizing AI literacy because we've just talked about how immature we might be in some cases with this. But if we can ensure that our team members understand how to work effectively with those AI powered tools and letting AI be an active team participant, then I think we're going to start seeing even a greater problem with being able to differentiate yourself. So the main point I want to make for 2025 that I believe is going to be a real big focus is a is a hyper personalization of customer products. So there's a lot of companies out there that are really good. You just mentioned it with the news, right? Hey, I'm building your content, I'm keeping you engaged, but am I really serving you? Am I giving you your needs? And maybe it's okay if news organizations do that if you have a way to filter it and customize it. But really what I'm talking about is, and I'll go back to what Gary Hamill says about this. He says, the markets are crowded. And when you have the rise of AI and tools like Trello, Monday, and things like that, those are project management tools, right? Used to, you could be a better product company just if you would manage your work better. You know, you were using Scrum or Agile, you had an edge on everybody else. You could deploy faster and that was your secret sauce, right? But now that most people can do that now, what's your next up level in game? And he thinks it's going to be this hyper personalized customer solution and engagement.

Brian (30:06)
Right.

Lance Dacy (30:23)
where we need to invest in more customer discovery processes. You know how hard that is in teaching tech teams to do that? All we focus on is building the features, but how about we get better at customer discovery and really understand the tools that provide deep insights into their behavior so we can recognize that? know, several companies that I think are on the forefront of that, for those of you who are like, yeah, I'm concerned about that too. Where can we get better at that? I mean, go look at Amazon.

Brian (30:30)
Yeah.

Lance Dacy (30:51)
You know, Amazon uses highly sophisticated algorithms to analyze customer behavior, which enables them to produce product recommendations and help you buy things you didn't even know. You remember when we would teach like Kano analysis in a product owner class and they had six categories of features and one of those feature categories was an exciter or delighter feature. You know, the key to being a good differentiator is providing product and features that people didn't even know they needed. That's why customers are not always right, you know, on what they need. They're thinking about their reactive sense. And so how can we get better at predicting their behavior even more than they can and use AI and machine learning that allow for real-time adjustments? Because that used to take forever. You you think about Benjamin Graham's book on investing in the 1940s and 50s, trying to predict what the stock market is going to do is nearly impossible now. But can you imagine how he differentiated himself by doing all these algorithms by hand?

Brian (31:20)
Yeah.

Lance Dacy (31:48)
And so what I mean by that is we need to use AI and these tools to help do more predictive customer experiences. So Amazon does a good job. Netflix employs a lot of data analytics to help understand viewing habits. Starbucks does this. Spotify does it. So I really feel like in 2025, if you want something to focus on and you're a software product development company practicing agile, build literacy of AI tools with your team. Make sure we're using them the right way. Track the right. data, but more importantly, let's discover what our customers are doing and behaving and use the AI to help us decipher that information a lot easier so that we as humans can make a decision on where we spend the great scarce capacity of our teams building great products for them. And so there's a lot of things that go into that, but I feel like that's going to be the focus in 2025. That's what's going to separate the people that succeed even individually. How are you going to differentiate yourself from a market pool of people out there? You need to start learning how to use these tools and differentiate yourself. That's the for 2025.

Brian (32:52)
Yeah. No, that's a great point. I'll tag on and say that I know there's this, people probably have heard of this, there's a social media kind of trend of if you use chat GPT or something like that a lot to go to it and say, tell me some insights about myself that I may not know, just based on all my interactions with you. And that was a trend for a while for people to ask that and then. they were shocked in some of the things that would come out from chat GPT. Well, what I found in taking a couple of courses and things about AI is, it's really good at taking a large amount of data and then pulling out things that you may not be aware of. I think that's going to be something, the more data driven we are, obviously the better because we have facts behind it. And as you said, it has to be the right, we have to collect the right kind of data. you can take a big...

Lance Dacy (33:19)
Yep. Yes.

Brian (33:43)
source of data and feed it into an AI like ChatGPT and say, give me five hidden insights from this data. Yeah.

Lance Dacy (33:50)
Yeah, stuff you thought about, right? I think insights, that's the way to put it. And I used to have a saying being a data analytics guy for 20 years. Most people and organizations are data rich, but information poor. And I would like to change that word nowadays to insights poor because

Brian (34:09)
Yeah.

Lance Dacy (34:09)
We may have all the data and tracking data, there's no harm in that, know, storage is cheap these days. So go ahead and track it all. You can report on it infinite number of ways. And that's the secret sauce. And I think you just hit it on the head that, just go ahead and start tracking stuff. Let AI, you can't ever read that amount of data as a human being and decipher it. Let the machine do that. But then you can test it. You can say, do I really believe that or not? Because you have a humanistic experience that AI doesn't have. So we should embrace that.

Brian (34:40)
Yeah, I agree. Well, I mean, I hope people are hopeful. I'm hopeful. I know when I start a new year, I generally am hopeful because that's just the way I try to start new years. But I'm hopeful for some of these changes. think the tools that we have are just making things, some things that might have been more mundane, a little easier for us to do. And maybe that allows us to focus. Well, like the data I brought about at the very beginning, you the fact that there's a rise in, you know, postings and companies needing jobs that require human judgment and decision-making. I think that's where we're headed is, you know, that rise in human judgment and decision-making skill. And that's something that's at least at the moment, you know, our computers can't do for us. And it really does require, just like you talked about, understanding our customers. I can't put an AI out there to try to interview all my customers and get deep. Well, but not and get the kind of deep insights I want, right? Not to find out what the real problems are. It wouldn't know how to question it enough and dig deeper into different ways to truly figure those out. So it requires huge human judgment and decision-making. And I think that's where we...

Lance Dacy (35:35)
you could. Right.

Brian (35:51)
now bring the value is in that area.

Lance Dacy (35:53)
Well, and people hate change, right? So let's just end with this. know, most people, customers, you change things on the product. You put a new car design. We usually don't like it. So you want to hang in there and not get too distracted by noise with that. mean, remember when the first iPhone came out, you know, older generations like this is too complicated. I don't want to use it. And there is something to say for that. But eventually that's what we use and we learn how to adapt to it. So stay hyper competitive in 2025. Foster continuous learning for your team. So stay updated on industry trends. It'll lead time to experiment and invest in your team's learning. Prioritize collaboration and innovation. None of us are smarter than all of us together. Break down the silos. Encourage the cross-functional collaboration. And experimentation is going to be key. Leaders and managers in particular. must foster an environment where it's safe to not do so well. I tried something, it didn't work, and I'm sorry about that, but I learned from it and I'm going to try it this way next time. That's not a huge thing right now. We need to foster that. The last one, focus on delivering value. Keep the customer at the center of everything. Use metrics to measure your real world impact, not just the outputs. And I think that's how we can summarize everything that we talked about. Those are the three things if we had to take away. continuous learning, collaboration and innovation, and focus on delivering value. Good luck in 2025, right, Brian?

Brian (37:19)
Yeah, absolutely. Absolutely. That's awesome. Well, I hope this has been beneficial to folks. And Lance, I appreciate you keeping our tradition and helping us look forward into the new year. obviously, a very happy new year to you and your family. And thank you for coming back and joining us.

Lance Dacy (37:35)
Yeah, likewise to you, Brian. Glad to do it. Hope to see you all soon. Thank you all.

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

18 december 2024 | 24 min

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

Overview

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

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

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

References and resources mentioned in the show:

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

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Auto-generated Transcript:

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

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

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

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

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

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

Brian Milner (12:38.326)
our 100th episode. Next up is someone that I found really fascinating. is Miss Heather McGowan. And she was the keynote speaker at the Scrum Gathering this year in New Orleans. And she was so gracious to come on the podcast and talk with us a little bit. She had some really great insights. Just listen to what she had to say here in thinking about sort of the place of work in general as a part of our lives today. But what I think what's really happening is we've outsized what work is in our lives. So community used to consist of social interactions, religious affiliations, clubs and groups we belong to, all of those kind of, if you think of them as circles, because everything's visual to me, all those circles shrank and work became bigger. So now part of this generational change, but more and more people are looking for work to provide their purpose. work to provide most of their relationships, work to fill these. It's a little bit in terms of how we're interacting with each other that's causing illness, but it's also an outsize expectation we have around work. So now it becomes table stakes for a lot of organizations for work to be my self-expression, work to be my sense of purpose, work to be where I think about my values. And it wasn't like that a few decades ago. I heard from a couple of people after this episode, just friends of mine talking about it. I want to make sure I'm clear about something here that Heather was saying, she's not saying that we should find our values from those places. She's just saying that's kind of how society has shifted a little bit. So you can debate whether it's good or bad, whether the other circles that she mentioned had shrunk or grown or anything like that. But really that's kind of the reality we're left with is that there's a lot of people who find their belongingness from work today, as I said, whether that's a good or bad thing, you can debate. but that's certainly a reality I think we have to live with. And this was a really interesting discussion. So I highly encourage you to check that out if you want to. That was episode number 111 with Heather McGowan. Next up was someone I found really interesting as well. This was Mr. Clinton Keith. Clinton is a veteran of the gaming industry. And I know there's always some interest in that in our listeners and in the Agile community about how you really can apply some of these Agile principles and things.

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

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

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

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

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

11 december 2024 | 31 min

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

Overview

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

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

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

References and resources mentioned in the show:

Mark Kilby
From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver by Johanna Rothman & Mark Kilby
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

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

Auto-generated Transcript:

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

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

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

Mark Kilby (00:31)
Yes it is.

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

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

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

Mark Kilby (02:51)
yeah.

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

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

Brian (05:55)
Yeah. Right.

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

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

Mark Kilby (08:38)
Mm-hmm.

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

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

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

Mark Kilby (10:48)
Yeah. Yeah.

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

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

Brian (12:18)
Okay, sorry.

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

Brian (13:47)
Hahaha.

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

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

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

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

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

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

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

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

Mark Kilby (18:34)
Mm-hmm.

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

Mark Kilby (19:45)
yeah.

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

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

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

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

Brian (22:51)
Okay.

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

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

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

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

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

Brian (26:29)
Yeah.

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

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

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

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

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

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

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

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

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

Brian (29:25)
Absolutely.

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

4 december 2024 | 35 min

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

Overview

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

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

References and resources mentioned in the show:

Gary K. Evans
The Effective Scrum Master: Advancing Your Craft by Gary K Evans
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Certified ScrumMaster® Training and Scrum Certification
Advanced Certified ScrumMaster®
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

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

Auto-generated Transcript:

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

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

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

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

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

Gary (02:18)
Efficient.

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

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

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

Gary (03:59)
Exactly.

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

Gary (04:09)
It does indeed.

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

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

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

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

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

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

Brian (08:06)
Right, exactly.

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

Brian (08:58)
Hahaha.

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

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

Gary (13:43)
Right. Yes.

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

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

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

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

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

Gary (17:55)
Yes. Yes.

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

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

Brian (20:41)
you

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

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

Gary (21:31)
Exactly.

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

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

Brian (22:33)
Ha ha ha.

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

Brian (26:06)
Right.

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

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

Gary (27:26)
It is.

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

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

Brian (27:48)
Hmm.

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

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

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

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

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

#125: Embracing Gratitude in Challenging Times with Brian Milner

20 november 2024 | 9 min

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

Overview

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

References and resources mentioned in the show:

Subscribe to the Agile Mentors Podcast
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Auto-generated Transcript:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13 november 2024 | 29 min

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

Overview

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

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

References and resources mentioned in the show:

David Pereira
Untrapping Product Teams by David Pereira
Certified Scrum Product Owner® Training
Advanced Certified Scrum Product Owner®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

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

Auto-generated Transcript:

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

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

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

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

Brian (00:43)
Ha ha ha ha.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

David Pereira (20:12)
Exactly.

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

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

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

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

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

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

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

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

#123: Unlocking Team Intelligence with Linda Rising

6 november 2024 | 45 min

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

Overview

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

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

References and resources mentioned in the show:

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

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

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

Auto-generated Transcript:

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

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

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

Linda Rising (00:33)
Yeah! wow okay

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

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

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

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

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

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

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

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

Brian (04:47)
Yeah.

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

Brian (05:17)
That's amazing.

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

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

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

Brian (06:43)
Yeah

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

Brian (07:53)
Yeah.

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

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

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

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

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

Brian (10:26)
Yeah.

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

Brian (11:24)
Yeah. Okay.

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

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

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

Brian (12:34)
Really?

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

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

Linda Rising (12:58)
Ha!

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

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

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

Linda Rising (16:02)
Yeah.

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

Linda Rising (16:18)
Yeah.

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

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

Brian (17:54)
Ha Linda

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

Brian (19:37)
Huh.

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

Brian (19:39)
Yeah.

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

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

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

Brian (20:43)
Yeah.

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

Brian (21:38)
Hahaha

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

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

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

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

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

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

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

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

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

Brian (25:44)
Yeah. That,

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

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

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

Brian (27:26)
Yeah, right.

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

Brian (28:22)
you

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

Brian (28:54)
Yeah.

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

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

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

Brian (29:48)
Yeah. Right.

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

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

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

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

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

Brian (34:43)
Yeah. Ha

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

Brian (34:58)
Hahaha Yeah.

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

Brian (35:48)
Yeah.

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

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

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

Brian (37:50)
Ha ha.

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

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

Linda Rising (38:09)
Yeah

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

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

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

Linda Rising (40:11)
Yeah!

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

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

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

#122: Empowering Diversity with Nosa Oyegun & Louria Lindauer

30 oktober 2024 | 37 min

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

Overview

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

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

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

References and resources mentioned in the show:

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

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

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

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

Auto-generated Transcript:

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

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

Louria Lindauer (00:30)
Yes.

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

Nosa Oyegun (00:37)
You nailed it.

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

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

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

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

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

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

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

Brian (04:47)
Hahaha.

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

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

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

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

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

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

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

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

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

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

Nosa Oyegun (09:32)
Mm-hmm.

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

Nosa Oyegun (10:07)
Correct.

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

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

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

Nosa Oyegun (11:34)
Absolutely.

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

Nosa Oyegun (12:21)
way. Yep.

Brian (12:23)
Right. Yeah.

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

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

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

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

Brian (15:16)
haha

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

Louria Lindauer (15:40)
Okay.

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

Louria Lindauer (16:41)
Yes. Okay.

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

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

Nosa Oyegun (17:52)
Yes.

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

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

Brian (18:58)
Hahaha. Okay.

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

Brian (19:39)
That's awesome.

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

Brian (20:09)
You

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

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

Louria Lindauer (22:05)
Yeah

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

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

Nosa Oyegun (23:44)
You

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

Nosa Oyegun (24:15)
AMAZING!

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

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

Nosa Oyegun (25:01)
Yeah, absolutely.

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

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

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

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

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

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

Brian (26:00)
Hahaha!

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

Brian (26:24)
Right.

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

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

Nosa Oyegun (29:17)
I job police.

Brian (29:19)
Yeah.

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

Brian (30:10)
You

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

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

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

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

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

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

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

Nosa Oyegun (32:00)
Absolutely.

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

Nosa Oyegun (33:14)
Yes.

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

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

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

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

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

Louria Lindauer (34:58)
Thank you.

Brian (35:10)
Thank you so much.

Louria Lindauer (35:10)
Thank you.

#121: Busting the Biggest Myths About Agile Tools with Steve Spearman

23 oktober 2024 | 38 min

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

Overview

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

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

References and resources mentioned in the show:

Steve Spearman
#43: Cultivating Agile Team Culture in a Virtual World with Richard Cheng
#29: Influencing Up with Scott Dunn
#71: The World of DevOps with Carlos Nunez
Jira
Miro
Mural
Trello
SAFe
LeSS
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

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

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have a very good friend of mine, a mentor of mine, Mr. Steve Spearman is with me. Welcome to the podcast, Steve.

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

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

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

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

Steve (02:24)
Yeah.

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

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

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

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

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

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

Brian (04:57)
Yep.

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

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

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

Brian (06:55)
Yeah.

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

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

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

Brian (08:23)
wow.

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

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

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

Brian (08:57)
Haha.

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

Brian (09:43)
Yeah.

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

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

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

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

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

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

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

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

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

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

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

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

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

Brian (21:17)
Right.

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

Brian (21:48)
Right.

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

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

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

Brian (23:18)
Neither have I. You

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

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

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

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

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

Brian (29:06)
Ha ha ha.

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

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

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

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

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

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

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

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

Steve (34:43)
Absolutely.

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

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

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

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

#120: Agile in Gaming with Clinton Keith

16 oktober 2024 | 32 min

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

Overview

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

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

References and resources mentioned in the show:

Clinton Keith
Agile Game Development: Build, Play, Repeat by Clinton Keith
Mike Cohn’s Better User Stories Course
Accurate Agile Planning Course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

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

Auto-generated Transcript:

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

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

Brian (00:23)
Welcome in, Clinton.

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

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

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

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

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

Brian (04:11)
Yeah. Yeah.

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

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

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

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

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

Brian (10:25)
Yeah.

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

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

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

Brian (14:47)
Mm. Right.

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

Brian (15:53)
Yeah.

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

Brian (16:11)
Yeah.

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

Brian (16:40)
Yeah.

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

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

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

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

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

Brian (22:06)
Yeah.

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

Brian (22:45)
Ha

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

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

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

Brian (26:10)
Yeah.

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

Brian (26:46)
You

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

Brian (26:55)
Yeah.

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

Brian (27:49)
Right.

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

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

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

Brian (29:22)
Yeah.

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

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

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

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

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

#119: Conferences, Connections, and Community with Chris Murman

9 oktober 2024 | 34 min

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

Overview

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

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

References and resources mentioned in the show:

Agile 2025
Chris Murman
Connect with Chris on LinkedIn
Agile Alliance Speaker Submission Tips Webinar
#105: Scrum Conferences & Neurodiversity with Brian Milner
Special Episode Scrum Gathering Denver 2022
Mountain Goat Software’s Accurate Agile Planning Course
Subscribe to the Agile Mentors Podcast
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

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

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today, a very special friend is here with us, Mr. Chris Murman. Welcome in, Chris.

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

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

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

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

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

Brian (04:18)
Yeah. Hahaha.

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

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

Chris (06:22)
Thank

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

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

Brian (07:27)
You Yeah, yeah.

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

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

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

Brian (09:28)
Yeah.

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

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

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

Brian (13:11)
Yeah, yeah.

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

Brian (13:35)
Yeah. You

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

Brian (14:09)
Yeah.

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

Brian (14:45)
Yeah.

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

Brian (15:21)
Yeah. Hahaha.

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

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

Chris (16:41)
you

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

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

Brian (17:20)
Yeah. Yeah.

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

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

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

Brian (18:47)
Hahaha.

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

Brian (19:23)
Right.

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

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

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

Brian (21:22)
Yeah.

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

Brian (21:41)
Hahaha

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

Brian (24:00)
Hahaha Right. Right.

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

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

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

Brian (27:16)
Yeah.

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

Brian (27:46)
Yeah.

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

Brian (28:26)
Ha

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

Brian (29:16)
Yeah.

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

Brian (30:04)
Yeah.

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

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

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

Brian (32:02)
Yeah Yeah.

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

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

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

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

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

#118: The Secrets to Agile Success with Mike Cohn

2 oktober 2024 | 34 min

In this episode of the Agile Mentors Podcast, Brian Milner and Mike Cohn reveal the keys to achieving lasting success with Agile methodologies. From embracing experimentation and fostering a culture of continuous improvement to improving communication with consistent vocabulary, they offer practical, relatable insights for Agile practitioners at all levels.

Overview

Brian and Mike discuss the essential ingredients to Agile success, touching on the power of experimentation, the need for flexible coaching, and building a culture of continuous improvement.

The conversation dives deep into the importance of effective communication within teams, especially through user stories and consistent vocabulary, ensuring that Agile teams stay aligned. With personal anecdotes and actionable tips, this episode provides a roadmap for anyone looking to excel with Agile.

References and resources mentioned in the show:

Mike Cohn
Essential Scrum by Ken Rubin
Agile & Scrum Glossary
#85: Effectively Managing Dependencies with Ken Rubin
Dependencies Are Killing Your Agile Flow at Scale by Ken Rubin
Creating a Software Engineering Culture by Karl Wiegers
Private Scrum & Agile Training
Agile For Leaders
Working on a Scrum Team Classes
Story Writing Workshop
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today we have our favorite back with us, Mike Cohn is here. Welcome back, Mike.

Mike (00:12)
Thanks, Brian. It's good to be here. Hi, everybody.

Brian (00:15)
So happy when Mike can make time and be with us here on the show. Obviously Mike has a lot of wisdom and experience to share with us. So we wanted to bring him in because we were talking about doing an episode titled The Secret Staggile Success. I remember back in the day in the 80s, was a movie called The Secret to My Success. There was a really obscure movie. was Michael J. Fox. Yes, it was Michael J. Fox.

Mike (00:37)
Michael J. Fox? Yeah, so it's not that obscure.

Brian (00:41)
But I still hear that theme song in my head. when we talked about this title, that's what I thought about. But we wanted to talk about maybe some hidden things or things that aren't as immediately apparent to people that are crucial to being successful when you go agile or if your teams are working in an agile way. So let's just open things up, Mike. What's one of the things you had thought about when we talked about this?

Mike (01:10)
think the number one secret to Agile success for me is being willing to experiment, to try new things. And if you think back, Agile itself, Scrum itself, began as experiments. They were probably teams going, know, this waterfall stuff we've been doing doesn't work. Let's try something different. Somebody else went, yeah, let's do something unusual, and let's try iterating or something. And so Agile itself began as experiments. And yet I see teams kind of get stuck in the mud and not willing to experiment. And I think that's to their detriment. We want to try things out. And silly, trivial examples, try different sprint links. Don't do a one -week sprint link and go, Agile doesn't work. It's not for us. No.

Brian (01:52)
Yeah.

Mike (01:59)
Maybe one week sprints are for you. Try a three week iteration or I try something different. And I think the the idea of experimentation is how we come up with new ideas. It's how we learn. It's how we get better. And so if you're going to succeed, you better have that that focus on experimentation.

Brian (02:19)
Yeah, there's a surprising number of Scrum Masters I've encountered that I'll hear stories about how they run the same exact retrospective, every single retrospective. And I just think, what are you doing? How can you be trying to communicate this and teach the team that this whole thing is based on doing little small experiments and seeing what the result is, when you're not willing to try something new in just how you run a retrospective? So yeah, I completely agree. I think the key there for me is demonstrate it. If you want them to pick up on that, then do it yourself.

Mike (02:56)
worked with a company years ago that fired their scrum master for basically for being too rigid. He had read something in Ken Schwaber's second book, and I don't want to pick on Ken's book, but he has this wacky sentence in there, and there are wacky sentences in my books, right? So somebody can go find those, and I mean, I get it. But anyway, Ken wrote that the daily scrum must be conducted left to right, starting with the person on the left of the scrum master. And it's like, what? Why is this mandatory? It must be left to right. Anyway, this guy read that in the book and insisted that the Daily Scrum be left to right, starting with the person on left of the Scrum Master. And his team knew that was insane, right? It's just nuts. And so they would mess with him. They would do things like he would call on the person to his left and the person on the right would start talking. he would point to the person on the left to start and they were standing in a semi -circle. They would move, right? So the person on the left was no longer on the left. And they were just messing with him over this. And he would just get mad and insisted it had to be left right because the book said so. And I don't know what it was with him, but he was just stuck on this. Ultimately ended up getting fired for it. Yeah, I heard this story because I ran into him at a conference and I saw him there and he

Brian (04:14)
Wow.

Mike (04:20)
looked a little down. It's like, you know, said his name and how are you doing? And he told me this story. And he said, you know, he'd gotten better since then. But, you know, don't get stuck on things. It's just not the it's just not a very agile mindset.

Brian (04:34)
Yeah. I mean, if you can't, no matter what it is too, I think that if you can't point to what you hope to achieve from doing it that way, or what's the purpose behind us doing it that way, that's questionable part of your process to just say, I can't point to any reason why this, any good that this thing does going left to right person by person, but. Ken said we should do it. I guess, no, I mean, if there's no reason, if you don't see the benefit in it, why would we do that?

Mike (05:07)
Knowing Ken, I think he was just trying to make it easier for people. Here's one less thing you got to think about. Start on your left and go around the room. But the way it's written and the way this guy interpreted it was like, shalt go left to right. It's like you've got to be willing to, I think, out the way that a known proven way start out that way. So yeah, go ahead and start left to right. It says so. I don't know any different. Might as well go this way.

Brian (05:17)
You

Mike (05:35)
But then experiment, learn, figure it out for yourselves. I I can't think of a successful company or team that I've worked with that ever quoted this Scrum Guide at me, right? You know, they may start out exactly the way a Scrum Guide says, or my favorite is Ken Rubin's Essential Scrum Book, start out in a known proven way, but then experiment, make agile your own. Don't throw away the important stuff, and that's why you have to start in a known proven way, but as you get experience, experiment, throw things out.

Brian (05:46)
Yeah. I love that. Yeah, I think that's a really good one. So a good one to start us off. Thanks for that.

Mike (06:12)
Yeah, that's, that's what I'm buying. Brian, can I ask you for one of your secrets to agile success?

Brian (06:17)
Sure. Well, and this one I know it's going to be a little, know, boy, it'd be nice if I could do that, but I, you know, we can't do that. And I understand that this is not going to be for everyone, but one of the things that I think is important is to have some kind of a coaching presence. Now, just to be clear about this, this doesn't mean that you have to, you know, fight tooth and nail to hire some outside consultant or anything like that. I understand budgets are tight and there may not be an ability to do that. But I think if I, you know, if you're a scrum master, then I think that having the ability to continue your learning journey and grow is really important and, and having someone you can go and bounce things off of. So if you can't have someone, if you, if you can't have someone on staff or someone there that's an outside consultant that can help you and coach you through the early stages, I think that could be really, really helpful. And to me, it's an accelerator. I think that kind of thing is something that can really, yes, we will go through training. We understand kind of the basics, but then the coach is sort of like pouring gasoline on that fire to say, now we're going to go from zero to 60 and I'm going to help you get there because I know the pitfalls to look out for and I know how to get you there. But if you don't have that ability, I think it's important to maintain some of those mentorship relationships that you can find through different community groups.

Mike (07:18)
Mm

Brian (07:44)
Maybe you'd find some kind of a weekly meetup or a monthly meetup or something that you could go to. Even if it's just a meetup of peers, right? There's not someone that you would say, that person's been in this for 10 years. No, we're all kind of in the same place. But if we can meet up in their network of my peers and let's talk about what's going on at your place, I'll talk about what's going on at my place, and we can share with each other and... help each other find the best solutions. Even that level, I think of coaching is really imperative and can really make an impact on how successful your implementation is.

Mike (08:25)
I think you're right. I think back to the earliest days of Agile, and at least of Agile training. And I'm thinking back to when I was teaching public courses on Agile in 2003, 2004, 2000, actually, the early days. One of the big benefits of the class, beyond whatever learning somebody had in the class, one of the big benefits was just feeling like you weren't alone in the world. And I remember people describing a problem, whatever it was. Like, my bosses aren't on board with this. and somebody would describe a problem and then somebody else in the class would just merely sympathize. Right. Yeah, mine too. I'm struggling with that too. That was like one level of support that was awesome. It was even better if there was somebody in the class who said something like, yeah, we had that problem and here's what we did. Right. But these were not people who were any smarter than each other. It wasn't like the person who'd worked through the problem was that much smarter. They probably just had a six month head start and Having that ability to go into a class and hear that you weren't alone and that your problems were not that unique was extremely valuable for people even way back then when there were not a lot of people doing this.

Brian (09:32)
Yeah, and I've said this before, and I probably said this to you, Mike, but one of the things I think people love the most when they come to the advanced classes that we offer is really being able to get sympathy from others, the camaraderie of talking to somebody else and saying, yeah, I've gone through that. It's not, I tell people at beginning of the class, it's

Mike (09:48)
Mm -hmm.

Brian (09:59)
likely not going to be a teaching point that sticks with you as much as it's going to be hearing from your peers and actually getting to learn from each other that's going to stick with you as much through those classes. to me, I think that's one of the reasons why those classes are so much fun is because I learned from the people who come to them.

Mike (10:20)
absolutely, absolutely. Some of what you're describing is why we set up our Agile mentors community years ago. Agile mentors community, not just the podcast, is a community we have where people who take one of our courses get a free membership. I hired a consultant to kind of give me advice on some business stuff years ago. he used the try. And I asked him, hey, we're thinking about starting this community. What do you think? I don't remember if he said do it or don't, but I do remember a term he used. He called it a continuity program. And it was a way to continue a relationship with people who taken our courses. And like I said, we give it away free to people who take classes because we know that a class isn't enough to get people successful, but it's a start. It gets people over some hurdles. It gives them the foundations of the education they need. But they're going to have ongoing questions. And our community has been wonderful because we have so many good people in there who helped each other out. And again, they're often somebody who's just six months ahead in their journey, helping somebody who's right behind them or, you know, there's somebody just in a similar industry and can sympathize or give advice on how they worked through a problem.

Brian (11:29)
Yeah, that's awesome. So we talked about experimentation, we talked about coaching. Mike, what was another one that was on your list?

Mike (11:36)
One for me is to focus more on practices than frameworks. The frameworks get all the attention. Should we do Scrum or should we do Kanban? Should we do extreme programming, going back a little bit more when that was extremely popular, still around, but not as popular? Should we do safe? And so people focus on their frameworks because they're these big, visible things. And I think what we want to do more is pick the right practices for us. Now, that's not to diminish frameworks. I think the frameworks are good. They're a good starting point. But I've said for years, if I have a team and they start with Scrum or if they start with Kanban, if they're doing the good old inspect and adapt thing, they're going to end up in the same place. They're going to invent the right Agile for them. And very likely, that's going to be some elements of Scrum, some elements of Kanban, perhaps some elements of Safe if it's big. I don't think it matters all that much where you start. I think it's worthy of some consideration. But if you're inspecting and adapting, you're going to end up in the same place. And that means that Agile needs to be thought of more as a set of practices rather than we do Scrum or we do Kanban.

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

Mike (13:14)
Mm -hmm.

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

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

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

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

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

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

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

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

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

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

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

Mike (17:59)
for two more months.

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

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

Brian (18:54)
you You

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

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

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

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

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

Brian (22:17)
Ha ha ha.

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

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

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

Brian (23:39)
Right. Right.

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

Brian (24:10)
Wow.

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

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

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

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

Mike (28:02)
Haha.

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

Mike (28:24)
Yeah, itself,

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

Mike (29:01)
Mm -hmm.

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

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

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

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

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

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

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

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

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

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

#117: How AI and Automation Are Redefining Success for Developers with Lance Dacy

25 september 2024 | 36 min

In this episode, Brian Milner and Lance Dacy dive into the evolving world of software development, exploring how AI and automation are reshaping the landscape. They discuss the essential skills developers need in this new era, from embracing AI as a tool to mastering emotional intelligence and continuous learning.

Overview

Brian and Lance discuss the transformative impact AI and automation are having on the software industry. They explore the importance of adaptability, continuous learning, and cross-functional expertise, emphasizing how developers can thrive by embracing AI as a tool rather than a threat.

The conversation highlights the growing need for soft skills like emotional intelligence, curiosity, and collaborative leadership, and encourages developers to be open to new technologies and ways of working to stay competitive in the ever-evolving tech landscape.

References and resources mentioned in the show:

Lance Dacy
Big Agile
“Be curious, not judgemental” – Walt Whitman
#54: Unlocking Agile’s Power in the World of Data Science with Lance Dacy
#63: The Interplay Between Data Science and Agile with Lance Dacy
#82: The Intersection of AI and Agile with Emilia Breton
#99: AI & Agile Learning with Hunter Hillegas
Accurate Agile Planning
Mountain Goat Software Certified Scrum and Agile Training Schedule
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. How's your week going? I hope everyone's week is going well. Yeah, I'm switching things up. I'm not saying things exactly as I did the past 100 episodes. But welcome in. I hope you guys are having a great week. We are back with you here at the Agile Mentors Podcast. And I have one of our favorites back with us. I have one of our repeat visitors, Lance Dacys with us. Welcome back, Lance.

Lance Dacy (00:28)
Thank you, Brian. Great to be here.

Brian (00:30)
Always excited to have Lance with us because we always have such great conversations. And I wanted to have Lance back because we were talking about something recently that I think might be a good topic for us, might be on a lot of people's minds. And that is really kind of getting into this, what we've loosely termed the new age of development. With the new tools and new kind of the way that AI has worked its way into things and automation. How is this going to change and affect our teams? How is it going to change and affect how we develop? How is it going to change and affect the software industry? Lance, I know you had some thoughts on this. I'm going to just open the floor for you and let you take it from there.

Lance Dacy (01:15)
That's great, Brian. My heart is always with organizations and developers, just trying to help people get better. You and I shared that vision that I remember a long time ago, even at DFW Scrum, one of our vision statements was just trying to help you to do better today than you did yesterday. It's like, what are the things that we can help teams and organizations? And something's real heavy on my mind lately as I work with these teams. You know, we have these notions out there like Agile is dead and, you know, where is Agile headed? And that's not really what this is about here because I think what's happening, as a lot of people have already said, it's just become more of the mainstream. Let's quit labeling it. You know, like Mike always tells us, object -oriented programming won. We don't really call it that anymore. Objects won and off we went. So I'm not really focused so much on the agile type scenario, but we do work in Scrum and agile teams and I see plenty of organizations that need help with that. And I still encounter to this day, developers who are lagging behind on their skills, right? We get so focused in the day -to -day feature development of our roadmap and things like that. that I just fear that developers aren't setting enough time aside or not challenging the organization to help them do that, to learn new skills. And I started compiling this list of like, if I go in and start teaching teams how to do scrum and how to manage your backlog and how to do that, it doesn't matter if they don't have the skills because everything we talk about in Agile is based on reducing waste and the more of these skills gaps that we have. then I find the more handoffs and the more bottlenecks and you know that's one of the eight waste, you know, of lean. And so that's what I wanted to talk about today. And I love the topic like the new age of development. I'm not going to sit here in a spouse to claim to say, here's all the skills you're going to need. But as you and I work, I think we can find plenty of examples to help guide some of these people, even Scrum Masters that are coaching teams or agile coaches, you know, just kind of put some thoughts in their mind about. know, these skills and I have about a short list of five that I've seen growing and then thought we'd go from there.

Brian (03:30)
That sounds great. I want to dive into one that I know is on your list and it's one we kind of talked about here beforehand, but that is kind of how AI is affecting teams and the skills needed to be relevant with that. Now, I want to preface this by just saying my own personal opinion here on this. I'm not a doom and gloom person when it comes to AI. don't really see it much different than...

Lance Dacy (03:34)
Thank So, I'll see you.

Brian (03:59)
how automation really changed things like testing. When automation entered the testing realm, we didn't lose all our testers. We still needed testing. It just was a tool that enhanced the way we did testing. And I think AI is sort of going to be that for how we program. don't think we're at a place where, or I don't know, things could change quickly, obviously, but I don't feel like we're within 10 years. of it completely replacing developers. I think we're still going to need to have expertise. We're still going to need to have that guidance. Maybe 10 years is too big of a window. don't know. Maybe five years? I don't know.

Lance Dacy (04:42)
These days you don't know. I just thought yesterday something changed. No, I'm just kidding.

Brian (04:46)
Right, right. But I don't see that happening in the near term window for sure, just because it does a lot of things well, but it doesn't create. It can do things based on what's already been done, but it can't really then go through and create something entirely new itself. So I think you still need human beings for that component of it.

Lance Dacy (05:04)
Done.

Brian (05:15)
And I think for developers, learning how to integrate that kind of tool set to help you reduce your errors, define bugs, AI is great at looking over a huge chunk of your code and finding potential issues that you can go back and look at. That can save you enormous amounts of time. So I think there's skill involved there for for the developers segment that I think is embracing it rather than kind of holding it at arm's length and saying, that's the enemy, that's gonna somehow replace me. No, think of it like automation. It's not to replace you, it's just another tool to enhance and give you time to do other things.

Lance Dacy (06:02)
I think, you know, you mentioned, don't think you and I either would be convicted of being doom and gloom people. think we're pretty well optimistic, right? It is scary. mean, obviously these things that are changing, you're like, my gosh, I have to, the main word I keep thinking about is adaptability. You know, I've got four kids. I keep telling them the best skill they can do is learn how to learn, you know, and I think you just used a perfect example in development about test automation.

Brian (06:10)
Yeah.

Lance Dacy (06:30)
We weren't scared of that. The testers might have been because they're like, well, what do I do now? Well, you got to go learn a new skill, right? But it freed us up. Can you imagine still doing, there's companies out there that still do manual testing, and they have to wait until all the changes are in until they do testing, and you will never compete. in a good hyper competitive marketplace doing things like this. So the test automation freed us up and actually what I used to tell my teams is it gives you more confidence, right? So developers can make more radical changes in the code without feeling like, know, you. You blow on something and then it breaks. know, y 'all ever seen code like that before? And it's like, I think it builds their confidence that test automation helped them to be more efficient and more productive because they can experiment more. think that's the goal is I write this code and I can quickly test to see what happens. And I start building my confidence and I can make more radical changes to the system instead of tiptoeing or walking on eggshells. So I'll date myself a little bit. Your example is probably much better than mine. But can you believe I don't use a Maps Go anymore? Y 'all remember the days of trying to navigate a street address with a Maps Go or a real map? I mean, I'm kind of at that bridge where we started having online maps, but you still had to know where you're going and print it out before you left and then take it in your car. You're still trying to read it as you're driving. I mean, who does that anymore, right? So I get in my car these days and now I don't even have to plug CarPlay or Android or whatever you have. It's wireless. You just get in and I'm now a co -pilot in my car. And we kind of laughed about that. think the last episode we're on and I can just drive around in it. I just do what it tells me to do. But it'll never replace my experience, my opinions, and my knowledge of the world. So I can.

Brian (08:05)
Right.

Lance Dacy (08:20)
you know, sidestep any suggestions it has, but it helps me be more productive. It knows where traffic is. I don't know that. You know, I know the city I live in and I know five different ways to get somewhere, but I don't know if there's a road closed or anything like that. So I feel like with developers, we need to start embracing some of these tools to help you be more confident, help you. mean, goal of agility, right, is to go faster, go faster than our competitors. So I feel like that's the premise of what we're trying to accomplish here is optimism with these tools. AI is just one of them. But we all have that in our day -to -day lives. test automation is good. I've got the driving. What's another one you got, Brian, that's made you more efficient with AI?

Brian (09:01)
Well, just before we move on, one thing I wanted to kind of throw out there because I heard this example recently for AI and I thought this was a kind of a really good practical example. If you've been a developer for any amount of time or if you've ever developed in the past, you've unlikely encountered a situation where you've had to go into somebody else's code. And when you do that and you have to enter, especially if it's like a rat's nest of code that you can't really make it out, it's been there for a long time. and it's fragile, no one wants to delve into it. Well, I read this article from a guy who basically had used this legacy code base and entered into AI and had AI go through and comment and help them learn what the different sections of the code did and how it was structured and organized. And it just saved them an enormous amount of time in trying to understand what had come before. Because you know, Like I said, we've all entered those places where we've had to come in behind someone else that is no longer there and try to figure out where we get started, even if it's not code, right? Even if it's something else, but we've all had to come behind someone else. And if we can take a folder full of documents, feed it into AI and then say, help me understand blah, blah, blah. Yeah, summarize this. Help me understand where would I go for this? That's just an enormous time saver. And that's what I think is really great about it is

Lance Dacy (10:17)
you summarize this.

Brian (10:27)
So as far as skills are concerned, think prompt engineering is a good one. think coding, interacting with code with an AI agent so that you can create your own AI agents so that you can programmatically call that information. If you're a coder and you can do that, man, to me it's like it just exploded. And now the possibilities are endless of what you can do with that kind of stuff.

Lance Dacy (10:57)
just dated myself with Cliff Notes too, right? Just think of it like on the fly Cliff Notes. And I heard Alastair Coburn, one of the thought leaders in our industry, been around for a very long time trying to help humans and machines interact better. And he kind of summarized really well about what it's doing in his life is saving him keystrokes.

Brian (11:03)
Right!

Lance Dacy (11:19)
And that's kind of like what I wanted to focus on with developers. Can you imagine if you got to spend more time being creative and less time writing on a keyboard to the computer, like you just talk to it. I'm getting to the point now, I used to text all the time and I used to laugh at people that hold the phone up to their voice and they talk into it. I fat finger things and misspelled things so much, all I do is just talk into it anymore. So I feel like coding, that's what it's, you're not even going to tell it the code to write. You're going to have to be... more problem solving design engineer, you less code writing, more problem solving and understanding the domain in which you're trying to automate and algorithm design and ethical considerations that go along with that. But the computer won't be able to do that, but it'll save you keystrokes. It'll save you time. And I think Alistair summed that up pretty good that way.

Brian (12:07)
Yeah, it's architecture, right? We have to be better architects at what it is we're trying to develop. that way we can give the rough architecture and let AI do the dirty work of the small details to fill in.

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

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

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

Brian (15:47)
Yeah.

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

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

Lance Dacy (18:51)
Yeah.

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

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

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

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

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

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

Brian (22:17)
Yeah.

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

Brian (23:38)
What?

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

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

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

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

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

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

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

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

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

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

Lance Dacy (27:21)
Yep.

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

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

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

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

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

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

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

Lance Dacy (35:32)
Yeah.

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

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

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

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

#116: Turning Weird User Actions into Big Wins with Gojko Adzic

18 september 2024 | 33 min

What do lizards have to do with product growth? In this episode, Gojko Adzic reveals how unusual user behaviors can unlock massive opportunities for product innovation. Discover the four steps to mastering "Lizard Optimization" and learn how you can turn strange user actions into game-changing insights.

Overview

In this episode of the Agile Mentors Podcast, host Brian Milner chats with Gojko Adzic about his new book, Lizard Optimization. Gojko explains the concept of finding product growth signals in strange user behaviors, sharing examples where unexpected user actions led to product breakthroughs.

He outlines a four-step process for optimizing products by learning, zeroing in, removing obstacles, and double-checking. Gojko also discusses helpful tools like session recorders and observability tools that can enhance product development by uncovering and addressing unique user behaviors.

References and resources mentioned in the show:

Gojko Adzic
50% OFF Lizard Optimization by Gojko Adzic
Mismatch: How Inclusion Shapes Design by Kat Holmes
Trustworthy Online Experiments by Ron Kohavi
Advanced Certified Scrum Product Owner®
Subscribe to the Agile Mentors Podcast
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Gojko Adzic is an award-winning software consultant and author, specializing in agile and lean quality improvement, with expertise in impact mapping, agile testing, and behavior-driven development. A frequent speaker at global software conferences, Gojko is also a co-creator of MindMup and Narakeet, and has helped companies worldwide enhance their software delivery, from large financial institutions to innovative startups.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today, very special guest we have with us. have Mr. Goiko Atshich with us. I hope I said that correctly. Did I say it correctly? Close enough. Okay. Well, welcome in, Goiko. Glad to have you here.

Gojko (00:15)
Close enough, close enough.

Brian (00:21)
Very, very, very happy to have Goiko with us. If you're not familiar with Goiko's name, you probably are familiar with some of his work. One of the things I was telling him that we teach in our advanced product owner class every time is impact mapping, which is a tool that Goiko has written about and kind of come up with on his own as well.

Gojko (00:21)
Thank you very much for inviting me.

Brian (00:47)
But today we're having him on because he has a new book coming out called Lizard Optimization, Unlock Product Growth by Engaging Long Tail Users. And I really wanted to talk to him about that and help him explain, have him explain to us a little bit about this idea, this new concept that his new book is about. So, Goiko, let's talk about it. Lizard Optimization, in a nutshell, what do you mean by that? What is it?

Gojko (01:14)
We're going to jump into that, but I just need to correct one of the things you said. I think it's very, very important. You said I came up with impact mapping and I didn't. I just wrote a popular book about that. And it's very important to credit people who actually came up with that. It's kind of the in -use design agency in Sweden. And I think, you know, they should get the credit for it. I literally just wrote a popular book.

Brian (01:19)
Okay. Gotcha. Gotcha, gotcha. Apologies for that incorrect. Thank you for making that correction. So lizard optimization.

Gojko (01:44)
So, lizard optimization. Good. So, lizard optimization is an idea to find signals for product ideas and product development ideas in strange user behaviors. When you meet somebody who does something you completely do not understand, why on earth somebody would do something like that?

Brian (02:03)
Okay.

Gojko (02:11)
and it looks like it's not done by humans, it looks like it's done by somebody who follows their own lizard logic, using stuff like that as signals to improve our products. Not just for lizards, but for everybody. So the idea came from a very explosive growth phase for one of the products I'm working on, where it... had lots of people doing crazy things I could never figure out why they were doing it. For example, one of the things the tool does is it helps people create videos from PowerPoints. You put some kind of your voiceover in the speaker notes, the tool creates a video by using text to speech engines to create voiceover from the speaker notes, aligns everything and it's all kind of for you. People kept creating blank videos and paying me for this. I was thinking about why on earth would somebody be creating blank videos and it must be a bug and if it's a bug then they want their money back and they'll complain. So I chased up a few of these people and I tried to kind of understand what's going on because I originally thought we have a bug in the development pipeline for the videos. So... I started asking like, you know, I'm using some, I don't know, Google slides or, you know, keynote or whatever to produce PowerPoints. Maybe there's a bug how we read that. And the person, no, no, we, know, official Microsoft PowerPoint. They said, well, can you please open the PowerPoint you uploaded? Do you see anything on the slides when you open it? And the person, no, it's blank. Right? Okay, so it's blank for you as well. I said, yeah. So.

Brian (03:48)
Yeah.

Gojko (03:54)
What's going on? so what I've done is through UX interviews and iterating with users and research, we've made it very, very easy to do advanced configuration on text -to -speech. And it was so much easier than the alternative things that people were creating blank PowerPoints just to use the text -to -speech engines so they can then extract the audio track from it.

Brian (03:54)
Yeah, why?

Gojko (04:23)
and then use that and it was this whole mess of obstacles I was putting in front of people to get the good audio. It wasn't the original intention of the tool. It wasn't the original value, but people were getting unintended value from it. And then I ended up building just a very simple screen for people to upload the Word document instead of PowerPoints. And it was much faster for users to do that. A month later, there was many audio files being built as videos. Two months later, audio... production overtook video production. then at the moment, people are building many, many more audio files than video files on the platform. So it was an incredible growth because of this kind of crazy insight of what people were doing. kind of usually, at least kind of in the products I worked on before, when you have somebody abusing the product, product management fight against it. There's a wonderful story about this in... Founders at work a book by Jessica Livingston and she talks about this kind of group of super smart people in late 90s who Came up with a very very efficient Cryptography algorithm and a way to compute the cryptography so they can run it on low -power devices like Paul pilots Paul pilots were you know like mobile phones, but in late 90s and Then they had to figure out, how do we monetize this? Why would anybody want to do this? So they came up with the idea to do money transfer pumping, Palm pilots, you know, why not? And kind of the built a website. This was the late nineties as a way of just demoing this software to people who didn't have a Palm pilot device next to them. The idea was that you'd kind of see it on the website, learn about it, then maybe download the Palm pilot app and use it in anger. People kept just using the website, they're not downloading the Palm Pilot app. So the product management really wasn't happy. And they were trying to push people from the website to the Palm Pilot app. were trying to, they were fighting against people using this for money transfer on the web and even prohibiting them from using the logo and advertising it. They had this whole thing where nobody could explain why users were using the website because it was a demo thing. It was not finished. It was not sexy. It was just silly. And Jessica kind of talks to one of these people who insists that it was totally inexplicable. Nobody could understand it. But then a bit later, they realized that the website had one and half million users and that the Pongpilot app had 12 ,000 users. So they kind of decided, well, that's where the product is really. And that's like today, people know them as PayPal. They're one of the biggest payment processes in the world because kind of, you know, they realized this is where the product is going. And I think in many, many companies, people

Brian (07:03)
Ha ha.

Gojko (07:18)
stumble upon these things as happy accidents. And I think there's a lot more to it. We can deliberately optimize products by looking for unintended usage and not fighting it, just not fighting it. just understand this is what people are getting as value. And I think for me as a solo product founder and developer and product manager on it, One of the really interesting things is when you have somebody engaging with your product in an unexpected way, most of the difficult work for that user is already done. That person knows about you, they're on your website or they're using your product, the marketing and acquisition work is done. But something's preventing them from achieving their goals or they're achieving some value that you did not really know that they're going to achieve. you know, that's something the product can do to help them and remove these obstacles to success. So that's kind of what lizard optimization is making this process more systematic rather than relying on happy accidents. And by making it more systematic, then we can help product management not fight it and skip this whole phase of trying to fight against our users and claim that users are stupid or non -technical or... They don't understand the product, but they're trying to figure out, well, that's what the real goals are. And then following that.

Brian (08:47)
That's awesome. So the pivot, right? The pivot from here's what we thought our problem was we were solving to now here's what we're actually solving and we should organize around this actual problem, right?

Gojko (09:02)
or here's what we're going to solve additionally. This is the problem we've solved, but hey, there's this problem as well. And then the product can grow by solving multiple problems for people and solving related problems and solving it for different groups of people, for example. And that's the really interesting thing because I think if you have a product that's already doing something well for your users and a subset of them are misusing it in some way, then kind of...

Brian (09:04)
Yeah.

Gojko (09:30)
The product might already be optimized for the majority of users, but there might be a new market somewhere else. So there might be a different market where we can help kind of a different group of users and then the product can grow.

Brian (09:43)
Yeah, I like to focus on the user. There's an exercise that we'll do in one of our product owner classes where we have a fake product that is a smart refrigerator. And one of the exercises we try to get them to brainstorm the different kinds of users that they might have for it. And one of the things that always comes out in that class is as they're going through and trying to describe the types of users, they inevitably hit to this crossroads where they start to decide Well, yes, we're thinking of this as a home product, something for people to use in their homes. But then the idea crosses their mind, well, what about commercial kitchens? What about people who might use this in another setting? And it's always an interesting conversation to say, well, now you've got a strategic choice to make, because you can target both. You can target one. You can say, we're ignoring the other and we're only going in this direction. So to me, I think that's kind of one of the interesting crossroad points is to say, how do I know when it's time to not just say, great, we have this other customer segment that we didn't know about, but actually we should start to pivot towards that customer segment and start to really target them.

Gojko (11:03)
Yeah, think that's a fundamental question of product development, isn't it? Do you keep true to your vision even if it's not coming out or if something else is there that's kind more important than I think? For me, there's a couple of aspects to that. One is, laser focus is really important to launch a product. You can't launch a product by targeting... the whole market and targeting a niche type, figuring out, you know, user personas, figuring out like really, really, this is the product who we think the product, this is the group who we think the product is for and giving them a hundred percent of what they need is much better than giving 2 % to everybody because then the product is irrelevant. But then to grow the product, we need to kind of grow the user base as well. And I think one of the things that... is interesting to look at and this comes from a book called Lean Analytics. It's one of my kind of favorite product management books is to look at the frequency and urgency of usage. If you have a group that's kind of using your product, a subgroup that's using your product very frequently compared to everybody else, that might be kind of the place where you want to go. The more frequently, the more urgently people reach for your product when they have this problem. the more likely they are going to be a good market for it. with kind of another product that I've launched in 2013, we originally thought it's going to be a product for professional users. And we aimed at the professional users. And then we found that a subcategory that we didn't really expect, were kind of teachers and children in schools. we're using it a lot more frequently than professional users. And then we started simplifying the user interface significantly so that it can be used by children. And it's a very, very popular tool in schools now. We are not fighting against other professional tools. We were kind of really one of the first in the education market there. And it's still a very popular tool in the education market because we figured a subgroup that's using it very frequently.

Brian (13:14)
Hmm. Yeah, that's awesome. How do you know when, you know, what kind of threshold do you look for to determine that, this is, because, you know, in your book, you're talking about, you know, behaviors that are not normal, right? People using your product in a way that you didn't anticipate. And what kind of threshold do you look for to that says, hey, it's worth investigating this? You know, I've got this percentage or this number of people who are using it in this strange way. At what point do you chase that down?

Gojko (13:49)
I think it's wrong to look at the percentages there. I think it's wrong to look at the percentages because then you get into the game of trying to justify economically helping 0 .1 % of the users. And that's never going to happen because what I like about this is an idea from Microsoft's Inclusive Design and the work of Kat Holmes who wrote a book called Mismatch on

Brian (13:52)
Okay.

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

Brian (14:34)
Yeah.

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

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

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

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

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

Brian (24:38)
Hahaha.

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

Brian (25:03)
Hahaha. Wow.

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

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

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

Brian (28:31)
Yeah.

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

Brian (29:31)
Yeah.

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

Brian (30:11)
Ha

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

Brian (30:58)
Yeah.

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

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

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

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

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

#115: Aligning Leadership for Success with Dr. Tess Thompson

11 september 2024 | 29 min

Join Brian and Dr. Tess Thompson as they delve into the complexities of scaling Agile, highlighting the challenges of aligning leadership priorities, fostering transparency, and applying system-level thinking for successful organizational transformations.

Overview

In this insightful episode, Dr. Tess Thompson tackles the pressing challenges organizations face when scaling Agile, with a focus on the critical role of leadership alignment. Drawing from her extensive experience, she explains how misaligned priorities at the leadership level can stall progress and waste resources.

Dr. Thompson emphasizes the importance of system-level thinking, transparency, and communication between teams and leaders to resolve misalignments and ensure success. She also shares her holistic approach, blending practices from various Agile frameworks to meet the specific needs of different organizations.

References and resources mentioned in the show:

Dr. Tess Thompson
Scrum Inc.
Scrum.org
#68: The Pros and Cons and Real World Applications of SAFe with Mike Hall
#94: Connecting Teams and Leadership with Anthony Coppedge
Three Questions to Determine If an Organization Is Agile by Mike Cohn
Certified Scrum Product Owner® Training
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Dr. Tess Thompson is a visionary leader in Agile transformations, with over three decades of experience reshaping industries from energy to biotech across the globe. As a professor at St. Mary's University, her dedication to fostering Agile leaders has empowered countless individuals to embrace adaptability and forge their own path to success.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have a very special guest with me. I have Dr. Tess Thompson with me. Welcome in Dr. Thompson.

Tess Thompson (00:13)
Hi, I'm glad to be here.

Brian (00:16)
I'm so happy to have Dr. Thompson with us. And just for people who aren't familiar, let me make sure that I introduce her and give you the background a little bit. First of all, she's been in this business for almost 40 years now. She's been doing stuff in IT since the 80s. She is a principal consultant and RST fellow with Scrum Inc. Scrum .inc, I should say. She is a PST as well with scrum .org. So two different organizations from two different founders of Scrum. She has been a professor at St. Mary's University. So has that kind of educational background as well. And I was asking her beforehand if there's anything else I needed to say. And she said, well, make sure you say I've got nine grandchildren. That's kind of my claim to fame. I love that. So. Nine grandchildren, very happy for that. So that's who we're talking with. And we wanted to have Dr. Thompson because there's a lot of experience here that she brings to the table in the realm of scaling, obviously being connected so closely with those two organizations. So with all that out of the way, let's talk about scaling a little bit. And Dr. Thompson, what I want to start with is just

Tess Thompson (01:27)
I'm

Brian (01:40)
When you work with organizations today that have scaling issues, what are organizations really struggling with? What's kind of the main issues that you see organizations have with scaling today?

Tess Thompson (01:55)
I would say there's a lot of things, but I would say still the biggest problem is getting everybody to align on what the priority is. So at some point, like you get alignment with maybe people that are doing Scrum and they're the people that are above them, but then the people above them are out of alignment. like, for example, one of the clients I have right now brought some consultants in to work on a project.

Brian (01:59)
Yeah, right.

Tess Thompson (02:24)
And those consultants have been stuck now for four weeks. And where the alignment problem is, is actually up at the C -suite with this client. Because one of them says, nope, we were supposed to help. That was a priority in 2023. And the other one's like, no, this is a priority in 2024. And they're not helping each other. So in the meantime, this project is stuck for four weeks. And we're spending money on people that are sitting there doing nothing.

Brian (02:50)
So just when you say alignment, give us kind of a flavor. when leaders are misaligned, what kind of things are they, are there different ideas about priority or different ideas about why they're doing this? What are they misaligned on? Okay.

Tess Thompson (03:09)
Both, both, I would say both. The, you know, especially as the companies get bigger and bigger, we have a CEO who's got some priorities, but then all the C -suite under them have their own priorities and they're not always, and then they break down to the next level and these priorities start to get out of alignment because people start bringing in their own objectives and their own priorities and they often don't match what somebody else is doing. So part of it is the different incentives and just the organizations being so big, they have to get even these priorities aligned at different levels.

Brian (03:49)
So this is kind of an amazing thing, I think, for people to latch onto here, because I hear a lot of people in just regular base level classes talk about how there's a disconnect between them and the leadership on how they're going to do Scrum and how this fits into the overall structure of the organization. just understand, Dr. Thompson here is talking about organizations that The leadership has stated, at least in some way, or form, we're in alignment with this. We want to do this. We want to have Scrum throughout our organization. But even in those situations, we're seeing these misalignments of just priorities and what are the drivers really for what they're trying to do. So I find that fascinating that talking to so many people who just wish that their leadership could get on board. with what it is they're trying to do, that even in those organizations where they do, quote unquote, get on board, there's still these kind of fundamental disconnects.

Tess Thompson (04:51)
Yep, absolutely. In fact, I do very little work anymore on scrum specific. is many organizations, I mean, almost every organization I go into anymore has some shape or form of scrum going on or people with experience with it. Some people, you know, they're not, it's something that they're trying to do anyway, something agile. And they're... They're getting things done quicker. They're delivering with higher quality. They have better communication at that level. But then as you go up the chain, things start to break down and then teams are stuck. So organizations can only get product out the door with high quality as quick as possible. The more the organ... We have to really think the system. So most of the work that I do today is around the system, which is scaling. It's system agility. Otherwise you start having, you just run into optimization in areas, that local optimization problem.

Brian (05:58)
Yeah, yeah, not seeing the whole, right?

Tess Thompson (06:02)
Right, absolutely. So I think that over the years that Agile has been around, we're seeing more and more of it, but then it's, like I said, almost all my work now is system level and not down at the team level. So often I'm not even using Scrum language when I'm talking. It is about alignment. It is about prioritization. So yes, at a Scrum level, your product owner is putting the order of the product backlog, and then the team can pull out off that backlog. based on value from all the different stakeholders that the product owner is working with. But in a big organization, those stakeholders can be a manager, can be a director, it can be another department, it can be, it's from all over the place. And then at some point, how does that work coming into the product owner roll up to the priority of the department or a higher level? And then how does that roll up to the higher level? And that's where we start running into messes.

Brian (06:58)
Yeah. Yeah. Yeah. mean, it's like you said, with all these various priorities, with all these various drivers, I've always talked to product owners and say, it's a tough job. You're balancing the needs and desires of all these people into one product, and you're having to take them all into account. So yeah, it's not easy. It's not an easy job.

Tess Thompson (07:08)
You.

Brian (07:27)
Well, so I'm curious about, you say you don't really even use the Scrum language as much when you're talking to the leaders, because they're not really interested in that, right? They're not really interested in, we doing this exactly according to what the Scrum guide says? They're interested in the outcome, right? The results that you're getting from this. Yeah, so I'm kind of curious, especially since you're a fellow with Scrum Inc. And I know that the...

Tess Thompson (07:37)
No. Absolutely.

Brian (07:55)
a Scrum at Scale kind of strategy is very specific about how these things are implemented. There's practices and all sorts of stuff that Scrum at Scale kind of implements. Would you categorize yourself as sort of a Scrum at Scale implementation consultant? Or is it more of just, I take more of a holistic approach to the scaling.

Tess Thompson (08:19)
Holistic, absolutely. So actually, I'm certified in Nexus, Scrummit Scale, Less, and Safe. I mean, I have all of them. So I always think you need to bring the best tool to the job. One of the things I like about Scrummit Scale and Nexus is they're just so simple. Like if, hey, if these two teams are not, if we need to coordinate, let's get these product owners together and work together to figure out what is really the order. So whether we call it a meta scrum or we call it something else, I don't think that language matters as much as seeing the need and then bringing in a tool to help meet that need. If these teams are interdependent and they need to be chatting to help get rid of those interdependencies, well, let's spin up a scrum of scrums here.

Brian (08:58)
Yeah. Yeah. Yeah. I've had someone on before that we've talked through kind of the safe model a little bit and talked about how, you know, there's so much additional overhead, there's so much additional roles and events and all these other things that get added from the safe perspective, that it can be very, very overwhelming for a lot of organizations to look at that and say, well, gosh, how are we ever going to, I mean, we're barely hanging on with it, trying to understand what Scrum is. And now we're going to layer in all these other things and,

Tess Thompson (09:22)
Thanks. Okay.

Brian (09:38)
It just seems like a recipe for disaster to try to understand all these things. So I guess one of the things that I had in that previous conversation was this dialogue about how you match the problem to the practice. You find the problem that is going on in the organization and you find the right practice that solves that, but not necessarily implementing the whole smorgasbord of practices because you may be trying to solve problems you don't have. Do you see that as kind of your approach when you work with organizations or how do you match the practices to what's actually going on on the ground?

Tess Thompson (10:18)
Yeah, I would say, you know, it's kind of similar to what happened with, so I'm also a PMP. So when we When we put together the PIMBOK over the years, it became this, know, it was supposed to be, these are best practices that you can have. And over time, it became very, big, thick book and people didn't understand they were only supposed to implement whatever tool from that book really helped solve the problems they were having. And started implementing the whole thing. And I think that's what happens too with like,

Brian (10:50)
Ha ha.

Tess Thompson (10:53)
safe or any of these agile practices, even though, know, Ken and Jeff went completely the opposite of PMI and said, hey, we're just going to roll out. This is the absolute minimum that you need for running, running a team or a project or product. And, but it's not enough. So you need to add in some more things to it. You got to bring in some additional tools to help depending on the organization, such as road mapping. I really believe that's one of the. I spend a lot of time helping organizations and product owners think about, we do need to plan ahead. And that is one of the pieces I do like about SAFE is that in their PI planning, have the getting some product owners and teams together to plan together to look out further, I think is pretty essential in most organizations. Now, do we need to do it on a regular cadence of every eight weeks? And do we need to have 200 teams together? I think

Brian (11:23)
Yeah.

Tess Thompson (11:49)
Sometimes it's, think organizations end up implementing all of SAFE, kind of like in the pin box, if you will, and it's way more than they need. So I think it's taking the elements of all of these and then using them to meet the need of the organization. I mean, if you're a 30 person organization, do you need a bunch of release trains and engineers and stuff? No.

Brian (11:59)
Yeah. Yeah. Yeah, I mean, it's very interesting to me with your background that you have all of these different scaling frameworks in mind. How much of what you do do you feel is aligned to a specific framework and how much of it is just piecemeal across the different frameworks?

Tess Thompson (12:34)
I would say I'm most aligned to, well, Scrum at Scale, never solely. It's always piecemeal. It is a piecemeal thing because I really do believe that teams do get to need to plan out in almost every company I go into. Teams do need to plan out more than one sprint.

Brian (12:44)
Hmm.

Tess Thompson (12:54)
Okay, we need to plan out and we're never delivering anything alone with one team. It seems like we're always need multiple teams. So we need that coordination and we need some of the scaling practices for sure. I really use a variation of safe of PI planning, but then I layer in, so we put together our plan for let's say the month, maybe we have a product goal for the month. And then I use the version of PI planning to get the teams together to plan out for sprints. weekly sprints to get to that product goal and try to get rid of the dependencies and problems that we see between the teams. And then we let it run. But then I pull in from Scrum at Scale, definitely the Metascrum. Like every sprint, let's still get the product owners together and revise our sprint plans because we've learned a lot in the last sprint or we learned a lot today. So we're not just going to let it ride for a month, for example, we're going to still get together at a regular cadence, like once per sprint. and realign our backlogs based on what we've just really happened. So it's using both, yeah.

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

Tess Thompson (14:04)
Absolutely.

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

Tess Thompson (14:22)
Okay.

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

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

Brian (16:13)
Yeah.

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

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

Tess Thompson (17:18)
Okay.

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

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

Brian (17:56)
Yeah.

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

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

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

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

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

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

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

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

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

Brian (21:21)
Right.

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

Brian (22:44)
Yeah.

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

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

Tess Thompson (23:07)
Okay.

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

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

Brian (23:50)
Yeah.

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

Brian (24:30)
Yeah.

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

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

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

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

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

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

Tess Thompson (25:44)
Yep.

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

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

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

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

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

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

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

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

Brian (29:27)
Ha ha.

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

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

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

#114: Is Agile Dead? with Scott Dunn

4 september 2024 | 40 min

Is Agile really dead, or are we just doing it wrong? Tune in as Brian and Scott dive deep into the controversies and misconceptions surrounding Agile practices and what it really takes to make Agile work in today’s organizations.

Overview

In this episode, Brian and Agile Mentors Podcast regular, Scott Dunn, tackle the provocative question: "Is Agile Dead?" sparked by recent claims of Agile's high failure rates.

They discuss the validity of these claims, the common pitfalls of bad Agile implementations, and the importance of continuous improvement and experimentation in Agile practices. The conversation explores the shortcomings of current training approaches, the crucial role of effective coaching and leadership support, and how to overcome the widespread misconceptions about Agile.

Brian and Scott emphasize the need to focus on outcomes and ongoing learning rather than getting bogged down by methodology debates and rigid terminologies.

References and resources mentioned in the show:

Scott Dunn
#93: The Rise of Human Skills and Agile Acumen with Evan Leybourn
Are Agile and Scrum Dead? By Mike Cohn
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. Welcome back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today, friend of the show, regular, you know him, you love him, Mr. Scott Dunn is with us. Welcome back, Scott.

Scott (00:13)
That's my new favorite intro ever. So thank you, Brian. Always glad to be and then glad to talk shop. So I appreciate you making me some space so that I get to work with you again.

Brian (00:16)
Ha ha ha. Yeah, we need like walkout music for you. know, like when the pitcher comes out to the mound, the relief pitcher or the wrestler comes out, you know, or whatever, they play the walkout music. We need walkout music. We wanted to have Scott back because there's a hot topic and this is your hot take alert because this show I'm sure is gonna be full of personal hot takes here on the subject.

Scott (00:30)
Yeah yeah, there you go.

Brian (00:50)
And that is, is Agile dead? There has been a lot of talk recently about this in the past few months. There's been a lot of blog posts written, a lot of armchair quarterbacks chiming in and trying to make sense of this. So before we dive in, Scott, I want to give a little bit of background to our listeners in case you're not aware of something that happened, where this came from, right? Because I think that there was In one sense, there's always an undercurrent. There's always people out there who are ready to say Agile's dead, right? And so they're waiting to pounce on anything that would back them up. And there was someone who was very happy to oblige about that. There was a company called Engprax, E -N -G -P -R -A -X. I couldn't find much out about them except they're a consulting company. And they put out an article that was announcing research they had done that said that 260 % higher failure rates for Agile software projects. That's what their study revealed. Yeah, 268%. So let's just start there, right? But the article is very thinly veiled in support. of another competing process, believe it or not, called Impact Engineering that is authored with a book that's just out, believe it or not, by a gentleman named Junade Ali. Now I have no idea, I have never crossed paths with this gentleman. I don't know his philosophy or his, much more about him. I did look him up on LinkedIn. He's been in the business for about 11 years. If I trace back to his first thing, it's about 11 years ago. He currently lists himself as the chief executive officer of a stealth startup. Well, I think I can remove the mask of what that stealth startup is because it is Ingeprax. So he is the head of that company. I found another article that did the research in support of his book.

Scott (03:03)
Hahaha

Brian (03:12)
announcing his new process that is a competitor, of course, to Agile. Now, there's been a lot of back and forth. He's tried to defend this and say, you know, the research is solid, but here's the thing I always say, without data, it didn't happen. If you're not showing me the actual methodology, if you're not showing me the scientific research paper behind it that says, here's the methodology of the research, here's how we conducted it, here's the... There are some details that are in the article, one of which is that the research was done over a period of about five days. So it was research over about five days. was interviewing a set of, I'm trying to scroll through and find the numbers. I think it was like 250 or so engineers from the UK and 350 from the US. It's something around those numbers. But it was interviews with engineers over a period of about five days.

Scott (03:50)
Wow.

Brian (04:11)
And so the numbers are based on these engineers' recall of what their idea of success was in projects, whether it was an Agile project or not an Agile project, by their definition of whether it was an Agile project or not. He doesn't really describe in the article what success is. So saying that it's 268 % failure, what is a failure? It doesn't really state that plainly. So again, where's the data, right? I'm not going to go on and on about the research and the fact, but I just want to give the background before we dive into it because that article is what now you will see quite a few blog posts and things crossing your desk on LinkedIn that say, wow, look, this new study says 268 % failure rate for agile projects. Well, anytime you see something like that, check the source. You have to check the source. I try to do this in any conference talk I do. I put the links to the sources. And I try to only list data that comes from scientific studies, where you can find the actual research paper and dive into it and get into the nitty gritty of it if you really want to. Otherwise, as I said, it didn't happen. He says in the article, hey, we had PhD people that looked over our work, unnamed PhD people. So you can't even question whether that person was someone legitimate who did it. Just trust him that they were legitimate. So I set that up because I don't mean to take so much time here at start of the episode, but I just wanted to set the foundation. If you weren't aware of that kind of thing or where that came from, you may not even been aware of the background of where that study came from.

Scott (05:46)
You

Brian (06:04)
And the fact that the person who kind of sponsored it is got an ulterior motive, right? They're trying to push their own methodology and they're publishing research that they collected, they are publishing, that just so happens to support their foregone conclusion that Agile's bad and their methodology is better. So, but Scott.

Scott (06:31)
I'm just trying.

Brian (06:32)
So let's get into the topic because what I really want to get into is, I'm sure you've seen people post things like this and there's been sort of this wave of things in the past year or so of people who are so quick and anxious to say Agile is dead. So what's your general impression there? What have you seen? What have you experienced and how do you respond if someone in class says, hey, is Agile dead?

Scott (06:43)
Mm Mm I great, great question. So for those listening, I want to just want to affirm that probably a lot of you had experiences like, well, certainly wasn't going great or we're not seeing what we thought and all those things. So part of this, Brian, is I think the ethos of why those things take off like that is I do think there's a general feeling of is this really working for us or not? That's that's fair. So I'm not going to pretend like, it's always goes great. It's, you know, be Pollyanna about that. I remember actually this year. of a CEO, a company saying, Agile absolutely does not work. We're going to go all the way back to just full waterfall. Right. That to me is kind of that harbinger of like, wow, it's built up enough for someone to say that. So a couple of thoughts I have, and I'm going to be pragmatic like you for my friends that are hearing this or maybe thinking this or people at your company are pushing back a bit, is I'm to go back and say, well, okay, let's just say that Agile is dead. So what are you going to do? Are you really going to go back to waterfall? Well, we already know that story. whole reason, for those listening, consider this, whole reason Agile took off was the option A wasn't working and very clearly wasn't working for complex projects like software. Now for this person to come and recommend XYZ, of course, not surprising for all the listeners out there. Obviously, there's a marketplace, there's business. I get it that people are going to pitch and recommend what they do my classic one in our space Brian would be because obviously you I Mike within Mountain Goat are teaching the CSM CSPO and I'll see like 350 page books of get ready for the CSM exam like right the scrum guide itself is I mean how many pages so come on

Brian (08:38)
You

Scott (08:47)
And they'll even be like, you know, misrepresentation. So clearly people are doing things in their own self interest. get that. as you as people out there, hear information, I love what you're saying is to just like look into it and really be mindful of what's their angle for some of that. But back to your question, is Agile dead? I would argue that Agile partly done or halfway is dead in the sense that that doesn't work or what I would kind of call Agile theater. Agile hand waving, spread the agile pace. So I've been doing this 18 years, I think, since becoming a Scrum Master. And I was on project delivery before that and managing IT people. So I've seen all the things that weren't working well as a developer, et cetera. And I saw the results of what I got. And I've seen plenty of stories beyond that. But what I see more and more is people who are further away from the beginnings and what they're kind of doing is implementing what's comfortable. And I would agree that doesn't work. in that sense, that Agile is dead. In a follow on the idea of and really kind of putting together realizing is for those out there that your company is the one implementing Agile, who usually gets that? Well, it's probably going to be the PMO. And I'm going to poke a little bit here, certainly for my PMO friends, but as a former PMP working within the PMO, what's the PMO responsible for? So if I go to your typical company, say, hey, we're going to go Agile. That's under the purview of who it's a, it's a, there's going to be a group that's responsible for watching over execution delivery. Who is that? It's a PMO. Think about this. The PMO is not responsible for like learning continuous improvement innovation. They're responsible primarily for, for status reporting, managing to a given date, managing resources, escalating issues, but not necessarily for improving. So they bring in Agile sense of, what do we need to do without maybe understanding it fully and really. How do we just manage this process and not, hey, we're starting off from point A, but we're going to learn and get better as we go across. It's going to stop where they feel like, I think we have a new process that implemented. Does it get the results? You know, I don't know and I don't understand how it works to fix that. So they may not be getting results is what I commonly see. I'm seeing a slew. I can tell you the last several companies just in these last few months we've worked with. We've got to fix our process is not working. Are you agile? Yes. But you look at it and they'd miss a lot of fundamentals. And so now we're kind of resetting a lot of people that are struggling with the same issues everyone's talking about. Visibility, predictability, can we deliver this by the date we gave senior management? And they're not by and large. For those who say agile is dead, one of the other options, people have put together agile manifesto had lots of ideas, lots of other approaches besides scrum, but even if just take scrum. Look, scrum is based on lean. Is lean dead? And scrum is an empirical process. Is empiricism dead? Does that not work? So I kind of come back like, what are your options? Just think about the results you're getting. Whose fault is that? And what are we even basing what we're looking at? The roots of it are all very solid. So yeah, I'm going to push back quite a bit on that, what I've seen. And maybe see some of those same. Results or lack of results for organizations Brian because I know that it doesn't always go great out there and in the marketplace is coming. Try to roll this out.

Brian (12:07)
Yeah, yeah, there's a, so I have a couple thoughts here. One is just in general, I think you're absolutely right that there's, know, well, just listeners, ask yourself, what percentage of Agile practices out there do you think are doing Agile the right way? Right? And I don't mean like a hundred percent. I just mean they are, they're all in on it. They're trying to do it the right way. I don't know what number you have in your head, I would say, don't know, Scott, what would you say?

Scott (12:43)
They're doing it right?

Brian (12:45)
Yeah, they're not perfect, right? But they're committed to doing it right. They're committed to doing it according to what the Agile Manifesto says, that sort of stuff.

Scott (12:55)
Fairly Fairly smart, right? I'm guessing, my first number that came to mind, you asked, I'd say 10%. That's my, maybe less than that.

Brian (13:02)
Okay. Yeah, I would bet it's a small thing, right? Now that right there, I think is something that we can talk about. Why is it that small? Right? Why is it that small? And I think that there's a discussion that's a legitimate discussion to be had about, well, maybe the structure that was put in place to spread this and train people up and get them, you know, situated to do this well. has failed. And if that's the case, that's the problem. It's not really that the methodology is bad. It's that we didn't do a good job of explaining it or training people for it. that's a separate discussion. But I think that there's a lot of bad agile out there. And I'll just put it to you this way. If you like to hike or camp or anything like that. If you are an aficionado of that stuff, right? If you occasionally go hiking or camping, I'm fairly certain that you've had some hikes or some camping trips that weren't that great, right? And you can probably recall them and think, wow, that was horrible. Well, imagine if that was your only experience, right? Imagine if that hike or that camping trip was your only experience. And you came back from that and someone said, you tried hiking or you tried camping. What did you think of hiking or camping? That sucked, it was horrible. I never wanna do that again. I don't know why these people are crazy, that do that stuff. I would never do that again. But if you really like it, you know that yeah, there could be some bad experiences, but there's some good experiences too. And if you plan a really nice hike and you've got good weather and everything else, it can be a really great experience. So to base someone's opinion on, well, my experience in one place was that it was terrible. Well, okay, come on, give it another shot, right? I mean, they're not all gonna be perfect. And if you see it in a couple of places, you'll probably understand, now I know what we were doing wrong in that other place because it's clear now, right? So that's one point here. And the other thing I wanted to say is one of the things that they talk about in their

Scott (15:17)
Right.

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

Scott (15:42)
boy.

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

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

Brian (18:34)
Ha

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

Brian (20:45)
Yeah.

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

Brian (20:59)
You

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

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

Scott (22:53)
Thank you.

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

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

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

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

Brian (25:14)
I agree.

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

Brian (25:56)
Right.

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

Brian (26:53)
Yeah.

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

Brian (28:26)
Yeah.

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

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

Scott (30:07)
you

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

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

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

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

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

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

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

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

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

Brian (37:37)
Yeah, yeah.

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

Brian (38:28)
Yeah.

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

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

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

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

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

#113: Influence Without Authority with Christopher DiBella

28 augusti 2024 | 31 min

Join Brian Milner as he talks with leadership expert Christopher DiBella about mastering the art of influencing without authority. Learn how to lead with respect, empathy, and compassion to inspire your team, even when you don’t hold the official title.

Overview

In this episode of the Agile Mentors Podcast, Brian interviews Christopher DiBella, an expert in leadership and organizational development, about the power of influencing without authority. They explore how Agile leaders, especially Scrum Masters, can effectively guide teams and influence organizational culture through respect, empathy, and compassion.

Chris shares practical strategies for building trust, navigating generational differences, and leading through relationships rather than formal authority. The discussion also emphasizes the critical importance of understanding the motivations and needs of others to achieve lasting influence.

Whether you're an Agile coach, Scrum Master, or organizational leader, this episode provides actionable advice for leading in a way that inspires collaboration and growth.

References and resources mentioned in the show:

Christopher DiBella
The Leadership Survival Guide: A Blueprint for Leading with Purpose and Impact by Christopher DiBella, PH.D.
#37 Servant Leadership, Not Spineless Leadership with Brad Swanson
#70 The Role of a Leader in Agile with Mike Cohn
#109 Leadership and Culture in DevOps with Claire Clark
Short Answers to Big Questions About Agile Leaders by Mike Cohn
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mike Cohn’s Better User Stories Course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Christopher DiBella is a leadership coach dedicated to empowering aspiring leaders by teaching influential leadership practices that streamline processes and maximize potential. As the founder of the Institute of Leadership Coaching and Development, Chris is committed to helping others lead with respect, empathy, and compassion to build engaged, high-performing teams.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have a very special guest with me. I have Mr. Chris DiBella with us. Welcome in, Chris.

Chris (00:13)
Thanks so much, Brian. I appreciate you guys having me.

Brian (00:15)
Absolutely. We're very excited to have Chris on. Chris, if you're not familiar with Chris and his work, just a brief little introduction here for you. Chris has an MBA in project management. has a PhD in organizational leadership. He's an author and speaker. He's the founder of something called, actually founder and president, excuse me, of the Institute of Leadership, Coaching and Development. And he has a book that should be out right about now while you're listening to this called the leadership survival guide quotes to keep you from going extinct as a leader. So very, very interesting title there. I can't wait to read that. That sounds amazing. But the reason we wanted to have Chris on was one of the topics that Chris focuses on and talks about from time to time is the topic of influencing without authority. And I thought that's really, really interesting in the Agile world and how that relates to things like Scrum Masters and how we work within the organization and stuff. So let's start there, Chris. Let's just talk about where that, what does that title mean to you influencing without authority? Where did that come from? How did that enter your sphere?

Chris (01:27)
Well, I mean, for the last couple of years, it's a topic that's just been gaining a lot of momentum within the workplace. I guess the easiest way for me to describe the topic is to say that influencing without authority is simply the ability to motivate others to get them to take your direction. But we all know that the real world doesn't work that way. And it's not so easy to get people on board with our ideas and thought processes. So we just need to be more methodical in our approach. when it comes to influencing others. And it's more important now, particularly because when dealing with the different generational and personal generational differences and personalities in the workplace.

Brian (02:06)
I'm kind of curious how you define that difference. What does influencing with authority look like? What does influencing without authority look like?

Chris (02:18)
So they kind of both the same. think people sometimes fail to realize that influence is what actually provides power, right? And not authority. So they both kind of fall on the same lines for me. So when you're trying to influence others, you got to remember that with or without authority, you're trying to get somebody, you're persuading somebody, recently you're coercing them to try to get onto your thought process. So you just got to remember that. When you're dealing with them, that you have the capacity to impact what happens next in their lives. Their lives, sorry, not lives. like you have the ability to shape their actions and their behaviors and their opinions, but you also have the ability to have an effect on their character or their continued development. Right. And kind of adding a little bit more to that question is Ken Blanchard, said that the key to successful leadership in today's workplace is influence and not authority. So for someone to be an influential leader, they just need to learn the skills of confidence and clarity and communication. So that to me implies that even if you're not in a formal position of authority, you can still have an influence on those around you. So it's kind of just bouncing off. You know, there's a thin line of with or without authority. It's just understanding people and understanding how to get the best out of them. And you don't need to be called leader or manager to get that out of people.

Brian (03:48)
I'm kind of curious because especially with your background in project management, kind of more traditional project management, how does that play in project management? I mean, I've gotten in trouble sometimes in talking in class about this issue because I've, know, in my work history, my experience with traditional project management was very much one of... authority. was very much that that person who was the project manager, basically there was a date, a set of work that we're trying to accomplish. it seemed as if the project manager's job was to kind of drive the team, push the team, be the parent of the team, and make sure that they come in on time, on scope, on budget. How does the project management community in today's environment see this dichotomy between leading with influence or with authority.

Chris (04:50)
So that's a great question because I think, can I even touch on Scrum teams with this? Cause, cause I think they're, kind of go hand in hand for me. Right. and I, you know, from, if we use project management or Scrum teams as an example, right. No one, even as a project manager, right. No one has any real form of authority on the people side of things. Project managers really are just people put in place just to get things done. Right. They don't, they don't have an official title to get things done. Right. So it can be argued that.

Brian (04:54)
Yeah, yeah, yeah, please.

Chris (05:20)
while these individuals on a Scrum team or a project management team have no formal authority at all, that they're still ultimately responsible for project outcomes, right? Or it can be argued that an authority is inherently given to them based on their ability to act on behalf of all those objectives. Right. But the bigger point for me is that if there's no formal authority given, this could just limit the influence that someone has on the people in the processes side. Right. But that doesn't mean that you still can't be an effective leader who others look to. And this type of authority is based more on who you are as a person and how you treat others, as opposed to simply being viewed by that title that you possess. So I think there's there's a very strong connection there between Scrumteam and project managers.

Brian (06:04)
Yeah, I mean, it's a tricky thing because I mean, I think about this, like a lot of things, I'll make sports analogies and how I think about these relationships. And when I think about like the coach of a team, the coach can't make the players perform better. It has to be their own personal decision to do what they need to do. But on the other hand, we definitely hold the coach accountable if the team isn't doing well. And it seems almost like slightly unfair, you know, to think about this, that I can't really, I don't really have the authority to make that person do something. I have to, as we said, influence them to do it.

Chris (06:50)
So can I touch on that real quick? Cause you brought up a great analogy that I like to talk about from coaching perspective. So I used to coach soccer and if I start rambling, just tell me to shut up, but I'm licensed to coach up to a college level, right? But I always opted to coach at about the 12 and 13 year age group for boys and girls. And I chose this age group because I believe that this is just where I could have the most influence on them in their development and in their soccer growth, right?

Brian (06:59)
You

Chris (07:20)
The high school level and college level, they could still learn, but they've already got it in there at that age, right? They they've already established who they are on the field, their own identity, right? And they have a good enough skillset to go out there and play the game. But I wanted to be a part of getting them to that point. So I decided that coaching at a younger age group would just give me a better opportunity to mold those players into those high school and college athletes. And anyone listening to this with kids understands. how much influence we have on them at that age. But we also know how difficult it is to effectively influence them in a way that allows them to develop into their own person. So whether we're coaching 12 and 13 year olds, or if we're trying to coach and mentor our peers or our followers, there are just a lot of similar attributes that can be used to influence others to get them to achieve their goals and their successes and those outcomes.

Brian (08:11)
Yeah. Yeah, I completely agree. you know, it kind of, it kind of brings to mind the, mean, we've talked, we talked a little bit about project managers, but, and, and touched a little bit on Scrum teams, but you know, that, that relationship with a, a, a Scrum master, think is also really interesting to consider in light of this, because I know one of the phrases that we use as trainers a lot when we talk about the Scrum master is a Scrum master leads through influence, not authority. And that that's kind of a defining characteristic of what a scrum master does. What does that mean to you? Because I know you speak about scrum as well and you have a lot of knowledge in this area. So how does that translate into the role a scrum master would play?

Chris (08:58)
So if you take it from a Scrum Master perspective, right? mean, that's kind of positional influence, right? So that can come from someone's job title or depending on the hierarchical level of that role, you know, that can have an effect on how influence is also portrayed, either positively or negatively. So whether you're a Scrum Master or some other form of positional leader, it just means that you're followed by other people. So how you choose to impact their life. from an influential aspect will determine the level of followership that you're able to acquire from them. Right. And then kind of going along with that, again, you know, there's really no formal authority in that role, but the influence can stem from expertise and just being competent. Right. That provides you with the background and the experience needed to be recognized for people to go to you for that advice, the leadership advice. But if you also have the available resources that your team needs and you know how to acquire them as well as deploy them, then you're going to have an impact on their success as well, right? If you have the necessary tools to provide them, that's also going to increase the likelihood of them trusting in you as those relationships are developed because that's really what influence is. It's about building relationships and developing those bonds, you know, and then influence. The biggest thing for me with influence is being direct and transparent in your approach. Whether you're a scrum master, project manager, anybody with or without authority, if you're direct and you're transparent and you seem genuine to people and you have a firm, a fair, and a professional tone, that's just going to let other people know that you can be counted on, right? And that you genuinely have their best interests at heart. So that's kind of where earned influence will begin to develop.

Brian (10:50)
Yeah. You know, I, there's a, there's a kind of aspect of this I try to draw out too, when we talk about this in class and that influence, as you said, trust relationship, right? It takes, it takes investment. It's not, influence doesn't come instantaneously. When you think about just in general in your life, the people who influenced you. Right, to use that word influence, that's a shift, that's a big shift. And when you think about the people that influence you versus the people who tell you what to do. And from my perspective, most of the people I would say, yeah, I'm heavily influenced by this or by that. It generally comes from the fact that I have, even if they're a public figure, even if it's, know, you know, Simon Sinek or Gary Vanderchuck, you know, I would say they influenced me not because I just heard one quote, but because I've consistently heard what they speak on and consistently say, yeah, I'm aligned to that. And this is really influencing the way I think about stuff. So how would you advise, especially someone like a scrum master, you know, if they say, yeah, I want to lead through influence, not authority, but... I've got a job to do. How do they start paving that road so that the influence is invited?

Chris (12:26)
Yeah. I love the Gary V shout out because I love Gary. He swears a lot like I do. So I'm actually being pretty good right now. I mean, I guess the first question to ask is, you know, when you think of the term influencer leadership, not for you, but in general, like when you think about it, what's the first thing that comes to mind, right? What are you hoping to get or achieve through that influence? Are you trying to get people on the same wavelength as you? Are you doing it only to get people to see things your way?

Brian (12:28)
You Yeah.

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

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

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

Brian (16:42)
Hahaha

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

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

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

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

Chris (18:35)
you

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

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

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

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

Brian (21:02)
Yeah.

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

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

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

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

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

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

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

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

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

#112: Exploring Collaboration Styles with Jessica Guistolise

21 augusti 2024 | 33 min

Discover how recognizing and accommodating different collaboration styles can transform your Agile team dynamics. Join Brian Milner and Jessica Guistolise as they delve into the key to effective and inclusive collaboration.

Overview

In this episode of the Agile Mentors Podcast, Brian interviews Jessica Guistolise about the diverse collaboration styles that impact team dynamics. They explore the importance of recognizing and accommodating different collaboration styles—relational, expressive, and introspective—to create effective and inclusive collaborative environments.

Jessica provides practical tips for Scrum Masters and facilitators to cater to these styles during meetings and retrospectives. The discussion emphasizes the value of diversity in collaboration styles, which brings different perspectives and ideas to the table, fostering creativity and innovation.

References and resources mentioned in the show:

Jessica Guistolise
Lucid
The Collaboration Style Quiz & Report
The Global Scrum Gathering
Advanced Certified ScrumMaster®
Certified ScrumMaster® Training and Scrum Certification
Advanced Certified Scrum Product Owner®
Certified Scrum Product Owner® Training
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Jessica Guistolise is an Agile Evangelist and coach at Lucid who excels in helping organizations deliver continuous value to their customers. With a passion for people over process, she specializes in change adoption, gaining critical buy-in, and establishing trust in Agile methodologies across various industries.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have a special guest with us. have Jessica Gastolis with us. Did I say that correctly?

Jessica Guistolise (00:14)
You did. Thank you so much. It's a mouthful. I am so happy to be here. Thank you so much for inviting

Brian (00:21)
Absolutely, incredibly excited to have you here. For those who aren't familiar with Jessica, she is an evangelist at Lucid. So I'm sure we'll hear a little bit about that as we talk. She is an agile coach and she has the credentials to back that up. She has from the Coaches Training Institute, a professional coach certification and also she's an ORSC coach, if you are familiar with that. I'm familiar with that. I know there's a lot that goes into getting those. So it's not just, you know, filling out a, sending in some box stops and, you know, getting it back in the mail. and, so the reason I wanted to have Jessica on is because she was speaking at, or she did speak at the scrum gathering that just took place, back in May. And, she had a couple of talks actually that she did with, Brian Stallings there. but one of them really caught my And I thought it would be interesting here to the audience. And that's about collaboration styles. So let's dive into that topic. When we talk about collaboration styles, Jessica, don't we all collaborate the same?

Jessica Guistolise (01:33)
You know, it's funny, we don't actually. Though, although there is a kind of a misconception that we do because we collaborate in the way that we collaborate, but not everybody collaborates in the same way. And so for us to create really amazing collaborative environments, it's helpful to have an awareness of those different styles. And if we facilitate in such a way that cares to each one of those styles, you're gonna get so much more in the room than you would if you only stick with, well, here's how I collaborate. So obviously this is the way to do it.

Brian (02:09)
Right. Yeah, I think this is such an important topic because I know one of the questions I'll get a lot in classes or just even in Q &A sessions when we talk about retrospectives is, I'm having a hard time facilitating my retrospective and my team doesn't want to talk or my team's quiet and shy. And to me, this is all kind of indicative of this concept of you're probably not recognizing that they have different collaboration styles than you do.

Jessica Guistolise (02:41)
Yeah, absolutely. And it's so amazing because I think as Scrum Masters, as Agile Coaches, this is a really important piece to recognize because as the facilitator, you're really building the container. think of these events as like the containers and the folks who are doing the work, they're all the content. But if you build a container that's going to allow for that content to emerge in a healthy way, you just, I mean, Anything's possible.

Brian (03:10)
Right, right. And you know, one of the things I love to say in classes is just that, you know, that facilitation, that's the root goes back to this phrase, it means to make easy. And you know, that's our job is to make whatever that thing is easy. And if we are, if we're not aware of our own personal preference and style and how we collaborate, then it's harder for us to even be empathetic or recognize that other people have different styles and much less how to accommodate them and be inclusive of them in those environments. So I just think it's a really important

Jessica Guistolise (03:51)
Well, and the interesting thing too, besides easy, there's also an element of safety. Because if you're asking me to collaborate in a way that makes me really uncomfortable, then I'm spending all of that time in my discomfort and trying to put forth ideas. Those two things are so, they clash. And so there's also an element of just creating an environment of not just easy because this is the way that I collaborate, but I feel safe in collaborating in a that make sense to me. In fact, there's some, there are a couple of styles that are almost opposites. So if you're asking me to collaborate in that way, ooh, I am not sharing anything with you.

Brian (04:31)
Right, right, you have that amygdala hijack going on. You're kind of, you're in that fight or flight mode of just, my gosh, I'm panicked. I don't want to do this. I feel highly uncomfortable. you know, it's, can, you know, literally it's blocking those neural pathways of actually being able to collaborate and access, you know, the parts of your brain that would allow you to, to contribute in that kind of environment.

Jessica Guistolise (04:59)
Yeah, it's fascinating actually, right before the study that was done came out, I was in a collaboration with a group of people who were collaborating in a way that was wildly uncomfortable. And I came out of that meeting feeling dumb. Like I really was like, wow, I didn't, I just gave nothing. But then, you know, a little while later I was like, well, but I have this idea and this idea and this, wait a minute. I was just stuck because this isn't a way that's very comfortable for me.

Brian (05:28)
Yeah. Well, you know, I know you probably know this, but for anyone else listening out there as well, I have definitely felt that way as well in sessions that were kind of contrary to, you know, opposite of what I prefer. And, you know, the way I always describe it is I don't, I'm not a person who thinks out loud. I think internally, I think quietly and then express it later. I need time to process and work through things. But I recognize there are others who are verbal processors who need to speak out loud and and You know if you're in a meeting with a bunch of those Types of people who have that collaboration style and and yours is a quiet one Then you know I've walked out of those rooms before feeling like gosh I'm the dumb one in this meeting because I didn't have anything to contribute

Jessica Guistolise (06:12)
Yeah, I didn't provide any value in that, but there is, there's so important to recognize that. And I think there's, there's, there are ways to create these containers and to create these collaboration sales that really help to make it so that everyone can feel comfortable collaborating in the way that is going to be comfortable for them. And it just, it's, you know, it's the facilitator work of being prepared.

Brian (06:16)
Right, right.

Jessica Guistolise (06:38)
preparing for the meeting or the event, creating the container in a way that's going to be safe, comfortable, and easy for everyone.

Brian (06:45)
Yeah, absolutely. All right, well, let's get to the meat of that then, because I know there are a few, you kind of delineated these in the presentation that you had. So walk us through, what are the differences in these different kinds of collaboration styles?

Jessica Guistolise (06:59)
Yeah, so the study was done, Lucid did a really interesting study. I was so excited by this. And what they found was over half of knowledge workers identify with one of three collaboration styles. And the other part of that is you may not land fully in one of the three and you may have kind of a blend of them, but these are the ones that we see most often. And one of the things that I always like to point out too is that none of these are Like it's just the way that you feel comfortable. They're all really helpful and healthy and really great ways of coming together. So I'll start with the one that I most identify with because it makes the most sense to me. That's we normally create collaboration is we see how do I collaborate and I'll collaborate with you. So the first is relational. And so relational collaborators really want that human connection. Like they want to be, they want to spend some time. How was your weekend? Or just if it's a brand new person, let's get to know each other a little bit before we dive into trying to solve problems. there's it's, it's almost like, for me, I just feel like I need to be in relation with, in relationship with someone before I'm comfortable collaborating. It's like, the metaphor I like to use is, is like baking bread. If I'm in relationship with you, I'm gonna bring you ingredients and recipes and stuff that I'm playing with and trying to figure out. But if I'm not in relationship with you, I will have that entire thing baked and then bring it out and see if you like it. But that's not collaboration, right? That's me by myself and how much better is the bread gonna be if somebody says, well, let's try this and let's try this and let's try this. So that's a relational

Brian (08:49)
So that sounds like that one in particular needs just a tremendous amount of trust to be effective.

Jessica Guistolise (08:55)
It does. really does. And I actually, I'll tell you a story about this because, so I, I was working with, an individual who had an interesting problem to solve another agile coach. and he'd come up to me and he was like, I have this interesting problem. Do you have anything in your coaching toolbox or knapsack that you can pull out for me really quickly? And I was like, Hmm, you know what? actually don't. but let me think about And so I went, was doing some other things and sort of in the back of my brain. And then I had just an absolutely ridiculous idea. I mean, it was like, I, I felt silly even thinking it, let alone saying it out loud, but I was in really great relationship with this other individual. So I ran across the hall and I said, okay, I have a really dumb idea. And he goes, okay, let's hear it. And I told him, and he goes, wow, that's really dumb. Let's play with it. And so we played with it and got it into something and he took it back to the team and it worked spectacularly. And I think he's still using it today as an exercise that'll help with the team's collaboration. but if I hadn't been in relationship with him, I would have had that dumb idea and then I would have let it go.

Brian (10:10)
Right, right, because you know, you don't want to get made fun of or you don't want to be made to feel dumb or anything. So yeah, absolutely. You got to have that trust and sense of safety with them to be able to bring it up. That's a great

Jessica Guistolise (10:23)
Yeah. The second one is one that I wish I had more of and I just don't. So some people identify as expressives. If you're an expressive collaborator, you are ready to dive in at any moment. Like somebody can throw out a topic and you've got, you're the first voice in the room. You love using visuals and drawing out your ideas and throwing up sticky notes and emojis. You're one of those people that's I'm ready to, I'm just ready to share. I really wish I had more of that. Sometimes I think of them as blerters. Like they're just willing to blurt it out. Whatever is there on top of mind and a brainstorm. And I just, think that's so admirable and it's just not a skill that I have.

Brian (11:09)
So less of that filter then. mean, it sounds like they don't necessarily need to have that basis of trust. They're just sort of always willing to say what's on the top of their mind and get it out in the open.

Jessica Guistolise (11:22)
Yeah, yeah, I think it's a great way of expressing themselves. And they also have maybe a harder time spending that time getting into relationship and all of that ooey gooey stuff. And they're like, let's get to the work, you know. But if we have an awareness that I as an expressive am working with a relational collaborator, some of the work is getting into relationship. So now I feel more comfortable spending that time because I know that the work we're going to do after that is going to be greatly

Brian (11:57)
And correct me here if I'm wrong, because I'm just trying to make sure that we're understanding all speaking the same terminology here, but it sounds like the way you describe this, that expressives are not necessarily verbal expressives. Like you mentioned, someone who's more sketch note based or anything like that. So they may not feel comfortable speaking, but they're very comfortable with the concept of getting an idea out of their head quickly in one way, or

Jessica Guistolise (12:26)
Yes, exactly. It could be in visual form. think of like people who always have memes or GIFs at their fingertips. Like they're just ready to go and send out these their ideas into the world and not hold on to them tightly. know, they hold them on, hold on to them, Lucy, please, because they're coming out in the world.

Brian (12:44)
Hold on loosely, but don't let go. Awesome, I love that. Okay, and then was there another one?

Jessica Guistolise (12:52)
There is. So the last one is introspective. So an introspective collaborator, I dip my toe in introspective collaboration as well. Deep work is really, you love deep work. Spending time really processing, thinking through, chewing on an idea, tossing, playing with it a little bit yourself before beginning to share. It's the opportunity to do some research, do some brain writing, spend some time in ideation. And you might even feel comfortable having a conversation with one person rather than if you have a giant group of people sending them into breakouts to have individual conversations. sending out thoughts about what's going to happen before the meeting or the event so that they've got that time to themselves to say, here's what I'm thinking about this topic. before throwing them into a room with a whole bunch of people and expect them to just go.

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

Jessica Guistolise (14:18)
Yes.

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

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

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

Jessica Guistolise (15:30)
Hm.

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

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

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

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

Brian (18:23)
Hahaha

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

Brian (19:52)
Ha

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

Brian (21:20)
Hahaha

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

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

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

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

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

Brian (23:28)
Right.

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

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

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

Brian (25:41)
No open discussion,

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

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

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

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

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

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

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

#111: Adapting to the Future of Work with Heather McGowan

14 augusti 2024 | 32 min

Explore the dynamic future of work with Brian Milner and Heather McGowan as they discuss the essential shifts in mindset and culture needed to thrive in the augmented era.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner interviews Heather McGowan, a renowned future of work strategist, about the rapidly changing landscape of work in the augmented era.

Heather emphasizes the importance of adaptation, empathy, and human connection in response to technological, societal, and cultural shifts. They discuss the pervasive issue of loneliness in the workplace and the critical role of leaders in fostering a culture of trust, agency, and high expectations to drive performance and productivity.

Heather also shares insights on finding personal purpose and intrinsic motivation to excel in the future of work. This conversation provides valuable strategies for individuals and leaders to navigate the evolving work environment successfully.

References and resources mentioned in the show:

Heather McGowan
Heather’s Website
The Adaptation Advantage by Heather McGowan & Chris Shipley
The Empathy Advantage by Heather McGowan & Chris Shipley
The UpSwing by Robert Putnam
Agile Training for Teams & Leaders
Subscribe to the Agile Mentors Podcast
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Heather McGowan is a leading strategist and keynote speaker on the Future of Work, known for transforming mindsets and organizations with her insights on continuous learning, leadership, and culture. Her groundbreaking approach has empowered employees, enhanced leaders' effectiveness through empathy, and driven businesses to achieve their goals in a rapidly evolving market.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back with you for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today we have someone I'm very, very excited to have on. She was the keynote speaker that kicked off our Scrum Gathering in New Orleans this year. It's Ms. Heather McGowan. So welcome in, Heather.

Heather (00:20)
Hey there, thanks so much for having

Brian (00:23)
I'm so excited to have Heather in. If you're not familiar with Heather's work, she has, think, the best job title I think I've ever heard. She is the future of work strategist. And like I said, that's awesome. I love that. But beyond that, there's a lot that I could say about Heather to introduce her to you. But I'll give you a couple of things just so you kind of understand the perspective of her coming home. First, She was named one of the top 50 female futurists by Forbes. So let that sink in. She also has two incredible books out there. One called The Adaptation Advantage. has more than two books, two recent books. The Adaptation Advantage, Let Go, Learn Fast, and Thrive in the Future of Work. That's one. And her latest one that just came out recently, it's called The Empathy Advantage. leading the empowered workforce. And I'm very, excited to have her on because her talk at the Scrum Gathering really captured my imagination. And I think everyone's imagination there. so let's just dive in, Heather. Let's talk about this whole concept of the future of work. And I think one of the ways you started in the presentation, I think, was really important to try to understand where we are on the timeline of the work. the way we have progressed through ways of working. So where are we? Where would you put us on the timeline?

Heather (01:57)
Yeah, so first of all, the title, Future Work Strategist, was not something I applied for. It's a title.

Brian (02:03)
Really? Because I want to fill out that job application.

Heather (02:07)
It's a title I created because I felt like there was a need for many of us to be working in looking at the future work, which is something that will never be done. It often gets conflated with being about where we work or DEI issues, but really it is about those things. But for me, it's about leadership, it's about workforce, it's about learning, it's about adaptation, it's about purpose. It's about adapting right now pretty rapid changes that are not only technological, but societal and cultural and demographic and generational. And we're wrestling with just a lot of change at once. one of the things I say to folks is sometimes I think that the majority of what we're going to be doing in the near term is helping each other adapt. Because we're to have to adapt at a clip we've never had to adapt to before. Prior generations had maybe one paradigm shifting change in a generation. Now we might have three or four.

Brian (03:02)
Yeah.

Heather (03:03)
So in terms of where we are, we had the agricultural era and the industrial era and the information era. Well, we're now in the augmented era. So we're dealing with technology consuming tasks that we do at a faster and faster clip. And a lot of people kind of catastrophize it about technology taking away jobs. We're the only species that would invent things to make ourselves irrelevant. that's how what people, but it doesn't make any sense. What we're really doing is inventing technologies that augment our potential. And it requires us to not only learn and adapt and think about differently about who we are, which is what the adaptation advantage was really about, but how do we relate to each other? How do we get the best out of each other? And that's really what the empathy advantage was about. So we're in the augmented era. Technology is going to continue to come at a faster and faster clip. But it's more important for us to think about how we learn and adapt and how we lean into our uniquely human skills. Because... The technology can provide the answers, but it's up to us to find the questions.

Brian (04:04)
That's awesome. Yeah. I think that's such an excellent point that, you know, just trying to think about the fact that, yes, in previous generations, there may have been one paradigm shifting kind of change that comes through a lifetime in the way that we work. But in our lifetimes, we've dealt with the Internet coming on board and we've dealt with multiple revolutions since then, mobile and AI. And these things happen. it's such a greater clip that it really does shift even even things like COVID changing, a lot of places working from home previously was always in the office. It seems like change is the constant now and that change is kind of the thing that we need to get good at is being adaptive and able to change. Why do you feel like, I'm just kind of curious of your opinion on this, why do feel like we're so resistant as humans to just change in general?

Heather (05:00)
I think we have a fear of obsolescence. then in times like right now, I delve into this sometimes in some of my talks, is we're going through some pretty significant division and polarization. It's really acute in the US, but it's happening all over the world. You look at the elections in France and the UK recently. I think it's important to understand how that happened because a lot of people think that's just social media. And technology did come into play, but if you look back in the US anyway in the 70s and 80s, that's when we started to see a real erosion in our social fabric. We started having fewer people over for dinner and being part of fewer fewer clubs, talking to our neighbors less. So we got more and more isolated. And then we had a loneliness epidemic that's been around for at least a decade or so, which, and when you're lonely, your amygdala, the kind of reptilian part of your brain goes into overdrive. So you go into fight or flight mode. So you have a lot of change, isolation, fight or flight mode, and then you throw in social media that kind of catastrophizes things. And we're all in this us versus them mode. And we've stopped seeing, hearing each other. And one of my messages in almost all my talks is we have so much more in common than we have in difference. They show lots of studies from it. So if we just could start talking to each other again, we may not vote for the same candidate. We don't vote for the same teams, but we both love the sport. And that's what we need to get back to is understanding how much we have in common because so much of the work we're going to be doing, especially when technology comes in, is communication, collaboration, exploration. And all of those things require us to relate to each other because you're going to see something that I don't see. And if I only hired people who think like me, it would be tragic because I wouldn't see the entirety of the opportunity. So if you want to really drive profitable growth in your company, you want those diversities of inputs and you want to set a culture that has people see and hear each other so you can see optimally the opportunity space. And because that's what we're going to be doing. It's most of the work we're going be doing.

Brian (06:55)
Yeah, yeah, this is a fascinating fact to me because I, one of the things I start in your presentation is just this idea about loneliness. And I absolutely agree. You know, there's, I think we all can kind of recognize that even though we've tried to create these social media companies that to try to, you know, get a, gain a stronger sense of connection in some ways it's driven the opposite of this sort of loneliness factor. But I'm curious from from some sort of a sociological perspective, that has, it seems, transferred into our workplace. And I know one of your stats there was about how we feel more lonely at work. And I'm just curious, what do you think is driving that, the kind of sense of loneliness that we have while at

Heather (07:48)
Yeah, know, some folks will point that to being about where we work. That's not my area of expertise. There plenty of people who look at where we work. That may be a factor for some folks if you're working remotely and you don't see other people, certainly a factor. But what I think what's really happening is we've outsized what work is in our lives. So community used to consist of social interactions, religious affiliations. clubs and groups we belong to, all of those kind of, if you think of them as circles, because everything's visual to me, all those circles shrank and work became bigger. So now part of it's generational change, but more and more people are looking for work to provide their purpose, work to provide most of their relationships, work to fill these. So it's a little bit in terms of how we're interacting with each other that's causing the loneliness, but it's also an outsize expectation we have around work. So now it becomes table stakes for a lot of organizations for work to be my self -expression, work to be my sense of purpose, work to be where I think about my values. And it wasn't like that a few decades ago.

Brian (08:49)
Yeah. Yeah, that's, I just, I love that point. think you're absolutely hitting the nail on the head with that. And, and, know, just so everyone listening doesn't, doesn't misinterpret this in any way, you know, we're not, we're not saying in any way that those other kinds of organizations like churches or community groups or anything are bad or that you shouldn't see community and those kinds of things. It's just that our society has sort of moved away from those as being the foundational, places where we get community and you're I absolutely agree. is, work has sort of filled that. Sort of analogous, I think, to the way that police have become the front line of our mental health,

Heather (09:27)
Mental health, yeah, exactly. Exactly, and that's not fair to the police and they're not prepared to do that and, you know, we suffer. I think the point with work is that that is where we are. So if you're leading an organization today, that is a reality. I hope that changes. I'm a big fan of Robert Putnam. He wrote Bullying Alone in the late 90s and he pointed out the sort of phrase we're having in ourselves, of fabric. He had another book that came out in, I think it was 2020 or 2021, in the middle of pandemic where he... which was called the upswing, where he says we go through these kind of, you you think about it like a pendulum, we go through periods of high collectivism, you know, the kind of the eye to the we. And we're at the highest, you know, the lowest level of the we and the highest level of the eye in terms of being isolated and all that we do. And we're primed to go back into a we phase. So I'll be interested to see what forms of community start to emerge because we're primed to have that happen. Soon, like I notice is a, live most of the time in Florida, part of the time in Massachusetts. It's a restaurant I go to in Florida. And I was like, why do we love that restaurant so much? I do like the food. It's very good. But it has a situation that an empty seat is is a, is anywhere you could sit. So if I come in by myself or with one other person, they would sit me at the table with one other person or two or 300 people. It's community seating. So you end up sitting with people that you don't know having conversations. It's kind of like a forced community. It's fantastic.

Brian (10:53)
Yeah, that's awesome. I love that. I mean, I will say, you know, the introvert part of me is like, I don't want to sit down. Right. Yeah. I identify with that. Yeah. Awesome. Well, so if we have this problem, right, we're dealing with, with a fear of change. We're dealing with a work in place that is lonelier than it's ever been. And we were dealing with a population that's seeking belongings, sinking.

Heather (10:59)
I'm an introvert too, but when I'm forced, it's good for me.

Brian (11:23)
connection and community while at work. I think you're right that that has a profound impact on the way we work even. And I know you talked a little bit about just kind of the main drivers of productivity, the main drivers of being successful. And I think that this is maybe counterintuitive to what some people think. Help us, talk us through that a little bit about what you found as far as what really drives productivity.

Heather (11:58)
Sure, so just to give you a little background on me that relates to this point. So I spent the last, prior to when I started speaking full time, which is about 10 years ago, I spent 10 to 15 years working on the corporate side, industrial design, product design, design strategy, so new innovation stuff. And every organization I went into, I felt people really weren't equipped. to propositionally think. They could reiterate on the existing solutions. If they had a product, they could make another version of that product, but they couldn't jump entirely to a white space and think of something where we didn't have a contextual reference. And then I found myself working in higher ed because I had a mentor who became president of university and he said, I want to create a new college focused on innovation. And I think you understand it better than anybody else. So I built a new college focused on innovation. From those two sides, I saw the supply and the demand side of talent. And what I saw happening, and this is what kind of led to my speaking career, is we're not preparing people to do the kind of work we need people to do. We're hiring people based on past skills and experience degrees. We've now like edged all the way up to skills -based hiring. But what that really is, is hiring somebody who can demonstrate that they can do something you need them to do. What happens when they get there three or four months later and you need them to do something that's never been done before? So we need to prepare more people to do work that's never been done before. And how do you do that? I think you look more at behaviors. And then how do you activate those behaviors? So what you look for in people is some level of skill, but also behaviors that will tell you what they'll do when they don't know what to do. And that is basically what culture is. Culture is collective behaviors. So that's how you screen for people. And then how do you set the conditions to activate those behaviors? What we've done in the past is hire the skills and exert some hustle culture. And that's going to rev the engine of productivity. We did that until we hit burnout and we're still hitting burnout and we're still hitting burnout and unhappiness and disengagement. So we went from hustle culture to going, we need more engagement. we need shared purpose. we need psychological safety. Well, what's behind all of that is we need humans who feel seen and heard. Somebody cares about me. I trust my leader. You set those conditions to people who have agency and they'll activate those behaviors for which you hired them. And so they have some of the skills you need. They're going to have to acquire so many more because you don't know the work they're going to be doing. So we got to focus on what I say is culture and then people who want to build their capacity.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Heather (26:53)
Sure.

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

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

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

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

#110: Overcoming Organizational Dysfunctions with Lucy O’Keefe

7 augusti 2024 | 28 min

Explore the hidden barriers to successful Scrum adoption as Brian Milner and Lucy O'Keefe dive into organizational dysfunctions and cultural impediments in this insightful episode of the Agile Mentors Podcast.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner sits down with Lucy O’Keefe to unpack the organizational dysfunctions highlighted in their talk at the Scrum Gathering.

They delve into how culture can significantly hinder Scrum adoption and discuss other common impediments like resistance to change, command and control leadership, and siloed teams. Emphasizing the importance of transparency, inspection, and adaptation, Brian and Lucy offer actionable insights to help organizations overcome these challenges.

Listeners will also learn why leadership understanding and stakeholder participation are crucial for successful Agile adoption and the necessity of training in Agile values and principles for true organizational change.

References and resources mentioned in the show:

Lucy O’Keefe
Dart Frog Consulting
Path to CTC - Monthly Cohorts
#109 Leadership and Culture in DevOps with Claire Clark
Agile for Leaders
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Lucy O'Keefe has over 28 years of IT experience and has worn multiple hats in the Agile world - developer, Product Owner, Scrum Master, and now, Certified Scrum Trainer® (CST) where she uses her experience to ensure each student has a great training experience.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner, and we have a favorite back with us today. We have Ms. Lucy O 'Keefe with us. Welcome in Lucy.

Lucy O'Keefe (00:12)
Thank you so much, Brian. Happy to be here again.

Brian (00:14)
Very happy to have Lucy back with us. Lucy and I saw each other recently. Actually, I think it was the first time we saw each other in person, right? Yeah. We finally saw each other in person at the Scrum Gathering that took place recently in New Orleans. And I had the pleasure of getting to see Lucy's talk that she had there at the Scrum Gathering. And...

Lucy O'Keefe (00:22)
It was the first time, yep. Finally.

Brian (00:41)
She gave a talk with Joe Miller called, Scrum Unmasked, Unveiling the Dysfunctions Within Our Organizations. And I thought it would be a good opportunity to bring Lucy back and talk a little bit about this topic, because this is an important topic. And it was a packed room, it was full of people that wanted to know about this as well. So I thought it'd be a good chance for us to share this with the audience. But to start this, actually, before I even begin, I get ahead of myself. myself here a little bit. For those who maybe haven't heard Lucy on the podcast before, Lucy is a CST. She has a CTC. Her company is called Dart Frog Consulting. And she also has started recently this mentoring program with a new smally that is kind of a really interesting concept. It's a CTC mentoring cohort. So if that's something you're interested in, We'll put links into our show notes that you can get in contact with her about that. But if you're interested in pursuing certified team coach certification with the Scrum Alliance, that's a really great way to do that. You get a group of people around it and kind of go on that journey together. But let's talk about this topic. And I thought a good way to start was actually to be a little bit meta about this. I want to go behind the scenes a little bit. and think about where this topic came from, what's the genesis of where this came from and how you and Joe hooked up on this. So give us a little bit of the backstory of where this idea came from.

Lucy O'Keefe (02:20)
So to start, Joe and I have worked together. We worked at a consulting firm together. And funny enough, we actually were both speakers at a virtual conference a few years ago. He was on the panel and I was an actual speaker, but we never met. Back then we met actually when we started working in the same consulting firm. And of course I left the consulting firm a few years ago to go independent, but we just kept in touch and we always wanted to do something together. so when, when I was trying to figure out topics for the scrum gathering in New Orleans, I reached out to him and I asked if he would want to do a talk with me. A lot of times it's much easier to do it with somebody else. And I thought it would be fun because he and I see eye to eye on a lot of stuff. And I think we, we complement each other pretty well. But when we were talking about what topics we'd want to talk about, I kind of always go back to the things that I've experienced when I've been in organizations. And I think, I think a lot of us have experienced kind of something, something similar where people are going to say, scrum just doesn't work for us. Right. I actually, it was actually one of my first blogs that I wrote probably six, seven years ago was about that, about people saying, it just doesn't work for us. There, you know, it's not something that we can do. So I kind of got this idea that this is what we should be talking about. And I always go back to. Ken Trebers quote, and I said this during the talk, you may recall, you know, scrum is like your mother -in -law, it points out all your faults. So this idea that scrum is holding up this mirror, you know, to the organization is something that I always talk about. And I think it's important for scrum masters and others in organizations to understand that, no, it's not scrum that's the issue. It's that we have all this stuff that's not, going well in our organizations and we're just putting Scrum on top of it without fixing the issues, right? So we're trying to put a band -aid on what's going on in our organization instead of looking at the root cause. So I just thought that that would be a great topic to talk about.

Brian (04:27)
I love that. And I think that's a great way to look at it because you're right. It's not something that's going to fix everything, but it does make it very revealing. I remember the phrase I've always heard people use is it's not a silver bullet, it's a silver mirror. You know, like it's going to reflect back very honestly to you what's going on. Awesome. Well, that's that. Thank you for the backstory. I really appreciate that because I know a lot of people, you know, if you're listening to this, you may be considering, you know, do I want to submit and try to speak at a conference? So.

Lucy O'Keefe (04:41)
Yep.

Brian (04:57)
just to give a little background to where those kind of ideas come from. I thought that would be interesting little sideline there. So let's get into our topic. Let's talk about some of these dysfunctions because I know the main point of this was talking about organizational dysfunctions, kind of some common problem. So hit us up. Give us a few of these big organizational dysfunctions that you guys talked about.

Lucy O'Keefe (05:22)
So I think the main one and one that's probably going to resonate with a lot of people is culture. For me, culture is always the biggest issue. People are the biggest issue, right? You know, as you know, you probably remember this, right? In the previous Scrum guide, it would say, Scrum is simple to understand, but difficult to master, right? Or difficult to implement because it involves people. So culture is the biggest issue and culture encompasses... quite a few things, right? It could be resistance to change within an organization. It could be a lack of empowerment. It could be command and control, which I'm sure you've seen in plenty of organizations. I've seen plenty of organizations, even though we know that we are hiring the best people, a lot of leaders or managers actually I'll call them, you know, still want to be in control, still want to be the people telling people what to do. And it's very hard to go to... to a way of working where it's like, okay, I need to remove myself from the equation and trust that these people are gonna do what they should be doing. So I think culture encompasses a lot of the other things that we talk about when we're talking about organizational impediments. Another thing is organizational structure. Are we highly hierarchical? Are we a matrixed organization? Do we still have these silo teams, right? That work on just specific skills? And I'm sure you've seen this. I'm sure you've worked in waterfall just like I have in the past, right? You have your business analysts on one side. You have your designers on another side and then your developers and then your testers, right? And they're all reporting into a business analyst or tester or developer or anything like that. So there is no cohesive team that has one. focus or one objective. You know, we're matric, you know, getting these people out of that matrix and putting them into a team. But they're all just interested in their own thing, right? It's a very siloed way of working. So it's very hard to make that transition into, okay, we are a product team and we work together. And we have to be dedicated and stable. Because we're not used to seeing that in a lot of organizations, people are not dedicated to teams. And we're talking about waterfall. I have barely seen any of that. I used to have a team where, and there was already a scrum team, but we had three BAs on the team and they were each 33%. And that's something that is very normal. And even when I'm teaching my classes and I'm sure you have the same questions or comments, a lot of people are like, well, this is very hard for us because we have John Doe here who, you know, he's in five different teams. How is he going to go to all these events? So that's definitely another organizational impediment, which for me kind of goes back to culture as well. Right? So those things are big things. Leadership not understanding. Yeah, sorry. Yeah, no, go ahead.

Brian (08:10)
Yes. Yeah. I was thinking, I was thinking, sorry, I didn't mean to interrupt you, but I was just, I was thinking the same thing that when you said that, that just, yeah, it is very, the hierarchy of the organization is very cultural. And if you, you know, if we're, we're trying to empower teams and instill in them this idea that, Hey, you need to, in order to move fast, you've got to have autonomy and you've got to have the ability to go and make decisions. that's, that's very. much ingrained in how we structure our organization. If I have to get approval for everything I do, that's going to run counter to what we're trying to do in a Scrum environment. So I love that you made that connection. I absolutely agree with you. It's a very cultural thing.

Lucy O'Keefe (08:59)
It is, it is. Yeah. And as I said before, I think a lot of the impediments we see go back to culture, leadership, understanding leadership participation, a lot of organizations when they're thinking about agile, they're thinking about scrum. It's like, okay, the teams need to do that. All right. Let's, let's start in IT and our IT teams are going to start doing scrum and who cares about the rest of the organization. We're going to keep thinking the way that, that we've always been thinking. We're going to keep budgeting the way we've always budgeted. And then we have. We have a lot more resistance, a lot more conflict because we have a team that's trying to work in a certain way. And then you have stakeholders and leadership that are expecting things to be the way that they always were. So stakeholder participation, for example, you know, a lot of stakeholders are going to be like, well, I already told you what I want. Why are you coming to me every two weeks or, you know, however long our sprints are, you know, for to get feedback. You know what I want. I shouldn't have to talk to you about it. Right. So there's that lack of understanding of what's in it for them. So back to culture again, right, understanding that this is a whole cultural shift. It's not just a team shift. So leadership needs to understand that. And of course, as you know, you know, we have, you know, certified agile leadership programs that I'm trying not trying to do a plug here for those classes. I don't even teach them. But.

Brian (10:03)
Yeah. Ha ha ha.

Lucy O'Keefe (10:22)
it's so important that leadership understands what it means to be an agile organization and what it means to lead in an agile organization. And I think when they do that, when they're able to get that understanding, it's going to make it a lot easier for everybody to succeed. So once again, that is another big impediment that I've seen is the lack of leadership and stakeholder understanding.

Brian (10:46)
Yeah, absolutely agree. I mean, it's almost like the concept seems to be more, like you said, we'll start from the team and build up when really it should be more of a from a top down or even not even kind of whole, right. Right, it's kind of, it's a whole organization thing. And if we try to compartmentalize it and say, no, we're just gonna do this group.

Lucy O'Keefe (10:57)
up and down. Or even from both extremes and meet in the middle. Right? Yeah.

Brian (11:13)
then we're already kind of setting ourselves up to fail a little bit because I can't change the culture of just one segment of my organization. If I do that and they have a different culture than the rest of the organization, then we have cultures at odds with each other and they're set to fail. The more dominant one's gonna overtake the lesser one, which is usually gonna be the scrum side of things. So yeah, I completely agree. Yeah, yeah, frustration.

Lucy O'Keefe (11:37)
Exactly. Yeah. And it causes a lot of frustration. Yeah. It causes a lot of frustration for the team. Right. So I was actually at a, I was contracting at an agricultural manufacturing company. I may have brought this up before, but like the, the stakeholders didn't understand why they had to come to sprint and review, why, why they had to talk to the product owner instead of just talking to the engineers themselves. And it wasn't until I had. the lunch and learn with the stakeholders and help them understand what's in it for them because that's what's so important. How am I going to, how is it going to improve things for me if I abide by what you're trying to do? It wasn't until we did that, that they were like, I understand now why I need to talk to the product owner. I understand now why I shouldn't be dealing with the developers or the engineers themselves. I understand now why my feedback's needed. Yeah, it's great that now I have a say in the process. I have a say in the outcome. So it's not like people are trying to just be difficult. They just don't know any better, which brings us to one of the other organizational impediments, which is lack of training and understanding. Cause we can't just train the team. We have to, yeah, I mean, we don't have to train everyone in, you know, a CSM or anything like that. That's, that's not it. Right. But they need to understand the basics of how, how agile works. What are the values? What are the principles? What, what are the benefits of working in this manner? Right. It's, it's not about doing the thing, but it's how is this going to impact who is and how, how are things going to be better after you start working this way?

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

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

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

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

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

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

Brian (16:02)
Sure. Yeah.

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

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

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

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

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

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

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

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

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

Brian (20:37)
Ha ha ha.

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

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

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

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

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

Brian (23:22)
Hahaha.

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

Brian (24:28)
Yeah.

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

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

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

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

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

Brian (25:47)
Yeah.

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

Brian (26:19)
Ha ha. Awesome.

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

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

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

#109: Leadership and Culture in DevOps with Claire Clark

31 juli 2024 | 30 min

Join Brian as he chats with DevOps expert Claire Clark about the cultural and mindset shifts needed for successful DevOps adoption, the concept of 'shift left,' and the crucial role of leadership support.

Overview

In this episode of the Agile Mentors Podcast, Brian and Claire Clark, founder of Sienso, winner of the The Great British Business Woman Award, and freelance software development executive, delve into the world of DevOps.

Claire explains that DevOps is far more than just tools and processes—it's about fostering the right mindset and cultural shifts within the team. They discuss the 'shift left' approach, emphasizing the importance of considering end stages of software development early on.

Claire highlights the critical role of leadership in supporting DevOps principles and aligning team goals. She also shares strategies for measuring success through a maturity matrix and underscores the importance of continuous improvement. This conversation provides a holistic view of DevOps, integrating both technical and cultural aspects.

References and resources mentioned in the show:

Claire Clark
Sienso
#108 Adaptive Organizations with Ken Rickard
Mountain Goat Software’s Working on a Scrum Team
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Claire Clark is a multi-award-winning transformational leader and Chartered Engineer with over 20 years of experience in Software Engineering. Specializing in leading high-performing teams, Agile transformation, and DevOps, Claire has successfully managed complex projects across various industries, including cybersecurity, logistics, and financial services.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast. And today we have a very special guest with us, someone I've been trying to get on for a while. We have Ms. Claire Clark with us. Welcome in, Claire. Glad you're here. Claire has been in our world for a while here at Mountain Goat. And she's had lots of interactions with us and Mike and over the years.

Claire Clark (00:13)
Hi, hi, good to meet you.

Brian (00:29)
And just for people who aren't familiar with Claire and her work, she is, I guess the best way to describe it is kind of a freelance software development executive. She kind of comes in in high level, kind of more temporary positions, would you say, Claire? Okay. Yeah, kind of coming in on the spot positions to help get people over the hump and get them situated and set up the way they need to be from an executive level.

Claire Clark (00:44)
Yeah. Yeah.

Brian (00:56)
Her company is called Cienso and she's won numerous awards over the years, but most recently she had a really huge honor. She was the winner in the engineering category of the Great British Businesswoman Awards. So first of all, congratulations on that. That's awesome. And the reason that we wanted to have Claire on was...

Claire Clark (01:15)
Thank you.

Brian (01:22)
just to share a little bit of her knowledge with us, and particularly the area of DevOps. She's done a lot of work with teams and building the teams. And we've had some really interesting discussions offline about this area. So let's start and just set the table a little bit here, Claire, for everyone. When we're talking about DevOps, first of all, let's just kind of explain what that means for people who aren't familiar with it.

Claire Clark (01:47)
Yeah. So I tend to describe it as it's a way that teams collaborate for the continuous delivery of a product from end to end, to get the value of the product to a customer. So it, it's not a specific process, a specific tool. It's a little bit around the mindset and approach to things. And how you get that continuous development and delivery of a software product, for example, to a customer. So yeah, I think people often tend to see it as possibly it's a tool thing or it's a process thing. And it's not quite that, it's all elements of that and a mindset side of it as well.

Brian (02:42)
Awesome. Yeah. That was the thing that I found really interesting in our conversation. And some of the things I've seen you write about this online, it's just the concept here that DevOps is really kind of a mindset. It's kind of a cultural thing. It's kind of culture first. And a lot of times we think of this as a set of practices. So let's get into that a little bit. How does the adoption of DevOps kind of change the culture?

Claire Clark (03:03)
Yeah.

Brian (03:11)
in an organization.

Claire Clark (03:12)
Yeah, I think in terms of changing the culture, it taps quite a lot into the agile side of culture, I guess, in that it promotes that collaboration and the continuous delivery of an integration of software, of a software product to a customer. So what I found is that, for example, with agile, That brought together a big collaboration with development and test and your product function. And then the DevOps kind of movement, I'll call it, sort of come to life a bit more. And that's where it then changed the culture again in terms of extending, I guess, the kind of agile side of things, but embedding the continuous integration and delivery into what the software engineering team does. So the operational aspects of the software. become more forefront into the, into like the team's thinking. They become like shift left. Do you think about this earlier? How are you going to maintain and deploy systems and how are they going to integrate? And I think that's where it's really shifted the culture quite a lot where instead of it being the, you know, we create, create the software and now there's an operational aspect of how we then deploy and integrate some of the dev op development and test aspects. into that. So I feel like it's really got into the mind, a lot of people's minds that we need to think of the full end to end when we're talking about building and delivering a product. It's everything and it's how you can make that pipeline that chain through that development team more of a continuous approach. So teams that have succeeded with Agile tend to be able to approach. embedding that DevOps mindset that bit more because there's a lot of overlap between some of the principles and the mindset needed between the two. So.

Brian (05:16)
Yeah, no, I absolutely agree. And you mentioned a term there that I've always loved in the DevOps community. And just in case people there aren't familiar with it, when you talk about shift left, what does that mean to you? What do you mean by shift left?

Claire Clark (05:32)
So for me, it means if you took a typical software development lifecycle and there's requirements, development and test and so on, it's very sequential and it typically follows the order. And what the mindset brings with DevOps and shift left, and you see this a lot with testing the term shift left is think about the latter stages up front. So the more you can think about some of those end, stages of software development and deployment and integration to customer systems, the more you think about them upfront, the more you start to design the way of working in what you're doing through agile and your continuous approaches, you start to embed that earlier. So it becomes a thought right at the front instead of being an add -on at the end. So shift left in essence being... what normally you would have done in a sequential manner and ends up far down the chain, you start trying to identify how could we do, how could we bring this earlier? What, you know, you start thinking about earlier, start looking at the practices and tooling and all those processes that people are doing in the software team. You start then to identify that can change the test, your test and your design. That can change then what you've. product functionality and non -functional requirements need to be. It's always about making sure that them later stages, what traditionally were later, are thought about upfront at the start, designed, planned in, and continuous efforts all the way along the software development lifecycle to embed them. So it becomes an easier stream from end to end and more automated and more, I guess, more constant flow through the system. So yeah, shift left is think about the end at the start as much as you can.

Brian (07:37)
I love that. Think about the end of the start. Yeah, that's a great way to phrase it. I love that. So when you we've talked about kind of the mindset behind this, the culture behind it. So when you when you come in and work with a new group, do you start with kind of a more culture approach and work on mindset first or you kind of go right into practices and let it kind of flow along the way? How do you approach that kind of shift when you start to work with a new New team.

Claire Clark (08:07)
Yeah, it's interesting because it's the balance because when you're introducing any of these practices, it means typically it would mean there's some form of change for a team and change itself is difficult for people to go through at times. And in terms of embedding some of the success of the frameworks and the processes, you can only really succeed if people are coming at that with the right mindset. because otherwise you can get people who say, I don't want to change. I don't understand why I need to change. So you can explain the kind of value in why to do some of these things. But fundamentally, what underpins that in all of this is a mindset. And in Agile, I've talked before on some presentations about how important an Agile mindset is. So being able to sort of... accept that, you know, change will happen, you know, change is the only constant that happens and the more that people can start to understand, I guess, appreciate that and then come up a new thing, a new challenge, start coming at that with how can I make that work and it's then subtleties that if you don't challenge the two together,

Brian (09:11)
Right.

Claire Clark (09:34)
you won't succeed in getting the benefits from Agile and DevOps. You could have the best processes in the world, but if the mindset's not there, you're never going to reap the benefits of what you're trying to achieve. So I try to work with teams on both fronts at the same time, because like I say, you can have the right mindset, but they might not understand the process or the right process. If the mindset's not there, the implementation won't come to fruition.

Brian (10:02)
Yeah, we actually just had another episode that was, I think it was our last episode actually, looking at the order of this. But when we were talking, we were talking with Ken Ricard about the overlap between change groups and the lean change overlapping with Agile and how really that ability to shift and adjust and change is really at the central core of it. What other kind of key cultural shifts do you feel like are necessary when a group starts to adopt DevOps practices that they really need to get a handle on?

Claire Clark (10:43)
Yeah, I found that some teams really struggle with the concept of the shift left side of it. So it tends to be, we've always done it this way. And because it's become second nature to do certain aspects, you know, certain aspects of the software delivery and development in a certain manner, that trying to open up people's minds to say there is another way and it's different.

Brian (10:52)
Yeah.

Claire Clark (11:13)
And it will feel different, but you've got to be open to trying that. And here's why. So I think the cultural side of it is I still see at times some teams that are really focused on DevOps tooling. And it's, I think the mind set shift, the cultural shift is it's not, that's a part of it. Part of DevOps is the tooling you have to do that. And same as when people struggled on the agile journey initially is, you know, thinking agile was, you know, user stories and Jira and yeah, Jira and things like that. And that's, that's a tool that facilitates you to work in that way. But having a tool like that, a Camman board it or so on, doesn't make you agile. And it is that.

Brian (11:50)
Sure. Right. Right.

Claire Clark (12:08)
It's that same thing with DevOps. There's some brilliant tools out there now and we are getting that shift left approach and using them tools to integrate at different stages of the software development more of the operational aspects and getting that continuous integration. But I think with Agile, people, a lot of teams have gone over time now and through the great work like what Mike does, helping people understand how to. to really come on board and get the best out of an agile way of working. It feels like with DevOps, we're in a similar spot where some people have really got it. They get that mindset, they live and breathe the kind of DevOps side of it. But there are still a lot of teams that you come across and DevOps is still a tool. It's still a thing. And maybe they get that tool in place and hey, presto, we're DevOps. And it's like... Some of the subtleties that you don't see, it's not in a process, it's not in a tool. That behavior and that mindset is what I think there's still a bit more of a journey to go on across the industry with that DevOps side of it. It just feels so similar to when Agile sort of come out and the challenges people were facing there and what we believed Agile is and what Agile really is.

Brian (13:29)
Yeah, that's a great analogy. I love thinking about it that way. I mean, it's like if you have a boat that's in a garage, you can get in the boat, you can turn it on, you've got a fantastic tool, but if you don't ever put it in the water, it's not going to really live up to its purpose. And that's kind of the way people, I think, sometimes look at some of these tools is, well, we got the tool, so we're sailors now, right? We can... We know how to drive our boat because we have a boat. No, you got to put it in the water, right? You got to actually know where to use it.

Claire Clark (14:01)
Yeah. Yeah. Yeah. One example I always think of is it's a bit like having a scenario where there's a driver and there's a really fancy, you know, car, but it's got no engine. So you can have all of these elements and you could say, I'm a racing car driver, I've got this really fancy car.

Brian (14:18)
Mmm.

Claire Clark (14:25)
It looks great and you know, it's got all the features on it and all of the buttons you can press, but, but underneath the core of that is the engine. And I liken it to like with Agile and DevOps, the core underneath this is the mindset. And it's that, it's that hearts and minds of the principles behind DevOps principles behind Agile that if people buy into that, the rest is a bit easier to implement. But often people can have tooling shoved at them or a nice fancy car in that scenario. But it doesn't come with the fundamental, the heartbeat, so to speak, inside that really embraces the principles behind some of these things. And it's that where the cultural side comes in that people really do not just read the words and say collaboration. They act it. They do it. They...

Brian (14:54)
Yeah.

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

Brian (16:08)
Yeah.

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

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

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

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

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

Brian (19:18)
It's Jenkins.

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

Brian (21:26)
Yeah.

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

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

Claire Clark (23:26)
Yeah. Yeah.

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

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

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

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

Brian (29:52)
Yeah.

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

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

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

#108: Adaptive Organizations with Ken Rickard

24 juli 2024 | 20 min

Join Brian and Ken Rickard as they delve into why agile transformations get stuck and uncover strategies for creating adaptive, resilient organizations and people.

Overview

In this episode, Brian sits down with coach, author, and Lean Change agent, Ken Rickard to explore the common pitfalls of agile transformations and the commodification of agile practices.

Ken emphasizes the need to focus on people rather than processes and introduces the art of change, which includes self-awareness and adaptability. And shares the six big ideas of adaptive organizations, such as sense-making strategies and leadership agility.

Tune in to learn how to navigate transformation challenges and create an environment that fosters resilience and adaptability.

References and resources mentioned in the show:

Ken Rickard
Insight
The Six Big Ideas of Adaptive Organizations: From Frameworks to Sensemaking by Ken Rickard and Jason Little
Agile Manifesto For Software Development
Lean Change
Mountain Goat Software’s Agile for Leaders Training
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Ken Rickard is a spark for transformative good — a change alchemist, deep thinker, and a catalyst for personal growth and organizational evolution. With over 15 years in the agile community, he's honed the art of navigating change and embracing adaptation as the true essence of agility.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have a really special guest with us. I have Mr. Ken Ricard with us. Welcome in, Ken.

Ken Rickard (00:12)
Thank you. Nice to be here.

Brian (00:14)
Glad to have Ken here with us. Ken recently spoke at the the global Scrum Gathering, in New Orleans that I was at as well and had a really interesting, actually had a workshop slot there for a workshop titled Humans Agile and Change, How to Get Your Transformation Unstuck. And wanted to have Ken on to kind of talk through that a little bit. But before we do, for those people who aren't familiar with Ken, let me give you a little bit of an introduction here. Ken is an enterprise coach and change alchemist. I love that. At a company called Insight, he co -authored a book called The Six Big Ideas of Adaptive Organizations, which I know we're going to get into here in this conversation. He's a licensed facilitator of Lean Change. He's an IC Agile authorized instructor. So he's got just a load of credentials and a load of experience to bring to the table here with this. So Ken, let's get into this. Let's talk about humans agile and change and how to get transformations unstuck. What do you think is the main cause of transformations getting stuck?

Ken Rickard (01:31)
Yeah. So I think, you know, we're all feeling the effects of the high of agile. And I think now we're, we're starting to come down a little bit in the industry. I think everyone's feeling that effect. I mean, I see so many agile coaches on LinkedIn that are still looking for roles and whatnot, scrum masters, you know, a good bit of that, though, I think it's a blowback from the industry and just companies in general who, when they need to tighten the belt, they're actually beginning to look at the roles they've got and figure out which ones that they can do without for now. Or maybe they can do with roles they've already got. And so the effect of that, I think is coming from this idea that, you know, the agile industry, let's even narrow that a little bit more and talk about scrum specifically, has really kind of in the industry has become commodified around this idea that it's a process. And that we just like, we used to do this thing over here and we can just go to the shelf and purchase like scrum in a way. And then like. take that and just drop it into the spot and the practices we used to do. And so when it was only viewed as a process replacement for what they're doing now, it's very easy when, things get rough or tough in the industry as they've been over the past year, year and a half, two years, that our natural, you know, kind of inclination is to kind of hunker down and that hunkering down is to go back to what's comfortable to us, which is typically non -agile, non edge. things because that edge is actually kind of uncomfortable. And so we want to kind of go back and go back into our hole and actually like do the things that we're most comfortable with as an organization or as leaders. And so, yeah, I think that's been kind of what's been happening. And it's just, you know, the follow up from that, I think it's just now hitting the industry, I think in the current times now.

Brian (03:10)
Yeah. Yeah, I agree. I mean, you talk about it being a commodity and I can definitely see that across the different organizations that do certifications with this, and we're both trainers, we both do trainings. The hard part for me as a trainer is that I don't wanna... discourage people from getting training because I think the training is an important step, right? I think it's you know, you got to know the basics before you can play a sport and You know, if this is the team sport, but it's it's so much easier for me to tell someone all right Well, there's these roles these events and these artifacts

Ken Rickard (03:49)
Mm -hmm.

Brian (04:05)
and they can just go, you know, start putting it into their schedule. Here's the events we're going to do, and we have these meetings at this time. It's easy to do that, but it's hard to say, all right, what is openness? And how do we operate in an open environment, you know, or how do we treat each other with respect as we go through this kind of thing? That's hard to train, you know?

Ken Rickard (04:10)
Right. Right. Yeah. Yeah. Yeah. And coming from the, you know, I've spent a three and a half, almost four years now, I think with lean change and Jason little, and, and obviously we co -wrote co -wrote the, the book together, but the, I think the thing that I've learned from all that is, I mean, I want to say that at the beginning, the intention of the folks that created the agile manifesto for software development, their intention was really to help the industry change, but from a software development and probably an adjacent request would have been that the project management kind of behavioral patterns that were there and existing already. They could have actually kind of caused that trajectory to start to shift. And they obviously did over time. I think the one thing, if I had a time machine and I could go back and I could just plant a little seed with those 17 folks, it would be to not look so narrowly at the organization, like just the software development part. Because I think that's what's caused agile and scrum to become that thing that those IT developers do. And it's actually in a way done a disservice, I believe, to the industry at large and then just kind of the trajectory over time and where we kind of landed over these past few years. And it's why with lean change, what I'm trying to do, and I'm not the only one trying to do this. There's a number of folks out there trying to do this as well. But I think Jason and I, what we're trying to do and all the lean change facilitators is to get people to realize. that at the end of the day, everything is really about change. So scrum is just a process. It has all these, like behavioral patterns that come along with it. You're going to need to change, but those things aren't laid out necessarily exactly explicitly in the scrum guide. So you can read through that with your current understanding and your current lens of the world. And you can go, okay, I got this. And okay, all I need to do is go and create a scrum master position and I need a product owner and we need to do these events and then we need to set up these artifacts. And, and that can very easily lead to that kind of mechanical approach to scrum because that's kind of the world they've come from, right? If they've come from kind of project management world where everything is very laid out, very kind of straightforward and linear and then sequentially executed. And I think what we would all probably agree is that what's really missing is that mentality shift and. and the perspective shift. And to get there, we got to really focus on people change. Like, and I don't mean just like, Hey, we're doing a new process. So what do I need to do differently? Or, Hey, we put, we installed this new piece of governance software. So what buttons do I need to push differently? I'm talking about like actual evolution of the individual, their beliefs, their behavioral patterns, and the rituals that match up to those behaviors and beliefs that set underneath them as a person.

Brian (06:52)
Yeah. Yeah.

Ken Rickard (07:14)
And so that's what we're really trying to focus on from Lean Change is we're really trying to help people understand that, that to do those things well, to do things like Scrum well, you really have to focus not just on the process change or the technology change, but actually on the people change. You may even have to focus on structures and strategies as well.

Brian (07:31)
So I'm trying to channel my inner listener and try to think of what they might be asking or thinking about in hearing this. And I mean, what I think about is, all right, well, let's say I'm an organization and I buy an end to all this stuff. And I'm like, yeah, yeah, yeah, we've tried that. We've tried to implement this stuff and it's all about process and we'd rather not do that. We want to do it the right way. Where do you start? How do you start to...

Ken Rickard (07:38)
Yeah. That's it. Yeah.

Brian (08:00)
you come in and just say, hey everybody, we're gonna change how you think and how you, how do you start to get the organization to shift like that?

Ken Rickard (08:06)
Yeah, that's tough. Yeah. Yeah. And I would actually, I would point the finger right back at ourselves first. I mean, this is the journey I've been on for the past five years. You know, I mean, I, I actually talked about this in the session at the global scrum, scrum gathering. I told the crowd there. I was like, like five years ago, Ken, like if anybody challenged anything or didn't understand how scrum worked, I would essentially kind of like,

Brian (08:14)
Ha ha ha.

Ken Rickard (08:34)
just picture this idea of Ken taking them by the arm and leading them over to the Scrum Guide and being like, look, here's what the Scrum Guide says. And that was kind of my go -to thing in a way, variations on that, obviously. But at that time, it was mentality -wise, I was just like, okay, well, we just need to do Scrum. If we just do it well and we do it like it says we're supposed to do it, then it'll fix all the things. And that didn't really get the best response out of it. everyone. You know, it wasn't until I started to shift myself and my own perspective and start to really understand that, okay, I'm not the snake oil salesperson that they probably think I am. I'm actually somebody who's trying to help them change. And so if I look at it from that perspective, now it becomes less about the process or the framework and all the specifics of the framework. And it becomes more about, okay, where are they now?

Brian (09:18)
Yeah.

Ken Rickard (09:29)
What mentality do they have now? What are the attitudes that they have about the things that I would hope to put in front of them? Like, are they, are they like, yeah, this is great. Let's do it. Or are they like, no, I don't know. Not so sure. Or are they like, no, that's a stupidest thing I've ever heard of. Like we would never do that here. so better understanding them as an individual and then being able to better show up in a way that is going to be conducive for them to see the need to change is actually the very first.

Brian (09:42)
Yeah.

Ken Rickard (09:55)
best thing that I ever did in the way that I shifted my own perspective and how I showed up. And then that started to actually unlock them and their ability to actually pay attention and realize how they needed to change. And then therefore the change started to go. It's a much slower route because you can just go take stuff off the shelf and be like, Hey, we need to do it like this. And you probably will get some traction with some folks, but you're probably going to miss a good bit of them too. So.

Brian (10:20)
Well, let me, let me ask you this because this is something I've kind of been wrestling with with some other guests on the podcast as well. It's just this, this concept that, you know, partly, I think what's behind some of the problems with this is, is also the short kind of nature of, of how we view change in organizations. And, you know, we want quick results. We, you know, we have a change initiative to do something and we want to see that, that, that benefit of that change in the next three months.

Ken Rickard (10:42)
Sure.

Brian (10:49)
And all of a sudden things are going to be completely turned around and we're going to do things differently. But that's driven a lot from this short -sighted nature of, you know, we got to increase our profits quarter by quarter. We got to, you know, please our shareholders and they don't have the long vision that we used to have in companies of, you know, 10 years or something.

Ken Rickard (10:54)
Yeah. Yeah. Yeah, I'm going to, I'm going to say something and I'm going to meet it in a completely different way. Planning. Let me explain what I mean by this. all right. And I don't want to make this into the lean change show either, but I'm going to talk about a concept, from lean change real quick. so bear with me, but, so there's this idea that has been created in lean change. It's called, we, we, we refer to it as a big next now. Really what it is is it's like.

Brian (11:17)
Okay? Hahaha.

Ken Rickard (11:42)
Think of like an overarching rainbow at the top of like, Hey, what's the largest, biggest thing we're trying to accomplish? And what's the strategy around that? And if we can define a high level strategy around that, it will help us be, get like an orientation towards what outcomes are trying to seek it at the grandiose level. Let's say it's an agile transformation. All right. Underneath there are like a series of smaller humps that are like, okay, what are the goals we might want to actually achieve? Let's make sure those are really loose. except for the ones that are in the very beginning. Does this sound familiar? I'm basically describing breaking down and iterating incrementally changing the organization, right? So, underneath that you'd have like what's referred to as like the lean change cycle. This idea that we go out and actually look at the organization and get data back on what might need to change instead of actually telling people what needs to change. Like, Hey, we're becoming a scrum team, or this is what scrum is, and this is how it works.

Brian (12:21)
Yeah, yeah.

Ken Rickard (12:41)
well, what if they just start where they are and maybe the first thing I add is like a daily, you know, maybe they don't have any kind of coordination events at all right now. And then their tolerance level to change is just minimal. So, okay. So as a coach or as a less even a scrum master, the first thing I might help them do is to actually just put in some frequency of a regular sink. That could wind up turning into something that we would recognize as a daily scrum or a daily standup, but. In the beginning, maybe they don't have the tolerance to go right directly to the thing. Maybe they'll reject that or resist that. So as, as a coach or as a scrum master who's focused on change and not the process of the framework, I would go in and actually help them figure out what the best changes for them right now. And that's the approach I've been using and it just works. It works pretty well. versus coming in and being like, Hey, here's what scrum is. Here's how it works. Let's go through this training. You know, we got to get all these things set up. We need, here's what perfect looks like.

Brian (13:14)
Yeah.

Ken Rickard (13:39)
guess what we can't get there. So yeah.

Brian (13:43)
Yeah, I mean, as I'm listening to you, I'm thinking, you know, it's a difference of listening versus telling, you know, like there's a, there's kind of a telling mindset of going in for a lot of coaching of, you know, what we would typically frame more as a consulting approach. You know, I have answers. Here's the answers for you. Just do the way that I've always done it and everything will be fine versus let's actually hear what your situation is. And.

Ken Rickard (13:59)
Yeah.

Brian (14:10)
what your needs are and what you're seeing going wrong and how can we address those issues? I love that. Yeah, yeah, exactly.

Ken Rickard (14:14)
Yeah, and experimenting through it and honestly showing up, showing up as, or knowing when to show up in a coaching stance, who is going to be more empathetic and more understanding and not going to give them all the answers and it's going to let them explore and figure it out. And it's going to shine the light in the dark corners of the room versus the consultant stance, which is going to show up in more of an advisory. Hey, If I see you all struggling, I'm going to kind of tell you what to do or show you what to do. And they may not be ready for that. So it's about knowing when to actually do one stance or the other and be able to be very fluid in those things.

Brian (14:47)
Yeah. Yeah, there's a, there's a phrase I'll use often in class when I talk about the coaching kind of mindset to say, you know, what we're trying to do is not build knowledge, but build capability. And if you build the capability, then people can then adapt and change when, when something similar comes along or something in the same realm, they can say, yeah, I remember last time when we had something like this, here's how I responded. So that, that ability, I think to. deal with change like you're saying. And if we have it ingrained in our mindset that, hey, we identify problems, we inspect them and we adapt as we go along, to me, that's so much more important to build into how we do things than it is to know, we got these four meetings or five meetings that we're gonna make sure we hold at a certain time. Awesome. Well, you know, I'd like to hear a little bit because I know, you know, your talk is somewhat loosely based on your book as well. And, you know, with a title like the six big ideas, help us understand. We may not have time for all six, but give us some of these big ideas.

Ken Rickard (16:00)
Yeah. Yeah. Sure. Yeah. Yeah. I'm also still, I think Jason and I are still trying to figure out if, how the word or the phrase big ideas is resonating with folks too, because in the agile community, you know, big, big is not a word that I think people will gravitate to very quickly, but, we're also trying to straddle the fence on the change community and the agile community. Honestly, what we're trying to do is I was joking around and I think we, I'm.

Brian (16:21)
Yeah. Yeah.

Ken Rickard (16:31)
might've wrote this either in the book that's out now or the bigger book that we're working on for later this fall. But I wrote somewhere that really the change community and the agile community should really go on a blind date because they never should have really been two separate communities in my opinion. And I think Jason would hold the same opinions and a lot of our lean change facilitators, I think would hold the same opinions. So yeah, so the book is really about trying to get Agilist to understand that their role is really about change.

Brian (16:47)
Yeah.

Ken Rickard (17:02)
They already know the agile bits and the iterative incremental and all that kind of stuff. And that the change community really needs to better understand the agility community and take some of those practices and apply it to the change. And if both sides do those things, we're going to wind up in the middle and everybody's going to be the same type of person or the same type of thing. Because at the end of the day, getting to agility, like this idea of the characteristics of being nimble and being able to adapt to what's going on with a certain grace and resilience.

Brian (17:25)
Yeah.

Ken Rickard (17:31)
that set of characteristics is really, I think what the agile industry is hoping to go for. And yet a lot of the folks that find these things come to it with their current understanding and they don't really, aren't really looking to change themselves and how they see things, their perspective. And so that's how we get into this commodified kind of off the shelf version of it. And so I think we're just trying to get people to realize that. Look, if you look at these big, these six big ideas, which are really just sense making strategies. At the end of the day, that's what they are. You should be able to sense your way through what your context, your organization, given the changes that are going on. you know, what are those circumstances? How well do you know those circumstances? If you can understand those things in a sense making way, you'll be able to show up in a way that it actually be conducive to help that organization change, no matter what the scope of the changes. Let's say you're a store master. It could be your scope of your change is essentially your team or teams.

Brian (18:25)
Yeah.

Ken Rickard (18:29)
And the product that they're building, let's say you're an agile coach. Okay. Maybe it's somewhat wider than that. I don't know. I'm still on the fence about what the difference between agile coaching and scrum master is. That's another podcast though. I think, or let's say you're somewhere higher up in the organization. So whatever your purview is, whatever your scope is, that context is really what we're trying to do. We're trying to help you and the others around you understand what it is that you're not paying attention to, what it is that you don't understand.

Brian (18:39)
Yeah.

Ken Rickard (18:58)
or that you might think you understand about your organization. So it's really six ideas to help people kind of unravel that about their organization and themselves. Because like, for instance, one of the six big ideas is something that Jason had created quite a long time ago called the four dimensions of change. And what it says is that there's four things that you really probably need to focus on as, as a agent of change. And that is yourself. So like,

Brian (19:07)
Yeah.

Ken Rickard (19:26)
Your set of beliefs about things, you know, how you show up because how you show up actually affects how others receive or perceive you. And then that impacts your ability to influence others and actually help them change. And then it goes on to say there's, the big ideas or strategies that you can deploy from, from a change perspective, typically minimally viable practices, or strategies. And then the last bucket in that four dimensions is, tools and practices. You know, the things that we have the most affinity for and tend to go to first, and kind of ignore the other three things. So it's, so that particular big idea is trying to get people to recognize that, no, there's like a bigger kind of art and science here to helping people change. It's not just about the science, like the strategy and the tools and practices to be good at those things. Most likely you got to focus on the art of change, which is yourself and your stance or how you show up.

Brian (19:59)
Right. Right. Yeah, I'm gonna share one of my geeky subdivisions here in making this quote, but it reminds me of in the musical Hamilton, there's a line in there that George Washington says to Hamilton where he's talking about, you know, Hamilton has these visions of going off and dying like a martyr and George Washington says, dying is easy young man, living is harder. And.

Ken Rickard (20:30)
Yeah. Yeah.

Brian (20:51)
That's kind of how I see this. I'm not saying we're dying or making a choice between dying or not, but I am saying that the practices side of thing, practice is easy young man, culture is harder. It's just harder to try to implement those things. And I think a lot of times, I don't know if it's, I think individually sometimes as coaches we can get lazy.

Ken Rickard (20:55)
Yeah.

Brian (21:18)
and go to the things that's easier to tell people about. But I also think that it's an institutional thing because it's much easier for me to certify somebody or give them a credential saying that, hey, this person knows their stuff when I can test them on facts and figures and how long is that meeting and that sort of stuff versus.

Ken Rickard (21:20)
Mm -hmm. somebody. Yeah. Please.

Brian (21:41)
you know, how do you change the mindset of the culture of the organization when they're really into quick solutions and they're into trying to get things out the door as fast as possible and not focus on quality. It's harder, right? It's just, it's more difficult.

Ken Rickard (21:55)
Yeah. Yeah. Yeah. Yeah. Yeah. You're hitting on one of the other six big ideas right now. Actually two of them, but we can start out with the explain the one. So there's another one that we made called the, the two change strategies of effective organizations. And so what this one says is that there's two ways that you can probably improve or change your organization. And that's a fractal statement in an organization because again, we're only talking about whatever context you have.

Brian (22:06)
Hahaha.

Ken Rickard (22:27)
Cause if you're a SCAR master, we're talking about the context you have of the teams you're working with. Agile coach or something higher up than that, whatever context you have. So, okay. So within your context, you probably have two ways to think about and try to help your organization change. And those two ways are either optimizing what they already do to make it better, faster, cheaper, or evolving the way they think about what they do so that they can actually succeed in ways that they never have before. And I'd be, I'll go out on a limb and say that every, at the very least, every single company I've come across that's doing agile and whatever way they call it, is really trying to do it from the purpose of the optimization, better, faster, cheaper. I think there are very few companies around the world that are actually taking it seriously enough to do the evolution part to actually change the way they think about how they do things in such ways that they're actually elevating. their set of beliefs and behavioral patterns, not just as individuals, sorry, as individuals, but as a collective and then ultimately as an organization. And so it's really trying to get you to, to focus on what is it that we actually are trying to improve? Is it just that we're trying to optimize what we're doing now? Cause that's a take scram off the shelf and just drop it in, you know, or that's send people to training and like come back and be like, cool, you're certified.

Brian (23:33)
Chief.

Ken Rickard (23:49)
But if we don't ask the hard questions around, okay, well, what are you gonna change about your behaviors? Then they're likely not focusing on evolution. And if we're not coaching them through that, yeah, not really going anywhere.

Brian (24:01)
Yeah, do you think organizations just don't know what they don't know? I mean, because I know you're right, they do want better, faster, cheaper. And that's sort of the end goal that they're coming at a lot of this stuff with. They just not recognize that it's really the change capability that they should prioritize.

Ken Rickard (24:05)
It's like. Well, I think it's because they focus. So what's really easy for a lot of organizations to change. There's a, we're going to keep tying these five, sorry, these six big ideas together, I guess, because there's another one called the five levers of change. And what that one is, is a, it's a circle of five things with people being the biggest circle in the center. And then on the four corners of it, it's basically process and technology strategies and structures.

Brian (24:32)
No, that's great.

Ken Rickard (24:48)
And so if we look at that as a systems approach to changing an organization, the reason why it's called the five levers is because they can pull any levers in any combination they want in order to try to change their organization. But the easiest levers to pull are process and technology. So, Hey, let's do scrum and we need to install Jira or Azure DevOps. Right. And that's generally where these kinds of things start because it's within the control of the teams oftentimes to make those changes. It doesn't impact a larger organization to, well, it can, but probably to a lesser extent initially. So the teams have some level of autonomy or local control to start making those changes. They don't run into problems or impediments or just kind of organizational dysfunction until a little bit down the road so they can kick that can down the road. And so I think it's, I think it's that that causes us to gravitate towards a process and then just pull that lever pretty easily. And, and that's an optimization lever. So if you tie those two ideas together, it takes the other side of those five levers, the structure and the strategies, which are all built on beliefs. You know, like if I'm a leader in a hierarchy who's worked 20 years to get to my lofty management position, I'm going to be a lot less likely to take a empathetic kind of delegated approach to my management style because I put in a lot of hard work to get to where I am now. And there's no way you're going to tell me now.

Brian (25:48)
Yeah.

Ken Rickard (26:18)
20 years that I now have to change the way I operate? Like, no, I'm in control here. So I think we're also battling that a little bit too.

Brian (26:20)
Right. Yeah, what I've done got me here. So why would I do something different now? Right?

Ken Rickard (26:32)
Right. Exactly.

Brian (26:34)
Yeah, I've battled that in multiple occasions, for sure. One of the places I worked was a newspaper. And if you want to talk about people not wanting to change their mindsets of, hey, what do you mean that people don't want to have delivery of their newspaper on their front doorstep every day like they've done their whole life? Yeah, it's crazy. Well, this is great stuff. I'm really enjoying this.

Ken Rickard (26:49)
Yeah. Yeah.

Brian (27:03)
Do you have one last big thought, big idea to leave us with here? Because we're almost out of time, but what have we missed in these big ideas?

Ken Rickard (27:13)
Yeah, probably the other big one that comes up a lot. one of the other six that I haven't talked about yet is the, what I call the three agilities. And we'll tend to focus on the delivery agility, which is like, Hey, we, we can help you team better and people better at the team level where you're delivering. And we can help you become more product led. And we can also help you with your technical excellence, you know, like DevOps types things, right?

Brian (27:21)
Okay?

Ken Rickard (27:38)
And I think we could probably draw a circle around those three things and go, you know what, for the vast majority of the agile industry, this is what they think agile is. But in my opinion, that's only one of the agilities an organization needs in order to actually possess the characteristics of agility. And the other two would be change agility. The idea that we are adaptable to the change that we cannot control and that we actually can adapt well in a resilient way to the change we can control within our organization. And that we're constantly evolving to get better at that so that we can sustain change in a graceful way over time. So that's change agility. And then the third one is probably possibly the most important one. And that is leadership agility. This idea that if we don't create the environment for change to take place in a conducive way that is productive and adaptable. then we won't change and we'll stay stagnant and we'll stick to our standardized approaches in a stagnant way. And then delivery will suffer even though we can put new things on top of it and we can call things new words, it won't actually change. And the leadership agility is really about not just trying to teach leaders to be more competent. That's generally what management consulting and a lot of other folks are focused on. It's really about trying to help leaders address their ability. to actually have a consciousness about themselves, that they can show up in ways that are actually enabling and empowering the organization to be adaptable and flexible and to be able to deliver and change in ways that are graceful and resilient. And so in my opinion, it kind of starts there even though a lot of them don't start.

Brian (29:14)
I love that. No, I love that. I think that's great because, you know, a lot of times you hear the complaints of people who come through classes that are kind of more team level in the organization. And it's, there's a lot of complaints about how management just doesn't understand, or we're bumping up against the glass ceiling, you know, kind of in our organization, we can't really Institute change or make the change permanent because, you know, leadership still wants things exactly in the old way. They haven't actually shifted. how they think about things. So I love that, I love that concept. I would agree there. Well, this is great stuff. And obviously, like I said, the workshop that Ken did at the Scrum Gathering was an hour and a half. And this is just a short little taste in half an hour. So there's no way we're gonna be able to cover it all here. I strongly encourage people, if they're really interested in this topic, if they're really interested in what Ken is saying,

Ken Rickard (29:53)
Thank you. Yeah.

Brian (30:15)
Check out the book the six big ideas of adaptive organizations. It's a great book And it'll go into detail on all of these these six big ideas that we talked about here And what we're gonna put lots of the links in our show notes here so if you want to just head on over our show notes you'll find links over not only that but to to Ken's organization the six big ideas network and you can find the website there and find the the

Ken Rickard (30:24)
Mm -hmm.

Brian (30:44)
classes and trainings that Ken is doing in this area. So we'll make sure that everybody can get to that. Ken, I can't thank you enough. Thanks for coming on and sharing your knowledge with us today. Yeah.

Ken Rickard (30:54)
Yeah, thanks for having me. It was fun.

#107: Transforming Organizational Mindsets with Bernie Maloney

17 juli 2024 | 28 min

Join Brian and Bernie Maloney as they explore the transformative power of mental models, emphasizing the shift from a mechanistic to an organic mindset in Agile organizations.

Overview

In this episode, Brian and Bernie Maloney discuss the profound impact of mental models on organizational culture. Bernie delves into how our beliefs and assumptions shape our thinking and behavior, particularly within Agile environments.

He discusses the importance of transitioning from a mechanistic to an organic mindset, focusing on problem-solving rather than merely delivering solutions. The conversation also highlights the role of psychological safety in fostering a culture of experimentation and learning.

Bernie shares valuable resources, including Amy Edmondson's 'The Right Kind of Wrong,' to further explore these concepts. Tune in for insightful strategies for enhancing your organization's agility and effectiveness.

Listen Now to Discover:

[1:03] - Brian welcomes Certified Scrum Trainer® and Principal at Power By Teams, Bernie Maloney, to the show.
[2:15] - Bernie delves into the concept of mental models, sharing the origins of his philosophy of "making new mistakes" developed during his time at Hewlett Packard.
[5:55] - Bernie illustrates the power of mental models and belief by sharing a compelling example that brings these concepts to life.
[13:46] - Join us for a Certified Scrum Product Owner® Training, where a year of coaching and development with Mike Cohn, Brian, and the Agile Mentors Community of Agile leaders is included with your training.
[14:39] - Bernie discusses how applying mental models can enhance the effectiveness of Agile transformations, creating a naturally adaptive and innovative climate.
[18:12] - Bernie offers language as a powerful tool to support the shift to a new Mental Model.
[23:30] - Bernie demonstrates the use of mental models for product owners through the Mobius Loop, providing actionable guidance and examples
[26:27] - Brian shares a big thank you to Bernie for joining him on the show.
[26:59] - If you enjoyed this episode, share it with a friend, and like and subscribe to the Agile Mentors Podcast so you never miss a new episode.
[27:27] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership to that site by taking any class with Mountain Goat Software, such as CSM, CSPO, or Mike Cohn’s Better User Stories Course. 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:

Bernie Maloney
Power By Teams
Mobius Loop
The Right Kind of Wrong: The Science of Failing Well by Amy Edmondson
Agile Teams Learn From Spikes: Time Boxed Research Activities by Mike Cohn
Certified Scrum Product Owner® Training
Certified ScrumMaster® Training and Scrum Certification
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 [email protected]

This episode’s presenters are:

Bernie Maloney is an Agile leadership coach and international speaker, leverages his 25 years of engineering and leadership experience to help teams and organizations unlock their full potential. Known for his engaging workshops and impactful coaching, Bernie believes in making performance breakthroughs both achievable and enjoyable.

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 with me. I have Mr. Bernie Maloney with me. Welcome in, Bernie. I am.

Bernie Maloney (00:14)
Thanks, Brian. Happy to be here.

Brian (00:16)
Great. I'm so excited to have Bernie here. Bernie and I have touched base for years over conferences. We've run into each other and had chats and shared our shared passion for Hawaii and other things. But Bernie was speaking at the recent conference and we've gotten into some conversations. I wanted him to come on because I wanted him to, first of all, if you're not familiar with Bernie, sorry, I see, I just want to jump right into it. If you're not familiar with Bernie, Bernie is a CST. He works at a company called Powered by Teams. He teaches classes, Scrum Master product owner classes and leadership classes and other things as well. But he is a principal at Powered by Teams. So just wanted to give you the basics there before we dive into anything. But the topic that we started to talk about that just as a jumping off place for us is a topic. the topic of mental models. So Bernie, why don't you explain to everyone how you define that, mental models.

Bernie Maloney (01:23)
So, Brian, this is a great topic. I find myself talking about it all the time. And y 'all, I warned Brian, like, he can press play on this, and it might be 15 minutes before he gets a word in edgewise here. It touches on mindset. It touches on a lot of topics. My talk that Brian was referencing at the recent Scrum gathering in New Orleans was make new mistakes, leadership lessons from an Agile success. which goes back to where I really kind of cut my teeth in Agile at Hewlett Packard. See, I'm a mechanical engineer by training. And I cut my teeth in Agile in the consumer PC division at HP about, this is scary to say y 'all, okay, about 27 years ago starting at this point. And some of the fun stuff, it was a bang up enterprise. It was the fastest business in HP's history to hit a billion dollars. And it was just...

Brian (02:05)
Yeah.

Bernie Maloney (02:18)
a great proving ground. We had hardware, we had software, we had distributed teams where volume manufacturing was in Asia, engineering was here where I am in Silicon Valley. Go -to -market for Europe was in Grenoble, France. We had high volume. Some of our products had 100 ,000 units in a single model run, with like 200 models in Europe on a quarterly basis at times. So high volume, high mix, tight margins from a business perspective. A lot of technology products want to have 20 % to 30 % gross margins. That's before you start taking off deductions like expenses and salaries and things like that. On a good day, we had 8 % gross margins for Christmas products, maybe 2 % gross margins. We used to refer to it as we were shipping rotting bananas. And like I said, I was there. When I started, we were shipping six products a quarter. We grew to 20. By the time I left after eight years, we were doing 200 products a quarter in Europe alone.

Brian (03:04)
Ha ha.

Bernie Maloney (03:16)
hardware, software, distributed teams, high volume, high mix. And we did all that with weekly iterations of a plan. At one point in my career, I was tactically responsible for the delivery of 2 % of HP's top line revenue with zero direct reports. And part of the secret sauce of success in that organization was really that mental model of make new mistakes. So that's where the talk title comes from. And in fact, makenewmistakes .com will point to poweredbyteams .com because I own that domain too. But that mental model really helped the organization thrive and not just survive. We went from like a number one to a number five share. Sorry, from a number five to a number one the other way around. Because the founding executives recognized that in that tide of a market, mistakes were probably going to happen. And so what they did is they established the psychological safety. Wow, look, there's another great topic. Make new mistakes. You knew that if it was an honest mistake, it would be forgiven. Just don't make it again. Get the lesson is one of the things that they said. I can even tell you the story about the weekend I blew a million dollars of HP's money and I was forgiven, but you'll have to come to a conference talk for that. So that was just like a great experience. And...

Brian (04:32)
Wow.

Bernie Maloney (04:39)
After that experience, I went on to TVs. Another part of my background is I shipped the very first internet connected TVs. Look it up, the Media Smart 3760 from HP. It shipped even before Apple TV. It bombed. Okay, it was way ahead of its time. But I recognized that that had been such a joyride. And then I recognized some other stuff that really gets into the psychological, the mental aspects of leadership, high performing teams. And I could, Brian, I could talk about that too, but okay. But that kind of got me to recognize that with those skills, the success that I had experienced at HP could probably be replicated. That's kind of been the path that I've been on for the past 15 years is really helping organizations go along that path. So mental models can be really big. Let me give everybody here an example. And so Brian, I'm going to speak to you as a way of illustrating mental models. So imagine you are physically where you are right now.

Brian (05:24)
Yeah.

Bernie Maloney (05:37)
but it is 150 years ago, okay? Imagine you're physically where you are right now, but it's 150 years ago. Now, Brian, let me ask you, can man fly?

Brian (05:47)
boy, you're testing my history knowledge.

Bernie Maloney (05:52)
Okay, make it 200 years ago, okay? That makes it easier. Okay, cool. Great, now fast forward to the present. Brian, let me ask you, can man fly?

Brian (05:54)
No, yeah, no. Yes.

Bernie Maloney (06:02)
What changed? Nothing about the laws of physical reality. It was just your mental model of what for man to fly means. That's the power of belief, okay? And belief limits a whole bunch of stuff in the way that people behave. So you'll hear Agilent talk all the time about, this is all about changing mindset. I'm probably, Brian, gonna give your listeners some ways of.

Brian (06:06)
invention.

Bernie Maloney (06:30)
changing mindset as we go through this, but that's going to illustrate the power of mental models. Now, a big one that I like to use that's specific to Agile comes from Gabby Benefield. She's an Agilist out of the UK, and it's called the Mobius Loop. And I think she's got the domain mobiusloop .com. So everybody can imagine a Mobius Loop. Okay. And what I really like about this model for her...

Brian (06:32)
Sure, yeah, please. Yeah.

Bernie Maloney (06:56) i
s the right -hand half is what a lot of organizations think Agile is. Build, measure, learn, build, measure, learn. The whole idea of the build trap that we talk about in Agile. It's all about the delivery of a solution. Okay? But the left -hand half is all about the discovery of the problem. Okay? And the discovery of the customer. And that's a part of Agile too that most organizations overlook. So you got to ask why. And it comes down to kind of mental models. So when I was at Persistent, if you go look me up on LinkedIn, you'll find some of my employment history. I was at Persistent for a while. They had a really good mental model. And it's something I still use when I go into a client. And they would talk about there's kind of three eras of a company culture. And so culture is really the environment that an organization lives within. And there's an era. where cultures were formed before the internet. So things like finance and government and mining and manufacturing and oil and gas field developed. I mean, I've had clients in all of these areas. And in that sort of an environment, okay, it was, well, an era. One of the things I'll ask, and Brian, I'll kind of like let you represent the audience. Would you say in general, the people that you work with, the markets that they serve, Are they moving faster and all up into a thumbs up, slower, thumbs down, or about the same, thumbs sideways? Are the markets moving faster, slower, or about the same as they were, say, five or 10 years ago?

Brian (08:32)
I think everything's moving faster, yeah.

Bernie Maloney (08:34)
Cool. Okay. Now, how about the technology that your clients use to solve problems for that market? You know, moving faster, thumbs up, slower, thumbs down, or about the same as it was, say, five or 10 years ago. Faster. Yeah, cool. Okay. Now, when things are moving faster, thumbs up for yes, thumbs down for no. Do they always move in a straight line?

Brian (08:46)
No, faster. No, not always.

Bernie Maloney (08:56)
Okay, cool. So now things are moving faster, but they're not moving in a straight line. So let me ask you, do most organizations try and plan and predict? Is it possible for you to plan and predict when things are moving faster and they're not moving in a straight line? Is it easier or harder to plan and predict?

Brian (09:19)
I think it's definitely harder.

Bernie Maloney (09:21)
Yeah, but organizations are trying to do that, aren't they? And it's because their mental model is as a machine. So organizations born before the internet have a mental model of the entire organizational system being a machine, the industrial age, which you can plan and predict. They treat people like cogs in a machine. In fact, the thing that us Agilists will say is, when you say resources, did you mean people? See, that's...

Brian (09:35)
Yeah.

Bernie Maloney (09:50)
That's kind of now we're starting to get into some of the culture aspects of this because language actually forms culture. And so you'll hear Angela say, did you mean people? Like when that whole word of resources comes up. But organizations born before the internet, they've got one culture. Okay, they were born in an era of plan and predict. They've got a mental model of the system being a machine. And your listeners would probably agree most of them struggle with Agile. Okay, now there's another era born in the internet but not the cloud. So some examples like here in Silicon Valley, Cisco, PayPal, okay, lots of us have had exposure to them and lots of us recognize they still struggle with agile because agile wasn't really fully formed and articulated. Then there are organizations that were born in the cloud and so places like Striper Square and I use payments because I've had... clients in finance across all three of these eras. So Stripe or Square, they were born in the cloud where things were almost natively agile because the Agile Manifesto had been published by that point. They just inherently get agile. So these mental models of your organizational system being a machine get reflected in the language. So things like people or resources, it turns them into objects. It enables something I've heard called pencil management. Wear them down to a nub, go get a new one. In fact, if you do the research on where the word resources was first applied to human beings, it might shock some people. So I don't talk about that openly. They'll have to find me privately. I'll be happy to point you out the reference. And once I do, it's like, ooh. But one of the jokes I'll crack. And this is one of the ways that you can start to shift the language. If people call you resources, because you know that turns you into an object, start calling them overhead.

Brian (11:23)
Yeah. Ha ha ha.

Bernie Maloney (11:48)
Okay, it can kind of make the difference there. Okay, so, but you know, if things are moving faster and they're harder to plan and predict, that mental model needs to shift. In fact, in agile, we talk about you need to move to sense and respond. When things are moving faster, it's kind of like Gretzky, skate to where the puck is going. You need to sense and respond to the situation. So a better mental model instead of a mechanism is an organism. Because think about organisms, like cut yourself, it heals, okay? It senses and responds. Or like a forest fire comes in, wipes things out, and nature always kind of fills things back in. Sense and respond. This gets reflected in the language. So Brian, do your clients talk about metrics?

Brian (12:37)
Of course, yes.

Bernie Maloney (12:38)
Okay, cool. So do they talk about efficiency?

Brian (12:41)
I would say a lot of businesses will talk about that. Yeah, sure.

Bernie Maloney (12:44)
Yeah, cool. That's the language of machines. Probably better language is diagnostics instead of metrics. That invokes some of the curiosity. And probably instead of efficiency is effectiveness. One of the things I'll say is scrum is not efficient. It's not about utilization of capacity. It's about the production of value, which is all about effectiveness. See, efficiency or effective. Do you go to your doctor for an efficient treatment? or ineffective treatment, Brian.

Brian (13:16)
Effective, hopefully.

Bernie Maloney (13:17)
Awesome. Do you go for blood metrics or blood diagnostics?

Brian (13:21)
Yeah, diagnostics for sure.

Bernie Maloney (13:23)
Yeah, so now you're starting to get some hints about how you can start to shift the mental model. What you're really doing with Agile, y 'all, is you're shifting the culture, and culture is hard because it's not visible. The tools, the processes, the practices that folks like Brian and I will teach and coach, they're super visible, they're super valuable, but they're often not enough to start to change things. So, Brian, would you say most of your listeners are familiar? familiar with the language of Tuchman of forming, storming, norming, and performing.

Brian (13:56)
I'd say there's probably a good percentage, yeah.

Bernie Maloney (13:58)
Cool. I actually like to draw a Satir curve. So Bruce Tuckman, Virginia Satir, they were contemporaries. They were both just researching human systems. So Virginia did a performance axis on the vertical and a time axis on the horizontal. And the way Virginia described it is you're kind of going along in a certain status quo. And so you're kind of along that baseline. And then a foreign element enters and some change. And then you descend into chaos. And you can't see it. like your performance goes down until you have a transformative idea and then through some practice and integration, you rise to a new status quo. This happens to people all the time when they introduce changes in their life like New Year's resolutions. I'm going to get fit and healthy this year. You know, it's a beach body time. And you start doing it and it's like, this is so hard. You're in chaos. And what human beings want to do is they want to go back to the way things were instead of moving through. OK, this happens when you introduce agile into your organization. You'll hear Agilist talk about this as the Agile antibodies. You introduce it, this is so hard, and people want to go back to the way things were instead of kind of moving through. So the tools, the processes, the practices, they're really good, but they're not powerful enough. You got to start changing the culture. Culture is like what we all swim in, but climate is something that you can start to affect. So climate is a little bit closer in to your team, and you can start talking about these mental models. Like when I was at TiVo, I was hired into TiVo to bring Agile in because I had shipped TVs, I knew about Agile. And I was hired in on, I think I can say this now because we're more than a decade past. Have you all ever streamed anything? Yeah, okay. So TiVo was working on that in like 2009, 2010. I got to see that stuff and I was like, really wish I had taken off for them. But that program...

Brian (15:42)
yeah.

Bernie Maloney (15:54)
disbanded, okay, and the culture kind of spread in the organization. And I knew that this was a possibility, so when I brought it in, I made sure I didn't just work with my team that was doing a Skunk Works project, where we were just kind of doing some internal development that we weren't, you know, or stealth is probably a better word these days. So a stealth program inside of TiVo that you couldn't talk about. I knew that... when Agile would spread, it would hit some of this resistance, these antibodies. And so I made a case for bringing in people from outside my team so that it was familiar. And when that program disbanded, it organically spread on the cloud side of TiVo because of some of this stuff. So within your own team, you can kind of create a climate. And then when you start to see results like that, that's going to start attracting kind of the rest of the culture that's there. But these mental models, like shifting from mechanism to organism can really help an organization recognize where their limiting beliefs are about how things go. And it's going to be reflected in language. So if you like dive into anthropology a little bit, you're going to recognize that it's really well established. You can change a culture by starting to change the language. And all of us, okay, if you're observing what's going on in Eastern Ukraine here in 2024, that's what's going on. with the Russian occupation, they're changing the language because that's going to change the culture. That's why they're doing stuff like that. So, and even language starts to shape the mental models that you've got. A good example of something like that was when European, you know, when European explorers is the language I'll use, came to the Americas, the natives didn't really have a language for ship. And so they saw these people coming in floating on the water. And that was the way that they could describe it. So even language kind of gets into a cultural sort of a thing. So these are techniques that you can put into your toolkit. Start shifting the language to start shifting the culture, which can kind of help with the mental models. When you got the mental models, that's where the language starts to come from. If you don't have the mental models, you're probably not going to have the language. And I encourage all the folks I work with, start shifting from the whole idea of mechanism to organism. Okay, Brian, was that 15 minutes? Did I go on for as long as I predicted I would?

Brian (18:27)
About 15 minutes. Yeah. No, but I think that's a good point. There's a thing that I'll talk about a lot of times in my classes where I would all say, you know, the waterfall paradigm is one that's based on manufacturing. And there's a false understanding of what we're doing as manufacturing and it's not. It's more research and development. So you have to kind of shift the process to be one that's more conducive. to research and development. So that's very much in line with what you're talking about here. I love that.

Bernie Maloney (19:01)
Yeah. Do you think people would appreciate some book references that can kind of like help you? Okay. So specifically on that whole ethos of experimentalism that you just touched on, Brian, I'm currently going through Amy Edmondson's The Right Kind of Wrong. Really good book. Now, Amy is well known because she helped establish psychological safety as a super important topic in organizations.

Brian (19:07)
absolutely. Absolutely.

Bernie Maloney (19:30)
So she was coupled, I think, with Project Aristotle at Google. And in this book, she unpacked some really interesting stuff. She talks about failure, and there's types of failures. There's basic, there's complex, and there's intelligent failures. OK, intelligent failures, they're just native to science. You know things are going to go wrong. You're going to have Thomas Edison, the I Found 1 ,000 Ways. to do a light bulb wrong, sort of. That's like intelligent failure. Basic failure, she breaks down into, let's see, neglect and inattention. And those are the things that you really want to start to squeeze out of a system. With that mental model of a mechanism, I would say a lot of, call it management, tends to think of a lot of failures as basic failures. And that's where blame starts to come into a system. Okay, so now we're back into psychological safety. Okay, where you want to establish, you know, that was an honest mistake. Hence the talk title of make new mistakes. Okay, so you can have processes and procedures that can kind of squeeze out some of those basic failures. Complex in the middle is really interesting to talk about. As I'm getting into the material, she unpacks... Now, complex failures are those chain of events, you know,

Brian (20:30)
Yeah. Yeah.

Bernie Maloney (20:54)
This thing and this thing and this thing all had to line up and go wrong at the same time for this catastrophic failure to go on. And in medicine, which is where her original research was, they talk about it as Swiss cheese. And she says, if you go into a lot of medical administrators' offices, you're going to find some model of Swiss cheese there. Because they talk about it's like all the holes have to line up for something to go sideways on you. So complex failures. It's a chain of events, a bunch of little things. And she points out that in the research, these often happen when you have an over -constrained system where there's no slack, where you're trying to operate with, get this, Brian, 100 % efficiency. You're trying to load everybody up. So that is just like, it's not just juice on psychological safety, but like, looking at the whole idea of intelligent failures that we want to encourage versus constraining out basic failures versus working to reduce those complex failures and not just thinking complex failures are basic failures, but they're systemic failures that then might be part of the system, might be part of the mental model that's going on that's there. So super juicy stuff.

Brian (22:11)
Yeah, yeah, that's really good stuff. I've always loved Amy's work and I feel, you know, silly calling her Amy. But Amy Edmondson's work has always been great. Yeah, Professor Edmondson. She, the work on psychological safety, I think was just amazing. And the examples she used in her research are amazing. And, you know, all the stuff with Project Aristotle.

Bernie Maloney (22:20)
Okay, Professor Edmondson, yeah.

Brian (22:36)
I love the concept of psychological. I mean, again, not to make this the topic of our podcast, but, you know, I love the idea that they, they, they found that psychological safety was, so foundational that nothing else mattered. That if you didn't have that, that not no matter what else you layered on top of it, it would not fix the problem that you didn't have psychological safety.

Bernie Maloney (22:58)
Yep. And that's one of the reasons why I say Agile is actually a social technology more than anything else. I mean, that's why it's people and people over processes and tools. This is really a social technology that we deal in.

Brian (23:10)
That's a great way to put it. I love that social technology. Awesome. I love that.

Bernie Maloney (23:14)
So kind of talking about Amy and psychological safety and kind of all these systems that we're talking about, another mental model that I like to give particularly my product owners, going back to that Mobius loop. and like on the right hand side is all about delivery, okay, that's where you give team solutions to build. That's what a lot of organizations do. Versus on the left hand side with discovery, it's all about problems to solve. So I like to encourage my clients to instead of just giving people solutions to build, give them problems to solve. Now, for product owners, if you imagine like an onion that's kind of stretched out left to right, so kind of an odd long little onion.

Brian (23:41)
Yeah.

Bernie Maloney (23:58)
and on the far right is your sprint. And then as you go to the left, you're at a release, and further out to the left, you're in roadmap, and way further out into the left, you're into these vague things like vision. So product owners kind of deal with this whole span of things. And in between, product and sprint goals start to make things a little bit more concrete. Okay, and... One of the things I'll do for my product owners is I'll take that Mobius loop and I'll overlay it on a planning onion like that and go, do you get to see how, like what we're talking about here, you're starting out way vague in discovery and you're getting way more concrete as you get into delivery and into the sprint. And really the job of Agile and Scrum is both. It's not just about turn the crank on the machine. In fact, I think it's unfortunate that there's a book title out there of twice. the work in half the time. I actually like to pitch this as more it's about twice the value with half the stress. Okay, now as you imagine that Mobius loop kind of overlaid, one of the things I'll unpack for folks is when you're way out in that vision area, there's a lot of uncertainty that's there, okay? And you're actually going to have to do discovery. You may have to run some experiments.

Brian (24:58)
Yeah.

Bernie Maloney (25:24)
Okay, and it's only as you get closer into delivery that you want to get closer to certainty. And really, that's kind of the job of a product owner is squeezing uncertainty out of the system. Initially through discovery of the problem to solve, who to solve it for, what the market is, but it's the job of the whole team in Agile to squeeze that uncertainty out of the system. Brian, I'm sure you've had folks like talk about spikes. You ever have people get wrapped around the axle about like including spikes in their product backlog?

Brian (25:48)
Yeah, for sure. yeah, for sure.

Bernie Maloney (25:54)
Cool, the way that I frame that up, okay, so here's a mental model. That's just technical uncertainty that you've uncovered. Great, okay, so now we've got to go squeeze that uncertainty out of the system. So stop getting wrapped around the axle on stuff like this. Just like stop trying to plan and predict things. Instead, kind of get into sense and respond on all of them. And there, I've kind of brought it around full circle for you, Brian, for where we started.

Brian (26:09)
Yeah, no. No, that's great. That's great stuff. And I love the fact that we can bring it back full circle. Well, this is fascinating. And like you said, we could press play and go on this for another half hour very easily. But we'll be respectful of people's time here and keep it to our normal time length. Bernie, I can't thank you enough for coming on. I really appreciate you sharing your experience with us. And... what you've learned over your years of working in this profession.

Bernie Maloney (26:50)
Thank you so much for asking me, Brian

#106: Innovating Through Economic Downturns with John Barratt

10 juli 2024 | 35 min

Join Brian and John Barratt as they delve into the current state of the agile industry, exploring the impact of economic downturns on agile coaches and Scrum Masters, and discover innovative strategies to navigate these challenging times.

Overview

In this episode, Brian and John Barratt dissect the current state of the agile industry, focusing on the effects of economic downturns on agile coaches and scrum masters. They discuss the reasons behind organizational layoffs and cost-cutting measures, emphasizing the need for innovation to thrive during challenging periods.

The conversation shifts to redefining the roles of scrum masters and agile coaches, highlighting the importance of delivering value and outcomes rather than merely facilitating meetings. John introduces two essential resources—the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics—to support agile practitioners in their professional development.

The episode concludes with a discussion on the significance of mentorship and continuous improvement within the agile community. Tune in for invaluable insights and practical tools to enhance your agile journey.

Listen Now to Discover:

[1:08] - Brian welcomes Certified Scrum Trainer®, Certified Team Coach®, & Certified Enterprise Coach®, and host of the Clean At Work podcast, John Barratt.
[4:42] - John reveals the core issues behind struggling organizations and shares how innovation can allow an organization to thrive during challenging times.
[5:50] - Brian and John analyze the impact of economic downturns on organizations and agility, offering strategies to navigate these challenging times successfully.
[10:04] - Brian and John explore the role of Scrum and Agile in an economic downturn.
[16:08] - Join Brian and the Mountain Goat Software team for not only a Certified ScrumMaster® class but a full year of membership, learning, and support from Mike Cohn, Brian, and the Agile Mentors Community. You don’t have to lead alone.
[17:09] - Brian poses an opportunity to expand the definition of done of Scrum leadership.
[19:43] - John introduces the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics as powerful resources to help Agile practitioners and leaders enhance their skills and progress in their development.
[23:42] - John shares the tool of Agile Scoping, based on From Contempt to Curiosity by Caitlin Walker, to lean into Scrum success within an organization.
[32:25] - Brian shares a big thank you to John for joining him on the show.
[33:04] - We invite you to share this episode with a friend and subscribe to the Agile Mentors Podcast.
[33:57] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email.
[34: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. 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:

John Barratt
Clean At Work podcast
Scrum Events Meetup
#93: The Rise of Human Skills and Agile Acumen with Evan Leyburn
The Agile Army - John Barratt
Agile Coaching Growth Wheel
Agile Coaching Code of Ethics
Agile Scoping
From Contempt to Curiosity by Caitlin Walker
Agile 2024 - The European Experience - Manchester
Agile Coach Camp UK
Certified ScrumMaster® Training and Scrum Certification
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast
Mountain Goat Software Certified Scrum and Agile Training Schedule

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

John Barratt is a Certified Enterprise Coach® (CEC) and Certified Scrum Trainer® (CST), passionate about helping individuals, teams, and organizations achieve their best through agile coaching approaches. With a background in the military and a keen interest in systemic modeling, John constantly seeks new ideas and innovations to support organizational resilience and agility.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We are here for another episode of the Agile Mentors podcast. I am with you as always, Brian Milner, and with me today, I have a good friend of mine that I've been trying to get on the show for a while. Mr. John Barrett is with us. Welcome in, John.

John Barratt (00:14)
Thank you for having me Brian. It's been a while. We've been trying. We're here today. I'm really pleased.

Brian (00:18)
Yeah, very, very excited. John and I have seen each other at conferences for years. We've crossed paths. And I kind of jokingly said to him, I'm threatening to have a conversation with you not at a conference at some point. And that was kind of how we started this. For those who aren't familiar with John and his work, John works with a company called Agile Affinity.

John Barratt (00:34)
Hahaha!

Brian (00:43)
He is a certified Scrum trainer, a certified team coach, and certified enterprise coach. So he has the holy trifecta of Scrum Alliance certifications there from the guide community. He's a coach and trainer. Couple of interesting things. First of all, we'll talk a little bit about this, but John has his own podcast called the Clean at Work podcast that we can talk about here a little bit. But another interesting thing that he told me before, I didn't realize this, but John actually started in the military. So do you want to say anything about that? How long were you in the military?

John Barratt (01:19)
Yeah, so I was in the military for six years, joined accidentally when I was 18. So I went into the career office with a friend who was joining. And they were like, you're a bright lad, you can earn all of this money. So it was either go to university and getting lots of debt or join the army, get lots of training and get paid and see the world. So no thoughts of joining before that day accidentally joined. Did six years including a tour of Iraq. And the important thing about that for me is when I left, I felt really isolated. So Army is all about team, right? Team focus. Left the Army, was in IT, and it felt totally different. People were there stabbing me in the back, not supporting me. And then I found this thing called Agile, which was about teams again. And this thing called Scrum, where it was a team game. I was like, this is what I've been missing. Where's this been for the last two years since I left the army? And the rest is history. I did do a keynote at Central Agile Spain. I'm not sure what year, but it is on YouTube for anyone who's interested in hearing more about how the army is actually rather agile in my humble opinion.

Brian (02:22)
Yeah. That's awesome. We'll find that and put that in the show notes here. So if people are interested in finding that, they can go and watch that.

John Barratt (02:45)
Yeah, we'll have to dust it out of the archives.

Brian (02:48)
Well, yeah, yeah, I'm sure we can find it. But we were talking before this about our topic and I think this is going to be a topic that's interesting to a lot of people. Really, really kind of diving into the state of the industry right now and what we're seeing as far as the economy in the agile industry. You know, there's there's several organizations that have laid people off You know, there's there's less demand at the moment in the coaching kind of realm So kind of what's behind that the the shifts and you know What might be driving this kind of thing? So I know John you got some opinions on this. So let us have it

John Barratt (03:18)
Mm -hmm. Yeah, so I don't want to talk too much about the global economics. I don't pretend to be an expert on why we're seeing a recession. We can talk about, you know, COVID and the cost of that and also the war in Ukraine and, you know, all of the pain and suffering that that's caused much more than, you know, what we're seeing, which is, you know, a few people being laid off. So I don't want to go into that. But what I do want to really explore is, so if an organization is struggling, there's two elements. for that. Do they try and cut back as much cost as possible or do they try and innovate themselves out of that recession? Do they try and do something different and in a unique way? Unfortunately what I'm seeing a lot of is the first one which is cut back, reduce cost as much as possible and that's to the detriment of the the Scrim masses and and agile coaches that we see and I'm going to talk a little bit why they are the ones that often are in danger in a minute. Instead of where they should go, which my bias opinion should go, right? What I'm trying to do in the company that I run is to actually lean into that as an opportunity and try and innovate and see, well, what is possible in this new, exciting world that we're perhaps moving into? Where do we need to go when organizations are struggling? What are the opportunities, an example, AI that we've seen and what difference will that make in the next few years? I mean, who knows?

Brian (05:14)
Yeah, yeah, I think it's fascinating and you know, there's something I've talked about with some friends for several years and that is that I think there's sort of a, boy, I don't know how deep we want to go on this, but you know, you have a lot of executives now that get hired to come into a company and it's gamesmanship because the idea is I've got to increase our... our stock price by however many percentage points. And my bonus is tied to that. The more I can increase it, the more I get a bonus. Well, it's kind of like if you go to a team and tell them, hey, can you do more story points? They can certainly game that and all of a sudden have more story points. Well, the same thing with a short -term kind of executive. If you're in an organization and you're only going to be there for a couple of years, And you know your site is, if I can raise it three percentage points, I get a bonus. Well, there's a lot of easy cuts I can make that all of a sudden I've gone up three percentage points. But the long term of that company has not benefited. It's only the short term. And it just feels like, I don't know if it's a day trader thing, if that's really why this is kind of becoming more prevalent or not. But it seems like investing is kind of more of the short term. Now, and it used to be when you buy a stock, you'd buy it for 10, 20 years because you believed in that company and you expected to pay off over the long run. There's still a little of that, but it seems much more short -sighted. And I think that's trickled down to our, like I said, I don't know how deep we want to get on this. I think that's trickled down to our executives. And I think from the executive, that's trickled down to the employees. And that's really affected how...

John Barratt (06:41)
Mm -hmm.

Brian (07:06)
you know, when we've had layoffs and we've had downturns in the economy that just, hey, this is an easy way for us to show an increase in profits.

John Barratt (07:15)
Yeah, I think that's a really good point. It reminds me of Craig Lammon's laws, structure leads culture. And when we talk about structure, we don't ever just mean the hierarchy, we mean the bonus system, how people are rewarded and paid and all of those things. And so if you're rewarding shortism by giving these execs bonuses based on

Brian (07:34)
Yeah.

John Barratt (07:41)
profit for this year or as you said stock increase by 3 % then they will cut costs because what looks good for short term and for stocks is to have the minimum operational expense possible right if they can keep that as low as possible then that looks like a solid company because they're keeping controlling costs they talk about and and If they're working on margins and profits start to go down, which is what we're seeing as a trend at least UK, US, I can't say if it's completely global, but it seems like a large percent of the company and the organizations are going in that way, then what they do is to keep their margins so that they get their bonus is they start to reduce that, right? Because they need to keep that buffer. If they were to do what I'm suggesting, which is to lean into that and perhaps spend a little bit, spend some money to make some money, or at least keep it lying and try some innovative stuff, then that's high risk for them. Hmm.

Brian (08:50)
Yeah. Yeah, I've seen things before that have said that when there is economic downturns, that their evidence shows that the companies that invest more during the economic downturns actually end up increasing their positions to a much greater extent when the downturn starts to turn around because...

John Barratt (09:02)
Mm -hmm.

Brian (09:14)
they haven't just set idle or they haven't tried to reduce, they've tried to invest and now they're positioned to really take advantage of it once the economy starts flowing again. I'm not like you, I'm no economic expert, I'm no economist. So I don't know all the ins and outs of what's causing that. But it certainly has caused pain in our sector. And I think a lot of sectors, because I have I know lots of people who have gone through layoffs, not just in the tech industry recently. So I guess kind of the question that I ask about this as far as the agile community is concerned is, if we were delivering value, right? If it was undeniable that what we were doing was increasing profits, increasing value to our customers, I think that would make it a lot. harder for these kind of layoffs to happen. So I don't want to entirely say, hey, it's bad leadership, right? I think we have to take ownership a little bit.

John Barratt (10:23)
Yeah, and I'm going to say something I think is quite controversial here, which I actually blame servant leadership for this. So I know in the latest version of the Scrum Guide, we use the word true leadership, but I still like the word servant leadership. And I've actually changed my mindset and how I teach these things over the last few years because of this, because we've started to see this trend.

Brian (10:28)
Go for it. All right.

John Barratt (10:51)
And I've seen it in organizations where I've worked, I've left one year later, and then they've made all the agile coaches redundant. And I think it's down to how we use and perceive servant leadership. So historically, I was always, you know, Scrum Master or Agile Coach is the great person in the background. They let everyone else take the credit. They're there to help and support the team and to do all of that stuff, which is great, right? until someone with a balance sheet comes along and goes, what are all these scrum masters who aren't delivering any value, right? They're an overhead. They're seen as an overhead. Not delivering any value. No one can even tell me what value they've created. These developers over here, they're doing great. And the product owner is really maximizing the value of this product. But these scrum masters, they don't add any value. Because that's what we told them to do, right? We taught them to...

Brian (11:29)
Yeah.

John Barratt (11:49)
give everyone else the credit and serve everyone else and be in the background. So I think we've got a lot to blame, Brian, as trainers for, well, I don't know how you've taught it in the past, but I feel a little bit guilty. Don't worry, I've got the answer, but I just want to hear from you, what you, where you are with that one.

Brian (12:04)
No, no, no, no. Yeah. I'll tell you my opinion and you'll tell me if I'm correct or not. Yeah, no, I agree. I definitely think that's part of it. But maybe this will be a little controversial. I kind of spoke about this recently at the Scrum Gathering in my talk. In the trend that we've seen, John Barratt (12:15) Yeah!

Brian (12:40)
that I kind of talk about the diminishing of the perception of value of the Scrum Master. And I think that there's kind of multiple parts to that. I think part of it could be, hey, leadership doesn't really understand the value. But I think that there is a secondary part of that, that they're not seeing the value. And if they're not seeing the value, then I think that that's

John Barratt (12:48)
Mm -hmm. Mm -hmm.

Brian (13:08)
that rest on us. I think that we have to partly do a better job of helping them to understand it, but partly doing a better job of delivering it. And again, don't want to get too controversial here, but in our industry, in our training industry, You know, we've done lots of two day classes. We've done lots of things where we get people out the door and then they're in place and they're doing things. And the follow -up, you and I both know the follow -up is so important. You can't just take a two day class and then you're set for life. It's two days, but that's a kickoff and you got to continue that. and if I, if I take a two day class and I kind of slide backwards a little bit from that class and I get in and I'm a scrum master, there's, John Barratt (13:43) Mm -hmm. Yeah.

Brian (14:01)
Unfortunately, I think there's a lot of scrum masters out there who see their job as meeting scheduler. I'm here to schedule meetings, and that's the value I bring. Well, I can't blame a leader for letting that person go, because anybody can schedule meetings. It doesn't really take a lot of skill to do that.

John Barratt (14:08)
Mm -hmm. Yeah.

Brian (14:26)
The skills that we should be adding are those soft skills, the conflict resolution and understanding the personality types that make up our team. And essentially what I talked about in my talk was that first phrase of the Agile Manifesto, individuals and interactions over processes and tools. It's about individuals and interactions. We have to know the people that make up our team, not every team in the world, but our team. And we have to know. how they work best together. And I think people who do that, there's enormous value for that. So I would propose to you there's a shared blame, right? I think there's a blame there that we need to do a better job of showing the executives, but we also need to do a better job of actually providing value for the executives. John Barratt (14:58) Mm -hmm. Yeah. Yeah, yeah, I'm just, I was just, you know, I'm new to running CSMs and things like that. And one of the things I've brought in is a follow -up session. So, you know, a month after the training, they can have 30 minutes and we can talk about stuff. And that's really where you appreciate that the CSM isn't enough, right, to be a Scrum Master because you... There's only so much you can do, but the thing that always lacks, at least I haven't managed to perfect it yet, is those soft skills, right, which are the things that are important because you can't cover that in half an hour, an hour, right? All of those things are a full one, two, well, I'm being generous, just touching the sides with a one, two day course in some of those. And it's good to see the Scrim Alliance moving into some of those, you know, competency based or what they call skills based. courses where we can go a bit deeper into those key things. Because they're talking about, well, how can I do this? And in my head, it's obvious, but it's clearly not. So there's a huge gap between putting someone on a two -day course and thinking they can be a scrum master. And we do see a lot of bad scrum masters in the industry. And it certainly does cost everyone, even the good ones, some credibility. Right? Because... And if there's more ones, and it's not bad because they're bad people or trying to do a bad job, it's just that they haven't been equipped to do the job, right? Yeah, it's as simple as that. Brian (17:03) Yeah. At one of the tables I was at at the recent guide retreat at the Scrum gathering, we were having a discussion around this. And one of the things that kind of struck me as that was going on was, you know what it sounds like? It sounds like we don't have a stringent enough definition of done. Like when we think about someone who's you're now ready to be a Scrum master, well, that definition of done right now is a two day class. Right? And.

John Barratt (17:22)
Mm -hmm.

Brian (17:32)
I think we have to put in the expectation that, no, this is a component of that definition of done, but there's actually more that you need in order to, you know, this is an important role. This is somebody who is shepherding and guiding a team to be successful in this. So if someone's not qualified in doing that, it's no wonder that we see a bunch of bad scum out there because the person leading it isn't qualified, you know?

John Barratt (17:38)
Hmm. Yeah, and actually, I was just thinking an apprenticeship approach would be a much better idea, right, for this type of work. I often give the metaphor in my classes that agile coaching is a craft, Scrum Mastery is a craft. And imagine you're a carpenter, you don't get better at being a carpenter by reading lots of theory about good joints and all of this stuff. You know, you pick up a few things, you get better at Scrum Mastery or agile coaching.

Brian (18:07)
Yeah.

John Barratt (18:29)
by working and getting feedback. Our work is with the people, right? And people are a lot more complex than would, so we have to do even more of it to get any good. And of course, in carpentry, you wouldn't think about, we'll do a two -day training course. You would do an apprenticeship, right? And they do it for years before they become like a master carpenter. Yet we have scrimmasters after two days.

Brian (18:58)
Yeah. Yeah, no, I completely agree. And for the organization, I know when you've seen organizations that have sort of that layer, that hierarchy of we have Scrum Masters, but we have coaches, and we have enterprise coaches. When you have that kind of structure where you can have the phrase we use as mentor and be mentored. And if you can be in that place where you mentor others and you're also being mentored,

John Barratt (19:21)
Mm -hmm.

Brian (19:28)
That I think is really key to reaching the next level, to being able to kind of grow into what it is that you want to become in this industry.

John Barratt (19:39)
Yeah, I mean, I can't solve that problem very easily myself. You know, we've got a certified team coach and enterprise coach in the Scrim Alliance. It needs to be a bit more of a gap, I think, between that and CSPSM and we'll see what comes out in the next few years. But there is a couple of resources that I have worked on to try and help with this. So I've been on a mission to try and professionalize the world of agile coaching for at least five years. And the two things that I've found that have helped most people, is something called the Agile Coaching Growth Wheel, which you may have heard of. We'll put the link in the chat to that, which has kind of all of the competencies that we think you need in Agile Coaching, which is the set of competencies that a Scrum Master needs. So not Agile Coach, Agile Coaching, Scrum Master, Agile Coach, or any, you know, job title could be anything, right? It doesn't really matter. So that's a really useful tool. gives you all the areas, but it also gives you guidance, like a one to five guidance that almost uses the apprenticeship type thing. I can't remember all the levels, I think it uses like the Drift for scale, but it says at level one, you should be able to do these sorts of things. At level two, you should be able to do these sorts of things. And that gives people at least a starting point. You don't know what you don't know, right?

Brian (20:58)
Right. No, I think that's awesome. And we definitely will put that in our links and make sure that people can find that. Yeah, you're right. That kind of apprenticeship idea, I know that I could not have gotten to where I am without the mentors I've had.

John Barratt (21:15)
Mmm.

Brian (21:18)
And it's people who have, for no benefit of their own, have taken their own time to say, I'm going to invest time in this person and help them reach the next level. And I've tried to carry that forward as I've grown in this career as well, because I think it's important. I think we have to help the next group that's coming along. Yeah.

John Barratt (21:44)
Mm -hmm. I was thinking becoming a CST is almost like that apprenticeship type system, right? Where you have to do the co -trains with different people. They're like mentors, right? Different diversity, different types and groups. And you learn, both people learn from doing the co -train. And I think personally, it'd be a shame if they ever...

Brian (21:54)
Yeah.

John Barratt (22:16)
remove that concept because I think it's the closest we've got to an apprenticeship.

Brian (22:21)
Yeah. Yeah, and it works, right? I mean, I think that it does a good job of getting people to the level they need to be. There's still a lot, I mean, that doesn't do it all on its own, but it is, you know, I think anyone who's been through it, I think you would probably agree with this as well, is, you know, that was a foundational part of becoming a CST for me, is being able to observe and watch others and learn from them and... get feedback on how I was doing it. So I think you're right. That could be a very intriguing addition if there was someone who kind of incorporated that into the process. And I think that would give organizations kind of a confidence to say, I can trust this person.

John Barratt (23:10)
Which is what we really want with the CCCTCs, right? It's that stamp. I can trust that person. Second tool I wanted to highlight was the Agile Coaching Code of Ethics. So this was an initiative we did with the Agile Alliance. And the beauty of when we created this code of ethics, it was for people who were just starting out as well as experienced professionals. So you can read through that and that's kind of your rule sheet of

Brian (23:25)
Yeah.

John Barratt (23:40)
I'm new to this. This is the minimum standard we expect from a Scrum Master or an Agile coach in this industry. Because you don't know what you don't know again. But we've tried to make it as simple as possible. A simple list of these are the things you should definitely do if you want to be ethical in your work.

Brian (24:00)
Yeah. Yeah, that's a good resource as well. And we'll make sure we have that linked. Was there another resource as well that you wanted to mention, or is it just those two?

John Barratt (24:12)
So it's the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics. So we've talked a lot about the problem of where we're at, and we've given a couple of pointers. I wanted to talk a little bit about how I've changed my direction from this original kind of servant leadership type focus, which seems to be having some...

Brian (24:36)
Yeah.

John Barratt (24:40)
traction and benefit and value to people. And it's a couple of tools combined. So I created something a couple of years ago called Agile Scoping, which was based on Clean Scoping. So Clean Scoping is something that Caitlin Walker created based on Clean Language around how she scoped out a new piece of work. If you want to know more, then I highly recommend her book from Content Curiosity.

Brian (24:44)
Awesome.

John Barratt (25:10)
Bit biased, but one of the best books I've ever read. Not an agile book at all, but just a truly incredible story about how she's used clean language and something we call systemic modeling, which is using clean language in groups, with youths that have been kicked out of school, for example, and how they went from all individuals to suddenly kind of helping and supporting and understanding each other.

Brian (25:31)
Hmm, yeah.

John Barratt (25:40)
So great book. But anyway, Agile Scoping was based on that and it starts off with a discovery phase. We call that initial scoping, which is setting out kind of, is this work set up for success? So is the person in charge actually got enough influence over the system to actually make any change? So if you are doing Scrum. Do they have permission to actually change the structure into something that is actually going to help Scrum succeed? Have they tried different things before? And also this thing called congruency. So it's what they're saying aligned to what they're doing. So asking for those examples of, okay, you're saying that this, have you tried that before? Those sort of things. Very high level, just checking it out. And you can do that in an interview as well. So this isn't just for an external person. I always think that interviews should be two -way, right? It's not just a one -way thing. I want to check that if I'm signing up 40 hours a week or however many, that this is an organization that actually wants to be agile. I mean, I always put my hand out to the people on my training and people I meet at conferences where they're really struggling, right? And it's a really hard environment. And I always think, wow, you've got way more patience than I have. I really respect that. but my patients' levels are very low. So if I'm going to work with a client, I need to have a feeling that they can work at a pace, right?

Brian (27:20)
Yeah, right. Right.

John Barratt (27:21)
So that's level one and that's fine. Then we do an organizational scoping phase where you work with as many people as possible. You're looking at the problems that the organization says they've got, what the culture is now, where they want it to be, running some workshops, finding out what's happening. And again, we call it scoping because you can scope it to the level that you've been brought into. So if you're a Scrum Master working with one team and it's... One product owner, small product, that's fine. That's your scope if it's a whole organization, much wider. At the end of that, you create a coaching plan with the organization. So you have a session and you agree up to four outcomes is what I've found. So we move into outcome -based approach. So even if you skip all of the other stuff, what I would say is move away from any output thinking. As a scrum -rosterer,

Brian (28:10)
Yeah.

John Barratt (28:18)
even if it's just in your yearly appraisal, make it clear these are the outcomes that we're looking for. And these are more business related outcomes or things that are going to actually make a difference to the organization. So it could be things like make more money for the organization, could be increase employee engagement, increase customer engagement, number of active users in your mobile app, whatever those are. But they're nothing to really do with Agile, they're to do with...

Brian (28:42)
Yeah.

John Barratt (28:47)
that the organization wants to set. Those go into a coaching plan. We have a coaching agreement canvas that you can use to put all of that in. And then it's really clear, like these are the things that I'm going to help and support you with as a Scrim Master or Agile coach. There's a bit more risk, right? Because if you don't meet them, then you've got to have a conversation, but at least then it's visible, right? These are what I'm saying I'm going to help with. This is what you've said you want help with. And now we're going to do a number of experiments to try and get there. And that's where we get into that continuous improvement cycle of trying to involve, adapt, inspect, work on all of those things that are happening within your team, within your department, within your organization, depending on where your scope is, constantly evolving and looking at. where we're at. We might have some lead -in indicators as well, perhaps in there to help us cycle time, lead time, throughput. Those can be useful, but really we're looking at end value and we're measuring our performance of a Scrum Master Agile Coach based on the value being given. We're not letting the product owner take all of that praise and credit. Of course, we don't want to be too arrogant and go too far the other way. It's a team effort. but we're at least putting our, you know, more, I think skin in the game is the thing. What I've seen in the past is, you know, bit of a puppy dog type thing, Scrum Master, ooh, shiny over here, great, shiny over there, no, skin in the game, this is a partnership, and we're gonna work on this together. Sorry, I spoke for a long time, though.

Brian (30:16)
Yeah. Love that. No, no, no. I love that. You were saying great stuff. And I mean, I love the bit about outcome -based kind of approaches to it. I think that's really, really important. I've always thought, you know, like the performance, I'm always really hesitant about performance -based kind of metrics. And I always want to shift more to output outcome -based kind of metrics, not output. And I think that because that's, You're right. A business doesn't care how agile we are. A business cares if we're increasing our bottom line, if we're increasing our membership, all the business goals that you might have. That's what they care about. And agile -ism means to that.

John Barratt (31:17)
Yeah, I have a big shiver when teams have like agile maturity models. Like the word maturity, first of all, like if I say to you, Brian, you're immature, Brian. You know, that's just like, why would you do that? And also if I, you know, it's many people have said agile is never the goal, right? We're never trying to be agile for agile sake. We're doing it to help organizations and, you know.

Brian (31:23)
Ha ha ha.

John Barratt (31:44)
Therefore, why would you want to know how mature a team is when that's not actually that important, right? Could be a very leading indicator, perhaps, of where you're trying to get to, but it scares me when I see those sort of things.

Brian (32:04)
Yeah, this is great. This is great stuff. And there's so I mean, from what you've said, there's so many good links that we're going to be able to put in our show notes for this. We'll also, by the way, make sure that people can get in touch with you, John, if they want to follow up and learn more individually from you, because that's always really important here as well. And I know it's conference season. There's a lot of conferences going on. And you were telling me you're going to be at the Europe.

John Barratt (32:12)
Mm -hmm.

Brian (32:33)
Agile 24 conference, right?

John Barratt (32:36)
Yeah, so I've decided to do my part for the environment and not fly out to America for the third time this year. So I'm going to be in the Agile Alliance Manchester in July. I'm doing two sessions there. One looking at product refinement using clean language and the other one how to help and support self -managing teams with Caitlin herself. So if you like the idea of the stuff I was talking with Caitlin. and that's the session for you. Also going to be in Agile Prague this year, Agile Coach Camp UK, which I run, but unfortunately that is full. So there is a waiting list if you did want to try and sneak into that. And I'm sure I'll be at a few other places as well. There's also my monthly meetup that I run with a number of other colleagues called Scrum Event. It's actually the second largest Scrum Alliance user group in the world.

Brian (33:33)
Awesome.

John Barratt (33:34)
and we tend to have some pretty cool speakers there, so watch out for that.

Brian (33:40)
That's awesome. Yeah. We'll try to link to all of that so that people can find it. But yeah, if you're going to be at any of those conferences or if you're on the fence about going to the conference, you can hear great speakers like John there. So make sure that if you do, that you go up and say hello and tell them that you were listening to the podcast and heard this and were interested. And that's why you're there. Well, John, I appreciate your time. We're recording this on a Friday afternoon for you. And I know that's really precious time at the end of a week. So I really appreciate you giving us your time here and sharing your knowledge with us.

John Barratt (34:19)
Thank you for inviting me and having me. It's been a blast.

Brian (34:24)
Absolutely.

#105: Scrum Conferences & Neurodiversity with Brian Milner

3 juli 2024 | 25 min

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

This episode’s presenters are:

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

26 juni 2024 | 39 min

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

This episode’s presenters are:

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

19 juni 2024 | 29 min

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

This episode’s presenters are:

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

12 juni 2024 | 31 min

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

This episode’s presenters are:

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

5 juni 2024 | 31 min

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

This episode’s presenters are:

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

29 maj 2024 | 46 min

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

This episode’s presenters are:

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

22 maj 2024 | 33 min

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

This episode’s presenters are:

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

15 maj 2024 | 34 min

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

This episode’s presenters are:

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

8 maj 2024 | 35 min

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

This episode’s presenters are:

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

1 maj 2024 | 39 min

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

This episode’s presenters are:

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.

#95: Navigating Change with Precision with Steve Martin

24 april 2024 | 35 min

Join Brian as he explores the Change Initiative Canvas with Dr. Steve Martin, a groundbreaking tool designed to streamline and succeed in organizational change efforts. Learn how to tackle change with clarity and strategic foresight.

Overview

In this insightful episode, Brian Milner and Dr. Steve Martin dive deep into the mechanics of the Change Initiative Canvas, a strategic framework developed to guide organizations through successful transformations.

They discuss critical aspects such as setting clear objectives, measuring impact, handling objections, and the importance of cultural alignment within the organization. Whether you're initiating small adjustments or major shifts, this discussion provides the essential tools and tactics to navigate change effectively and achieve meaningful, sustainable results.

Listen Now to Discover:

[1:10] - Brian welcomes Dr. Steve Martin, PhD, Certified Scrum Trainer®, CEO of Agility Guides, and professor at Franklin University and creator of the Change Initiative Canvas.
[2:38] - Steve unveils the intriguing origins of the Change Initiative Canvas, sharing the inspiration and journey behind its creation.
[4:38] - Steve breaks down the concept of failure, offering insightful strategies on how to interpret and learn from setbacks.
[7:00] - Steve delves into the essentials of recognizing when change is necessary by questioning the underlying reasons and observing the problem's impact.
[11:29] - Brian emphasizes how understanding the customer's immediate need for change is vital for navigating towards the right solutions.
[14:34] - Steve explains the delicate balance between thoroughly understanding a problem and avoiding the trap of analysis paralysis.
[15:24] - Explore your Agile potential with the custom Elements of Agile assessment, crafted by Mike and Brian to help you gauge your team’s current agility and identify opportunities for growth.
[17:17] - Steve emphasizes the significance of clearly outlining what success entails to align efforts and expectations across the board.
[20:29] - Explore effective strategies for navigating resistance and overcoming constraints during a change initiative, ensuring smoother transitions and successful outcomes.
[26:48] - Steve highlights the critical need to understand an organization's culture and outlines methods for accurately assessing it to ensure alignment with strategic initiatives.
[30:46] - Steve encourages listeners to connect with him on LinkedIn and explore the practical tools and resources available on the Agility Guides Resources page, designed to enhance real-world Agile practices.
[31:56] - Brian expresses his heartfelt gratitude to Steve for sharing his insights on the show, enriching the conversation with his expertise.
[32:34] - Continue the conversation and deepen your Agile knowledge by joining the Agile Mentors Community. Enjoy a complimentary year-long membership by enrolling in any Mountain Goat Software, such as the Certified ScrumMaster (CSM) or Certified Scrum Product Owner (CSPO).
[33:24] - Subscribe to the Agile Mentors Podcast and spread the word to anyone who might appreciate our discussions. Have feedback or an idea for a future episode? We'd love to hear from you—drop us an email!

References and resources mentioned in the show:

Steve Martin
Agility Guides
Change Initiative Canvas
Agility Guides Resources
Elements of Agile
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 [email protected]

This episode’s presenters are:

Dr. Steve Martin is driven by a passion to help leaders excel, by leveraging extensive experience in orchestrating large-scale transformations and academic insights to empower leaders at all levels to navigate today’s volatile business landscape. From failed beginnings to leading successful agile transformations and teaching leadership principles, he guides executives and managers to lead with authenticity, humility, and a coaching mindset, ensuring both organizational success and personal fulfillment.

#94: Connecting Teams and Leadership with Anthony Coppedge

17 april 2024 | 39 min

Join Brian and Anthony Coppedge as they unlock the secrets to bridging the team-leadership divide. Learn how to navigate through fear, short-term thinking, and the transformative power of Agile within top-tier organizations like IBM.

Overview

In this episode of the Agile Mentors Podcast, Brian sits down for a groundbreaking conversation with Anthony Coppedge, of IBM and creator of the Retrospective Radar.

They delve deep into the disconnects plaguing organizations between their teams and leadership. From overcoming fear and fostering long-term value to harnessing the strength of middle management and the critical role of data-driven decision-making, this episode offers a treasure trove of insights for those looking to drive agility and foster a culture of transparency and success in their organizations.

Join us to explore how translating team realities into leadership vision can catalyze meaningful change and position companies for enduring success.

Listen Now to Discover:

[1:18] - Brian welcomes Anthony Coppedge, IBM's business agility expert.
[2:40] - Unveiling the core issue, Anthony explores how fear fuels the disconnect between teams and their leaders, offering insights into bridging this crucial gap.
[4:04] - Anthony highlights the power for the team in delivering real value for the benefit of others.
[5:14] - Hear Anthony unpack the significance of scalability in systems and processes, highlighting its role in enabling organizations to adapt and thrive, and what the conversations with the teams can look like to achieve scalability.
[6:00] - Anthony lays out vivid examples of the existing gap between teams and leadership, offering insightful strategies needed to effectively bridge this divide.
[7:50] - Highlighting the pivotal role of middle management, Anthony suggests leveraging these key players as connectors between teams and top leadership.
[8:50] - Anthony shows how to effectively convey the ground-level realities of teams to leadership, ensuring their efforts are directly linked to the organization's overarching direction.
[10:30] - Brian emphasizes the critical need to grasp what drives leaders, advocating for the translation of team insights into a language that resonates with leadership priorities.
[13:59] - Anthony explores how adopting a client-centric approach fosters transparency in communication, ensuring clarity and alignment across all levels.
[16:31] - Bridge the gap between your leadership and teams by helping the leaders to expand their Agile language and experience with Mountain Goat Software’s Agile For Leaders Course.
[18:34] - Anthony proposes actionable strategies and the importance of teams spearheading cultural shifts within their organizations, steering them towards embracing Agile principles.
[21:43] - Highlighting the strategic use of data, Anthony discusses how it can illuminate results and motivate shifts towards better practices.
[29:14] - Brian unveils Anthony's innovative approach to reflection and growth with 'The Retrospective Radar.'
[36:11] - Brian shares a big thank you to Anthony for joining him on the show and invites listeners to connect with him on LinkedIn.
[37:27] - We invite you to share the podcast with friends and 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.
[38:06] - If you’d like to continue this discussion on the episode specific discussion forums on the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software.
[38:48] - Brian invites listeners to join him live and in person at the 2024 Global Scrum Gathering in New Orleans and the Agile2024 conference in Dallas.

References and resources mentioned in the show:

Anthony Coppedge
Retrospective Radar
Retrospective Radar Template
Creative Commons usage rights for the Retrospective Radar
Agile For Leaders
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 [email protected]

This episode’s presenters are:

Anthony Coppedge is the Principal Agile Digital Sales Global Transformation Lead at IBM and creator of the Retrospective Radar. Anthony has reshaped enterprises from startups to Fortune 500 giants like IBM, pioneering enterprise Agile Sales and driving customer-centric outcomes worldwide.

#93: The Rise of Human Skills and Agile Acumen with Evan Leybourn

10 april 2024 | 32 min

Explore the skills revolution with Brian and Evan Leybourn of the Business Agility Institute as they dive into a landmark study on the skills shaping today's workforce. Learn why adaptability, human skills, and agile acumen are the keys to success.

Overview

In an enlightening episode, Brian sits down with Evan Leybourn, co-founder of the Business Agility Institute, to delve into recent research findings on the essential skills for the modern workforce.

They discuss the paramount importance of human skills over technical abilities in hiring, the emergence of 'pi-shaped' professionals who excel in multiple domains, and the critical role of agile acumen across various job roles. Additionally, they address the pressing need for educational systems to pivot from traditional role-based learning to a more versatile skill-based approach.

This episode is a treasure trove for anyone looking to navigate the workforce's future, offering deep insights into adapting and thriving in an ever-evolving professional landscape.

Listen Now to Discover:

[1:17] - Join Brian in a captivating session with Evan Leybourn, the innovative author and co-founder of the Business Agility Institute, as they explore groundbreaking insights into agility and workforce evolution.
[2:32] - Discover the unexpected findings from Evan's recent study, ‘Skills in the New World of Work,’ on the workforce's most sought-after skills and their pivotal role in modern hiring practices.
[4:50] - Brian sheds light on the rising value of soft, or human, skills in the workforce, suggesting a pivotal expansion of Scrum Master skills to embrace these vital attributes.
[8:00] - Evan reveals their unexpected discovery: organizations are increasingly seeking 'pi-shaped' skills that blend diverse areas of expertise.
[12:45] - Perfect your human skills and refresh your Agile approach with Mountain Goat Software’s Advanced Certified ScrumMaster® and Advanced Certified Scrum Product Owner® courses. For further details, visit the Mountain Goat Software training schedule.
[15:05] - Unpacking the idea of 'pi-shaped' professionals, Evan details how these unique individuals bring multiple skill sets to one role, elevating their effectiveness and output, using a full-stack developer as an example.
[16:22] - Evan tackles the provocative statement that Agile is dead, offering insights and counterarguments to this bold claim.
[21:47] - Evan highlights a key finding: Agile Acumen emerges as the runner-up in the most coveted skills during the hiring process across organizations.
[24:50] - Evan stresses an important takeaway: 'The skills you have are valuable,' pointing out that the essence of Agile expertise transcends the exact wording of job descriptions.
[27:05] - Highlighting a necessary evolution in learning, Evan advocates for a move towards skill-based training and education, away from traditional role-focused models, to better prepare for the workforce of tomorrow.
[29:21] - Brian shares his gratitude for Evan and his work to help better understand the job market.
[30:02] - Brian invites listeners to join both him and Evan live and in person at the Global Scrum Gathering 2024 in New Orleans.
[30:33] - 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:03] - 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:

Evan Leybourn
Skills in the New World of Work: Which Agile Skills are Most In-Demand in Today's Workforce?
Business Agility Institute
Directing The Agile Organization: A Lean Approach To Business Management by Evan Leybourn
#noprojects: A Culture of Continuous Value by Evan Leybourn
Global Scrum Gathering 2024
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Evan Leybourn is the co-founder of the Business Agility Institute and author of "Directing the Agile Organization" and "#noprojects; a culture of continuous value." Evan champions the advancement of agile, innovative, and dynamic companies poised to succeed in fluctuating markets through rigorous research and advocacy.

#92: Navigating Scrum Anti-Patterns with Stefan Wolpers

3 april 2024 | 31 min

Join Brian and Stefan Wolpers as they explore the labyrinth of Scrum anti-patterns, shedding light on the crucial shifts needed in communication, event understanding, and organizational empowerment for Agile success.

Overview

Brian welcomes special guest Stefan Wolpers as they explore the maze of Scrum anti-patterns.

Discover the art of tackling communication breakdowns, unravel the misunderstandings that plague Scrum events, confront the systemic issues of organizational anti-patterns, and challenge the rigidity of dogmatism in Agile practices.

Whether you're a seasoned Scrum practitioner or new to the Agile philosophy, this conversation between Brian and Stefan will arm you with the insights needed to navigate the complexities of Scrum, enhance team collaboration, and drive successful Agile transformations. Tune in to transform your understanding and practice of Scrum, and take a step towards mastering the dynamic world of Agile.

Listen Now to Discover:

[1:06] - Join Brian as he sits down with Stefan Wolpers, a seasoned Professional Scrum Trainer and the mastermind behind ‘The Scrum Anti-Patterns Guide,’ for a deep dive into the pitfalls to avoid for Scrum success.
[2:33] - Discover the power of inversion with Stefan, as he elucidates this groundbreaking learning principle, challenging traditional methods and revolutionizing our approach to personal and professional development.
[5:21] - Stefan delves into the critical issue of communication breakdown and assumptions among teams, revealing effective strategies to address and navigate these common pain points.
[10:01] - Listen as Stefan highlights the transformative impact of trust building and team bonding, revealing their significance as key elements in bridging cultural differences and bringing remote teams closer together.
[12:02] - Brought to you by Mountain Goat Software, the Agile Mentors Podcast invites you to enhance your Scrum skills through the Certified Scrum Product Owner® course. Explore a world of Agile learning opportunities by checking out Mountain Goat Software's extensive training schedule.
[13:03] - Join Stefan as he delves into the Scrum framework, highlighting the Daily Scrum and Sprint Planning as events ripe with anti-patterns, and providing guidance on overcoming these obstacles for smoother sprints.
[18:10] - Listen as Stefan illuminates the critical anti-pattern of lacking empowerment within organizations, emphasizing its widespread impact and proposing pathways to cultivate a more empowered workforce.
[22:08] - Explore with Brian the significance of an anti-dogmatic stance, highlighting its role as a pivotal anti-pattern in fostering innovation and adaptability in Agile environments.
[26:14] - Brian shares a big thank you to Stefan for joining him on the show.
[29:01] - If you’d like to continue this discussion, join the Agile Mentors Community.
[30:01] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback, a question, or a great idea for an episode of the show? Great! Just send us an email.

References and resources mentioned in the show:

Stefan Wolpers
The Scrum Anti-Patterns Guide by Stefan Wolpers
Certified Scrum Product Owner®
Training Mountain Goat Software Certified Scrum and Agile Training Schedule
Mike Cohn’s Letting Go of Knowing
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Stefan Wolpers is the author behind "The Scrum Anti-Pattern Guide" and a celebrated Professional Scrum Trainer known for his unparalleled expertise in Agile methodologies. Stefan has dedicated his career to empowering professionals around the globe.

#91: Revolutionizing HR with Pia-Maria Thorén

27 mars 2024 | 33 min

Dive into an enlightening conversation with Brian Milner and HR innovator Pia Maria Thorén on the transformative power of Agile in HR and leadership. Discover a people-centric approach that champions attitude, growth, and empathy.

Overview

Join Brian Milner in this compelling episode as he sits down with Agile and HR expert Pia Maria Thorén, who shares her insights on revolutionizing Human Resources and leadership with Agile project management principles.

Pia Maria delves into the critical shift from traditional hiring practices to prioritizing attitude and potential, fostering a nurturing candidate experience, and the vital role of team involvement in the hiring process.

Through her advocacy for empathy and a people-centric approach, Pia Maria outlines how understanding and support can transform handling performance challenges and layoffs into opportunities for growth. Tune in to explore how these strategies not only enhance HR practices but also pave the way for more dynamic, resilient organizations.

Listen Now to Discover:

[01:13] - Dive into an enlightening conversation with Pia-Maria Thorén, the visionary author behind 'Agile People' and a leading expert in Agile human resources.
[02:30] - Join Pia-Maria as she unfolds the compelling narrative of Agile's breakthrough into HR practices, crafting a more effective and adaptive approach to leadership and human resources management.
[07:46] - Hear from Pia-Maria as she unveils the secrets behind Agile's innovative recruitment and hiring strategies, focused on creating an environment where candidates are eager to work and flourish.
[09:44] - Brian explores the catalyst behind Agile hiring practices, pondering how organizations kick-start the recruitment process when their sights are set not on vacancies but on attracting the perfect fit.
[10:55] - Shifting the focus from traditional job slots to dynamic team contributions, Pia-Maria introduces the transformative concept of 't-shaped' teams in recruitment, urging a reevaluation of how we define the ideal candidate in job descriptions and hiring processes.
[13:08] - Brian draws upon Simon Sinek's insightful video, dissecting the intricate relationship between trust and performance in teams, and highlighting the importance of trust in the makeup of high-performing teams.
[15:00] - The Agile Mentors Podcast is brought to you by Mountain Goat Software. Elevate your expertise with their Certified Scrum Product Owner® course and gain exclusive access to Mike Cohn’s Agile Mentors Community for a full year of continuous coaching and support. Explore the full spectrum of Certified Scrum and Agile Training on the Mountain Goat Software schedule.
[16:44] - Pia-Maria introduces a groundbreaking perspective on measuring team success, steering away from individual performance metrics and static goals towards a more dynamic and holistic assessment strategy.
[21:37] - Pia-Maria delves into the complex dynamics of employee departures and layoffs within the Agile HR framework, questioning how these principles reshape traditional approaches to such challenging situations.
[28:11] - Pia-Maria raises compelling counterpoints to the general avoidance of specialization, inviting listeners to consider the circumstances under which honing in on specialized skills could be advantageous.
[29:24] - Brian shares a big thank you to Pia-Maria for joining him on the show, inviting listeners to connect through Agile People or LinkedIn.
[31:07] - 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, CSPO, or Mike Cohn’s Live Online Better User Stories class, 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.
[31:40] - 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:

Agile People
Agile People: A Radical Approach for HR & Managers by Pia-Maria Thorén
Agile People Principles by Pia-Maria Thorén
Agile People Picture Book by Pia-Maria Thorén et al.
“How Do You Measure Success?” By Simon Sinek
Certified Scrum Product Owner® Training
Certified ScrumMaster® Training and Scrum Certification
Mike Cohn’s Better User Stories
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast
Scrum Gathering in New Orleans 2024

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Pia-Maria Thorén is the founder of Agile People and author of ‘Agile People' and specializes in driving organizational agility through HR, leadership, and motivation. She creates workplaces where employees perform better and feel engaged, contributing to successful transformations from both financial and human perspectives

#90: Mastering Agile Coaching with Cherie Silas

20 mars 2024 | 35 min

Join Brian Milner and Master Coach Cherie Silas as they discuss the intricate dance between professional coaching and Agile coaching and unlock the secrets to empowering Agile transformations.

Overview

Join us on a captivating journey with Brian Milner and Cherie Silas, the visionary founder of Tandem Coaching, as they delve deep into the nuances that distinguish professional coaching from Agile coaching and learn why adopting a coaching mindset is crucial for effective Agile coaching.

Explore the pivotal role of an Agile coach within an organization and the fine art of balancing consulting with true coaching to foster empowerment and self-solution finding.

Cherie unravels the complexities of Agile practices, the thin line between coaching and counseling, and the transformative Tandem Coaching program.

This episode is a treasure trove of insights for anyone looking to understand the essence of agile transformation and how it's not just about adopting new practices but about achieving meaningful business outcomes. Whether you're an aspiring agile coach or a seasoned professional seeking to deepen your understanding, this conversation is your gateway to elevating your agile journey.

Listen Now to Discover:

[01:18] - Join Brian as he greets Cherie Silas, the visionary behind Tandem Coaching, co-author of 'Enterprise Agile Coaching,' and a revered Master Coach.
[03:38] - Listen in as Cherie clarifies the essential differences and intersections between professional coaching and the dynamic field of Agile coaching.
[07:07] - Explore with Cherie as she articulates the nuanced differences between being labeled an 'Agile Coach' and embodying the true essence of Agile coaching.
[09:15] - Cherie shares her expertise on striking the perfect balance between consulting and coaching, highlighting strategies for blending these two vital roles effectively.
[12:12] - Brian highly endorses Cherie’s dynamic, mentorship-driven Professional Coach Training for anyone looking to deeply enrich their coaching abilities.
[14:42] - Learn from Cherie the critical role of engaging as a thought partner in coaching clients, a fundamental strategy for fostering profound and effective Agile coaching connections.
[18:00] - Discover with Cherie the dynamic strategy of engaging clients with thought-provoking questions like, "What's the challenge we're tackling?" and "What's the goal we're striving towards?" This approach not only clarifies objectives but also charts the course towards achieving them, making each coaching session a journey of mutual exploration and growth.
[22:04] - If you're on the path to becoming a Certified Scrum Master, look no further than Mountain Goat Software's engaging, top-rated courses. Beyond the interactive classes, you'll gain a year-long membership to the Agile Mentors Community—a vibrant space to both give and receive mentorship. Dive deeper into your Agile practice and explore the Mountain Goat Software Training Schedule today.
[24:47] - Join Cherie as she unveils the foundational pillars of becoming an exceptional coach - the art of active listening, the skill of insightful questioning, and the journey through coaching training.
[27:17] - Brian invites listeners into a thought-provoking exploration of the nuanced differences between coaching and counseling, questioning how to skillfully navigate the boundaries that define and differentiate them.
[31:44] - Brian shares a big thank you to Cherie for joining him on the show, inviting listeners to pick up the book, ‘Enterprise Agile Coaching’ and highly recommends Tandem Coaching’s training programs.
[33:15] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback, a great idea, or a guest suggestion for an episode of the show? Great! Just send us an email.

References and resources mentioned in the show:

Tandem Coaching
Enterprise Agile Coaching: Sustaining Organizational Change Through Invitational Agile Coaching by Cherie Silas, Michael de la Maza, and Alex Kudinov
Professional Coach & Team Coach Training with Cherie Silas and Tandem Coaching
2024 Global Scrum Gathering in New Orleans
Certified ScrumMaster® Training and Scrum Certification
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Cherie Silas is a Certified Enterprise Coach (CEC) and is the first agile coach to be awarded the ICF Master Certified Coach (MCC). She is the Founder and CEO of Tandem Coaching with a 20-year legacy in corporate leadership and co-author of the book Enterprise Agile Coaching: Sustaining Organizational Change Through Invitational Agile Coaching

#89: Transformational One-on-Ones with Avipaul Bhandari

13 mars 2024 | 30 min

Join Brian and Avipaul Bhandari as they uncover a secret to transformative Agile teams. Discover how one-on-one conversations can redefine team dynamics and even scaled organizational culture.

Overview

In this episode of the Agile Mentors Podcast, Avipaul Bhandari, a seasoned Agile coach, takes us through the critical role of one-on-one meetings in nurturing agile teams.

Avipaul sheds light on how such meetings are pivotal in building trust, understanding individual perspectives, and fostering a culture of empathy. By adopting a coaching mindset, Scrum Masters and coaches can empower team members to lead the conversation, encouraging them to uncover and propose their own solutions.

Listen in as they explore the profound impact these meetings have on scaling agile principles and catalyzing cultural transformation within organizations. Through emphasizing individual strengths and ensuring a safe environment for honest dialogue, one-on-ones emerge as a key strategy for enhancing team performance and achieving agile excellence.

Tune in to learn how you can leverage one-on-one meetings to unlock the full potential of your team and spearhead a shift in your organizational culture.

Listen Now to Discover:

[01:15] - Brian warmly welcomes Avipaul Bhandari, a distinguished Agile coach and musician, joining us by popular demand from our listener community.
[02:26] - Avipaul unveils the secrets behind effective one-on-one interactions and their ripple effect on enhancing organizational culture.
[05:54] - Avipaul heralds human connection as a key driver of positivity and cohesion within teams, advocating for its impact on team success.
[07:14] - Discover how Avipaul successfully navigated resistance to one-on-one meetings, turning reluctance into productive conversations, even from those claiming to have nothing to say.
[10:55] - Mountain Goat Software is the sponsor for this podcast. Whether you’re looking to get Certified ScrumMaster® (CSM) or Certified Scrum Product Owner® (CSPO) training or want to take an Advanced Certified ScrumMaster® (ACSM) class, click here to see what we have to offer.
[12:00] - Brian discusses the profound impact of empathy and Simon Sinek's approach to nurturing a culture of psychological safety.
[13:05] - Avipaul shares insights on enhancing empathy in the team members and yourself through the intimate dialogue of one-on-one meetings.
[19:23] - Avipaul unpacks how one-on-ones within scaled teams can significantly boost processes and deeply motivate team members.
[23:10] - Brian highlights how these interactions can embody and influence the broader company culture through demonstration, creating a ripple effect of positive change.
[23:47] - Avipaul makes a compelling case for the power of respect in eliciting the best performance from everyone.
[26:43] - Brian shares a big thank you to Avipaul for joining him on the show and the lister who suggested him! If you have a topic or person you would love to hear on the podcast, send your suggestions to [email protected]
[27:41] - 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®, Advanced Certified Scrum Product Owner®, and Mike Cohn’s Better User Stories Course, 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.
[28:41] - 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:

Avipaul Bhandari
Listen to Avipaul’s music on Spotify
Simon Sinek’s Books
Mike Cohn’s Better User Stories Course
Subscribe to the Agile Mentors Podcast
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Avipaul Bhandari is an established agile coach and musician with over 20 years of experience. He is an intuitive and knowledgeable change agent and has been instrumental in successful agile adoptions in companies such as Microsoft, the Financial Times, Allianz, and others.

#88: Slicing Work For Agile Success With Anton Skornyakov

6 mars 2024 | 31 min

Join Brian Milner and Anton Skornyakov as they tackle the often overlooked art of slicing work on this episode of the Agile Mentors Podcast. Discover how this pivotal strategy can revolutionize feedback loops and drive impactful results across industries.

Overview

Join us on a riveting journey with Agile expert Anton Skornyakov to unearth the transformative power of slicing work in Agile environments.

In a world where most projects miss the mark on effective breakdown, Anton sheds light on the critical need for well-sliced work to secure valuable customer feedback and accelerate delivery of results.

From the nuanced art of vertical slicing to innovative strategies for tackling complex story breakdowns, this episode is packed with insights and practical examples that span beyond the confines of software development. Whether you're grappling with how to split your next project into manageable increments or seeking to refine your Agile practice, Anton's expert advice and favorite splitting techniques offer a roadmap to success.

Listen Now to Discover:

[01:20] - Brian introduces an Agile Mentors Podcast listener-requested guest, Anton Skornyakov, Certified Scrum Trainer® and author of The Art of Slicing Work.
[02:20] - Hear Anton recount the real-world struggles of translating the fundamental principle of defining effective increments into actionable insights for teams beyond software development.
[04:39] - Anton delves into the art of work slicing by expertly applying the rules for splitting user stories, revealing insights for seamless practice.
[06:41] - Anton brings vertical slicing to life with a relatable dinner party analogy, illustrating its transformative impact on teamwork.
[11:12] - Anton uncovers the magic of vertical slicing, revealing its pivotal role in enhancing team responsibility—an esteemed Agile virtue.
[13:01] - Facing challenges in cultivating a unified understanding of Agile principles across your team? Let Mountain Goat Software elevate your team's agility—from non-software teams to the executive suite.
[13:58] - Brian expands the conversation to explore the far-reaching implications of vertical slicing on project management and team dynamics.
[16:36] - Confronting a familiar hurdle, Anton dissects the notion that the complexity of work stands in the way of effective slicing.
[17:57] - Anton explores strategies for navigating resistance when team members push back against the practice of slicing work.
[19:20] - Anton reveals his insights into teams' struggles with splitting tasks they deem too large and how to overcome this perception.
[24:43] - Anton shares his favorite ways of breaking down work.
[28:47] - Brian expresses heartfelt gratitude to Anton for his invaluable insights on today's show and extends a warm thank you to the listeners for their brilliant guest recommendations. If you have a guest or topic suggestion for an upcoming episode, send us an email at [email protected]
[39:56] - We invite you to subscribe to the Agile Mentors Podcast. Please like, subscribe, and share with your friends.
[30:30] - 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.

References and resources mentioned in the show:

The Art of Slicing Work by Anton Skornyakov
Agile.Coach
Introduction to Agile
Working on a Scrum Team
Agile for Leaders
Mountain Goat Software’s Courses
Subscribe to the Agile Mentors Podcast
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Anton Skornyakov is a Certified Scrum Trainer® and author of The Art of Slicing Work. He is passionate about educating and supporting organizations, reliably delivering results on unpredictable projects.

#87: Testing Beyond Assumptions with David Bland

28 februari 2024 | 35 min

Join Brian and David Bland as they journey into the novel idea of testing assumptions before development to avoid costly mistakes and ensure the right things are being built in the latest episode of the Agile Mentors Podcast—a must-listen for any product owner wanting to determine if their team is working on the right thing.

Overview

In this episode of the Agile Mentors Podcast, Brian talks all things testing with David Bland, the founder of Precoil and co-author of the book Testing Business Ideas: A Field Guide for Rapid Experimentation.

Learn the importance of testing assumptions and experimentation in product development as David shares his journey from working in startups to coaching and consulting and how he realized the need to bring Agile principles into the discovery phase of product development.

You can listen in as they explore the concept of testing business ideas and the three-step process of extracting assumptions, prioritizing them, and running experiments.

Listen Now to Discover:

[01:01] - Brian introduces David Bland, founder of Precoil and co-author of Testing Business Ideas: A Field Guide for Rapid Experimentation.
[02:10] - David dives into weaving testing assumptions and experimentation into managing the product backlog for product owners.
[02:51] - David discusses how you can determine if you're working on the right things and prevent iteratively delivering something that nobody cares about by applying the Agile principles further upstream.
[04:20] - Brain adds insight with the notion of being selective as the product owner, referencing the work of Henrik Kniberg.
[05:18] - David breaks down the themes he developed from design thinking and how they apply beautifully to the product backlog: desirable, viable, & feasible
[06:50] - Brian asks the question burning through many of our minds, “How do you apply it to testing your ideas?”
[07:15] - David lays out the three-step process he uses and applies to testing business, product, and service ideas.
[08:32] - David discusses the difference between requirements and assumptions.
[10:33] - David provides a practical example of adding wishlist functionality to a website and what testing this idea would look like under his testing framework.
[14:47] - Today's episode of the Agile Mentors Podcast is brought to you by Mountain Goat Software's Private Training for Agile transformations. Get your team on the same page through customized training and coaching programs to level-set your team. For more information, visit the Mountain Goat Software’s Private Training page.
[16:07] - Brian poses the concept of asking, “How does an idea move the needle” before the idea is developed?
[18:14] - David shares his thoughts on running customer-facing acceptance criteria and the product death cycle, a term David coined.
[21:06] - David provides an example of a client who puts a positive spin on killing projects that prove not to be viable via testing.
[22:33] - Brian asks if there are testing methods that can be applied after a product launch as a lagging indicator of the launch.
[24:57] - Brian clarifies the value of testing before making a bet on a new product, even as an entrepreneur working alone, through the example of knowing how a bet will play out in a Las Vegas casino.
[25:38] - David lays out the common objections he sees from companies and how you could address them.
[27:13] - David lays out one of his favorite techniques for testing, concierge, which he lays out in detail in his book.
[30:41] - Brian draws the conversation back to the Agile Manifesto.
[31:49] - Brian shares a big thank you to David for joining him on the show.
[33:30] - We invite you to subscribe to the Agile Mentors Podcast on Apple Podcasts. 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:

David Bland
Precoil
Testing Business Ideas: A Field Guide for Rapid Experimentation by David Bland & Alexander Osterwalder
#25 Scaling with Henrik Kniberg
Agile Manifesto
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Mountain Goat Software’s Private Training
Mountain Goat Software Certified Scrum and Agile Training Schedule

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

David J Bland helps companies such as GE, Toyota, Adobe, HP, and Behr find product market fit using lean startup, design thinking, and business model innovation through his company, Precoil. He is the lead author of Testing Business Ideas with Alexander Osterwalder.

#86: Revisiting User Stories with Mike Cohn

21 februari 2024 | 42 min

Have you ever returned to an old User Story and wondered, “what was I thinking?” On today’s episode, Mike Cohn, walks us through how and why he recently revisited and updated 200 Real Life User Story Examples from his past projects and updated a resource for you! Listen in as Mike and Brian share what worked and what didn’t work from the past, in an effort to make their user story writing skills stronger.

Overview

What makes a user or job story great? In this episode of the Agile Mentors Podcast, Brian Milner and Mike Cohn of Mountain Goat Software, share Mike’s recent updates and edit to 200 Real Life User Story Examples.

Listen as they revisit 200 older user stories, breaking down their analysis through the lens of more experience and an evolving technological landscape.

Plus, in true iterative fashion, Mike shares how he is still working to write better user stories after years of perfecting and teaching the art of story writing.

Tune in to learn what makes a great clear user story, and what makes a story that stinks.

Listen Now to Discover:

[00:57] - Brian is joined today by Mike Cohn who will be revisiting user stories.
[02:58] - Mike talks about how he came back to these 200 user stories and decided that some of them sucked and needed updating.
[04:42] - When writing user stories, Mike talks about prioritizing meaningful conversations over perfect user stories.
[06:35] - Brian underscores the importance of efficient communication with developers through unconventional yet practical user stories.
[07:22] - Brian points to previous podcast episodes with Mike that delve into the basics of writing user stories, in episode, #10 Why User Stories are the Best Way to Capture Requirements with Mike Cohn and #39 The Art of Writing User Stories with Mike Cohn
[08:22] - Mike walks through a story written for the development of the Scrum Alliance website, noting it is framed well within the site's premise.
[09:10] - Brian raises considerations about inserting information mid-story.
[09:57] - Mike finds the story intriguing but suggests simplifying it by moving details into acceptance criteria, a notion that didn’t exist at the time, for clarity.
[12:03] - Mike advocates for concise user stories, suggesting omitting unnecessary details and using acceptance criteria for specifics.
[13:52] - In a job story example, Mike and Brian point out common mistakes from an era without distinct fields.
[16:34] - Brian understands the attempt to prompt discussion in the job story but finds it normal overall.
[17:32] - Mike critiques a job story for site admins approving job postings, suggesting modernizing language for notification methods and flexibility.
[19:34] - Reflecting on a story about user authentication, Mike acknowledges a bias toward email-centric perspectives, and questions if this story goes too far separating the what and the how.
[21:22] - Mike highlights story #42, recognizing a potential mistake in specifying UI details in a story about navigating job listings.
[23:24] - If you’re struggling to get your team or organization on the same Agile page from team members to senior executives. Mountain Goat Software can help you Build a Common Understanding of Agile on your team!
[24:17] - If you’re a visual learner or you’d like to follow along, you can find the pdf of all the user and job stories discussed in this episode, plus many more, right here.
[25:12] - Mike defends a story about viewing detailed course pages, acknowledging UI implications but justifying the necessity of the detail.
[27:13] - Mike critiques a user story about creating user accounts, cautioning against a potentially misleading "so that" clause with a specific example.
[29:18] - Reflecting on the evolution of user stories, Mike emphasizes a shift from stating "I can" or "I want to" to a more neutral "I."
[30:40] - Critiquing a user story about browser compatibility, Mike suggests that it's a nonfunctional requirement and better suited as part of the definition of done.
[33:18] - Brian presents a user story for Mountain Goat Software’s Planning Poker tool about database indexes, expressing reservations about the commonality of developer-focused stories.
[34:00] - Mike reflects on the “as a developer” story and expresses uncertainty about its inclusion, considering it potentially problematic.
[36:22] - Mike critiques a story about database analysis, acknowledging its verbosity but justifying the detail as necessary for clarifying the researcher's role and objectives.
[38:03] - Brian appreciates the brevity of the "I want" part of a user story and finds the "so that" clause acceptable as it provides examples and context for developers.
[38:39] - Considering a story about storing results, Mike deems it not bad but potentially too long.
[40:00] - Mike highlights that the best way to get better at writing stories is to write a bunch of them, acknowledging that his early stories taught him valuable lessons.
[41:03] - Brian thanks listeners and invites them to share and subscribe to the Agile Mentors Podcast on Apple Podcasts.
[41:29] - 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:

Free download: 200 User Story Examples
#10 Why User Stories are the Best Way to Capture Requirements with Mike Cohn
#39 The Art of Writing User Stories with Mike Cohn
User Stories Applied: For Agile Software Development by Mike Cohn
Job Stories Offer a Viable Alternative to User Stories by Mike Cohn
Mountain Goat Software’s Planning Poker
Better User Stories Course
Build a Common Understanding of Agile
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Mountain Goat Software Certified Scrum and Agile Training Schedule

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#85: Effectively Managing Dependencies with Ken Rubin

14 februari 2024 | 50 min

In this week’s episode, Brian is joined by the legendary Ken Rubin, the author of Essential Scrum. Together, they dive deep into the world of dependencies in larger organizations and scaling, drawing from Ken's extensive experience since the early days of Scrum. If you're navigating the complexities of dependencies and looking to optimize your team's flow, this episode is a must-listen.

Overview

In this episode of the Agile Mentors Podcast, Brian welcomes the iconic Ken Rubin to explore the intricate realm of dependencies at scale. They dive into the impact of dependencies on flow, the challenges of scaling, and the effectiveness of feature teams in managing structural dependencies.

Ken shares valuable insights into the myths surrounding dependencies and practical strategies for minimizing their impact, whether they involve external partners, scarce specialized roles, or deliberate component teams.

As a bonus, Ken announces his upcoming one-day live online course where you’ll dive deeper into effective dependency management strategies, Dependencies are Killing Your Agility: Learn to Fight Back!

Tune in as Ken and Brian provide practical wisdom, actionable strategies, and a wealth of knowledge.

Listen Now to Discover:

[01:16] - In today’s episode, Brian sits down with the first director of the Scrum Alliance and author of Essential Scrum, Ken Rubin.
[03:03] - Ken defines dependencies as a relationship between two or more entities that requires collaboration or coordination.
[04:31] - Ken distinguishes two dependency types: structural and instantiated.
[06:48] - Brian emphasizes addressing the root cause of dependencies, comparing it to optimizing water flow in plumbing systems.
[08:06] - Ken stresses the importance of addressing structural dependencies to prevent them from becoming blockers and impeding flow.
[10:18] - Brian highlights an upcoming one-day live online course with Ken titled Dependencies are Killing Your Agility: Learn to Fight Back! on March 14th, emphasizing its relevance for Scrum Masters and product owners.
[11:10] - Ken defines the concept of flow and compares it to the concept of utilization.
[13:04] - Leaders listening should prioritize optimizing flow over squeezing individuals for efficiency.
[14:23] - Ken underscores the importance of managing structural dependencies by balancing system-level WIP.
[16:28] - Ken debunks the myth that 100% feature teams can eliminate all dependency issues.
[19:14] - Ken shares how feature teams are compelling but face exponential challenges.
[21:45] - Ken explores the need for specialized roles in scaling feature teams, proposing a threshold approach.
[24:57] - Discover why Ken advocates for a combined feature and component team model, suggesting systemic swarming for specialized roles.
[26:55] - Today's episode of the Agile Mentors Podcast is brought to you by Mountain Goat Software's Private Training for Agile transformations. Get your team on the same page through subject-specific training, coaching, and mentoring. For more information, visit the Mountain Goat Software’s Private Training page.
[28:06] - Ken challenges the idea of a one-size-fits-all solution for dependency problems, cautioning about tool limitations.
[30:25] - Ken proposes expanding the concept of working agreements to include inter-team arrangements.
[33:55] - Ken highlights the misconception of solving external dependencies through internal escalation, stressing the limitations and challenges.
[35:40] - Ken dispels the myth that identifying dependencies means solving the problem, emphasizing the need for control.
[38:35] - Brian highlights the significant impact of waiting time, using the example of ordering a t-shirt online.
[39:36] - Addressing flow problems in scaling challenges is crucial.
[42:35] - Brian underscores the impact of addressing flow issues and promotes Ken's upcoming one-day live online course, Dependencies are Killing Your Agility: Learn to Fight Back! on March 14th
[43:24] - Brian highlights the value of Ken's insights on dependencies and provides helpful resources and links.
[43:50] - Brian thanks listeners and invites them to share and subscribe to the Agile Mentors Podcast on Apple Podcasts.
[47:26] - 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®. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here.
[48:12] - 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:

Dependencies are Killing Your Agility: Learn to Fight Back!
Essential Scrum by Kenneth Rubin
Innolution
Dependencies Are Killing Your Agile Flow at Scale by Ken Rubin
#47 Exploring Lean Thinking In Agile Development with Bob Payne
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Mountain Goat Software’s Private Training
Certified ScrumMaster® Training and Scrum Certification
Certified Scrum Product Owner® Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Ken Rubin is the #1 best-selling author of Essential Scrum and world-renowned Agile trainer and coach. Ken focuses on full end-to-end business agility, applying agile ways of working with your development teams, technical and business leaders, executives, as well as the important non-development groups that are critical to providing your whole product solutions.

#84: Listener Questions with Brian Milner

7 februari 2024 | 33 min

Join Brian in this solo episode of the Agile Mentors Podcast as he tackles listener questions, discussing topics ranging from the impact of AI on Scrum teams to managing retrospective challenges and fostering active participation. Don't miss this episode filled with practical advice and thought-provoking discussions.

Overview

In this solo episode of the Agile Mentors Podcast, Brian answers listener questions unraveling everything from AI's role in Scrum to the complexities of Agile practices and team dynamics.

Listen in for valuable insights as Brian explores metrics for evaluating the effectiveness of product owners, offering key indicators for project success. He also discusses managing challenges within retrospectives, including strategies for handling upper management involvement, fostering transparent reporting, and the significance of visibility in sprint reviews.

Discover the art of promoting active participation in retrospectives—Brian underscores the significance of psychological safety within teams and offers actionable insights into tailoring retrospective approaches to your team’s diverse personality types.

Tune in as Brian answers listener questions with both practical wisdom and actionable advice.

Listen Now to Discover:

[01:18] - In today’s episode, Brian sits down to answer Agile Mentors Podcast listener questions.
[01:59] - Brian briefly shares a personal update about speaking at the upcoming Global Scrum Gathering 2024 New Orleans and invites listeners to attend.
[03:21] - The first listener question explores whether AI can replace members of a Scrum team. Brian discusses the current state of AI and its potential applications in different roles within a Scrum team. He also shares how his team is using “Goatbot.”
[08:10] - For the second listener question Brian tackles the issue of handling resistance to Agile from a team member, sharing some strategies to understand the root cause and address misunderstandings.
[11:48] - Brian introduces the third question about using metrics to judge the effectiveness of a product owner.
[14:47] - Brian discusses handling retrospective issues involving upper management, and the value of transparent reporting.
[16:42] - Brian explores scenarios about the cost of addressing an impediment and the importance of transparent decision-making by the organization.
[17:22] - Brian suggests raising visibility in sprint reviews and seeking assistance from stakeholders or powerful individuals to address unresolved issues.
[18:45] - Today's episode of the Agile Mentors Podcast is brought to you by Mountain Goat Software's Certified Product Owner Course. This is a two-day training course taught by one of our Certified Scrum Trainers to teach you how to use the product backlog as a tool for project success. For more information, visit the Mountain Goat Software Certified Scrum and Agile Training Schedule.
[24:39] - Brian explores the issue of low participation in retrospectives, and how to tailor approaches to different personality types for more active engagement. He highlights the work of Amy Edmondson, suggesting her research on psychological safety for deeper insights into team dynamics and participation.
[26:15] - Lack of safety may be the Scrum Master's responsibility.
[27:18] - Awareness of personality types is crucial for Scrum Masters. Brian advises varying retrospective formats to avoid monotony, including visual and written formats tailored to diverse preferences.
[30:38] - Brian thanks listeners and invites them to share and subscribe to the Agile Mentors Podcast on Apple Podcasts.
[31:23] - 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®. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here.
[32:39] - 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:

Global Scrum Gathering 2024 New Orleans
Psychological Safety – Amy C. Edmondson
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Certified ScrumMaster Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#83 Navigating the Challenges of Small Agile Teams with Scott Dunn

31 januari 2024 | 38 min

Join Brian and Scott Dunn as they journey into the heart of handling conflicts and challenges within small teams for effective teamwork in the latest episode of the Agile Mentors Podcast.

Overview

In this episode of the Agile Mentors Podcast, Scott Dunn sits down with Brian to delve into handling conflicts and challenges within small teams.

From the impact of hierarchies on team dynamics to the nuances of technical leadership, listen in as Brian and Scott tackle the intricacies of managing conflicts to navigate the delicate balance between individual excellence and fostering a collaborative team culture.

Listen in as Listen Now to Discover:

[01:54] - Today, Brian is sitting down with Scott Dunn to discuss the topic of handling conflicts and challenges in small teams, particularly regarding hierarchies and experience levels.
[03:17] - Scott shares his experience with issues arising from unofficial authorities, highlighting challenges with project managers and leads.
[04:03] - Scott talks about the transition to a democratic process and shares a humorous anecdote about a unique meeting disruption and the resolution.
[07:27] - Brian discusses the challenge of individuals feeling a loss of authority in the shift to self-organization and emphasizes the need for communication to address their concerns.
[08:27] - Brian categorizes leads into obstructive and unintentionally hindering types.
[09:27] - Scott discusses the need for aligning expectations with Agile principles.
[11:34] - Brian discusses the challenges faced by Scrum Masters and Agile coaches in identifying and addressing team dynamics, emphasizing the importance of clear communication, and understanding to resolve misunderstandings.
[12:07] - Scott shares an example of a scrum master effectively addressing a bottleneck issue with a lead.
[13:13] - Brian highlights a leadership misunderstanding where senior individuals are consistently assigned challenging tasks and the unintended consequences of pigeonholing experts into specific roles.
[14:35] - Scott shares experiences of individuals falling into roles they didn't initially choose, and the negative impact on job satisfaction.
[15:32] - The importance of promoting teamwork, continuous learning, and adaptability over being the sole expert.
[16:11] - Brian discusses the issue of knowledge silos and suggests a proactive approach within the team to mitigate risks and ensure knowledge sharing.
[16:32] - The importance of managing resource fungibility and avoiding bottlenecks.
[17:40] - Brian debunks the idea of job security for those deliberately hoarding knowledge and emphasizes the importance of staying marketable and adaptable.
[18:52] - Scott highlights the consequences of being difficult to work with and shares the secret for long-term professional success.
[20:00] - The Agile Mentors Podcast is brought to you by Mountain Goat Software and their Advanced Certified Scrum Product Owner® course. Plus, automatic enrollment in Mike Cohn’s Agile Mentors Community, including twelve months of ongoing coaching and support. To learn more, check out the Mountain Goat Software Certified Scrum and Agile Training Schedule.
[20:42] - How different roles, especially leads, should interact in a scrum team where equality is emphasized.
[21:34] - The importance of a lead developer having a mindset focused on helping others succeed and empowering the team.
[22:31] - Scott defines true technical leadership and the importance of empowering team members to scale workload and creating a culture of learning within the team.
[23:59] - The impact of senior team members as "pollinators of learning."
[24:56] - Brian defines a lead's role using sports analogies to illustrate leadership beyond individual excellence.
[26:48] - Brian shares the ‘see one, do one, teach one model for successful leadership and teams.
[27:57] - Leveling up expectations and helping and asking for help as a lead.
[32:32] - Setting the example by what you do, not by what you say.
[33:17] - The importance of leads in establishing culture.
[34:53] - Brian shares a big thank you to Scott for joining him on the show.
[35:29] - We invite you to subscribe to the Agile Mentors Podcast on Apple Podcasts. Do you have feedback or a great idea for an episode of the show? Great! Just 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, 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.

References and resources mentioned in the show:

Subscribe to the Agile Mentors Podcast on Apple Podcasts
Certified ScrumMaster Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#82: The Intersection of AI and Agile with Emilia Breton

24 januari 2024 | 31 min

Join Brian and Emilia Breton as they explore AI and its practical applications in Agile, from enhancing productivity to coaching. Don't miss their insights on AI tools shaping the future of Agile.

Overview

Today, Brian sits down with Emilia Breton to unravel the dynamic intersection of Artificial Intelligence (AI) and Agile.

Brian and Emilia share their experiences and experiments with AI tools, revealing how they leverage these technologies to enhance productivity and decision-making and amplify human capabilities.

Listen in to learn more about the evolving landscape where AI and Agile converge to shape the future of work.

Listen Now to Discover:

[01:25] - Brian welcomes Emilia Breton to the show to talk about the intersection of AI and Agile, focusing on using AI to enhance human connections.
[03:04] - Emilia shares that it's about using AI to accentuate our humanity and create space for us to connect, observe, and inspire.
[05:15] - Emilia discusses the questions about copyright for AI-produced content, such as code and why It's important to be able to trace where AI-derived information comes from.
[06:02] - Brian reflects on the rapid evolution of mass-consumable AI and its transformative impact over the past year.
[06:39] - Emilia underscores the importance of visibility in AI outputs, and the need to cross-verify AI-generated information with human expertise.
[08:41] - Brian introduces the concept of hallucination in AI, emphasizing that AI can't think or reason, and it may generate false information to please users.
[10:29] - The importance and irreplaceable qualities of human competence.
[11:30] - How tools like Lucidspark can help with ideas during product brainstorms or retrospectives. Otter.ai and Spinach.io can automate tasks like taking meeting notes and updating Jira, saving time for more important work.
[14:16] - Brian introduces Rewind.ai, a tool that records computer activities for later recall, explaining its potential benefits and privacy considerations.
[16:10] - The Agile Mentors Podcast is brought to you by Mountain Goat Software and today’s episode is brought to you by Mountain Goat Software's Certified ScrumMaster Class a two-day class covering the fundamental principles of scrum as well as detail about the different roles, meetings, and artifacts. For more information click on the Mountain Goat Software Certified Scrum and Agile Training Schedule.
[17:01] - Emilia explores the use of AI to spark inspiration, and shares generative AI art programs DALL·E or Midjourney.
[20:06] - Emilia discusses using Grammarly and AI as a partner in content creation, to iterate prompts to achieve the desired tone and style.
[21:10] - Discussing Google's new multimodal Gemini models, which can translate speech, text, video, and images.
[22:07] - NotebookLM is designed for researchers to organize and refer to research papers and articles. Brian shares his experience with this tool.
[22:48] - The speakers discuss using AI for data analysis to interpret large datasets, capture notes, brainstorm ideas, and facilitate retrospectives to enhance Agile practices.
[25:08] - Brian and Emilia discuss how AI can be a valuable tool in coaching and can assist in facilitating sessions.
[28:08] - What lies ahead with AI?
[29:24] - Brian sends a huge thank you to Emilia for being on the show. If you found this episode useful, please share this episode with others. We’d love your feedback and suggestions for future episodes. You can email us at [email protected]. And don’t forget to subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode.
[30:09] - If this topic was impactful to you and you want to continue the discussion, join the Agile Mentors Community where we have a topic discussion for each podcast episode. You can get a free year-long membership in the community just by taking any class with Mountain Goat Software.

References and resources mentioned in the show:

Emilia Breton
Lucidspark
Otter.ai
Spinach.io
Rewind.ai
DALL·E
Midjourney
NotebookLM
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Certified ScrumMaster Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Emilia Breton is an Agile wizard with over two decades of experience, who effortlessly navigates the realms of startups and global corporations. Specializing in guiding both scrappy ventures and colossal entities, she brings innovative approaches to software development and team building. Emilia's commitment to injecting playfulness ensures a dynamic and creative touch to Agile practices, making her the go-to coach for those ready to elevate their software development game.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast. I'm with you as always Brian Milner, and today I have a very special good friend of mine who's come on with us. Miss Amelia Britton is on with us. Welcome in Amelia.

Emilia (00:15)
Thanks, Brian. It's great to be here.

Brian (00:17)
So glad we've finally been able to do this. I've been trying to arrange our schedules to do this for a while. So it's hard to really pin Amelia down on one thing that I would say, here's who she is, because she's a lot of things. I think coach, if I just said coach, I think that would be a very good term, because she's a very, very good coach. And... She's credentialed with the Scrum Alliance in that area. She's got the highest credential with IC Agile in this area. She's an IC Agile expert. She's worked the gamut. She's worked with startups. She's worked in very, very large companies. And we got to see each other in person at Agile 2023 last year. And really, that was the first time I think I've seen you in person in a while. And it just was really fun to see you and get to catch up there. So we thought we'd get Amelia on. And she's been doing some talks recently along a certain topic that I know people are really, really interested in. But it may not be exactly where you think we're going with this. But really it's talking about AI and Agile as it plays into AI. But like I said, it's not going to be, I think, where most people think we're going to go with this. So I'm talking too much. Emilio, why don't you take it from here? If it's not going to be where most people think we're going to go, how would you sum it up where we're going with this?

Emilia (01:49)
I think really it's about using AI to accentuate our humanity and create that space for us to do what we do best as humans, which is connect and observe and inspire.

Brian (01:54)
Mm, I love that. That's awesome. Yeah, I love that. So just to lay the foundation here a little bit, neither Amelia or myself are AI engineers. Neither of us work for open AI or anything like that. We are not in the thick of that AI world. We're consumers. We're consumers of it. And we're tech people. So We've spent our lives in and around software development teams. And that gives us a little bit of a unique perspective. I think that combined with the combining Agile with AI, I think, also is the other unique kind of perspective we're trying to bring to this. So let's kind of dive into this a little bit. When we start talking about AI and Agile, What are the kind of considerations you think are the most important things we should be dealing with when we start to delve into this area?

Emilia (03:07)
Yeah, I think one of the really first important things to know is to really think a little bit about the sort of ethical considerations when you're starting to use AI. You know, there's there are many privacy concerns. You know who owns the thing that you've created. Do you own it. Does it belong to everybody. The ownership of the things that this was trained on and knowing what it was trained on and where the data comes from. How do you keep your data safe and secure? Anything, you know, it all depends on what are the rules of the thing that you're putting your data into. Sometimes you're putting data in and you retain it as exclusively yours. And sometimes you're giving it to the model. So you want to be really careful in knowing what you're doing, knowing what the model is, and then making your own sort of ethical determinations around that. and what you want to use.

Brian (04:03)
Yeah, there's a, you know, I dabble in music sometimes and there's some interesting channels I followed on music with AI. And, you know, there's kind of a, there's one gentleman in particular who talks about copyright and music and AI. And one of the things that he proposes is that if it's AI produced, that he thinks there should not be a copyright for the content because it's not created by a human, it's created by a machine. And I found it to be kind of an interesting take on it. You know, and I wondered how that would play in our space. You know, if a machine writes code, is it private?

Emilia (04:41)
Yeah. And there's a lot of questions that kind of come around that. And right now, it looks like if you're following any of the big legal cases that have happened, that it may actually lean to, if you created it with the AI, you might not own it. So it's a consideration if you're starting to use any of these tools. Another one that's really big for me is explainability. So being able to tell.

Brian (05:05)
Okay.

Emilia (05:07)
where the AI got this information. Different models, different applications, you are better or worse at this. Certainly a lot have gotten better over the last few months. I mean, we're only really a year into this mass consumable AI world. I mean, certainly AI has been around since forever and big blue, but the mass consumption of it being available to you and I to just...

Brian (05:24)
Right.

Emilia (05:34)
go on the internet and use really came with chat GPT and those a year ago this week. So it's a new field. And we've gotten this much in a year, which is just, you know, we're in technology, we're in one of these growth curves. So everything's changing. But explainability like Google's model probably does it the best. They give you really great links. Others, you just don't know.

Brian (05:41)
That's amazing, isn't it? Yeah.

Emilia (05:58)
And there's a lot of push within the AI ethics community to really make that visible and be able to see. Because AI actually isn't competent, right? It doesn't actually know the things. In pretending, it is performing of being intelligent and competent. And so it's also important to keep that in mind. And that's one of the powers that we have as humans, is intelligence.

Brian (06:09)
Yeah.

Emilia (06:26)
We actually do have that competence to be able to check the AI, to be able to figure out, you know, is what it's saying true or not. There was an instance I was creating, I had a list of books and I said, OK, great list of books. Tell me more. Give me some more answers that are like this. Right. And one of the books it came up with, it was perfect. It was talking about

Brian (06:43)
Yeah.

Emilia (06:53)
Agile in Enterprises versus Startups. This was like exactly the book I wanted to read. I was so excited about it and it told me that it had been written. I think it was Diana Larsen and someone else. I don't remember who the other person was, but I was really excited because these were two people who I was like, oh, yes, I know they collaborated on a book. This is gonna be fabulous.

Brian (07:13)
Oh wow. Yeah.

Emilia (07:21)
Um, and I went to Diana's site and it wasn't there. It was like interesting and then Amazon and wasn't there. Um, and I went to the other individual site and it wasn't there. And I went to Lean Pub because you know, a lot of times we as Agilist will start something on Lean Pub. Um, and it wasn't there. Um, and I DMed Diana. I was like, I'm so excited. Tell me more. She's like, uh, not a book.

Brian (07:25)
Ha ha ha. No idea what you're talking about.

Emilia (07:50)
like, well guess what book you should write? Because it would determine like this is the book that you want to read and it fits with these other books. So interesting and scary but I totally hallucinated this thing existing. Had an ISBN number, had the authors, had a publish date, had a publisher. All the things that looked like a proper citation.

Brian (07:53)
Right. Yeah, that's an important thing for people to know. If you haven't really gotten too far into it or if you really kind of stayed out of it, the term hallucination is a term you'll become familiar with at some point because like Amelia said, it doesn't think, right? It can't think, it can't reason, but it is programmed to try to please you. It is programmed to try to give you what you want. And if it doesn't have the data, Sometimes it does this thing called hallucinations where it'll make it up. It'll kind of create it based on the data that already has. Yeah, I remember I've tried to push it in certain ways. I like to do a lot of just testing the boundaries. So I know from early on to, you know, for the past year, there have been times when I've done things with things like Chat GPT, where I've tried to push it and say, what's the answer that you have for this or... You know, and one of the things with Chat GPT is it's not, or at least for a period of time, I guess now it is kind of connected, but for a period of time, it was not directly connected to live data. So there's no way you could have it search the internet and find something out. Now there are ways that you can have it do that. But I remember early on trying to get it to tell me the score of a game. And it was a professional sports game. And it said, oh, yeah, here's the score. Here's what happened. These are the stats from the game. No, that game hasn't happened yet. It's this date, and that's not happening till. And you'll get that typical response. I apologize. You are correct. I did not. I apologize for giving you incorrect data. Right.

Emilia (09:55)
Yeah, I've only been trained till September 2021.

Brian (09:58)
Right, right, right. So that's something to just be familiar with is, like you said, it can't reason. It's really approximating what it's doing to you based on all the huge volume of data that it has and trying to craft a response that is similar to the data that it's already been fed. So I'm probably telling people things they already know, but just in case you didn't know that, wanted to state that.

Emilia (10:23)
But it's super important to always keep that in your head. And this is one of the places where AI really can't replace us. We are truly competent. We are truly creative. We are truly innovative. And that's the place where we as humans really stand out. And I've been using AI for a bunch of things and experimenting with at my work. Fortunately, I work for a startup, so things are much easier to get through. It's a matter of having a conversation. having one of our wonderful legal team take a look at things and then give me the go ahead. I don't have a lot of red tape that I'm sure some of your folks who are in larger enterprises may have. But I've had the opportunity to play with a bunch of things that have been really helpful. I sort of, there's like two sort of categories of things I've been looking at. The first one is stuff that automates the non-promotable work. So.

Brian (11:15)
Yeah.

Emilia (11:16)
All of the little things that we have to do that take a lot of time, but nobody's gonna remember you for. Nobody is going to remember you for taking wonderful notes of that meeting. Nobody's gonna remember how accurate you were at updating Jira. People are gonna remember the impacts that you made on them and their teams. And that's the work I wanna spend my time doing and not spend as much time on the other stuff.

Brian (11:43)
Right.

Emilia (11:45)
So I've played with a bunch of different apps. I don't know if it's okay to talk about specific ones. Yeah.

Brian (11:48)
No, yeah, please go ahead. Yeah. I'm sure people want to know some, want some tips. Yeah.

Emilia (11:53)
Yeah, so like one I love is Lucid Spark. So they are one of the mass of collaborative whiteboards and they have some really beautiful AI features. They're just ubiquitous built into their product that help when I'm facilitating. So I can have it take our massive wonderful, creative, messy ideas that we've all come up with when we're like doing a product brainstorm. And then... sort them all up so that we can really quickly like in moments as a team look at okay here's some different ways that this might be sorted where do we want to go next what do we want to do next um and that's just a super useful piece that they have and then say i'm done with that or i'm done with a retrospective to be able to get a okay let me select all the stuff and then give me a summary of what are all the things that happened

Brian (12:42)
Yeah.

Emilia (12:50)
And then I edit it because we're humans and we need that part, but it saves a lot of time. These are pieces that are just, it's using the technology to give us time to have better conversations, to have to work better as a team. It's just taking that out. So that's one that I love. There's another.

Brian (12:56)
Yeah. Yeah, I think of that, you know, I've tried to say to some people that it's more on the level of like a spell check, you know, like I don't I don't look at it like, you know, like I said, it's not it's not creating its own ideas. It can help you brainstorm, it can help you do things, but it does still have that human element that it requires to refine and to push back a little bit and say, yeah, but what if we went this way? So it's good if you look at it as this is another tool, this is a tool that can help me do things, yeah.

Emilia (13:43)
snack them. And there are a ton of tools that do that. You know, there's some great tools that will take your meeting notes for you. Otter.ai, Spinach.io are two that I've used that are pretty good. You know, Spinach has the plus of, it'll go update my JIRA for me, which of course we love. But they're things that are, they just take all of the bits and pieces and they do them for you. so that you can spend the time on the important stuff. And that's one of the things I'm loving with a lot of these nutrients.

Brian (14:14)
That's awesome. Yeah, there's one that I've come across as well. I'll just throw out there. And we're not plugging anything, trust me. We're just sharing our own experience. But there's one that I have used a little bit often on an experiment with, it's called Rewind. And yeah, now some people might think it's a little creepy. So let me explain and then you can decide if that's something you wanna experiment with or not. But Rewind basically kind of records everything on your computer.

Emilia (14:21)
No. Yeah, that's a pretty good one as well.

Brian (14:44)
I mean, you can tell it what not to record. You can say, don't do this. And you can set it up so that it will ask you any meetings. Should I record this one or not? But basically, it's sort of there in the background. And then you can call it up and say, I saw a website that was about this, or I saw something this week, or there was a meeting I was in where we talked about this topic. Can you recall that for me? And it'll say, yeah, here's the meeting, and here's the transcript of that part of your meeting where you talked about this thing. So I've heard people say it's sort of like my extended brain. And it does, I mean, my understanding is it's just local. It's not putting that out into the. world anywhere, it's not saving your data anywhere else, and you can control how much data it saves and everything else. But I understand that might have some privacy concerns, especially depending on someone's industry. If you're in a very highly secure industry, that might be a huge warning flag. So it's to each their own, I get it. But that's kind of where it's at, that boundary of let's see if it can do this. Oh yeah, it's actually. It actually can do this and it can do this pretty well. Yeah.

Emilia (16:04)
Yeah, and there's also like that's consent at that point becomes really important. Right, you're putting on your choosing, you're giving your consent to this thing. It's something you know, you wouldn't want somebody to impose upon you. That's when it goes from the useful tool into like creepy dystopian world, right? It's all about the consent and all about knowing and traceability and that kind of thing. And I think, you know, when you talk about some of the

Brian (16:23)
Right.

Emilia (16:32)
ethics folks, they are worried about crossing that line. It's just a matter of being aware, I think, at this point. And the other play way I've been using a lot of AI is for really working and helping it to spark and inspire stuff. And I've been doing a lot of that with using it to create metaphors. So.

Brian (16:39)
Yeah. Yeah.

Emilia (16:54)
One of my favorite things I've used it both in one-on-one coaching and then also in like team retrospectives is using some of the generative AI. I've used some of the generative AI music, some of your generative AI art programs like Dolly or Mid Journey to take what somebody is feeling, thinking, seeing about the situation, the sprint, and then having them write the prompt. to create that piece of generated art that they can then share because it takes us beyond our words as humans. And into that so that you can see visually or hear what I'm feeling and it creates this lovely emotional tone that lets us go into different places and ask different questions of each other in say a team environment or of an individual ourselves in a coaching kind of environment. It's really powerful because it's taking, you know, before we would say, okay describe it, tell me more about that. But to be able to show it, put it on the table, and then for that individual to look at it, or to listen to it and pick a part and tell me about this part, tell me about that, how does this connect? It just creates all of these other areas that we can explore. And that's the stuff like we're humans when we really excel.

Brian (18:16)
Yeah. Yeah. Yeah, that's a great point. And it's, you know, when we forget that, when we forget that and try to lean too heavily on it, then it's painfully obvious. It becomes really easy to spot and you're like, this is not human. This is not, this has no soul to it. This has no, you know, creativity or imagination. It's just spouting back stuff that I've seen and heard before.

Emilia (18:46)
million.

Brian (18:46)
But yeah, I think you're right. You know, if it can inspire me a little bit and say, yeah, I'm looking for something like this, give me some examples. You may get 10 examples back and then think, no, none of those are exactly right. But I like kind of how number seven talks about this. What if you gave me several examples like number seven, but tweak it this way? So that's the kind of. For me, that's the kind of back and forth that it takes to get something usable. It's just not write a book, here's the book, you know?

Emilia (19:20)
Yeah, I think one of the things that really we as Agilent have the power when we're using some of those AI things like chat GPT to generate content is the iterations that we're so good at. You know, I've done some work with like, okay, I'm going to use GPT. I'm going to use one of the large language models. Let me to get me started on writing a large piece of content. And then you iterate, you're like, no, more this, less this. What I actually like in that is less than starting the content and more, here's my piece of not very well-written content with all of my ideas and all these things. OK, so help me turn this into a tone that is more ABC. I love Grammarly for this. But give me a more playful tone. Give me a more.

Brian (19:58)
Thanks for watching. Right. Yeah.

Emilia (20:14)
business tone and you can take the same piece of content that you've written and then tailor it to different situations. Well it's still you. And iterating on that prompt like, you know, less marketing jargon, more, you know, and really till you get that piece. Kind of acts as a partner to help you inspect and adapt. To get it just the way you want it.

Brian (20:24)
Yeah. Ha ha ha. That's awesome. Yeah, and I like the idea of thinking of it kind of like a translator. You know, like when you talked about the images and stuff, that's what was going through my head is, you know, there's some people who do really well at creating images and drawing and digital artwork and everything. And there's other people who don't really know that language, don't know how to do that as well. But if we can have something that I can describe it to and it can create it for me, it's just a translation. It's taking my words, it's taking what my idea was and showing me a version of that. I can tweak it, I can push it one way or the other, but it's just giving a vocabulary, if you will, to my idea.

Emilia (21:26)
Exactly. And I think these are the things that are only going to get better. You know, we just recently had the release of Google's new Gemini models, which are multimodal, which is a whole other realm. So how can I take and translate, you know, speech and text and video and still images?

Brian (21:37)
Yeah. Ha ha ha.

Emilia (21:51)
and bring them all together into something. I'm really excited to play with them as they start hitting because I think that's the thing that's really going to unlock our power to do some really neat things together.

Brian (21:56)
Yeah. Yeah, I agree. By the way, there's a tool I'll mention as well that I've played with recently that I'll give a shout out to. Because for some of the stuff I've been trying to do, gather research and draw some conclusions from it and everything else, it's been a really helpful tool for that. Google has this tool out that's called Notebook LM. It was designed specifically for researchers. It allows you to, it's in the same mode or realm as sort of a custom GPT kind of thing, but you feed it research papers, articles, you feed it things that you've been using as a basis, and then it can help you. to refer back to the right thing and say, show me all the research about this, and it'll bring it up for you. So it's sort of just like a research assistant that you can use and you can create different little notebooks for different topics and other things. So I found that to be really, really useful. And that's kind of one of the newer tools that's out there in their experiments as well.

Emilia (23:08)
Yeah, I've been experimenting with OpenAI's data analysis and feeding it. So I have a set of surveys that I use with teams to really kind of look at, you know, where's your agile fluency? What are some of the markers of this team on their journey and different things like product, et cetera? And then feeding it these things and having it, you know, tell me more, you know, give me some analysis on this.

Brian (23:13)
Hmm, wow.

Emilia (23:33)
And I found it one that I had done previously. Usually when I take in a bunch of them, it takes me about a week to compile things, look at standard deviations, pull some things out about what I'm seeing as patterns. And it was able to produce the stuff that usually takes, again, I'm both human, around a week. I was able to do it. I mean, it did stop and start and feed and ask questions. And so there's tweaking. but probably within about 10 minutes on not terribly well clean formatted data. And its conclusions matched very closely with what I had done as far as analyzing the data. Now, of course, we take that and then based on that data analysis, what does that really mean? That parts us as humans. But it's a huge time saver when you're looking at large pieces of data.

Brian (24:19)
Right. Yeah, it's fascinating the kind of tools that are available to us, like you said. So this is great. I just want to reiterate a few things here. If you're... Working on Scrum teams, and you haven't considered doing something like this in the past, there are tools that could help you capture notes from maybe a sprint planning session or a sprint review. There are tools where you can help brainstorm new ideas for a retrospective or even take action items from that retrospective when you're done. So. This is what I'm saying, this is what I meant at the beginning. We're not going into the typical kind of areas with this. There are small little things that you can use this for today that I think can really give you a boost and enhance your practice.

Emilia (25:16)
Exactly and give your team the time for the stuff that your team is really great at It gives you the time more time to collaborate more time to have the conversations about how might we or what might we? Where we are wonderful Nope like I said before nobody's gonna remember you because you took great notes

Brian (25:21)
Yeah, that's great. Right. What about, and I know we're pushing up against our time, we'll try to wrap things up here, but what about because you have a lot of experience in the coaching realm, what about tools in that kind of aspect? How have these tools helped in sort of coaching practices?

Emilia (25:54)
Yeah, so one, obviously the metaphor I spoke about earlier, helping inspire those ideas and let us ask deeper questions, kind of, it's really great to put, say, a picture out and be able to tell me about this, tell me what's the significance of this, what do you see, what do you, or with team, what do you notice about this pattern of pictures? That's one I've used. Another one is I've used it just for my own sort of self-improvement.

Brian (26:21)
Hmm.

Emilia (26:22)
Um, I have a custom GPT that I trained and I fed it, you know, a bunch of stuff around ICF coaching ethics and how to be a great coach as far as those things. Um, and then I fed it some other, um, agile resources like the agile coaching growth wheel, um, and I've used it just to sort of have it ask me questions as I start exploring where do I want to go next. What do I want to do next? And I certainly have deeper more meaningful conversations with my human coaches Who coach me because I believe everybody needs a coach But they help me sort of sort my ideas and think about different areas and different things That I might not have thought of They're certainly not actually coaching me, but it does do pretty well at you know

Brian (26:57)
Sure. Ha ha.

Emilia (27:15)
pulling out those pieces so that I can think about what I need to think about and get a little bit out of my head. And it's useful for that.

Brian (27:21)
Yeah, that's awesome. Yeah, I haven't even thought of using it for something like that, but that makes perfect sense. Again, it's just a tool. It's something that you can use to give you a push maybe in one direction or the other. But at the end of the day, it's still on you. It's still on you to actually do the work. That's awesome.

Emilia (27:37)
Exactly. Yeah. Another quick one I do is like, it's really good at taking all of your notes for a session and building a nice facilitation guide. It's easy to follow.

Brian (27:50)
I hadn't even thought of that. That's awesome. Yeah.

Emilia (27:52)
And like pieces like that are just like, just, it's like having, you know, it's like having an intern. Doesn't know anything. Who's brand new and fresh. But that fresh set of eyes can be useful.

Brian (27:59)
Yeah. Yeah. It's such an exciting time. I mean, I really, to me, it's just, like you said, it's only really been publicly around for about a year. And what we're talking about here is more these large language models. And we're not even really getting into machine learning and what might happen in this coming year with the combination of those two things.

Emilia (28:22)
Exactly.

Brian (28:28)
And then we're really cooking with gas, right? Then we're like, that's going to be amazing to see what kind of things come out of that combination. 2024, I think it's just going to be a really interesting year. You know, I know when that happened last year, I thought, you know, this feels a little bit like when the internet kind of launched. It's that kind of wild west kind of feel to things. And It feels a little like that's happening now, in this realm.

Emilia (28:56)
Yeah, I think it's going to be really interesting.

Brian (28:57)
All right, well, this has been. Yeah, I agree. Well, Amelia, this has been really interesting. I've had a really good time talking with you about this stuff. It's, you know, we could talk about this for a long, long time. And it might be interesting for us to check in maybe next year and say, look what's happened since the last time we talked. Here's where it was then and let's see where it is now. But thank you for proposing this and coming on and talking with us. And I really appreciate you sharing your research and learnings and insights on this recently.

Emilia (29:30)
Thank you.

#81: Unleashing the Power of Visual Storytelling in Product Ownership with Stuart Young

17 januari 2024 | 39 min

Ever wondered how visuals can transform your role as a product owner? Join Brian as he sits down with visual storyteller Stuart Young to unravel the power of visualization in product ownership. Join them on a journey to discover the art and science behind being a successful product owner.

Overview

Ever wondered how to elevate your product ownership game? In this episode, we delve into the world of visual storytelling with Stuart Young.

Join Brian and Stuart as they discuss the diverse tools, such as story mapping and the product disposition canvas, that can bring your product visions to life.

From storytelling techniques to the neurodiversity lens, we explore the art and science of communication that transcends traditional boundaries. Listen in to uncover the impactful ways visuals can shape your product strategy.

Learn how being more visual can sharpen your skills, foster collaboration, and create a more inclusive and successful product development journey.

Listen Now to Discover:

[00:23] - Today welcomes Stuart Young, a Certified Scrum Trainer and visual storyteller to discuss storytelling through the product lens and more.
[03:32] - Stuart discusses drawing large-scale pictures at conferences and recommends Visual Meetings and Visual Leaders by David Sibbit.
[06:54] - Stuart emphasizes the impact of visual storytelling on individuals, highlighting the universal language and information retention through visuals.
[08:46] - The benefits of visual representation in capturing the flow of ideas and aiding memory.
[10:26] - The importance of varied methods for engaging different learning styles.
[11:41] - Stuart discusses the value of visualization tools such as roadmaps, post-it notes, and story mapping to provide clarity and a clear narrative.
[12:14] - The importance of blending Stuart references Pixar and Ed Catmull's book Creativity, Inc., discussing the importance of blending exciting elements, like storyboarding, in motivating teams and creating a compelling narrative.
[15:13] - Stuart emphasizes the importance of authentic storytelling, even if it doesn't always have a happy ending, he references TEDxHogeschoolUtrecht - Steve Denning - “Leadership Storytelling" for further inspiration.
[15:25] - Brian recommends Simon Sinek's TED talk on "Start With Why" as an example of effective storytelling despite not being visually polished.
[16:09] - Stuart praises Henrik Kniberg's impactful video on product ownership, acknowledging the simplicity of the drawings but highlighting the potency of storytelling. He recommends the Sketchnote Handbook by Mike Rhodes for those interested in delving further into storytelling.
[17:08] - The Agile Mentors Podcast is brought to you by Mountain Goat Software and their Certified Scrum Training Classes. For more information, click on the Mountain Goat Software Certified Scrum and Agile Training Schedule.
[18:38] - Stuart highlights the significance of visual elements in crafting compelling visions and underscores the value of utilizing available templates, from sources like the Gamestorming book.
[20:06] - Stuart discusses the role of visualization in making the intangible tangible, particularly in the tech space.
[21:50] - Brian emphasizes the imprecision of words. He also discusses the value of showing rather than just telling, especially in product requirements, to enhance understanding and avoid delays caused by miscommunications.
[23:34] - Stuart reflects on how visual communication can enhance inclusivity. He shares, “For people with reading and writing difficulties, pictures and symbols are better. The worst, the most abstract form, of course, is the word.”
[25:22] - The role of a visual storyteller as a "human cursor" connecting diverse conceptual thinkers. Stuart recounts an illustration experience, emphasizing the challenge of visualizing details without clear specifications and underscoring the mantra of "process over art" in product ownership.
[28:06] - Stuart underscores the product owner's role in leveraging the unique skills of team members to converge on a shared understanding of what "good" looks like.
[29:19] - Brian references the episode of the show they did on Navigating Neurodiversity and the importance of understanding and accommodating different communication styles within a team. He highlights the need for product owners to be aware of the preferences of their team members and adjust communication methods accordingly.
[30:54] - Stuart introduces the product disposition canvas and shares a personal revelation.
[32:54] - Brian acknowledges the potential superpowers that come with neurodiversity, sharing his own experience of a late-in-life ADHD diagnosis and the benefits of leveraging the unique qualities each team member brings to a team.
[33:36] - Stuart reflects on the importance of recognizing individual strengths and blind spots, emphasizing that everyone has a valuable contribution.
[34:20] - Stuart encourages recognizing individual strengths for collective success.
[35:23] - Listeners can connect with Stuart on LinkedIn and at Agile Nuggets | Agile Tips
[37:38] - Please share this episode with others if you found it useful. Send feedback and suggestions for future episodes to [email protected]. And don’t forget to subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode.
[38:21] - If this topic was impactful to you and you want to continue the discussion, join the Agile Mentors Community where we have a topic discussion for each podcast episode. You can get a free year-long membership in the community just by taking any class with Mountain Goat Software.

References and resources mentioned in the show:

Stuart Young on LinkedIn
Agile Nuggets | Agile Tips | Cprime Learning
Scrum in Under 10 Minutes
#76: Navigating Neurodiversity for High-Performing Teams with Susan Fitzell
David Sibbet
Visual Meetings by David Sibbet
Visual Leaders by David Sibbet
Creativity, Inc.
Sketchnote Handbook by Mike Rohde
TEDxHogeschoolUtrecht - Steve Denning - “Leadership Storytelling"
Simon Sinek: How Great Leaders Inspire Action | TED Talk
Agile Product Ownership in a Nutshell by Henrik Kniberg
Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Certified ScrumMaster Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Stuart Young, a Certified Scrum Trainer and Visual Storyteller, merges Agile methodologies and design thinking to empower individuals and teams. As a thought leader, he champions Visual Storytelling for engaging stakeholders, addressing customer needs, and expediting learning. Through workshops, Stuart encourages teams to embrace visual methodologies to achieve business success.

Auto-generated Transcript:

Brian (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. And as always, I'm with you, Brian Milner. Today I have a guest with me that I've been trying to get on for a while. Our schedules have been kind of misaligned a couple of times, but we're really, really fortunate to have him with us. Mr. Stort Young is with us. So welcome in, Stort. I'm glad you're here.

Stu (00:22)
Hello, it's lovely to see you. Yeah, time zone differences and the bit of water between across the pond has stopped us, but we are here. It's lovely to see you.

Brian (00:31)
Just a tiny bit of water between us, tiny. Stuart, for those who aren't familiar with his work, Stuart is a product trainer, a visual storyteller. He's a certified Scrum trainer, as I am. And if you ever attend a conference that Stuart's at, you will know who Stuart is, because he does this wonderful thing at a lot of conferences where he documents

Stu (00:33)
I'm going to go ahead and turn it off.

Brian (00:58)
the content of the conference on this giant kind of mural. And it's really amazing to see. I remember feeling like a celebrity at Agile 2023 because my talk, you know, Mike and I's talk ended up on the big board. And I'm like, wow, now I've made it. Stuart captured our talk onto the big board. That just was a great feeling. So, Stuart is a very, you know, tell them, tell them a little bit about visual storyteller. What do you mean by visual storyteller?

Stu (01:28)
Yeah. So apart from sort of looking very tired at conferences and holding lots of pens and being with big bits of paper. I think that it's becoming more and more common in training classes and in the business space, the use of visuals, which is wonderful. I think it's a great thing. We think about different preferences of learning. And I guess the best way to describe it is visual literacy. the days of school, you know, we, we learned to, uh, we learned to navigate a children's book using our visual literacy. So that's really what it's all about. And, um, and when you see me in a conference drawing in sort of large scale pictures, the, the idea is really to, to minute, minute meetings and conferences and talks in pictures to make the information more engaging, try to synthesize the key points. and help with the retention of memory. So that's kind of it. The focus should be communication over decoration, but of course I like to make things look nice.

Brian (02:33)
And they do, they always look amazing. Stuart was also speaking at Agile 2023 and he had a talk that was using this kind of same visual storytelling, but it was storytelling through the product lens. So I know that's what we're gonna be talking about a little bit here throughout the course of our conversation. I mean, loosely, we might dabble in some other areas as well, but... Yeah, I know I encountered this, you know, when I first started going to conferences and started to see this and, you know, I'll share with you Stuart, probably what a lot of other people think when they think about doing this kind of stuff is, boy, I'm a terrible drawer. Like I can't draw at all. You know, my penmanship is horrible. I can read what I write, but you know, lots of other people can't read what I write. unless I'm really careful and taking my time. So I'm sure you get a lot of people when they see this and think about being a visual storyteller and trying to capture notes and story noting things that they kind of have that objection of, well, I just can't do that. How do you respond to that kind of real common objection?

Stu (03:38)
hopefully. Well, you know, the thing is, it's so common and it's really sad. And, you know, it's a cliche and it's obviously, we've all heard the Picasso's quote, we're born artists, but we grow out of it. And I think that's the real problem. And the sad thing is that as adults, we have so many inhibitions that we can't draw. And I think that that's the really the key point to make. And I've mentioned it, my little quote about communication over decoration and process over art. You can get better, you can focus on improving your pen mastery, but the focus should be on trying to communicate information. And there are tricks and tips to do just that. I think that people need to sort of change their mindset that they're not trying to draw a lovely picture that they're gonna frame as a wonderful output, but it's more a case of a facilitative tool. And especially in the sort of space that we're both in. And as I'll talk a little bit more about product ownership, you know, you're the gift of drawing is to bring people on a compelling journey or bring developers closer to end users. It's all about the art of storytelling. So you've got to really just let go of your inhibitions and, and remember that you're there to help people to communicate. There's a lovely, uh, saying, well, not saying it cool. There's a guy called. Dave Sibbitt from Grove Consulting in San Francisco. And he's a guru in the visual facilitation space. A couple of books that I'll bring out here, just by Dave, just so that any of you are keen to learn more. There's a lovely book called Visual Meetings and Visual Leaders by Dave Sibbitt. And he calls himself the human cursor. Not that he's smart, but like a laptop cursor in that you're not there. If you spell something badly or you draw something badly and you get that terrible cold sweat when you're at the flip chart, it's really not about you. It's really about the communication that you're trying to create. So I think that would be my first sort of tip.

Brian (05:53)
Yeah, yeah, that's really good. And, you know, when we think about this, I don't want people to get lost in this. I don't want you to think, well, I don't speak at conferences, so I don't really need to tell a story to a big group of people. Or, you know, I don't routinely hold big meetings in my organization. I know this is something that can even be really impactful just individually, right?

Stu (06:21)
Yeah, absolutely. Absolutely. I think that there's some of the key motivations for using visuals is the way in which we receive information and we can obtain information and it is, it's a universal language, which is really powerful, how we can retain that information and so even if you're thinking things through, you know, I have a lot of people come to me and say, Oh, you know, I don't really draw Stu, but sometimes I'll just scribble in my sketchbook, some ideas and like, I'm sorry to tell you. That is drawing, that is thinking conceptually. So I think that the process of the patterns that we create, in this very volatile and certain world that we live in, some things that are so abstract with the written word that just drawing something out is really important. So I like that you say, it's a really good point that's worth emphasizing on. I think a lot of the benefits of visual storytelling. in the product space is really about that collaboration and great thing about visual storytelling is it's, it's impactful for you as an individual, as much as it is for a group. I think a lot of the focus I have when I'm, I'm training in teaching and facilitating this stuff is all around that collaboration, but you as an individual. you grab a sketchbook and you're drawing out ideas and you're thinking through things, that's the sort of the power play really and it really does help with that sort of retention of ideas. So, you know, doing it on your own, working in a group, I think it's always really useful.

Brian (07:57)
Yeah, I know I've had that happen to me. That was something that I had to try to learn a little bit was just the, I would scribble a bunch of handwritten notes and I'd come back to them later and be like, what is this about? And it's hard to really follow my train of thought going through this. But when I started to draw some things and started to have a little bit more of, oh yeah, this idea flowed to this. And then that, the visual nature of that really allowed that kind of to mimic that chain of consciousness that I was having at the moment, you know, when I encountered it. So that, to me, I know personally that became very helpful, yeah.

Stu (08:32)
Yeah, absolutely. So, so just picking up on what you said there, uh, another motivation that I talk about is that divergent convergent thinking. So just sort of separating the two things out there, which is of course, something very useful and from a product ownership perspective, the divergent thinking, that diversity of thought that comes from the drawings. And, um, without going too geeky on you, um, in the world of business and scrum. know, the world is, it's riddled in what we call ideographs. So if you think about refinement or any of the scrum values, they're all, they're all, when you draw a picture to represent focus, for example, it's a picture that represents an idea or concept. And so it's very difficult to draw some of these things. However, it provides wonderful variety and it provides diversity, because we'd all draw something differently. So that's the first thing that's really nice about drawing is it really offers that opportunity to, to generate ideas. And when you were saying about sort of, well, how do I converge on that? How do I know where I'm going? That's kind of the idea behind the product disposition canvas and not just the canvas I created, but the business model canvas, a good old fashioned SWOT analysis, the value proposition canvas.

Brian (09:45)
Hmm.

Stu (09:53)
any, you know, any of the great templates that we see from some of the great thought leaders in our space, all of these things are providing a level of convergence. So, you know, the drawing itself helps with the convergence, the frameworks and the frames that we use, the templates we use, as well as visual metaphors like the sailboat are all anchoring things and then bringing us back onto the same page.

Brian (10:18)
Yeah, that's something I try to talk about with my Scrum Masters a lot is, when you get to that retrospective, you have to have different methods that you go through. You can't just do the same thing every time because like we're talking about, there's different methods of learning and that activates different parts of people's brains. And if I am more of a visual processor, yeah, having something like Sailboat gets my brain to start to work in a way that's having just start, stop, continue won't, because that's just words on a page and it may not excite me as much. This is great. So I think we have an understanding of this. And by the way, we're gonna link something in our show notes. Stuart and I were talking about this beforehand. Stuart did a very lovely little quick overview of the Scrum framework that he used some of this storytelling process with as he described it. So if you're having trouble visualizing what we're talking about, we gotcha. We'll give you a link for that, and you'll be able to see this. So I want to transition that from just in general understanding, because I think we probably have a good idea of this now, into the product space. And I'm a product owner. I'm working with my stakeholders. I've got a product I'm working at day in, day out. How can?

Stu (11:18)
Thanks.

Brian (11:40)
how can being more visual help me in my, how's that helped me discover more about my product?

Stu (11:48)
Good question, good question. So for me, you know, when it comes to product ownership, there are many qualities and we could just talk forever on this, I'm sure. But one of the qualities I think that really matter is that passion, is that storytelling. And so of course, you can create wonderful stories regardless of visuals, but with the visualization, it really helps get people on the same page. And I think that, you know, without getting carried away with Neulen pens and nice big bits of paper and nice highlighter pens, we don't need to make this any more grander than it needs to be. You know, I think that a roadmap, uh, you know, post-it notes on a wall, story mapping, all of these are methods of, um, visualizing the work. And I think that, that for us, for a product owner, that your focus is on the why and the what. You really want to sort of try and create as much clarity as possible. And I think all of the good tools that we use are providing that clear narrative. And I'll take as an example, story mapping, or customer journey mapping, that general narrative of left to right, we're used to that flow. And so we can tell a story and it provides enough information. And I think what's nice in life, I don't know, I find is...

Brian (13:00)
Yeah.

Stu (13:15)
blending your, the things that excite you. So I'm quite interested by Pixar and if anyone's read Ed Catmull's Creativity, Inc. book, it's fascinating. It's talking really about motivating teams as well as everything else. But you think about storyboards, any of the good things that we've been doing for years, like Walt Disney. I think he coined the, there's a gentleman called Webb Smith. who is the illustrator who, and I think Walt Disney sort of, you know, coined the idea of story mapping and story, sorry, storyboarding from, from web. And it's just really interesting how those storyboards can tell a story and those little gaps between a comic provide you with just enough information to fill in the gaps. So it brings people on that journey, not telling people how to do something. but kind of presenting that picture.

Brian (14:16)
Yeah, that's awesome. I mean, yeah, there's a lot, when you start to describe it, you think about, oh yeah, this is not uncommon. There's a lot of places where people use visualizations like this to try to help, like you said, thinking about storyboarding a movie or think about advertising agencies that do little storyboards of what their ad might look like or what their, even their. ad in a magazine might, you know, not television ad, but an ad in a magazine might look like. There's lots of ways that people use visualizations in our world that we probably just don't even recognize because we're just so used to it now.

Stu (14:53)
Exactly, exactly. And, you know, I think that, that when it comes to sort of product ownership, you know, the focus is that, you know, if we go, if we talk about some of the, desirability, viability, and feasibility, and for me, product ownership sits right in the core of that. We're not always thinking about creating new shiny features and that desirability factor, sometimes we've got to think about the total cost of ownership and the efficiencies that we're trying to save for the reduced, the reduced cost. So. some of the experiences I've got is really blending some of these practices, like statistical analysis and measuring the non-value add activities in a process and adding that and combining that with a customer journey with some qualitative information that's quite thought-provoking is a really good blend. And to kind of emphasize that, Steve Denning said he did a TEDx talk quite some time ago around leadership. storytelling and he says that you've got to wake people up out of their complacency and you've got to be authentically, you know, authentically true. And so that's what I'm talking about. It's like you don't always tell a good story. The story's not always got a happy ending, but you want to wake people up to go, all right, we need to make some changes here.

Brian (16:18)
Yeah, yeah, you know, one of the people that, for those people out there who think, oh, I don't draw very well, if you, I'll just give you one person that you can go look at and kind of see someone who doesn't draw very well but uses it very effectively. Anything that you would see from Simon Sinek. Go try to find Simon Sinek's talk on uh, why, uh, you know, starting with why, if you, if you find his initial tech talk on that, he draws or any kind of, there's a lot of talks that he'll do where he draws kind of sloppy, you know, it's, it's kind of all over the place, but you, you don't think about it when you watch it, you're not looking at it going, well, he doesn't draw very well. He's emphasizing his point. And it's really highly affected. I don't know if you agree or if you've seen any of those. What do you think about that?

Stu (17:11)
I absolutely, totally agree. And I'd say the same and he wouldn't, he wouldn't be offended by me saying this, but Henrik Kleyberg, you know, probably one of the most watched videos, product owner in a nutshell, he'd say himself that the drawings are quite limited, quite crude, but the art of storytelling is so powerful. The other thing that we might get chance to talk about is structure. The way in which you structure information is really key. So.

Brian (17:18)
Yeah.

Stu (17:39)
you know, Henrik's drawings were like of the stick men were, were sort of very quick and low fidelity, but the structure in which he created that video really reinforced the message. So the power of storytelling in structure really helps. There's a, if any of you again, want to find out more about the art of storytelling, there's the sketch note handbook by Mike Rhodes, and he talks about structure. being the meat and veg and the fancy drawing being the gravy on top. So, you know, again, that kind of reinforces that message.

Brian (18:15)
I love that. I love that example. Well, connecting back with the product owner then, I wanna kind of get practical a little bit in where this would fit in. So let's, and just thinking about what a product owner does, kind of the typical kind of things. I know you mentioned story mapping and I agree, that's a very visual way of seeing our products. Not drawing as much, although it could be, right? You could have some drawings on those as well, but. Just in the normal course of doing things like coming up with our visions and trying to understand our customers and trying to validate assumptions and everything that a product owner typically does, how does something like this help in those kind of specific things that a product owner would normally do?

Stu (19:02)
Well, a couple of things I just wanted to say before I delve into the depths of all these things is that it's worth, and I know you're on the same page as me on this as a, as a product owner, there are lots of things that, that you just need, I think, to be aware of and cognizant of, of doing, regardless of whether it's you doing it or whether you're saying, look, how can we gain more discovery? How can we get more validation? How can we get more alignment? And again, I'm preaching to the converted, you know, a sprung team. It's that.

Brian (19:30)
Hehehehe

Stu (19:32)
cohesive unit, right? So, but as far as the individual tools that you as a product owner may use or encourage others to do so, talking about visions and things like that, I've always felt like it should be a team sport and the more visual that you can make that, there are so many different templates available out there to create compelling visions. And again, it's very much There's two ends right to storytelling. There's, as I've said from Steve Denning, waking people up from their complacency if something's not so great, or the art of the possible, the postcard from the future. All of these kind of creative things are taking people on this compelling journey. So always would make use of any of the templates available. Like you said, you've got to mix things up, but there's some great, great things from the Game Storming book. I've mentioned so many books, I apologies to whoever's got all these links in.

Brian (20:34)
Yeah, our show our show note person's scrambling trying to find all these things

Stu (20:38)
Right now, go never invite this person back again. Um, um, so yeah, there's lots of different vision, vision things available. And, you know, like all of these tools, two things I'd say is it's more about, not the tool, but more about the collaboration that you get from the tools. And I'd also say, um, tools in your toolbox, not a checklist, right? Um, but touching on the other two things you mentioned there, from a discovery perspective, I really do quite like blending, um, you know, a lot of the design thinking techniques with Agile, right? I'm all about blending everything, but I'm very passionate about customer journey mapping and as is and to be customer journey mapping. And again, as I've just, I used the example earlier, sort of blending qualitative and quantitative data. I'm all about outcome metrics and I'd love to say that data beats opinion, but actually opinion does matter. So. Blending a lot of these visuals with real qualitative information from customers is great. And, and again, thinking about the validation very similarly, you know, what can we do visually that can validate design ideas? A lot of us in the product space, work in the tech space. And I think one of the key things that I say about visualization is making the intangible tangible. And that's the thing, right? You know, a lot of us are working in software or we're working with process. How can you define that you're doing a good job if you're working on an MVE or you're trying to improve something and all you've got is just a bunch of code. You need ways to visualize and say things in a business in business language that people understand. So, you know, all these. All of the above, Brian.

Brian (22:35)
Right, right. Yeah, and you know, I'm just reminded, I remember there was, back way back in the day, there used to be an exercise, I know people would do in classes around, you know, you'd have a description of something and then someone would try to draw it. And there was a couple of rounds of this or there was a couple of different ways of doing it, you know, one team or one round, basically you wrote out the instructions and the people just had to follow them. Uh, and there's, you know, another round or another team that they got to ask questions back and forth, clarifying questions about things, uh, and you know, there's rounds or I may be misremembering this, but I thought there was sons where they could show you the picture and you could say, Oh no, that's not quite right to do this. Um, and one of the, the kind of key, uh, learning points of that was to try to say, you know, at the heart, when we have. requirements, when we have something that we're trying to express, you know, from a product owner standpoint to have a team work on, we're we have a picture in our head. And it's very visual, right? We have a picture in our head of what it is we want. And matching the picture that's in our head, and trying to describe it, you know, I heard of I've used this phrase quite a bit. I don't know where it came from. But words are imprecise. They are right words are just imprecise. They have different meanings. And even when I notice this in my classes, when I give descriptions of exercises, a lot of times people will come back and say, yeah, but you say this and that in instruction, but do you mean this or do you mean that? And that clarification is needed. So yeah, all this is just to say that matching pictures, if it's visual, it's helpful to see it. It's helpful to say, you know, it's not just, let me tell you what I need, but let me show you what I need. And, you know, that oftentimes can clear up those miscommunications that can cause the back and forths and, you know, having delays in a team just because you didn't really try to match the pictures.

Stu (24:46)
The, the, some of those motor key motivations I've said, simplifying complexity, uh, helping people to generate ideas, solve problems, but gain alignment is worth going back a little bit in time here, cause what you've touched there is a really pertinent point, um, before I'm a design graduate, as, as you could probably imagine with my passion, that doesn't really give me any more right to be, to be talking about this specific thing, uh, many important milestones in my life, being a business analyst, project manager before I was.

Brian (24:51)
Yeah.

Stu (25:15)
brought into the world of Agile and also spent time looking at design thinking. But they're 10 years working in social care and frontline services with adults with learning disabilities. And working back then on before the days of Agile for me, activity boards introducing symbol and picture communication to make it more inclusive and make people more involved with reading and writing difficulties. was really powerful. It's quite interesting going into the agile space years later and going, we were doing this then in social, but you touched on a really good point in that there's something that, you know, speech and language therapists talked about then, which was the symbol hierarchy of need, which suggests that there's different kinds of ways in which you can represent an object with different levels of abstraction and, um, without being tokenistic.

Brian (25:48)
Yeah.

Stu (26:09)
for people with profound and multiple learning disabilities, objects of references or, you know, things that miniature objects are better. But for people with reading and writing difficulties, pictures and symbols are better. Then the one at the worst, the most abstract form, of course, is the word. So you're absolutely right. And, you know, as someone back in the day as an illustrator, you'd get someone saying, oh, Stu, draw me a skyscraper and I'd be like, yeah, but, but how anything will be fine. And I'd be like, what, you know, and then, you know, you sure? Yes, yes. I'll draw it and they'll say, we wanted seven windows, you know, this brings me back to another point that, that I think is important to any, anyone out here that wants to use these skills for product ownership is again, another little phrase I like to say, which is again, process over art. I remember forgetting the importance and significance of this, ignoring everything I've told all of you, being commissioned to come in as the live visual storyteller, as this team that are working within a high street bank improving their agile transformation, were telling me about their journey and they wanted me to visualize it to create a storyboard. So there I was with all my specialist pens and the paper. And I'd be, you know, I was paid to be there as this visual storyteller. I even had like a little, like a, like a, uh, electrician's bag, you know, on the side, like a, like a cowboy with my pens in, I mean, like very professional. And, um, I had all these different people telling me about their process and about what it looks like. And it was just, I had that cold sweat, right? You know, I was just, all it was, was a pipe, a bit of paper with, with just. mess was the mess of lines and everything else. And at the end of the day, they looked at it much like that sky skyscraper analogy and said, this is great. You know, this is it's a mess. I saw, I said, I'm sorry. I feel like I failed. Said, no, this is great. You've managed to conceptualize what we're all saying. And that, that night I went home and I had some, maybe some classic music on. And I went all precious and I drew up as a wonderful storyboard. I thought, oh, phew, again, forgetting all the important things.

Brian (28:18)
Aha.

Stu (28:30)
And I brought it in to have a bit of integrity. And I said, right, everyone put a post-it note over anything that needs to change when you couldn't see the picture. And once again, once again, I feel like I'd failed, but not again. They're like, this is great Stu. You've got us on the same page. So again, you are that human cursor and you know, you're there to help with that connections because like you say, we're all conceptual thinkers and we need to join the dots and we're thinking differently, which is a beautiful thing.

Brian (29:00)
Yeah, it just struck me as we were talking about this thing. And maybe this will highlight a difference in personality. And some people might answer this one way or another. But if someone's going to give you directions, would you rather have the directions written out or would you rather have a map? I know for me, I'd rather have the map. To me, I like to see, oh, yeah, you go here and you go there. But when someone starts to rattle off, well, you go about a mile this way, and then you turn left, and then you take the roundabout. I'm lost already. If it's more than two directions, that's it. But if I have the map, yeah, I'm following step by step, and I can visualize where it is I'm trying to go.

Stu (29:41)
I think that that's another really beautiful thing about Scrum, right? And about sort of you as a product owner, trying to maximise value and get, and make the most from those amazing humans that you're working alongside and rubbing shoulders with. And like you say, you know, what are people's preferences? That's the beauty, I think, for me, is that diversity, the diversity of thought, reducing those assumptions and sort of thinking, thinking outside of the box. Um, and embracing that divergence a little bit more. And it's interesting. And Lee, if there's anyone listening, they're thinking, well, I, I can't visualize anything, there's actually something called aphantasia, which is the inability to imagine visual images, uh, which, which I only heard about sort of not so long ago. And I find that fascinating. And there's other people and there's like apparently 2% of the population as opposed to aphantasia. which is the condition of having extremely vivid mental visuals, which is around 10%. So it's just, I just think it's beautiful how people think differently, but you, you know, you as a product owner, bringing this back, I think from a facilitation perspective, you're using the skills of everyone to kind of come together to converge on, on what, what good looks like.

Brian (30:51)
Yeah. Yeah. And, you know, we, we had an episode of a few episodes back now, but we had an episode on, uh, kind of, uh, neurodiversity. And so speaking about some of the same things you're talking about here. And again, just to reiterate, you know, one of the reasons that's important is because you have differences in people on your team. So it's not necessarily important for you to know every single kind of person that could be out there in the world, but what's important for you to know. is the people on your team and the people you're communicating with. So if you have someone who does have a preference of a certain communication style and they are more visual, then yes, we need to be more visual. If you have people who would rather, you know, are more data-driven and want to see facts, then maybe we need to present things in a different way. Yeah, I saw something recently stored about kind of along the same lines. two people having a conversation and they were talking about how when, the person was questioning the other person saying, when you say the alphabet, when you say A, B, C, D, you're telling me you actually see the letters in your head every time you do it and the woman was like, yes. When I say A, I see a picture of an A in my head. I see the B, I see C, and I can't say it, I can't go through the alphabet without seeing in my head those letters visually. And the man was just stunned by it. He thought, wow, that's so foreign to me. I can't imagine that. I just, it's just, I'm speaking it. It's just words to me. But they're highlighting, right, kind of the differences in their brains. Their brains are wired a little bit differently. And... I just thought that was brilliant. I never heard anyone kind of express it that way, but that was a great way to kind of capture that, you know?

Stu (32:52)
You know, you're bringing it back to the product disposition canvas. And I should probably share that or a link to that. It's basically, um, uh, a vertical and horizontal axis. And you've got structure strategic to tactical, but visionary to implement it. And just sort of aligned to what you were saying there. And for the folks listening, uh, it's called the disposition canvas. Not so I'm using very clever big words, but because if you Google disposition, you look at, you know, uh, the encyclopedia and

Brian (32:58)
Yeah.

Stu (33:22)
dictionary even, it's got two definitions. One is a person's inherent qualities, which is what you're talking about. And the other is around your orientation. So whenever I'm delivering certified product owner classes or any product oriented classes, everyone has a different position, whether they're a glorified product backlog administrator or they're working very strategically, but also the thing that people forget to talk about. is what about you as an individual? Because I'm much more of a visionary than an implementer. And for the first, this is the first crowd that I've shared this with, but you talked about neurodiversity at the age of 44. Yesterday, I had a clinical assessment for ADHD and positive, yeah. So just quite liberating. I wish I'd learned earlier, but you know, it's kind of like all the people that know me are like, And you're telling us something we didn't know, but it's the, the thing about product ownership as well, that people forget, I think is that people assume that everybody, when you talk about scrum mastery, it's all around people and we feel kind of more comfortable talking about, about neurodiversity, all of these things. But product ownership is it's a job. It's, it's an accountability, but it's, you know, you are a, you're, you've got a, you're not a superhero. You're, you're a, a person.

Brian (34:23)
Yeah. Yeah.

Stu (34:50)
mining for truth and sharing your inherent qualities with the team is wonderful. So for me, hyper-focus, creativity, problem solving, big picture thinking, sometimes slightly impulsive, you know, but again, that's the Johari window. It's that openness, that transparency that needs to come through.

Brian (35:03)
Yeah, yeah. Yeah. I mean, they can be, I'm with you. It's there, you know, by the way, it's same here. Everyone who listens knows I've said it multiple times that, you know, I had late in life diagnosis as well. Um, but you know, it's kind of one of those things where there's superpower to it, you know, there's, there's kind of this superpower that comes along with it, but then there's also things that we don't do as well. And if you want, you know, this is not a neurodivergence thing. This is not an ADHD thing. This is a human being thing, I think, to just say,

Stu (35:16)
Thanks, Steve.

Brian (35:38)
we cannot accept and mine the superpowers of a person without also accepting and helping them with the things that they struggle with, right? Because they're a whole human being and they're someone on our team. So yeah, absolutely. I love that point. I think that's a great point.

Stu (35:59)
And I, this is, and I hope this sort of resonates with everyone listening in. Cause I think we, we are all good at identifying the things we're not good at. And we're never very good and we're blind to the things that we're good at. And so, you know, there's a seat at the table for everyone. And that's why I love talking about product because regardless, if you've ever delivered a service, I've talked about working with adults with disabilities to whatever you've done, worked in a shop, you're, you're trying to like deliver value to someone. Um. And just wanted to share a story, which is product related. I remember having massive imposter syndrome back in the day when I first became a business analyst, because I'm not a number cruncher, um, actually I quite do like numbers these days, especially when it comes to running and cycling, but, um, I didn't feel like I'd found my home and then something, um, those of you that may be dialing in from the listening in from the UK may remember in the news some years ago, there was a thing called the baby P incident. which was a terrible situation, safeguarding situation where a child died due to a lack of connections and joining the dots between social and healthcare providers. No individual was wrong, but the system was wrong. And due to that, working for local authority, I was tasked to work with the safeguarding teams in visualizing their processes. And that was the first time I'd gone from frontline services with a passion for drawing with some post-it notes in hand, visualizing and working with stakeholders to visualize a journey. And I'm like, you know, Visio process mapping galore, but I'm like, oh, I'm home, this is what it's about. So, you know, in everything we do, you know, never under emphasize the way your brain works.

Brian (37:43)
Hmm.

Stu (37:50)
and the qualities that you can bring, but it's that diversity together, that collection, which is the power.

Brian (37:57)
Awesome. That is very well said. Yeah, I really enjoyed this. This has been a great conversation. And I know we may have caught in a few different places, but that's the way conversations are. They get messy sometimes. And I'm all for that. But I like to ask, usually at the end, is there any, people wanna know more where they go to, but I feel like we've sprinkled throughout this, a lot of good...

Stu (38:23)
Hehehe

Brian (38:24)
follow on things that people can go and find out more about. But is there anywhere else that you would say, anything, anywhere people should, if they wanna get in touch with you, can reach out to you.

Stu (38:33)
More than welcome. We create agile nuggets, little agile nuggets of insights from different, different people around the globe. And I draw these little pictures. So I'll share that with you, but more than welcome to reach out. I usually make quite a bit of noise on LinkedIn. So, you know, I'm sure I'll be talking about this or sharing a post or something in the foreseeable future. So that's good with me.

Brian (39:00)
Well, Stuart, I can't thank you enough. Thanks for coming on and making time for us and sharing just your knowledge and wisdom with us.

Stu (39:08)
Thank you so, so much. It's been an absolute pleasure.

#80: From Struggling to Success: Reviving Agile Teams with Mike Cohn

10 januari 2024 | 30 min

Are you part of a struggling Agile team? Join Mike Cohn and Brian Milner in this episode as they uncover the primary signs of a team in distress. Listen in as they share the common causes of underperforming teams, and what to do to boost morale, enhance collaboration, and transform your Agile team from struggling to thriving!

Overview

What is the primary sign of a struggling Agile team? It's when the energy in the room feels like a deflated balloon, and laughter is a distant memory.

In this episode of the Agile Mentors Podcast, Brian Milner and Mike Cohn of Mountain Goat Software help listeners identify the signs of a struggling Agile team and the common culprits.

Listen in as they unveil the key principles of cultivating a positive work environment and the vital importance of addressing CYA behavior.

Plus, they share their top-notch tips on boosting team morale and enhancing collaboration, all while preventing unfinished projects and ensuring consistent delivery.

Tune in to transform your Agile team from struggling to thriving!

Listen Now to Discover:

[01:23] - Brian welcomes back Mike Cohn to the show to discuss how to identify the signs that your team is struggling and what to do about it.
[01:54] - Common causes of unfinished work.
[04:45] - Do developers use Scrum as an excuse to be lazy? No—that’s rare but can be easily corrected.
[07:36] - How to manage underperforming teams.
[09:04] - Teams that lack excitement and laughter may be struggling. Work should be fun and enjoyable. How to create a positive work environment.
[10:32] - How to break the habit of rolling unfinished work forward.
[12:44] - The power of small wins to improve job satisfaction.
[14:12] - How to boost morale and deliver small wins that create a sense of accomplishment.
[14:30] - The Agile Mentors Podcast is brought to you by Mountain Goat Software and their Certified Scrum Training Classes. Whether you want to be a Scrum Master, Product Owner, or even take an advanced certification, all courses are designed to give you the skills that agile teams and organizations value so you’ll stand out in the market. For more information click on the Mountain Goat Software Certified Scrum and Agile Training Schedule.
[15:35] - What CYA is really telling you about your team.
[16:59] - The role of managers in creating an environment of openness and collaboration
[19:03] - How individualistic behavior—working in isolation, not collaborating—hinders teamwork.
[21:08] - Introducing Swarming—a horrible way to work, you’ll get less done—but a great drill to help teams discover new ways to collaborate.
[27:54] - Thank you to Mike Cohn for joining us on the show.
[28:18] - Please share this episode with others if you found it useful. Send feedback and suggestions for future episodes to [email protected]. And don’t forget to subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode.
[27:54] - If this topic was impactful to you and you want to continue the discussion, join the Agile Mentors Community, where we have a topic discussion for each podcast episode.

References and resources mentioned in the show:

#70: The Role of a Leader in Agile with Mike Cohn
#39: The Art of Writing User Stories with Mike Cohn
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Certified ScrumMaster Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software
Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Auto-generated Transcript:

Brian (00:00)
Welcome back Agile Mentors. Very glad to be with you again. My name is Brian Milner as always. And today I have my good friend back with me, Mike Konis here. Welcome back, Mike.

Mike (00:11)
Hey Brian, thanks for having me back.

Brian (00:13)
Really, really excited that Mike could join us again. And wanted to talk about something that I think is, maybe it can hit on multiple fronts. And that's really signs that your team is struggling. What are some things that could be going on with your team? And what do they mean? What does it kind of symbolize? What do we do about it? There's lots of common issues I think that teams face. I know Mike, you probably, You do classes all the time as well, and I'm sure you hear kind of the same questions over and over in classes. Yeah. So there's kind of a set of the same issues that seem to rear their head again and again. So we thought we'd maybe make our way through a few of those and just talk through them, and maybe we can find some things here that would help you if one of these things happens to be something you're experiencing.

Mike (00:45)
Mm-hmm.

Brian (01:06)
So the first thing, if we're kind of working along in our team and we find out that they're kind of frequently reaching the end of their sprint and stuff's just not done. I know I had this a lot in teams I've worked with where we had carryover, we had stuff that just wasn't finished. I remember even one team early on I had that just kind of told me, hey, it doesn't matter. It doesn't matter we don't finish it. We'll just do it next sprint. So what do you think is kind of at the core of something like that, Mike?

Mike (01:40)
I think there's two common causes for a team not finishing work. And one's kind of an obvious one, which is excess pressure from management, right? Management's pushing them on how much to do. Management is not letting the team have full authority over how much work they bring into a sprint. And that could be a misguided scrum master, misguided product owner, or management outside the team, but somebody is putting some excess pressure on the team. And then the second one, I'm going to call it a second one, but it's, it's pretty related. is over optimism from the team. And the team just thinks they can get that much done. And they have a really hard time learning the lesson that they can't. And I'm thinking of a team I worked with outside of Sacramento, California. Absolutely phenomenal team. Phenomenal team. One of the best I've worked with in my entire career. But I don't know that they ever finished what they said they would. Literally, I don't know if they ever finished. And a lot of it boiled down to the optimism kind of their weed guy. And he was great, phenomenal guy. I've stayed in touch with him for many years. But he just always had the attitude of, yeah, we can do it. We can do the one more thing. And always bringing that in. And so the product owner and I would talk after a planning meeting going, I wonder how many they won't make. It's like, you think it'll be two or you think it'll be three. And after a while, the product owner just had to kind of take an attitude of like, okay, you committed to these many things, but you know, let's not work on this one until all the others are done. We'll kind of keep this one.

Brian (02:46)
Ha ha. Hahaha.

Mike (03:06)
kind of on deck or ready to go in next. And that worked better, but it was just their overoptimism. And now the reason I said, I think both of those go together, that somebody's putting pressure on the team or the overoptimism, somebody's putting pressure on the team and I cited management, Scrum Master, product owners, could be the team itself, right? The team is putting more pressure on itself. That's why I think they're related. So I think that's the, those are the two most common reasons for this to happen.

Brian (03:24)
Yeah. Yeah, it's funny, you know, I get questions a lot of times in classes or when I talk to leaders where they, there seems to be a concern, which I think is completely unfounded, that the developers are going to just goof off. And that, you know, somehow this whole Scrum setup is just a shell game to kind of give developers a chance to just fool around and do whatever they want to do.

Mike (03:53)
the

Brian (03:58)
I don't know, I mean, I'll share my personal experience. What I tell those leaders is that, you know, it's actually just the opposite has been my experience. You know, developers want to please the others in the organization. And so when someone comes to them and says, hey, you know, can't you do a little bit more in the sprint than, you know, they're usually not gonna say no. They wanna make people happy. So they'll say yes, you know, so it's over optimism, but like you said, the pressure too,

Mike (04:22)
Mm-hmm.

Brian (04:27)
could contribute to that to say, hey, you know, I don't wanna make anyone mad. I don't wanna tell them, no, I can't do this. So I'll make them happy for today. They'll be mad, you know, at the end of the sprint, but for right now, you know, they'll be happy for a few days.

Mike (04:41)
Yeah, I'd rather have people mad later instead of mad today. I think we have to be careful though. There are some small percentage of teams that will use it as an excuse to be lazy. And I've worked with thousands of teams at this point. I have worked with a few of those right there. They were using scrum as an excuse to be lazy. Like, you mean we get to pick how much we do? Okay. We'll do that little. Right. Um, and normally that's fairly easily corrected.

Brian (04:51)
Sure. Right.

Mike (05:07)
because it normally boils down to one or two people on the team that are kind of creating that mindset. And I'll go back to the guy I talked about on the amazing team, right? His name was Todd. And he had an outsized influence on the team, just kind of by his seniority and by his personality. You're kind of a big personality, people liked him. He was the one that would occasionally have like parties at his house and things like that. I was referred to him as the glue that held that team together. And again, an amazing team. But his personality, had an outsized influence, right? And so his optimism drove that team to picking too much. If you had somebody, his evil twin, it's like, oh, let's commit to a little, right? That could have the same influence there. And so when we have that problem, it's often fairly easily fixed. You need to talk to the one person or you move the person onto a different project or out of the company if you have to. Other times the problem is caused when we have two people together, right? It's the combination of these two that make it happen. So... It hasn't ever been a really hard problem to fix, but I do want to acknowledge that is a, it's a, it's a concern. It could happen. Right. But I think what we tell, we would tell leaders is it's pretty rare. Right. And if you have a team using Scrum to, to deliberately go slow, deliberately take it easy, not do a lot of work. Pretty easy to notice. And it's pretty easy to fix, right? You know, fire somebody if you have to. Right. I mean, I hate saying that, but I mean, that's an option. And if we have people that are just, you know, deliberately.

Brian (06:15)
Yeah.

Mike (06:33)
underperforming and it's a valid option. So I don't think it happens off but I do want to be fair there that it can happen.

Brian (06:41)
Yeah, I'm glad you pointed that out because I do agree it's kind of a you know, the percentage of it I don't know I don't have any studies to say this but the percentage of it is probably so small that you know It's kind of one of those things again. Are we managing towards the majority? Are we managing towards the small minority? Are we making all our policies around the small minority? Are we making around what the majority would actually do?

Mike (07:05)
I love that point because I get some criticisms on my blog or YouTube videos or stuff sometimes where people will tell me, yes, but this advice doesn't work for such and such a team. And they're always describing some horrible team, right? You know, this is some totally, you know, where you've got the total command and control manager or the architect that's also the scrub master and abusing their power. It's always just some horrible messed up situation. And somebody will tell me my advice doesn't work for those teams.

Brian (07:10)
Hehehe

Mike (07:32)
I'm totally okay with that. I made the decision many, many years ago that I want to offer advice that will help good teams become great. I don't really want, I don't care if they do, but I don't really wanna focus my life on helping really poor performing teams become mediocre. Right? This doesn't motivate me. That doesn't get me excited. I wanna help the good team become world-class, right? And so I'm gonna write things with the assumption that we're...

Brian (07:39)
Yeah.

Mike (07:57)
We all have positive intent. We are trying to get better for making a mistake. We're going to own it. We're going to, we're going to go from there, but I don't want to, I don't want to give advice for all the horrible teams to get mediocre. That's it. That just doesn't get me excited.

Brian (08:10)
Yeah, completely agree to that. It's, you know, there will be other signs. It's not like it's gonna be hidden if you do have a team that's trying to abuse it in that way. It's gonna be fairly obvious that that's happening.

Mike (08:23)
Yeah, I'll get it asked. You know, leaders will say, how will I know if the team is underperforming? And, um, one of my, um, professors back in graduate school has got him, Peter Drucker, who's often, um, considered like the, you know, the management guru of the 20th century. And, um, he had a term management by walking around, right? You just walk around and you will notice. Right. And, um, you know, we started out, you're talking about, um, struggling agile teams and one of the things I was thinking there, like, what is, like, what is the like primary sign of a struggling?

Brian (08:34)
Yeah. Hmm.

Mike (08:52)
agile team. I think one of them for me is they're not having any fun. Um, I love, I love building stuff, right? I love creating products and, um, it should be fun. Um, you've heard me before say that I hate work is called work, right? You know, I get it. We got to call it work, but work should be fun. We spend most, you know, not most, but you know, half a third of our day working, it should be fun. And if you go into a company and nobody's having any fun, you're not hearing any excited voices or laughing ever. That's a sign that the team is struggling. So.

Brian (09:25)
Yeah, that's a great point. And I completely agree. You know, I get it, right? I mean, it's not recess. Like, there's a limit. There's work, and we're trying to make money in what we're doing. But you're right. If there's no need for our workplaces to be overbearing and just stuffy, I can't stand being in this. I can't wait to get out of it.

Mike (09:50)
Yeah, yeah. I mean, we all have days like that, but work should be fun, right? And that should be one of our goals, to make it fun. I mean, people are gonna get more done when they're having fun.

Brian (09:54)
Yeah. I don't know that we've addressed this, but I just want to throw it out there in case you have anything else you put in there. So if we do have a team that's sort of missing delivery, and they're not really being able to complete things by the end sprint, any kind of quick tips you would give teams like that to try to turn that around?

Mike (10:19)
The biggest one for me has to do with this being one of the worst habits that an agile team can fall into. I think it's a horrible habit to get into the mode where we don't finish things. And I'm a user of a phrase you used a moment ago, you were kind of quoting teams. It's okay. We'll just roll it forward. Right. I think the attitude of roll it forward is horrible because it implies that the iteration or sprint boundaries are meaningless and we're just going to roll things forward and I don't want that. I want the thing to go, the unfinished thing to kind of back on their product backlog. and we make a decision, do we still want them? We probably do, but not always. And so I try to get teams to stop using that phrase. I know you weren't using it. You were referencing a team calling it that. But I think it's just a really bad habit and I wanna break that habit. The way I do that is I ask the team in their new sprint, whatever we're planning, the new sprinter iteration, to under commit. They know what it feels like to not finish everything.

Brian (10:57)
Yeah. Yeah.

Mike (11:14)
I want them to see what it feels like to finish everything, right? To get everything done. And we do that by getting them to go deliberately light in the, in the next sprint and then add work hopefully at the end of the sprint, right? And so being able to add work is going to feel very different to them. It should be a positive experience. They should be excited about it when they, when they get to work that way.

Brian (11:39)
Yeah, that's a great tip. I completely agree. If we can, don't, you know, there's oftentimes lots of stress about just the idea of, oh, but you know, my managers are gonna be mad at me that the team didn't really commit to. Yeah, but what we're looking for is consistency. And if they're consistent, then we can forecast and we can start to look ahead. But if they're inconsistent, we can't do that. And what...

Mike (12:00)
So you would point, we want to be clear though, that we don't want a team to make it every time, right? You don't want a team to, I'll call it succeed. You don't want a team to succeed a hundred percent of the time at finishing what they said in a sprint. If you see a team making it every time, they're playing it safe, right? They're under committing. They're like, oh, let's not grab that extra one item. Let's play it safe. And I always use sports analogies for this and pick a sport. It doesn't matter what sport this can map to any sport, but you know, let's go with football, soccer.

Brian (12:04)
Right.

Mike (12:29)
Right. Um, I don't want a player who scores every time they kick the ball. Right. That, that sounds awesome. Right. Who wouldn't want that? Except what it means is the guys, the player is only kicking. They're only trying to score when they can. Right. They're not like, Oh, I think I can make it. Let me give it a try. They're playing it safe. They're only going to kick when they're assured of making a goal. Basketball player, baseball player, hitting the ball, anything, um, quarterback throwing the ball in American football.

Brian (12:33)
Yeah. Yeah. Yeah.

Mike (12:54)
And you don't want them to make it 100% of the time. And managers have to embrace that with teams that it is success when we can make it. I kind of target 60 to 80% of the time, the team finishes what they said they would. And so I like to reduce the commitment, get the team to feel what it's like to add instead of remove. There's a Harvard professor, Theresa Imabile, who's written one of my favorite papers, it's called The Power of Small Wins. And what she did is study what improves job satisfaction. And her research led to the idea that the number one determinant of job satisfaction was the frequency of small wins. And I consider finishing or mostly finishing what we said we'd do in an iteration, a small win. And if we can do that, have a team make it most of the time, every two weeks, you're getting a small win under their belt. That's gonna feel good. It's gonna feel a whole lot better than the team I described in Sacramento at the beginning that never finished anything.

Brian (13:51)
Right, right.

Mike (13:52)
never finished everything. They finished lots of things and they never finished everything.

Brian (13:55)
eah, and it goes to Dan Pink's, one of Dan Pink's big threes, mastery there, that if we start to see progress, we're saying, oh, we're getting better. We're actually improving as we go along. Great tips. Okay, let's talk about another one. Let's see if we can get another one in here. And this is one that kind of, to me, I think is a team dynamic issue that I've seen quite a bit. Not a ton, but I have been on teams that have had this. And that is when a team starts to develop kind of more of a...

Mike (14:06)
Mm-hmm.

Brian (14:25)
um, shall we say a CYA, uh, kind of approach, uh, cover your, um, the, the backside, uh, put it that way. Um, yeah, yes, CYB. Yeah. Uh, yeah. Um, but, you know, kind of, kind of when the team sort of feels like, you know, I'm, I'm being really scrutinized here and I better deliver or.

Mike (14:35)
That's a CYB behavior. Cover your backside.

Brian (14:54)
I'm gonna be in trouble, or if there's gonna be someone who's in trouble, it's not gonna be me, I'm gonna make sure it's somebody else. What is that kind of indicative of on a team? What is the most important thing

Mike (15:04)
the biggest thing is just kind of a lack of respect for your co-workers, right? You know, if you're really working as peers and you have this shared goal of deliver an amazing product, then you're looking out for your team members. You're not making sure they're the one that gets in trouble if there's a problem, right? And I remember early in my career, and I don't remember if this project was Agile or not. I don't remember if we'd gone to Agile on this project, but I remember it very much being a case of what I called project deadline chicken. Nobody wanted to be the one to admit that they weren't gonna make the deadline, right? So we had a software group, we had the database group, we had the testers, probably another group or two. And everybody knew they weren't gonna make the deadline, but nobody wanted to be the one that was gonna admit it, right? Because if they're the one that admits it, they're gonna get all the heat from the boss, and that was a yelling boss, he'd yell at somebody.

Brian (15:37)
Yeah.

Mike (15:57)
And the other teams would just go, oh yeah, okay. We, you know, relax today. That's fine with us, but we would have made it. Right. And, um, we need that type of openness, transparency and trust in teams. And when I don't have respect for my teammates and I don't feel like we're in it together, um, or that they don't have my back, I think that's where the CYA behavior comes from in many cases.

Brian (16:21)
Yeah, there's a, you know, I tell this in classes sometimes, there's an old boss of mine who had this phrase I thought was really good. He said, you know, bad news is not like wine, it doesn't get better with age. And I completely agree, right? I mean, if something is not going well, there's no good that comes from just pretending that it actually is going well. And let's not find out about the issue until now it's too late for us to actually adjust or do anything about it.

Mike (16:32)
That's good.

Brian (16:49)
The earlier we find out about it, the more runway we have that we could say, all right, well, let's make sure that people are aware. Let's make sure the dependent parties know and that if we need to, we can, you know, change staffing, we can do whatever we need to do when there's runway. But when there's none, it's done, right? It's history.

Mike (17:09)
Yeah, it's too late to alter behavior.

Brian (17:11)
Yeah, I've been a part of some teams that are kind of finger pointing and backstabbing a little bit. And there is sort of a CYA approach in that. And I think that is, there's a trust issue there obviously as well. It does come down to a little bit of just not. We got kind of a cancer as a team. We're not really working together as a team then, yeah.

Mike (17:29)
Mm-hmm. I think managers are doing better at this. I'm not, you know, cause this, the manager has to create an environment where we're going to listen to people and root out the truth, not just blame one group for something and not let a team or a team member get away with this type of behavior. And I think managers have gotten better at this in terms of knowing that, you know, well, it's not listening to the first guy that blames the other person, right? Let's go check into it. So I think managers have gotten better at this over the years, at least what I've seen.

Brian (18:00)
Yeah. What about like, this is one that I know I encountered multiple times, but you get the scenario where you have that team that say, hey, we're kind of more independent. We like to work on our own and kind of the frequent. mode is, hey, we're gonna decide in sprint planning, but then you see everybody go off in their own corners and put their headphones on, and they're kind of in the zone for like eight of the 10 days of the sprint. They're just all on their own doing their own coding, and they're not really working together as a team. What do you think is kind of at the root of that kind of behavior?

Mike (18:34)
Mm-hmm. Lack of teamwork. One of my favorite movie scenes is Robert De Niro in the movie Untouchables. And he gives a speech about, basically about baseball players and how the baseball player stands at the plate and you make this your cricket player if that's your sport, but you know, they stand at the plate, it's just them, right? They're the only player from their team on the field. And he talks about that being a very individual thing. And he makes the point to his mafia associates, whatever they were, that he needs teamwork.

Brian (18:40)
Mm.

Mike (19:07)
right? And he makes it in a very interesting way. It's worth, go watch this little three minute snippet on YouTube. But he uses it to make the point that he needs teamwork. And I think when we see this, when you know, you grab your thing, I grab my thing, and, you know, I'll see you in 10 days at the end of the sprint, we're not a team, right? We're just this loose collection of individuals doing things. And that's often the result of not breaking up work very well. It's often the result of defining our roles in very specific ways. You only do the front end or I only do the back end. That can happen or you grab one user story and it's yours front back end all the way through. And I grab another one. It's just not a good way to work. I want people collaborating on things because one of the things that we're after with Agile is kind of a faster turnaround time on each item that we work on. So that, you know, we grab an item and three or four of us might work on it. we get it done very quickly. And then we grab the next item. We get it done very quickly. One of my early agile transition efforts was a company that was transitioning a few hundred people, which was big at the time. And they were very much in this mode. Each person would grab a thing to work on. They would work on it for three or four months, or six months even. And then they would hand it over to a tester. And the testers have to verify everything. But it'd be done over three, four, six months. Not an agile way of working.

Brian (20:29)
Yeah, well, we should also probably define a term here because I know there's a term that gets used a lot when we talk about this kind of thing, and that's swarming. It's another one of those kind of agile words that we hear sometimes and think, ah, swarming, what's swarming? What's your experience with that? What does swarming mean to you?

Mike (20:46)
To my knowledge, I was the one that first used that. And I used it a little bit differently than people use it today. When I talked about it, I said swarming would be the entire team working on one item. And this is a horrible way to work. It's an absolutely horrible way to work. But it's a worthwhile exercise to do. It's a good drill. And I think when I first wrote about it, I was a swimmer. And I was comparing it to a drill that

Brian (20:52)
Hmm.

Mike (21:14)
my swim coach had me do, which was called closed fist swimming. So you swim through the water with your fists, right? Picture doing that. It's not a good way to swim, but what it does is it really helps you get good arm position in the water. And then when you open your hand up and make kind of a palm, you're much faster because you've learned proper arm position. So a good drill. And so swarming have the whole team work on one thing's good drill and you'll get less done that sprint velocity is not going to go up with people working this way. Absolutely not. But when you.

Brian (21:23)
Yeah.

Mike (21:43)
open your fists when you let the team work in a more normal way. Um, all of a sudden they're going to have found ways to collaborate that they would not have found. So it's basically an over collaboration technique because you're going to have six or seven people work on one item. Right. And today people will use swarming to mean, you know, we're kind of batch mode, right? You know, we'll have two or three things in process at a time. And you know, maybe that's okay if the team's pushing good team size boundaries, but I legitimately met it as. one item and we all work on it. And that is gonna be very inefficient, but we're gonna have to find ways to break it up into smaller pieces, find ways to collaborate on it. And those skills, what we learned from doing that will be handy when we go back to working on now, two, three or four items in process at a time.

Brian (22:31)
See, this is why it's so great to have Mike Cohn on, because terms like this that I've heard my entire career in this area, I had no idea that came from you. So I'm glad I got some of the history of it. See?

Mike (22:44)
Well, I'm pretty sure it did. I'd have to look up when I first wrote about it, but I do know when I wrote about it, I hadn't heard it from anybody else. Doesn't mean somebody else hadn't, you know, done it on a blog I'd never seen 20 years before me, but that's, that was where I started with it.

Brian (22:56)
Sure. Yeah, and I think it's a great concept. And yeah, I mean, that sounds a little like what we would call mob programming today. If you're going to take everyone and work together at the same time on the same thing, that might be a little bit more like the original concept that you had when you were doing that.

Mike (23:16)
Yep. Except we'd also have the testers, the designers, everybody, right? The whole team on one thing.

Brian (23:21)
Ah, okay, yeah. Yeah, and it's just, you know, when we think about how teams work today, you know, I think one of the things I try to help the team understand is that we don't want everyone to just grab their own thing and then go off and work on their own, you know, because then, you know, you use a sports analogy, sometimes I apologize in class and just say, hey, look, I apologize that there's gonna be sports analogies, but hey, Scrum is a sports analogy, right? I mean, it comes from a sport. But yeah, I mean, when you think about any team sport and how a team works together, they have different jobs, but they have a same goal, and their goal is to win the game. I can't just say...

Mike (23:50)
Yeah. Mm?

Brian (24:11)
You know, if I, if I play, you used soccer earlier or football to the, you know, 90% of the rest of the world, you know, 10% of us here, yeah, we call it soccer, everyone else is football. But yeah, just, just kind of the, the concept that if, if I know my position, let's say, you know, I'm a midfielder, well, I can't just stay right, you know, on the left midfield and never move. You know, I'm not touching anything unless it comes in this little square box. Well, I'm not a very good player.

Mike (24:17)
Right.

Brian (24:39)
And am I doing kind of what I'm in charge of? Sure. But am I being a teammate and am I helping my team to achieve our goal of succeeding? No.

Mike (24:49)
Yeah, you've got to, it's not my job, man, right? Mind telling you, you're doing that. I think the analogy that I find that works really well is a restaurant, right? Let's suppose you go to, it doesn't have to be a fast food. You're gonna go to some Italian restaurant, low end, high end, doesn't matter. You go to this Italian restaurant and you got one guy gonna make your meal, right? He's gonna make the salad, he's gonna bake the croutons, he's gonna make the dressing, he's gonna put all that together, then he's gonna bring it to you, then he's gonna start making your main dish. Your dinner's gonna be three hours, right? Because you've all got to bake the termissu.

Brian (24:52)
Right, right. Yeah, yeah.

Mike (25:19)
Right. I don't want one guy, one person, just a guy, but I want one person making my whole dinner. Right. I'm hoping that a dozen people worked on my dinner, right, including the dessert or whatever back there. So that's where we'd have a team in it. One of the things, I'm gonna stick with the restaurant thing. One of the things I talked about with my wife is I get mad at bad service at times. And I've said, if I were owned a restaurant, I would make sure that servers helped tables that weren't their own. Right. Because I love that at restaurants, right. Because I drink a lot of water when I'm out or iced tea, whatever I'm drinking. And I'm always empty. Right. And I always wish I like it when I'm at a restaurant where somebody is not my weight, my server fills it up. Right. And it's just a little touch. Right. Just a little touch. But it's like I'd probably want to train my staff like, look, 20 percent of the tables you touch shouldn't be your own. If everybody's doing that, we're all going to be happier. Right. And, you know, I'm sitting there parched with no water and

Brian (25:49)
Hmm, yeah. Yeah.

Mike (26:18)
three waiters walk by going to other tables. I'm like, please.

Brian (26:23)
Yeah. Yeah, yeah, it's water, please. Yeah, I've heard our friend Lance Dacey use this analogy as well as far as the kitchen. And I like what he says. He kind of talks about how if you have people back in the kitchen, just talking about cross functionality of a team, if you have a team back in the kitchen, they all have different specialties and you have the grill master, and you got the pastry chef and all this other kind of stuff. Yeah, they all have their own specialities, but.

Mike (26:25) Yeah.
Yep. I think they helped.

Brian (26:48)
You know, if there's a table of 20 that all want a steak, you know, the pastry chef doesn't just sit in the corner and say, wow, it sucks to be the grill chef tonight, you know, they all come over and say, how can I help? Yeah. So yeah, the restaurant's a good analogy. I like that. That's a good one. Well, this has been good. I think we're probably.

Mike (27:00)
help. Yeah, yeah, absolutely.

Brian (27:10)
pushing up on our time and I want to be respectful of your time Mike and also respectful of our listeners time so thank you once again for coming on I know you've got a lot of stuff to do and I just really appreciate you making time out for the show

Mike (27:22)
Thanks, Brian, it's always a pleasure.

#79: Navigating Agile Trends and Challenges in 2024 with Lance Dacy

3 januari 2024 | 42 min

Join Brian and his guest Lance Dacy as they dive into the trends and challenges awaiting the Agile community in 2024 and the importance of adapting Agile principles to the hyper-competitive world of product development.

Overview

In this episode of the Agile Mentors Podcast, Brian sits down with Lance Dacy to take a deep dive into the anticipated trends and challenges awaiting the Agile community in 2024.

The duo explores the ongoing debate between remote and in-person work, the imperative need for innovation in leadership and management, and the intricacies of forward-thinking strategies as we work toward building organizations tailored for the future.

Join Brian and Lance as they navigate the complex intersection of Agile principles, organizational leadership, and the ever-evolving landscape of the business world in 2024.

Listen Now to Discover:

[01:17] - Brian Milner has Lance Dacy on the show today for the traditional discussion of looking ahead at trends and upcoming developments in the Agile and Scrum space for 2024.
[02:10] - Remote vs. in-person work—opening the discussion with this hot-button topic and the evolving debate.
[03:31] - Lance offers his insights on organizations' adaptive strategies, what we learned during the pandemic, and the potential benefits and drawbacks of remote work.
[05:58] - The loss of collaboration and learning when in a remote environment.
[07:22] - The hybrid work solution.
[07:36] - Brian shares a study favoring in-office productivity.
[09:50] - Lance shares his personal work-at-home challenges and the importance of aligning work environments with individual personalities and preferences.
[11:32] - The importance of accommodating individual preferences and working styles, and the need for organizations to match their environments to employees rather than requiring employees to adapt.
[12:58] - The challenges faced by managers and leaders in making decisions about remote work, and the importance of flexibility in work hours.
[15:20] - Brian raises concern about layoffs in the Agile area during tough economic times, questioning if it's the right strategy for long-term success.
[16:23] - Lance emphasizes the need for understanding Agile rather than blindly applying it, suggesting the Agile industry may be bloated and encouraging a focus on culture and effective coaching.
[17:23] - Mountain Goat Software, is the sponsor for this podcast. Whether you’re looking to get Certified ScrumMaster (CSM) or Certified Scrum Product Owner (CSPO) training or want to take an Advanced Certified ScrumMaster (ACSM) class, click here to see what we have to offer.
[19:33] - Leadership and management innovation—Brian and Lance discuss the need for organizations to prioritize human-centric management AND leadership innovation, citing Gary Hamel's concept of building organizations fit for the future.
[23:25] - Lance discusses the devaluation of the human element in organizations.
[24:31] - Brian and Lance share their insight into the devaluation of developers, and the need for discussion on the trajectory of Agile in the face of such challenges.
[25:55] - Lance highlights the need to educate leaders and managers on the criticality of Agile budgeting alongside project management to align expectations.
[27:40] - Lance addresses the challenge in achieving true Agility, and why coaches offer such a long-term ROI.
[28:10] - The importance of educating leaders on the value of coaching, psychological safety, and the need for a neutral perspective in fostering organizational improvement.
[29:15] - Brian predicts a continued emphasis on cost-cutting in 2024 due to economic uncertainty.
[29:57] - Brian expresses his concern about the long-term negative impact of eliminating coaching roles.
[31:34] - Lance anticipates a cultural shift that might make it difficult for companies to attract talent if they don’t embrace more human-focused values that empower individuals.
[32:59] - Lance urges Agile coaches to adapt to a changing paradigm and discusses the challenge for leaders and managers to shed bureaucratic structures and implement an effective strategy for embracing these principles.
[34:17] - Brian urges a reevaluation of Agile's focus, emphasizing transparency and adaptability over rigid structures and roles.
[34:48] - Brian stresses Agile's strength in handling unexpected challenges and calls on Agilists to emphasize the fundamental principles to demonstrate Agile's value effectively.
[35:40] - The need for new thought leaders in leadership, management, and organizational design to guide Agile practitioners in effectively leveraging data and scaling Agile practices.
[36:30] - The importance of evolving beyond rigid practices to embrace Agile's adaptability. Lance uses the analogy of professional sports to illustrate the importance of adaptability, discipline, and rigor in responding to dynamic situations.
[38:03] - Not doom and gloom but a chance for growth and adaptation—Brian expresses optimism and excitement for the upcoming year, seeing it as an opportunity for renewed focus and bringing value to organizations in the evolving world of product development.
[40:20] - Brian extends his thanks to Lance Dacy for being on the show. And don’t forget to share your thoughts and ideas on upcoming trends in the Agile Mentors Community.
[41:09] - Please send feedback and ideas for upcoming shows to [email protected]. And don’t forget to share and subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode.
[41:14] - Happy New Year to everyone, Brian expresses excitement for the journey ahead in 2024, meeting more listeners at in-person events, and sharing more insights on future episodes of the Agile Mentors Podcast.

References and resources mentioned in the show:

#63: The Interplay Between Data Science and Agile with Lance Dacy
#30: How to Get the Best Out of the New Year with Lance Dacy
#76: Navigating Neurodiversity for High-Performing Teams with Susan Fitzell Humanocracy
Certified ScrumMaster Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified ScrumMaster®
Advanced Certified Scrum Product Owner®
#4: The Developer Role in Scrum with Sherman Gomberg
DFW Scrum (Dallas, TX) | Meetup
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#78 A Year in Review: The Best Moments and Insights of 2023

13 december 2023 | 35 min

Embark on a captivating journey through the Agile Mentors Podcast in 2023 with Brian Milner. Explore a spectrum of Agile topics, from Scrum Master challenges to leadership insights. Join Brian for insightful summaries, memorable moments, and a walk through the rich tapestry of Agile wisdom on the show.

Overview

In this episode of the Agile Mentors Podcast, Brian embarks on a retrospective journey through the standout moments of the podcast in 2023. Explore carefully curated episodes, offering solutions to the common challenges and then delving into the world of Agile beyond software development.

Listen in as Brian shares insightful summaries featuring memorable moments and a diverse landscape of Agile wisdom shared by his esteemed guests. Categorized into topics like Scrum Masters, Product Owners, Developers, Agile’s use beyond software, general career advice, and leadership and coaching, this retrospective is a treasure trove of practical advice, actionable insights, and real-world experiences.

Tune in for an inspiring tour through the rich tapestry of the Agile Mentors Podcast 2023 episodes.

Listen Now to Discover:

[01:16] - Brian introduces the episode and invites listeners to join him in a retrospective of the year's episodes, highlighting ones that may have been missed or are hidden gems worth revisiting, which he will group by listener preferences and areas of interest.
[02:39] - For Scrum Masters: Brian begins discussing the first episodes tailored for Scrum Masters, kicking things off with #47, "Exploring Lean Thinking and Agile Development," featuring guest Bob Payne, who shares insights into lean thinking, a foundational principle in agile development. Brian recommends this episode for Scrum Masters aiming to enhance their understanding of Agile's fundamentals.
[03:34] - Episode #52, "The Birth of Agile: How 17 Adventurous Techies Changed the World," features Agile icon Mr. Jim Highsmith, one of the authors of the Agile Manifesto. Jim provides a glimpse into the past and offers insights into the future of Agile.
[04:06] - Episode #59, "Revising the Scrum Guide," features Don McGreal, who played a key role in the guide's revision, shedding light on the thinking behind the revisions.
[05:31] - In Episode #62, "Effective Sprint Goals," Maarten Dalmijn delves into effective crafting techniques and the finer details of achieving success with Sprint Goals.
[06:12] - In Episode #69, "Should Scrum Masters Be Technical with Allison Pollard," Allison and Brian explore the question of whether Scrum Masters should possess technical skills. If you grapple with how technical a Scrum Master should be, this episode provides valuable insights and perspectives.
[06:51] - In Episode #39, Mike Cohn, an authority on user stories, shares valuable insights into the art of crafting effective user stories.
[07:15] - In Episode #65 with Randy Hale titled "Unlocking Lean Portfolio Management," Brian and Randy explore the concept of moving beyond a single-team focus as a product owner, delving into the realm of lean portfolio management building upon insights shared by Bob in episode #47.
[07:50] - For Product Owners: Must listen bonus from last year, Episode #22, with Roman Pichler, who shares his insights on "How to Create Helpful Product Roadmaps," addressing challenges commonly faced by product owners in dealing with the nuanced aspects of their role. The episode covers strategies to avoid pitfalls, especially the dangers of rigidly locking into scope and schedule timelines.
[08:54] - For Developers: Episode #33, "Mob Programming with Woody Zuill," introduces developers to the transformative practice of mob programming. Woody Zuill, a pioneer in this way of working, shares insights and a practical and thoughtful approach that makes it worth exploring.
[10:00] - In Episode #48, Brian hosts a unique episode featuring the renowned Lisa Crispin and Janet Gregory, experts in Agile testing, in a show called "Holistic Agile Testing." This episode is particularly recommended for developers specializing in testing or involved in testing within a Scrum team.
[11:00] - In Episode #54, "Unlocking Agile's Power in the World of Data Science," Brian and Lance Dacy explore the intersection of Agile methodologies and data science. The popularity of this episode prompted a sequel, Episode #63, on the fusion of Agile and data science.
[11:58] - In the final developer-focused episode, Carlos Nunez joins Brian to delve into the world of DevOps. Carlos, a speaker at Agile 2023, shares insights on the significance of DevOps in today's Agile landscape, emphasizing DevOps as a means of empowerment rather than gatekeeping.
[12:38] - Agile Outside of Software: Episode #32 with Cort Sharp focuses on Scrum in High School Sports—specifically high school swimming. Cort shares his experience applying Scrum principles to create practice schedules and routines for the swim team he coaches, providing valuable insights for those interested in using Agile beyond the software realm.
[13:24] - In #38: "Using Agile for Social and Societal Transformation with Kubair Shirazee," Kubair walks listeners through how his nonprofit employs Agile methodologies to empower micro-entrepreneurs in developing countries. The episode highlights success stories, such as a barber's journey from a rented spot to owning a professional store, demonstrating Agile's transformative impact beyond the tech industry.
[14:40] - Episode #45 with Scott Dunn explores "Overcoming Agile Challenges in Regulatory Environments." This crucial topic addresses the unique challenges faced in tightly regulated sectors like government, legal, and medical professions, offering a compelling dialogue on navigating regulatory hurdles within an agile framework.
[16:00] - Episode #64 features John Grant discussing "How Agile Methodologies Reshape Legal Practices." This episode reveals the transformative impact of Agile in the legal profession and offers a unique perspective on Agile as a philosophy rather than just a practice, illustrating its broader applicability beyond the software realm.
[17:00] - Today's episode is brought to you by Mountain Goat Software's Certified Scrum Product Owner (CSPO) course. This is a two-day training course taught by one of our certified Scrum trainers that teaches you how to use the product backlog as a tool for project success and how to respond to changes in business conditions by restructuring the product backlog. For the schedule, visit the Mountain Goat Training Schedule.
[17:27] - General Career Advice: #34: "I'm Trained, Now What? with Julie Chickering" addresses the post-training phase for Scrum Masters and Product Owners. Julie shares insights on taking the next steps, implementing knowledge, and finding opportunities to build a resume in Agile roles.
[18:29] - In #40: "Is it Time to Go Out on Your Own? Tips and Insights with Chris Li" Brian and Chris Li discuss considerations for those at later stages of their careers contemplating the transition to independent consulting. If you're pondering whether it's time to establish your consultancy, this episode provides valuable insights and considerations to guide your decision-making process.
[19:00] - In #42: "The Importance of Self-Mastery with Bob Galen," Bob emphasizes the value of constant learning, even after years of experience, highlighting the importance of staying open to new discoveries and others' experiences. This episode serves as a compelling guide for personal growth and continuous improvement.
[20:28] - Episode #46 with Christina Ambers: In this episode, Christina shares insights on "How to Assess Company Culture Before Accepting a Job Offer." As the year closes and people consider new job opportunities, Christina guides listeners through the crucial step of evaluating company culture and the importance of understanding if a company truly embraces Agile values or merely pays lip service to them.
[21:14] - Episode #50 celebrated the milestone of the 50th episode. Lance Dacy was on the show to discuss "Choosing Your Path: Exploring the Roles of Scrum Master and Product Owner." The episode offers guidance for individuals at crossroads, helping them decide between Scrum Master and Product Owner roles. It serves as a valuable resource for those navigating career decisions in the Agile landscape.
[22:13] - Leadership and Coaching: In the Leadership and Coaching category, Episode #37 features Brad Swanson discussing "Servant Leadership, Not Spineless Leadership." Brad dispels misconceptions and offers valuable insights into the essence of servant leadership, making it a compelling resource for those interested in effective leadership approaches.
[23:28] - In Episode 41, Karim Harbott explores "Cultural Transformations in Organizations." The episode delves into the challenges of changing organizational culture, emphasizing the time and effort required beyond implementing specific practices.
[24:00] - In "#44: Transformations Take People with Anu Smalley", Anu highlights the often-overlooked aspect of involving people in organizational transformations, shedding light on the human dynamics that can either support or hinder the process.
[24:35] - In Episode #53, "Debunking Myths in Agile Coaching with Lucy O'Keefe," we tackle the common myths surrounding Agile coaching and provide insights on unlocking excellence in Agile coaching practices.
[25:01] - Episode #66 is a solo episode where Brian shares his insights into navigating team conflicts, laying the foundation for understanding and mastering the essential skill of conflict navigation.
[26:00] - In Episode #68, Brian hosts Mike Hall for a discussion of "The Pros and Cons and Real-World Applications of SAFe." Whether you're new to SAFe or deeply involved, Mike's expertise provides valuable perspectives and tips for navigating this framework.
[26:42] - In Episode #70, Mike Cohn joins Brian to explore "The Role of a Leader in Agile." Here, Mike shares valuable insights based on his extensive experience, offering sound advice and perspective on the crucial role of leaders in self-organizing teams.
[28:10] - Brian encourages listeners, especially newcomers, to explore relevant episodes based on their roles, with the goal being to offer practical advice and solutions on specific issues rather than lengthy discussions. All episodes are available in the show notes for convenient access.
[29:33] - Brian expresses gratitude to listeners for the past year, reflecting on the unique nature of podcasting and letting listeners know he cherishes the encouragement and connections made, especially at events like Agile 2023.
[31:00] - What do you want to hear in 2024? What are some of the hot-button topics that haven’t been covered on the show or guests you want to hear from? Send Brian an email with your ideas.
[32:28] - And don’t forget to share and subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode.
[33:00] - We also have our Agile Mentors Community, where we have discussions about every podcast
[33:24] - Wishing you a Happy Holiday Season! We'll see you early again in 2024.

References and resources mentioned in the show:

#47: Exploring Lean Thinking in Agile Development with Bob Payne
#52: The Birth of Agile: How 17 Adventurous Techies Changed the World with Jim Highsmith
#59: Revising the Scrum Guide with Don McGreal
#62: Effective Sprint Goals with Maarten Dalmijn
#69: Should Scrum Masters Be Technical with Allison Pollard
#39: The Art of Writing User Stories with Mike Cohn
#65: Unlocking Lean Portfolio Management with Randy Hale
#22: How to Create Helpful Product Roadmaps with Roman Pichler
#33 Mob Programming with Woody Zuill
#48: Holistic Agile Testing with Lisa Crispin and Janet Gregory
#54 Unlocking Agile's Power in the World of Data Science
#63: The Interplay Between Data Science and Agile with Lance Dacy
#71: The World of DevOps with Carlos Nunez
#32: Scrum in High School Sports with Cort Sharp
#38: Using Agile for Social and Societal Transformation with Kubair Shirazee
#45: Overcoming the Challenges of Agile in Regulatory Environments with Scott Dunn
#64: How Agile Methodologies are Reshaping Legal Practices with John Grant
#34: I'm Trained, Now What? with Julie Chickering
#40: Is it Time to Go Out on Your Own? Tips and Insights with Chris Li
#42: The Importance of Self-Mastery with Bob Galen
#46: How to Assess Company Culture Before Accepting a Job Offer with Christina Ambers
#50: Choosing Your Path: Exploring the Roles of Scrum Master and Product Owner with Lance Dacy
#37: Servant Leadership, Not Spineless Leadership with Brad Swanson
#41: Cultural Transformation in Organizations with Karim Harbott
#53: Agile Coaching: Debunking Myths and Unlocking Excellence with Lucy O'Keefe
#66: Successful Strategies for Navigating Team Conflicts
#68: The Pros and Cons and Real World Applications of SAFe with Mike Hall
#70: The Role of a Leader in Agile with Mike Cohn
#49: Celebrating One Year: A Look Back at 50 Episodes of the Agile Mentor Podcast
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified ScrumMaster®
Advanced Certified Scrum Product Owner®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#77 Navigating the Challenges of Becoming a Certified Scrum Trainer® with Lucy O’Keefe

6 december 2023 | 48 min

In this episode, Brian Milner and Lucy O'Keefe share their journeys to becoming Certified Scrum Trainers® (CSTs). Join them as they discuss the challenges, unexpected moments, and valuable lessons learned along the way, offering insights for those considering the CST path.

Overview

Explore the transformative journey to becoming a Certified Scrum Trainer® (CST) with Brian Milner and Lucy O'Keefe.

From the submission process to mentorship, co-training, and the rigorous Trainer Approval Committee (TAC) interviews, they unravel the intricacies of achieving CST status.

Listen in for valuable tips, reflections, and inspiration for navigating the rewarding but challenging road to becoming an elite Agile trainer.

Listen Now to Discover:

[01:26] - Brian introduces his guest, Lucy O'Keefe, who recently achieved her Certified Scrum Trainer® (CST).
[02:53] - Today’s discussion will explore the experience of becoming a Certified Scrum Trainer® with Brian and Lucy sharing their personal experiences and insights into the process of becoming a CST.
[03:44] - Lucy shares what fueled her passion for becoming a CST and how her mentor—Anu Smalley—inspired her.
[05:00] - Brian discusses his decision-making process for becoming a CST and why it's important to make a decision that aligns with your instincts and career goals.
[06:07] - Brian and Lucy each share their journey to becoming a CST and the steps required before being eligible to pursue the trainer certification.
[08:24] - Insight into the two phases of the submission process for becoming a Certified Scrum Trainer®: the materials phase and the Trainer Approval Committee (TAC) phase and the challenges along the way. [09:38] - Brian reflects on the significance of mentorship in the journey to becoming a CST and David Hawks's crucial role in opening doors and making connections with other trainers.
[09:48] - Lucy acknowledges Anu's pivotal role and emphasizes the importance of these relationships, (especially considering the challenges posed by the pandemic.
[12:00] - Lucy and Brian discuss the relationship-building phase involved in co-training and mentorship.
[13:22] - Lucy explains the (time-intensive) nature of co-training.
[14:26] - Brian shares his approach to initiating co-trainings.
[15:11] - The importance of feedback and obtaining recommendation letters—a crucial element in the submission process.
[16:28] - Brian and Lucy discuss the impact of mentorship on their journey, expressing gratitude for the individuals who opened doors and provided mentorship. Brian mentions David Hawks, Kert Peterson, and Lance Dacy, emphasizing the diverse perspectives and valuable insights gained from them.
[17:20] - Lucy shares about the recent special episode of her podcast where she featured her mentors.
[17:55] - The value of in-person training (and some of the expenses involved).
[20:09] - The challenges of training in a virtual environment.
[22:18] - The limitations of virtual classes and the added value of personal interactions and shared experiences during breaks.
[23:38] -The Agile Mentors Podcast is brought to you by Mountain Goat Software and their Advanced Certified Scrum Product Owner® class. This is the only ACSPO that uses our interactive software so that breakout exercises are valuable and FUN! Plus, you will automatically receive 12 free months in the Agile Mentors Community. For more information, click on the Mountain Goat Software Certified Scrum and Agile Training Schedule.
[25:17] - The lengthy process of submitting materials for Certified Scrum Trainer® approval. Brian shares his personal experience.
[25:35] - Lucy explains the current two-phase process for CST approval and her experience (highlighting the changes since Brian's initial submission).
[26:33] - The rigorous examination process and the scrutiny applied to every aspect of the application during the fine-tooth comb review during the TAC phase of becoming a CST.
[27:00] - Lucy describes the final stages of the approval process.
[27:19] - Brian reflects on the changes in the CST qualification process and emphasizes the importance of following the TAC's feedback for those who reach this stage. (Advice from Chris Li)
[28:49] - Resilience and persistence in the face of potential setbacks during the CST approval process.
[30:42] - An in-depth explanation of the challenging TAC (Trainer Approval Community) interview process for becoming a Certified Scrum Trainer®.
[32:23] - Brian shares his personal preparation strategies and reflects on the unpredictability of TAC interviews, recounting an unexpected request during his own experience.
[33:32] - Lucy shares her preparation methods and also stresses the unpredictability of TAC interviews and the importance of adaptability during the process.
[34:29] - Be prepared to think on your feet. Brian shares the emergency situation he faced and a mistake during his live presentation. Plus the surprising comments he received from the committee.
[37:27] - Lucy shares her unexpected experience after the committee's vote. And a valuable piece of advice for listeners.
[38:33] - Embarking on the CST journey involves challenges and moments of doubt, but perseverance is crucial, as success may require multiple attempts—not everyone passes on the first try.
[39:43] - Becoming a CST is a subjective process and often involves multiple attempts—it doesn’t diminish your capabilities as a trainer. Brian shares the crucial aspects of the journey.
[40:13] - Lucy shares why it's important not to take rejection personally, instead viewing it as a chance to identify areas for growth and become a better trainer in the end.
[41:23] - Brian emphasizes the importance of viewing the CST process as a journey—being prepared for potential setbacks, highlighting the mindset of growth and continuous learning.
[42:30] - Lucy adds that the rigorous Certified Scrum Trainer® requirements aim to ensure that CSTs are among the elite trainers, making the achievement more meaningful.
[43:38] - The importance of embracing each chance to enhance oneself as an Agilist and a trainer.
[44:09] - Brian's words of wisdom: "Hard things that are hard to do, that just makes it all the better when you achieve them.”
[44:45] - Lucy’s advice: “It's not just becoming a CST. It's what you learn on your journey that really matters."
[45:25] - Congratulations to Lucy for getting her CST! Brian extends his thanks to her for being on the show. For listeners interested in continuing the discussion, you can join the conversation in the Agile Mentors Community, where they also have monthly Q&A calls.
[46:58] - If you found this episode useful, please share it. Send feedback and suggestions for future episodes to [email protected]. And don’t forget to subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode.

References and resources mentioned in the show:

#53: Agile Coaching: Debunking Myths and Unlocking Excellence with Lucy O'Keefe
#44: Transformations Take People with Anu Smalley
#17: Getting There From Here: Agile Transformations with David Hawks
#12: Kanban with Kert Peterson
#54: Unlocking Agile's Power in the World of Data Science with Lance Dacy
#40: Is it Time to Go Out on Your Own? Tips and Insights with Chris Li
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#76: Navigating Neurodiversity for High-Performing Teams with Susan Fitzell

29 november 2023 | 47 min

In this episode, Brian sits down with Susan Fitzell to unravel the realm of neurodiversity in the workplace. Join them as they explore the intricacies of accommodating neurodivergent individuals, discussing the challenges they face and the strategies to foster an inclusive environment for everyone on your team.

Overview

Today, join host Brian Milner in an insightful conversation with Susan Fitzell as they explore the intricate world of neurodiversity within Agile environments.

Listen in to gain valuable insights into the challenges neurodivergent individuals encounter and discover effective strategies, from reevaluating dress codes to adapting communication methods, to foster an inclusive workspace.

Susan provides practical tips that offer a fresh perspective on accommodating diverse work and communication styles, empowering teams to collaborate successfully.

Tune in to revolutionize your leadership approach by embracing the unique strengths neurodivergent team members bring, and create an environment where every individual can thrive.

Listen Now to Discover:

[00:00] - Brian introduces guest Susan Fitzell, a certified speaking professional, and author to discuss neurodiversity in the workplace.
[03:24] - Susan explains the evolving neurodiversity language, now encompassing diverse brain wiring, including conditions like ADHD and autism, and discusses terminology challenges.
[08:22] - Brian shares his own personal connection to ADHD and a story about his daughter’s autism and her triumphs.
[10:40] - The challenges of diagnosing autism in females and how the criteria are based on male presentations.
[15:16] - The importance of neurodiversity for Scrum Masters and leaders, and the challenges of recognizing neurodivergence, especially in females adept at masking.
[19:19] - The need for flexibility in understanding neurodivergent team members, the impact of past negative experiences, and the importance of soft skills for a collaborative Agile team.
[21:33] - Susan addresses the high unemployment rate (80%) among neurodivergent adults, especially autistic individuals, and highlights challenges in interviewing.
[24:22] -The importance of recognizing and leveraging the unique skills of neurodivergent individuals on Agile teams, and acknowledging their specialized contributions.
[25:41] - Brian shares a study that indicates young autistic individuals choose computer science degrees at three times the general public's rate, emphasizing the likelihood of having neurodivergent individuals on your teams.
[26:04] - The Agile Mentors Podcast is brought to you by Mountain Goat Software and their Certified Scrum Master Training Class. Despite the name, it's not just for Scrum Masters, it's designed for anyone who wants to understand Scrum and add value to any team. For more information click on the Mountain Goat Software Certified Scrum and Agile Training Schedule.
[27:41] - Susan addresses accommodations in the workplace for neurodivergent individuals.
[28:10] - Brian and Susan discuss specific aspects scrum masters should consider for accommodating neurodivergent individuals within team environments.
[31:30] - Susan shares insights on sensory sensitivities and the challenges of conforming to things like dress codes for neurodivergent individuals.
[34:16] - The significance of recognizing and accommodating sensory preferences for better productivity.
[35:27] - The positive impact of remote work on neurodivergent individuals, allowing them to create a comfortable work environment tailored to their needs.
[37:35] - Susan emphasizes the importance of understanding team members as individuals to recognize and embrace the diversity of strengths and challenges in their teams.
[40:19] - Supporting neurodivergent team members through workspace recommendations, emotional check-ins, and communication preferences.
[41:04] - Brian mentions Susan’s Neurodiversity in the Workplace and "The Autism at Work Playbook" as valuable resources.
[43:36] - Brian thanks Susan for her insights. You can connect with Susan and there are more resources at her website at https://susanfitzell.com/, or by sending her an email.
[44:19] - If this topic was impactful to you and you want to continue the discussion, join the Agile Mentors Community where we have a topic discussion for each podcast episode.
[45:18] - Please share this episode with others if you found it useful. Send feedback and suggestions for future episodes to [email protected]. And don’t forget to subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode.

References and resources mentioned in the show:

Susan Fitzell
Neurodiversity in the Workplace
"Autism at Work Playbook"
Autism in Heels
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Susan Fitzell, M.Ed., CSP, is a renowned neurodiversity speaker, coach, and consultant with over 30 years of experience. Specializing in training neurodivergent thinkers, including those with dyslexia, autism, ADD, and ADHD, Susan is a trusted expert and author of 16 books. With a holistic approach and dedication to creating competitive learning cultures, she collaborates with organizations globally to maximize the potential of neurodivergent individuals.

#75: A Special Thanksgiving Message from Brian Milner

22 november 2023 | 8 min

In this episode of the Agile Mentors Podcast, join host Brian Milner in a heartfelt Thanksgiving reflection filled with gratitude to listeners of the show and a sneak peek into what's coming up on the podcast.

Overview

With gratitude at the forefront, Agile Mentors Podcast host Brian Milner reflects on the year's journey toward agility by extending heartfelt appreciation for listeners of the show and their contributions and dedication to making workplaces better.

Listen in as Brian shares the power of gratitude and recognizing those who challenge the norms for the sake of improvement and go the extra mile to get the job done.

Tune in for an insightful Thanksgiving message, sprinkled with valuable tips for team appreciation and building a positive culture within the Agile community.

Listen Now to Discover:

[00:45] - Brian welcomes listeners to this special Thanksgiving week show.
[01:22] - Brian shares his thanks for those he and Mike Cohn were able to meet at Agile 2023.
[02:09] - Gratitude for the growing list of ideas for upcoming shows. Brian explains the backlog process of the Agile Mentors Podcast from Mountain Goat Software to ensure a thoughtful and tailored exploration of agile themes.
[02:30] - Praise goes a long way— Brian shares his ideas for finding opportunities to say thank you to your teams.
[03:52] - Advice for a mix of public and private appreciation.
[04:33] - Cultivating a positive organizational culture —it's a complex and time-consuming process. Brian shares his advice for listeners who want to improve the work environment.
[05:52] - Praise for the imperfect solutions.
[06:19] - A Holiday break and then a whole new slate of episodes of the Agile Mentors Podcast for 2024.

If you have feedback or a great idea for an episode of the show? Great! Just send us an email and don’t forget to subscribe to the Agile Mentors Podcast on Apple Podcasts or your favorite platform so you never miss an episode.

References and resources mentioned in the show:

Previous Episodes of the Agile Mentors Podcast from Mountain Goat Software
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#74 Unlocking the Power of Neurohacking with Ted Wallace

15 november 2023 | 37 min

In this episode of the Agile Mentors Podcast, we dive deep into the fascinating world of neurohacking with Ted Wallace. Discover how you can unlock your brain's superpower to accelerate your learning and personal development journey!

Overview

Are you ready to revolutionize the way you learn, work, and lead? In this episode of the Agile Mentors Podcast join Brian and his guest, author Ted Wallace as they delve into the fascinating world of using neurohacking to unleash the potential of your brain.

Whether you want to change your habits, learn a new skill faster, or just increase your personal and professional growth, listen in for valuable insights that can help you harness neuroplasticity to tap into your brain's incredible potential.

Listen Now to Discover:

[01:02] - Brian introduces his guest, Ted Wallace, an Enterprise Agile Coach at the Principal Financial Group. Ted has also co-authored a series of books including Total Brain Coaching and Self Empower with his father, Dr. Robert Keith Wallace. Today’s show is a deep dive into the concept of neurohacking and its application in personal and organizational development and learning.
[01:22] - What is Total Brain Coaching?
[04:48] - How understanding the connection between neuroscience and learning can help individuals approach situations and come up with effective strategies.
[06:10] - Ted discusses the research findings from his book 'Neurohacks' which explores ways to help individuals change their habits for faster learning.
[07:32] - The importance of individual growth in driving overall organizational and societal change.
[08:54] - How simple neurohacks such as getting enough sleep, can have a positive impact on mental health and productivity while networking and collaboration help amplify intelligence and foster innovation.
[11:39] - We all have different learning styles. Ted walks listeners through the different learning styles and how applying personalized learning can lead to faster adoption and habit change resulting in improved team performance and adaptability.
[13:15] - This podcast episode is made possible by our sponsor, Mountain Goat Software. The company’s Scrum certification classes were developed with the assistance of an instructional designer for an online learning experience that is both interactive and engaging. For more information visit Certified Scrum Training, Agile Training by Mike Cohn.
[14:23] - The key elements in building effective habits for increased productivity.
[16:35] - Why creating an environment of psychological safety is essential in improving learning outcomes.
[20:51] - How different levels of adoption, from self-coaching to group dynamics, can accelerate value delivery.
[21:53] - Maslow's Hierarchy and for effective meetings.
[22:55] - How the Cynefin framework and Agile practices can help solve hard problems elegantly.
[26:02] - How implementing neurohacks can improve the speed of learning.
[27:36] - Ted walks listeners through some neurohacks that help improve learning.
[28:52] - Neuroplasticity is everyone's superpower but what’s the secret to developing new pathways in the brain?
[33:17] - You can connect with Ted by visiting his website at Total Brain Coaching and for further learning check out his books.
[35:49] - If you want to discuss this topic further join the Agile Mentors Community and jump into the discussion there.
[36:22] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email and don’t forget to subscribe to the Agile Mentors Podcast on Apple Podcasts or your favorite platform so you never miss an episode.

References and resources mentioned in the show:

Total Brain Coaching
Total Brain Coaching: A Holistic System of Effective Habit Change For the Individual, Team, and Organization
16 Super Biohacks for Longevity: Shortcuts to a Healthier, Happier, Longer Life
The Coherence Code: How to Maximize Your Performance And Success in Business - For Individuals, Teams, and Organizations
Self Empower: Using Self-Coaching, Neuroadaptability, and Ayurveda
Trouble In Paradise: How To Deal With People Who Push Your Buttons Using Total Brain Coaching
The Backwards Brain Bicycle - Smarter Every Day 133
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Ted Wallace is currently an Agile Coach at Principal Financial Group. He is a certified Scrum Master Professional (CSM, CSPO, CSP, CTC) and a registered corporate coach (RCC) with thousands of hours of coaching sessions. He’s also the author of several books, including Total Brain Coaching and Self Empower.

#73: The Four Common Fears that Hinder Agility with Ryan Gottfredson

8 november 2023 | 39 min

Discover the mindset and courage it takes to be truly agile. Listen in as Ryan Gottfredson sits down with Brian to explore the four common fears that hinder agility. In this episode of the Agile Mentors Podcast, Ryan Gottfredson, an expert on the psychology of agility and author of the bestselling book "Success Mindsets," sits down with Brian to explore the four common fears that hinder agility.

Listen in as Brian and Ryan walk listeners through examples of how these fears manifest in the workplace, sharing valuable insights on how recognizing and reshaping your mindset can lead to more effective agile, and more personal and professional growth.

Listen Now to Discover:

[01:18] - Brian introduces his guest, Ryan Gottfredson, a leadership and management professor at the College of Business and Economics at California State University, Fullerton to walk us through his talk from Agile 2023 in Orlando called The Four Fears that Undermine Agility.
[06:07] - Brian reflects on the evolving understanding of agility as one progresses in their Agile journey, emphasizing the importance of interpersonal dynamics and human psychology in Agile work.
[07:47] - The mindset and courage it takes to be truly agile.
[09:23] - Ryan offers up some indicators of agility.
[10:11] - Ryan introduces the four fears that undermine agility.
[12:02] - How fear of failure and reluctance to try new things can lead to resistance to change, ultimately undermining agility.
[12:16] -The importance of leadership in fostering agility with an example of Satya Nadella at Microsoft.
[15:03] - Ryan discusses the first fear inhibiting agility, the fear of failure, and how it can significantly impede agility.
[15:27] - The conversation then delves into the second fear, the fear of being wrong, and how this fear can obstruct agility by hindering the acceptance of diverse perspectives.
[17:03] - The Agile Mentors Podcast is brought to you by Mountain Goat Software and their Certified Scrum Training Classes. These classes were designed and developed by the Co-founder of the Scrum Alliance, Mike Cohn. Mike taught his first Scrum class in 1997, and since then, more than 24,000 people have chosen to train with Mountain Goat Software. To join them, click on the Mountain Goat Software Certified Scrum and Agile Training Schedule.
[18:13] - Is your expert mindset holding you back? Brian and Ryan explore the importance of shifting from an expert mindset to a truth-seeking mindset to foster agility by being open to the possibility of being wrong.
[20:04] - Brian shares a personal experience related to the "no estimates" movement.v [21:28] - The value of conversations that focus on embracing the complexities of a topic.
[22:09] - Ryan introduces the third fear inhibiting agility, the fear of having problems. Ryan shares an analogy of reacting to a mouse like it's a bear to illustrate his point.
[24:29] - The "window of tolerance" for handling problems effectively.
[25:43] - Ryan explains the fourth fear that hinders agility, the fear of getting passed up or not being recognized.
[26:22] - The difference between a limited mindset, and a more open mindset that acknowledges the value of giving and sharing.
[27:10] - Ryan shares a real-life example of an executive who initially shut down his employees' ideas to keep from being viewed as dispensable. [28:23] - Ryan reflects on the prevalence of these fears in organizations, and how they can collectively hinder agility.
[30:03] - Ryan shares the four mindsets related to the four fears: fixed vs. growth, closed vs. open, prevention vs. promotion, and inward vs. outward.
[31:33] - Brian thanks Ryan for sharing his insights on the show. You can find Ryan’s mindset assessment on his website, Ryan Gottfredson. You can also find his book, "Success Mindsets," or take his FREE Personal Mindset Assessment on his website or connect with him via LinkedIn.
[36:45] - We invite you to subscribe to the Agile Mentors Podcast on Apple Podcasts. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. And if you’d like to continue this discussion, join the Agile Mentors Community.

References and resources mentioned in the show:

Ryan Gottfredson
Success Mindsets by Ryan Gottfredson
Ryan Gottfredson on LinkedIn
Ryan's talk from Agile 2023
Ryan Gottfredson's FREE Personal Mindset Assessment
#33 Mob Programming with Woody Zuill
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input. ● Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. ● Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Ryan Gottfredson, Ph.D., is a renowned mindset expert, author, and consultant. Through his work at California State University-Fullerton, his talk called, The Four Fears that Undermine Agility, and his bestselling book "Success Mindsets," Ryan helps organizations and leaders thrive through mindset improvement.

#72: The Parallels Between Roller Skating and Workplace Challenges with Melissa Boggs

1 november 2023 | 30 min

Today, Brian sits down with Melissa Boggs to explore the parallels between roller skating and workplace challenges as she shares her four-stage framework for personal and professional growth.

Overview

Today, on the Agile Mentors Podcast, Brian sits down with Melissa Boggs, host of the Wild Hearts at Work podcast to explore the parallels between roller skating and workplace challenges.

Listen in as Melissa shares her experiences in the rink and in the workplace as she introduces her four-stage framework for personal and professional growth and the essential mental preparation required to embrace audacity and approach challenges with courage and curiosity.

Listen Now to Discover:

[01:33] - Brian introduces Melissa Boggs, a keynote speaker, leadership coach, and the host of the Wild Hearts at Work podcast to discuss moving from caution to courage.
[03:57] - Melissa shares where the resistance to Agile concepts comes from and the inspiration for the Wild Hearts at Work podcast.
[05:44] - The parallels between Melissa's roller skating journey and workplace challenges and how the distinct stages of personal and professional growth inspired her talk, "From Cautious to Courageous: A Live Roller-Skating Journey."
[06:47] - Melissa introduces the fourth container, audacious, emphasizing the willingness to make dramatic and transformative moves to make major changes.
[08:05] - The true meaning of audacity.
[09:03] - Melissa walks listeners through the journey from cautious to audacious by fearlessly facing challenges that are bigger than you.
[11:17] - The Agile Mentors Podcast is brought to you by Mountain Goat Software. If you want to get your Certified Scrum Product Owner Training or another certified training, here is the Mountain Goat Software Certified Scrum and Agile Training Schedule.
[11:45] - How to distinguish between a growth opportunity or genuine danger.
[13:58] - Melissa emphasizes the importance of the "Curious" stage in her framework, to tap into your intuition when transitioning from cautious to courageous.
[14:30] - Melissa shares a specific example from her skating experience, highlighting the role of curiosity in addressing her caution and fear when attempting a challenging move.
[15:06] - Melissa shares the elusive puzzle piece that was the final piece of her framework to show up, shedding newfound clarity on the journey from caution to audacity.
[17:19] - “Danger Will Robinson.” The importance of exploring the reasons behind discomfort and discerning when it's a valid response.
[20:51] - Identifying the true source of a fear to gain control over it—the role of reason in guiding human actions.
[22:02] - The danger of remaining perpetually in the caution container.
[22:51] - Brian shares a pivotal moment in his journey to become a CST (Certified Scrum Trainer) and the importance of acknowledging setbacks and mistakes when they occur in order to move forward.
[25:08] - How jam skating can help you learn to fall gracefully. Melissa underscores the mental preparation involved in facing challenges.
[28:14] - Brian sends a special thanks to Melissa Boggs. To continue the discussion, join the Agile Mentors Community.
[29:07] – We invite you to subscribe to the Agile Mentors Podcast on Apple Podcasts. 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:

Wild Hearts at Work podcast
Melissa Boggs
Melissa Boggs on LinkedIn
The Audacity of Hope: Thoughts on Reclaiming the American Dream
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Melissa Boggs is an Agile advocate with experience serving on the Boards of Scrum Alliance and Agile Denver and serving as a keynote speaker at several global conferences. As a Certified Enterprise Coach and the host of the Wild Hearts at Work podcast, she specializes in bridging generational, cultural, and societal gaps to enhance workplace engagement.

#71: The World of DevOps with Carlos Nunez

25 oktober 2023 | 34 min

In this episode, Brian dives into the world of DevOps with guest Carlos Nunez. Listen in as they explore the origins, debunk myths, and unlock the potential of DevOps in optimizing software delivery on the Agile Mentors Podcast.

Overview

On this episode of the Agile Mentors Podcast, join Brian as he welcomes guest Carlos Nunez, to explore the origins, debunk myths, and unlock the potential of DevOps in optimizing software delivery.

Listen in to explore DevOps, its tools, and its profound impact on fostering effective communication and collaboration between development and operations teams.

Listen Now to Discover:

[01:18] - Brian welcomes his special guest Carlos Nunez, a DevOps consultant at VMWare, to discuss DevOps and its relationship with Agile.
[02:40] - Carlos introduces the concept of DevOps and the need for collaboration between development and operations and the importance of both sides understanding each other's work to improve communication and efficiency in software delivery.
[03:36] - What DevOps is not. Brian and Carlos discuss the various aspects of development, testing, and deployment in software development.
[04:25] – Carlos shares a common misapplication of DevOps.
[05:35] - Fostering a culture of communication and collaboration rather than using technical knowledge to obstruct progress and create bottlenecks.
[05:48] - Brian shares the core concept of DevOps with the agile mindset.
[06:20] - Brian asks Carlos why DevOps was developed and what can be gained when teams advance their DevOps practices.
[06:30] - Carlos discusses the origin of DevOps, (hint: it started at an Agile conference).
[07:05] - How DevOps can enhance team operations by fostering better communication and collaboration between developers and operators.
[08:35] - The importance of looking at software and operating systems holistically.
[09:54] - Brian expands on the importance of breaking down rigid skill boundaries to work more efficiently to enhance teamwork and results.
[10:40] - Carlos discusses the common issue of Scrum Masters who only focus on facilitating ceremonies without understanding the product aspect.
[11:57] - Are Scrum Masters still effective?
[12:49] - Brian delves into the relationship between DevOps and Agile, addressing occasional pushback from DevOps practitioners who claim that DevOps and Agile don't work well together.
[13:16] - Carlos shares insights from his talk, where he explored criticisms of Agile from DevOps practitioners, where some of the criticism originates from and his thoughts on the negative perception.
[15:15] - Are you thinking about getting certified as a Scrub Master? If so, you will want to check out the resources and training options with our sponsor, Mountain Goat Software. They run certification classes every week. Each course comes with 4 hours of training videos from Mike Cohn and includes twelve months of membership in the Agile Mentors Community. You can find the schedule here.
[16:34] - Brian asks about the categories of software that people use in DevOps.
[16:41] - Carlos discusses DevOps tools and approaches, categorizing them into two ways: traditional Agile tooling and pragmatic programmer-type tools.
[18:19] - Carlos highlights the significance of behavior-driven development (BDD) as the second bridge between DevOps and the broader business while noting that BDD tools are generally user-friendly and can help enhance collaboration between different roles in the software development process.
[19:20] - How test-driven development (TDD) forms a bridge between developers and operators, allowing both to understand how to write tests, get them to pass, and refactor—like the developer's "red, green, refactor" process.
[20:25] - Carlos discusses Jira, a widely recognized (and polarizing) Agile tool, and the two reasons he prefers it.
[22:19] - Carlos discusses how the concept of story points can sometimes turn into person-hours. He emphasizes that the key is to focus on addressing the process to make it more effective and user-friendly.
[23:12] - Why story trackers are crucial for operations teams.
[23:55] - Brian offers his take on Jira.
[24:35] - Carlos highlights the importance of CI/CD build systems and value stream mapping to understand the path from inception to production.
[26:31] - Carlos highlights that having DevOps tools is important but not sufficient.
[27:37] - How people with DevOps skills add value.
[28:12] - You can find Carlos’ teaching on LinkedIn Learning, including DevOps Foundations, Kubernetes fundamentals, his Docker Essential Training Online Class, and more.
[31:07] - Brian offers a big shout-out to Carlos for coming on the show. If you want to connect with Carlos, you can email him here.
[32:33] - If you like this more technical episode, email us and let us know. As always we’d like to invite you to subscribe to the Agile Mentors Podcast on Apple Podcasts. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email.
[33:49] - Brian sends a special thank you to all Agile Mentors Podcast listeners.

References and resources mentioned in the show:

Email Carlos Nunez
LinkedIn Learning Courses By Carlos Nunez
Carlos’ DevOps and Agile Slides From the Agile 2023 Conference
Agile Mentors Podcast from Mountain Goat Software
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Carlos Nunez is a DevOps consultant at VMWare, who enjoys making engineering and product development in complex environments fun, fast, and profitable through DevOps, everything-as-code, and clean software. You can find his training courses on LinkedIn Learning.

#70: The Role of a Leader in Agile with Mike Cohn

18 oktober 2023 | 29 min

Today, Brian sits down with Mike Cohn, the CEO of Mountain Goat Software to talk about how leaders can use agile concepts in order to keep their team operating at its best.

Overview

Today, on the Agile Mentors Podcast, Brian sits down with Mike Cohn, the CEO of Mountain Goat Software to discuss the role of a leader role in Agile.

Listen in as Mike and Brian share their combined years of knowledge to help leaders use agile concepts to avoid the pitfalls of becoming a manager “behaving badly.”

Listen Now to Discover:

[01:08] - Brian introduces the show and his special guest Mike Cohn here to talk about the role of a leader in the Agile space.
[01:53] - "Don't command, create a culture." Mike shares the difference between Agile leaders and traditional leadership.
[02:59] - The concern about a resurgence of ‘old-school’ leadership and the concerns that brings.
[04:48] - Mike shares how leaders can use agile concepts like self-organization, setting goals, choosing team members, and defining constraints in order to keep the team operating at its best. (Resource: Wicked Problems, Righteous Solutions: A Catologue of Modern Engineering Paradigms).
[06:26] - Brian shares options for management to allow teams to figure out how to address problems as a team.
[08:23] - Trust but verify isn't ideal—Mike shares why it’s better to manage by exception, i.e. giving trust upfront and asking questions later.
[11:18] - Did you know the Agile Mentors Podcast is brought to you by Mountain Goat Software? Whether you're looking to get Certified Scrum Master Training or would like Advanced Certified Scrum Product Owner® training, Mountain Goat has plenty of options. To see everything Mountain Goat has to offer visit Mountain Goat Software.
[12:01] - Delving into the complexity of the relationship between leadership and employees, especially when it comes to trust, self-organization, and planning.
[12:48] - Mike introduces the “Cone of Uncertainty” concept, sharing that having a plan is not a problem over any horizon, (over three days, three months, or three years) but managers need to accept that the level of precision in the plan should match the timeframe.
[14:23] - Mike refers to an article from Harvard Business Review that highlights the difference in scrutiny between product development deadlines and sales projections, and the need for a more balanced and flexible approach in evaluating both areas.
[16:05] - Language and terminology shape our perception—how the shift from "estimating" to "forecasting" helps facilitate the recognition of uncertainty in future predictions.
[19:12] - Mike shares an anecdote about a client in Kansas City, who wanted him to use the word "forecast" instead of "estimate."
[20:31] - The importance of assessing metric application in a leadership context.
[21:06] - Mike highlights the danger of using "velocity" as a metric for team performance, explaining how subtle pressure on teams can lead to estimate inflation, rendering velocity less reliable for forecasting and more as a tool to pressure (and demotivate) teams.
[24:12] - Brian encourages leaders to reflect on the motivation behind using things like velocity as a metric to measure teams and how this relates to the principles of self-organization in Agile.
[25:22] - How a lack of proper training during role transitions can lead to managers ‘behaving badly,’ despite well-intentioned actions.
[26:45] - A special thank you to Mike Cohn for joining us and sharing his knowledge. If you're interested in further discussions on this topic join us in the Agile Mentors Community where you can access exclusive content, participate in discussions, and attend Q&A calls with Mike and me.
[27:50] - As always we’d like to invite you to subscribe to the Agile Mentors Podcast on Apple Podcasts. 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:

Wicked Problems, Righteous Solutions: A Catologue of Modern Engineering Paradigms
Agile Mentors Podcast from Mountain Goat Software
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified Scrum Product Owner®
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#69: Should Scrum Masters Be Technical with Allison Pollard

11 oktober 2023 | 37 min

Today, Brian sits down with Allison Pollard on the Agile Mentors Podcast to discuss the age-old question: Should Scrum Masters be technical? Tune in for Allison’s insights during this thought-provoking episode. Overview Today, on the Agile Mentors Podcast, Brian sits down with Allison Pollard to tackle the age-old question: "Should Scrum Masters be technical?" Allison shares her extensive experience with this topic and the importance of a clear definition of “technical” within the Scrum Master role.

Allison candidly discusses the biases and assumptions associated with the expectation of Scrum Masters being technical and the potential impact in the workplace. Plus, she shares her advice for a more open and inclusive approach to accommodate diversity within the Agile community.

Listen in for a thought-provoking discussion that uncovers new perspectives and insights on Scrum Masters' technical expertise to help you find the right fit for your team.

Listen Now to Discover:

[01:22] - Brian welcomes Allison Pollard to the Agile Mentors podcast.
[03:31] - Alison introduces the topic of the show, which is whether Scrum Masters should be technical, her experience with the question of Scrum Masters' technical expertise, and the need for a clear definition of what "technical" means in this context.
[06:12] - What’s more important, technical skills or soft skills?
[07:55] - Alison shares an interview experience where a Scrum Master candidate underestimated the importance of technical debt, highlighting the need for Scrum Masters to be familiar with these concepts.
[11:41] - The importance of a willingness to adapt and grow.
[11:56] - The biases and assumptions associated with the expectation of Scrum Masters being technical and how that can create a division in the workplace.
[13:12] - The importance of acknowledging the limitations of personal experience.
[14:46] - The history of Scrum Masters as servant leaders and the impact this had on the role.
[20:49] - Brian shares the importance of understanding the business value of Agile practices.
[21:50] - Allison shares the importance of asking questions to gauge the comfort level of potential Scrum Masters in discussing various topics to determine how they will work with your team.
[22:32] - How biases and implicit assumptions related to Scrum Masters can affect hiring and promotions.
[22:51] - Today's episode is brought to you by Mountain Goat Software's Certified Product Owner course, a two-day training course that teaches you how to use the product backlog as a tool for project success. For more information, check out the Mountain Goat Software Certified Scrum and Agile Training Schedule.
[24:04] - Allison shares the importance of balancing servant leadership and focusing on tasks that help the team achieve results, rather than performing non-value-added tasks that hinder effectiveness.
[26:28] - The value of building personal relationships during off times.
[27:45] - They discuss biases and the importance of recognizing implicit biases when evaluating Scrum Masters' performance and effectiveness.
[29:39] - Helping diverse individuals succeed in Agile roles. The challenges people face due to biases and the need for systemic changes to better accommodate diversity in the Agile community.
[30:58] - Did you know recognizing impostor syndrome may be a sign that you are not an impostor? Plus, advice for overcoming imposter syndrome.
[32:37] - You can connect with Allison on LinkedIn or at Helping Improve LLC to find out more about the training and coaching she offers.
[33:05] - A huge thank you to Allison for being on the show. Did you know you can find all of the show notes and resources for all of the Agile Mentor Podcast on the Mountain Goat Software website? We had a question about the information shared on the recent show with Lance Dacy, you can find the show notes and resources from that show here.
[34:29] - If you enjoyed this episode share it with others and subscribe to the Agile Mentors Podcast on Apple Podcasts. Did you know we discuss every episode of the podcast in the Agile Mentors Community? Join us (a 12-month membership is included with any training class from Mountain Goat Software) and post your questions there. As always, if you have feedback or ideas for the show, just send us an email.

References and resources mentioned in the show:

Allison Pollard on LinkedIn
Helping Improve LLC
Helping Improve on LinkedIn
Agile Mentors Podcast from Mountain Goat Software
“#54: Unlocking Agile's Power in the World of Data Science with Lance Dacy”
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Certified Scrum Product Owner Training
Advanced Certified Scrum Product Owner®
Certified Scrum Master Training and Scrum Certification
Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Allison Pollard, the co-owner of Helping Improve LLC, is a coach, consultant, and trainer who brings the power of relationship systems intelligence to go beyond tasks, roles, and frameworks to create energy for change. As Program Director for Women in Agile's mentorship program, she champions diversity and amplifies women's voices, contributing to the agile community's growth. Allison is a Certified Professional Co-Active Coach and a seasoned speaker at global conferences, including Scrum Gatherings and the Agile Alliance Agile20xx conferences.

#68: The Pros and Cons and Real World Applications of SAFe with Mike Hall

4 oktober 2023 | 47 min

Join Brian on the Agile Mentors Podcast as he sits down with Mike Hall for a refreshing perspective on SAFe (Scaled Agile Framework), its real-world applications, and the hidden costs of a one-size-fits-all approach.

Overview

Today, on the Agile Mentors Podcast, Brian delves into the intricacies of SAFe (Scaled Agile Framework) with guest Mike Hall of Agile Authority.

Listen in as Mike shares the four essential steps for effective SAFe implementation, the hidden costs of a one-size-fits-all method, and why it's crucial to listen, understand, and honor the dynamics within your unique organization.

Tune in to gain a profound understanding of SAFe and how to make it work for your team.

Listen Now to Discover:

[01:21]- Brian Milner introduces his guest, Mike Hall, Founder and chief evangelist of Agile Authority to discuss the Scaled Agile Framework (SAFe).
[02:41] - Mike shares his background and perspective on SAFe and clarifies this is not a SAFe bashing session.
[05:07] - The importance of lean thinking and continuous improvement.
[06:13] - Mike shares the definition of SAFe and its core components, and popularity in Agile transformations.
[09:08] - The pros and cons of SAFe: Mike explains why SAFe appeals to executives and its popularity in addressing agile scaling needs.
[13:06] - Brian and Mike acknowledge the criticism of SAFe but discuss the appeal of its "connective tissue" concept.
[14:04] - Mike highlights some of the pros of SAFe, including the accessible resources and low risk. But also shares some potential issues like the importance of value alignment and the comprehensive yet generic nature of SAFe.
[16:53] - Improving SAFe: Brian asks Mike which aspects of SAFe he believes could be enhanced.
[17:19] - Mike discusses the issue of considerable overhead and complexity, especially in the full configuration mode. [18:35] - In SAFe there are six new team roles that require training investments along with the addition of 17 new recurring meetings (events) in SAFe and 31 new artifacts.
[20:51] - Mike discusses the extensive elements of SAFe, underlining new roles, meetings, and artifacts while emphasizing the need to evaluate their relevance for specific organizations.
[23:51] - Customizing SAFe to reduce waste and overhead, Mike raises the question of a more efficient way to leverage lean and agile concepts in a fit-for-purpose approach.
[28:45] - A word from our sponsor: Mountain Goat Software's Advanced Certified Scrum Product Owner® class teaches you the skills you need to increase your confidence, credibility, and value as a product owner with interactive software that makes the breakout exercises both valuable and fun. You’ll also receive 12 months of membership in the Agile Mentors Community.
[29:31] - Mike introduces the concept of simple scaling, and its focus on four common-sense steps to consider—with the flexibility to discard steps that don't apply.
[30:53] - Brian mentions #17: Getting There From Here: Agile Transformations with David Hawks.
[31:10] - Step 1: Start with a Clear Business Objective: Mike shares the importance of beginning with a well-defined objective.
[32:19] - Step 2: Observe, Understand, and Honor the Past: The most overlooked step, Mike shares why skipping it can be counterproductive.
[33:28] - Step 3: Align to the Flow of Value.
[34:28] - Step 4: Apply Targeted Agile Principles and Practices: Mike shares how specific Agile practices can be chosen to align with the business objective, like improving product quality.
[34:38] - Mike highlights Agile practices that enhance product quality, (such as working at a sustainable pace, shift-left testing, test-driven development, code reviews, and sprint reviews) and help reduce errors.
[35:09] - Mike discusses the concepts that can be used to align with the business objective of faster time-to-market.
[36:41] - Brian and Mike discuss the debate on targeted vs. mass deployment, the key factors driving this debate, and how Agile principles and practices can help.
[38:07] - Brian shares the significance of choosing the right guide for Agile transformations, emphasizing the importance of philosophy alignment.
[39:00] - Why every framework should come with a big red asterisk in the fine print.
[40:36] - Brian shares an analogy related to taking medicine, highlighting the importance of a targeted approach for organizations.
[43:01] - You can connect with Mike Hall, on the Agile Authority website.
[43:59] - Did you know we discuss every episode of the podcast in the Agile Mentors Community? Join us (a 12-month membership is included with any training class from Mountain Goat Software) and post your questions there. Additionally, if you enjoyed this episode share it with others and subscribe to the Agile Mentors Podcast on Apple Podcasts. As always, if you have feedback or ideas for the show, just email [email protected].

References and resources mentioned in the show:

Agile Authority
#17: Getting There From Here: Agile Transformations with David Hawks
Advanced Certified Scrum Product Owner®
Certified ScrumMaster Training and Scrum Certification
Certified Scrum Product Owner
Training Advanced Certified ScrumMaster®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Mike Hall, of Agile Authority is a seasoned Agile Coach/Trainer, who brings 20+ years of Agile experience, specializing in software development and technology leadership. With a rich repertoire of Agile and Scaled Agile certifications, including CSP, CSM, CSPO, and SPC6, he's a key player in Agile transformations.

#67: The Role Personality Plays in Team Dynamics with Dr. Ryne Sherman

27 september 2023 | 42 min

Join Brian on the Agile Mentors Podcast as he sits down with Dr. Ryne Sherman from Hogan Assessments to delve into the world of personality assessments. Tune in to discover how understanding individual strengths and motivations can help organizations make better hiring and team-building decisions.

Overview

What role does personality play in creating successful team dynamics?

Today, on the Agile Mentors Podcast, Brian sits down with Dr. Ryne Sherman, of Hogan Assessments, and the co-host of The Science of Personality Podcast for an in-depth discussion on how personality assessments can be used to revolutionize the way organizations make informed choices in hiring and assembling teams.

Dr. Sherman walks us through the diverse landscape of personality assessments, shedding light on their strengths and limitations. Then, he shares the unique approach embraced by Hogan Assessments to unveil profound insights into the members of your team and how they will work together.

Listen in to discover how gaining insight into the unique strengths and motivations of individuals within a team can cultivate greater unity, boost productivity, and create a more positive work environment.

Listen Now to Discover:

[01:15] - Brian introduces his guest, Dr. Ryne Sherman, Chief Science Officer at Hogan Assessments, and co-host of The Science of Personality Podcast to discuss the role of personality in team dynamics.
[03:19] - How Hogan Assessments helps organizations make better hiring and team-building decisions
[06:00] - The risk of hiring based on “likeability.”
[08:28] - How scientific assessments help ensure fair and objective hiring.
[10:03] - The historical evolution of personality assessments.
[14:31] - Dr. Sherman shares how the personality assessment process works.
[15:38] - There are many different types of personality assessments, and each serves a specific purpose. Dr. Sherman shares how those provided by Hogan Assessments are designed to offer more nuanced insights.
[19:27] - A word from our sponsor: Mountain Goat Software has designed our Certified Scrum Master Class as a two-day class that covers the fundamental principles of Scrum and more. Visit the Mountain Goat Software training schedule to learn more and schedule your training.
[20:08] - What personality tests actually measure.
[23:05] - Are you faking it? The biggest concern with most personality tests is they focus on the impressions individuals aim to make rather than the actual behavior. Dr. Sherman explains.
[26:37] - How assessments provide valuable insights into behavior, possible triggers, and suitability for specific roles.
[27:45] - How assessments aim to accommodate neurodiversity and cultural differences.
[32:34] - Why understanding individual strengths and motivations is essential for team cohesion and productivity.
[34:05] - Dr. Sherman shares the importance of transparency, and why you shouldn’t shy away from both positive and negative feedback to drive personal and team development.
[38:47] - You can connect with Dr. Ryne Sherman at Hogan Assessments, or tune into their podcast, The Science of Personality Podcast
[40:00] - If you enjoyed this fascinating episode share it with others and subscribe to the Agile Mentors Podcast on Apple Podcasts. For further discussion on personality assessments join the Agile Mentors Community and post your questions there. As always, if you have feedback or ideas for the show, just email [email protected].

References and resources mentioned in the show:

Hogan Assessments
The Science of Personality Podcast
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified ScrumMaster®
Advanced Certified Scrum Product Owner®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Ryne Sherman is a Doctor of Psychology and the Chief Science Officer at Hogan Assessments and also the co-host of The Science of Personality Podcast. Dr. Sherman has devoted his career to researching the interplay between situational factors and personality traits. His work at Hogan Assessments aims to assist organizations in comprehending the role of personality in the workplace.

#66: Successful Strategies for Navigating Team Conflicts

20 september 2023 | 37 min

Join us on the Agile Mentors Podcast as Brian unveils the secrets to resolving conflicts to achieve win-win outcomes in your Agile teams.

Overview

Whether you're a Scrum Master, Product Owner, or an Agile coach, conflicts are inevitable and can become messy if not navigated successfully.

Today, on the Agile Mentors Podcast, Brian guides us through various conflict types and shares techniques for effectively managing and resolving team conflicts. These methods encompass the Thomas-Kilmann Instrument (TKI) framework, facilitative listening, and the use of team agreements to validate differences, ensuring that everyone feels safe and acknowledged, creating win-win solutions for all involved.

Listen Now to Discover:

[02:29] - How we handle conflict on our teams.
[02:55] - Conflict is necessary for teams to challenge each other and make better decisions (Chernobyl disaster example).
[04:38] - Conflict is inevitable and can take various forms, including messy and sticky situations that are not always desirable.
[04:56] - Brian shares a past conflict management failure when as a Scrum Master, he inadequately handled a conflict between two team members, leading to a breakdown in communication and a loss of mutual respect.
[09:15] - The need for Scrum Masters to develop corporate counselor skills, such as emotional intelligence and empathy, to effectively counsel and navigate conflicts within teams.
[10:44] - Rational vs. Emotional conflict and the importance of shifting the focus back to the rational side for productive conflict resolution.
[12:15] - Brian shares the difference between constructive and destructive conflict and the signs of each.
[13:34] - The three types of conflicts in a team: task, relationship, and process conflicts and why it’s vital to understand the differences between these types of conflicts in order to navigate them effectively.
[16:20] - Mountain Goat Software has designed our Scrum Certification classes to combine the best learning with the best engagement. If you want to see it in action, check out our training pages at Mountain Goat Software today.
[17:22] - Each person has a default way of responding to conflict. You can identify your own response style using the Thomas-Kilmann Instrument (TKI) framework which divides responses into five categories: competing, collaborating, compromising, avoiding, and accommodating.
[18:32] - Competing involves prioritizing one's own position but it can be justifiable in certain situations.
[19:55] - Collaborating aims for win-win solutions through creative problem-solving, especially in scenarios with conflicting preferences.
[21:01] - The third C offers an acceptable solution that satisfies both individual's concerns.
[21:34] - Avoiding, marked by its unassertive and uncooperative nature, ultimately striving to sweep the conflict under the rug.
[22;42] - Accommodating prioritizes the relationship above all else, willingly setting aside one's own stance to adopt the opposing point of view.
[23:40] - Your default conflict resolution approach isn't necessarily bad; it can be effective in certain situations. Brian offers tips for recognizing and responding to these approaches in conflict situations.
[25:08] - Psychological safety in a team is vital for healthy conflict resolution. Brian explains what that means and how to build it within your team.
[28:10] - How team agreements can help prevent conflicts from turning destructive.
[28:40] - Putting ground rules in place on your team so that when conflict occurs, you can navigate it successfully.
[30:42] - Facilitative listening helps address problems without attacking personalities. Brian shares his techniques to assist others in hearing. Legitimizing differences by acknowledging and validating opposing viewpoints can help resolve conflicts within a team.
[32:29] - Overlooking human dynamics can lead to team failure but legitimizing differences helps everyone feel safe and heard.
[35:11] - If you enjoyed the episode, the best way to support us is to share it with others and subscribe to the Agile Mentors Podcast on Apple Podcasts. If you have feedback or ideas for the show, just email [email protected]. For further discussion join the Agile Mentors Community where we discuss each podcast episode.

References and resources mentioned in the show:

Thomas-Kilmann Instrument (TKI)
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified ScrumMaster®
Advanced Certified Scrum Product Owner®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenter is:

#65: Unlocking Lean Portfolio Management with Randy Hale

13 september 2023 | 32 min

Join Brian and his guest Randy Hale as they delve into the world of Lean Portfolio Management to drive Agile transformations and make informed decisions for greater business success.

Overview

In this episode of the Agile Mentors Podcast, Brian sits down with Agile Transformation Coach Randy Hale to discuss Lean Portfolio Management.

Listen in as they explore strategies for navigating organizational culture, redefining metrics, and addressing uncertainty to make informed business decisions and drive successful Agile transformations.

Listen Now to Discover:

[01:18] - Brian Milner welcomes Randy Hale of Agile Velocity to the Agile Mentors podcast to discuss Lean Portfolio Management.
[02:40] - Randy shares the definition of Lean Portfolio Management.
[04:07] - The first steps to implement Lean Portfolio Management.
[06:41] - How to engage finance and accounting teams in the conversations and emphasize optimizing value delivery.
[09:35] - What's broken with traditional budgeting?
[10:15] - How Lean Portfolio Management helps organizations more easily align with customer needs and adapt to swiftly changing market conditions.
[11:56] - Why traditional budgeting processes often lead to delays in responding to unexpected changes.
[14:15] - How cultural factors can hinder an organization's adaptation to changing circumstances.
[14:30] - Mountain Goat Software has designed the best training to help you stand out in the market. With live interactive courses and a mixture of lecture time and frequent breakout rooms to keep you engaged every second you're learning. All their courses are designed to give you the skills that agile teams and organizations value. For more information and the class schedule visit Mountain Goat Software today.
[16:19] - The key components in Lean Portfolio Management.
[18:34] - The value of early detection for proactive responses.
[19:31] - Randy discusses the impact of organizational culture on transformation efforts and the importance of adapting processes within a compliance-based culture.
[21:26] - Brian and Randy discuss the challenge of selecting meaningful metrics for effective decision-making.
[24:48] - Randy highlights the importance of addressing uncertainty and focusing on critical factors using a scenario where a projected $5 million in revenue failed to meet expectations due to unvalidated assumptions.
[25:21] - Brian discusses the common-sense principle that the further you are from a future event, the less precise your predictions can be.
[26:29] - The million-dollar point of the conversation.
[27:01] - The default way of tracking things that is disconnected from reality and the real value of what you deliver.
[28:57] - You can connect with Randy at Agile Velocity or via LinkedIn.
[30:32] - Don’t forget to subscribe to the Agile Mentors Podcast on Apple Podcasts. If you have feedback or ideas for the show, just email [email protected].
[31:04] - For further discussion about Lean Portfolio Management or any other topic on the Agile Mentors Podcast join the Agile Mentors Community.

References and resources mentioned in the show:

Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified ScrumMaster®
Advanced Certified Scrum Product Owner®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts
#17: Getting There From Here: Agile Transformations with David Hawks

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Randy Hale is an Agile Transformation Coach with over a decade of experience guiding companies through Agile transformations. Randy's hands-on knowledge and training have helped businesses of all sizes embrace Agile and Lean thinking for greater success including Fortune 500 companies like Nike, Petco, and Charter Communications.

#64: How Agile Methodologies are Reshaping Legal Practices with John Grant

6 september 2023 | 34 min

Join Brian and his guest John Grant as they unveil how Agile methodologies are revolutionizing legal practices for improved client experiences and smarter workflow efficiency.

Overview

In this episode of the Agile Mentors Podcast, Brian sits down with John Grant to discuss using Agile methodologies and client-focused strategies in the legal profession. Listen in as John shares his unique perspective and innovative approach for reshaping legal workflows and enhancing client communication at the intersection of law and Agile practices.

Listen Now to Discover:

[01:00] - Brian introduces the podcast and guest, John Grant, a lawyer using Agile in the legal space.
[01:19] - How legal use of Agile differs from other fields.
[02:06] - John shares how clarity in communication is a challenge in legal work, similar to other fields.
[03:00] - Brian compares legal work to building websites.
[03:43] - John differentiates between "sheet music" (standardized work) and "jazz solos" (unique cases) in legal practice.
[05:16] - The challenges of a high demand for legal services and a shortage of lawyers and how to ensure quality.
[08:23] - John explains why the Kanban method is well-suited for legal practices.
[09:27] - How to avoid overloading capacity and prioritize effectively.
[11:39] - How the principles of Agile, Lean, and other methodologies, along with a focus on client value, are crucial even outside software development.
[12:09] - The tendency to devalue the client's role in legal matters and the challenge of balancing technical work and customer care.
[12:31] - The role of lawyers and discerning what clients genuinely want from legal services.
[12:49] - The law is fundamentally a caregiving profession: John emphasizes the importance of caregiving and customer support in the legal profession.
[13:31] - The need for effective communication and collaboration.
[15:00] - John shares a case study involving a law firm specializing in estate planning and trust administration.
[15:47] - John explains the creation of a multi-step client journey roadmap in the introduction letter, setting the tone for the client journey.
[17:30] - The unique role of clients in legal work and how they contribute vital information to the legal team.
[18:48] - This podcast is sponsored by Mountain Goat Software’s Certified Scrum Training classes. All certified classes include a twelve-month membership in the Agile Mentors Community.
[19:36] - Brian draws parallels between capturing customer attitudes and feelings in personas in Certified Scrum Product Owner® classes and the importance of understanding clients' emotions in legal work.
[20:21] - Daniel Katz's breakdown of clients seeking legal help to either mitigate risk or navigate complexity, and how this helps tailor the client journey.
[21:35] - The frequent client complaint in the legal field.
[23:09] - John explains how mapping workflows to the client journey introduces the concept of classes of service and enables smarter prioritization of work based on its urgency and importance.
[23:32] - The key Agile concepts applied in the legal context: focusing on the customer, limiting work in progress, understanding customer journeys, and making work visible.
[23:53] - Humans are naturally inclined to process information visually and the significance of visualizing work in knowledge work environments.
[25:00] - The scalability of Kanban in law firms.
[28:31] - John introduces the concept of the "help desk theory of lawyering," comparing lawyers' support roles to IT help desks and how Kanban systems can aid communication with clients.
[31:22] - For more information on John’s Kanban training visit Agile Attorney.
[32:00] - If you enjoyed the episode, the best way to support us is to share it with others and subscribe to the Agile Mentors Podcast on Apple Podcasts. If you have feedback or ideas for the show, just email [email protected].
[33:24] - For further discussion join the Agile Mentors Community where we discuss each podcast episode.

References and resources mentioned in the show:

Agile Attorney
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified ScrumMaster®
Advanced Certified Scrum Product Owner®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

John Grant is a fourth-generation lawyer with a background spanning both technology and law. Drawing from his experience in the tech industry and legal sector, he offers a unique perspective on legal practice. He's passionate about facilitating positive change in legal practices and using the Kanban methodology to help legal teams unlock their full potential.

#63: The Interplay Between Data Science and Agile with Lance Dacy

30 augusti 2023 | 55 min

Join Brian and his guest Lance Dacy as they address the interplay (and the skepticism) of combining Agile and data science. Tune in as they explore the art of crafting Minimum Viable Products (MVPs) to create impactful and efficient solutions.

Overview

In this episode of the Agile Mentors Podcast, Brian sits down with Lance Dacy to delve into the nuances of aligning data science with the software development mold while dispelling the myths along the way.

Listen in as Lance shares his wealth of experience and insights guiding listeners through the step-by-step process of building MVPs in data science projects and sharing how Agile principles seamlessly apply to both worlds.

Listen Now to Discover:

[01:13] - Brian introduces Lance Dacy on the Agile Mentors Podcast. Since listeners appreciated the previous data science and agile episode, Lance is here for Part Two, this time discussing how data science fits into the software development mold.
[02:00] - Addressing the skepticism of combining agile and data science; Lance has both expertise and practical experience.
[02:43] - Lance emphasizes that he understands the “naysayers” concerns but aims to help others comprehend the synergy.
[03:05] - Waterfall might be better: sorting out the different perspectives on Agile development and data science.
[04:45] - The importance of scoping and architecture in software development projects.
[05:15] - Challenging the notion of perfectly defined objectives.
[05:46] - Most software projects lack a completely predefined understanding.
[06:39] - How Agile's empirical process and mindset of experimentation align with data science.
[07:30] - Presenting a real-world MVP example combining business drivers and data science techniques.
[08:04] - Clarifying what Agile is—a philosophy based on values, not a step-by-step process.
[09:03] - The importance of sustainable pace and productivity in Agile.
[10:10] - Introducing the concept of MVP and acknowledging the evolution of data science techniques.
[11:00] - Discussing MVP in the context of data science, and aligning it with empirical approach.
[11:38] - Highlighting the role of MVP in testing assumptions, mitigating risks, and user feedback.
[12:00] - Exploring data science's practical relevance for consumers to forge a relatable discussion.
[12:47] -Acknowledging familiarity with technology, uncertain about tactics.
[13:00] - Highlighting how AI and data science are pervasive in everyday technology use.
[13:29] - Examples of AI data science integration: search engines, online shopping recommendations, social media content, smart homes, and more.
[14:42] - Introducing common uses of data science: customer segmentation and marketing techniques.
[15:19] - Applying clustering techniques like K means for automated segmentation.
[15:34] - Lance shares his paper on supply chain optimization, using an ant colony algorithm.
[15:56] - The techniques and purpose of supply chain optimization.
[16:23] - Exploring data science applications: collaborative filtering, matrix factorization, neural networks.
[16:42] - Clarifying data scientists' approach: not a random process but based on problem-solving with models.
[17:18] - Iterative development as a primary reason for MVP in data science.
[17:57] - Using real-world performance data for model improvement.
[18:21] - Risk mitigation as a critical aspect of MVP: linking risk mitigation to surviving challenges and learning from them.
[19:51] - Starting with an MVP reduces risk by avoiding overly complex models without sufficient feedback.
[20:19] - Setting stakeholder expectations with an MVP: providing tangible insight into data science trade-offs and early deliverables.
[20:39] - Highlighting operational considerations of deploying and maintaining data models, addressing challenges in data pipelines, infrastructure, and monitoring.
[22:17] - An MVP approach aligns with Agile principles for data science.
[22:35] - Brian clarifies the misconception that MVP means sacrificing quality for speed.
[23:30] - Lance agrees, addressing the misconception, and emphasizes MVP's importance in learning and improvement.
[23:32] - Have you thought about training with Mountain Goat Software? With classes such as Mountain Goat Software, Certified Scrum Product Owner (CSPO) developed by Mike Cohn, and team home software for better interactivity during classes you can’t go wrong.
[24:00] - Brian suggests transitioning to walking through a model or example of creating an MVP.
[24:07] -A tangible framework for mapping data science work to MVP steps, acknowledging the contextual nature of the process.
[24:50] - Lance acknowledges the complexity of the steps, so they’ve been posted below under resources.
[25:11] - The importance of problem definition and defining the scope of the MVP.
[26:34] - The challenge of gathering and preprocessing data.
[27:20] - Selecting a simple model that is easy to interpret and implement for faster training times, easier troubleshooting, and adherence to the principle of parsimony.
[29:12] - Using feature engineering to select the most relevant features for the model.
[29:33] - Choosing a manageable number of features for the model, rather than attempting to incorporate all available data and avoid overcomplicating or overfitting the model.
[30:11] - Lance emphasizes the importance of selecting a simple model and conducting feature engineering based on the insights gained from that model.
[30:36] - Training the chosen machine learning model using pre-processed data, typically by splitting the data into training and validation sets.
[31:15] - The challenge of evaluating the model's performance and the importance of using the appropriate metrics.
[31:34] - The goal: create a model that is good enough for gathering feedback that aligns with the concept of MVP.
[31:53] - Lance describes the last step of building an MVP: deploying the MVP by integrating the model into a suitable platform or application.
[32:26] - The importance of making the MVP accessible to end users.
[33:00] - The crucial feedback loop for making improvements to the model and features, and refining, scaling, or reconsidering the approach.
[34:09] - Why you might want to initially deploy a slightly higher-level model.
[34:57] - The parallel between the steps of creating an MVP in data science and the principles of Agile.
[35:18] - Brian adds that in data science, feedback not only comes from customers and users but also involves analyzing results and outcomes as a form of feedback to refine the model.
[35:53] - The importance of relying on scientific expertise to analyze the results of the model and evaluate its accuracy and validity.
[36:10] - In data science, the feedback loop also involves analyzing the outcomes and results, similar to the iterative process of receiving user feedback in software development.
[37:00] - Lance draws parallels between software development and data science by comparing the process of building software features with the steps involved in creating an MVP for data science.
[39:21] - Lance offers some practical examples, beginning with a recommendation system.
[41:06] - The decision tree approach and its benefits for stakeholders.
[43:00] - Lance talks about churn prediction to gradually incorporate more nuanced data.
[43:55] - MVPs for chatbots and the benefits of starting with simple scripted responses in a chatbot MVP.
[45:59] - Managing multiple projects.
[46:24] - The effectiveness of using logistic regression and decision trees for MVPs.
[47:00] - Lance emphasizes the importance of managing stakeholders' expectations.
[47:53] - Lance discusses the need to consider the context when interpreting model performance metrics and involving stakeholders in these discussions.
[49:16] - The importance of collaboration between data scientists and stakeholders for delivering valuable solutions.
[50:11] - Lance draws a comparison between data science and software development in terms of the challenge of coordinating work across different specialized areas.
[51:00] - Lance highlights the importance of feedback and iterative adjustments for success.
[53:24] - Again, you can find Episode #54: Unlocking Agile's Power in the World of Data Science with Lance Dacy, here.
[53:48] - We’d love to hear your thoughts on this topic and your suggestions for future topics. Just email [email protected]. If you enjoyed the episode, the best way to support us is to share it with others and subscribe to the Agile Mentors Podcast on Apple Podcasts.
[55:00] - Don’t forget to check out the Mountain Goat Software Certified Scrum and Agile Training Schedule, including, Certified Scrum Master (CSM) or a Certified Scrum Product Owner (CSPO) and Advanced Certified Scrum Master (ACSM) and Advanced Certified Scrum Product Owner (ACSPO) classes. I'd really love to see you in class!

References and resources mentioned in the show:

6 Reasons Why I Think Agile Data Science Does Not Work | by Ilro Lee
Why Data Science Doesn't Respond Well to Agile Methodologies
Lance’s SMU Paper (Ant Colony Algorithm and Traveling Salesman Problem)
#54: Unlocking Agile's Power in the World of Data Science with Lance Dacy
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified ScrumMaster®
Advanced Certified Scrum Product Owner®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Reasons for Quick MVP in Data Science are to support:

Iterative Development
Feedback Loop
Risk Mitigation
Setting Expectations
Operational Considerations

Steps of the MVP:

Problem Definition
Gather and Preprocess the Data
Select a simple model
Feature engineering
Train the model
Evaluate the model
Deploy the MVP
Collect Feedback
Iterate
Decision Time

Examples of MVP in Data Science (Logistic regression and decision trees are often used as initial models due to their simplicity, interpretability, and relatively quick development time.)

Recommendation Systems: Instead of building a complex recommendation engine, a company might start with a simple rule-based system (e.g., recommending the most popular items) to gauge user interest and system engagement.
Churn Prediction: An MVP might involve creating a basic model based on a few key features (like usage frequency and customer complaints) to predict which customers might churn. Later versions can incorporate more nuanced data and sophisticated algorithms.
Natural Language Processing (NLP): For a chatbot, the MVP might involve scripted responses or basic keyword matching. Once deployed, user interactions can inform the development of more advanced NLP capabilities

Conclusion

With Rapid MVP, context is crucial with regard to our general benchmarks (F1-Score, ROC-AUC, MAE, RMSE). You should strive to always consider the context of those benchmarks with the problem being solved. In some medical diagnostic tests, even an F1-score of 0.95 might not be good enough due to the severe consequences of false negatives or false positives. We also likely need to compare the model's performance metrics with a simple baseline (e.g., random classifier, mean prediction) to determine how much value the model is adding. Always align the model's performance with business objectives. Even a model with a high ROC-AUC might not be suitable if it doesn't meet the specific precision or recall targets set by the business. Isn’t it better to find ways to know that earlier than later?

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#62: Effective Sprint Goals with Maarten Dalmijn

23 augusti 2023 | 31 min

In this new episode of the Agile Mentors Podcast, Brian welcomes Maarten Dalmijn to discuss the secrets to setting impactful sprint goals, fostering collaboration, and bridging the gap between team objectives and stakeholder expectations for Agile success.

Overview

In this new episode of the Agile Mentors Podcast, Brian is joined by Maarten Dalmijn, author of the new book, Driving Value with Sprint Goals: Humble Plans, Exceptional Results to share his invaluable insights into the art of crafting effective sprint goals.

Maarten shares his wealth of knowledge including how to navigate the challenges of setting sprint goals while ensuring alignment with stakeholders' expectation, and optimizing team structure while fostering a collaborative environment that ensures success.

Listen in as Maarten and Brian explore the essence of sprint goals, the strategies behind their formulation and the impact they have on Agile projects.

Listen Now to Discover:

[1:06] - Today, Brian is sitting down with Maarten Dalmijn, of Dalmijn Consulting and author the book Driving Value with Sprint Goals: Humble Plans, Exceptional Results that’s the number one new release in software design and engineering on on Amazon to discuss sprint goals.
[2:16] - Maarten explains the concept of sprint goals using the analogy of a military commander's intent during missions.
[3:22] - Brian shares how sprint goals serve as a commander's intent for the team's work.
[4:07] - Maarten highlights that a sprint goal is not about completing a list of tasks but rather identifying the most important objective for the sprint.
[5:24] - The challenges of conceptualizing sprint goals.
[5:58] - Unable to set a single spring goal? Maarten addresses the question of setting a sprint goal for teams with multiple purposes or projects.
[7:29] - Scenarios where setting a single sprint goal might not be feasible.
[8:31] -The challenge of staying focused on the sprint goal when encountering obstacles.
[9:44] - Maarten shares an example of the importance of knowing the underlying business objective when setting a spring goal.
[11:08] - The importance of managing stakeholder expectations by communicating and aligning stakeholders with the sprint goal to prevent last minute surprises.
[12:19] - Brian draws a parallel between sprint goals and TV episode titles, highlighting the need to share the sprint goal in the sprint review to prevent surprises and encourage stakeholder engagement.
[15:28] - Are you thinking about getting certified as a Scrum Master? If so, check out the resources and training options with our sponsor, Mountain Goat Software. They run interactive certification classes every week that include 12 months membership in the Agile Mentors Community.
[16:10] - Setting achievable vs. challenging sprint goals and what Maarten advocates for.
[19:46] - Brian shares a teaching example.
[20:12] - Maarten introduces the acronym "FOCUS" to assess the quality of sprint goals: Fun, Outcome-oriented, Collaborative, Ultimate, and Singular and shares each one’s role in creating effective sprint goals.
[22:12] - Maarten discusses the importance of stakeholder management and its connection to clear vision and strategy within organizations.
[22:47] -The role of team structure in setting sprint goals.
[24:17] - Managing stakeholder pushback during sprint reviews. Maarten underscores the importance of working as a team with stakeholders to foster effective communication and alignment.
[26:50] - The impact of planning and road mapping on the ability to set sprint goals.
[28:21] - What stakeholders ultimately want.
[29:18] - You can find Maarten’s book, Driving Value with Sprint Goals: Humble Plans, Exceptional Results on Amazon. It’s part of the Mike Cohn book series.
[29:50] - To continue the discussion, Join Us in the Agile Mentors Community, there’s a discussion about every episode of the podcast on there.
[30:30] - Your feedback is valuable, we’d love to hear from you. Feel free to email us by clicking here. We'd love your thoughts about today's show and suggestions for future episodes.
[31:04] - If you enjoyed the episode, the best way to support us is to share it with others and subscribe to the Agile Mentors Podcast on Apple Podcasts.

References and resources mentioned in the show:

Dalmijn Consulting
Maarten Dalmijn
Driving Value with Sprint Goals: Humble Plans, Exceptional Results
Certified Scrum Master Training and Scrum Certification
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Brian Milner is the 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.

Maarten Dalmijn of Dalmijn Consulting is an accomplished speaker at Fortune 500 firms, governmental bodies, and global conferences, who thrives at the nexus of Product Management and Agile. With a decade of versatile experience spanning roles from Marketing Manager to Scrum Master, he empowers teams to transcend the Feature Factory and achieve impactful value delivery. Maarten is the author of the recently released Driving Value with Sprint Goals: Humble Plans, Exceptional Results.

#61: The Complex Factors in The Office Vs. Remote Debate with Scott Dunn

16 augusti 2023 | 34 min

In this episode of Agile Mentors Podcast, Brian, and Scott Dunn delve into the biggest question challenging teams right now: Should they return to the office or continue to embrace remote work? Join us as we navigate the complex factors in the office vs. remote debate.

Overview

Across industries, the call to return to the office is gaining momentum among management circles. In this episode of the Agile Mentors Podcast, Brian sits down with Scott Dunn, to unravel the layers of the working in the office versus remote settings debate.

Listen in as they discuss various perspectives and considerations such as productivity, work-life balance, leadership styles, personality types, and even economic factors that influence the decision to have your team in the office or at home and what truly defines an effective workspace.

Tune in as Scott and Brian share valuable insights into the ongoing debate that's reshaping the modern work landscape

Listen Now to Discover:

[01:31] - Brian welcomes guest Scott Dunn to the show to discuss their feelings toward management saying it’s time to return to the office post-Covid.
[02:48] - Everyone’s affected in one way or another by the return to the office vs the prevailing “squishy” remote work policy.
[04:01] - Where are you really the most productive?
[04:16] - The basic needs of a generation: why “fully remote” is so appealing to Gen Z.
[05:55] - Words straight from the Agile manifesto that supports in-person work and face-to-face communication.
[06:44] - Quantifying what’s been lost from being face-to-face to being fully remote.
[07:13] - How open working sessions and working side by side but independently boosts productivity.
[07:41] - The tools that elevate remote collaboration and help facilitate small group dynamics when working remotely.
[09:31] - Remote work and the allure of opening the talent pool combined with less turnover is a game-changer.
[10:26] - How to run a focused remote work trial to assess applicants and gather insights.
[10:58] - It's about more than just the comfort or preference of the leadership team.
[11:23] - The most critical factor in determining if you have a hiring problem.
[12:03] - How to deal with the issue of unequal contribution and improve team dynamics.
[12:39] - Why managers have concerns about remote and how to alleviate them.
[13:27] - How to enhance team accountability and empower team members by implementing measurable tracking to ensure everyone's pulling their weight.
[14:48] - Drive positive change by experimenting and then taking action.
[19:41] - The Agile Mentors Podcast is proudly sponsored by Mountain Goat Software with a range of training options, from Scrum certifications to skill enhancement, visit www.mountaingoatsoftware.com.
[15:25] - How to balance support for employees with managerial accountability.
[16:00] -The correlation between happy employees and productivity. Simon Sinek's insights highlight the connection between employee happiness and success.
[17:07] - The vital (and challenging) responsibility of leaders to not only guide teams but define the expectations of the company culture.
[19:00] - Open dialog and constructive conflict: Patrick Lencioni’s approach to vulnerable leadership for trust and psychological safety.
[19:35] - How to spark healthy conflict and promote results.
[20:00] - The importance of acknowledging personality differences, diverse working styles, and ideal working conditions.
[20:37] - How to encourage open dialogue to address concerns and foster employee ownership.
[21:14] - Leading the conversations about remote work to the right approach.
[21:40] - Embracing personal user manuals for improved teamwork.
[22:14] - How to embrace a balanced approach that values different work styles.
[23:35] - How introverted and extroverted differences can impact experiences: How constructive feedback promotes awareness and inclusive adjustments.
[26:16] - Why remote work decisions should be rooted in culture and individual fit rather than an across-the-board, fixed policy.
[27:09] - How a hybrid approach accommodates diverse work styles.
[27:29] - Remote teams, as shown by a Harvard Business Review study, can be more productive, especially when employees overwork to prove their worth from home.
[28:11] - How to help employees align with teams that suit their work styles.
[28:45] - Consider implementing a system where teams choose to be fully remote or not, allowing for a comprehensive evaluation of factors like productivity, team happiness, and innovation.
[29:02] - How to help fully remote teams take ownership of their success.
[29:32] - Weighing all the factors in the remote vs. in-person debate is essential, for aligning goals, ensuring meaningful decision-making, and opening the door to change.
[30:33] - How the critically important remote work decision will impact future Scrum teams', economic considerations, and overall work-life balance.
[31:10] - We don’t claim to have definitive answers but hope you enjoyed our conversation on navigating complex workplace challenges.
[32:09] - Your feedback is valuable. We'd love your thoughts about today's show or any suggestions for future topics for the show. Email us by clicking here.
[33:24] - We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here. If you enjoyed the episode, share it with others and subscribe to the Agile Mentors Podcast on Apple Podcasts.

References and resources mentioned in the show:

Miro
Start With Why by Simon Sinek
The Five Dysfunctions of a Team by Patrick Lencioni
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#60: Breaking the Agile Déjà Vu: Tackling Recurring Anti-Patterns with Reese Schmit

9 augusti 2023 | 39 min

In this episode of the Agile Mentors Podcast, Brian welcomes Agile coach Reese Schmit who shares her tips for breaking recurring anti-patterns in teams and organizations through the power of the why.

Overview

In this episode of the Agile Mentors Podcast, Brian is joined by Agile Coach Reese Schmit to discuss identifying and tackling recurring Agile anti-patterns in teams and organizations. Reese shares her valuable insights on the significance of understanding the "why" behind Agile practice and avoiding the trap of "cargo cult Scrum." Listen in as she shares her tips for fostering transparency, collaboration, and trust among team members and how rediscovering the purpose behind Agile practices can lead to a world where people are excited and happy about their work.

Listen Now to Discover:

[01:10] - Brian sits down with guest Reese Schmit, a coach, trainer, and mom, from the Agile 2023 Conference in Orlando, to discuss identifying and tackling recurring Agile anti-patterns in teams and organizations.
[03:10] - Reese talks about her revelation during an open jam session at the Agile 2023 Conference, where she realized the prevalence of the same anti-patterns across different teams and organizations over the past 15 years.
[05:04] - Brian and Reese discuss the frustratingly common situation of organizations claiming uniqueness but facing the same Agile challenges.
[06:19] - Reese highlights the misguided approach of blindly adhering to Agile frameworks like Scrum without understanding the principles.
[06:38] - Overplanning and white-knuckling the backlog = irrelevant user stories and wasted efforts.
[07:25] - Reese shares her journey as a Certified Scrum Trainer (CST) and her initial motivation to uncover the reasons behind the persistent issues in Agile implementations.
[08:54] - Brian uses the analogy of a road trip to bring home the concept of why teams need a clear goal to keep them engaged and aligned with the Agile transformation rather than just imposing Agile practices on them. [09:35] - Organizations driving without a clear destination end up with confusion, disengagement, and a sense of going through the motions.
[10:32] - Reese emphasizes the importance of a clear "why" at all levels - from product features to team goals.
[11:16] - Reese shares her early experiences as a Scrum Master, where she lacked a clear understanding of a "cargo cult" mentality in your organization.
[12:24] - The critical role of understanding the "why" behind Agile practices.
[12:28] - Brian references Dan Pink's ideas on autonomy, mastery, and purpose, about the importance of understanding the "why" and measuring progress.
[13:07] - Lack of autonomy results in disengagement, ineffective retrospectives, and helplessness to fix issues.
[13:56] - Reese emphasizes the significance of recognizing the capabilities of team members and trusting them to build better products, teams, and organizations.
[14:38] - Brian mentions a talk by Dr. Anne-Marie Charrett, a psychologist, that discussed the issue of trust within teams and what that entails.
[15:40] - Reese shares her approach to building product teams based on expertise and interest rather than imposed structures.
[16:46] - Brian emphasizes the importance of paying attention to the team's preferences when organizing them around products.
[17:37] - Reese highlights the challenges faced in true Agile transformations, and why merely renaming roles or events does not lead to a shift in mindset or a genuine transformation.
[18:15] - What true Agile adoption requires.
[19:16] - Missing Opportunities: Organizations that fail to embrace Agile's inspect-and-adapt principle miss out on the chance to improve products based on real user feedback, optimize ROI, and focus on delivering the highest value to customers.
[19:41] - Today’s show is brought to you by Mountain Goat Software's Advanced Certified Product Owner® Course, a two-day training course led by a certified Scrum trainer.
[20:16] -Understanding the "why" allows for better adaptation and problem-solving.
[21:26] - Reese emphasizes that Agile issues are often complex and not solved by one-size-fits-all solutions.
[23:37] - Brian shares how presumptive fixes can lead to misunderstandings and reduced trust.
[25:46] - Recognize that team members are capable and intelligent professionals to foster trust and collaboration.
[26:58] - Reese emphasizes the need to help organizations acknowledge when their information or assumptions are wrong.
[27:30] - The importance of having a clear sprint goal (hint: it transforms ceremonies into meaningful events where collaboration happens).
[30:35] - Clear communication about the purpose of events enhances effectiveness.
[31:48] - Avoid pointless meetings.
[32:12] - Overcoming inertia is essential to make meaningful progress.
[32:58] - Reese humorously references a book on becoming healthy, which boils things down to the simplest terms, (eating veggies, sleeping enough, drinking water). Agile success can also be obtained simply, too by focusing on the fundamental principles.
[35:31] - Rediscovering the purpose behind Agile practices can lead to a world where people are excited and happy about their work.
[36:56] - Making a pact for improvement: Brian encourages listeners to take the lessons from the discussion and make a pact to focus on the core principles and purpose behind Agile practices.
[37:09] - Your feedback is valuable, so email us by clicking here. We'd love your thoughts about today's show and suggestions for future topics for the show.
[37:47] - If you enjoyed the episode, the best way to support us is to share it with others and subscribe to the Agile Mentors Podcast on Apple Podcasts.

References and resources mentioned in the show:

Daniel Pink
Drive
Anne-Marie Charrett
Advanced Certified Scrum Product Owner®
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast on Apple Podcasts
Agile 2023 Conference in Orlando

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Reese Schmit is an Agile coach, trainer, and mom with nearly two decades of experience in the software industry, she wears multiple hats. With a deep understanding of Scrum, Kanban, and Agile methodologies, she fosters change through empathy, driving customer value, and continuous improvement. An avid volunteer for Agile organizations and conferences, she balances her time between coaching and enjoying life with her family and pets.

#59: Revising the Scrum Guide with Don McGreal

2 augusti 2023 | 43 min

In this episode of the Agile Mentors Podcast, Brian welcomes Don McGreal to discuss the revision of the Scrum Guide and the delicate balance between staying true to the core principles of Scrum while allowing for necessary flexibility.

Overview

In this episode of the Agile Mentors Podcast, Brian is joined by Don McGreal, to delve into the topic of revising the Scrum Guide.

Don shares some of the behind-the-scenes of the decision-making process, and the rationale behind the crucial revisions that have shaped the latest version of the Scrum Guide.

Listen in to gain a deeper understanding of the principles that guide Scrum and how they continue to evolve and the delicate balance between staying true to the core principles while allowing for necessary flexibility.

Listen Now to Discover:

[01:11] - Brian welcomes us to the show and introduces his guest, Don McGreal, the Founder and Vice President of Learning Solutions for Improving, author of “The Professional Product Owner” and a big name in the Scrum.org community to talk about revising the Scrum Guide.
[04:27] - Don shares how he got involved in revising the Scrum Guide.
[05:21] - One team, one group focused on the product.
[06:57] - What a scrum team consists of now and why they made the change.
[08:11]- We don't expect you to have a title on your business card.
[08:53] -The switch from role to accountability.
[10:51] - Ten people on a team, one Scrum master, one product owner: It's not illegal in Scrum to take on more than one set of accountabilities or have a bigger team but there are risks involved.
[12:51] - Three people using Scrum to work through treatments for a child with autism.
[13:34] - Why the team decided to stick with the term "developer."
[16:22] - Other terms, including "sprint" and 'backlog" that caused debates and why they stuck.
[17:39] - Scrum sounds different because it IS.
[18:20] - True Leader: the hot-button topic in the scrum guide that people are still debating, and how they landed on their decision.
[19:52] - Clarifying the term "serve" and the need for true leaders who empower the team and make things happen beyond just serving.
[21:21] - Today’s show is brought to you by Mountain Goat Software's, Advanced Certified Product Owner® Course, which aims to enhance product owners' skills, confidence, and credibility. The course offers lifetime access to materials and interactive software for valuable and enjoyable breakout exercises. Additionally, participants gain access to Mike Cohn's Agile Mentors Community, with 12 months of ongoing coaching and support.
[22:00] - The decision to drop the three questions from the Daily and the new approach.
[22:47] - A significant addition to the Scrum framework – the concept of a product goal representing the journey towards a vision.
[23:40] - The (results-driven) power of the product goal as inspired by “The 4 Disciplines of Execution." and how it’s changed how backlogs are managed and success is measured.
[25:00] - Changing the measure of success: measuring success by value rather than checking things off a backlog list.
[25:26] - The vision is the big idea-the product goal is the milestone. It's a step towards the vision.
[26:21] - In the revised Scrum Guide, the product goal is now part of the product backlog, emphasizing a commitment to achieving objectives with sprint and product goals focusing on the overall goal, not every task, while the Definition of Done ensures the increment's success.
[29:28] - Before the new Scrum Guide, teams working on multiple products had debates on having one prioritized backlog or multiple lists.
[30:12] - How the introduction of the product goal in the Scrum Guide directed teams towards having one focused direction, (preventing everything from being equally important).
[31:06] - How emphasizing one strategic focus helped teams with multiple products alleviate challenges with prioritizing and improved their approach and alignment.
[31:43] - Product backlog with mixed products lacks direction. Product goal provides focus without excluding other items.
[33:15] - Some of the controversial changes, like making refinement an event and concerns about terminology like "master" in Scrum roles.
[34:49] - The term "immutable" in the Scrum Guide means unchanging, which some find bothersome, but it serves to maintain consistency and distinguish genuine Scrum from modified versions.
[36:49] - It's immutable, and it isn't suffocating. It's a lightweight framework described in a 13-page document—there's a lot of wiggle room in there—give it a shot and give it its best chance to succeed by following these simple rules.
[37:28] - Change it if you must but then stop calling it Scrum.
[38:05] - The sacred text about Scrum is meant to be easy to take on, helpful…AND flexible.
[39:22] - Learning from the early days: streamlining a 200-300 page document with legal complexities into the current Scrum Guide, while aiming to distill its essence and promote simplicity and accessibility.
[40:48] - You can find out more about Don and Improving by visiting their website. Additionally, Don's book, "The Professional Product Owner," can be found on Amazon.
[41:07] - If you enjoyed the episode, the best way to support us is to share it with others and subscribe to the Agile Mentors Podcast on Apple Podcasts. Your feedback is valuable, so feel free to email us by clicking here.

References and resources mentioned in the show:

Scrum Guides
Improving
The Professional Product Owner: Leveraging Scrum as a Competitive Advantage
Scrum.org
The 4 Disciplines of Execution
Advanced Certified Scrum Product Owner®
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Don McGreal is Vice President of Learning Solutions at Improving, and author of the best-selling book: 'The Professional Product Owner: Leveraging Scrum as a Competitive Advantage', and a Scrum.org Professional Scrum Trainer who has authored and taught classes for thousands of professionals around the globe.

#58: Help! My Retrospectives Are Boring

26 juli 2023 | 18 min

Are your retrospectives boring? Join us on the latest episode of the Agile Mentors Podcast as Brian shares valuable insights on how to supercharge your retrospectives. Discover the three root causes behind boring or ineffective retrospectives and unlock tips to enhance their effectiveness.

Overview

Today on the Agile Mentors Podcast Brian Milner shares valuable insights on supercharging your retrospectives.

Listen in to discover the three root causes behind boring or ineffective retrospectives, plus Brian shares his tips on ways to enhance their effectiveness.

Tune in as Brian unveils some innovative ways to breathe new life into your retrospective themes while creating more meaningful connections within your team and fostering a deeper understanding of the bigger picture.

Listen Now to Discover:

[01:18] - On this last podcast episode for July, Brian offers insight into the three root causes behind uninteresting or ineffective retrospectives and tips to enhance and revitalize your retrospectives.
[01:58] - Are your retrospectives boring? To supercharge your retrospectives: don't just go through the motions; take ownership, connect the dots, and make things happen.
[02:45] - Scrum Guide Tip: to progress towards resolving the biggest issues, put action items from your current sprint into your next sprint's backlog.
[03:25] - You don't have to solve everything in one sprint.
[03:51] - Showing your team their recent successes can help with motivation.
[04:22] - How to make your retrospectives less boring. Boredom buster #1: make them effective—avoid repeating the same issues.
[04:43] - Boredom buster #2: transparency is vital in boosting collaboration and trust—create a safe space for open discussions (use anonymous voting to gauge team comfort).
[06:10] - Equal say for all (including Scrum Masters), how anonymity empowers everyone and leads to collaborative problem-solving.
[07:05] - How setup systems for topic submissions can keep your team from forgetting important issues. [07:36] - Make your retrospectives diverse: different perspectives bring fresh ideas.
[08:32] - This is your chance to be creative and invent your own themes to activate your team's brain in a different way.
[09:42] - Fun takeaway! Brian shares his one-of-a-kind idea for a unique retrospective theme you can use with your team.
[11:49] - Pop culture, the flavor of the day, or non-traditional, Brian shares some more ideas to liven up your retrospective.
[12:33] - Or try something completely different: discuss industry trends, company uniqueness, and personal highlights to connect to the bigger picture and deepen team connections.
[13:39] - How unleashing the human connection can lead to stronger bonds and better teamwork.
[15:40] - Why you should experiment with new ways to revive your retrospectives.
[16:48] - New guest episodes are coming up in August! Do you have an Agile subject you'd like us to discuss or a question that needs an answer? Share your thoughts with us here.
[16:51] - A message from our sponsor: Better User Stories, a one-day live online training course with Mike Cohn to improve your user story writing, so your team can do its best work, faster.
[17:22] - New guest episodes are coming up in August! Do you have an Agile subject you'd like us to discuss or a question that needs an answer? Share your thoughts with us here.

References and resources mentioned in the show:

Scrum Guides
Mountain Goat Software’s Better User Stories
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#57: Saying NO Without Losing Your Job

19 juli 2023 | 16 min

Join Brian Milner in another episode of the Agile Mentors Podcast series on unlocking the secrets of a sustainable pace. Today he’s delving into the power of "No" in Agile. Tune in to discover the truth behind feature usage, prioritize value-driven choices, and tips for mastering the art of saying no without losing your job.

Overview

Today on the Agile Mentors Podcast, Brian Milner sheds light on the power of saying "No" in Agile organizations.

"No" is an integral part of a healthy Agile organization. Learn how prioritizing value-driven choices empowers success in delivering the highest value to customers every time. Listen in as Brian shares valuable insights on establishing shared desired outcomes to ensure alignment and effective decision-making within teams and organizations.

Tune in for practical tips on mastering the art of saying "No" with confidence, navigating challenging conversations, and preserving relationships and job security along the way.

Listen Now to Discover:

[00:53] - In this episode of our summer series on practicing sustainable pace, Brian Milner talks about how important it is to say no, without losing your job.
[01:40] - Challenging the 64% Myth: Unveiling the Truth Behind Feature Usage (famous Standish Group study on feature utilization and Mike Cohn’s research).
[2:15] - The 2019 Feature Adoption Report | Pendo.io White Papers and The Surprising Power of Online Experiments.
[02:49] - Slack's monetization woes - unveiling the reality: 70% of features fail to deliver.
[03:13] - Product development philosophy: switching course to design features people care about.
[04:49] - Unlocking Agile's Key Principle: Product owners must practice saying NO daily in the mirror.
[06:34] - Saying no to unlock actual value - selective deliveries for maximum impact and prioritizing quality over quantity in our deliverables.
[07:17] - Saying no isn't always easy.
[07:32] - Tips for navigating the art of saying no while preserving relationships and job security.
[08:50] - How establishing shared desired outcomes in Agile ensures alignment and effective decision-making and fosters collaboration and value to customers.
[10:11] - For product owners: how prioritizing value-driven choices ensures success for both the product and the organization.
[12:56] - How developers can foster understanding and acknowledge their role while exploring how choices will impact the team and process.
[13:39] - A strategic dialogue on overtime requests' downstream effects and impact.
[14:54] - NO should be a regular occurrence in a healthy agile organization.
[15:08] - A message from our sponsor: Better User Stories, a one-day live online training course with Mike Cohn to improve your user story writing, so your team can do its best work, faster.

References and resources mentioned in the show:

Standish Group
Are 64% of Features Really Rarely or Never Used?
#25: Scaling with Henrik Kniberg
Product Ownership in a Nutshell
Manifesto for Agile Software Development
Mountain Goat Software’s Better User Stories
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#56: The Power of Experimentation

12 juli 2023 | 15 min

In this week's episode of the Agile Mentors Podcast, Brian Milner dives deep into the importance of experimentation in Agile organizations. Tune in to learn valuable tips for Scrum Masters, Product Owners, and Developers to embrace an experimental mindset.

Overview

Experimentation is at the heart of Agile's DNA, fueling innovation and continuous improvement.

Today on the Agile Mentors Podcast, Brian Milner explores the fundamental role of experimentation in Agile organizations.

"Agile is a framework that allows teams to find the best ways of working together, and this can only be achieved through continuous experimentation." Brian offers his tips for Scrum Masters, Product Owners, and Developers to embrace experimentation in their respective roles.

Experimentation is a cultural value. Listen in to gain insights into the power of experimentation to unlock the full potential of Agile within your organization.

Summer is a great time to explore new approaches and experiment with Agile practices. Join Brian as he shares practical tips and real-world examples to help you embrace an experimental mindset on your Agile journey.

Listen Now to Discover:

[00:53] - This is the second of our special July episodes where we're taking a break from interviews and focusing on some quick tips you can use.
[01:21] - Today, we're diving into the topic of experimentation.
[02:53] - What Google says about experimentation
[03:46] - What is Empiricism, and what does it have to do with Agile?
[04:09] - Unlike traditional product development, Agile operates on a research and development paradigm focused on experimentation and inventing new solutions rather than mass production.
[04:35] - Experimentation is really at the heart of what we do in Agile.
[05:03] - Experimentation is a cultural value.
[06:10] - Wipe the word failure out of your vocabulary.
[06:42] - Experiments can go either way, and that's okay. It's just the facts.
[07:09] - Three tips for Scrum Masters to embrace experimentation.
[10:04] - Three tips for Product Owners to embrace experimentation.
[11:44] - How Developers can embrace experimentation.
[14:03] - Finding the right balance for your team.

References and resources mentioned in the show:

Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#55: What is a Sustainable Pace?

5 juli 2023 | 16 min

In this episode of the Agile Mentors Podcast, Brian takes listeners on a discovery of what sustainable pace is, what it isn’t, and how embracing a culture that is pro work-life balance can lead to not only enhanced well-being for your team members but also help them be more productive.

Overview

Today on the Agile Mentors Podcast, Brian Milner is walking listeners through the hidden drawbacks of pushing teams to their limits in a fast-paced work environment and the benefits for work and employee well-being of maintaining a sustainable pace.

Brian takes a look at the resurgence of the "crack the whip" mentality and the impact of prioritizing excessive work hours over sustainable practices.

Listen in for Brian's tips for creating a culture that embraces sustainability and work-life balance and the transformative impact it can have on individuals, teams, and organizations alike.

Listen Now to Discover:

[00:53] - Join us in July for quick shorter episodes and valuable insights designed to enhance your Agile journey. We'll be back with full episodes in August!
[02:11] - Diving into the topic of sustainable pace: uncover the drawbacks of pushing teams too hard in a fast-paced work environment and why sustainable pace is essential for productivity and employee well-being.
[03:49] - The resurgence of the "crack the whip" mentality and its impact on employee morale and quality of work.
[4:33] -The philosophy of hardcore work, including a specific example involving Elon Musk and the importance of finding a sustainable work-life balance.
[6:04] - Discover the impact of stress on software development through a study by Tsuneo Furuyama to learn how long-term stress factors contribute to 71% of software faults.
[7:25] - Pushing people to work nights and weekends has a negative effect on the quality of work.
[7:43] - The origin of the concept of sustainable pace in XP and the importance of maintaining a sustainable pace for long-term success.
[8:57] - The true meaning of sustainable pace: how to embrace the balance between productivity and personal well-being.
[10:14] - The negative consequences of rushing and time pressure in software development.
[10:49] - How pushing teams beyond their sustainable pace actually results in more errors, bugs, and delays.
[11:14] - A sustainable pace leads to faster and more efficient releases in the long run.
[11:53] - There really is something to work-life balance.
[12:13] - Brian shares three tips to promote a sustainable pace.
[12:56] - A downstream effect of having high stress in your life.
[14:14] - What a sustainable pace is all about.
[15:31] - Coming up on next week’s show.

References and resources mentioned in the show:

Tsuneo Furuyama Study
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#54: Unlocking Agile's Power in the World of Data Science with Lance Dacy

28 juni 2023 | 44 min

In this episode of Agile Mentors, Brian sits down with Lance Dacy to discuss integrating Agile and Scrum practices into the world of data science.

Overview

In this episode of the "Agile Mentors" podcast, Brian sits down with Lance Dacy to discuss integrating Agile and Scrum practices in the world of data science.

Tune in to gain insight into the importance of feedback, the stages of the SAS Enterprise Miner initiative, and how frameworks like OSEMN can enhance the data science process.

Listen in to learn how to strike the right balance between technical knowledge and product ownership and why culture is crucial in successful Agile implementation within the data science domain.

Listen Now to Discover:

[01:16] - Brian introduces his guest Lance Dacy, referring to him as "our San Diego Zoo guy" and the topic of today's show using Agile or Scrum practices in a data science world.
[02:27] - Lance shares his background in data science and how it fits into the world of Agile.
[05:06] - The big reason so many people are against using Agile for data science and where the big rub is.
[09:02] - Who cares if it’s Agile or not? Lance shares Jeff Salts's poll about data science and introduces CRISP-DM.
[11:05] - The six steps of the cross-industry standard process for data mining.
[14:18] - Adopting a Scrum-like approach and treating data science work as smaller phases makes it possible to classify and organize tasks effectively.
[15:59] - Does anyone remember the Rational Unified Process?
[17:57] - It’s up to you to come up with ideas—once you have them, here's how we get it done.
[18:18] - In the world of data science, implementing frameworks like Scrum can lead to misconceptions and failures—the key lies in understanding the layers of data science, navigating the complexities of the work effectively, and making informed decisions.
[23:06] - The vital importance of feedback.
[23:45] - The stages of the SAS Enterprise Miner initiative.
[27:25] Brian introduces the sponsor for the podcast, Mountain Goat Software, and their two-day Certified ScrumMaster Course that’s perfect for anyone who wants to understand Scrum and add value to any team.
[28:23] - How the product owner fits in when discussing working with big data.
[29:50] Lance introduces the OSEMN process and explains how to solve a problem like a data scientist.
[30:47] - When it comes to the role of a product owner, the technical knowledge required depends on the nature of the product.
[31:42] - While Scrum lacks explicit guidance on backlog construction, the OSEMN framework themes (obtain, scrub, explore, model, interpret) can be incorporated to align sprint goals with specific aspects of the data science process.
[33:47] - The framework or the structure of how you carry it out is less important than the kind of agreement.
[35:07] - It's a cultural rather than a process problem. Lance delves into the debate on applying Agile Scrum to research.
[36:37] - A fundamental misunderstanding about daily scrums.
[37:18] - None of us are smarter than all of us together. Agile and Scrum work well when you know how to solve the problem, and there's a relatively clear path to victory.
[38:49] - Brian shares his biggest piece of advice to people considering this in the data science
[39:28] - “Data science is just the work that we're trying to do, tailor your process for your team and your culture and always inspect and adapt to try to make it better.”
[41:08] - If you have feedback for the show or topics for future episodes, email us by clicking here (if you have yet to get a response, send another one as something has gone wrong in the process). And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode. And if you are a data scientist or work in big data and found the information in this valuable, let one of your co-workers know about it.

References and resources mentioned in the show:

Data Science Process Alliance
CRISP-DM
OSEMN
Scrum and Data Science
Agile Mentors Blog Topic: Decision Science - What methodology fits best?
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 on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#53: Agile Coaching: Debunking Myths and Unlocking Excellence with Lucy O'Keefe

21 juni 2023 | 32 min

Unveiling the truth behind Agile coaching! Brian sits down with Lucy O'Keefe to debunk the misconceptions, share the keys to effective coaching, and share their insight on the one-two punch of training and coaching for sustainable success.

Overview

In this episode of the "Agile Mentors" podcast, Brian sits down with Lucy O'Keefe to debunk the misconceptions and unveil the true role of Agile coaches.

They share their personal stories and revelations and explore the pros and cons of moving from Scrum Master to Agile coach.

They'll walk listeners through the transformative power of external perspectives, navigating conflicts, and the collaborative mindset that fosters meaningful change. Plus, hear Lucy's invaluable advice on finding mentors and embarking on the journey to becoming a certified Team Coach.

Listen Now to Discover:

[01:10] - Brian welcomes CTC Agile Coach & Trainer Lucy O'Keefe, to the show for today’s discussion on the true role (and the common misconceptions about) of an Agile coach
[02:17] - Lucy shares her initial misconception about agile coaches and how it shaped her perception of their role.
[03:02] - Brian relates his experience with the term "Agile Coach" and his revelation when delving into the subject.
[04:16] - Lucy and Brian reflect on their transitions from exceptional Scrum Masters to agile coaching roles.
[05:53] - The pros, cons, and trade-offs of transitioning from a Scrum Master to an Agile coach.
[06:32] - The shift in focus that comes with Agile coaching and what to consider to determine if this change aligns with your preferences and career aspirations.
[07:12] - There's nothing wrong with being a kick *** Scrum Master. The world needs lots more like you.
[07:51] -How your role as a coach involves assisting your team and organization in their pursuit of progress (or debunking the myth of perfection in Agile).
[08:11] - An Agile coach is NOT merely an elevated Scrum Master.
[08:33] - The two opposing misconceptions about Agile coaching and the multifaceted aspects of coaching by Bob Galen.
[09:20] - Lucy emphasizes the importance of wearing multiple hats and the diverse skills required as an Agile coach.
[10:26] -Avoid the “Ferris Bueller's Day Off” scenario and ensure effective communication.
[11:16] - Learn to read the signs and strike the right balance to avoid frustrating situations and empower meaningful progress.
[11:54] - Professional coaching requires a willingness to engage deeply and tackle tough issues.
[13:38] - Knowing where to step in and when it's time not to step in.
[14:07] - Brian introduces the sponsor for this podcast episode, Mountain Goat Software, and their exceptional Scrum certification classes that go beyond a traditional online whiteboard for a fun and effective way to achieve learning objectives.
[14:52] - Effectively communicating the value proposition of having a team or enterprise coach.
[15:41] - The dynamics of internal and external coaches within organizations. And the transformative impact that external coaches can have on an organization’s ability to address impediments effectively.
[16:58] - Lucy shares how to approach coaching with a collaborative mindset, helping organizations see the value of change rather than imposing it and the questions. Agile coaches conduct assessments to uncover hidden issues to guide organizations to the areas for improvement.
[19:18] - Resistance to change often stems from fear of the unknown rather than change itself.
[19:57] - The most important thing to understand to help organizations reach the outcome they want and make the changes they need to make to get there.
[20:15] - Brian draws a parallel between the value of a coach and that of a therapist and how an outside viewpoint proves highly beneficial in understanding and addressing systemic issues within teams.
[21:29] - Asking the right questions to resolve the underlying issues through Agile coaching.
[22:42] - What coaches can and can't help with—knowing your limits as a coach and the lines NOT to cross to keep your coaching journey on track.
[23:40] -Don't settle for just training; go for the one-two punch of training and coaching—the winning combination that propels sustainable change.
[25:48] -Why would you need to take a class? Even Bob Galen realizes he always needs to grow and learn in what he’s doing to avoid becoming irrelevant.
[26:37] - Act with curiosity, but not curiosity for our own sake.
[27:30] - Lucy offers her advice for people who want to become a Certified Team Coach (CTC).
[29:02] - How to find the mentors that will offer you the most growth.
[29:55] If you have feedback for the show or topics for future episodes, email us by clicking here (if you have yet to get a response, send another one as something has gone wrong in the process). And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode.
[30:49] - Remember that Brian and Mike will speak at this year's Agile 2023 Conference in Orlando in July.

References and resources mentioned in the show:

#42: The Importance of Self-Mastery with Bob Galen
Agile2023!
Certified Scrum Master Training and Scrum Certification
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the "Agile Mentors" Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Lucy O'Keefe has over 28 years of IT experience and has worn multiple hats in the Agile world - developer, Product Owner, and Scrum Master and now, as a Teaching Assistant, where she leverages her diverse background to ensure students have an exceptional training experience.

#52: The Birth of Agile: How 17 Adventurous Techies Changed the World with Jim Highsmith

14 juni 2023 | 33 min

Join Brian and Agile pioneer Jim Highsmith as they dive into the riveting saga of 17 tech rebels who defied convention, unleashed their passions, and revolutionized the world of software development.

Overview

In this episode of the "Agile Mentors" podcast, Brian sits down with Agile pioneer Jim Highsmith to share how 17 tech rebels reshaped the software landscape.

Jim shares captivating stories from his time working with NASA and Nike to the collaboration of 17 nonconformists that led to the Agile Manifesto and transformed the software industry.

Listen in for a behind-the-scenes look at the circumstances that led to the birth of Agile and how camaraderie, collaboration, and a human-centric approach sparked a wildfire of support for the Agile movement. Tune in to this episode for insights, lessons, and a glimpse into the future of Agile from an industry legend.

Listen Now to Discover:

[01:10] - Brian introduces Jim Highsmith, a renowned figure in the Agile community. Jim is an experienced software developer, writer, and storyteller. His latest book, "Wild West to Agile," has become a sensation in the industry, earning the top spot as a new release on Amazon. He also co-authored the Agile Manifesto and the Declaration of Interdependence for Project Leaders, co-founded the Agile Alliance, and served as the first president of the Agile Leadership Network.
[03:57] - Jim recounts his journey working on the NASA Apollo program and how the constant advancements in technology shaped the course of the Apollo project, offering valuable insights into the era's challenges and adaptability.
[08:47] - Jim shares a fascinating story from his time at Nike, where outdated requirements left a project stagnant for 18 months.
[10:34] - How waterfall methodologies left companies trapped and projects taking too long and costing too much.
[11:53] - Setting the stage for the revolutionary Agile movement.
[13:16] - A problem so painful leadership was on board to find a solution.
[14:48] - A message from our sponsor: Mountain Goat Software has courses from Certified Scrum Master Training and Scrum Certification to Certified Scrum Product Owner Training that equips you with the sought-after skills valued by top-notch teams. Visit the Mountain Goat website for all the details.
[15:40] -Jim reveals the connections and common ground that started the manifesto meeting.
[18:21] - An agenda-free meeting with 17 nonconformist experts seeking common ground and how an encounter with Steve Mellor led to an unexpected alignment of intent.
[21:01] - 17 individuals, each with nonconformist perspectives, agree.
[21:17] - Why did 17 audacious techies revolutionize the world? And what lessons can we learn from their experience for the future?
[23:39] - Where Agile's lasting impact lies and what keeps it at the forefront of change.
[24:39] - Putting aside competition for collaboration and cooperation that led to change.
[25:30] - What keeps Agile at the forefront of change? Brian shares a nugget of wisdom from Jim's book about Agilists.
[26:38] - Finally, a language that spoke to us all!—how the Agile movement shattered the notion of interchangeable cogs and embraced our humanity, sparking a wildfire of support.
[27:59] - Jim shares his thoughts on where he thinks the Agile movement is headed and why he thinks the agility of organizations and people will be a definite advantage in the future.
[29:56] - Brian mentions his high recommendation for listeners to pick up Jim’s book, Wild West to Agile: Adventures in Software Development Evolution and Revolution.
[31:38] - There are a ton of podcasts out there; thank you for taking the time to listen to this one. And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode.
[32:05] - If you've considered taking a CSM or CSPO class, check us out at Mountain Goat Software. Or join the conversation in our Agile Mentors Community.
[32:32] - If you have feedback for the show or topics for future episodes, email us by clicking here, and I'll get back to you ASAP.

References and resources mentioned in the show:

Jim Highsmith
Jim Highsmith on LinkedIn
Wild West to Agile Agile Manifesto
Agile Alliance Agile Leadership Network
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified ScrumMaster®
Advanced Certified Scrum Product Owner®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the "Agile Mentors" Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Jim Highsmith is an experienced software developer, writer, storyteller, and industry pioneer recognized for his instrumental role in the birth of the Agile movement. His latest book, "Wild West to Agile," has become a sensation in the industry, earning the top spot as a new release on Amazon. Jim continues to inspire and guide Agile enthusiasts worldwide through his insightful stories and expertise.

#51: The Secrets of Team Safety with Julie Chickering

7 juni 2023 | 34 min

Gain insights into building cohesive and agile teams that bleed into each other and explore how conflicts can be transformed into opportunities for growth and improvement when Brian and his guest Julie Chickering delve into how to create team safety.

Overview:

In this episode of the "Agile Mentors" podcast, Brian sits down with Julie Chickering to explore the topic of team safety. They dive deep into the concept of psychological safety and its impact on team dynamics and productivity. From navigating conflicts and encouraging participation to embracing multiple perspectives and detaching personal worth from ideas, Brian and Julie provide valuable insights and actionable advice for Scrum Masters and team members alike. Join them as they uncover the secrets to creating a cohesive and psychologically safe environment where teams thrive and excel.

Listen Now to Discover:

[01:12] - Brian welcomes Julie Chickering back to the show. Teams need to feel safe and agile to be successful; that's a foundational aspect of a team. So, we're talking about team safety today.
[02:12] - Julie shares how one Manhattan bartender described her team that works well together; she says it feels like "we bleed into each other."
[04:11] - Sometimes people misuse or abuse the safe space, having each other's back as a license to be rude.
[04:57] - From pointing fingers to fixing problems together.
[05:39] - Julie shares a book called "The Culture Playbook" by Daniel Coyle and a quote on distinguishing between relational conflict and task conflict.
[06:38] - Protecting team dynamics: Learn how to navigate conflicts that escalate into personal territory and regain focus on improvement.
[07:37] - Effective strategies to steer discussions back to areas of agreement and keep the focus on facts.
[08:09] - Embracing multiple perspectives: Explore scenarios where opposing ideas are equally feasible and the importance of making a choice and moving forward.
[08:51] - Sometimes safety is misconstrued and used to stop discussions.
[09:17] - How to encourage participation based on comfort levels and through smaller group sharing.
[10:00] - The true meaning of safety.
[10:54] - Tension-free environments don't always lead to productive cultures: why disagreements are vital for meaningful discussions.
[11:33] - Detaching personal worth from ideas so you can focus on finding the best solution (vital as the Scrum Master).
[12:42] - How to facilitate conversations by focusing on facts and using visual aids to encourage objectively analyzing multiple ideas.
[13:00] - Nurturing sensitive team members: strategies to create a sense of safety for individuals who are more susceptible to critique to ensure them of the value of their contributions.
[14:13] - Why you should avoid labeling opinions as “wrong” and how assuming positive intent fosters a sense of safety.
[14:45] - The challenge of assuming positive intent (especially in written communication).
[15:21] - How to empower team members to define operating agreements that foster a sense of safety and a respectful working environment.
[17:23] - This podcast is sponsored by Mountain Goat Software's Certified Scrum classes, including Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), Advanced Certified Scrum Master (ACSM), and Advanced Certified Scrum Product Owner (ACSPO). Mike Cohn taught his first Scrum classes in 1997, and since then, more than 24K people have chosen to train with Mountain Goat Software. All certified classes include a twelve-month Agile Mentors Community membership.
[18:08] - How to open communication lines when unintentional offenses occur during interactions.
[18:49] - Scrum, though a simple framework, becomes complex when people's dynamics come into play.
[19:22] - Brian shares that achieving psychological safety requires a cultural shift and agreement among team members to express opinions freely.
[20:54] - Julie shares why psychological safety matters.
[22:09] - When the swirl of uncertainty and lack of safety is removed, teams can accomplish more due to increased productivity and effectiveness.
[22:34] - Brian shares some tips for Scrum Masters to make psychological safety a focal point if it is lacking within their teams.
[23:40] - Julie discusses the importance of understanding and supporting team members beyond Scrum practices and offers advice on ensuring everyone on the team is heard.
[25:15] - The secret to team cohesion: how sharing coffee preferences can build a sense of safety and collaboration within your team.
[25:51] - Julie explores the challenge of fostering a sense of team and safety at the corporate level and why starting at the team level is the key to cultivating a culture of trust and psychological safety, even in the face of external obstacles.
[27:31] - Julie delves into why teams work in a particular way and how aligning work practices with the desired outcomes can positively impact results.
[28:04] - How fostering psychological safety improves human interactions and drives better products, higher quality, and faster delivery.
[28:51] - How to address safety concerns with higher-ups.
[29:53] - The dangers of dismantling high-performing teams prematurely: the importance of nurturing team cohesion and the pitfalls of overlooking this critical aspect.
[30:42] - Brian shares how protecting the team sometimes involves making tough decisions and advocating for a better fit for both the individual and the team.
[32:06] - Julie’s parting advice encourages teams to assess their current state, ask critical questions, and collaboratively work towards creating a more cohesive and psychologically safe environment.
[33:06] - If you have feedback for the show or topics for future episodes, email us by clicking here. And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode.
[33:46] - Look for a different type of show coming to you during our July "break."

References and resources mentioned in the show:

The Culture Playbook: 60 Highly Effective Actions to Help Your Group Succeed
Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified ScrumMaster®
Advanced Certified Scrum Product Owner®
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#50: Choosing Your Path: Exploring the Roles of Scrum Master and Product Owner with Lance Dacy

31 maj 2023 | 35 min

Join Brian and his guest Lance Dacy as they explore the key differences, skill sets required, and the exciting opportunities in the roles of Scrum Master and Product Owner.

Overview

In this episode of the "Agile Mentors" podcast, Brian sits down with Lance Dacy to explore the dynamic roles of Scrum Master and Product Owner. They delve into the fundamental differences between these roles, highlighting the unique skill sets required for each.

Lance shares his valuable insights and personal experiences, shedding light on the challenges and opportunities that arise in these pivotal positions.

Whether you're considering a career in Agile or seeking to enhance your understanding of Scrum, listen in to this episode for practical advice and guidance for aspiring Scrum Masters and Product Owners and a deeper understanding of the crucial roles they play in driving successful projects and maximizing team productivity.

Listen Now to Discover:

[01:17] - Brian Milner has Lance Dacy on the show today to talk about a question emailed to the listener email address about the two different approaches to Scrum and which class would be a good fit for you, a Certified Scrum Master (CSM) or a Certified Scrum Product Owner (CSPO).
[02:28] - Lance shares how he looks at the two different designations and what he looks at as the centerpiece of the process of Scrum.
[03:24] - Things to consider when deciding whether the CSM or the CSPO is right for you.
[04:34] - Where to start your Scrum journey as a beginner and when taking both the CSM and the Certified Scrum Product Owner (CSPO) classes might be beneficial.
[05:28] - You don't have to be a Scrum Master to benefit from the CSM class.
[05:54] - The dual focus of the Product Owner roles and the diminishment of Scrum roles.
[06:45] - The challenge of combining these roles effectively.
[07:54] - The goal is to be agile rather than just doing Scrum-Lance shares the importance of delivering value efficiently and early. Relegating the Scrum Master to facilitation and metrics tasks yields minimal ROI.
[08:28] - Do you ever see the coach playing the game?
[09:10] - Scrum is a tool - you have to know the tools, how to apply them, and, more importantly, how to use them for the appropriate case.
[10:16] - The distinction between programmers (those who code) and developers (anyone working to produce the product) and a look back at the developer role in Scrum.
[11:34] - What confuses most people about the different classes and roles.
[12:28] - The importance (and top challenges teams face) of capacity planning, Sprint planning, and daily work management in Scrum teams. Lance shares why addressing these aspects is valuable for software and product teams, including marketing and infrastructure teams.
[13:44] - The value of certifications as a standard and an advantage in certain situations, but it's like learning to drive - experience is crucial.
[15:42] - The importance of learning the values, principles, and tools associated with Agile methodologies to engage in experimentation and gain practical experience, whether a CSM, CSPO, or CSV.
[16:25] - How active involvement in user groups and communities (such as the DFW Scrum user group) provides valuable insights and career benefits, fostering collective knowledge sharing and continuous learning in Scrum (and beyond).
[17:23] - Mountain Goat Software, the sponsor for this podcast, offers certified LIVE online Scrum classes, including Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), Advanced Certified Scrum Master (ACSM) and Advanced Certified Scrum Product Owner (ACSPO) classes. Book more than three weeks in advance for an early bird discount of $100.
[18:38] - Lance shares the three characteristics of a great product owner.
[19:28] - Advice for what you should do if you’re starting from scratch and aiming to become a product owner to gain exposure and valuable experience in the field.
[21:28] - The likelihood of moving from Scrum Master to product owner rather than vice versa.
[22:47] - The four requirements of becoming a Scrum Master requires strong facilitation, teaching, mentoring, and coaching skills, and the demands of being a product owner that makes it a higher barrier for entry.
[23:52] - The focus of a Scrum Master vs. a product owner.
[24:48] - It's like being the Zamboni for a hockey team—as a Scrum Master, you have the opportunity to work in diverse industries, ranging from space science and astrophysics to finance and software development, without being an expert in those domains.
[26:34] - A safer environment for experimentation and growth without the high stakes of individual accountability.
[26:58] - Brian shares the primary determining factor in deciding between product owner or Scrum master.
[27:51] - In the movie-making industry, like in software teams, there are distinct roles and responsibilities. You can choose to define the problem, manage the process, or contribute to building the product—pick your door and start running (and if you don't like it, you can always switch).
[29:06] Real knowledge comes from doing, BUT a class can get you started on the right foot to understanding how to do things and getting your hands dirty to cement further what you want to do.
[30:26] - Lance shares how obtaining a CSM or CSPO certification is like earning a black belt in karate—it's a pathway that empowers you to explore.
[33:24] - Still on the fence? Send us a note, and we'll gladly help you find your path.
[33:40] - Check out the Mountain Goat's training schedule to attend a class with Lance or Brian.
[34:01] - Exciting news! We have introduced an Agile Professional Directory to our Agile Mentors community. As a member, you can now sign up and claim your certifications, allowing you to showcase your expertise when interacting with others on the site.
[34:35] - Don’t forget, Mountain Goat Software offers a range of classes, including Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), Advanced Certified Scrum Master (ACSM), and Advanced Certified Scrum Product Owner (ACSPO). We love having podcast listeners join our classes to explore further the topics discussed on the show (click here to subscribe).

References and resources mentioned in the show:

Certified Scrum Master Training and Scrum Certification
Certified Scrum Product Owner Training
Advanced Certified ScrumMaster®
Advanced Certified Scrum Product Owner®
#4: The Developer Role in Scrum with Sherman Gomberg
DFW Scrum (Dallas, TX) | Meetup
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#48: Holistic Agile Testing with Lisa Crispin and Janet Gregory

17 maj 2023 | 41 min

Join Brian and his guests, Janet Gregory, and Lisa Crispin, as they share their expertise on integrating testing into Agile teams. Discover how to bridge the gap between programmers and testers for collaboration and success.

Overview

In this episode of the "Agile Mentors," Brian Milner sits down with Janet Gregory and Lisa Crispin, founders of Agile Testing Fellowship, to discuss integrating testing into Agile teams.

They discuss the history of the divide between programmers and testers and the importance of collaboration and communication between the two groups.

Listen in as they explore the different levels of holistic testing, the mindset shift needed for bug prevention, and the tools and strategies for planning and estimating testing activities. Plus, the role of AI in testing.

Listen Now to Discover:

[00:05] - Brian Milner introduces the guests for this episode, Janet Gregory and Lisa Crispin, who are advocates for integrating testing into Agile teams and the Founders of Agile Testing Fellowship.
[02:25] - Lisa explains the most important goal for collaboration and success.
[03:34] - Janet talks about the history of the gulf between programmers and testers.
[05:09] - How to bridge the gap between programmers and testers and the value of collaboration.
[07:29] - What the values of Agile and Extreme Programming emphasize.
[09:49] - The mindset shift needed for bug prevention.
[11:17] - Managers behaving badly—Brian shares a story about how measuring the wrong things can drive the wrong behaviors.
[12:13] Brian discusses the micro view of testing instead of a system view.
[12:17] How to handle intense forms of testing that take a long time to complete.
[14:02] Janet explains the different levels of testing and that teams should determine where testing belongs based on when it can be performed earliest.
[15:23] Avoiding a "hardening sprint."
[16:48] Lisa shares how to use visual models like the agile testing quadrants and the holistic testing model to help plan and communicate the testing activities needed throughout the software development lifecycle.
[17:25] The website where you can find the training written by Lisa and Janet, including “More Agile Testing” and “Agile Testing Condensed” (recently released), and where you can download the FREE Mini-book "Holistic Testing: Weave Quality into your Product."
[18:29] - Brian introduces the sponsor for the podcast, Mountain Goat Software. If you are thinking about getting certified as a Scrum Master, check out the resources and training options where certification classes are available every week.
[19:26] - The key to fitting testing into a normal sprint cycle and integrating testing with other system pieces.
[20:52] - Janet shares a tip for ensuring testing is not overlooked.
[20:59] - Lisa shares how to remind teams to do testing at the right time.
[22:31] - Why have a visible reminder for testing?
[23:54] - The importance of accounting for testing and not treating it as a separate thing to do.
[24:37] - Lisa shares her experience using planning poker for estimation and her preference to get every story the same size so they can be completed in a day or two.
[25:50] - Janet suggests sizing stories and estimating tasks, why she estimates her tasks herself, and what she’s learned in that process.
[26:44] -How to reduce the time needed in estimation meetings: Lisa shares some insight to identify when a story is too big and needs to be split up.
[27:35] - The importance of conversation and understanding to avoid creating a wall between programmers and testers during estimation.
[28:03] - Another tool in the toolbox: how Chat GPT will revolutionize testing (and who it might replace).
[29:01] - There will never be enough time to do all the testing required.
[29:31] - Lisa highlights how AI as a tool saves time with testing and allows more time for critical thinking skills.
[30:12] - The need for a human presence in the use of AI.
[31:19] - Janet shares information about her and Lisa's two courses, Basic Strategies for Agile Teams and Holistic Testing for Continuous Delivery, based on the Holistic testing model of looking at testing activities throughout the software development lifecycle. These courses can be found here.
[36:37] Lisa mentions that her book, “Assessing Agile Quality Practices” helps teams identify where they are and where they can improve, using a framework that looks at ten different quality aspects. Plus, information on the book they are working on now on how to facilitate an assessment.
[39:03] - Brian provides a list of resources available from Lisa and Janet, including their books “Agile Testing Condensed: A Brief Introduction” “Agile Testing,” “More Agile Testing,” and Assessing Agile Quality Practices and their "Holistic Testing: Weave Quality into Your Product” free download.
[40:14] - Join the Agile Mentors Community to continue the discussion. If you have topics for future episodes, email us by clicking here. And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode.

References and resources mentioned in the show:

Agile Testing Fellowship
Agile Testing - The Book
Agile Testing Condensed: A Brief Introduction
More Agile Testing
Holistic Testing: Weave Quality into Your Product
Assessing Agile Quality Practices
Mountain Good Software's Advanced Certified Product Owner course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Lisa Crispin is the Co-founder of the Agile Testing Fellowship, an author, and an Agile tester and coach, who helps practitioners deliver quality software frequently and sustainably.

Janet Gregory is the Co-founder of the Agile Testing Fellowship, an author, and a consultant, specializing in building quality systems and helping companies promote agile quality processes.

#47: Exploring Lean Thinking in Agile Development with Bob Payne

10 maj 2023 | 37 min

Join Brian and his guest Bob Payne as they discuss the principles of lean thinking and how they apply to Agile methodologies.

Overview

In this episode of the “Agile Mentors” Podcast, Brian sits down with Bob Payne to discuss the intersection of Agile and lean thinking. As an experienced Agile coach and host of the “Agile Toolkit Podcast,” Bob shares his insights and offers practical tips for implementing lean thinking in your own team.

Listen in as they explore the fundamental principles of lean thinking in Agile methodologies. They discuss managing flow, not workers, and the importance of continuous improvement and experimentation to achieve sustainable, high-quality results in your organization and success in today's fast-paced business environment.

Listen Now to Discover:

[01:23] - Brian welcomes Bob Payne, the Senior Vice President of Training and Coaching at Lithespeed, as well as the host of the “Agile Toolkit Podcast” and the Chairman of the Agile DC Conference. Bob is here to discuss lean systems and lean thinking.
[03:57] - Bob explains how lean thinking is connected to Agile methods in knowledge work.
[07:30] - Agile methods generate value through teamwork that ultimately ends up in the customer's hands, and lean thinking is the larger circle that encompasses these methods.
[08:24] - Lean thinking involves discipline and continuous improvement, which are essential characteristics for any successful team.
[10:30] - Lean thinking also considers the sustainability of the workforce—workers are seen as producing value, while management is there to create the system that makes them the most effective.
[11:31] - Lean thinking provides inspiration for visual management systems (such as Kanban boards) to track work which is incredibly powerful (and were not invented by Agile methods).
[11:47] - Lean didn't just appear out of thin air; it built off of multiple things.
[12:17] - Lean principles are foundational, and empiricism is built into lean.
[14:34] - Bob shares that visualizing work is crucial to managing it effectively and citing the example of Toyota's electronic boards.
[15:52] - Managing the flow of work, not the workers. We aim for cross-functional, self-organizing teams in an Agile team to get the job done.
[17:05] - Bob shares an analogy about the workflow in a coffee shop.
[17:41] - Bob shares the lean thinking philosophy and discusses the use of on-demand planning and continuous improvement.
[19:14] - Brian introduces the sponsor for the podcast, Mountain Goat Software, which offers various training options for Agile methodologies. You can find their training schedule here.
[19:46] - The difference between fixing the system and fixing the people in terms of leadership— Brian highlights the importance of a holistic view of the organizational structure to support the work and the workers in lean thinking.
[20:36] - Brian shares the importance of limiting work in process within Scrum. He shares his experiences with XP teams and emphasizes the need to identify blockages and fix the source, not (just) the symptom.
[23:03] - Bob and Brian discuss how Agile methods often miss local optimization, focusing on fixing bottlenecks instead of making other parts of the process more efficient.
[25:23] - Bob shares how the focus on DevOps and better tooling has enabled Agile teams to go faster while maintaining safety (and avoiding burnout).
[26:30] - Bob shares a talk called "Project to Product: Practical Realities at Large Scale Enterprises,” Kevin Fisher gave at a DevOps conference about an end-to-end value stream analysis.
[27:40] - Bob discusses the need for a shift towards prioritizing rapid building and getting products to market, as Jeff Patton and Marty Cagan advocate.
[28:37] - Bottlenecks? What the Scrum Master should focus on.
[29:27] -Understanding the theory and philosophy behind Agile rather than just focusing on the practices is important. Brian shares why he believes it's crucial to recognize that the system needs to be fixed, not the worker.
[30:49] - Understanding the theory and philosophy behind Agile methodologies rather than just focusing on the practices for more successful teams is essential.
[31:18] - Bob talks about how teams should experiment with different ways of doing things and shares the early Agilists were making stuff up and pulling together ideas that worked. He spends the first hour and a half of his classes talking about the history and mindset of Agile and lays out these principles with case studies.
[35:24] - Check out Bob Payne’s work on his podcast, “Agile Toolkit Podcast,” and at Lithespeed.
[36:08] - Join the Agile Mentors Community to continue the discussion. If you have topics for future episodes, email us by clicking here. And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode.

References and resources mentioned in the show:

Lithespeed
"Agile Toolkit Podcast”
Agile DC Conference
Project to Product: Practical Realities at Large Scale Enterprises
Mountain Goat Software's Advanced Certified Product Owner course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Bob Payne is an industry-leading Lean+Agile Transformation leader with over 20 years of experience. He is the SVP of Enterprise Transformation at Lithespeed, the host of the “Agile Toolkit Podcast," and the Chair of the Agile DC Conference. With a wealth of practical experience, Bob has been a trusted advisor to executives, teams, and management at leading firms such as Walmart, National Geographic, and Samsung.

#46: How to Assess Company Culture Before Accepting a Job Offer with Christina Ambers

3 maj 2023 | 35 min

Join Brian and guest Christina Ambers on this episode of the "Agile Mentors" podcast as they discuss the importance of asking the right questions during a job interview to determine if a company (and its culture) is a good fit for you.

Overview

In this episode of the Agile Mentors podcast, Brian sits down with Christina Ambers to discuss the most important questions to ask during a job interview for an Agile role and the yellow and red flags to look out for.

Listen in as Christina shares her insights on which questions to ask in order to probe deeper and better understand the company's values and culture to assess whether the role is a good fit for you as a candidate.

Whether you're a job seeker or a hiring manager, this episode offers valuable insights into ensuring a good match between the company and the candidate.

Listen Now to Discover:

[01:13] - Brian welcomes Christina Ambers to the Agile Mentors podcast. Christina is an Agile Enthusiast, Enterprise Coach, Speaker, and owner of SMART ACE Formula. She’s also an active member of the Agile Mentors Community. Today we're discussing the topic of interview questions and why it's essential to ask questions during an interview.
[02:31] - Christina explains how asking questions during an interview allows the candidate to interview the company to see if it's a good fit for you.
[02:48] - Brian shares that having questions prepared shows a level of preparedness and readiness for the interview to determine if the company is the right fit for you, especially in today's job market with increased layoffs.
[03:54] - How asking the right questions can save you from frustration and a dead-end career
[05:01] - Christina shares a good starting point for asking questions that will help you determine what it's like to work at a company and help you get a sense of their culture.
[05:35] - Brian shares a tip on weeding out vague answers about culture and offers a warning of what to look for as an indicator that the culture isn't great.
[07:04] - Christina adds that if the interviewer relates culture to food or other benefits, it’s another warning sign that culture might not be taken seriously in the organization.
[07:58] - Christina suggests that these red flags could also be opportunities to improve the company culture if it's an area you excel in, offering a chance to make a positive impact and provide you with some job security.
[8:37] - Brian suggests asking a question that puts the interviewer at ease and helps them focus on the company's culture and offers an example
[09:09] - Christina shares her favorite question to ask in an interview, sharing that this question helps her understand what the interviewer expects out of your role.
[09:44] - Christina shares that if an organization's culture isn't conducive to improvement, that could be a red flag.
[10:36] - More than just a warm body—why it's essential to clarify what is expected of your role BEFORE you take the job.
[11:09] - How to avoid being the “new Dave.”
[11:46] - Christina shares how asking questions about the outcomes and responsibilities of the role can help a candidate identify any hidden or unexpected aspects of the position that were not included in the job description.
[12:30] - Asking the right questions to avoid misunderstandings (and wasted time and effort)— Brian shares his experience of being misled during the interview process by a company that claimed to be interested in agile methodology.
[13:50] - How flipping the question can help clarify what outcomes they expect from the role, especially when talking to the team, to understand how to be successful in the position.
[14:28] - Christina talks about clarifying whether the role is a replacement or a new role and how the company values the role.
[15:04] - Christina shares her concern about the company's expectations being too high, especially for a new role. She suggests asking whether the company is ready for the change and how much they value the new position.
[15:41] - Brian adds that asking how the team's performance is measured is essential. He recommends understanding what the company is trying to accomplish with the team.
[16:49] - Christina shares some yellow flags that provide room to grow and an opportunity for coaching.
[18:08] - Brian recommends asking how the company invests in employee growth to determine how they value individuals versus teams.
[18:40] - Brian shares the sponsor for today’s episode, Mountain Goat Software's Certified Scrum Product Owner Training which teaches how to use the product backlog as a tool for project success.
[19:17] - Christina talks about inquiring about how the company connects developers to actual customers.
[20:36] - A passion for continuing education: Christina recommends asking about how the company values additional learning experiences and how they reward individuals versus teams for continuing education.
[23:56] - Avoiding potential red flags.
[24:46] - Christina suggests asking about the company's changes since COVID-19 to find out how they respond to significant disruption and delving into employee longevity.
[25:58] - Brian emphasizes the importance of asking questions during the interview process to determine how Agile a company is right now and how they actually care for their employees vs. just what they can deliver.
[27:44] - The value of talking to other employees in the company.
[28:32] - How to determine how a company views work/life balance (and their flexibility for work from home).
[29:35] - Probing a company's attitude towards offshore or outsourced employees in relation to their in-office employees before starting to work for them.
[30:18] - Success isn't measured by simply sitting at a desk and typing—watching out for red flags indicating the company hasn't figured out what success means to its customers.
[31:05] - Determining the Agile framework of your future team.
[32:15] - What does Scrum mean to you—there might be more than one answer—how to find out and what follow-up questions to ask.
[32:50] - Connect with Christina in the Agile Mentors Community or check out SMART ACE Formula.
[33:39] - Join the Agile Mentors Community community to continue the discussion. If you have topics for future episodes, email us by clicking here. And don’t forget to Subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode.

References and resources mentioned in the show:

SMART ACE Formula
Mountain Good Software's Certified Product Owner course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Christina Ambers is a certified Scrum Master, Agile, and Kanban Coach with over 16 years of experience in software development and transformations. She is passionate about unlocking agile potential, inspiring teams to succeed, and applies agility and lean concepts in her everyday life. Christina is a founding member of the SMART ACE Formula and has worked with companies of all sizes and industries to help teams collaborate and work more effectively.

#45: Overcoming the Challenges of Agile in Regulatory Environments with Scott Dunn

26 april 2023 | 32 min

Join Brian and guest Scott Dunn as they share practical tips on navigating the challenges and achieving success in implementing Agile practices in regulatory environments on this episode of the "Agile Mentors" podcast.

Overview:

In this episode of the Agile Mentors podcast, Brian and Scott Dunn delve into the challenges of implementing Agile practices in regulatory environments. They discuss the importance of finding ways to work within regulatory frameworks, building trust with stakeholders, and adapting Agile principles to fit the unique needs of the organization. Listen in to discover practical strategies for navigating regulatory hurdles, effective communication with regulators and customers, and building a culture of continuous improvement in highly regulated industries.

Listen Now to Discover:

[01:30] - Brian welcomes Scott Dunn to the Agile Mentors podcast. Scott is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience. Today's show is focused on the listener-inspired topic of implementing Agile in regulatory environments. (If you want to hear something specific, you can email us at [email protected]).
[02:31] - Change is hard. Sometimes you must dig deeper into the reasons for resistance, as it may not always be related to regulatory requirements.
[03:09] - Scott shares his experience working in a compliance-heavy environment, noting that the people responsible for compliance may not always fully understand the regulations.
[04:16] - Scott emphasizes the importance of researching the regulations independently. In his experience, mindset and willingness are key factors in successfully implementing Agile in regulatory environments.
[06:05] - Brian shares an anecdote about a pushback he received in a private class about whether Agile principles would work in the real world.
[07:59] - Scott shares a recent experience on a call with a Prime contractor for the government, where they discussed the government's modernization efforts and their shift towards agile methodologies. He also mentions the GSA's internal agile group, which requires funding recipients to adopt agile practices.
[09:19] - The issue of government contracts requiring specific roles rather than generalists and how this can limit the implementation of agile practices.
[10:20] - Scott discusses how contracts in government organizations can limit the ability to fully implement Agile principles and how to create change within their organizations.
[11:33] - Brian discusses the idea that a transformation is an ongoing process and not something that can be checked off as completed. He talks about the importance of continual learning.
[12:01] - Brian introduces the podcast sponsor, Mountain Good Software's Advanced Certified Product Owner course. He explains how the course can help product owners increase their confidence, credibility, and value.
[12:39] - The importance of collaboration over contract negotiation: Brian shares a story about Michael Sahota, who worked with the Canadian government on a bidding contract and revolutionized the government's fixed bid system.
[15:07] - Brian explains that while regulatory environments require more documentation, examining whether certain documentation is necessary is essential.
[15:54] - The need for empathy and understanding when working with regulatory environments.
[16:26] - Small nudges = Significant change.
[19:45] - The challenge of testing in regulatory environments, particularly regarding validation. Brian shares a story about a client with FAA regulations and how they tackled the issue, emphasizing the importance of collaboration.
[23:20] - Scott suggests a pragmatic approach to achieving work goals, acknowledging the external constraints that may prevent perfection.
[24:09] - Scott further explains that in some cases, there may be a sliding scale of achieving different levels of agility. Even small incremental steps towards agile implementation can provide benefits.
[25:37] - Brian shares what he considers the #1 win in implementing Agile into these types of environments.
[26:57] - What's possible? If you fast forward a year from now, what could be done now that gets us to the next step?
[28:10] - Think about how you are showing up: the importance of facilitating idea-generating conversations and the type of leadership it takes to start those conversations and helps make the right thing happen.
[29:30] - Scott and Brian discuss the quote, "if you're the smartest person in the room, you're in the wrong room," and how important it is to be around people who can push you and help you grow.
[30:52] - Join the Agile Mentors Community community to continue the discussion. If you have topics for future episodes, email us at [email protected].

References and resources mentioned in the show:

Mountain Goat Software's Advanced Certified Product Owner course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Agile Manifesto
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

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.

#44: Transformations Take People with Anu Smalley

19 april 2023 | 33 min

In this episode of the “Agile Mentors” podcast, Brian and Anu Smalley share their perspectives on the relationship between culture and Agile transformation and why people are key.

Overview

Coaching an Agile transformation requires more than just knowing how to run a daily Scrum. Finding the right people for the job is critical to success.

In this episode of the "Agile Mentors" podcast, Brian and Anu Smalley chat about the importance of diversity in Agile teams.

Listen in as Brian and Anu explore how culture impacts an organization's ability to adopt Agile practices, the role of leaders in creating an inclusive culture, and the power of sharing stories in building a strong community.

Listen Now to Discover:

[01:17] - Brian introduces us to the guest, Anu Smalley, who has a lot of experience in Agile coaching and consulting. She’s also been instrumental in increasing diversity in the Agile community. She has a CST mentoring group for people who don't have the same background as the majority of people in the Scrum Alliance. Her company is Capala Consulting Group.
[03:34] - Metrics and methodologies are important in organizational transformation, but people are at the heart of it. Organizations cannot successfully transform without the right people.
[04:02] - Anu talks about how the Agile Manifesto emphasizes individuals and interactions as the key to success in transformation. She emphasizes the importance of having the right people in an organization to ensure a successful transformation.
[05:07] - Coaching an Agile transformation requires more than just knowing how to run a daily Scrum. Finding the right people for the job is critical to success.
[05:55] - Brian notes that some businesses see their employees as replaceable parts in a machine. A diversity of perspectives is essential; having only one perspective limits the team's potential.
[06:52] - Each person is unique and cannot be replaced like a part in a machine. Anu stresses the importance of recognizing the human aspect of transformation to succeed and that metrics alone will not suffice.
[07:48] - Brian discusses the comparison between Agile software development and research and development. Having the right people for the job is critical. [08:30] - Agile transformation requires a focus on people and coaching, and the framework will fall into place once that focus is in place.
[09:14] - Anu highlights the importance of understanding what being Agile truly means rather than just knowing the techniques.
[09:59] - Brian notes that while many attendees may attend Agile training classes solely for certification, trainers can use this opportunity to teach attendees a deeper understanding of Agile and transform their approach to work.
[10:46] - Anu notes that there is a significant difference between implementing Scrum and transforming an organization—one can be learned in a two-day class, while the other requires a deeper understanding of what being Agile truly means.
[12:02] - Focusing on people is the key to success in Agile transformation; without it, organizations will not get very far.
[14:17] - Brian emphasizes the uniqueness of organizations and how Scrum is designed to be adjusted and custom fit for each group that uses it.
[14:49] - Anu highlights the importance of role clarity for individuals and teams to minimize conflicts.
[15:53] - The virtual world has made role clarity even more important. Anu shares an example of a client whose main focus for 2023 is to achieve role clarity amongst their teams, explaining what is essential to achieving this goal.
[16:19] - Clarity is achieved by bringing people together, resolving conflicts, and working towards common goals.
[16:19] - Anu emphasizes that coaching and resolving conflicts are key to achieving role clarity and smooth functioning among teams in an organization.
[16:37] - Brian compares learning the basics of baseball to attending a class on Scrum—a class can teach you the basics—a coach is necessary to grow and improve.
[17:50] - Anu shares that a coach is essential, even for the best sports people on the planet.
[16:19] - Anu emphasizes the importance of role clarity and resolving conflicts in an organization to ensure everyone understands their role and works together effectively.
[18:39] - Anu explains that the best players in any sport have personal coaches to keep them in the "being mode," focusing on the individual's growth to impact the company's growth.
[19:33] - Brian highlights that even the best athletes in the world have coaches, and we should always keep growing and never stand still.
[19:51] - Agile transformations are about the people we have—Anu reiterates the importance of focusing on individuals' growth to impact the company's growth.
[20:12] - Leaders need to ensure they have the right people and are continuously teaching, coaching, and helping them move forward.
[20:35] - Brian introduces the sponsor of the podcast, Mountain Goat Software's Certified ScrumMaster Class, and highlights its benefits for those interested in understanding Scrum.
[23:34] - Anu shares examples of clients who have decided to combine roles or accountabilities due to budget cuts and how it impacts the Agile journey.
[24:40] - Anu advises against continuing the Agile journey until it can be done properly.
[25:43] - Leaders often make the mistake of not understanding the importance of ScrumMasters, but ScrumMasters do, in fact, provide value (a little sarcasm here).
[26:00] - Without capable ScrumMasters, the transformation will stall or fail.
[26:39] - Brian notes that even with capable ScrumMasters, leaders must trust and empower them to drive the transformation forward.
[27:02] - Culture is all about people; if you don't have a culture supporting Agile transformation, it won't go anywhere.
[27:55] - Talking about trust issues between leadership and teams.
[28:55] - Anu explains that some leaders may have talented staff, but they are too scared to trust them with an Agile transformation because they are worried about the culture and power structure changes.
[29:35] - Brian suggests an innovation initiative, to which Anu sarcastically proposes an innovation sprint as a solution.
[29:47] - Brian encourages listeners to contact Anu through LinkedIn or through the website of her company, Capala Consulting Group.
[30:52] - Anu invites listeners to share their Agile transformation stories with her and promotes the importance of building a community through shared experiences.
[32:58] - The value of learning from different cultural perspectives.
[33:17] - Brian invites you to share your ideas for the show or feedback. Email Brian.

References and resources mentioned in the show:

Capala Consulting Group
Mountain Goat Software's Certified ScrumMaster Class
Mountain Goat Software Certified Scrum and Agile Training Schedule
Join the Agile Mentors Community
Agile Manifesto
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Anu Smalley is the President and Founder of Capala Consulting Group, where she specializes in Executive Coaching and Agile Transformations. She is a Certified Enterprise Coach and Certified Scrum Trainer®. She’s an active member of the larger Scrum and Agile community and enjoys giving back via volunteering at various conferences.

#43: Cultivating Agile Team Culture in a Virtual World with Richard Cheng

12 april 2023 | 35 min

In this episode of the Agile Mentors podcast, Brian and Richard Cheng discuss the challenges of working in a virtual environment, sharing insights and strategies for maintaining team collaboration and communication. Listen in for practical tips and expert advice on navigating the changing landscape of remote work.

Overview

In this episode of the "Agile Mentors" podcast, Brian and Richard Cheng discuss the challenges and opportunities of the ever-evolving world of remote work in Agile teams and the role of technology in supporting Agile practices.

Listen in as they share their insights on the tools to use, how to maintain team cohesion and collaboration, and the importance of culture and personal connections. You'll find practical tips and inspiring ideas to help you navigate the virtual landscape and thrive in the new normal of work.

Listen Now to Discover:

[01:14] - Brian introduces Richard Cheng, founder of Agility Prime Solutions, trainer, teaching CSM, product owner, and combat classes. He is also working on a graphic novel about the adventures of a scrum master. He's here today to discuss the challenges of working.‌
[04:16] - Richard highlights the significant shift towards virtual work that was already happening before the pandemic and the adoption of virtual work tools such as Zoom, Miro, and Slack, which made the transition easier during the pandemic.
[06:22] - Richard emphasizes the importance of using tools that foster better communication and collaboration rather than replacing them. The tools and policies around them should enable people to work better together rather than create more distance.
[07:08] - Richard is relatively agnostic regarding specific tools, but he mentions that he is a huge fan of Zoom for instruction and prefers Miro or Mural for collaboration.
[08:03] - Brian tends to use Mural but also acknowledges the benefits of Miro (and shares a fun fact about Miro).
[09:42] - Brian advises against letting the tool drive the collaboration process and instead focusing on conversations and collaboration first, then finding tools that enhance that process.
[11:00] - Richard agrees with the idea that tools should not drive the team's workflow, but rather the team should drive the tools using the example of Jira™. He advises teams to tailor their tools to support their evolving needs.
[12:46] - Brian acknowledges the importance of standardization in big enterprises and advises teams to refer to items in their terms to better align with their workflow.
[14:20] - Brian shares why tools that allow deep customization are enormously useful because you can implement a wealth of plugins.
[15:01] - The key to keeping it simple—strip it down to the bare bones and then grow it. Richard shares an example from the best Agile shop he ever worked at, The Motley Fool, and their tools, including Bugzilla.
[16:00] - Brian shares the sponsor for the podcast, Mountain Goat Software, and the team home software they use for their Agile and Scrum Training.
[18:39] - Richard discusses the virtual challenges of creating culture and teamwork, including communication, collaboration, and cross-functionality.
[19:15] - The new frontier for companies: experimenting with different methods is essential while adapting methods to make them more effective.
[20:46] - Richard discusses the issue with the Scrum guide's statement that Scrum is immutable, stating that once you're an expert, you should take what works and tweak what doesn't, drawing on an analogy about CrossFit, where workouts can be scaled up or down, and suggest that Scrum should be approached similarly.
[23:48] - Promoting conversation and collaboration between teams, which is a big issue for many teams in the virtual world. Brian points out that time zone differences can be a problem. People on the other side of the globe must experiment more with asynchronous tools to communicate and collaborate effectively.
[24:49] - Collaboration is less about geography and more about times. He promotes time zone friendliness to enable teams to collaborate more effectively and independently. Richard recommends setting up time zone-aligned value streams to improve product and service delivery speed, particularly for organizations with teams in multiple time zones.
[26:25] - Brian emphasizes the importance of maintaining company culture in a virtual environment. He recommends virtual show-and-tell sessions to build a deeper connection among team members.
[27:51] - Richard suggests that events such as game nights and virtual chocolate tastings can help bring teams and organizations closer together, even in a virtual environment. At the same time, optional in-person events for geographically connected teams can also be a good way to foster a sense of togetherness and culture.
[29:15] - To help improve communication and strengthen the team's dynamics, create user manuals for team members: that includes their background, contributions to the team, and
[30:37] - As a Scrum Master and Coach, being there and having osmotic communication was a big part of the job. Without it, we have to engineer everything, which can be challenging.
[31:30] - Brian acknowledges that technology is rapidly changing but emphasizes the importance of not letting the tool drive the conversation. Instead, he suggests promoting collaboration and enabling teams to work better through policies and practices that bring the team together and rethink those that separate them.
[32:56] - You can learn more about Richard and his classes at Agility Prime Solutions or email him at [email protected].
[34:24] -Join the Agile Mentors Community for further discussion, and if you have an idea for the show or feedback, we'd love to hear from you. Email Brian.

References and resources mentioned in the show:

Agility Prime Solutions
Mountain Goat Software Certified Scrum and Agile Training Schedule
Mural
Miro
Jira
Bugzilla
Private Virtual Chocolate Tastings– Bar & Cocoa
Join the Agile Mentors Community
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Richard Cheng is the founder of Agility Prime Solutions, which provides training programs that focus on Agile, Scrum, Kanban, and Product Management. Richard is a founder and was an executive committee member of the Agile Delivery for Agencies, Programs, and Teams (ADAPT), an Agile government task force.

#42: The Importance of Self-Mastery with Bob Galen

5 april 2023 | 35 min

Join Brian and Bob Galen, Agile Coach and author, as they explore the significance of self-mastery in leadership and coaching.

Overview

In this episode of the Agile Mentors podcast, Brian and Bob Galen, Agile Coach, author, and podcast host, discuss the importance of self-mastery for leaders and coaches.

Bob emphasizes the significance of self-reflection, journaling, and introspection as tools to mine valuable information from one's history in order to move forward successfully.

Listen in to understand the crucial role emotional intelligence and self-mastery play in leadership and coaching and how one can balance their needs with those of the team and organization.

Listen Now to discover:

[01:09] - Brian welcomes Bob Galen as a special guest on the podcast.
[01:30] - Brian and Bob discuss the concept of inside-out mastery for an agile coach.
[02:32] - Bob explains that the agile coaching growth wheel emphasizes self-mastery as a central aspect for coaches to consider.
[03:42] - Self-mastery is a mindset that emphasizes coaching from the inside-out. It includes coaching presence, listening skills, and self-care.
[05:00] - Bob emphasizes the importance of having a coach and active mentors to improve self-mastery and humility.
[07:40] - Bob discusses the importance of continuous improvement of agile coaches and leaders for self-mastery and shares his own journey.
[09:12] - Bob emphasizes the importance of becoming a "feedback sponge" and activating self-awareness as a critical part of self-mastery for agile coaches while activating assessments to understand how they are perceived.
[09:53] - Developing emotional intelligence—a critical aspect of self-mastery.
[10:03] - Brian compares the concept of self-awareness to a principle in acting called "intention versus action." He explains that understanding the intention behind someone's actions is important for interactions with others.
[11:21] - Bob describes the concept of "meta skills," or mindsets that guide how coaches should show up with clients.
[13:02] - Bob suggests that coaches should take 5 minutes before coaching conversations to "clean themselves up" and get rid of biases and baggage.
[14:48] - Brian shares his approach to coaching when he’s had a bad day.
[15:09] - Why it’s important to show vulnerability as a coach, even though it can be challenging and how that creates space for clients to do the same.
[16:50] - Bob emphasizes the importance of modeling and how it can be used to highlight certain behaviors or values.
[17:39] - Brian adds that self-awareness is crucial for effective modeling and coaching and shares an example where he dropped the ball on that and how he corrected his behavior.
[18:38] - The power of modeling in coaching and the importance of making a conscious choice to model positive behavior.
[19:18] - Brian shares the sponsor for the podcast, Better User Stories, a one-day live online training course with Mike Cohn to improve your user story writing, so your team can do its best work, faster.
[19:59] - Bob shares the importance of journaling for capturing observations and reflecting on experiences to improve future behavior and why he requires it in his leadership class.
[21:03] -The journal is like breadcrumbs, not just for the past, but the future.
[21:16] - Brian shares his own experience with journaling and why he considers it a crucial tool in coaching.
[23:48] - How wonderful it would be if leaders felt comfortable enough to model their vulnerability to their organizations.
[24:03] - Leadership sometimes feels like putting on a brave face and being a strong presence, but vulnerability can actually create more safety and change the ecosystem in a positive way.
[25:15] - Bob shares that showing humanity can be a real advantage in creating a resilient organization and shaping its culture.
[26:44] - Brian reflects on how his actions as a leader shaped the culture of the organization (even when actions went against traditional ideas of what a leader should do).
[27:35] - Bob shares an example of how journaling helped a young lady who was struggling with her job to go back and mine her history for valuable information.
[29:36] - Brian reflects on the importance of reflection and learning from past failures.
[30:02] - Bob brings home the concept of historical learning and self-mastery through journaling and reflection.
[30:28] - Check out Bob's podcast, “Meta-Cast.”
[34:09] -Join the Agile Mentors Community for further discussion, and if you have an idea for the show or feedback, we'd love to hear from you. Email Brian.

References and resources mentioned in the show:

Meta-Cast
Mountain Goat Software's Better User Stories
cORSC - CRR Global
The Agile Coaching Growth Wheel | Scrum Alliance
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Bob Galen is a renowned Agile coach, speaker, and author with over 30 years of experience in software development. He has authored books such as “Extraordinarily Badass Agile Coaching:The Journey From Beginning to Mastery and Beyond,” "Scrum Product Ownership - Balancing Value from the Inside Out" and "Three Pillars of Agile Quality and Testing.” He frequently speaks at Agile conferences and events, sharing his knowledge and experiences in Agile testing and coaching. You can listen to him on his podcast, Meta-Cast.

#41: Cultural Transformation in Organizations with Karim Harbott

29 mars 2023 | 36 min

Karim Harbott joins Brian to talk about the 5 levers of crafting a strong culture in an organization and the critical role of leaders in establishing it.

Overview

On this episode of the "Agile Mentors" podcast, Karim Harbott joins Brian to discuss the importance of crafting a strong culture in an organization through his 5 Levers for Changing Organizational Culture.

Listen in as they discuss the importance of aligning behaviors with the organization's strategy and the often-overlooked but critical role that leaders play in the cultural transformation of organizations.

Listen Now to Discover:

[01:34] - Brian introduces Karim Harbott, an Agile coach and CST, and highlights his book, “The 6 Enablers of Business Agility” He’s joining Brian to discuss culture change and the challenges associated with it.
[02:25] - Karim discusses where to begin to make cultural change.
[04:14] - Brian and Karim discuss the challenges of teaching culture and the importance of modeling desired behaviors.
[04:47] - Karim explains that behaviors are a key factor in shaping culture and shares that there are five levers for changing the culture of an organization. The first lever is the organization's structure, which can encourage collaboration or silos and is the first thing within your control to influence behavior and how people collaborate.
[07:15] - Karim emphasizes the importance of examining the system in place using the analogy of a gardener to explain that leaders need to create an environment that fosters the growth of the desired culture and behaviors.
[07:51] - Brian references a quote by Craig Larman highlighting that whatever you're seeing at the moment, your system is designed to output that—for a different output, you gotta change the system.
[08:21] - Karim explains that Craig Larman's and Deming's quote that "every system is perfectly designed for the results it's getting" both emphasize the importance of the structure in determining culture.
[08:47] - Karin shares the second lever for changing culture, which is that the policies and rules that leaders create can be used to control or influence behaviors.
[10:37] - Brian references the "Don't be evil" structure at Google and what it entailed.
[11:37] - Karin discusses the importance of weaving high-level values into every part of how the organization operates, even the low-level aspects of the organization, to truly influence behaviors.
[12:15] - Karin talks about the third lever of culture change, which is metrics and targets, and notes that what you measure and set as targets speaks volumes about what leadership values in the organization.
[14:18] - Measuring intangible things like respect and integrity can be difficult, but it is important to find a way to measure them even though they don’t fit neatly into a dashboard.
[15:51] - Brian shares an interesting paradigm they use at Mountain Goat Software, where they set goals with both a visual and emotional aspect to help them determine when they’ve reached their goal.
[16:56] - Karim discusses the importance of HR processes as a lever (Lever #4) for influencing and reinforcing behaviors in an organization.
[18:27] - Brian shares the sponsor for the podcast, Better User Stories, a one-day live online training course with Mike Cohn to improve your user story writing, so your team can do its best work, faster.
[19:12] Brian emphasizes the concept that the company is a team effort, not an individual sport.
[20:21] Karim highlights the difference between Henry Ford's production line and a team-based environment using the analogy of chopping onions in the kitchen but being asked to make a tiramisu.
[21:30] - If the culture incentivizes individuals to prioritize their own interests over the interests of the team, then there is a problem, and conflicting incentives will lead to failure.
[22:21] - Incentivizing individualism over teamwork will lead to failure (and unhappiness among 70% of employees).
[23:39] - Karim discusses the fifth lever, which he considers to be the most powerful: leadership behaviors.
[26:20] - Actions speak louder than words: Brian speaks about the importance of leadership behavior in promoting a healthy work culture with the example of unlimited vacation policies.
[28:23] - Karim talks about the importance of behavioral norms in an organization, citing descriptive and injunctive norms as examples. By using the example of a library, he illustrates how people tend to conform to social norms.
[30:39] - Karim shares the two things that are necessary to strengthen a culture; without these, a culture cannot be strong (it's important for leaders to be hypersensitive to this).
[31:47] - The disapproval of others can be a powerful tool to make sure people behave the way we want them to behave.
[32:47] - Brian shares how the TV show Brain Games demonstrated social norms and people conforming to the crowd.
[33:43] - Karim emphasizes the importance of crafting a strong culture as one of the most important things a leader can do and calls for it to be a core leadership capability.
[35:46] - Do you have an idea for the show or feedback you'd like to share? We'd love to hear from you. Email Brian.

References and resources mentioned in the show:

Mountain Goat Software's B etter User Stories
The 6 Enablers of Business Agility: How to Thrive in an Uncertain World
The 6 Enablers of Business Agility
5 Levers for Changing Organisational Culture
Lead and Disrupt
Larman's Laws of Organizational Behavior
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Karim Harbott is a leadership and business agility expert, entrepreneur, author, and international keynote speaker with over a decade of experience helping organizations with business agility. Karim is one of only a few people globally to hold the Certified Agile Leadership (CAL) Educator, Certified Scrum Trainer® (CST), and Certified Enterprise Coach® (CEC) status.

#40: Is it Time to Go Out on Your Own? Tips and Insights with Chris Li

22 mars 2023 | 38 min

Chris Li joins Brian to talk about making informed decisions about going out on your own and navigating the challenges of entrepreneurship.

Overview

On this episode of "Agile Mentors," Chris Li joins Brian to discuss the journey to becoming an entrepreneur. They dive into everything from the importance of having a clear vision and passion to weighing the benefits of partnerships and investors.

Listen in for valuable advice from Chris and Brian on sidestepping the fear of going alone and the crucial things to consider before taking the leap.

Listen Now to Discover:

[01:08] - Brian introduces Chris Li.
[03:13] - Chris discusses the importance of taking stock of your threshold for comfort before determining the next step, especially in the current climate.
[05:33] - Brian emphasizes the importance of passion in making decisions about the next steps and recognizing when you've reached the pinnacle of your current position so you can explore other opportunities that align with your passions.
[07:05] - Chris shares his journey, from knowing he had an entrepreneurial spirit to finding the right people to help him as he took the leap.
[08:51] - Brian highlights the importance of having a network of people to fall back on and the value of mentorship for personal and professional growth.
[09:29] - Chris notes that going out on your own looks different for everyone and why it's essential to find the path that works for you and shares an example of someone who took a different route to improve their career.
[11:35] - Chris breaks down external and internal factors that can help you determine if you're ready to go out on your own, including the most critical factor to consider.
[14:22] - Brian discusses healthcare as a significant factor.
[15:15] - Brian discusses the importance of risk tolerance and mapping out income streams and costs to ensure that going out on your own is financially viable.
[15:49] - Chris discusses the investment period at the beginning of a move and why having an end goal is essential.
[17:37] - Taking stock - what will you have to give up to have this other thing?
[18:47] - The importance of a support team to help walk you through ALL sides of the situation—good, bad, and neutral.
[21:13] - Brian talks about why developing a backup plan is essential.
[21:43] - Chris shares why getting legal advice is vital.
[23:23] - Brian emphasizes the importance of hustling when you are your own boss.
[24:05] - Chis encourages listeners not to be discouraged by the elements of the process. Starting a business can be a valuable experience (regardless of its outcome).
[25:17] - Brian encourages listeners to be realistic about their situation but not to let fear hold them back from pursuing their entrepreneurial dreams.
[26:18] - Chris advises listeners to consider all the angles of any new opportunities that may come up, being realistic about their potential value.
[29:21] - Brian emphasizes the importance of hustling, working extra hours as an entrepreneur, and considering your own work-life balance priorities.
[31:32] - Think about how you will spend your time AND your money: Chris shares some practical things to consider, like how you will spend your time AND your money, and partnerships and securing funding.
[35:49] - No matter your choice, you can always change course.
[35:56] - Do you have an idea for the show or feedback you'd like to share? We'd love to hear from you. Email Brian.

References and resources mentioned in the show:

Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Chris Li is the Founder of SparkPlug Agility and a dynamic and enthusiastic IT consultant with more than two decades of industry experience. He specializes in delivering exceptional learning opportunities and is passionate about delivering outstanding speaking engagements, mission-focused insights, and cultivating meaningful partnerships for individuals, teams, and organizations.

#39: The Art of Writing User Stories with Mike Cohn

15 mars 2023 | 29 min

Mike Cohn joins Brian to share his experience facilitating story-writing workshops and offers insights on creating effective user stories that deliver value to customers and focus to your team.

Overview

In this episode of the "Agile Mentors" podcast, Brian is joined by Agile coach and trainer Mike Cohn to discuss the art of writing user stories through story-writing workshops.

Mike shares his expertise on the importance of creating user stories, including how to write them effectively and their benefits in the development process.

Listen in as Mike provides valuable insights on conducting effective story-writing workshops, including the role of a skilled facilitator, keeping the conversation on track, and how using the INVEST criteria can help you create high-quality user stories that meet the needs of your users.

Tune in for practical tips and strategies to improve your user story writing workshops to energize your team while giving them a clear focus on what they need to do.

Listen Now to discover:

[01:09] - Brian is sitting down with Mike Cohn today to discuss story writing workshops.
[01:57] - Mike shares team/stakeholder writing sessions during the early 2000s that morphed into "story writing workshops" to help teams understand what they were doing.
[03:37] - Mike explains why he prefers to write 20-30 stories at the start of a quarter, only writing a few new stories during the sprint, then doing another story writing workshop every three months.
[05:20] - Brian clarifies that teams don't have to wait for a story writing workshop to write stories. He shares his recommendations for holding story-writing workshops once a quarter to replenish the backlog and "refill the gas tank" with new ideas.
[06:03] - Mike expands on the gas tank analogy, explaining that, like filling up a gas tank, teams don't need to wait until the backlog is empty to have a story-writing workshop.
[06:52] - Mike shares why he prefers a quarterly approach to story writing for its big-picture view of the coming months.
[07:17] - Brian references the 2020 Scrum Guide and suggests using the product goal as the bigger idea to zero in on.
[07:32] - Mike agrees with Brian's suggestion of using the product goal as a focal point during story-writing workshops sharing his idea of the importance of something to aim for beyond just the single sprint goal.
[07:59] - The importance of focusing a story-writing workshop on a single goal, i.e., setting a product goal for three to six months and using it as the workshop's focus to generate necessary stories.
[09:29] - Who should attend a story-writing workshop? Mike offers his suggestions to bring creativity and new ideas and build better products.
[11:33] - Mike shares why he believes involving team members in story-writing workshops is a time-saving, worthwhile investment that will improve product outcomes.
[12:06] -The tools for a successful story-writing workshop for everyone involved.
[13:57] - Mike explains why story-writing workshops might work better online than in person.
[17:19] - To keep the conversation on track, having a skilled facilitator for your story-telling workshop is crucial.
[17:58] - The importance of having a scrum master or agile coach facilitating story mapping sessions for guidance through any issues with sequencing or organization of ideas.
[19:16] - Collectively writing the same story simultaneously vs. brainstorming different stories and then coming together—Mike shares which he prefers and why.
[21:34] - Mike shares why saving the story refinement for later is best.
[24:05] - The importance of striking a balance between the level of detail in the stories and the time spent on the story-writing workshop.
[25:21] - Brian shares a story about an organization he worked with recently at Mountain Goat Software that used the INVEST criteria as a definition of Done to check off every story they wrote.
[25:58] - Mike explains the six attributes a team should know to create good user stories.
[27:20] - Mike shares why story-writing meetings energize teams, leaving them excited about the product and the upcoming period while giving them a clear focus on what they need to do.

References and resources mentioned in the show:

How to Run a Successful User Story Writing Workshop
Better User Stories Video Course by Mike Cohn
2020 Scrum Guide
Join the Agile Mentors Community
Mountain Goat Software Certified Scrum and Agile Training Schedule
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Mike Cohn is the CEO of Mountain Goat Software and the Co-founder of Agile Alliance and Scrum Alliance. He’s passionate about agile and finds it rewarding when a company really understands agile, commits to doing it well, and succeeds dramatically. Mike’s focus is coaching, training, developing new courses, sharing ideas in his blog posts and tips, and participating in the Agile Mentors Community, especially with the live Q & A sessions.

#38: Using Agile for Social and Societal Transformation with Kubair Shirazee

8 mars 2023 | 39 min

Kubair Shirazee, Founder of Peace through Prosperity, joins Brian to share his experiences using Agile tools for social and societal transformation, helping to empower marginalized communities and break the cycle of poverty.

Overview

In this episode of the Agile Mentors podcast, we explore how Agile can be applied outside of software development as a powerful tool for driving societal transformation with Kubair Shirazee, the Founder of the Peace through Prosperity project.

Kubair takes us on his journey of using Agile methodologies to empower marginalized communities by supporting business owners in creating long-term solutions that are helping to break the cycle of poverty.

Listen in as he shares some of the challenges he has faced in implementing these methodologies and offers listeners detailed information on how to get involved in the Peace through Prosperity Scrum Masters Experience Academy and insight into ways you can make an impact in your community.

Listen Now to discover:

[01:07] - Brian introduces to UK-based Kubair Shirazee, Agility Coach through Agilitea and Founder of the Peace through Prosperity project that uses Agile to foster social and societal transformation.
[02:33] - Kubair discusses how Agile, which emphasizes people and relationships, can be applied to social and societal transformation.
[04:43] - Kubair explains how marginalized solopreneurs in conflict zones and developing countries can use Agile principles to maximize their potential.
[07:18] - The targeted way entrepreneurs with mobile businesses in marginalized communities use Agile to leverage what they've learned in the past to help them capitalize on future opportunities.
[08:42] - How Agile coaching and support helped a barber named Anwar to go from having a beat-up chair on the street to owning a salon.
[11:14] - Not just increased revenue—touching the lives of over 2400 marginalized micro-entrepreneurs in 12 short years.
[12:57] - Back to Anwar's story, how focusing on the pillars of empiricism and developing a product goal helped him shift his mindset and grow his business.
[16:27:] - We don't just hijack people's lives; it's all about creating relationships and collaborating with people to co-create solutions that work for them.
[20:21] - How finding out you have the power to write your own story is the first crucial step towards realizing your full potential and overcoming the challenges of marginalization.
[21:55] - Brian explains how Agile helps people manage challenging goals in any and every environment.
[22:55] -How Peace through Prosperity helps provide long-term, sustainable, and impactful solutions to help create an environment of financial stability.
[27:34] - Peace through Prosperity aims to empower marginalized communities to create a better future without resorting to extremism or outside help.
[28:42] - The exciting opportunity to get involved with Peace through Prosperity through the Scrum Masters Experience Academy and work with teams in Pakistan, Yemen, and Egypt to gain valuable Scrum experience in just six months.
[30:10] - Kubair shares how to become involved with the mission to meet the needs of marginalized communities in your own location (using Peace Through Prosperity's open-source programs).
[34:41] - How individuals like Dominique de Cooman, CEO of Dropsolid, are helping fund Peace Through Prosperity and how you can, too.
[36:39] - "Scrum is industry agnostic. Scrum is something if we if we all just embrace it, its principles, and its values. It can enrich not just our individual lives, but it can enrich us as an entire community on our pale blue dot."—Kubair Shirazee

References and resources mentioned in the show:

Peace through Prosperity
Agilitea
#32: Scrum in High School Sports with Cort Sharp
#23 How Agile Works in Education with John Miller
#21: Agile Marketing Teams with Stacey Ackerman
Mountain Goat Software Certified Scrum and Agile Training Schedule
Scrum Alliance
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Kubair Shirazee is a highly experienced Enterprise Agility Coach with over 20 years of experience helping people, teams, and businesses transform using his coaching skills. He has worked with a range of prominent brands in the pharmaceutical and non-profit sectors, including Novartis and Bayer, helping them to improve their product, service development, and operations. In addition to his coaching work, he is also the founder of the Peace through Prosperity project, which leverages Agile methodologies to promote social and societal transformation.

#37: Servant Leadership, Not Spineless Leadership with Brad Swanson

1 mars 2023 | 32 min

Brad Swanson joins Brian to explore the concept of servant leadership and share actionable takeaways to help you lead with compassion and empathy.

Overview

In this episode of the Agile Mentors podcast, Brad Swanson joins Brian to discuss the concept of servant leadership and how it can be applied in an Agile environment.

Learn how to create strong personal connections with your team members, the power of asking powerful questions to foster collaboration, and how to be more assertive as a leader while remaining flexible about the process.

Listen in as Brad shares three practical ways that listeners can cultivate a servant leadership mindset and build a positive and productive work environment.

Listen Now to discover:

[01:48] - Brian introduces Brad Swanson, who has the trifecta of certifications with Scrum Alliance: CST, CEC, and CTC.
[02:54] - Brad shares his belief that servant leadership involves prioritizing the needs of the team while cultivating a culture of trust and collaboration.
[04:43] - Since the 1970s, the servant leadership concept introduced by Robert K. Greenleaf has involved empowering team members rather than seeing them as subordinates.
[07:48] - Brian shares his experience playing football and how it relates to management styles, highlighting that a calm and empowering approach can be more impactful than an authoritative one.
[09:55] - Brad shares the idea that effective leadership involves the ability to balance and leverage multiple power styles and shares the book "Leadership Agility" by Bill Joiner and Steven Josephs, which emphasizes the importance of situational leadership.
[13:30] - Brad shares his perspective on the shift in the last version of the Scrum Guide from using the term "servant leadership" to "true leadership" and why he prefers the term situational leadership.
[15:05] - Brian acknowledges that people have a natural predisposition towards being either assertive or accommodating and how stepping outside of one's comfort zone can lead to both personal growth and an expansion of your skill set.
[16:05:] - Brad suggests there is a difference between being assertive and directive.
[19:38:] - The effectiveness of asking powerful questions to invite collaboration and reach a mutual goal.
[20:17] - The key to being more assertive as a leader without attacking the individual (and remaining flexible about the process).
[21:55] - Brad shares three ways listeners can implement a servant leadership mentality.
[23:35] - Brian shares how to use a notebook to process your thoughts and ideas while giving others a chance to speak up.
[24:38] - Brad shares why listening is a skill that requires frequent practice.
[25:15] - Why it’s a good idea to keep your team in the loop about the changes you are trying to make in your leadership style.
[26:13] - Why being open and transparent about your efforts to improve can help create a learning environment where improvement is both expected and accepted.
[27:05] - Why creating strong personal relationships with the people you are leading is crucial to effective leadership and developing the team's skills.
[29:05] - Listeners of the Agile Mentor’s Podcast can get a 10% discount on the Certified Agile Leadership class Brad has coming up on March 27th by using promo code friend10. Find out more by visiting Agility 11.
[30:34] - Join the Agile Mentors Community to continue the discussion. You can get a free 12-month membership into the community by taking a class with Mountain Goat Software.

References and resources mentioned in the show:

What is Servant Leadership?
"Servant Leadership: A Journey into the Nature of Legitimate Power and Greatness"
"Leadership Agility"
Agility 11
Certified Agile Leadership - CAL Essentials & Organizations with Brad Beginning March 27, 2023 - Promo Code: friend10
Mountain Goat Software Certified Scrum and Agile Training Schedule
Scrum Alliance
Join the Agile Mentors Community
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Brad Swanson, Founder and Principal Coach and Trainer at Agility 11 helps organizations achieve sustainable success through Lean and Agile principles. With extensive experience as a trusted advisor to executives and organizations worldwide, Brad holds certifications as a Leadership Agility 360 Coach, Agile Leadership Educator, Scrum Trainer, Enterprise Coach, Professional in Agile Coaching, and LeSS Practitioner.

#36: Working with Humans with Dallas Jackson

22 februari 2023 | 39 min

Dallas Jackson joins Brian to explore the human aspect of work and the challenges that come with prioritizing the team while ensuring everyone is heard.

Overview

In this episode of the Agile Mentors podcast, Dallas Jackson joins Brian to delve into the human side of work and why it's essential to create work that fits people's lives rather than forcing humans to fit the work.

They delve into the importance of understanding and appropriately responding to conflict in the workplace as a Scrum Master and prioritizing the team while ensuring everyone is heard.

Listen in as they explore the challenges of adapting to change, why prioritizing human factors is essential for driving cultural shifts, and how to create an Agile culture that supports the human element of work.

Listen Now to discover:

[01:13] - Brian introduces Dallas Jackson, a native Texan, living in New Zealand who is a Teaching Assistant with Mountain Goat Software and certified team coach with Scrum Alliance.
[03:18] - Dallas highlights the importance of recognizing individuals as human beings and creating work that fits their lives rather than forcing humans to fit into work.
[05:17] - Brian shares the value of remote work to allow individuals to gain insight into each other's personal lives and encourages virtual show-and-tell sessions to foster stronger team bonds.
[06:43] - Connecting to foster deeper relationships as a team.
[07:42] - Dallas shares how showing her humanity helped her build a connection with colleagues, leading to a development of trust and a better quality of teamwork.
[10:41] - Why it's important as a leader to prioritize taking care of employees.
[12:21] - Dallas shares why creating a positive environment where people feel cared for and supported is crucial for producing good work.
[15:22] -The importance of building connections in team relationships through reciprocity and sharing personal stories, even those unrelated to work.
[16:39] - How opening ourselves up allows us to give the best to our fellow humans because we're ALL members of the same tribe—the human race.
[18:06:] - Brian shares the importance of understanding and appropriately responding to conflict in the workplace, including avoidance.
[21:08] - What about conflict—Dallas shares the importance of playing the long game and how not to handle it as a Scrum Master.
[23:39] - How using crucial conversations helps everyone stick with the facts and avoid misunderstandings caused by differing perspectives.
[24:43] - Brian shares the mantra he uses with teams to move beyond personal conflicts and focus on finding solutions.
[26:08] - Acknowledging that facts are the foundation, but feelings in the workplace matter too.
[27:17] - Dallas explains the significance of goldfish memory in conflict management, completing the stress cycle, and prioritizing the team while ensuring everyone is heard.
[28:07] - Brian shares why the Scrum Master's job is similar to that of a football coach in that you need to be clued into the emotional temperature of your team.
[30:32] - You can't process your way to a better culture—cultural shifts change when we take humans into account.
[31:38] - Agile is a philosophy that requires a shift in thinking about work and a departure from following step-by-step instructions and can be a difficult transition for organizations to make.
[32:39] - Dallas shares a football vs. rugby analogy about how to help managers make a mindset shift.
[34:53] - Brian shares that working with humans requires a different approach than working with machines because repeatability isn't always possible—adaptation is the name of the game.
[36:26] - Dallas shares the Cherokee saying that we die a thousand deaths to become our true selves.
[37:54] - You can hear more from Dallas at Scrum Australia in March.

References and resources mentioned in the show:

Burnout: The Secret to Unlocking the Stress Cycle
Mountain Goat Software Certified Scrum and Agile Training Schedule
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Dallas Jackson is a Teaching Assistant at Mountain Goat Software with a multitude of Scrum and Agile qualifications, including CSM, CSPO, CAL-E.

#35: Metrics with Lance Dacy

15 februari 2023 | 34 min

Join Lance Dacy and Brian Milner as they discuss the use of metrics in an Agile environment to ensure optimal performance without taking things in the wrong direction.

Overview

In this episode of the Agile Mentors podcast, Lance Dacy joins Brian to delve into the intricacies of utilizing metrics in software development to ensure optimal performance while avoiding incentivizing adverse behaviors.

Listen in as he walks us through the three tiers of metrics that are crucial for Agile teams to consider in order to stay on course.

He’ll share the tools required to gain a holistic understanding of an individual's performance and how leadership styles and stakeholders influence team-level metrics.

Plus, a look at the common challenges that teams may encounter during their Agile adoption journey and how to overcome them.

Listen now to discover:

[01:18] - Lance Dacy is on the show to discuss metrics.
[02:09] - Brian asks, are there ‘good’ ways to track performance?
[02:32] - Lance shares why Agile doesn’t really lend itself to tracking performance.
[03:57] - How to handle performance reviews.
[04:32] - Lance shares the best way to measure individual performance.
[06:40] - Measuring team contribution vs. standalone rockstar.
[07:48] - What Ken Schwaber and Jeff Sutherland say about the completeness of the Scrum Framework and why having a superhero on your team is bad.
[09:45] - Lance shares the 3 tiers of metrics to measure when working as an Agile team to be sure their team is going in the right direction.
[11:09] - Using tangible business-level metrics such as time to market for products, NPS, and support call volume to evaluate performance.
[12:20] - How metrics, such as the number of work items completed per month, and cycle time, can be used to evaluate performance at a product level in an Agile environment.
[14:10] - Lance shares standard metrics such as velocity, backlog churn, and work-in-process that can be used to evaluate things at the team level.
[14:45] - Brian shares the importance of having a broader perspective to avoid having a distorted view of performance.
[16:53] - How using tools such as Ishikawa (fishbone) diagrams can help you identify the root cause of the problem instead of the apparent cause.
[17:22] - Individual velocity and other big metrics to avoid.
[19:02] - How the balanced scorecard can help managers use ALL the information available to develop a comprehensive understanding of an individual's performance.
[19:25] - The detrimental effects of using the wrong metrics to evaluate an individual's contribution.
[21:29] - Brian shares the story of how a manager's bug squashing endeavor led to incentivizing the wrong behavior
[22:31] - Lance references Stephen Denning's statement and reminds us that assumption testing is what developers do every day.
[24:00] - Referencing the State of Agile Report statistics on what's stalling your transformation to Agile.
[25:15] - Lance shares a behind-the-scenes look at how team-level metrics are affected by leadership styles and stakeholders.
[27:05] - Lance shares the spreadsheet he's been using to track data for a Scrum team for over 5 years to understand why the team is not predictable and what they can do to improve.
[31:38] - Got metrics management questions? Reach out to Lance.
[31:46] - Why it’s imperative that you think of software development as R&D rather than manufacturing to arrive at the right metrics measurements.
[33:26] Continue the conversation in The Agile Mentors Community.

References and resources mentioned in the show:

Additional metrics resources mentioned by Lance

Agile Metrics

Business outcomes, product group metrics, unit metrics)
- KPI/OKR (Business Outcomes)
- Time to market, NPS, Support Call Volume, Revenue, Active Account, New Customer Onboarding Time, Regulatory Violations)
Product Group Metrics
- Work items completed per unit of time (quarterly)
- % of work in active state vs. wait state
- Cycle time of work times (idea to done)
- Predictability (% of work items that reach ready when planned)
Unit metrics
- Velocity, backlog churn, work in process, team stability Metrics Spreadsheet

Team Size
- Tracking the size of our cross-functional team (typically Dev and QA), allows us to pair that number with velocity to play “what-if” scenarios in the future. Whether you count half of a person if shared, or whole, keeping it consistent throughout your tracking is what is important. Most teams simply count the number of developers and testers.
Team Days
- Tracking the iteration length is also helpful in understanding a team’s performance. If the team has a 2 week sprint, then usually that is 9 development days of actual work. The 10th day is set aside for sprint review, retrospective, and planning.
Committed
- Tracking what the team committed to completing within a sprint is crucial to understanding their predictability. The are the most uneducated at the beginning of the sprint and tracking what they think they can complete helps us in long term planning.
Completed
- Tracking what the team completed is actually just tracking velocity above, but comparing it what they committed helps us understand their predictability index.
Predictability Index (Pi)
- Software development is complex, risky, and uncertain. A skill that is sought after in this type of environment is predictability. The better we are at understanding what we can accomplish, then finishing what we said we would accomplish builds trust with our management team and customers. If we aren’t very good, tracking this metric often helps us get back to good by committing to less or more depending on our index.
- Example:
  - Completed Items / Committed Items = Predictability Index (Pi)
  - 25 Story Points / 20 Story Points = 125% 20 Story Points / 25 Story Points = 80%
  - Just because a team has a high Pi, does not mean they are good at predictability. Don’t let high and low numbers fool you, focus on the variance from 100% instead of the actual number. An arbitrary number to shoot for is +/- 15% Pi (85% or 115%).
Story Points / Per Day (SPD)
- Story points per day is just that, tracking how many story points per day of the sprint did we complete (Completed / Team Days).
Story Points / Per Day / Per Person (SP/PD/PP)
- This perhaps is the most useful metric to capture throughout the process. Most of our teams do not have the luxury of maintaining a consistent size or make-up. Inevitably over the course of a few months, the team make-up will change. Once the teams change, velocity has to be reset.
- In addition, we may actually change our sprint duration over a long period of time (don’t change it each sprint). Once we change sprint lengths, it can jeopardize our pure metrics, velocity has to be reset.
- However, over all of our teams in a product, if we can capture the SP/PD/PP that our teams complete on average, we can begin to play “what-if” scenarios in long- term planning.
  - Example:
    - Completed / (Team Size * Sprint Days)
    - 24 / (4 * 9) = 0.67
    - You can then average that number over 4-6 sprints or even the year.
Defects
- While we understand that we won’t ever likely have a zero defect product, it is useful to track how many defects our teams are creating over time. There are usually 2 types of defects, internal and external.
Internal
- Our definition of done should at minimum include that testing is taking place during the sprint with the idea that we would not allow a story to be called DONE if it had remaining defects. As such, an internal defect are the ones that were created while working on a backlog item in the sprint, that we have fixed before calling the item DONE.
External
- External defects are those that have “escaped” our development process and were not discovered during our testing. In a sense, our customer discovered the defect and the work item will become a new backlog item for a sprint.
Warranty
- We should strive to have the warranty concept built into our process. If you bought a car yesterday and the radio fell out, you could take it back and they would fix it fairly quickly. Our customers deserve the same service. Don’t manage a defect backlog, get used to fixing escaped defects immediately, while they are fresh on your mind (right after a sprint). It doesn’t take a long time to fix defects, it takes a long time to find them once identified by a customer.
Defects per Story Point
- Tracking defects per story point help to understand velocity a little better. If you have a team that has drastically increased its velocity, have the defects have increased along with it? Defects per story point help us understand the relationship between a velocity and defects created.

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? It would be great if you left a rating and a review. It really helps, and we read every single one.
Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Lance Dacy, known as Big Agile, is a dynamic, experienced management and technical professional with the proven ability to energize teams, plan with vision, and establish results in a fast-paced, customer-focused environment. He is a Certified Scrum Trainer® with the Scrum Alliance and has trained and coached many successful Scrum implementations from Fortune 20 companies to small start-ups since 2011. You can find out how to attend one of Lance’s classes with Mountain Goat Software here.

#34: I'm Trained, Now What? with Julie Chickering

8 februari 2023 | 33 min

Join Julie Chickering and Brian Milner as they provide exclusive insight on utilizing your Scrum training, expanding your expertise, and passing your knowledge on to others.

Overview

In this episode of the Agile Mentors podcast, Julie Chickering sits down with Brian to discuss getting started in the key Scrum roles.

They highlight the value of establishing relationships with like-minded individuals for both support and greater success. Plus, a look at some ways to use Scrum outside of the software development arena.

Listen in as they guide you through the initial steps you can take when you are just starting out on your Scrum journey and how collaboration and continuing education can aid your career growth and advancement.

Listen now to discover:

[02:26] - The framework is simple. Then we put people into the mix. Julie shares the most crucial aspect for those starting in key Scrum roles.
[04:04] - Brian shares Mike's foundational philosophy for approaching this work from Mike Cohn's popular conference keynote session, Let Go of Knowing.
[05:58] - How communities online like The Agile Mentors Community and local groups like DFW Scrum help members achieve more success.
[07:02] - How being part of a community was foundational to Brian's Scrum journey.
[8:33] - Julie shares her introduction to Scrum and how the connections and support she received from the community were crucial to her growth and advancement.
[09:42] - Brian shares his regrets about not getting involved with a community sooner.
[11:56] - Brian shares how mentoring is like dating and why taking the time to have the discussions needed to form the foundations for authentic relationships is vital.
[13:08] - Read the room. Julie offers guidance on avoiding mistakes while searching for a mentor.
[14:46] - How cross-pollination and venturing out to form connections in other industries helps you grow in your own.
[15:41] - Being part of a safe community can help you advance your skills while helping others.
[16:57] - Julie shares how to get started as a Scrum Master after you've been trained and the overall value of finding the right fit.
[18:50] - Successful product ownership requires two key components.
[19:16] - Where the rubber meets the road: expanding what you've learned in your training through real-world experience.
[20:45] - Start where you are: how applying your Scrum training to other areas beyond software development can help enhance your skills.
[22:55] - Brian and Julie share some examples of Scrum hidden in the non-software world, including in education and marketing.
[25:32] - How to use your skills to help a nonprofit in your area.
[27:11] - Brian explains how A-level classes can help you overcome hurdles as you advance in your career.
[28:53] - Learning never stops: the importance of obtaining knowledge for now and later. [29:10] - Julie shares the value of debriefing with someone else.
[30:31] - Problem-Solving Leadership (PSL)
[31:22] - What classes and tools have you used to advance your skills? We'd love to hear. Reach out to share your experience.

References and resources mentioned in the show

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? It would be great if you left a rating and a review. It really helps, and we read every single one.
Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected].

This episode’s presenters are:

Julie Chickering, the brains and brawn behind JC Agile Consulting, believes that Lean and Agile practices are packed with potential — to enable positive culture change, business agility, and breakthrough results. Julie is a past president and board member of the Agile Project Management Network (APLN), a Certified Scrum Trainer (CST), PMI Agile Certified Practitioner (PMI-ACP), as well as a traditional Project Management Professional (PMP).

#33 Mob Programming with Woody Zuill

1 februari 2023 | 40 min

Join Woody Zuill and Brian Milner as they discuss the benefits of teams working together through Mob Programming.

Overview

In this episode of the Agile Mentors podcast, Woody Zuill, a 40-year veteran software developer specializing in team interaction, joins Brian to explore the concept of Mob Programming.

Woody shares the benefits of working together rather than separating tasks in software development and how removing things like queuing, multitasking, and context switching can actually make teams more effective.

Listen in as he walks us through the collaborative software development approach's perks.

Listen now to discover:

[02:22] - Brian introduces Woody Zuill, a 40-year veteran software developer specializing in team interaction.
[02:51] - Woody explains how he discovered the term Mob Programming.
[04:56] - Where the idea of Teaming came from.
[06:20] - Woody explains why he's changing the name from mob programming to teaming.
[07:23] - Teaming = collaboration brought to software development, where more than one brain connects to do the work that needs to be done.
[11:11] - Painting the Mob Programming picture: it's when "all the brilliant minds work together on the same thing ‌in the same space, at the same computer."
[13:40] - To work efficiently in software development, one team member acts as the driver at the keyboard while everyone else acts as the navigator.
[16:41] - The drawbacks and disconnect of breaking software development down into smaller pieces.
[18:34] - Isn't six people in one room working on one computer a waste of resources?
[21:07] - Do you want to be productive or effective? Examining the Lean concept of flow.
[24:57] - Enhancing the effectiveness of software development by removing the negative impact of waiting, queuing, multitasking, and context switching.
[25:22] - The benefits of working together vs. separating tasks in software development.
[26:53] - Team Flow: how collaboration adds to our ability to work in the zone.
[28:38] - Working together is often more effective, so why have we gotten better at it?
[31:25] - The strength of experimentation.
[33:09] - Woody explains that since the software development process is a discovery process, innovations such as mob programming can benefit the process.
[35:25] - Woody shares resources where you can find more information on Mob Programming (see the resources section below for more) and how you can contact him to schedule a workshop.

References and resources mentioned in the show:

Software Teaming: A Mob Programming, Whole-Team Approach by Woody Zuill
Teaming by Amy C. Edmondson
Code with the Wisdom of the Crowd: Get Better Together with Mob Programming by Mark Pearl
The Mob Mentality Show on Apple Podcasts
Diffusion of Innovations by Everett M. Rogers
Online And In-Person Training To Help You Succeed With Agile Through Mountain Goat Software
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? It would be great if you left a rating and a review. It really helps, and we read every single one. Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Woody Zuill has been a software developer for over forty years. Woody is one of the pioneers of Mob Programming, a method of teamwork in software development that involves the entire team working together. Woody gives remote and in-person workshops on the topic. You can find out more about him on Twitter @WoodyZuill or on LinkedIn.

#32: Scrum in High School Sports with Cort Sharp

25 januari 2023 | 34 min

Join Cort Sharp and Brian Milner as they discuss experimenting with Scrum in other out-of-the-box environments, including how Cort uses it to train the high school swim team he coaches.

Overview

In this episode of the Agile Mentors podcast, Cort Sharp joins Brian to explore how to use Scrum tools in other environments outside of the software development arena.

Cort shares the lightbulb moment when he realized Scrum might help him become a more effective coach for his high school swim team.

Listen in as he walks us through his real-world experience using Scrum to coach swimmers, including what worked and what didn't and how he redefined things to make using Scrum successful for the team.

Listen now to discover:

[01:27] - Brian introduces Cort Sharp, the Agile Mentors Community Manager and high school swim coach.
[02:49] - Scrum is used chiefly in software, BUT there are other options. Examining out-of-the-box uses from Scrum.
[03:46] - Cort shares the story of how he got started as a high school swim coach.
[06:26] - Cort meets Scrum.
[08:39] - The discovery during Certified Scrum Training that led Cort to believe he could use Scrum to become a more effective swim coach.
[10:20] - Brian shares his own light bulb moment from his first exposure to Scrum.
[11:53] - What’s the product: Cort shares the process of translating Scrum to the swimming world.
[15:57] - How the sprint review brought everything home for Cort.
[17:03] - Evaluating how things were working with the parents of the swimmers (the stakeholders) at the weekly invitational swim meets.
[17:48] - Brian describes how Scrum helps you break things down into smaller, digestible chunks when you want to reach a big goal but don't see progress every day.
[19:02] - Cort shares how they developed the user stories for each swimmer and used feedback to develop the backlog for swim practices.
[19:44] - Cort shares the process of developing the backlog for swim practices.
[21:19] - How Agile principles (i.e., sustainable pace) translate into arenas other than software.
[24:30] - Cort explains how Scrum events like daily stand-ups and sprint reviews helped the team organize practices.
[24:47] - Which Scrum practices were harder to implement for the team? [26:47] - Opening yourself up to experimentation. (And how to reach Cort with your coaching ideas and suggestions).
[27:36] - Cort shares the biggest changes he had to make to make things work for the swim team.
[28:00] - So, who is the Scrum Master for the swim team? Redefining the Scrum roles and responsibilities to make them work in other environments.
[30:04] - Cort shares what he’s learned in the process of using Scrum with the swim team.
[33:29] - Do you have a topic or guest you'd like to see on the Agile Mentors podcast? If so, send us an email. We'd love to hear from you.

References and resources mentioned in the show

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? It would be great if you left 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 as [email protected]

This episode’s presenters are:

#31: Starting Strong: Tips for Successfully Starting with a New Organization with Julie Chickering

18 januari 2023 | 35 min

Join Julie Chickering and Brian Milner as they discuss strategies you can use to get started on the right foot with your new organization.

Overview

It's the new year, and for many people, that means starting a new chapter in their life, maybe in a new position, with a new team, or possibly an entirely new organization. It's the perfect time for reflection to determine what you can do in these first few days and weeks to set yourself up for success.

So, we thought it would be a great time to take this episode of the show to highlight some strategies you can use to hit the ground running.

In this episode of the Agile Mentors podcast, Brian Milner and Julie Chickering discuss some strategies to set the stage for success in your new position. We will walk you through the vital steps for settling into your team and making an impact no matter what level of the ladder you are on. Plus, what to ask when you are interviewing to ensure you find the right fit.

Listen now to discover:

[01:40] - Julie Chickering is on the show to discuss starting strong with your new organization.
[02:15] - How to use team retrospective to identify where things are going well to amplify the good stuff while on a discovery mission of what needs work.
[03:35] - The one thing that Julie cautions about in one-on-one conversations that will help you avoid being influenced by others' opinions of their team members.
[05:22] - How to create curiosity instead of animosity by offering reciprocal grace to help everyone work better together.
[07:17] - Brian shares how to use an improvement board to keep a running track of things while identifying your next target, stay on the right track and avoid the worst-case scenario (as referenced by Henrik Kniberg in the Spotify Model - Part 2).
[09:23] - What Brian calls his 15-minute' cheat code" for understanding the dynamics of a team.
[11:31] - Julie shares her improvement backlog one-on-one ONE thing for Scrum Masters.
[12:08] - Essential techniques to help developers make an impact and utilize their skills in their new team.
[13:57] - How to get off on the right foot with a new team as a product owner.
[14:14] - Julie shares how to determine if an agile framework like Scrum is helping you meet your business goals (or not).
[15:34] - If you cannot communicate and collaborate with your stakeholders… you'll never deliver value to them.
[16:32] - How story mapping exercises can help product owners.
[18:31] - Why communication is the key to top-to-bottom team success.
[19:40] - The most important questions to ask when you are interviewing to determine if the organization is a good fit for what you bring to the table.
[22:17] - Why it's important to remember every interaction during an interview is a part of the job interview.
[22:33] - Brian shares a story of why it's crucial to determine if the company you are going to work for is looking for someone agile or Agile.
[24:42] - Why it's essential to do a background check on a company you're considering hitching your wagon to.
[25:38] - Start with where you are: how to start strong if you have the skills and are certified but need to gain experience.
[28:30] - How can you use your skills to give back and advance in your career?
[29:38] - How to highlight your experience and use it to your advantage when seeking various roles within a company.
[32:40] - The most powerful question you can ask your team that will help you start the new year fresh.

References and resources mentioned in the show

Spotify Engineering Culture - Part 2 (aka the "Spotify Model")
The Culture Code
How does project management work in Agile? with Julie Chickering
#7: The Sprint Review is not a Demo with Julie Chickering
Agile Mentors Community
Meetup
#13: What Does Cross-Functional Really Mean? with Lance Dacy
Mountain Goat Software
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

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? Please share your thoughts with us at [email protected]

This episode's presenters are:

#30: How to Get the Best Out of the New Year with Lance Dacy

11 januari 2023 | 29 min

Join Lance Dacy and Brian Milner as they discuss how to get the best out of the new year.

Overview

Something about that turn of the calendar from December to January makes us want to dig into planning, goal setting, and change.

In this episode of the Agile Mentors podcast, Brian Milner and Lance Dacy discuss how to get the best out of the new year. They’ll walk through why personal retrospectives are the key to determining where to look for change. From 30-day challenges to building relationships with others in the Agile community, to fostering a fertile learning culture, listen in for insight into what might work for you to accomplish the change you seek to make this year your best.

Listen now to discover:

[01:15] - Welcome to our first podcast of 2023. [01:55] - How opening up our calendars to a new year sets us up for planning new things.
[03:17] - Lance walks us through the two types of leaders, the visionary and the executor.
[04:13] - Brian shares the benefit of personal retrospectives.
[07:15] - How 30-day challenges catapult us to success by breaking things down into smaller chunks.
[10:56] - Lance shares why New Year’s resolutions set us up for failure.
[12:35] - How to plan goals using backlogs and the cyclical nature of organizations.
[13:09] - How to use cross-training to challenge team members to broaden their horizons in the new year.
[13:09] - Why you need to think about your intentions when trying to influence up.
[14:03] - Why do 30-day challenges work well to engage in a new task, project, or skill with an experimental mindset.
[15:29] - Lance shares why it’s critical for Scrum Masters to help leadership and management formulate career plans to help grow the people in the organization.
[16:33] - If you’re doing the same thing you did last year, you’re not Agile.
[17:16] - How plugging into a community can help you maintain your focus for growth.
[19:48] - Why being a Scrum Master and a lone wolf don’t mix.
[22:36] - How networking can help you take your career to the next level.
[24:10] - Why it pays to keep an open mind (even to that which you don’t agree with), so you don’t miss out on vital information that can change your trajectory.
[26:07] - Growing as a Scrum Master and as a person.

References and resources mentioned in the show

Agile Mentors Community
Meetup
#13: What Does Cross-Functional Really Mean? with Lance Dacy
Mountain Goat Software
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

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? Please share your thoughts with us at [email protected]

This episode's presenters are:

Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

#29: Influencing Up with Scott Dunn

21 december 2022 | 30 min

Join Scott Dunn and Brian Milner as they discuss how to influence up, including the tools you can use to overcome difficulties and step into a partnership with the influential people in your organization for influence that creates lasting change.

Overview

While we all want to be heard, but we are sometimes met with leaders in our organization who are uninterested in our concerns or resistant to giving needed support.

And sometimes, it's our approach that's causing our conversations to fall flat.

In this episode of the Agile Mentors podcast, Brian Milner and Scott Dunn share their real-world experience on what to do from your side to earn the right to influence up. They discuss what bosses, managers, leadership, stakeholders, and other higher-ups in the organization want and tools you can use to overcome the gaps and step into a partnership with the powerful people in your organization for lasting change.

Listen now to discover:

[01:06] - Today, Brian and Scott Dunn discuss influencing up.
[01:40] - Scott shares how it's easier to influence if you meet people where they are.
[03:46] - How to create a win-win by adjusting your communication style.
[04:25] - Scott shares how to earn the right to influence up by making things happen on your side of the fence.
[06:17] - How a mind of curiosity can help you negotiate your position when the higher-ups say they are 100% onboard with Agile except for…
[08:22] - How to challenge management without losing your job or credibility.
[10:05] - Why it's vital to look for opportunities to influence an organization at every level.
[11:07] - Organizational taxes are the price of the privilege of working in an organization.
[12:07] - Brian shares how even small iterations of Agile can move the needle in organizations.
[13:09] - Why you need to think about your intentions when trying to influence up.
[14:28] - Scott shares how you can introduce tenants of Agile to show people how to work differently, show up differently, and make a difference to improve an organization.
[16:05] - How returning to values on the Agile Manifesto helps organizations create team dynamics that inspire respectful team dynamics.
[18:59] - Scott shares how making your boss look good makes a big difference for everyone in the organization.
[20:09] - Brian shares how to think like your boss so you can frame your approach in a way that speaks their language.
[23:58] - The opportunity to 'choose your own adventure' within your organization through sharing information.
[25:29] - How to use the power of story to give your boss the tools to help make the change to Agile.
[27:11] - Scott shares how resources such as the Agile Mentors Communit y can help you delve deeper into community for insight into solving your influence issues.

Listen in next time when Lance Dacy will be on the show.

References and resources mentioned in the show

Agile Manifesto
#24: How Agile Organizations Respond to Challenging Economic Times with Scott Dunn
#1: Scrum vs Agile & Keys to Success with Mike Cohn
Lyssa Adkins
How To Be Successful with Agile in Any Culture
Christopher Avery - CEO & Founder -The Responsibility Company | LinkedIn
Mountain Goat Software
Agile Mentors Community
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

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? Please share your thoughts with us at [email protected]

This episode's presenters are:

#27: Leading Without Blame with Tricia Broderick

7 december 2022 | 32 min

Tricia Broderick joins Brian to discuss how to lead without blame.

Overview

Vince Lombardi said, “Leaders aren’t born, they are made,” Great leadership is a learned skill, but in companies focused on the blame game, transparency and problem-solving becomes secondary to self-protection.

Tricia Broderick is a leadership and organizational advisor.

Today on the show, Tricia joins Brian to discuss how the blame game stifles great leadership and how the 4Cs can help leaders create safe spaces for highly connected, motivated teams to achieve better results and more impactful outcomes.

Listen now to discover:

[01:37] - Brian introduces us to Tricia Broderick, co-author of the new book, Lead Without Blame: Building Resilient Learning Teams.
[02:36] - Is there a difference between a leader and an Agile leader?
[04:18] - How exposure to the Agile community framework organically promotes leadership.
[06:47] - How the blame game stifles leaders.
[08:28] - When you're afraid of blame, you’re focused on self-protection instead of moving forward.
[09:38] - Why impact is more important than intention and why taking responsibility for your impact is vital.
[11:57] - Tricia shares what we really need for the most creative, quality-based results and outcomes.
[14:43] - Tricia shares why we need to break free from a culture of blame and instead focus on shared goals for quality outcomes.
[16:43] - Tricia shares the 4Cs of leadership.
[17:52] - Great leaders aren’t afraid of complexity; they embrace uncertainty.
[18:37] - Leaders instill confidence in others—having a leader that believes in you before you even believe in yourself has a huge motivating impact.
[19:53] - Brian shares the concept of ‘dark leadership.’
[20:42] - Why compassion is the key to defeating imposter syndrome.
[22:37] - It takes a courageous leader to create a safe space to challenge the status quo and seek out alternative ways for your team to operate.
[25:37] - Why investing yourself personally and compassionately in the personal development of your team members isn't for the weak.
[26:08] - The importance of the investment in a connection.
[26:37] - Tricia shares the biggest takeaway for leaders.
[27:31] - Tricia talks about resilient transparency and the leadership learning curve.

Listen next time when Julie Chickering will be on the show.

References and resources mentioned in the show

Lead Without Blame: Building Resilient Learning Teams
Mountain Goat Software
Agile Mentors Community
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

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? Please share your thoughts with us at [email protected]

This episode's presenters are:

Tricia Broderick’s transformational leadership, at all levels of an organization, ignites the growth of leaders and high-performing teams to deliver quality outcomes. Tricia has more than twenty years of experience in the software development industry. She is the author of Lead Without Blame: Building Resilient Learning Teams.

#26: How Getting to Small Helps Teams Get Things Done with Lance Dacy

30 november 2022 | 35 min

Lance Dacy joins Brian to discuss breaking down stories to get things done.

Overview

There are ways to break stories down into two- or three days worth of work across the team. But sometimes, they can be taken down to a level that devalues what your team is trying to deliver.

Lance Dacy is a Certified Scrum Trainer® with the Scrum Alliance®

Today on the show, Lance joins Brian to discuss some of the questions you need to ask when breaking stories down. We discuss how to organize teams for the best outcome and share different systems and processes to determine how far is enough when breaking down stories to help your team deliver a usable product to the end user.

Listen now to discover:

[01:37] - Brian introduces us to Lance Dacy, his guest and neighbor.
[02:29] - Brian shares how you can suggest a topic for a future podcast episode by emailing your suggestion to [email protected].
[02:57] - Today, we're talking about getting work into its smallest component.
[03:21] - Lance shares the four things teams need to do to be sure they are all speaking the same language when transitioning to Scrum.
[03:44] - The make-or-break consequences of organizing teams for the best outcomes.
[05:49] - Lance shares his insight on breaking things down into tasks in the product backlog.
[07:47] - Lance uses a car cleaning analogy to break down the story into smaller tasks.
[09:40] - In backlog refinement, we will start rounding out those acceptance criteria or conditions of satisfaction and make them their own story.
[10:58] - Lance shares his system for determining how far is 'enough' when breaking down stories to be ready.
[12:33] - The goal for each sprint planning session.
[13:09] - Using the INVEST criteria to assess the quality of a user story.
[13:48] - How small is too small?
[15:17] - I love metrics, BUT metrics CAN BE misused.
[15:55] - The key to not being surprised.
[16:37] - Brian shares the importance of the V in the INVEST criteria.
[18:14] - Vertically slicing stories to deliver something usable to the end user (the product owner).
[21:42] - Using the SPIDR approach to splitting stories.
[22:24] - Asking the right questions to create paths that lead to stories that turn into relevant products.
[25:55] - The importance of interfaces when splitting up stories.
[28:22] - The pros and cons of spikes—why they should be the exception and NOT the rule.
[32:01] - Lance circles back to the consequences of creating your teams—focusing on the deliverables.
[33:37] - Remember, releasing the product is independent of your sprint time box.

Listen next time when we'll be discussing…

Transformational Leadership with Tricia Broderick

References and resources mentioned in the show

What does INVEST Stand For?
The S.P.I.D.R. Approach to Splitting Stories
HOW TO SPLIT A USER STORY by Richard Lawrence
Mountain Goat Software
Agile Mentors Community
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

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? Please share your thoughts with us at [email protected]

This episode's presenters are:

#25: Scaling with Henrik Kniberg

16 november 2022 | 37 min

Henrik Kniberg joins Brian to talk about creating the Spotify Model.

Overview

There are ways to get things done, and then there are the best ways to get things done. But the only way to arrive at the right way of doing things is to try and fail, to see what works and what doesn't.

Henrik Kniberg is a Certified Scrum Trainer who has worked with teams like Spotify and LEGO to help them implement agile culture in their fast-moving and fast-growing environments. He's also the co-creator of the Spotify Model.

Today on the show, Henrik joins Brian to discuss his accidental introduction to Spotify and how he inspired the company to transition to Scrum. We discuss the leadership model that helped the startup scale while holding its own against behemoths like Apple and Google. Plus, an inside look at his time as a designer with Minecraft.

Listen now to discover:

[01:55] - Brian shares Henrik's Agile Product Ownership in a Nutshell that's become required viewing.
[02:22] - Brian shares some of the places on Henrik's resume, including Lego, Minecraft, and Spotify.
[03:42] - Henrik shares his love for playing accompaniment musical instruments.
[04:08] - Brian shares his professional musical background.
[04:35] - Introducing the Spotify engineering culture videos that have sparked a thousand conversations about scaling challenges.
[05:10] - Henrik shares the story of his accidental introduction to Spotify and how he inspired the startups to transition to Scrum.
[8:26] - Henrik describes how the lack of off-the-shelf scaling frameworks led to his work with Spotify.
[08:45] - Standard Scrum, by the books, works for small teams, but for scaling at larger teams like the one at Spotify, it's hard to find a "one size fits all" approach.
[10:59] - How realizing 'this is what's helping us swim' during their impressive growth got all the technical leaders of Spotify on board with using Agile.
[12:50] - Henrik shares the leadership model that helped Spotify scale up.
[14:58] - How Spotify used the speed of innovation to stand against goliath-like competitors like Apple and Google.
[16:30] - Convincing the investors that being able to iterate quickly (rather than through roadmaps) was the key to winning the game.
[18:09] - Fueling future inspiration—why Spotify instituted the twice-a-year hack weeks for their entire organization.
[21:36] - Henrik shares why leadership is the key to culture and driving change in an Agile organization.
[24:19] - Brian shares why it's wise to make a change where you can benefit a company rather than hanging on to the now-extinct gold watch at retirement.
[25:53] - "Go ahead and copy the Spotify model… and don't worry about someone telling you that you're doing it wrong because that's just you adapting."
[26:44] - How the Spotify culture videos had the opposite outcome from what Henrik had planned.
[29:54] - Brian asks Henrik an important Minecraft question (as posed by his daughter.)
[30:36] - Henrik shares insider information about the guiding principles for designers at Minecraft (and how that led to the creation of Striders).
[32:34] - Brian shares why copy/paste is only sometimes best.
[32:46] - Henrik shares how creating video games differs from life applications.

Listen next time when we'll be discussing…

Getting to Small with Lance Dacy

References and resources mentioned in the show

Agile Product Ownership in a Nutshell
Spotify Engineering Culture - Part 1 (aka the "Spotify Model")
Spotify Engineering Culture - Part 2 (aka the "Spotify Model")
Mountain Goat Software
Agile Mentors Community
Scrum Alliance
Subscribe to the Agile Mentors Podcast on Apple Podcasts

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? Please share your thoughts with us at [email protected]

This episode's presenters are:

Henrik Kniberg is former member of the board of directors of the Agile Alliance and enjoys helping companies succeed with both the technical and human sides of software development. A Certified Scrum Trainer he’s worked with teams like Spotify and LEGO to help them implement agile culture in their fast-moving and fast-growing environments. He’s also the co-creator of the Spotify Model.

#24: How Agile Organizations Respond to Challenging Economic Times with Scott Dunn

9 november 2022 | 34 min

Scott Dunn joins Brian to talk about how Agile teams and organizations respond in difficult economic times.

Overview

Right now, the word recession is being bandied about, and big companies like Apple and Facebook are already beginning to scale back. But economic downturns can present opportunities for the right individuals.

Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with more than 20 years of experience.

Today on the show, Scott joins Brian to discuss why now is the moment to hone in on your mission and determine your job market value and how Agile training can prepare you for any opportunity that comes your way.

Listen now to discover:

[01:52] - Brian shares how the word recession triggers companies to batten down the hatches.
[03:19] - How leaning into Agile in an organization creates a natural operating cost reduction.
[04:52] - Studies show organizations that invest during recessions are better positioned at the back end of it to, you know, accelerate like a rocket out of it.
[06:55] - Scott explains how the Japanese concept of ‘danger opportunity’ offers teams a chance ‘to really do Agile’ and operate efficiently with less.
[9:34] - How difficult times help companies prioritize and hone in on their mission and vision and stop trying to be everything to everybody.
[12:57] - How organizations create unease and lack of employee trust.
[14:46] - How Agile can help workplaces bring humanity back when responding to change.
[16:18] -Scott shares a conversation with his daughter about voting with your feet and your values.
[19:16] -Scott explains why companies need to invest in top talent to lower their technical debt.
[20:17] - Why times like these require ruthlessness in proving out your theories.
[22:10] - Scott shares why down economic times are opportunities in disguise for individuals to determine the types of environments they want to help flourish.
[25:13] - Determining your job market value and the importance of looking at the total package of an opportunity.
[28:30] -Is it really Agile, or is it Agile in name only?
[31:33] - How taking classes at Mountain Goat can prepare you to bring your knowledge and skills to any opportunity.

Listen next time when we'll be discussing…

Scaling with Henrik Kniberg.

References and resources mentioned in the show

Mountain Goat Software
Agile Mentors Community
Scrum Alliance
Jim Collins The Hedgehog Concept

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? Please share your thoughts with us at [email protected]

This episode's presenters are:

#23 How Agile Works in Education with John Miller

2 november 2022 | 36 min

John Miller joins Brian to talk about Agile in the classroom.

Overview

Agile classrooms help students develop skills that will serve them long after they've left the classroom.

John Miller is a Certified Enterprise Coach (CEC) and the Chief Empowerment Officer for Agile Classrooms.

Today on the show, John joins Brian to share how he started introducing the Agile framework to educators. He walks us through how Agile classrooms help students solve complex problems while developing decision-making skills. He'll share how converting to an Agile classroom creates deeper, more fulfilling student and teacher relationships and the steps teachers can take to make their classroom an Agile classroom.

Listen now to discover:

[01:27] - Brian introduces John Miller and explains how, as a CEC, he's reached the highest rung on the Scrum Alliance certification ladder.
[03:33] - How John got started with bringing Agile to the classroom.
[06:09] - The collaboration between John and the educators to achieve the goal of creating a self-managing classroom.
[09:45] - John shares how he went from thinking he'd ruined one class's education to watching them become one of the best self-managing groups he's ever seen.
[12:16] - How children's lack of preconceived notions about how things are supposed to work helps them create teams that work.
[13:48] - How an Agile classroom empowers students of all levels and learning abilities.
[14:36] - The five levels of choice in an Agile classroom.
[15:44] - John shares the objective of Agile classrooms to help students solve complex problems by developing choice-making skills.
[17:55] - Brian shares that "Scrum is a sports analogy."
[19:33] - Dark Scrum vs. Bright Scrum. John shares the formula he created using Ron Jeffries' term Dark Scrum.
[24:06] - Is Agile dead, or are people just doing it wrong?
[25:13] - John shares the levels of classrooms where Agile works best. Plus, which one did he work with that made him more nervous than high-level CEOs?
[27:12] - John explains how the different dynamics lead to different success outcomes for incorporating Scrum into the classroom.
[28:42] - What size classrooms achieve the most benefits from working with Scrum?
[29:44] - John shares the steps teachers can take to make their classroom an Agile classroom.
[31:20] - How converting to an Agile classroom creates deeper, more fulfilling teacher-student relationships.
[31:53] - How Agile in the classroom acts as a bridge to industry and a life skills primer.

References and resources mentioned in the show

Agile Mentors Community
Scrum Alliance
Agile Classrooms
Dark Scrum
Agile Manifesto
McGregor's Theory

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? Please share your thoughts with us at [email protected]

This episode's presenters are:

John Miller is a Certified Enterprise Coach (CEC) and the Chief Empowerment Officer for Agile Classrooms. Since 2012, John's mission through Agile Classrooms has been to help educators take a more innovative and creative approach to guiding faculty, managing their schools, and teaching students.

#22: How to Create Helpful Product Roadmaps with Roman Pichler

26 oktober 2022 | 44 min

Roman Pichler joins Brian to talk about Product Roadmaps.

Overview

Product roadmaps help teams plan their everyday work and how their products will change over a year. But then, products evolve, and new data is collected and shared. Companies must then decide how to adapt and progress. So, how can we then create a product roadmap?

Roman Pichler is an internationally renowned product management expert specializing in product strategy, leadership, and agility.

Today on the show, Roman joins Brian to discuss how to create helpful product roadmaps that create value for the end users in a Scrum based context to move forward and simplify product management.

Listen now to discover:

[00:06] - Brian introduces Roman Pichler, one of his 'agile heroes.
[00:35] - Brian shares about the book Strategise, 2nd Edition.
[02:54] - Roman answers the question, "What is a Product Roadmap?"
[03:58] - Roman explains if product roadmaps are helpful in an agile Scrum based context.
[05:31] - Roman discusses using outcome-based goal-oriented roadmaps to determine a company's product value.
[07:33] - Roman shares some examples of goals on a product roadmap.
[08:12] - Why a goal-oriented based roadmap is all about outcomes.
[09:35] - Brian shares insight into Roman's downloadable Go Product Roadmap.
[10:07] - Roman shares how the latest version of the Scrum guide fits in with protocols, product goals, and outcome-based roadmaps.
[11:54] - Why Roman adds time frame constraints into his product end goals.
[14:41] - Roman shares the two things you need to succeed with collaborative product road mapping in an agile space.
[16:40] - Roman explains how to incorporate time frame constraints into your roadmap.
[19:40] - The difference between an internal and external product roadmap for public consumption.
[21:11] - The importance of an impact analysis when determining whether to stick with a specific delivery date or fully meeting a goal.
[25:00] - How to get precise estimates for your team.
[26:15] - Roman shares his 'sweet spot' for making outcome-based investment decisions.
[28:40] - Roman advises setting dates on (internal) roadmaps for contract-based environments.
[29:06] - Roman shares Apple's trade-off decision when they launched the original iPhone in 2007.
[31:40] - How to use goals to track the most valuable metrics.
[34:41] - The importance of understanding the needs of the stakeholders.
[35:19] - Roman shares the importance of balancing expectations with empathy for improved collaboration.
[39:12] - Brian shares a funny story about the difference in polite communication between Americans and our friends on the other side of the pond.
[40:46] - Roman shares why you shouldn't relinquish product road mapping in an agile space too soon.

Listen next time when we'll be discussing…

Agile and education with John Miller.

References and resources mentioned in the show

Roman Pichler
Strategise
Go Product Roadmap

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? Please share your thoughts with us at [email protected]

This episode's presenters are:

Roman Pilcher is a leading product management expert specializing in product strategy, leadership, and agility. He has advised product leaders and taught product managers and owners for over 15 years, pioneering agile product management practices. Roman shares his knowledge through his training courses, books, and podcast. You can find his popular Product Vision Board and Go Product Roadmap on his website.

#21: Agile Marketing Teams with Stacey Ackerman

19 oktober 2022 | 31 min

Brian speaks with Stacey Ackerman about working with Marketing teams using Agile.

While the majority of teams using Agile are based in software, one of the fastest growing areas for Scrum teams is in Marketing. There’s a natural fit as Marketers are used to using such practices as A/B testing and getting quick results that feed their next steps.

As you can imagine, there are a unique set of challenges that a marketing team presents that other Scrum teams don’t necessarily have to deal with as well. In this episode, Stacey talks us through the process that marketing teams follow when attempting to apply agile principles to their work.

Listen now to discover:

- 2:28 - what’s different about the way marketing teams approach agile?
- 8:51 - what is the Agile Marketing Navigator and how are teams using it?
- 15:05 - Stacey goes over the different roles
- 17:43 - what are the chief problems marketing teams deal with in adopting this?

Listen next time when we’ll be discussing…

Product Roadmaps with Roman Pichler!

References and resources mentioned in the show

Agile Marketing Manifesto

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? It would be great if you left 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 as [email protected]

This episode’s presenters are:

Stacey Ackerman is one of the few agile coaches and trainers that got her start in marketing. After graduating from journalism school, she worked as a content writer, strategist, director, and adjunct marketing professor. She became passionate about agile as a better way to work in 2012 when she experimented with it for an ad agency client. Since then she has been a scrum master, agile coach and has helped with numerous agile transformations with teams across the globe. Stacey speaks at several agile conferences, has more certs to her name than she can remember and loves to practice agile at home with her family. As a lifelong Minnesotan, she recently relocated to North Carolina where she’s busy learning how to cook grits and say “y’all."

#20: Best of Coaching Calls with Mike Cohn

5 oktober 2022 | 31 min

Mike and Brian take audience questions in the “best of” from the Agile Mentors Community’s monthly coaching calls.

Overview

Twice a month, there is an open Q&A session we offer as part of the Agile Mentors Community where anyone from the community can join in and ask either Mike or Brian questions. These are open discussions and allow the users to ask their own questions that are unique to their situations. We call these “Coaching Calls” because they are there to help coach the members and help them overcome obstacles along the way.

Everyone who takes a class with Mountain Goat Software receives 12 months membership in the Agile Mentors Community and they are able to attend these calls and ask questions. Take a listen to some of the best questions we’ve received over the past few months to get an idea of what these sessions are all about.

By the way, we are aware there are a few places where the audio is not perfect in this episode and apologize for the less-than-ideal audio in several places. This is because these answers come from live sessions and there were a few streaming hiccups while delivering them.

Listen now to discover:

3:10 - Brian: How to conduct fun retrospectives when you aren’t allowed to use cloud-based tools?
7:40 - Mike: How much planning is needed to ensure we complete items in a Sprint?
11:50 - Brian: Do you change the story points on an item if it turns out to be bigger than you thought?
14:50 - Mike: Why use Fibonacci numbers to estimate?
18:05 - Brian: Should Product Owners attend a Daily Scrum?
20:25 - Mike: What’s the best practice for capturing Non-Functional Requirements?
23:00 - Brian: How do you get your first experience as a Scrum Master if you have none?
26:46 - Mike: Tips for starting out with a new team?

Listen next time when we’ll be discussing…

Next week we will be taking a very short break of just one week. We are trying to practice a sustainable pace approach and are taking just one week off in order to do that.

References and resources mentioned in the show

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? It would be great if you left 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 as [email protected]

This episode’s presenters are:

Mike Cohn is co-founder of the Scrum Alliance, and founder of Mountain Goat Software. He’s a veteran of applying Scrum and agile principles and practices to help organizations build better products and ship them on time.

#19: How does project management work in Agile? with Julie Chickering

28 september 2022 | 38 min

This week, Brian Milner is joined by Julie Chickering to talk about the wild world of Project Management.

Overview

Brian Milner and Julie Chickering discuss how the world of project management can blend successfully with an Agile approach. There seems to sometimes be an attitude that it’s an either/or decision with these two. In this podcast, we take a look at how to blend them, how project managers fit in, and how these two disciplines can coexist.

Julie brings her experience to this discussion having come from the project management realm.

Listen now to discover:

3:42 - Brian asks Julie about the general distrust between these communities
6:15 - Julie shares that 50% of the PMP exam now is on Agile practices
8:38 - Julie brings up the dreaded status report - Green / Yellow / Red
12:10 - Julie brings up the politics of Green / Yellow / Red
15:10 - Julie talks about the cost of poor quality
16:26 - Are we in the Agile community making PMs feel wrong?
17:22 - Brian discusses Outcomes vs Output
26:10 - Brian asks about PMs who are in companies making transitions. What happens to the project managers?

Listen next time when we’ll be discussing...

Brian and Mike Cohn share some of the best questions from their live coaching calls on the Agile Mentors community.

References and resources mentioned in the show

Monty Python
Project Management Institute
The Cowman and the Farmer Should be Friends from Oklahoma!
HBR article on Output vs Outcomes
From Project Manager to Scrum Master - 3 Tips for Making the Transition
Agile Project Management by Jim Highsmith
The Software Project Manager’s Bridge to Agility by Michele Sliger and Stacia Broderick
PM Illustrated: A Visual Learner’s Guide to Project Management by Mike Griffiths - free on Kindle

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? It would be great if you left a rating and a review. It really helps, and we read every single one.
Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Julie Chickering is a certified Scrum Trainer as well as a CST, PMP, PMI-ACP CSM, CSPO, and Path to CSP Educator. She believes that Agile practices are packed with potential — to enable business agility, and breakthrough results. Julie loves to help people implement agile even when the environments are messy, people are complicated, and situations are challenging. She brings real-world experience working with people at all levels to adopt and roll out realistic Agile strategies organization-wide.

#18: Coaching in an Agile world with Lyssa Adkins

21 september 2022 | 34 min

Lyssa Adkins joins Brian to talk about the wonderful world of Agile coaching.

Overview

When you think of the term “Agile Coach,” what comes to mind for you? This term has meant many different things over the years. Are we talking about a role or an approach? Lyssa Adkins, author of Coaching Agile Teams, joins Brian to dive into this topic. Lyssa has written and spoken about this topic for years and many would say she had a large hand in defining what we now call agile coaching.

Listen now to discover:

02:05 - Brian shares a story about Lyssa from the Vienna Scrum Gathering conference

06:40 - Lyssa answers the question, “What is an Agile Coach?”

08:10 - Lyssa explains the unintended consequence of using the term “coach” in her book

12:02 - Lyssa talks about the “X-Wing Diagram” and the 5 coaching stances

18:50 - Lyssa talks about not colluding when someone in power pushes something you disagree with

27:04 Lyssa talks about coaching in a remote world

Listen next time when we’ll be discussing…

Project Management with Julie Chickering.

References and resources mentioned in the show

Coaching Agile Teams by Lyssa Adkins

Agile Coach Competency Framework

Developing Great Agile Coaches whitepaper describing 5 coaching stances

What is an Agile Coach? talk with Lyssa Adkins and Michael Spayd

Want to get involved?

This show is designed for you, and we’d love your input.

● Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.

● Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Lyssa Adkins has been one of the foundational voices in the Agile community for years now. Her book Coaching Agile Teams has been a best seller for over 12 years now. She released an audio version of this classic book on its 10th anniversary. In 2010, Lyssa co-founded the Agile Coaching Institute which has developed over 10,000 people in the knowledge, skills, and being-ness needed to yield genuinely competent agile coaching. She is a member of the ICAgile working committee and has served as a reviewer for the Scrum Alliance’s Certified Enterprise Coach certification program. Lyssa is also dedicated to amplifying women’s voices and is a founder of TENWOMENSTRONG #WomenInAgile programs.

Show edited by Rhett Gill.

#17: Getting There From Here: Agile Transformations with David Hawks

14 september 2022 | 40 min

David Hawks joins Brian to discuss the process of an organization becoming Agile.

Overview

When you read through the Scrum Guide, the picture it paints is of the desired end result - what the team/organization should look like when finished. There’s surprising little said though about how you get from where you are to where you want to eventually be. Enter the topic of Agile Transformations. There is a journey that organizations undertake when they decide to adopt Agile and like any journey, it’s always helpful to have a guide to help you get there who has been through it before. David Hawks joins Brian to share his experience in helping countless organizations make this journey to become Agile.

Listen now to discover:

03:10 Brian asks David what the biggest hurdle is that organizations have when adopting Agile?

05:24 David explains that multiple levels the organization needs to focus on in the process

11:00 David talks about “Implementing Practices over Outcomes”

16:30 Brian asks what individuals who aren’t leaders can do to help?

20:20 Brian asks David to explain how his Path to Agility helps address these issues?

29:35 Brian talks about the Spotify Engineering Culture videos example

Listen next time when we’ll be discussing…

Agile Coaching with Lyssa Adkins!

References and resources mentioned in the show

Path To Agility & Agile Velocity

SAFe and LeSS

Yellowstone spinoff 1883

Oregon Trail

Spotify Engineering Culture Video 1 and Video 2

Want to get involved?

This show is designed for you, and we’d love your input.

● Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.

● Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

David Hawks is the CEO of both Agile Velocity and Path to Agility. He is a Certified Scrum Trainer as well as a Certified Enterprise Coach with the Scrum Alliance - their top two certifications. He received his Bachelor of Business Administration in Management Information Systems degree from the University of Texas at Austin. His love for his beloved Longhorns from UT is only eclipsed by his love (and expertise) in tailgating prior to their home games!

Show edited by Rhett Gill.

#16: Quality: The Hidden Secret Ingredient with Mitch Lacey

7 september 2022 | 31 min

Mitch Lacey joins Brian to talk about building quality into our work.

Overview

The Scrum Guide says the developers own quality and that it is both a right and responsibility of the team. What does that look like though? What do we mean when we say quality? How do teams practically go about building quality or is it just “baked in?” Join Brian and Mitch Lacey as they discuss this all important secret ingredient to the Scrum framework and hear why it’s so vital to a team’s success.

Listen now to discover:

2:25 Mitch explains what we mean by quality

6:48 Brian asks Mitch how to tell when you are “gold plating” things?

12:30 Brian asks about the developer who thinks the code needs to be perfect before they release

16:55 Brian talks about the last stage of the creative process is releasing

21:25 Mitch relates self-accountability to a recent Soccer(Football) match

22:34 Brian and Mitch discuss the infamous “Squirrel Burger” story

Listen next time when we’ll be discussing…

David Hawks joins us as we discuss transformations.

References and resources mentioned in the show

Test Driven Development

“Squirrel Burger” story

Want to get involved?

This show is designed for you, and we’d love your input.

● Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.

● Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Mitch Lacey is an agile practitioner and trainer. Mitch has been managing projects for over fifteen years & is credited with many plan-driven & agile projects. He is the author of “The Scrum Field Guide,” a book targeting teams adopting agile and Scrum practices. He has published many papers, including “Adventures in Promiscuous Pairing,” “Transitioning to Agile: Key Lessons Learned in the Field,” “The Impacts of Poor Estimating -& How to Fix It,” plus a variety of papers for Microsoft and “Immersive Interviewing -Building Great Agile Software Teams.”

Show edited by Rhett Gill.

#15: Answering Questions from Quora with Brian Milner

31 augusti 2022 | 36 min

Brian takes some of the most popular questions about Scrum from Quora.com and answers them.

Overview

If you are unfamiliar with it, Quora.com is a site people in the technology industry go to to ask and answer questions. For a change of pace, I decided to take a batch of the most popular questions from the site and provide my own answers to them. If you have questions you’d like to include in a similar episode in the future, make sure to email them to [email protected].

Listen now to discover:

01:14 Brian explains the premise behind this episode’s topic

02:25 Question 1: Why do iterations in Agile start from Wednesday to Tuesday rather than Monday to Friday?

09:00 Question 2: Are Burndown charts even useful?

16:14 Question 3: Who decides sprint duration in a Scrum project?

18:50 Question 4: As a Scrummaster, how do you deal with people being late or refusing to come to Daily Scrums?

24.32 Question 5: Can a User Story be used for bugs?

26:54 Question 6: Can Agile work without a Scrummaster?

Listen next time when we’ll be discussing…

Join us next time where we will be discussing the topic of Quality with our guest Mitch Lacey.

References and resources mentioned in the show

Send your questions for a future episode to [email protected].

Want to get involved?

This show is designed for you, and we’d love your input.

● Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.

● Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenter is:

Show edited by Rhett Gill.

#14: What does it mean to be Product-Centric? With Scott Dunn

24 augusti 2022 | 40 min

Scott Dunn joins Brian to talk about what it means to be product-centric

Overview

Being product-centric has become a recent buzzword and objective for companies. But what does it mean? Is it the next stage of becoming agile? Or is it something that should drive an agile transformation in the first place? In this episode Scott and Brian discuss their definitions of what it means to be product-centric, and whether this is different to being customer-focused. They also look at the limitations that can stop teams from being more focused on the customer and long-term product value, such as being forced to fight those daily fires.

Listen now to discover:

00:23 - What does the term product-centric mean?

07:13 - Is there a difference between being product-centric and customer focused?

14:47 - Are nonprofits customer-focused entities?

22:02 - Does product-centric mean putting quality first?

28:23 - How does a disconnect between leadership and teams affect things?

Listen next time when we’ll be discussing…

Next time, I’ll be answering questions you’ve sent into the show as well as addressing other common agile questions.

References and resources mentioned in the show

Impact Mapping and Story Mapping

The Scrum Guide

Kano Model for prioritization

Want to get involved?

This show is designed for you, and we’d love your input.

● Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.

● Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Scott Dunn is a Certified Enterprise Coach and Certified Scrum Trainer with more than 20 years of experience in management, project management (PMP), engagement management, and software development (MCSD). He is passionate about strengths-based teams and a solutions-based approach to people and organizational issues.

Show edited by Rhett Gill.

#13: What does cross-functional really mean?

17 augusti 2022 | 45 min

Lance Dacy joins Brian to dig into cross-functionality.

Overview

You will often hear people say that Scrum teams are cross-functional. But what do we mean when we say that? Are we talking about a jack of all trades but master of none? Do we want team members who can do anything? How does a cross-functional team actually work together and what should we do as agilists to support and nurture cross-functionality in our teams? Join as we discuss these and other aspects of cross-functional teams.

Listen now to discover:

02:00 Lance tells us how he defines cross-functional teams

04:34 Brian compares cross-functional teams to the A-Team

08:58 Lance talks about generalists vs specialists

12:39 Brian talks about T-shaped individuals

18:05 Brian discusses the Equity Couch

24:10 Brian describes the Market of Skills tool

27:45 Lance talks about personality profiles

29:20 Brian asks Lance about how to handle cross-functionality on specialist teams

Listen next time when we’ll be discussing…

Scott Dunn joins us again to discuss the term ‘product-centric.’

References and resources mentioned in the show

The A-Team

Market of Skills by Lyssa Adkins

OSEMN Process

What does Scrum mean by Cross-functional?

Want to get involved?

This show is designed for you, and we’d love your input.

● Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.

● Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

Show edited by Rhett Gill.

#12: Kanban with Kert Peterson

10 augusti 2022 | 29 min

Kert joins Brian again to talk about Kanban

Kanban is a pull system of working where work is ‘pulled’ in based on a team’s capacity. Whether it’s a card from a backlog, or a bin of items on a manufacturing floor, the concept of pulling in work is common to both kanban and scrum. It supports the idea of being agile because whenever you’re pulling work in, you’re basing it on the latest feedback and emergent needs so that you can focus on delivering the most value. Listen now for an overview of Kanban as well as common mistakes to avoid.

Listen now to discover:

00:48 - The origin of Kanban’s meaning

04:34 - How the principles of Kanban are expressed in Scrum

07:00 - Common misconceptions people have about Kanban

09:00 - The five pillars of Kanban

12:58 - How to get started

19:41 - How to improve your current Kanban process

Listen next time when we’ll be discussing…

I’ll be joined by Lance Dacy as we talk about cross-functional teams.

References and resources mentioned in the show

Kanban University

The Official Guide to the Kanban Method

Want to get involved?

This show is designed for you, and we’d love your input.

● Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.

● Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Kert began his professional career as a Software Engineer in NASA's Space Shuttle program, affording him practical insights into the daily challenges faced by engineers, designers, and testers. Driven by the belief that learning unlocks potential, Kert has pioneered educational programs for Dell, Rockwell Collins, Amazon.com, and Capital One Financial. Kert is one of the few trainers world-wide to be actively credentialed as both a Scrum and Kanban trainer by Scrum Alliance and Kanban University, respectively.

Show edited by Rhett Gill.

#11: Estimating in Agile with Mike Cohn

3 augusti 2022 | 34 min

Brian and Mike talk about why and how to use Story Points in estimating.

Overview

To estimate or not to estimate. There are many different views on the matter. It’s important then to start with why. Why would we spend time estimating in the first place? What is the benefit of that effort? Do all Agile teams need to estimate? Join Brian Milner and Mike Cohn as they discuss estimating using Story Points in order to plan for things such as releases.

Listen now to discover:

1:51 - Mike talks about the 3 reasons why would we estimate in the first place?

4:30 - Brian asks about the #NoEstimates movement

8:00 - Brian talks about the marketing aspect of his conference talk this year

9:42 - Mike defines what a Story Point is

14:30 - Mike talks about using Story Points as a performance metric

21:20 - Mike talks about consistency in point scales across teams

25:58 - Mike talks about working with contractual constraints when using Story Points

Listen next time when we’ll be discussing…

Join us as we dive into Kanban with Kert Peterson. We’ll talk about this close relative to Scrum and discuss how these two can coexists in today’s Agile world.

References and resources mentioned in the show

Agile Estimating and Planning by Mike Cohn

Agile Estimating and Planning online ecourse by Mike Cohn

Woody Zuill of the #noestimates movement (and Mob Programming)

Want to get involved?

This show is designed for you, and we’d love your input.

● Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.

● Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Show edited by Rhett Gill

#10: Why User Stories are the Best Way to Capture Requirements with Mike Cohn

27 juli 2022 | 35 min

Brian and Mike talk about how to capture requirements with User Stories.

User Stories are not native to Scrum. We actually borrow the practice from XP. Traditionally, requirements were gathered in huge binders that were very detailed and complex. These were considered complete and were locked down when development began. Teams quickly found that change was a constant and this method of capturing requirements didn’t allow for requirements to emerge. Enter User Stories.

Listen now to discover:

2:15 - Mike talks about the history of User Stories

4:00 - Mike discusses the problem User Stories is attempting to solve

4:58 - Mike talks about making lunch

7:30 - Mike talks about when NOT to use User Stories

10:26 - Mike and Brian talk about The Beatles

14:00 - Is As a User an ok way to start a User Story?

15:00 - Mike talks about Job Stories

19:55 - Mike talks about some common mistakes people make with User Stories

23:00 - Is the So That clause needed?

Listen next time when we’ll be discussing…

Mike Cohn returns to discuss Estimating with Brian. Mike has written a book about this (Agile Estimating and Planning) and will share his insights on this important topic.

References and resources mentioned in the show

User Stories Applied - by Mike Cohn

Better User Stories course - by Mike Cohn

Billboard interview with Paul McCartney where he talks about using personal pronouns

Intercom who makes chatbots

Want to get involved?

This show is designed for you, and we’d love your input.

● Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.

● Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Show edited by Rhett Gill.

#9: Scrum Artifacts with Kert Peterson

20 juli 2022 | 40 min

Brian and Kert talk about the final component of the Scrum Framework - Artifacts.

Overview

The term “artifact” seems a bit strange, doesn’t it? Why would the authors of Scrum include this as a component of the framework? What are the main artifacts that Scrum prescribes? And what are some of the other artifacts that are not required but many teams see as helpful to the running of a Scrum team? In this episode, Brian and Kert will discuss this final component of the Scrum framework in the Scrum Framework series and give you pointers on how to make the most out of the Scrum artifacts.

Listen now to discover:

3:45 - hear Kert and Brian talk about the roots of this term

6:15 - Kert talks about his experience with documentation working at NASA

9:15 - Kert talks about the two backlogs in Scrum

12:30 - Brian and Kert talk about what level of detail is needed in backlog items

16:12 - Who is the therapist on a Scrum team?

19:00 Is tasking out everything required for Sprint Planning?

23:41 - Kert talks about how Ken Schwaber called Scrum, “The Art of the Possible”

31:27 Brian and Kert talk about the Definition of Done

33:24 Brian talks about a tool to facilitate the creation of a Definition of Done

Listen next time when we’ll be discussing…

Mike Cohn returns to discuss User Stories with Brian. Mike has literally written the book on User Stories (User Stories Applied) and shares his wealth of experience and knowledge on the subject.

References and resources mentioned in the show

Married at First Site - Lifetime TV Network

Larry Maccherone talks about Kanban Metrics

David A. Koontz’s exercise for creating a Definition of Done

Want to get involved?

This show is designed for you, and we’d love your input.

● Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.

● Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#8: Sprint Retrospectives with Scott Dunn

13 juli 2022 | 37 min

Join Brian Milner and guest co-host Scott Dunn as they discuss why the retrospective is an important part of agile and how to use this meeting to help teams to improve continuously.

Overview

In this episode, Brian Milner is joined by guest co-host Scott Dunn, Certified Enterprise Coach and Scrum Trainer, to get insights into delivering retrospective sessions that energize and inform the whole team — while ensuring they are effective at meeting goals.

A sprint retrospective is a great way for teams to reflect on the previous sprint but this meeting can become stale if you sleepwalk your way through the same agenda every time. Brian and Scott discuss the Scrum Master’s responsibility to take ownership of the retrospective and the importance of developing a toolkit of techniques that you can use and adapt to engage and motivate your teams.

There are many great retrospective ideas in the Agile community, including variations and additions on the basic questions and creative facilitation techniques. Sharing their experiences and offering advice to Scrum Masters on how to empower their teams, drive participation and unlock creativity, Brian and Scott discuss the importance of innovation and how to establish a culture of trust and accomplishment to maximize the value of this meeting.

Listen now to discover:

· 00:03:00 - Why Scrum Masters need to establish safety for retrospectives to work

· 00:07:00 - How to structure a retrospective to motivate teams

· 00:09:00 - Why it is not the Scrum Master’s responsibility to resolve all impediments

· 00:11:00 - How to empower your team to have more agency over the work and make a difference as team members

· 00:13:30 - Why Scrum Masters need to take ownership of the retrospective

· 00:19:00 - Why you need to change up your retrospective to engage your team

· 00:19:30 - How to conduct fun and engaging retrospectives

· 00:23:58 - How to influence and shape your team’s culture

· 00:26:10 - How to get value from a retrospective with an introverted team

References and resources mentioned in the show

· Strengths-based Leadership - Gallup

· Training from the Back of the Room – Sharon Bowman

· Marcus Buckingham

· Agile Retrospectives - Making Good Teams Great - Esther Derby and Diana Larson

Want to get involved?

This show is designed for you, and we’d love your input.

· Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.

· Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#7: The Sprint Review is not a Demo with Julie Chickering

6 juli 2022 | 50 min

Join Brian Milner and Julie Chickering as they discuss the true purpose of the Sprint Review and why it is a mistake to call this event a ‘demo’.

Overview

Brian Milner talks with Julie Chickering about Sprint Reviews, addressing the myth that the Sprint Review is primarily an opportunity to ‘demo’ the increment to stakeholders.

As an experienced Project Management Professional, Julie shares her perspective on the Sprint Reviews from a project management viewpoint. She shares different ways to approach this event and offers advice on what components are needed for a good quality Sprint Review.

Brian and Julie agree that the Sprint Review meeting is probably the most important Scrum event for product people as it encourages collaboration and generates the feedback required to increase the chances of creating a successful product. However, opinions on who should attend the meeting, how it should be run, and how to collect relevant feedback can change quite considerably from one organization to another.

Are you holding Sprint Reviews every Sprint?

Do you have Stakeholders in your Sprint Reviews?

Are you getting valuable feedback from your Stakeholders in your Sprint Reviews?

Brian and Julie discuss why you should be answering “Yes” to each of these questions and share their tips on how to make your Sprint Review more effective.

Listen now to discover:

· 00:06:06 - How the Scrum Review saves time in the long run

· 00:10:20 - The benefits of reducing the distance between the developer and the end user

· 00:11:49 - The Stakeholder feedback window – how long should feedback take?

· 00:12:19 - Why you should never skip a Sprint Review

· 00:12:30 - Why Stakeholders need to be constantly engaged for a Scrum team to be successful

· 00:13:49 - The integral role of the Product Owner in Sprint Reviews

· 00:17:05 - Why you shouldn’t cancel a Sprint Review even if work isn’t “done”

· 00:21:36 - Why you need to clarity the definition of “done” to Stakeholders

· 00:27:19 - Tips and feedback to anyone wanting to improve their Sprint Reviews

· 00:31:02 - The importance of preparation before Sprint Reviews

· 00:34:29 - Methods of collecting feedback

· 00:39:32 - The best order for a Sprint review

· 00:41:36 - How to coach stakeholders to increase team productivity

Listen next time when we’ll be discussing…

Sprint Retrospectives with guest co-host Scott Dunn. You’ll learn the primary importance of this Scrum event and how to run effective and engaging Sprint Retrospective meetings that boost productivity and lead to positive change.

References and resources mentioned in the show

· Daniel Pink – When: The Scientific Secrets of Perfect Timing

Want to get involved?

This show is designed for you, and we’d love your input.

● Enjoyed what you heard today? Take a second to leave a rating and a review. It really helps, and we read every single one.

● Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Julie Chickering is a certified Scrum Trainer as well as a CST, PMP, PMI-ACP CSM, CSPO, and Path to CSP Educator. She believes that Agile practices are packed with potential - to enable business agility, and breakthrough results. Julie loves to help people implement agile even when the environments are messy, people are complicated, and situations are challenging. She brings real-world experience working with people at all levels to adopt and roll out realistic Agile strategies organization-wide.

#6: How to make the Daily Scrum more effective with Julie Chickering

29 juni 2022 | 55 min

This week, Brian Milner is joined by Julie Chickering to talk about the best practices and common pitfalls to avoid during the Daily Scrum event.

Overview

Brian Milner and Julie Chickering discuss the true purpose of the Daily Scrum and how to make this 15-minute meeting more efficient.

According to the Scrum Guide, the Daily Scrum is to inspect progress towards the Sprint Goal, synchronize activities, and create a plan for the next 24 hours. Debunking the myth that “The Daily Scrum is a Status Meeting”, Julie and Brian share their first-hand experience of this misconception and show Scrum Masters how to transform the Daily Scrum into a purposeful and collaborative planning session led by the Developers, for the Developers.

You’ll learn how to get your Daily Scrum under control and discover new approaches to encourage productivity, accountability and collective ownership as well as Daily Scrum formats that encourage teamwork.

Finally, Brian and Julie dive deep into the struggles brought by remote working and the many alternatives to tackle this issue.

Listen now to discover:

- 02:00 - The purpose of the daily scrum and common misconceptions

- 11:00 - How to use the sprint backlog to prioritize work

- 00:12 - The importance of teamwork and striving for smaller stories that flow

- 14:56 - How to encourage developers to take ownership of the Daily Scrum

- 00:20 - Suggestions for Daily Scrum formats to encourage teamwork

- 00:22 - When to update items on the Sprint Backlog to benefit the Daily Scrum meeting

- 00:25 - How to encourage accountability and collective ownership of work

- 00:27 - How to monitor and assess unplanned work and forecast velocity

- 00:35 - Guidelines for problem identification and problem solving during the Daily Scrum

- 00:38 - How to adapt the Daily Scrum for distributed teams in a remote world

- 00:44 - The benefits of cross training

- 00:45 - The 16th minute concept

- 00:47 - Ken Schwaber’s clockwise scrum methodology

Listen next time when we’ll be discussing...

Julie joins Brian again to explain the true purpose of the Sprint Review and why it is a mistake to call this event a ‘demo’.

References and resources mentioned in the show

· Agile Project Management with Scrum by Ken Schwaber

· The Scrum Guide

Want to get involved?

This show is designed for you, and we’d love your input.

· Enjoyed what you heard today? It would be great if you left a rating and a review. It really helps, and we read every single one.

· Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

#5: Scott Dunn Shares Everything You Need to Run Sprint Planning

22 juni 2022 | 44 min

In this episode, Scott Dunn and Brian review the key aspects of leading an effective sprint planning meeting: its purpose, how it works, who attends, and ensuring yours are achieving the desired result.

Overview

Brian Milner and Scott Dunn discuss product ownership and leading a sprint planning meeting. 2020’s Scrum Guide introduced new guidance: sprint planning must go beyond the WHAT and the HOW of product backlog items to the WHY, specifically why is the sprint valuable?

Scott shares his firsthand experience of how to run an effective sprint planning meeting, including focusing on the ‘Why?’ plus practical advice on increasing an agile team’s motivation and engagement.

You’ll learn why the product owner-development team relationship is the linchpin of sprint-planning success and the primacy of preparation, forward vision, and a value-driven mindset.

Final advice includes better communication of expectations with distributed team members and aligning with the evolving nature of the tech landscape through trying new approaches.

Listen now to discover:

· 04:00 – How asking ‘Why?’ adds value and motivates, empowers, and engages teams

· 07:00 – Why the relationship between the product owner and development team is the linchpin of success

· 10:00 – What level of detail Scrum teams should be striving for during a sprint planning meeting

· 12:00 – The purpose of a sprint review and what needs to change in order to support inclusive collaboration

· 14:00 – How to leave room for discovery with minimal documentation

· 15:52 – How flexible requirements and ongoing conversation enable collaboration and employee engagement

· 17:00 – How to remain focused on driving value when facilitating sprint planning meetings

· 19:00 – The mindset shift required to define value through conversation and negotiation

· 21:30 – Craig Larman methodology - culture follows structure

· 22:00 – Why assigning work during sprint planning kills collaboration and team spirit

· 26:00 – The purpose of the sprint planning meeting and how to maximize the time allocated

· 27:30 – The restrictions of forward planning and how to find confidence in emergent architecture to align with the changing nature of tech organizations

· 30:00 – How product owners in sprint planning can improve efficiency through preparation

· 34:00 – Tips for distributed teams: adapting to remote working, improving communication, and more effective sprint planning

· 40:30 – The ‘Inspect and Adapt’ concept: the importance of trying new approaches and implementing new methods.

Listen next time when we’ll be discussing . . .

Daily scrums with certified Scrum trainer, Julie Chickering. You’ll learn the true purpose of this 15-minute time-boxed event as well as common pitfalls and mistakes to avoid in this meeting.

References and resources mentioned in the show:

· Larman's Laws of Organizational Behavior

· David Hawks

Want to get involved?

This show is designed for you, and we’d love your input.

· Enjoyed what you heard today? Take a second to leave a rating and a review. It really helps, and we read every single one.

· Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Show edited by Rhett Gill.

#4: The Developer Role in Scrum with Sherman Gomberg

15 juni 2022 | 49 min

Join Brian Milner and Sherman Gomberg for a discussion of the importance of a Scrum team’s developers and why self-organizing teams are at the heart of agile methodologies like Scrum.

In this episode of the Agile Mentors podcast, Brian Milner and Sherman Gomberg discuss the evolution of one of the Scrum roles: developer. They also explain why self-organizing teams of developers have become critical to all organizations.

On agile projects, developers are the people who “do the work” and while at first glance you may see agile developers as always engineers or other software development professionals, that’s not invariably the case. According to the Scrum Guide, the development team can be composed of all kinds of people including designers, writers, programmers, etc.

Using over 25 years of Scrum, agile, and project management experience, Sherman and Brian compare notes on the topic of how to build and sustain agile, self-organizing teams. They share their insights and advice on why empowering individuals to work in cross-functional agile teams leads to greater efficiency, higher rewards, and lower risks.

Listen now to discover:

- 03:38 –How to tell whether your agile team is self-organizing

- 05:25 – The advantages of having self-organized teams in agile environments

- 07:10 – Bruce Tuckman’s four stages of team development: Forming, Storming, Norming, and Performing

- 09:17 – Advice for Scrum Masters and product owners on how to promote self-organization among team members

- 09:60 – The parallels between software teams and sports teams: self-organize and work together to shine

- 13:34 – How and why to build a learning organization

- 18:00 – The definition of “self-managing” as cited by the Scrum Guide

- 22:00 – How to address bug-fixing and technical debt during a sprint

- 28:00 – The three most valuable practices adopted by developers in a sprint

- 37:50 – The importance of understanding the developer role and why all three roles on a Scrum team should take a Scrum developer course

- 40:48 – The role of a tech lead in Scrum

- 43:00 – Why it is essential to form a team of equals and how self-organization works to support this

Listen next time when we’ll be discussing…

Sprint planning with guest co-host Scott Dunn. You’ll learn about the sprint planning event as described in the Scrum Guide and the 3 essential “Why? What? How?” topics addressed in order to plan successful sprints.

References and resources mentioned in the show

● Scrum Guide

● The Bruce Tuckman Model

● The Agile Manifesto

Want to get involved?

This show is designed for you, and we’d love your input.

● Enjoyed what you heard today? Don’t forget to rate and review: it really helps!

● Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Sherman Gomberg is CEO at Scrum Adventures, Inc. He is a CTC and has a total of eleven certifications from the Scrum Alliance. He has over 25 years of experience with agile, Scrum, and project management across various industries. He enjoys working with teams during breakout sessions in online courses, where he helps to bring curiosity to valuable discussions and in doing so, moves the needle from training to knowledge obtained to knowledge applied.

#3: What Makes a Great Product Owner? With Lance Dacy

8 juni 2022 | 47 min

Join Brian Milner and guest co-host Lance Dacy to look at the key capabilities of the product owner, mistakes to avoid, and getting maximum business value from the resources available.

In this episode, Brian Milner and guest co-host Lance Dacy take a detailed look at the role of the product owner.

They discuss a common source of confusion about what a product owner is, or does: people try to boil down the role to its tactical processes—such as writing user stories. The product owner may be accountable for these processes, but providing direction for what the team is trying to accomplish is their forte.

Product owners need to be great communicators and collaborators, with passion for solving problems with their product. Brian and Lance share their experiences of what makes a great product owner, the importance of protecting a team’s capacity, and why saying no is often essential to protecting the vision.

Listen now to discover:

04:10 - What’s the difference between a product owner and a product manager?

07:25 - Henrick Kniberg’s criteria for successful product owners

08:57 - Why Scrum Masters focus on the how and product owners focus on the why

09:05 - What does ‘being passionate’ mean to a product owner?

12:48 - The mistake of trying to be too productive as a product owner

19:46 - Can you combine other roles with that of the product owner?

25:55 - What should you find out about a company before accepting a job offer as a product owner?

34:49 - Why one of the most important things you can do is act as a steward of the team’s capacity

Listen next time when we’ll be discussing…

A special bonus episode with details about Brian’s talks at the upcoming Scrum Gathering on June 6-8

References and resources mentioned in the show

Agile Product Ownership in a Nutshell - Henrick Kniberg

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.

Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Lance is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

Show edited by Rhett Gill.

Special Episode Scrum Gathering Denver 2022

1 juni 2022 | 27 min

In this special episode, Brian describes the upcoming Scrum Gathering in Denver, including the subject of his talks on the daily scrum and leadership styles.

The Scrum Gathering is happening in Denver on June 6-8, so in this podcast episode Brian discusses the conference and shares a preview of his two talks: one on the daily scrum and one on leadership styles.

In “Daily Scrums Suck: How I Killed the Daily Scrum and Replaced it with Something Even Better,” Brian shares his advice for making the most out of those 15-minute meetings. For his second talk, “The Opposite of Leadership: The George Costanza School of Agile Leadership,” Brian designed an interactive workshop to encourage you to turn your idea of leadership on its head to perhaps reveal a much better way to lead.

Listen now to discover:

02:33 - Daily Scrums Suck - a teaser about Brian’s first session

03:45 - The George Costanza School of Agile Leadership - details about Brian’s 75-minute workshop

08:33 - Why go to conferences? The value is often in the connections as much as the content

14:19 - If you have a Scrum Alliance certification, one conference can help you earn SEUs you need to renew

15:03 - How conferences can help you chart your next career steps

18:29 - The Coaching Clinics available at the event

19:25 - The Open Space - anyone attending can pitch a topic to talk about and Brian shares his tips for getting the best from this opportunity

21:38 - Introverted? So is Brian, but here’s how he survives a conference environment

24:55 - Planning to attend and want to meet Brian? Don’t hold back!

Listen next time when we’ll be discussing…

Join Brian Milner and Sherman Gomberg as they discuss the importance of the developer role within a Scrum team and why self-organizing teams are at the heart of agile methodology.

References and resources mentioned in the show

Global Scrum Gathering 2022

Brian’s Talk Descriptions

George Costanza turns his life around by doing the opposite

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.

Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenter is:

#2: Succeeding in the Scrum Master Role with Mike Cohn

25 maj 2022 | 35 min

Join Mike Cohn and Brian Milner as they discuss the Scrum Master role: its distinctions from project management, Scrum Master responsibilities for team success, and advice for new Scrum Masters.

In this episode, Brian Milner talks with Mike Cohn about the Scrum Master role from the inception of its title to the role it plays in agile today.

Mike Cohn has trained more than 30,000 Scrum Masters and shares his experience of the challenges he faced early on helping project managers to transition to effective Scrum Masters.

Brian and Mike discuss the distinction and overlap between traditional project management styles and the servant-leadership role of the Scrum Master. They also talk about how responsible a Scrum Master should be for the success of the project and the success of a team.

Finally, Brian and Mike share the advice they would give to Scrum Masters who want to be valuable to any team and organization—including those looking to get their first job in this role.

Listen now to discover:

02:14 - Why the Scrum Master title was created to help people succeed in this position

04:54 - Job role, title, or accountabilities? Is one more important for defining someone’s position in a Scrum team?

07:41 - The key differences between a project manager and Scrum Master

08:43 - How responsible should a Scrum Master be for the success of a project?

13:21 - Facilitator or leader? How not to fade into the background

17:46 - How to deal with people in power who make bad agile decisions

22:06 - Continuous improvement doesn’t mean you should play it safe

26:34 - How do you know when you’re ready to break the rules to be a successful Scrum Master?

27:06 - No experience and looking for your first job? What to do (and not do) to improve your resume

Listen next time when we’ll be discussing…

The product owner role with guest co-host Lance Dacy. You’ll learn what it takes to be a great product owner as well as common misunderstandings people have about the role.

References and resources mentioned in the show

Monty Python’s Dead Parrot sketch

Kaizen approach for continuous improvement

Lyssa Adkins Coaching Stances

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? Take a second to leave a rating and a review. It really helps, and we read every single one.

Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Show edited by Rhett Gill.

#1: Scrum vs Agile & Keys to Success with Mike Cohn

18 maj 2022 | 38 min

Join Mike Cohn and Brian Milner as they discuss succeeding with agile, including how to choose a framework, the best place to start, & when to break the rules.

In this first episode of the Agile Mentors podcast, Brian Milner and Mike Cohn explain why it’s important to understand and sometimes break the rules if you want to succeed with an agile approach like Scrum.

While the Scrum Guide states that the rules are ‘immutable,’ clinging to the rulebook mindlessly only holds you back. Instead, you need to know which rules Scrum teams can flex (and when), and which agile principles should always be adhered to.

Brian and Mike share their real-world experience of team members getting things right and wrong, and how you can improve your chances of making long-lasting change as you move to agile.

Listen now to discover:

05:12 - Why people still confuse the terms agile and Scrum
9:01 - How moving to Scrum changed (and improved) Mike’s traditional management style
10:51 - Which rules are OK to break, and how to know when to break them
13:51 - The daily scrum has to be conducted left to right…doesn’t it?
17:38 - An agile culture or agile practices? Which do you adopt first for a successful agile transformation?
22:19 - What do people need to get right for an agile transition?
24:15 - Does continuous improvement mean cross-functional teams are worked to death? (And a fight breaks out on LinkedIn)
30:03 - Of all the methodologies and agile frameworks you can choose (Scrum, Kanban, SAFe, extreme programming, etc) which one should you start with?

Listen next time when we’ll be discussing…

The history of the Scrum Master role, its connection to project management, and tips to succeed in this vital Scrum role.

References and resources mentioned in the show

Agile Project Management with Scrum by Ken Schwaber
Scrum Guide
The Princess Bride
The Agile Manifesto
The Karate Kid
Nameless Organizational Change: No-Hype, Low-Resistance Corporate Transformation by Glenn Allen-Meyer
Drive: The Surprising Truth About What Motivates Us by Dan Pink
Spotify Engineering Culture Part 1 and Part 2

Want to get involved?

This show is designed for you, and we’d love your input.

Enjoyed what you heard today? It would be great if you left a rating and a review. It really helps, and we read every single one.

Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected]

This episode’s presenters are:

Editing by Rhett Gill

00:00 -00:00