Agile Mentors Podcast from Mountain Goat Software

#160: The Real Work of a Scrum Master with Brian Campbell

What separates a solid Scrum Master from a great one? In this episode, Brian Milner sits down with veteran Scrum Master Brian Campbell to talk about the balance between being empathetic, staying grounded, and knowing when it’s time to move on.
Overview
In this episode of the Agile Mentors Podcast, Brian Milner is joined by longtime Agile Mentors Community member and enterprise-level Scrum Master Brian Campbell to explore the core skills every Scrum Master needs, beyond the textbook answers.
Drawing from 13+ years of experience, Brian Campbell shares how flexibility, empathy, and situational awareness help Scrum Masters navigate real-world team dynamics, conflicting priorities, and tough leadership environments. Together, the Brians discuss how to support product owners without overstepping, when to gently push back with leadership, and how to foster effective teamwork even under pressure. They also dive into what it means to advocate for your team—especially during crunch time—and how to know when it’s time to walk away from an unhealthy engagement.
Whether you’re just starting out or deep into your Scrum career, this episode is packed with practical insight from someone who's been there.
References and resources mentioned in the show:
Brian Campbell
Rescue Your Daily Scrum videos
#113: Influence Without Authority with Christopher DiBella
#126: Mastering the Scrum Master Role with Gary K. Evans
The Daily Scrum Meeting - a detailed breakdown
Subscribe to the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast 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.
Brian Campbell is a seasoned Senior Scrum Master with over 13 years of experience helping enterprise teams in healthcare, insurance, and tech deliver real results with agile. He’s known for his calm leadership, strong facilitation skills, and a flexible, coaching-first approach that meets teams where they are.
Auto-generated Transcript:
Brian Milner (00:00)
Welcome back Agile Mentors. We are here for the Agile Mentors podcast. I'm here, Brian Milner, and I also have with me another Brian. I have Mr. Brian Campbell with me. Welcome in, Brian.
Brian Campbell (00:12)
Hi. Nice to be on the podcast.
Brian Milner (00:13)
⁓ I was, yeah, we're really happy to have you here. I always kind of joke with, with other Brian's and, and, Brian is one of the other ones I can joke with here about this and say, thank you very much for spelling your name correctly. Brian is, is, someone who's a member of our agile mentors community and he's, he's shared a lot of really great, advice and he's mentored people through there.
Brian Campbell (00:27)
I do know people too.
Brian Milner (00:39)
So we wanted to highlight that, but he's an enterprise level scrum master. He's been doing this for a while. He's got over 13 years experience as a scrum master and has had some really insightful comments in our and post in the Agile Mentors discussion forums. We're going to link to one in particular that's really interesting that hopefully everyone here will find interesting in the show notes. But we talked about what we would. kind of dive into here and seeing as Brian has all this experience as a scrum master, we wanted to focus on some scrum master issues. in particular, one particular quality that Brian brought up that he felt was really, really essential, and I agree with him, for a successful scrum master, and that's flexibility. So maybe we start there and just define that for everyone. When you talk about how important it is for a scrum master to be flexible, What does that mean to you, Brian?
Brian Campbell (01:33)
Well, there's three things. You've got to work with a product owner at their level. So you may have a brand new product owner who doesn't understand how to construct a story with acceptance criteria or a bug with steps to reproduce. Other times you have a product owner who's really, really on their game and very established. And then you're going to be more hands off and just providing a little bit of guardrails according to the way the company works. You're going to be flexible with the daily standup. I've had teams rebel against the idea that standup has to be run cookie cutter scrum. So you may find that they prefer to go person by person. And that's fine. You may find they prefer to go issue by issue. You may find that you do it a whole section at a time. Dev, QA. going down a column on a board just to try and work with the team the way they want to be worked with. But my goal as a Scrum Master is to make it efficient and effective. I'm not trying to keep them sitting on a call for the sake of being a Scrum Master. But get familiar with how each company does things. Don't try to radically improve things. Suggest incremental improvements where merited. So don't come in guns a-blazing trying to change everything in the environment. Come in, observe for a while, make a little course correction here and there. Suggest things if they're above your station that might allow you to allow the teams to work more effectively. So those are three ideas.
Brian Milner (03:02)
Yeah, that's awesome. I agree with you on those. think those are really important. There's kind of this, starting with the last thing that you brought up there. There's kind of an idea that I've heard people say before. I've always subscribed to this as well. Kind of the evolution versus revolution kind of approach to doing things that you're going to be served better by trying to incrementally in small little doses change things rather than big bang. let's all of a sudden, Monday morning, everyone's going to be doing Scrum. It doesn't really work very well if you try to drastically change things. I know that's one thing with Kanban I've always appreciated is Kanban talks about start with where you are. And I think that's a good approach for us as Scrum Masters as well, is kind of start with where the team is,
Brian Campbell (03:31)
Yeah. Well, I've also done Kanban implementations and where people are doing scrim and they want to do Kanban and developers think there isn't a lot of, you know, I'm just going to be wild, wild west and do what I want. But Kanban has its own structure and way of doing things that you need to get the team, its own set of ceremonies, et cetera, that you need to get the team familiar with.
Brian Milner (04:06)
Yeah. Yeah. And you mentioned earlier as well, like trying to be flexible as you work with your product owners. I agree there as well. Product owners, you know, come in all shapes and sizes as far and all kind of levels of experience. maybe you'll get lucky and you'll have one that's really experienced and doesn't really need a lot of help. But maybe you'll get one that's brand new, that's never done this before. In which case you have to have a lot of patience and a lot of time to coach and help them get up to speed with what's really going to be valuable. Brian Campbell (04:38) Yeah, they need different kinds of support. I think the new scrum master may, new scrum master, new product owner may require, let's read, let's start that one over again. I think they will require different levels of support. The.
Brian Milner (04:48)
Yeah. ⁓
Brian Campbell (04:51)
the new product owner needs to have have stronger agile guard rails in place. The biggest problem I have sometimes is there's a product owner that's very set in their waste. I had one product owner who decided that he was going to map out all the work for this quarter and tell a sign by developer and even story point the items. And I had to go to management and say, Hey, this guy's bad. We'll get into that later. You have a time to move on thing. This was one of my times to move on because management was not supportive and changing his viewpoint. ⁓
Brian Milner (05:30)
Yeah. Yeah, I mean, that's part of just being agile that you expect the kind of same attitude towards being flexible from the product owner that, hey, you know, I'm going to grow and learn. And maybe that starts with kind of a humility of just saying, I may not be right.
Brian Campbell (05:49)
Yeah. I like to form a trika between, well, actually four people. I like to get the product owner, the dev lead and the BA all coordinating at the same time. So the product owner is not writing these stories blind. They're getting feedback from the dev lead and the BA. is learning how to support the product owner. It's kind of like that whole idea with Three Amigos where you get the product owner, developer and QA together and you just try and get them to work on an individual story. This is more like at the team level.
Brian Milner (06:24)
Yeah, if you do that, just have to make sure you don't kill the invisible swordsman, right? ⁓ Little three amigos reference for the listeners. Yeah, I agree. And I'm kind of curious there because you mentioned business analysts, mentioned dev leads, and that's always a hot button issue as well as we think about working with our teams because there's not really strong guidance from Scrum on
Brian Campbell (06:29)
That's it.
Brian Milner (06:50)
those roles and how they might interact or play with the Scrum team, what have you seen work well with those kind of roles?
Brian Campbell (06:59)
Just like I am an advocate for proper Scrum, know, agile guardrails, dev leads are people who have an ear towards the product owner and an ear towards the team. And if they had three ears, their third ear would be towards best practices in the company. So they have a very difficult job to wear where they're wearing, to do where they're wearing multiple hats. In terms of a BA, I think they just need to learn how the product owner thinks.
Brian Milner (07:31)
Yeah, that's good point. mean, they're assisting, they're alongside the product owner. it's back kind of like your three amigos reference, right? mean, it's somebody who should anticipate and assist and yeah, that's what I've seen work well also. Well, I want to talk a little bit more about the developer side of things as well, because they're the majority of our team. And if they're not working well, then our Scrum team is not going to work well. And that's always a fine line, I think, too. So I'm curious what your thoughts are here. It's always a fine line with how technical do I need to be? And how do I help my developers become the best version of a team possible without crossing over into getting into their realm and trying to tell them how to do everything?
Brian Campbell (08:20)
Yeah, I had an interesting lesson with the latter. think one of my first gigs as a scrum master, I was in a room full of people and there was a systems architect with all the developers doing something on a whiteboard. And I said something and they went, you're here to observe. And it taught me that there were boundaries. And on the other hand, there is something you can and should do, which is Try to have enough familiarity with what the team's working on and the other teams involved in the project to where you can anticipate what's coming down the line. try to, if you're trying to anticipate that you're forming good connections with the other teams and their product owners, you're forming maybe even with their BAs, and you're trying to make sure that the dependencies are addressed before the team comes to the work would be a really good example of that. So what else did I, I wrote some notes here because we went over the questions. ⁓
Brian Milner (09:22)
Sure. Yeah, you brought dependencies. I agree, the dependencies are kind of a huge area for teams and they can be a team killer, they can be a productivity killer. I know there are people who are focused really, really huge amounts of attention on how do we reduce our dependencies and how can we make our team more independent. So I think you're right, that's a huge key to unlocking the team's speed and productivity is just, you know, how can we have as few dependencies outside our team as possible?
Brian Campbell (09:58)
Well, that's true, but at the same token, you're going to have, for instance, if you've got a systems team, you're going to have dependencies with them. Right now I'm working at a company where there's a team that does, they're moving off a legacy system, they're moving on to a new system. So they have to sync the data with the old system coming out of the system, going back into the system. And there's a team that specializes in that. There are teams that specialize in different aspects of the system. They all come back to the team that synchronizes stuff in and out of the system. So there going to be dependencies from time to time, but you have to have a good working relationship with both, with any of those teams. you know, the idea is you get ahead of when the need is so you don't disrupt that other team and their work.
Brian Milner (10:49)
Yeah, I agree. I don't think you can ever really truly get rid of every dependency that you have. I think that's kind of a fantasy, but you you can you can try to limit them. You can certainly try to eliminate the ones that you can and then then try to just realistically handle the ones that are remaining. Right. Yeah. That's a great point. So the other area I was kind of curious to talk to you about is is the area of working with with leaders, because that's always a huge
Brian Campbell (11:06)
Right. Right.
Brian Milner (11:17)
hot button issue for us as Scrum Masters. I know there's been lots of surveys and things that have been published in the past saying that that's one of the kind of determining factors of whether it's going to be a successful adoption of these agile values and principles or not is whether the leaders are behind it, on board, supportive. But you know. I'm sure you've had the same experience I have. There's degrees. I've never had 100%, but there's been times it's been more than others. What do think the Scrum Master's role is in then working with leadership?
Brian Campbell (11:54)
they're going to set a tone and you need to work within the tone and realize that especially if you're in a contract job, you're not going to effectively facilitate change at a VP level, for instance. You're going to have to understand their paradigm and work within it. think you can advocate for your team, but often you'll be advocating across multiple teams. see a pattern, again, goes back to understanding more than just your team. You may be advocating for a pattern you see across multiple teams. And then you come at it from a suggestion that would be in their best interests or in the interest, usually in the interest of getting the project done on time. But I've had good leaders, I've had bad leaders. I think about three or four years ago, I was working for a company where There was a very, very good VP in charge of development and all of a sudden he was replaced by a guy that turned the company into a meat grinder and he was very difficult to work for. Well, you I think, I think that's a, you're, just have to understand what the leader wants and try and, try and mold to their vision along with those agile guardrails.
Brian Milner (13:13)
Yeah, I agree. mean, I think what you're kind of saying there is really important to, especially in light of the topic here across everything we're talking about, being flexible, of just trying to understand that there are things that you're not going be able to change, right? Sometimes you're going to have leaders that are kind of set in a certain way of doing things and you know, they're not going to be open to having, intellectual conversation about, whether there's benefits to doing things a different way. And should we examine it? They're just going to want it done a certain way. And when that's the case, I think the word flexible is, is the right one there to say, look, I have to recognize what's within my control and what's, what's not. And if these things are not within my control, then
Brian Campbell (13:53)
Yeah.
Brian Milner (13:56)
Yeah, how do I find the best compromise that really gets closer to what it is we're trying to do here?
Brian Campbell (14:02)
I think one thing that's really important to remember about that is you have to have empathy for the pressure they're under. And that goes for senior leadership, that goes for your lead developer, your product owner, to a lesser extent your business analyst. I think they're all under different kinds of pressure and you have to empathize with them. I think one of the biggest things that a Scrum Master can do in their role is have empathy.
Brian Milner (14:30)
I agree. I think that's such a huge point. Not only from just trying to think about and feel what might be important on their end, to then also try to speak at a level with them that connects and resonates. Because if you understand what's important to them or what kind of pressures they're under, what kind of strains and what they're trying to accomplish as a result of that, then as you present some of these things, you can put it in a language that might be more impactful and resonate with what they're trying to accomplish. ⁓
Brian Campbell (15:04)
Yeah, you're going to be a more effective communicator if you speak in terms of what they want to do or need to do.
Brian Milner (15:11) "Yeah, it's a tricky thing and I agree. It's sort of like there's leaders within the company and then there's subtle ways we can spread and help to populate the organization with these ideals. So we have a role there as well as leaders to try to. try to help people understand why this is important and kind of the benefits they might see from it.
Brian Campbell (15:34)
Yeah, especially the team members.
Brian Milner (15:36)
Yeah. Well, I know another big area we talked about that we were talking about being flexible and, you know, important area to consider as a scrum master is kind of the whole dynamic of working on a team of teamwork. And there's a lot that comes along with that. I know one of the things we talked about was just kind of the whole concept of how you help your team with conflicts and how you help them to learn how to compromise on things. What kind of things have you seen, what kind of tips have you collected through your years on how to help your team through those sorts of issues?
Brian Campbell (16:16)
It's important to have an ear with a team to be able to hear when they're having a problem and try to connect them with the right person to solve the problem. You're not going to be the person that solves the problem majority of the time. You're going to be the person that facilitates the connection to get the problem solved. So it's another form of advocating with the team, but that's probably the best approach that I would recommend to people.
Brian Milner (16:46)
Yeah, that's such a hard thing to do. And you're absolutely right. It's just so hard to, you know, a lot of times we just want to fix things. You see a problem, you know a solution, you just want to fix it. And, you know, we can do that on occasion, but if that's what we're doing as a majority of our job, then we're not really, as you said, making those connections that would then enable it to happen. on an ongoing basis, not just a one-off.
Brian Campbell (17:18)
But it's important also to remember that sometimes a team will have a gripe and it's something that can't be changed. So you have to, especially in a retro, you kind of have to work with them to find the solution that works within the framework or the environment they're in. Both are important.
Brian Milner (17:35)
I've had some experience in this area as well. And I know this is one of the things I talk about in classes because it's kind of a personal thing to me with how I've worked with teams. I'm just curious, Brian, have you had some really hairy conflicts on your teams, some really kind of bad blood between different members of the team? And if so, how have you handled that?
Brian Campbell (18:04)
Um, I think my favorite example of that, I was working for a company. were rewriting all the systems, the main part of the business and everybody was under a lot of pressure. And at one point I got pulled into a meeting where, um, the, this was during the pandemic, so everybody was on zoom and I got pulled into a meeting where the product owner was at loggerheads with the lead developer. And my job became one of being a mediator to make sure both of them were heard, to make sure that they felt their points were valid, but then to guide them towards a place where they could work better together. And I like to think at the end of that conversation, it's a working relationship, but it was very touch and go. That was a very, very difficult project.
Brian Milner (18:59)
Yeah, that's such a great story because it's a tough thing. I know, we talk about empathy. I empathize with all the scrum masters out there that find themselves in those positions because I've been in that too. And I'll be the first to admit, I haven't always handled those situations so well. Sometimes I've left it up to them to try to resolve and have had bad consequences as a result. But I think your approach there, Brian, is absolutely the right one to take. It's not fun to dive into the middle of two other people's conflict. No one would do that naturally in life. It's just something we'd try to, you hey, that's their thing. I'm going to leave it up to them. But when we're talking about our team, I mean, we're kind of framing this part of this in the frame of teamwork. That's kind of the concern, I think, when those conflicts start to become really bad. Well, how is that going to affect the team? It may just be those two people, but it's not going to stay those two people. It's going to spread. It's going to get wider in the team. your approach of kind of just, hey, I'm going to roll up my sleeves. I'm going to get in the middle of this with you. And it may not be fun, but I'm not going to abandon you. I'm here with you, and we're going to find our way through this.
Brian Campbell (20:09)
It is really important that both sides feel they're heard and that both sides understand the merit of what the other side's saying from a third person.
Brian Milner (20:19)
Yeah. Such a great point. And isn't it amazing how sometimes that's really all it takes? Sometimes it just, people need to feel like they were heard. That they're not being, their point isn't glossed over. That we've really heard their concerns, we've processed it, it's been considered. And it's such a defeating feeling when you feel like that doesn't happen, when I'm not being heard. So you're absolutely right, I agree with that. One of the other things that we touched on and talked about in this section was the whole idea of navigating the thing that none of us wants to navigate. That's when we're in that crunch time mode for projects. I remember being told early on as a developer, hey, everyone works nights and weekends in crunch time because that's just part of the industry. You just have to be ready for it. How have you handled and helped the team navigate some kind of crunch time moments?
Brian Campbell (21:12)
Well, first of all, you leave with empathy. Uh, I remember going into a big project that I had a lot of experience with this kind of thing, but the team and I said, things are going to get really crazy and very disheveled. And I just want you to know I'm here to support you, but don't be surprised if you get a lot of curve balls turn along the way. And I remember the business analyst thinking I was absolutely crazy, but. especially with large enterprise projects, there's going to be crunch time. you're going to be the person who kind of soothes nerves a lot like that confrontation we talked about earlier. You're going to be the person who lends an empathetic ear but maintains agile guardrails to make sure a process is being dealt with correctly, but not being an agile Nazi either. I think those are all really good things. Again, you want to keep meetings efficient and minimize the team from being, minimize wasted time and also minimize distractions because the team's got to be heads down during those times. And you've got to be really proactive about forging connections and getting familiar enough with what they're doing that you can foresee when there's going to be an issue.
Brian Milner (22:35)
Yeah. Yeah, that's such a good point. Yeah, it's not a position you want to be in, but it does happen, even in agile projects. You do find from time to time when you just are kind caught in that crunch time moment. when that happens, I love your approach of being empathetic with the team also. But it's sort of. I was kind of thinking, well, how can I serve the team through this? know, like they're going through a tough time right now. It's not fun. How could I make it easier? You know, what's something I could do? Can I hop in there and do something that maybe grunt work that no one else wants to do, but it doesn't take a lot of brain power. It just is going to be time consuming. Can I? go buy lunch, can I bring coffee? Things that I wouldn't do on a normal basis, but they're in a unique position.
Brian Campbell (23:25)
⁓ Yeah, I've done those things. Although I had to say that there was one company I left shortly after this. But there were two teams of developers working on a project for three months. And of course, because they were not doing agile correctly, there was no feedback from the stakeholders during that period. So they dropped this project in the lap of the stakeholder. Stakeholder doesn't like it at all. teams given two weeks to correct the flaws. And unfortunately, there are a bunch of people on H1B visas. So if they don't like it, they can get on a boat and go home or a flight. And it's more modern nowadays. But I remember working two weeks, nights and weekends with them. And the only thing I was allowed to do was bring donuts in the morning. And it was
Brian Milner (24:20)
Ha
Brian Campbell (24:23)
extremely frustrating to have my hands tied like that as the Supreme Minister.
Brian Milner (24:27)
Yeah, yeah, it's, it's, it's bad too, when it becomes the expectation. Hey, where are the donuts today? you know, that kind of thing. you know, I think there's, there's a middle ground and there's somewhere to say, Hey, if things are tough, I can do that without it being the expectation. I can find ways to kind of make life better for them, to help us get through this. Yeah.
Brian Campbell (24:47)
yeah, you should always be advocating for the team. ⁓ Even when they're beat down, you should be saying, we're under a lot of stress right now. What can we do to make things easier on the teams that already having enough problems without us making it harder?
Brian Milner (24:51)
Yeah. Yeah. Yeah, well, I want to kind of get and bring us around a little bit full circle here because you referred to this earlier. And I think it's an important thing for us to talk about in this section as well. And that's kind of, there are times when it's time to move on. And maybe the best thing I can do for the organization, for the team is to move on. So. I guess the question then is how do you know that? How do you know when it's time to maybe pack up and find somewhere else?
Brian Campbell (25:41)
I think the example I just gave is a really good one where they were being asked to work insane hours. And I had been on prior projects with this company where one example they had given me, a team with five developers and no product owner. And I worked around that by having the team write the stories. I didn't even have BA. It was really, really difficult. And I ended up advocating for them when they didn't have enough testers. It was just a real nightmare. And then they put me on this other team that was given two weeks to do probably two months worth of work. At that point, I didn't like the way they were treating the teams. And I said, OK, it's time to move on. Luckily, the company that I moved on to was three floors above where I was working, so that made it really easy transition. There was the meat grinder mentality, when it went from being a good environment to a meat grinder, disposed company for meat grinders. And then there was another example where they wanted the scrimmasters to take on project management duties and I was already in this case. They had given me a 25 person team, which we broke into five teams and we had, we had kind of made it so that I taught the lead developers and all the schemes, to facilitate the daily scrum. And we all came together right after that for a scrum of scrums. And they wanted me to throw project manager duties on top of that. And that was like, I don't think that's a feasible thing for me to do so I kind of kind of stepped away from that job
Brian Milner (27:18)
Yeah. Yeah, I think there's moments like that where you just have to look at things and say, I know I've had moments where I've had to look and just say, I'm not going to be of any help. You know, with with kind of the things I do well, and the direction this organization is going in, I don't see how I can come alongside and really help them because they're headed the other direction. ⁓
Brian Campbell (27:41)
Yeah.
Brian Milner (27:42)
And if that's the case, I don't want to tell them, hey, the whole organization has to change and come around to my way of thought. That's not going to happen. Mike tells a story. Mike Cohn tells a story about even experiencing this as a trainer of going into different places and private companies hiring him to come and train and him experiencing things while training. that he just realizes, hey, no one's going to, nothing's, this isn't going to make an impact, right? Either the culture here is everyone has their laptops open and they're all doing their emails the entire class anyway, or, you know, they just say, well, we're not doing that. We're not going to be able to do it that way or something. And at a certain point, you just have to say, well, then I don't want to waste your time.
Brian Campbell (28:25)
Yeah.
Brian Milner (28:25)
I'm wasting your time and it's wasting my time and it's not helping anything.
Brian Campbell (28:31)
Yeah, I actually was at that same company that had, you know, no product owner on one team and developers working two months for their work in two weeks. They were doing scaled agile. So they had a scaled agile scrum master class where they invited a bunch of people from all over the company. And all they wanted to do was gripe about how they really didn't want to move to agile and how horrible it was and how they wanted to do things the way they've always done them. And the facilitator had lost control of the room and I had to, I had to subsequently go study to get my certification with them on my own because it was so incredibly off the rails. But yeah, I've been in environments like that.
Brian Milner (29:17)
Yeah. Well, this has been great. I really appreciate the topics here. And I appreciate your approach to this, Brian. I think that it shows your years of experience, just that especially the initial thought seems to always be one of, let me try to have empathy for the. the person in the other shoe and lead from that standpoint, right? Try to understand them at that level. So I appreciate you coming on and sharing this information. Any kind of key takeaways you'd leave everyone with here?
Brian Campbell (29:49)
You do want to leave with empathy, but you want to have firm guardrails, like I said. Sometimes they, particularly in crunch time, they want to bend the rules. ⁓ So that's one thought. But the other thought is support your product owner. They're already under enough pressure. Maybe it's as simple as
Brian Milner (29:59)
Yeah.
Brian Campbell (30:10)
making sure that the tags on the stories are correct or making sure that, I mean, if you're in person, making sure that you show up for meetings on time and that you corral the troops, you know, make it easy on the product owner because they're under usually quite a bit of pressure. And that's probably one of the bigger ones too.
Brian Milner (30:32)
Yeah, that's a great point. Well, Brian, thank you so much for your time. I appreciate you making time for this and coming on and sharing your wisdom with us and kind of helping us to see from a different perspective a little bit about what it's like to really be out there and working as a Scrum Master today. So thanks for your time, Ryan.
Brian Campbell (30:50)
Thanks, it's a pleasure being on the show.

#159: Is Scrum Really Too Many Meetings? with Lance Dacy

“Too many meetings” is one of the most common complaints in Scrum teams, but is it really the meetings, or what’s (not) happening in them? In this episode, Brian and Lance Dacy dig into the events of Scrum to uncover what works, what doesn’t, and how to make each one actually add value.
Overview
In this episode of the Agile Mentors Podcast, Brian Milner welcomes Certified Scrum Trainer and Mountain Goat colleague Lance Dacy for a breakdown of the four main Scrum events, and why so many teams struggle with them.
They tackle one of the most persistent frustrations teams face: the sense that Scrum has “too many meetings.” Together, they explore how to reframe these as working sessions, clarify their purpose, and avoid the common traps that drain time without moving the work forward. From sprint planning that skips the plan to daily scrums that lose their rhythm, this episode is full of specific guidance for getting more value out of each event. Plus, hear why retrospectives and backlog refinement are two of the most underrated (and powerful) drivers of team improvement.
Whether you're new to Scrum or looking to reset a struggling team, this conversation will help you re-center on what the framework is really designed to do, and how to help your team do it well.
References and resources mentioned in the show:
Lance Dacy
#138: The Bad Meeting Hangover with Julie Chickering
#156: Making Product Ownership Work in Shared Services with Kert Peterson
Does Scrum Have Too Many Meetings? By Mike Cohn
What Happens When During a Sprint By Mike Cohn
Scrum Activities: An Overview
Working on a Scrum Team Course
Subscribe to the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.
Auto-generated Transcript:
Brian Milner (00:00)
Welcome back Agile Mentors. We're here for another episode of the Agile Mentors podcast. I'm here as always, Brian Milner, and I have with us friend of the show, once again, Lance Dacy with us. Welcome back, Lance.
Lance Dacy (00:12)
Thank you, Brian. Glad to be here.
Brian Milner (00:14)
Always happy to have Lance on. we thought we'd have Lance on. We were kind of doing this thing at Mountain Goat. We're getting ready for the launch of a new course here that's called Working on a Scrum Team. And Lance and I are going to be two of the people that teach that course. And it's going to deal with a lot of like basic stuff that the teams deal with, common problems, common issues, and really how to work together well on a Scrum Team. And one of the things that we always hear questions about is about the meetings themselves. There's kind of three core components there for the Scrum framework. There's the roles, the events, and the artifacts. And so the events, the meetings are one of the biggest kind of focal points. And there's lots of questions about it. So I guess let's kick it off that way, Lance, and just say, what do you most hear? people complain about when they talk about scrum meetings.
Lance Dacy (01:06)
Well, that's the big thing, right? It's like we call them meetings. And the first thing I like to do is try to explain to them that there really aren't meetings, right? So when you hear the idea that you're going to go to a meeting, that's not very exciting, right? You're like, I'm to sit there and not get a lot out of this. So what I would like to say about the, working on a scrum team, I'm going to say it's probably the first course I ever taught as a scrum trainer. And we've been actually teaching it for a very long time. It's mainly just a private. you know, that we go into organizations and help them learn this. So I'm super excited that we're making this available publicly because so often people say, well, I'm a, you know, I'm not a product owner and I'm not a Scrum Master and I want to learn more about Scrum and I don't want to kind of bend to one role. So I am just shouting for joy that we have this one now. And I really hope that a lot of people will benefit if you're a stakeholder or if you're a manager or leader or things like that. A lot of times you have to pick and choose, you know, which class you're going to go to. So
Brian Milner (01:49)
you
Lance Dacy (02:00) "That's one thing, but it helps us address this idea. We kind of talk about it in Scrum Masterclass where people are like, well, we're practicing Scrum now, and now I feel like I got to go to all these meetings. Okay, well, first of all, they're not meetings. Let's get that out of the way. Let's quit calling them meetings. You called them events. I think that's an appropriate term, but I like to call them working sessions. No matter what process we use, you are going to have to get together with your team and collaborate on how we're going to approach building this thing. You have to collaborate on
Brian Milner (02:11)
Mmm. Hmm.
Lance Dacy (02:29)
understanding the needs of the users. Like that doesn't go away. Regardless of the process you use, Scrum just tries to focus us and allow us to get together in specific checkpoints throughout the process. And so if you boil it down, the Scrum framework itself has the four events of sprint planning, daily Scrum, review, retrospective. And then we have this activity, product backlog refinement, which if I had to choose... One of the top two problems with Scrum teams is we don't spend enough time doing product backlog refinement. So a lot of teams even misunderstand what that is. Is that a meaning? Well, not always. It's an activity as well. So I think probably some of the biggest complaints we hear about Scrum as we go to all these meetings. And so I typically like to advise people, you know, if you're going to implement Scrum, get rid of all the other meetings first. Okay. So you're going to do Scrum and
Brian Milner (03:16)
You
Lance Dacy (03:19)
We're gonna do sprint planning at the beginning of a sprint. Every day we're gonna check in on how we're doing against the work that we've collectively decided we could do. We're gonna show our stakeholders at the end and then we're gonna meet at the end and try to figure out how we can get better. There's nothing inherently wrong with that if you don't call it a meeting. Like plan the work we're gonna do for the next, let's say two weeks. Every day check in on it. Show our stakeholders at the end, is this what you wanted? And then what's wrong with getting together and saying how could we do better next sprint? Okay, so get rid of all the other meetings and try to build it into that cadence, if you will. Now, the other side to that is you're going to also have to get together and do backlog refinement, which is estimating, breaking large items down into smaller items. You're going to have to do some level of design on these items. And then, of course, adding clarity and detail to the work items is another big aspect of that. So those aren't meetings. Those are working sessions. So. When I hear most people complain about the scrum meetings, get rid of everything else, only do these. You're going to have to spend that time anywhere, anytime, know, whatever process you use. And if you want to get into the numbers, you know, I hear managers all the time or project managers going, I've got 12 people on a team and they're going to spend, you know, let's say a two week sprint maximum time box for sprint planning is four hours. And that's multiplied by 12 people. That's a terrible amount of time. It's like, yeah, but if you start doing all the math, And you spent the maximum amount of time, which we always would want to lead and coach and train them to spend half of that eventually. But you may have to spend all that time at the beginning, but you don't spend more than that. So, sprint planning kind of just boils down to about 5 % of a 40 hour work week for two weeks, daily scrums, about 3 % sprint reviews, about two and a half percent retrospective 2%. And so that's a total of about 12 % of your collective time going to these scrum events. Now. I would pay that any day if it's going to save us some mismatch, you know, further down the road. So that's really what I like to boil it down to is these are not meetings, first of all, they're working sessions, and it's not as much as you really think it is. So what do you think?
Brian Milner (05:17)
Yeah. Yeah. No, I agree. mean, I hear people say that all the time that there's, why are there so many meetings? And I mean, I think when people say that it's usually one of two kind of core reasons why. One is maybe they're doing it for like four or five teams. And if that's case, yeah, that's a lot of meetings because you're not meant to be on four or five teams. You know, that's kind of the your problem isn't the meetings, right? Your problem is something else. But the other thing I think is, I think it really can feel like there are more meetings than there are when the meetings don't really accomplish the purpose or the people don't really understand the purpose of why they're there. ⁓ Right, they're ticking a box.
Lance Dacy (06:16)
They're ticking a box, right? They're saying, well, we went through this meeting.
Brian Milner (06:19)
Yeah. I mean, and when you do that, just feels like it does feel like a drag. feels like just a, you know, a beat down, you know, that happens over and over again. It's funny that you put that about 12%. I was trying to do the math in my head and I just, I roughly kind of thought, well, what did I do last time I was a scrum master? Yeah. We would, we would have like half a day of the first, if I have a two week sprint, we'd have half the day, the first day in sprint planning about, or maybe not even half of it, right?
Lance Dacy (06:48)
Right. When you get better, it's less time, right?
Brian Milner (06:50)
Yeah, right. We would have a portion of the morning of the last day being a sprint and review and a portion of the afternoon being retrospective. But even if you made that just the whole time, mean, the maximum that you could even add that up to if you had tried to squeeze in those daily scrums as well would be 20%. But even at that, would say, you know, compare if you're not doing scrum. Compare what percentage of your times in meetings now. And I guarantee you it's more than 20 % of your work time over two weeks that you're in a meeting. ⁓
Lance Dacy (07:15)
Right? Well, you also have the context switching, right? If you're not doing it in a more focused event like Scrum, you kind of have more probably interrupt. I, you know, I think that's such a great point to make when we're teaching people this, which we kind of talk about this in our class as well. But we try to encourage people to not think of it that way as a meeting. It's a working session. It's a collaboration session. Cause I hear all the time, you know, developers will say, I don't want to go to sprint planning. I just want to get in there and start coding. I'm like, code what?
Brian Milner (07:47)
Yeah.
Lance Dacy (07:49)
What are you going to code? I mean, what if you went in there and coded a thousand lines? It's all incorrect. Is that helpful? No, it's not helpful. So I find let's help the teams learn how to translate time because they're always sensitive to it, to ROI, not a cost. So every event that we typically have in Scrum is what we would call a scheduled inspect and adapt loop, right? That's really what the three pillars of Scrum, inspection, adaptation, and visibility or transparency. So those loops are what tries to help us, you know, slash up the rework that might happen later or missed requirements or delay costs. So the real hidden meanings that devour our calendars, Scrum is going to give us a little bit more thoughtful way to do that. And, you know, there was a study out there, actually, Jeff Sutherland did a study, I think it was back in 2024, and he found that teams who hit each time box saw about 32 % fewer unplanned meetings and a 27 % drop in defect work. Now with numbers, you never know, you I'd have to go read, where did he get these numbers at? But I just think it's curious, an argument to make with that. And so you can invite leaders who are saying this is too many meetings to do a, you know, like a cost of delay experience to say if a 15 minute daily scrum saves even one developer from being blocked for half the day. we're already net positive on meeting time. So how often does that happen in the world? And that kind of turns it around from time to flow and ROI and all that. So I think making those metrics visible is important to especially leaders and managers who kind of balk at, my gosh, my people are in these, all these meetings and they feel like the only way to be productive is hands on a keyboard. So. In our working on a Scrum Team class, we get to kind of broach that not from any particular role and just say, celebrate that. Don't be mindful of that as we go. know, obviously the CSM course, we would try to talk about techniques on how to mitigate it. But that to me is one of the biggest issues is this notion that meetings are not a good thing to be in.
Brian Milner (09:36)
Yeah. Yeah, yeah, I agree. Well, let's step through the four main meetings. This is always a trick question too. I tell people in class, if you are answering a test, there's actually five events in Scrum, but the fifth one is the sprint itself. So we're not gonna focus on the sprint, but we'll talk about the four here. Just at least hit them. and talk about some of the bigger issues that we've seen in them. So let's start with the one that sets it up, sprint planning. Like you said, I think one of the kind of chief things to think about here is if you don't do this, how are you solving that purpose of knowing what it is we're gonna do? But what do you think some of the biggest mistakes people make are in trying to do a sprint planning session?
Lance Dacy (10:30)
Get in and out of it very quickly. That's the biggest mistake. I typically like to teach, know, sprint planning is really, we could use all the scrum terminology, but we are trying to co-create and forecast work that the team believes will accomplish the sprint goal set forward by the product owner.
Brian Milner (10:32)
Yeah. Yeah.
Lance Dacy (10:48)
and then devise a plan on how to get there. So we typically think of sprint planning in three parts. And I think that's the big mistake is they just want to get in there and say, well, we do 20 units of work a sprint, pull in 20 units, eyeball it and off we go. No, no, no. Product owner needs to kick us off and say, here's the focus of the sprint. Here's why I want to run the sprint. That's our sprint goal. And a lot of people think, well, the sprint goal is just to get this work done. It's like, no, no, the sprint goal is to deliver something. that's a value somewhere. It doesn't have to be customer value. It can be any kind of value right there. So first of all, what is our sprint goal? Secondly, who are, you who's on the team? What are our collective capacity and skill sets? So what could we high level try to bring into the sprint from the product backlog to achieve the sprint goal? And then that third part is devising the plan for you. So, you know, the Scrum Guide kind of uses language like... The whole point of a sprint backlog is to have enough detail in the plan that changes in the plan can be detected every single day. So if you ask me what's one of the fundamental problems with sprint planning, is teams do not spend enough time doing that. So when they look at the, you know, let's say the daily scrum, its purpose is to inspect and adapt and make visible the sprint backlog. they don't have a good visualization of the plan. It's more of a stair step like burn down chart because they don't have enough detail to see changes every day. So I'm really a big fan of teaching teams how to take a product backlog item and break it down into, know, the product backlog item says what we need to deliver, but our sprint backlog is how to deliver it. So I use the example, I want you to clean my car, right? That's what I want. I'm going to give you acceptance criteria. I'm not going to tell you how to clean the car, but our team should get in there and say, okay, In order to get the car clean, we got to wash the car, wax the car, vacuum the car, do the wheels, clean up the trash in the car, open it. Those are all the things that we have to do. And to me, those should be like individual sprint backlog items that every day of the sprint, we can see how much of that are we getting completed or not. Lack of completion. So to me, that's really what it's all about is teams just thinking they're getting in there. check in a box saying, here's what we're going to do this sprint. It's like, no, here's what we're going to do. Here's how we're going to do it. we have, remember the last one a lot of people miss is that the collective team has a level of confidence that they can achieve it. So how do we know that if they haven't detected their capacity versus the skills and what skills are needed for the work that's brought in? So I think teams do a terrible job at that,
Brian Milner (13:07)
Yeah. I absolutely, 100 % agree. I think so much of the problems, not even just with sprint planning, but so much of the problems with just the making our sprint goal and other things in their sprint really can be focused back to this to say, did you spend enough time trying to fully understand the work? And if you didn't really spend enough time trying to fully understand what's gonna take to do this, yeah, that's a clear why. behind the reason that you weren't able to complete everything, because you kind of just rushed through it, right? You didn't really get to the, yeah, you didn't really get to the detailed level of what it was gonna take.
Lance Dacy (13:49)
and it's gonna cost you a lot. Yeah. And that's the whole point is teaching them that's going to cost you later. So yeah, this time we're spending upfront, what if it saves us a lot of this other rework that we're going to have later in the sprint? I just don't know why people can't think about that. And, know, with, with any kind of agile process in particular scrum, we're doing progressive planning, which means we've got to be comfortable with ambiguity all the way up until delivery of the thing. You know, we may not know everything until it's actually done. And that's usually the case, but so you got to be comfortable with ambiguity, but at the same time, Are you learning enough about the work to feel comfortable with that ambiguity? You know, it's like, what level of confidence do we have that we've kind of thought through a lot of these things? It'll never be everything really, but why not spend the time that's built into your velocity? You know, it's like, if you're tracking how much work you get completed and you're spending time doing these things and your velocity is already accounting for this stuff. So go ahead and celebrate that, you know.
Brian Milner (14:28)
Right. Yeah, I think this is also a clear indication. When people ask sometimes, well, what does the scrum master do? You when you hear about a meeting like this, the sprint planning, and we were saying, you you need to spend enough time that you fully understand the work. How can we be sure they've spent enough time really fully understanding the work? Sure would be nice if you had a coach that could help them understand that, right? That's what the scrum master should be doing. So if you're kind of skimping on, is that skimping? Skimping? Skimping. On the Scrum Master role in general, then that might be even the source behind this is that they're not doing very well with the sprint planning session because they don't have anyone that actually knows what a good sprint planning session looks like to help them even get through it.
Lance Dacy (15:14)
Skipping by we'll say it is somebody Right. I mean, I tell, I coach people on sprint planning all the time. They're like, my gosh, that's too much work. Too much work. I mean, half the work is understanding what you need to deliver. mean, everybody just kind of seems to think that, especially in technology, if my hands aren't on a keyboard and I'm not writing code and testing code, I'm like, what if the hour long session we had with eight people in a room told us we didn't have to write any code at all? That reduces complexity of the product and.
Brian Milner (15:40)
you
Lance Dacy (15:59)
less things we have to test. I just feel like we're narrow minded when it comes to that. And I try to tell teams all the time, the litmus test of success to me on sprint planning is that everybody on the team can articulate why the chosen backlog items move the product closer to the overarching goal. But how often do we just glaze over the sprint goal and the product goals? It's like, you you hear people all the time. The goal of this sprint is to get these eight backlog items done. That's terrible.
Brian Milner (16:25)
Yeah, yeah. Well, we could park on this the whole episode, but we do want to try to make it through the others as well. So let's go to the one that the only repeating event that takes place in Scrum, the Daily Scrum. What have you seen as being some of the biggest problems with this meeting?
Lance Dacy (16:30)
Right. Well, I mean, I think we could probably placate this one and say, most of the time people turn it into a status meeting. Okay. Okay. I agree with that one that Scrum says that the daily Scrum is more about the team collectively assessing the progress or lack thereof the sprint. Well, that entails some level of, you know, status of how things are going. But I think what they lose sight of is that the daily Scrum is really, you know, more about I would say synchronization, right? We're supposed to be synchronizing on the system of work to uncover, you know, the bottlenecks, you know, plan the work for the next 24 hours to help us hit the sprint goal. So I find that at the daily scrum, if the team leaves, you know, maybe with at least one concrete adjustment, like, hey, I'm going to pair up with you on this item that's taken too long or re-sequencing work because of the dependency or escalating something that's you know, stagnant is an impediment. Well, that's a really good way to do that. But I'd also say, Brian, so let's just put the status meeting problem on the side. The other one I hear quite a bit, and you'll hear this from teams a lot, I'm sure you have, but people are saying, hey, we already talk all day. I just don't think we need a daily scrum. You ever heard that one before?
Brian Milner (17:58)
Yeah, I have.
Lance Dacy (17:59)
What do you think of that one? Is that one a big deal? I mean, I find that I face that one all the time. So I don't want to just put that on the plate, but yeah, the status meeting problem. But how often have you heard teams saying we're, we excel at collaborating all day. Why do we have to have another meeting? Right.
Brian Milner (18:15)
I don't hear that often, but I do hear it occasionally. And my question would be, is that the reality? Are they really communicating that much? Because if they are, we talk about sometimes this development practice called mob programming. Mob programming, everyone's in the same room at the same time all day long. And they don't have daily scrums usually when they do mob programming because There's nothing to share they don't already know, because they've all been working together the entire time. using that as an extreme example, right? In those cases, I think that they're accomplishing the purpose in a different way. And I don't really have a problem with those teams doing it. if a team says, we communicate all the time, do they really? Because if they do, yeah.
Lance Dacy (18:58)
Right. And how much of it on Slack? mean, how much of it's an email? So we, we, hear this all the time. And you know, I just, I just seem to, maybe I come across the teams that say it all the time and it's, took me a long time to finally, you know, try to get to the point and articulate that, you know, talking all day does not equal a 15 minute whole team inspection. and adapt the loop that focuses everyone on the sprint goal. I mean, yeah, you collaborated today and say, how are you looking on this? But have we all collectively got together, look at the scrum board or the Kanban board or whatever it is that you're looking at and actually look at each other in the eye and say, how are we doing with this? So, you know, I typically think about synchronizing on the sprint goal. Conversations are fragmented, right? So some voices never hear the full picture. Some hidden work piles up. We don't know it.
Brian Milner (19:18)
Yeah.
Lance Dacy (19:46)
We already know that if you just read asynchronous comments, you may not interpret them correctly. That's another problem. And so I just find that if you are just talking to a couple of people, then those blockers may stay local and developer loses half a day before maybe anybody notices, even though they were collaborating and talking with people. So I think the Slack stuff is good. There's good ways to have asynchronous daily scrums if you absolutely have to do it. But I find that those like a Slack you know, ping scatter attention, and create a lot of context switching as well. And I just don't feel like the information is radiated very evenly or cohesively across the team. And so, I think it affects their predictability to do that, even though they're talking every day. That's great. I love y'all collaborating, but who's coming together and saying, do we all feel good, you know, about where things sit? I just don't think that that's happening in my opinion.
Brian Milner (20:35)
Yeah. Well, and I think your initial point about purpose, I think, is really important with this one, to understand the purpose of why we're there. And maybe even underneath that, or parallel on the same level as a little bit, is who is this for? Who is the owner of this? And the sooner I can get the developers to understand this isn't my meeting, this is your meeting. This is your event. This is your working session, as you said. If they own it and take
Lance Dacy (20:57)
developers understand this.
Brian Milner (21:08)
ownership of it, then it becomes a productive time because they realize, oh, we can talk about or do whatever we need to do here. Yeah, it would be great if we could coordinate and spend some time doing this kind of thing every day. So yeah, think kind of helping them understand that they own it as well, I think is an important aspect.
Lance Dacy (21:28)
Right. Like focusing on like, hey, you know, the outcome, not the necessarily, you know, the ceremony says, Hey, it's up to you. You choose what format you want to do this. But, I had a team one time that just kept reiterating Lance. do not need this. I'm like, you know what, if you're truly in sync, prove it. You know, it's like, let's experiment. So skip the event for one week intentionally and track two metrics, right? How many items are blocked 24 hours and how much unplanned work is discovered late. And most teams are going to see a spike in all of that. Right. So the thing is, um, you want to optimize it, you know, don't delete it. Mature teams may finish their daily scrum in half the time. That's okay. Right. So some run it asynchronously in a chat, plus then they get together in five minute live huddle to tackle. So there's a lot of different ways to do it, but I think so much, we focus on the daily scrum because it's the recurring meeting, right? It happens most often. And I find most leaders and managers in my early consulting days, they would call me up. Lance, we'd like you to come assess the team's daily scrum. don't think they're doing well. It's like really just the daily scrum. Why is that such a focal point? But yeah, that's a huge one,
Brian Milner (22:35)
Yeah, I always think of it kind of a little bit like checking the oil in your car. Like it can tell you so much about things, even though it's a quick little check, like it can just tell you how the car's been treated, you know, all that kind of stuff. ⁓ Right.
Lance Dacy (22:47)
Yeah. Or a pacemaker, right? I mean, it's like, I'll try to think of it since cadence is such a big thing. You know, think of the daily scrum, like a pacemaker of the sprint, that continuous chat is like blood flow. And that pacemaker ensures that that B to stay in regular, ⁓ just at minimum to surface problems, know, great point.
Brian Milner (23:03)
Yeah. Yeah. Let's talk about the sprint review. I know one of the things that's always been a pet peeve of mine is when people call it the demo, because that seems to probably placing the focus on just the demonstration and not really where I think the purpose is, which is getting feedback. So how have you seen teams handle successfully What kind of strategies have they used to get feedback and really inject feedback into their work?
Lance Dacy (23:33)
Well, I find if I had to like say one of the biggest issues here is I find that the right stakeholders typically aren't there, they're too busy. And I'm like, well, what's more important than spending, you know, $80,000 every two weeks for this team to build something for you? It's like, ⁓ so I'm just curious sometimes, you know, and I leave that up to the product owner. That's your responsibility is to make sure that the right stakeholders are there and that can highlight some problems as well. So let's just put that to the side.
Brian Milner (23:40)
Yes. Yeah. Yep.
Lance Dacy (23:59)
the fact that we need the right stakeholders there and they need to attend and find it valuable. Well, actually let's dive into that one. Stakeholders don't find it valuable. Why? Well, teams show up maybe with a PowerPoint slide and say, here's what we did. And it's a bunch of technical jargon and it's just boring to everybody. So the first thing I like to do is I'll create a nice little agenda for it where I'll have the product owner kind of stand up and recap. What was the purpose of the sprint? Why did we have the sprint? What were we trying to get accomplished?
Brian Milner (24:12)
you
Lance Dacy (24:28)
What did we get accomplished, what we didn't get accomplished and how that affects the overall budget release and timeline. Can you believe that most people don't think a sprint review is actually a review of the sprint? Standing in front of your stakeholders saying, here's how the sprint went. It's not a retrospective. It's just saying, here's how it went. Here's the problems we have. Here's some things we might need help with removing impediments, but that's the first part of a sprint review. And I want the product owner to own that.
Brian Milner (24:38)
Ha ha ha ha.
Lance Dacy (24:53)
and show the timelines and show the budget and do all of those things. I love that kind of stuff. And then I kind of let the Scrum Master go over metrics of the team that the stakeholders like to see. Remember, Scrum should be a self-reporting framework. They shouldn't have to request status updates. We should just be pushing the information. I think the sprint review is a good way to kind of test what information do you want, what's valuable, but to bake that into our process so nobody has to go run a report. So.
Brian Milner (25:19)
Yeah.
Lance Dacy (25:19)
I like the Scrum Master to kind of do that and engage what that's looking like. And then the third part, like you just said, is a demo. Well, really what's better is let them use the product. That's probably the best thing we can do, but don't show me a PowerPoint slide. Show me what's working and show me how this works and let me experience it so that I can actually say that that solves our problem. I know the product owner already said that, but they may have missed it as well.
Brian Milner (25:29)
Yeah.
Lance Dacy (25:44)
I find the, and what happens is you say, this is too technical. You know, I just updated a, you know, it was a, just say a re-indexed a database table. It's like, they don't understand what that means. That's not true. You show a query, run the query, say it was very slow. It's had a subtree cost of this and I changed these indexes. I run it again. It's the same data. So that's good, but it goes quicker. And here it is. I mean, it takes under a minute. You don't have to know SQL to understand what's going on, but that gives them confidence that
Brian Milner (26:07)
Yeah.
Lance Dacy (26:13)
Wow. Okay. That's really cool. So it took time, right? Some people just think, well, it's too technical. They want to understand it. It took you half the sprint. Be proud of that. So I think one of the big problems as well, not having stakeholders there at all, but not having a good, you know, I don't want to make it so formal that it's stuffy, but I like to put those three components in there. Why did we have the sprint? What's the overall budget release and timeline? What are the metrics we're capturing? Do these look good to y'all? Is there anything else you want? And then the demo.
Brian Milner (26:21)
Yeah, yeah.
Lance Dacy (26:42)
and let the developers be prepared. What am I going to show? Let me have my test data up and ready to go so those demos go really smooth. And I find that it builds trust and confidence. So that's what I think.
Brian Milner (26:52)
I completely agree. it's, if you're a developer, and I've encountered this before from developers where they feel a little nervous about letting the stakeholders actually do the thing in the sprint review. And my question to them is, well, then how can you call it done? Right? I mean, if you're afraid to even in the sprint review have someone actually use the product, it needs you, the developer to actually do it. in order for it to be successful, then how can that be done?
Lance Dacy (27:19)
Right. Or they're like, I don't want to spend the time to get it ready for demo. Well, no, that's the point. You've got to spend some time preparing for the sprint review. That's OK. and guess what, Brian? That might be another meeting.
Brian Milner (27:25)
Yeah. Yeah, right. Yeah. And, you know, I think this is, this is something we talk about pretty well in, in the WoS class as well, just kind of what a good sprint review looks like and what, how to plan it. you know, what everyone's responsibilities are there. think having being armed with that really does give you a leg up on, on making this a more successful meeting.
Lance Dacy (27:54)
Absolutely. So I think, you know, we want to involve the stakeholders, have a conversation, invite the right people and make sure, you know, the other part of this, make sure your process is providing the information to the stakeholders that they want. And that's the job of a scrum master. So the sprint reviews are great litmus test for that as well.
Brian Milner (28:12)
Yeah, well, we got the last one here to cover. That's the retrospective. And this is one of my favorite meetings. But what have you seen as some of the biggest issues with teams and retrospectives?
Lance Dacy (28:24)
Well, I mean, if usually when somebody asks me, you know, what's the most important pieces of scrum, there's a lot of important pieces. the two most important activities or events in scrum. The first one in my opinion is the retrospective. And the second one is product backlog refinement. Like if you get those two things right, you know, I hear business people, mentors in business all the time. If you take care, of the top line stuff, the bottom line will follow. Right. So if you do really good at retrospection and you do really good at backlog refinement, all these other things will typically fall into place fairly easily. But what happens in the retrospective, in my opinion, is teams try to solve too many problems at one time. They don't know that by the way. So how this really manifests is, we don't see any improvement. And so they just start losing sight of the retrospective providing any value. But really I find the root cause in my opinion is,
Brian Milner (28:52)
Yeah.
Lance Dacy (29:19)
They're trying to fix too many things and too many things are too big. You're not breaking it down, right? In Scrum, we talk about breaking product backlog items down into smaller ones that fit in the sprint to show usable increments. Well, you got to drink your own champagne and take your improvement backlog and break it down and limit. You remember that goal of lean concept, I believe I've read somewhere is limit your work in progress. The more things you work on at a time, the longer everything take and people are too busy. to improve, does that sound ridiculous or what? Too busy to improve. And the reason they're too busy to improve is it's too big, they don't see the value in it, so we're not doing a good job backlog refining the improvement backlog. So my opinion is, how we facilitate this event is probably the key because Scrum Masters really can earn their money here. But I've seen teams just get in a conference room, open up a Word doc and go, okay, what went well in the sprint?
Brian Milner (29:49)
Yeah.
Lance Dacy (30:11)
and they write it down and then, okay, what didn't go so well this sprint? And then they write it down and then, okay, anything we want to change, yeah, let's change these three things. Okay, Jane, you got this, Bill, you got that one. And then nothing ever happens. So I think that there's an execution part of the retrospective that is lacking. And one thing that I used to do with my teams that I thought worked really well is every retrospective we would have our action items and put them wherever we're doing the daily scrum. so that we're mindful of not only how the scrum is going or the, know, the sprints going with the daily scrum review, but it's also, are we keeping these other things in top of mind? And if that list is too long, you won't. And so I follow what Jeff Sutherland, you know, taught me one time when I was talking to him, he was saying that fine tuning your processes is a lot like fine tuning your computer. If you have a slow down or a bottleneck in your computer, you don't just change all these components and say there it was, you try to change one thing at a time so you can actually troubleshoot if that causes another problem, but it often exposes a bottleneck you never knew was there. So he actually talks about only select one, two, or maybe three things at a time to improve. And if they're too big that you can't really make improvement, break them down. So that to me, is the root cause that causes a ton of other superficial problems, if that makes sense.
Brian Milner (31:31)
Yeah. Yeah, I think there's a lot of subtlety with this meeting as well, right? mean, there's structure kind of issues that sometimes teams have, but there's some subtle issues that go to things like psychological safety and trust that I think can really make a difference here as well. whenever I bring that up, I always kind of worry people think, this is kind of a kumbaya thing. this guy wants us all to sit in a circle and hold hands and whatever. And that's not what I'm saying, but I do think that there is a level of safety that's needed. if I say my opinion and someone speaks up and says, well, that's stupid, or that's ridiculous, why would we ever do things that way? Right, mean, how likely am I to give you my opinion the next time?
Lance Dacy (32:14)
I know, what an idiot. ⁓ my gosh, I know, that's so bad.
Brian Milner (32:22)
Yeah. So I think that's something that you got to kind of be on guard with as a whole team. And you got to make it a whole team mission just to say, look, we're going to prioritize this. We're going to prioritize that we want to feel safe to speak our minds here in a safe way that's not going to be impairing, that's not going to have repercussions. when we do that, we'll find the most important stuff. ⁓ Yeah.
Lance Dacy (32:46)
Well, I mean, that's kind of why I go back to how it's facilitated, right? Because the way you facilitate, you can make it very institutionalized, right? So the people are just talking about the same problems over and over again. You know, I used to put a little, when I was talking about putting that little piece of paper up on where the daily scrum was, at the end of the sprint, in the retrospective, we would put a plus sign next to the ones we really thought we got better at. We'd put a minus if we got worse and just a slash if we didn't really pay attention at all. And we'd have to look at each other and go, why didn't we make any progress on this? we commit to do much? So the work of improvement is just as important as the product development work because that's what makes you hopefully deliver sooner at some point. I like to not think of agile as a faster way to work. It's actually slower, but you may deliver sooner because of the efficiencies you gain about getting better and more effective. And if you think about agile,
Brian Milner (33:08)
Yeah.
Lance Dacy (33:35)
as the philosophy of the way that we're delivering our product, Agile Principle Number 12 actually commands of the team to continuously tune and adjust their people and processes to get better. Well, the way we do that in Scrum is the retrospective. And so to me, it's inspecting the team's own people, process environment, and trying to select the most, know, biggest bang for the buck, the highest value for least cost. Does that sound familiar? You know, what's the improvement we can make and commit to it as a team just as important as we commit to the work of a sprint. And then that top impediment item, you know, becomes visible and, we get it removed and we start building out that cadence. And there's a lot of different, you know, I don't know. We have a lot of different online tools and things like that to facilitate. I'm curious, you do a lot of facilitation with this as well. What are some tools that you think work best to pull that best out of the team to do that?
Brian Milner (34:26)
Well, I mean, as far as actual tools, I think there's a lot of online tools like Miro and Mural that are really good kind of whiteboarding tools that allow people to interact and sometimes even in some anonymous ways. Sometimes you can have some anonymous type portions of it where that adds a little bit of safety to the room. ⁓ I'm not, no one's gonna know that it was my comment.
Lance Dacy (34:26)
Thank Yeah.
Brian Milner (34:49)
I used to use that kind of thing a lot when I was a scrum master. We would use a tool that allowed people to type in things anonymously. And that made a huge difference because here's the thing. One of the hard lines to walk as a scrum master facilitating this is that you're also participating. And facilitating should be kind of a neutral thing. But we're kind of
Lance Dacy (35:05)
Right. Yeah.
Brian Milner (35:14)
blurring the lines here as a Scrum Master, because you need to do both. You need to facilitate, but you also need to participate. And that's why I loved having kind of the anonymous nature of people adding things is because I could add things. I could put things on the board that then no one knew came for me, because I'm a team member like everyone else. And if everyone else agreed with me, then we'd talk about it. But if no one else did, hey, we'd talk about whatever everyone else thought was most important.
Lance Dacy (35:33)
because I'm a human, I can't be one of this. But you could also, know, bias the, or anchor the argument as well, just like when we do with estimating when you got the senior leader. So Scrum Masters, I totally agree. We walk a fine line, you know, active listening and doing some of those professional facilitation techniques to make sure we're guiding the team to a solution. you know, one of the biggest things that I like to do that I thought helped teams, regardless of how, you know, there's multiple ways to... format of retrospective, know, liberating structures has a lot of good activities that you could prey upon. But really what I want to do is bring the data. I bring data that hurts and helps, you know, what are our flow metrics look like, what are the escape defects? Let's not hide away from that. Concrete evidence is what's going to help focus the discussion on the work, not the people. And that's where your psychological safety, I think, comes into play. We want to challenge ideas, not the people. you know, and so we start thinking about ways to come together as a team and really address these things. So I like to prime psychological safety in that way. and focus on the problems with the data, not the people causing them, even though there's probably people causing them. you know, maybe you start with a two minute icebreaker or check in or something like that, that, there's a lot of ways that we could facilitate that.
Brian Milner (36:46)
Right.
Lance Dacy (36:55)
you just kind of get what they call an emotional exhale. You know, we just went through this sprint, we might've got our butts chewed in the sprint review by the CEO or whatever. We're in this together as a team, how can we bring that together? And then try to come out with a framed shared goal that's gonna help us all get better, you know, in that as well. So there's a lot of ways to do that. You know, in the WoZ class, we actually show a couple of those, right, that you can walk out.
Brian Milner (37:21)
Yeah.
Lance Dacy (37:22)
But that's what I love. The retrospective has to be one of the most important activities, I think, in Scrum.
Brian Milner (37:27)
I agree. I agree. Well, I mean, we made it through the events and you know, when we kind of look back at this, I would say, I hope what people hear is that it's not really the meetings that are the problem. It's really what goes on in that meeting. What's happening or what's not happening in that meeting that I think is kind of the important part. Recently, recent episode here on the podcast with Kurt Peterson.
Lance Dacy (37:47)
and I'll see you guys in a second.
Brian Milner (37:54)
we kind of brought this idea of talent versus skill and talent being kind of more the inborn ability to do something and skill being something you learn and earn on your own. And that's, think the good news about this is that a lot of this is skill-based. It's stuff that you can learn and get better at and improve upon. It's not something you have to just be naturally good at.
Lance Dacy (38:16)
Right. Well, and we didn't get into backlog refinement too much. That may be its own other thing, but I think those are handled poorly as well. But I agree with you, know, meetings aren't the villain necessarily, know, poorly designed meetings are the enemy. And I find that when every Scrum event is time boxed and anchored to real data and laser focused on inspecting and adapting and learning, that takes some time to learn how to do that. Right. Most individuals that join a team,
Brian Milner (38:23)
Right.
Lance Dacy (38:43)
aren't used to working that way, just like a lot of stakeholders aren't used to progressive planning. So I think the foundational element of a scrum master is to bring empathy and, you know, love on people where they are. That's what a coach does is embrace us where we are and say, here's what I'd like to get us and facilitate a plan to get us there. So that's some of the best things that a scrum master role can do. But also it's the team learning. those things as well to help adapt to that. So that's what the WOS class is such a great thing because now they're gonna be on the same language that a scrum master may be doing and that undercurrent can start moving at the same pace. So.
Brian Milner (39:19)
Absolutely agree, absolutely agree. Well, Lance, I can't thank you enough for making time for us to come back and talk. Thanks for chatting with us.
Lance Dacy (39:27)
Absolutely. Thanks for having me and wish you all the best of luck out there in your scrum endeavors. Hope to see you in a woes class very soon.
Brian Milner (39:34)
Yes.

#158: Should You Skip the Sprint Retrospective? with Mike Cohn

Is your team dreading retrospectives, or skipping them altogether? Mike Cohn joins Brian Milner to unpack what’s really going wrong (and how to fix it) so retros don’t just take up time… they actually make your team better.
Overview
In this candid conversation, Brian Milner welcomes back Mountain Goat Software co-founder Mike Cohn to talk about one of the most misunderstood parts of Scrum: the sprint retrospective.
Too many teams treat retros as boring, repetitive, or even pointless—and end up skipping them entirely. But retros are where the magic of continuous improvement actually happens… when they’re done right. Brian and Mike dig into the common reasons teams dread retros, how to spot the signs a retro isn’t working, and the practical ways to bring them back to life.
They also share their own lessons learned (including how Mike once argued retros shouldn’t be part of Scrum!) and walk through the real reason retros matter: giving teams space to inspect, adapt, and improve together.
References and resources mentioned in the show:
Mike Cohn
Your Fast Tract to a Fresher Retrospective Webinar
#141: Cooking Up a Killer Retrospective with Brian Milner
Overcoming Four Common Problems with Retrospectives by Mike Cohn
Retrospectives Broken? Fix Them for Good by Mike Cohn
Subscribe to the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.
Auto-generated Transcript:
Brian Milner (00:00)
Hey everyone, welcome back to the Agile Mentors Podcast. I'm here with you always, Brian Milner. But before we dive in today, I wanted to let you know that we're gonna have a free webinar that I'm gonna be running here for you. It's gonna be on September 24th at 9 a.m. Pacific. So do your adjustments wherever you are. It's called Your Fast Track to a Fresher Retrospective. It's just gonna be a little short 20 to 25 minute presentation. And then there's gonna be some open question and answer that we're gonna have after that. it's perfect if your team's retros are feeling a little stale, or if you're looking for practical ways to shake things up. We're gonna put a link to it our show notes, but wanted to make sure right up top that you guys knew about that. It's completely free, September 24th, 9 a.m. Pacific. We're gonna have that webinar on retrospectives. And joining me here today, also is the one and only Mike Cohn. Welcome in, Mike.
Mike (00:55)
Hey, Brian's good to be back.
Brian Milner (00:57)
Glad you're here. We wanted to have a conversation because I think we can probably all agree that not all retrospectives, we might even say are worth having. When you look back on them and you look back on the content of it, maybe we'd say it wasn't worth having. If your team isn't getting value from the meeting and skipping it might feel rational. But skipping the point of retrospective, continuous improvement, isn't something high performing teams really can afford. It's a main part of what we do. So we're going to talk a little bit more. We're going explore that about why some teams end up dropping retros. Because I hear that all the time. People ask that in classes. Is it OK to? Should we? Should we do it less often? So we're going to talk about why some teams might drop retros. What that really says about the team health itself. and how you can bring retros back in a way that reconnects to their purpose so that it's not just a ritual. And with that then, I'm going to pull Mike back in. So again, Mike, thanks for being here. I really appreciate you giving us your time for the episode today.
Mike (02:05)
Yeah, I appreciate it. I'm glad to be here. Before you jump in, I do want to point out that we've been on for about 15 minutes before we got ready to record. Just kind of haven't talked to each other for a bit. And I just want to point out for everybody listening that Brian did a mini retro on his podcast before we got started, talked about how we can change some editing on that, maybe get episodes out more quickly and also to get them out in video. So I guess I'm saying that to. make us commit to the video part of it, but to also point out that Brian did a retro on his podcast, right before we got started. So Brian is walking the walk.
Brian Milner (02:40)
Yeah, mean, it's always good to inspect and adapt, right? I mean, if you don't do that, then you're not questioning why things are happening the way they are and things get stale and eventually fall off. So yeah, I'm a big proponent in that, stopping down to inspect and adapt for sure.
Mike (02:56)
Brian, one of the things that does come up with retros is teams feel like skipping them when they're not getting anything out of it. Do you think it's okay to skip a retrospective?
Brian Milner (03:08)
Well, I'm probably not going to shock anyone here in my answer, but I'm not going to be someone who would support that. I'm not a proponent of that. I think that's a mistake. I try to be very careful about saying, hey, this is always this way. I do think that that's the Agile Manifesto talks about periodically, routinely. kind of having this kind of inspecting and adapting moments where we retrospect on how things went. And Scrum has this meeting built into it to happen every single sprint. The thing that kind of jumps out at me when I first thought about this is we kind of take this attitude sometimes that, this thing isn't working great. And so maybe we should skip it. Or least that's, I guess, the mentality behind skipping the retrospective.
Mike (03:55)
When you say skip it, I think about the guy skipping leg day, right?
Brian Milner (03:59)
Right, right. Well, that's exactly where I was going to go. It's like, where else in life do we say, that's not working, so I just won't do it. You know, like, I'm having a hard time getting my passport renewed, so I guess I just won't get my passport. You know, like we don't do that with other things. There are things that are hard. There are things that take more effort. And it doesn't mean that if it's harder or it's not working right now that we just don't do it. We got to figure out why and... you know, fix it and, you know, get better at it.
Mike (04:27)
Yeah, there's a I'm a big fan of the Lego Batman movie. And in there, there's a song where this says Batman never skips leg day. Right. And, you know, skip something if it's truly useless, but don't skip something because it's hard. Right. I would agree that. Brian, I'm curious what you think about this situation. What suppose you have a team doing one week, one week sprints and one week is.
Brian Milner (04:31)
Ha ha. Right.
Mike (04:51)
Awesome. It's the right length for the team. It's a right length for the business. Everybody agrees. It rocks. One week sprints rock. But the team hates retrospectives. Like literally, they'd rather go to the dentist and have a root canal instead of having a retro. And at some point, somebody on the team goes, huh, if we switched to four week sprints, we wouldn't have to do these darn retros as often. That's a tough one. What do you think about that?
Brian Milner (05:18)
Well, there's some truth in that. You know, they're not wrong, as they say. You know, if you do longer sprints, then you have meetings less often and included in that is a retrospective. So yeah, that's not wrong. You would do it less often. But on the other hand, your retro is gonna be a lot longer. If you're retrospecting over the past month versus over the past week,
Mike (05:28)
Mm-hmm.
Brian Milner (05:42)
A weekly retrospective is going to be very short. A monthly retrospective is going to be very long and no one likes longer meetings. So that's the trade-off is, yeah, we can do it less often, but do you really want to have those meetings double and triple and link?
Mike (05:46)
Okay. in double and triple perhaps, but I I gave it the example where it'd be one fourth as often. So it'd have to be four times as long. And I doubt that it would truly be four times as long. See, this is a case where we probably disagree on this a little bit, because I have had teams that have made that argument. Hey, if we went to longer sprints, we wouldn't have to do this as often. And I don't want them to go to longer sprints. I doubt you do either. But what I've told them is like, look, the rule is do a retrospective often at least once a month.
Brian Milner (06:20)
Yeah.
Mike (06:27)
If you're going to do it every four weeks and you want to do two weeks sprints, for example, do your two weeks sprints. But I'd rather have you do the retro every other sprint, but take it seriously. Because what they do is they just go through the motions. They're going to go through the motions for 10 minutes. They're going to go through the motions in 10 minutes in a four week sprint too. Just show up. Can we get better or anything? No, we're good. Done.
Brian Milner (06:37)
Right.
Mike (06:49)
I'll let them trade off if they want. If they will make the commitment to me, they'll take it seriously and really come with ideas and try to improve.
Brian Milner (06:56)
Yeah, well, I think this is a prime example as well why inspecting and adapting is so important because, all right, what's our issue? No one likes going to the retrospectives. We're jumping from that to, then let's just not do them as often. When what you need to do is stop and inspect and say, why don't any of us like coming to the retrospectives? What's the problem about our retrospectives? And that's really the core issue there is to say, Hey, are we doing the same thing every single retrospective? Are we saying, Hey, what went well? What didn't go well? Right. I mean, are we being asked the same questions every time? we never varying it up? Are we always doing kind of navel gazing kind of thing? Or sometimes are we doing team building stuff? Sometimes are we even just celebrating some things that happen from time to time? The root cause is the important part because otherwise, you know, it's like cutting off your leg because you you got to a little infection or something in your big toe. That's not the cure for it. The cure is find out what the disease is and treat the disease.
Mike (07:57)
'm back to it's leg day at the gym and I'm going to cut my legs off because I hate leg day that much. Right. It's like, no, no more leg day. Right. So you'd have to really hate leg day for that, for that to be the solution. What, what are some of the signs that you've seen that indicate a retro is not working and that the team needs to kind of rethink things? What are some of those signs?
Brian Milner (08:00)
All right. No more leg day. Thanks. Yeah, no, that's really good. Common things, people checking out, people just giving surface level answers. Here's a big one. There's obvious things that didn't go well in your sprint, and no one brings them up. You just kind of get there and it's like, for example, hey, we didn't finish everything in this sprint.
Mike (08:39)
Yeah.
Brian Milner (08:44)
But then we get into our retrospective and no one puts on the board. What's something that didn't go well this front? We didn't complete all our work, right? Sometimes people get to that point where they just feel like, it's so obvious. Why would I need to bring it up? Well, if it's so obvious, then we need to address it, right? We need to do something about it. So yeah, I think that's part of it is that sometimes people will just check out and you might be able to tell it that way. You might be a tell it because they're not really contributing things. People try to rush through it. You know, it's like you only get a team where only a couple of things are in each one. And it's almost like it feels like the team's colluding to sort of, well, you put these two things up there and that'll be enough. And then they'll leave us alone. We can go on. You know, so, you know, they're, they may not literally be doing that, but it's almost, you get that feel that it's almost like there's an implied, I guess we have to have this number of things up there. Yeah. I mean, it's just,
Mike (09:13)
Good.
Brian Milner (09:37)
In general, there's no investment. When people show up, they're not really engaging. They're marking the time. And when that's going on, yeah, that's usually a precursor to someone eventually saying, hey, let's just not do this then.
Mike (09:54)
One of the problems that I'd add or one of the symptoms that I'd add would be when the team is talking about things again and again, the same item again and again, right? And it's not gonna get fixed. You we might be in there talking about, you know, I hate the new building, right? The new building's farther from my home. This is a real team I worked with where they all moved. They were downtown and the company moved everybody out. near the airport in their city. And it wasn't better for anybody. I mean, it was probably better for the CFO writing the check for the landlord or to the landlord. But it was a bigger commute for everybody. The facility wasn't as nice. It wasn't your restaurants. I mean, it just kind of sucked. And they would grumble about it every week. It's like, we can't fix this, right? We can't fix this. Right. You know, and so sometimes talking about things that are out of a team's hands are are they're just frustrating. Right.
Brian Milner (10:34)
Ha ha ha ha. Yeah.
Mike (10:42)
It's like mention it one time. I hate the new building. It sucks. There's no good restaurants here. And you know, you're probably not going to fix that problem. Maybe you can agree that you're going to, know, on, you know, the last Friday of a sprint, everybody on the team is driving back downtown and we're all going to lunch together, right? Fix it that way a little bit. But, you know, don't grumble about things that are out of your hand, right? You know, I'm worried about climate change. It's like, yeah, but I don't hear about that. It seems retrospective, right?
Brian Milner (11:02)
Yeah. Yeah, that's completely outside our circle to do anything about, right? So yeah, I agree that there is that scope sometimes that happens. But on the other side of it too, I would say one of the other killers that can contribute to people kind of checking out is not feeling like it's making any difference. know, if we bring something up, let's say it's not completely out of our hands, but it is something that's a real issue. And we bring it up.
Mike (11:09)
You Yeah, we need to test earlier. We need to test earlier in the sprints, right?
Brian Milner (11:33)
Right. We need to test earlier. We think we'd be better if we had some test automation here and we want to put test automation software in place. Yeah, well, I asked the manager and he said no. So I guess we're done. Right. I mean, it's frustrating. We say these things. I think it's important that the team see progress. It doesn't mean that you have to solve it 100%. In that case, hey, the manager said no. OK.
Mike (11:46)
No. Frustrating.
Brian Milner (12:01)
Well then how can we raise the transparency of the issue it's causing for us not to have it? We can make it apparent that this is what's going on. I remember there was a team I had one time that they started to bring up the issue that they didn't have a coffee machine near them. Now this was an absurd case because I don't know any other place that would do this. for whatever reason, this place I was at, they had two floors. the programmers were on a floor without the coffee machine. The coffee machine was down the stairs on the lower floor. And so they were complaining because they were saying, hey, we have to walk up and down the stairs all these times a day. mean, there's a reason that we name our languages Java. They're coffee drinkers. So they brought it up, and we talked about it. And we said, oh, guess they kind of set up the office the way they set up the office. immediately put me into action to think, you know what, this may not be about coding or may not be about something that's kind of a day by day thing that's doing our work, but it is an important thing that they have access to this. And I was able to then kind of start to compile some data and show, look, they're spending this much time walking up and down the stairs and that's happening to each developer and you're losing this much time of their day walking up and down stairs. You think it's too much expense to put in this coffee machine, but you're paying this every week by not having a coffee machine up here. And we were able to get them to actually make that change. That was huge for those developers. They thought that was the best thing in the world that now the coffee machine was relatively easy to get to, and they could get refills anytime they wanted. So I think it's important that they see that progress happens. Right.
Mike (13:46)
Yeah, it showed that they were cared for, right? That somebody heard, right? Why do you think this is so prevalent? Because, mean, you we hear this all the time, right? You know, oh, our retro soccer. Oh, man, I'm going go to retro today. Why is this such a common thing? Why do so many teams feel like they don't need to do retrospectives?
Brian Milner (13:50)
Exactly. I'm not really sure why they jumped to that as the solution, because as I said, we don't really do that anywhere else in life. Other than to just think, you know, no one likes meetings. And when we come up against a meeting that we don't feel is going well, then that's sort of, that is sort of our instinct is, well, then let's just not have this meeting. But if they, maybe that gets back to purpose even a little bit then. If I don't understand the purpose of it, then now it's not just that it's not going well, it feels pointless. And why do I want to go through something that's painful to go through and I don't understand why you want me to go through it? You know, that's a double whammy that now the easy solution is, well, let's just not do it then.
Mike (14:34)
Right. think a lot of teams feel like, you they adopted just the bare beginnings of Agile or Scrum and they start to, they notice they're better, right? We've improved. And they, maybe they are 10, 20, 50 % better than they were before and got there pretty easily. And it's like, well, we don't need to keep improving. We just improved, right? ⁓ And you know, it's the Dunning-Kruger effect, right? This is like so much more you could get better at, but you you see that you got better. Why keep going, right?
Brian Milner (15:03)
Yeah. Yeah.
Mike (15:14)
So I think that's a factor. I'm curious what you would say to me 20 something years ago, because Esther Derby is the reason why retros got added as a standard thing in Scrum. They were not part of Scrum at the beginning. And she started lobbying that they should be a standard part of Scrum. And I disagreed. I said retros should not be part of Scrum. And I'm very big on admitting my mistakes. So I argued no. So I'm curious what you would say to me, because here's my argument. I don't want to wait until the end of a sprint to tell my team an opportunity to get better. If I notice an opportunity to get better, I need to bring that up in the next morning's Daily Scrumber. If it's a huge opportunity to go grab everybody that afternoon and mention it. How would you argue with me about that? Because in some ways, that is a better way to get better, right? Just bring it up in the moment. Why wait till the end of a sprint?
Brian Milner (16:03)
Well, I think what I'd say is, then if you recognize something in the moment, then absolutely bring it up in the moment. There's no need for you to wait till the end of the sprint. I don't think that you store it up or that you have to wait. I would say something similar about a sprint review. Why do I have to wait till the end of the sprint before I get feedback from a customer about something I just did? You don't, right? ⁓ There's no reason why you can't on day two or three
Mike (16:25)
Okay.
Brian Milner (16:28)
show it to somebody who's going to be using it and say, what do you think about this? In fact, it's better if you do that. What it becomes though is that, speaking now about the review, the review is the time everyone can count on every sprint to show up and examine the increment and give feedback. The retrospective is very similar. We can give feedback throughout the sprint. We can improve throughout the sprint.
Mike (16:52)
Right.
Brian Milner (16:52)
but it's the designated cadence. It's the time that we can count on every sprint that we're gonna set aside, right? We're gonna set that aside to do this because we think it's that important.
Mike (17:04)
I think it's that dedication, that dedicated time that is part of what persuaded me because suppose I come, I do come up with a brilliant insight. It's my idea. Of course it's a brilliant idea. I come up with this brilliant idea about how our team can get better, Brian. And I want to talk to about it right now. And I, I, I Slack you and I said, let's talk about this. No, your head's down in the middle of something else. You don't want to talk about it right now. It's not the right time, right? And if we set aside that time at the end of the sprint as a dedicated time, it's more likely to happen and it's everybody knows to have their brain ready for that conversation, right? It worked better, right?
Brian Milner (17:42)
Right, and the fact is, lots of people are heads down throughout the sprint, right? There's lots of time in the sprint where you're just so involved and busy and your brain's working on what we're building that unless you get told, unless you get that thing on the schedule that says, wait, I gotta stop, okay, time to retrospect, right? Unless you get that reminder that, hey, this is important too, right? We gotta do this thing. You could very easily just end up going for a long period of time with never doing it. And that's the danger. It falls off your radar and pretty soon you're never having any kind of time to retrospect. So it's not that there's something magic about, we've got this meeting that's called this. It's really what happens in it. And if that's happening on an ongoing basis, well, maybe you have another process that's not Scrum that would be as effective, but Scrum dedicates that time so that you make sure you don't miss it.
Mike (18:35)
Yeah, I just don't think it happens. If we told everybody, as soon as you come up with an opportunity to improve, interrupt your team and tell them about it right then. It's not going to happen because if I have a brilliant idea, OK, I might go talk to people. How many brilliant ways to improve a team do you come up with, right? Most of them are incremental, right? Hey, here's a way that we do a little bit better. And I'm going to go, well, this will all be a little bit better, but everybody looks busy. I'm not going to go bother them right now, right? And I noticed that I would do this. I would have an idea. I wouldn't bring it up. And then tomorrow I'd forget about it. What was that brilliant idea I had yesterday? And so I became a very strong advocate of the retro, despite at the beginning, and being very honest with that, not thinking that it should be part of Scrum. It should be something that we just do on a more ad hoc basis.
Brian Milner (19:21)
Yeah, that's very interesting. And I'm glad you shared that because it's interesting about the evolution of things and how things have changed over time as far as that's concerned. But you know, the other kind of aspect there it also is, you know, if my if I'm heads down and I'm going through, there are some things I'm going to notice just in the course of doing my work, because, hey, I would have been better if I could have done it this way versus that way. But I also feel like I'm going to miss so much if I don't actually pause and and redirect my brain from, I'm just plowing forward to let me actually turn my attention towards what's happened over this recent past and really think through it. Well, what did happen this last sprint? Let me think through everything that's happened. Yeah, that wasn't great. That was okay. That was actually pretty good.
Mike (20:07)
Do you have a structure you use for helping teams find ways to get better?
Brian Milner (20:13)
You mean as far as a retrospective is concerned?
Mike (20:16)
Yeah, I you mentioned earlier asking people like, you know, what went well, what didn't. Is there a structure, even a higher level framework you use?
Brian Milner (20:24)
Yeah, mean, the way I, Astrodurby and Dinah Larson's book has a really great five step kind of process for it. But I even tend to kind of distill it down even a little bit more than that, to just say that, you if you think about this thing that we talk about as the three pillars of Scrum, that, we talk about in Scrum classes, transparency, inspection, adaptation. I think that's actually a good pattern for retrospective transparency. What actually happened? I mean, let's try to be clear about what the reality was from this past sprint. Inspection, why did those things happen? What was the root cause of why those things happened? And then adaptation, what are you going to do about it? We don't want to just keep doing the same things and let's hope everything gets better. No, hope is not a strategy, right? We have to figure out the root cause and then have a plan. What are we going to do differently?
Mike (21:12)
Yeah. What advice do you have for somebody listening right now that wants to fix their retrospectives, wants to stop them feeling useless and be productive in their retros?
Brian Milner (21:29)
Yeah, it's, you know, I sound like a broken record. It's the, it's time to inspect and adapt, right? You need to find the truth of what's behind that resistance, right? What's causing the team to not want to do retrospectives. And, and if you're a scrum master, you know, that, that could be a hard look in the mirror for yourself to kind of look and say, well, maybe I'm not doing a great job facilitating this. Maybe that's the root cause of this. Or maybe there's mistrust on the team. Maybe there's some safety issues. Do we feel safe enough to say things that actually went not so well here? Sense of fear. Or maybe the root cause is it just doesn't matter. It doesn't feel like it matters to anyone on the team. It kind of feels futile and that we're just saying the same things every time, but nothing's actually changing. So I think there's different solutions depending on what that root cause is. And I think that's where I'd probably try to focus is if it feels broken, that's the symptom. What's the root cause of it? Why is it feeling broken to everyone? And then we can come up with a plan for what to do.
Mike (22:31)
OK, that's good. Inspect and adapt at a meta level, right? mean, why is our retro broken? Inspect and adapt over that, and then inspect and adapt within the retro. So for somebody who's listening today, I want to start to wrap this up. I know we're kind of at the target limit for our podcast episodes. For somebody who's listening right now and maybe is thinking about or has skipped retros, maybe wants to get back to it, are there any things you'd like them to know?
Brian Milner (22:35)
Yeah.
Mike (22:57)
What takeaways would you give people as we start to wrap up here?
Brian Milner (23:01)
Yeah, I think that some of the big takeaways are it's important to always inspect and adapt no matter what we're doing. And that's what the retrospective is, is a chance every sprint to actually inspect and adapt. It's just a tool, right? It's important to understand the retrospective. There's nothing magic there. It's a tool. And we always say, know, individuals and interactions over processes and tools. it's not that that's a magic thing. It's a tool. But if the tool isn't working for you, then inspect and adapt on it, change it to make it work. If you feel like you've lost sight of the job the tool is meant to do, that's a big problem. And that's something that maybe should be a focus not just for you personally, but for the team. Does everyone understand what we're here for, what the purpose is, what we're trying to do with this, and why this is an important use of our time? If not, then Again, maybe you're asking me to go through something that right now is painful and I don't understand why you're asking me to go through it. A lot of these things, when we put together our Better Retrospectives course, we try to address a lot of these common kind of concerns behind why people might skip a retrospective. And as I said, there's various cures to various diseases and you have to be able to really diagnose it. and get to the heart of it before you can apply the proper one to it.
Mike (24:23)
You mentioned you're doing a webinar. you tell us about that so I can put that on my calendar? I want to join that and listen.
Brian Milner (24:29)
Yeah, absolutely. And anyone listening can. doesn't cost you a thing. It's a free live session we're going to have September 24th at 9 a.m. Pacific. So 9 Pacific, 10 Mountain, 11 Central, 12 Eastern. So it'll hit right around lunchtime if you're on the East Coast or first thing in the morning if you're on the West Coast. But yeah, it's going to be September 24th. We call this webinar, your fast track to a fresher retrospective because that's the idea. want to try to freshen it up. We want to try to give you some practical concrete ideas in just a short little 20 to 25 minute session. We want to give you some practical steps and things that you can apply immediately and take advantage of. And we're also going to give time afterwards for open Q &A. So if you have a question that's You have a burning question about retros. You feel like you have a situation you need help with. Yeah, bring it to that session and you can ask us. we're not going to be able to get through every question, but we'll be able to get through a good handful of them and try to deal with the things that we think are going to be the most popular questions there in the group.
Mike (25:41)
Good. I just put it in my calendar and notice it's September 24th is National Punctuation Day. I think the National Punctuation Day celebrations are at the bar that night. that shouldn't conflict with participating in your webinar.
Brian Milner (25:54)
Is there a sub group that has a party for celebrating the Oxford Comma during this National Punctuation Day?
Mike (25:58)
You Probably I want to see who is out celebrating National Punctuation Day. So I'll have to have to start looking for that look for look for the parties but
Brian Milner (26:08)
You I don't know who it is, but I know they are celebrating it! Exclamation point, exclamation point.
Mike (26:15)
With a few exclamation points. So thanks for letting me on here to talk to about retros, Brian. I learned a lot. I'll turn it back over to you.
Brian Milner (26:23)
Yeah, no, this was a great conversation. I appreciate you coming on and kind of driving this a little bit for us, Mike. yeah, just a reminder, we'll say that again, September 24th, at 9 a.m. Pacific. You can go to the Mountain Goat website and we'll put a link in our show notes as well where you can kind of find out more information about it and put it in your calendar.
Mike (26:45)
Perfect.

#157: What Teams Are Struggling With Right Now with Cort Sharp

Scrum isn’t new, but the questions teams are asking about it are evolving. In this episode, Brian and Cort Sharp compare notes on what they're hearing in class, in the community, and behind the scenes.
Overview
In this episode of the Agile Mentors Podcast, Brian Milner welcomes Mountain Goat Software colleague and community manager Cort Sharp for a real-time pulse check on what’s top-of-mind for Scrum teams today.
From overloaded calendars to misunderstood metrics, Cort and Brian dig into the patterns and questions they’ve seen across classes and conversations lately. They unpack common friction points like meeting overload, velocity confusion, misused roles, and daily scrums that eat the whole morning, and offer grounded suggestions for handling each one. Whether you're a Scrum Master trying to protect team time or a developer wondering how to work more collaboratively, this episode offers helpful context (and practical nudges) to help your team work better, together.
References and resources mentioned in the show:
Cort Sharp
#143: What Still Makes Teams Work (and Win) with Jim York
#152: The Five Pillars of Real Agile Improvement with Mike Cohn
7 Advantages of Scrum (Plus 1 Hidden Disadvantage) by Mike Cohn
What Is a High-Performing Agile Team? by Mike Cohn
Mountain Goat Software’s Working on a Scrum Team Course
Subscribe to the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast 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.
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. We're back for another episode of the Agile Mentors Podcast. I'm here as always, Brian Milner. And today we have Mr. Court Sharp with us. Welcome in Court.
Cort Sharp (00:10)
Hey Brian, thanks for having me on again. Brian Milner (00:13) Yeah, Court has been a frequent guest of our show. If you've been around for a while, you probably remember some episodes we've done with him. Court works with us here at Mountain Goat Software. He is a producer and other things, community manager, other things. But he sits in on just about, well, not every class, but he sits in on a lot of classes and helps produce them and make sure that they work. We previously have had Court on with sort of this theme that, you know, Court has his finger on the pulse of things a little bit more because he sees the classes through multiple trainers. He hears the Q &As that take place in all the classes. You know, he even sees some of the emails and some of messages come through the Agile Mentors community from his work there. So Court just has some insight that maybe... a trainer like myself who only gets to see how people question in my classes that I might not have. So we like to have Kordon to get a broader voice of the people approach, if you will, into things. So we wanted to talk a little bit about what are people talking about now? What are the questions? What are the concerns?
Cort Sharp (01:18)
You
Brian Milner (01:29)
What are we hearing now in classes as opposed to maybe a year ago or six months ago? So I think probably a good place to start there, Court, is when people are talking to us about just the common, hey, here's things that's a problem, here's things that are a pain point, how do you deal with this? What are some of the more common things that you've been hearing across the classes and across the interactions with people who are in our our system.
Cort Sharp (01:53)
Right, right. Yeah, I guess I am kind of the collector of questions. ⁓ But even outside of our classes, I'm hearing a lot of questions about, I'm hearing a ton in our classes about this, but outside of our classes, whether it's on various social medias, various emails, of just questions in general to people who are newer to Scrum or I guess Agile as a whole, but specifically about Scrum.
Brian Milner (01:58)
Ha ha ha ha.
Cort Sharp (02:18)
organizations that are newer to Scrum is time management. So like how do we fit all of this new stuff? Like all this new stuff is great. All of what we talked about is great. All that we know about it is great. We were on the same page of like, hey, here's, it's a good time to check in daily with our daily Scrum, make sure we're all on the same page, right? We do need stakeholder feedback with the sprint review. It's good of us to kind of retrospect. and use our retrospective to check in on our team and our process and make sure we're doing the right stuff. But how do we fit all of that in with all of the other meetings and stuff that we already have? And you and I were talking a little bit about just kind of what we're going to talk about a bit more. But we were talking about this before we started recording. And I think I told you literally three or four days ago, I just had a conversation with one of my friends who they're working in a tech software, they're doing a software project in some organization and they're like, yeah, they're trying to get us to move to Scrum because they've heard about this thing. And I just, I don't know how you push this man. I don't know how you do this. I don't know how you live in this world because they got me in six hours of meetings a day and they expect me to get four hours of work done. And I'm not sitting at the office for 10 to 12 hours a day. That's ridiculous. So I think the biggest one is the the time management specifically with all of these meetings. And I know my personal take is I think all of these or a lot of these organizations, I can't say all a lot of these organizations are looking at Scrum as an additive to their current process, not a substitute or replacement. you do you see that, Brian? Do you agree with that?
Brian Milner (03:53)
Yeah. Yeah, I agree. mean, if they already have a huge slate of meetings that they're, I mean, there's going to be some things that Scrum isn't going to replace and shouldn't replace, for example, like, you know, one-on-ones with your manager, right? There's not a function inside Scrum for a one-on-one meeting with your manager, nor should there be, because that's not about how a team builds something. That's more general management and HR, you know? so those kinds of things, no, it's not going to replace and there are going to be other meetings outside of scrum. It's not intended for scrum to replace all of them, but it is intended to replace some of what you already did. and if you, so for me, it's all about purpose. You know, that's, that's where I think that you should start with everything is what's the purpose. And if you understand the purpose,
Cort Sharp (04:46)
Mm-hmm.
Brian Milner (04:54)
then you can compare, ask yourself what the meetings that you have now, what's the purpose of this meeting? And if you can't answer that, then I would challenge it. I think that an agile organization should be open to challenges for any part of the process. And you should be able to say, hey, I'm not sure why we're doing this. And if we can't really articulate, here's the purpose behind it, it should be gone.
Cort Sharp (05:10)
Mm-hmm.
Brian Milner (05:19)
We should get rid of it. So I think you're right. I think there is sort of this layering on top of, and if we don't allow the scrum meetings to replace some of the things that we've done previously, yeah, can be, it can seem like a lot more of a meeting heavy kind of system, but the meetings in the system, let's be clear, right? First of all, depends on how long your sprint is, but let's just go with the sprint that's the sprint length that's the average or most common, which is two weeks. If I have a two week sprint, first day of the sprint, I'm gonna have sprint planning. That is going to be a long meeting. There's no two ways around it. The official time box is up to eight hours if you have a month long sprint. Most people would half that if it's a two week sprint.
Cort Sharp (05:45)
Yes.
Brian Milner (06:07)
So maximum maybe of around four hours. So half a day, let's just say, right? Half a day of your first day is gonna be in planning your sprint. Then maybe you finish that meeting up with a small sort of mini daily scrum, but that's it for that day. So you have half the day on day one. Day two, day three, day four, almost all the days of the sprint that are remaining, you have 15 minute meeting. That's it. If you, if you layer on maybe a backlog refinement, maybe you have another hour long meeting in the middle somewhere, but there's no other scrum meetings every day. It's a 15 minute meeting until you get to the last day. So first day, last day, right? First day, four hour meeting last day, you're going to have the sprint review and the retrospective. So there's going to be some time probably in the first part of your day that you have a sprint review. It's going to be some time in the the back part of your day for a retrospective. But those two combined, they're not gonna, maximum I would say there, if you combine those two, would be the same as the sprint planning, maybe up to about four hours or so, maximum. So maybe half a day. So two days of your sprint, you've got half the day for meeting, two out of 10. And the other days, you've got 15 minutes every day. So yeah, there's a lot of those 15 minute meetings, but they're just one a day. And otherwise you have the entire rest of the day to do whatever you need to do to build. So percentage wise, it's actually a small percentage of the total time that you have to work in the course of two weeks. ⁓ If the meetings are not being kept in their time boxes,
Cort Sharp (07:32)
Mm-hmm. Right.
Brian Milner (07:55)
then that's the issue, right? If we have a daily scrum that goes for an hour, yeah, I would feel like that's a beat down as well. That's not what it's intended to be.
Cort Sharp (08:06)
Right, right. And I've also heard the other really common complaint is about the daily scrum of, I understand it's only 15 minutes. I understand that it's a check-in. There's been, I've heard complaints about other, or seen complaints about other meetings where the point of the meeting isn't really well understood across the team, which I think we'll get into a little bit later. But specifically about the daily scrum, the biggest complaint I've seen is, okay, it's 15 minutes, but is it actually really only 15 minutes of your day? And again, same buddy of mine, same friend of mine who threw this out to me, and he was like, so let me paint this picture for you. I get in the office, let's say at 9 a.m. I sit down, I eat. respond to a few emails. look at my emails, I check that out until about 9.30. Our daily standup is at 9.30. Our daily scrum is at 9.30. I have to do minimal work because I can't get into any deep work. I can't get into any major thought work in that first 30 minutes. So I can't really do a whole lot there. Maybe I'll grab a cup of coffee and hang out. That's what most of my days look like. 15 minutes. And then there's always 15 minutes after that 15 minutes to kind of coordinate with whoever needs to, whoever I need to work with to get stuff done, to help remove bottlenecks or anything, which is totally fine, right? We encourage kind of that 16th minute, so to speak, outside of it, but the meeting officially ends at 15 minutes and unless you need to coordinate with someone else, you're free to go, right? So he's like, okay, there's normally another about 15, maybe 30 minutes. So that takes me until about 10, 15. Well, lunch is at 11, so I got another 45 minutes of nothing. Can't really do a ton of work, and that's basically my whole morning just gone, right out of the gate, right? So it's a 15 minute meeting, but in my friend's world, it's a lot more than 15 minutes. ⁓ I know what I would say to that. I'm curious what you would say, and then I'll share what I would say to that.
Brian Milner (10:02)
Yeah. Okay. Yeah. I'm going to say something that may blow people's minds. What if you don't have the daily scrum first thing in your day? Right. Maybe what the issue is here is the time of your daily scrum. If it's at 9.30 and that's messing with your day because you can't really get anything done before that. And then afterwards you're spending more time. So it's taken time and then there's not enough focus time before lunch. so you feel like half your day is gone, well, what would happen if it was the last thing in your day? What about if you ended the day with a daily scrum? What about if you did it first thing after lunch? There's nothing that says it has to be first thing in the day. The team can decide any point of the day to have the daily scrum, and I encourage the team to experiment with it. I've had some teams before who
Cort Sharp (10:48)
Right. Mm-hmm.
Brian Milner (10:58)
really love end of the day daily scrums because they felt like at the end of the day, we check in with each other. We get together and say, all right, what happened today? Right. And they can all, it's all fresh in their mind because they just finished the day. They can talk through it all. All right. So what does that mean for tomorrow? All right. When we come in tomorrow, we're going to do this. And one of the things that allows is if you have, most of the places I've worked,
Cort Sharp (11:02)
Hmm. Mm-hmm.
Brian Milner (11:24)
You have developers who have sort of different time schedules. Some people will sleep in and come in late and work late. And other people like to come in really early because they like to avoid the traffic. If you have that kind of situation, if you put it towards the back part of your day, then when people come in in the morning, it doesn't matter what time they come in, they have a big chunk of focus time, but then they can dive in and do things. to me, your friend's problem is more about
Cort Sharp (11:32)
Mm-hmm.
Brian Milner (11:50)
that interrupting the block of concentration time and it just needs to be moved to a place where it doesn't, you know, kind of split that block of focus time.
Cort Sharp (11:54)
Mm-hmm. That's a much better answer than I gave him. I just said, well, what else would you be doing in your morning? And he said, well, probably, you know, putzing around, checking email, doing nothing until lunch anyways. ⁓ Right, right.
Brian Milner (12:06)
Ha ha ha! Well, there is always that, right? mean, just because you've got the opportunity to have focus doesn't mean you're going to focus, but that's a whole other set of issues, right? Yeah.
Cort Sharp (12:24)
Right, yep. And really, I guess my additional answer to him was also, when you're working in an organization, you're making a reciprocal commitment to that organization to say, I will get this amount of work done, you will give me this type of compensation, and there will be communication between everyone. ⁓ And to me, the Daily Scrum is that communicative part, maybe not necessarily with the organization as a whole.
Brian Milner (12:44)
Right.
Cort Sharp (12:51)
but you're still communicating with your team and you're getting on the same page, you're getting aligned so that you all can meet your reciprocal commitment. So really, is the daily scrum for the team or for the organization? I think you can make an argument for either, but at the end of the day, it's for everyone to get on the same page so that we can move forward, which you were going to say something? Go ahead.
Brian Milner (13:12)
No, just going to say, part of that as well is just, this is some of the stuff that we talk about in our working on a Scrum team class that we're launching here at Mountain Goat Software is really these kind of more subtleties of how the team works together. When you take a Scrum Master class or something like that, you'll learn that, it's a 15 minute meeting and there's a time box. You may not hear that kind of thing of, well, what works best for this team? Maybe it's the end of the day. Maybe it's the middle of the day. Those are the kinds of things that we try to focus on in a WoWs class is what's the best way for your team to actually do this thing and actually make it successful. ⁓ One of those other areas that I think is kind of a classification of problems is that classification of things and just kind of general process confusion.
Cort Sharp (13:49)
Mm. Mm-hmm.
Brian Milner (14:00)
You know people who just don't understand You know chunks of the process or why things are done a certain way or how to do certain things What what kind of issues have you heard along those lines? Cort Sharp (14:01) Right. I cannot tell you how many times I have heard and seen and had conversations with people about velocity and how velocity, some piece of after it's explained to them, they totally get it. They're on the same page. That's all good. Then they run into the issue of explaining it to their leadership. But the understanding of velocity is that it's a changeable or it's a metric to compare teams.
Brian Milner (14:21)
Ha
Cort Sharp (14:41)
And I'm on team A and we have a velocity of 20. You're on team B. You have a velocity of 30. Someone looks at that, bigger number, better, right? Brian's team is better than Court's team. No, that's not what it is at all. That's not how it should be used. That's not how it should be handled. That is a misuse of the process. That is a confusion point on what velocity actually is. Velocity, I guess we'll explain it here.
Brian Milner (14:52)
Right.
Cort Sharp (15:06)
Velocity is just a measurement of how much one specific team gets done in a period of time. That's it. How many points? And points are all relative. So story points are relative. They are not the same from one team to the next. So therefore, your velocity cannot be the same from one team to the next or comparable from one team to the next. You might have the same velocities, but it's not like saying, OK, my US American dollar is the same as your US American dollar. Those are two very similar, those are the same exact thing. Those are very comparable. We're working with different types of measuring is really what it comes down to, right?
Brian Milner (15:43)
Right. Well, and I get the confusion because Mike's phrase is, estimate size, derive duration. So when you start to say, well, a story point is a measure of size, not time, you sometimes get pushback from people to say, yeah, but you're eventually going to translate it into time anyway. And you're right. We are. We're deriving duration from it. But the split we're trying to make there is when we estimate, right? When the developers are doing the estimation, we don't want them thinking in terms of time. We don't want them to make that process forward leap to say, well then the story point equals this number of hours. So let me do the calculation in my head and figure out how many story points this is gonna be. I say this in class. If your organization has a conversion chart like that,
Cort Sharp (16:12)
Mm-hmm.
Brian Milner (16:33)
a story point equals this number of hours, you're gonna have to convince me and explain to me what benefit there is of doing that. Because I have yet to hear anyone say, oh, well, we do that because it gives us this benefit. Other than saying because that's the way our tool works, right? Our tool we use to manage our process or whatever takes it in this way. And so we have to make the conversion so that we can use this tool.
Cort Sharp (16:42)
Mm-hmm. Right. Mm-hmm.
Brian Milner (17:01)
Now the problem is the tool is driving your process. But other than that, there's not really a benefit that anyone can show me for making that conversion, because what the developer ends up doing is estimating in time. And if they're going to estimate in time, wouldn't it be easier just to say, our estimate is in hours rather than story points? ⁓ It's six hours to do that. It's not one story point. ⁓
Cort Sharp (17:19)
Mm-hmm. Right. Right.
Brian Milner (17:26)
That's what I encourage people to do. the confusion comes from the fact that we do make that duration, we do drive the duration eventually, but that's for the long range forecast. I mean, we say very clearly in our other classes, but we talk about this in the worst class and the working on a scrumpting class, that when you're estimating something, you're thinking in terms of size, you're thinking in terms of risk. comparative to other things. And there's really only two reasons that we would use Story Points. One is to make those longer term forecasts, but the other is to help the product owner to know the relative cost of things so they can prioritize. But the thing you're mentioning, Core, is to use it as a performance metric, and that's where people fall into, I think, a big trap. When you use it as a performance metric, it actually destroys the other two reasons. Mike says this, we have a good thing going with the other two reasons. Organizations want to be able to forecast forward. Organizations need the product owner to be able to know the relative cost of something so they can prioritize. Those are good things. So why go in and destroy it by also trying to use it as a performance metric? Because those two things are needed still. And we won't have a way of doing those.
Cort Sharp (18:24)
You Right. Right. Mm-hmm. Right. Yeah, totally. I agree with that. I don't really have anything to add. I you just kind of knocked that one out of the park there, Brian. Good job.
Brian Milner (18:48)
Yeah. Yeah, no, mean, velocity, some of these, part of it's, you know, these are all new terms for a lot of people as well. And so you hear terms like velocity and think, oh, what does that mean? And, and I get it, you know, if you're a manager and you're not really familiar with this kind of stuff and you hear the term velocity and you think, oh, that's the speed of the team. Well, yeah, it is the speed of the team. Right. And if it's the speed of the team, why can't I use that to judge one team against the other? Because it's like using, um, you know, Fahrenheit and Celsius. I mean, it's
Cort Sharp (18:56)
Right.
Brian Milner (19:18)
metric and imperial. They're different measures. And so one number doesn't equal the same thing as the other. ⁓ Now, there are some scaled frameworks like safe that we'll try to level set across teams by having a little cheat sheet saying, hey, this is an example of a five-point story. This is an example of an eight-point story. So that the teams can maybe relatively compare against the same definitions of
Cort Sharp (19:25)
Right? Right. Mm-hmm. Mm-hmm.
Brian Milner (19:45)
sizes. ⁓ But I gotta say, even there, the teams are going to be off. The teams are not going to be perfectly aligned. That's the only thing that you can really do to try to align those. But they still have their own conversations. They still reach their own conclusions. And so the scales aren't going to be perfectly aligned no matter what you do.
Cort Sharp (19:46)
Mm-hmm. think even more importantly beyond they have their own conversations or I guess more fundamentally, not more importantly, more fundamentally, is that they have different people on different teams. You have different skill sets, you have different abilities, you have different people working on different stuff. I think I've programmed a little more recently than you have maybe, or it might be vice versa. I know you've recently just built a website again. But I would probably wager my programming skill set in like, I don't know, Ruby on Rails is probably a little, I got a little edge up on you right there, right? So if we were on different teams, Court's on this team, Brian's on that team, how can we possibly compare this different skill sets to each other and expect the same result, the same speed, the same pace?
Brian Milner (20:37)
Yep. Yep, definitely so.
Cort Sharp (20:55)
You were talking about, oh, it's like comparing using Fahrenheit and Celsius. The first one that popped into my mind was miles per hour or miles and kilometers per hour, miles per hour, kilometers per hour. Right. Speed in different cars. And then even beyond that, I guess, building on the car analogy, that's like comparing a high end Ferrari to my little first car ever, which was a Saturn Ion little beater. Could barely get up to 60 miles an hour thing. Those are two different cars. They're two different skill sets and they require two different viewpoints to even be able to compare them. There are comparisons you can make, know, four wheels, steering wheel, whatever. But at the end of the day, one of those is going a whole lot faster and it was not my first car. I can tell you that. ⁓
Brian Milner (21:39)
Yeah. Yeah, no, I think that's a good way to compare it as well. What about things that have to do, and I'll kind of combine some thoughts here, but maybe what about things that are kind of more role-centric or even just how the team works together? What kind of issues have you heard people mention recently in those areas?
Cort Sharp (21:49)
Mm-hmm. So managers, for one, what is the role of managers within Scrum? What's the difference between a product owner and a product manager? Is there a product manager? Does that person even exist? Do we just need to fire all of our product managers or turn them all over into product owners? That one's very common. But I think another really common one is when does the Scrum master step in? And the first time I took my first scrum master class, I can't say first time I took one. I've only officially taken one. but I've been in, if you look at the title of a podcast episode, a couple, couple episodes ago, a rough estimate of a billion, scrum classes. Laura, Laura, Laura Kendrick and I have been in a billion scrum master classes. That was, that was the fun conversation we had, but. I made that that I needed that question to answer to help me kind of grasp what is this new role? This is not a very traditional typical thing that you see within organizations of the Scrum Master. Do I as the Scrum Master, do I help estimate? Do I help prioritize the backlog? What do I do? Am I am I a team lead? Is everyone trying to talk with me on the daily stand up and is it my role or my job to hold? take notes, hold people accountable to what they're saying? Or is that kind of just my job to say, okay, cool, we did it, we're good. I facilitated this meeting, I put it on all your calendars, you showed up and do your thing, I'm out, see ya, right? So I think the Scrum Master role as a whole, there's a bit of confusion on that and product or project managers, right? How do we manage those or handle those?
Brian Milner (23:43)
Yeah. Well, the other titles, no matter what other title that you have, first of all, let's separate out. This is part of what people need to understand. Do not confuse job title with scrum roll, right? Because you can have, let's say I'm a project, I'm hired as a project manager, but...
Cort Sharp (24:00)
Hmm.
Brian Milner (24:07)
now I'm gonna be on a Scrum team, I could be the Scrum master on that Scrum team. Does that change my job title? No, I'm still hired as a project manager. So that's kind of the thing that people need to understand. You don't have to have the job title Scrum master or now we're doing Scrum, so now we got to fire our project managers and hire Scrum masters, right? That's not necessarily the case. It's a role on the team. ⁓ So that being said, Scrum defines three.
Cort Sharp (24:15)
All right. Mm-hmm.
Brian Milner (24:33)
It defines Scrum Master, Product Owner, and Developer. It doesn't define any others. It doesn't mean you don't have them. Mike has this phrase that I love. says, the Scrum guy doesn't mention tacos, but it doesn't mean we don't have tacos. ⁓ The one I like to say in class is it also doesn't define a CEO. But I bet you have a CEO. I bet your company has a CEO.
Cort Sharp (24:47)
Right.
Brian Milner (24:58)
It's not saying that you don't need these other roles or that there's no place for them in an organization using Scrum. It's saying Scrum is going to define for you how a single team works. And if you have a product manager, maybe that's more of a scaled thing of how we manage that product across multiple teams. If you have project managers, maybe that's about coordinating information across teams. If you have business analysts, maybe that's helping product owners to write stories. Maybe they are a product owner. I don't know. If you have managers, managers are usually not on a Scrum team unless they're really expert at doing a certain skill. Sometimes I'll see managers who are developers on a team. But the power dynamic is a weird thing on a Scrum team and that's something to be careful of. If you do have someone who is a manager of any kind on a Scrum team, I would, if at all possible, try to make sure that they don't have any direct reports that are also on that same team. They can be on another team with other people that don't report to them, but if you have them on a team with people that directly report to them, now you got this weird power dynamic within this team that's supposed to be a team of equals, but it's not a team of equals because one person's going to fill out a...
Cort Sharp (25:56)
Yeah. Mm-hmm.
Brian Milner (26:12)
performance report on me. So how safe do I feel to say I made a mistake around a manager who's gonna put that on my performance report? That's the danger. ⁓ But yeah, I think you're gonna have any of these other roles. And as far as the Scrum Master is concerned, when does the Scrum Master step in? Well, let me ask everyone listening to think about this question. If you were a parent of a child, when do you step in if you have a child who's doing something that could be harmful?
Cort Sharp (26:21)
Right? Right.
Brian Milner (26:39)
Think about this, I didn't tell you what age the child was, right? If you have an infant, you're gonna step in a lot quicker. You're gonna protect them a lot more. If you have a teenager, you might give them a lot more leash and say, hey, that's your responsibility, right? You know kind of how to do this. And if they insist on doing something a way that you don't think is the right way,
Cort Sharp (26:42)
Mm-hmm.
Brian Milner (27:04)
a certain point as a parent, you have to just say, you know what, this is their lesson to learn. And, you know, they need to have the, I believe very strongly as a parent that you have to really defend your kids' rights to make their own mistakes. And I'm not saying developers are kids, or I'm not saying that, you know, you're, as a Scrum Master, you're the parent of the team. Please don't interpret it that way. But I am saying there's a parallel to this to say,
Cort Sharp (27:09)
Mm-hmm. Right. You
Brian Milner (27:29)
As a scrum master, knowing when to step in is an issue by issue decision. At this instance, how harmful will it be if they do this thing? Is this a kid running out in front of a truck coming down the street? Well, I'm gonna stop that. ⁓ Is this, hey, don't touch that plate, it's hot. I have told you 50 times, don't touch that plate, it's a hot plate.
Cort Sharp (27:35)
Right. Right.
Brian Milner (27:52)
Okay, well hey, maybe it's time for you to touch that hot plate and understand that, hey, next time I'm not gonna touch that hot plate, you know?
Cort Sharp (27:54)
Right. I totally agree. I'm a little more, and I understand I'm a little biased in this, but I'm a little more of a fan of the Scrum Master. The best or a good analogy of a Scrum Master is like a coach on a team, like a sports team is what I'm saying. And the reason I'm biased, right.
Brian Milner (28:12)
Gee, I can't understand why that would resonate with you.
Cort Sharp (28:16)
Who would have thought? I am a, well, recently, I'm a little hiatus right now, but I am a swim coach, head coach, and I think the parallel there is just much easier for me to grasp because think of a coach. You are supporting your team. You're stepping in when needed. You're talking with, whether it's officials or referees or someone that's a little higher up, has a little more authority. than you or your team has in a moment. You're not being disrespectful to them, but you're just communicating, you're conversing, you want to get their understanding and you want to communicate that to your team and work within whatever kind of scope is set there. You're working within the scope of the rules. So I like to view that as kind of like, here's the general organization rules that we follow and standards and practices and all that stuff. But I'm not the one, me personally, I'm not the one.
Brian Milner (28:48)
Yeah.
Cort Sharp (29:09)
jumping in the water and doing the races, right? I'm not the one out there on the court, dribbling a ball up and down. I'm not the one out there on the field tackling people, right? I'm there to help the team formulate a plan, help the team execute that plan and help the team really just do what they can't or remove as much of their stress as possible so that they can only focus on doing their job, which in the coaching space is
Brian Milner (29:15)
Yeah.
Cort Sharp (29:36)
sport coaching space is let the team go out and swim, let the team go out and play football, let the team go out and play basketball or baseball or softball or whatever it is, right? Let them do their thing. You're there to help them and make their day on game day on meat day as easy as possible and as seamless as possible for them. So there was there was something that you said there to Brian that kind of got my gears gears turned a little bit.
Brian Milner (29:55)
Absolutely, Kreen.
Cort Sharp (30:02)
You were talking about how the kind of power dynamic, if like a manager is on a team and someone reports to them, there's that power dynamic there. But you said that everyone is on an equal playing field within Scrum. we're all on the same level within our team. We might have different roles, but we're all on the same level. And that kind of got me moving into like, what have you seen that one kind of helps establish that we're all on the same team, we're all on the same playing field, we're all working together, you I might be the product owner, so I might have a little, or I do have guidance over here's the direction we're gonna go more so than maybe the Scrum Master does with the product development itself. But how do you kind of build that trust within a team to be able to say, yeah, I see you, Cort, as an equal contributor here, even though you're the one saying, We're going to do, we need to do this, this, this, and the other thing in the next two weeks. cause I see a lot of, I see a lot of questions about that. see a lot of struggles with that. And I think that's a very common issue that a lot of people face within a scrum team. Because again, it is so different from, I report to my manager. You don't report to your scrum master. You don't report to your product owner. You sit down and have conversations with them. So how do you, how do you kind of foster that and facilitate that? that type of environment.
Brian Milner (31:25)
Yeah. Great question. And like the kids used to say a while back, there's the rub. You know, that's kind of the key point there. There's a thing we say about Scrum where we, a lot of trainers and coaches will say this, Scrum is simple to understand, difficult to master. And that is precisely what's meant by that. And that's kind of some of the stuff that we try to capture in this working on Scrum team. Class is is that difficult to master portion because? You know, how do you how do you gain trust from someone else? well That's not in the scrum guide, right? I we're not gonna be able to you know, look that section up and say here's the rules on how you You know start to trust someone else that you're working alongside That's a difficult thing How do you do it? Well, it takes time You know, it's like a any kind of any other kind of relationship you have with another human being, you can't walk in from day one and say, hey, we're going to now have this deep trust with each other. You have to extend it and you have to earn it. That's the way that it's built. And that has to happen over time. You have to display that I have trust in you and I'm worthy of your trust. So when you put your trust in me, you can count on me. I'm going to be here and I'm going to do what it is you expect me to do. That's really the only answer that works for that. it's difficult. is the human working dynamic, I think, is the undervalued kind of glue that holds a lot of this other stuff together. ⁓
Cort Sharp (32:52)
Yeah. Mm-hmm.
Brian Milner (32:55)
And it's that kind of stuff that a good scrum master, I think, can really make an impact on because, hey, they're not just going to know a time box. That's kind of just Scrum 101. But they're going to also know, well, what happens when I have two team members who get into a big conflict, who disagree? My hand's off, and I just let that run. And all of a sudden, now we have a team that splits, that fractures along that line.
Cort Sharp (33:05)
Right. Right. Yeah.
Brian Milner (33:23)
Or do I get roll up my sleeves and get involved and have the skills to help them navigate that conflict and come back as a team without resentment, without losing trust in each other, but really working honestly with each other and being productive when we come back. That's the difficulty. And like I said, that's something we tried to capture when we kind of created that working on a Scrum Team classes.
Cort Sharp (33:23)
Right.
Brian Milner (33:48)
And what are some of those more subtleties of nuances that really are the heart of whether the team is going to work or not?
Cort Sharp (33:57)
Right. think even, even beyond just what do these look like? I think the way I view a working on a scrum team is it's for everyone on a scrum team, right? It's not just for scrum masters. It's not just for product owners. It's not just for developers. It gives you a big picture. Excuse me. Sorry. It gives you a big picture of how, how effective you can truly be when you are.
Brian Milner (34:18)
Yeah.
Cort Sharp (34:25)
working together on a Scrum team, right? You were talking a little bit about the human working dynamic or nature, one of those. And as soon as you said that, I was like, we should double click into that a little bit. But very briefly, maybe double click into it a little bit of when we work together and humans are working together and not working in siloed environments, not saying, hey, I'm the front end developer. I did my mock up.
Brian Milner (34:31)
Yeah, yeah.
Cort Sharp (34:52)
I'm out, I'm done. Figure it out everyone else. you're, struggling with your database stuff. Tough. I'm done with my thing. I'm going to sit back and sip a, sip a cool lot on, on Tahiti's beaches or whatever. Right. We're not doing that. We're, we're helping each other out. We're working together and we're saying, okay, cool. You're having database issues. I don't know anything about databases, but maybe I can help look up some stuff or I can find some. help you out in some way that isn't inhibiting you from doing your job. But it might not be like doing it. It's definitely not doing your job for you. And it's not like it's a, I know everything about databases or I know enough about databases to be able to get by. It could be even as basic as, you run into this error code. Cool. I'll look that up for you and send you the results and save you a little time, hopefully that way or something. But it's that team collaboration, it's working together as a team. I like the perfect example, which I'm pretty sure we talked about this in working on a Scrum Team course as well, of developers and testers working together in tandem and saying, instead of, we like to say, developers finish their code and then we throw it over the proverbial wall. And all right, testers, you got to catch it, figure it out. and then test it, developers maybe sit side by side with testers or hop on a call, not too dissimilar from what we're doing here, just hop on a call with each other and say, let's figure out the verification that the password meets the requirements. Okay, cool, tester, you want to write up the tests, I'll start developing or working on the code for it. Awesome, here's my code, here's my thought process. Do you have any thoughts, Tester? Do you see any edge cases right out of the gate that I should keep an eye out for or work on? I think that is the bigger picture that working on a Scrum team really highlights and really focuses on and allows a lot of people to kind of open their eyes a bit more and see the forest through the trees, so to speak, to be able to understand here's the value and here's what it actually means to be working on a Scrum team rather than just here's my role. I'm gonna go do my role, do my thing and see everyone else figure it out.
Brian Milner (37:08)
Yeah, not that it ignores the basic components and the ground rules that help us, but it goes beyond that to say, how do you actually make this thing work? So yeah, that's a great point. Well, this has been really useful. I really appreciate you taking time to do this, Court, and coming back. And I'm sure we'll do this on a periodic basis, just to check in and see, hey, what are you hearing now? What are the hot button issues now? So.
Cort Sharp (37:18)
Absolutely. Yeah. Yeah.
Brian Milner (37:32)
Thanks for sharing that and keeping your ears open and continue to do that so we can do more of these.
Cort Sharp (37:39)
Hey, happy to Brian always always fun just seeing what's what's going on out there. What conversations are are being had. And I hope this actually like help someone. Right. I hope this this helps solve either clears up some confusion about, know, maybe what the daily standup is for, what the daily scrum is for, who it's for. Hopefully it doesn't add more confusion. But if it does, you know, you know where to go. Right.
Brian Milner (37:59)
Hahaha. Exactly, All right, thanks, Cort.
Cort Sharp (38:05)
Yeah, thanks for having me.

#156: Making Product Ownership Work in Shared Services with Kert Peterson

Shared services teams often wonder: Does product ownership still apply here—or are we the exception to the rule? In this episode, Brian and Kert Peterson explore how Scrum principles hold up when value isn’t always customer-facing and demand never stops.
Overview
In this episode of the Agile Mentors Podcast, Brian welcomes back longtime friend and mentor Kert Peterson for a deep dive into what product ownership looks like in a shared services environment.
They explore the practical realities that differentiate shared services from traditional product teams, from endless stakeholder requests to the challenge of defining “value” when your users are internal. Together, they discuss the importance of proactive leadership, strategic alignment, and understanding who your real customers are. Kert also shares tools for improving intake, applying an experimentation mindset, and closing the feedback loop, even when your work is abstracted from the business’s end goals.
Whether you’re a product owner in infrastructure, data, middleware, or internal tools, this episode will help you reconnect your team’s work to the outcomes that matter.
References and resources mentioned in the show:
Kert Peterson
#9: Scrum Artifacts with Kert Peterson
#12: Kanban with Kert Peterson
What Happens When For Product Owners
Subscribe to the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast 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.
Kert Peterson is an experienced Agile coach and trainer who bridges the gap between business strategy and technical execution. With a background spanning engineering, marketing, and management, he’s helped teams at Amazon, NASA, and Capital One launch Agile practices that actually deliver.
Auto-generated Transcript:
Brian Milner (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you here as always, Brian Milner. And today I have one of my dear friends with me, Mr. Kert Peterson is back. Welcome back, Kert.
Kert (00:13)
Thank you, Brian. It's great to be back with you.
Brian Milner (00:16)
Love having Kert on. Kert is one of my mentors and actually first person I ever came in contact with when I was trying to become a CST. He kind of showed me the ropes and took a lot of time helping me to understand how to do this thing. So I have a huge debt of gratitude to Kert that I can never repay. But wanted to have...
Kert (00:33)
It's funny, Brian, let me just say I have the same debt of gratitude to Mike Cohn. So it's funny, it's coming full circle.
Brian Milner (00:37)
That's awesome. That's awesome. So, but we wanted to have Kert on because we want to talk about something that we I know I've heard a lot of questions about in class and it's a big topic of conversation. And that is, you know, when we talk about working in the area of shared services, you know, how does product ownership fit and work into that area? Does it fit and work into that area? Or do we find the exception? Is this the place where product ownership just all of a sudden is not able to provide any value? So Kert, that's a huge big ball of yarn to unravel there, but what comes to mind when you think about this?
Kert (01:18)
Well, I think back to the origins, what inspired the Scrum framework, which was Japanese product companies in the late 1970s doing things differently, using this sort of rugby approach and getting cross-discipline groups together and seeking to innovate and reduce time to market. So when I think about product ownership arising out of that context, it's very clear, right? There's a printer that I want to get better at. I want to take a Canon EOS Rebel and I want to make the next generation of it, or I want to take the Honda Civic. And I want to improve the way it shifts or whatever. And so there's a lot of clarity. And I think, I would say an easy vision to sort of begin to form and coalesce around the direction we're moving in. And the shared services groups I've worked with, whether it's middleware or data people or cybersecurity folks, they just experienced this constant deluge of requests from a variety of stakeholders, dozens, if not hundreds of stakeholders. And it feels like they're always operating tactically. helping those product owners that they're leading shared services teams to shift out of the tactical and begin to think more strategically and begin to get more, I guess, proactive about how they meet requests and what they're going to offer and how they're going to offer it is sort of a challenge that I think I see many of my customers and clients up against.
Brian Milner (02:37)
Yeah. I think one of the things I hear quite often about this is it's sort of, you know, cause and for example, a product owner class or something like that. We'll talk a lot about understanding your customers and, and mapping out kind of personas and other things and how that influences our idea of value. And then how you, kind of rank value according to your backlog. And that, that to me is kind of where one of the friction points here in shared services is you've got these demands coming at you. all day, every day from all these different corners and from everyone, it's urgent. From everyone, this is the most important thing. So how can you apply some of this product ownership mindset principle to scenarios where everything is urgent?
Kert (03:21)
Yeah, you those fundamentals, you know, when something's coming in, how do we weigh it against other opportunities? And usually we want to do so financially. How do we kind of begin to assess this particular request or opportunity against others? And when I teach product owner training in person, I hand out these little plastic covered pictures of currency. So I'll have like a yuan from China. I'll have a euro, I'll have all these varieties of currency and I won't, I make them kind of cryptic. Like I'll choose one from, you know, maybe one from Mongolia. And so I put this currency in front of them. say, okay, rank these in order of value, you know, translate it to U S dollars, which one's most to least important. And they struggle because I don't let them look at their phones and they have to, you know, sort of think or be creative. And at the end of the activity, they realized, wow, I don't have a system for translating this currency into the currency that's universal, which is US dollars. And it gets them, it sort of sets the stage for this idea of scoring, you whether you're using rice or some other scoring method, it sets the stage for that conversation, which is critical. How do you objectively assess what's coming in and make the choice on the next best thing to build? Yeah.
Brian Milner (04:36)
Yeah, that's a great exercise. I love that because it's a great picture there to understand as a product owner, you can't make those decisions in a vacuum. If you don't have the background, if you don't have the knowledge, if you don't have source information coming in, then no, I can't rank currencies. I've got to have expertise in those areas to help me understand those things. So yeah, I love that exercise. That's awesome. One of the other things I hear quite often in the shared services space is kind of the idea of, maybe this stuff is, maybe Scrum doesn't work as well in a shared services space because of the immediacy of all this stuff. And maybe we have to do Kanban versus Scrum. What's your opinion there?
Kert (05:18)
When I was at Capital One many years ago, shared services teams were adopting Scrum because that was the only game in town. This was 2005. really Agile was sort of very closely connected to Scrum because the Scrum and XP communities sort of were the members of the Agile Manifesto. And what Scrum teams end up doing is they say, you know, we're going to have a sprint planning session and we're going to plan 10 % of our capacity for something that is doable. And we're going to reserve 90 % for unplanned work. that's coming at us. And I see Scrum teams that retain Scrum and that want to leverage Scrum for shared services really just allow for a huge buffer of flexibility. But they also start to get curious about, you know, over the last two weeks, we left 90 % of our capacity open. We used all of it. And here's the top three, you could say offenders, right? Top three requesters, top three sources of demand. And they really begin to get good at tracking where their money's being spent as a team. So they can go back to those stakeholders and say, look, if you want us to continue to serve you, give us some more funding. So I think Scrum teams can excel in shared service. You're applying Scrum in shared services. I just think there's some nuance to it. That's been my experience. I'm curious what you see too.
Brian Milner (06:34)
Yeah, no, I think that's a great point. I think that 90-10 kind of thing, the thing that concerns me or that I always try to raise with people is the whole concept of transparency and trying to understand the reality of what's behind this. So you make a good point. If we have top three offenders of people who are the people who constantly requesting things from us, it's important, I think, to stop and look at those things and say, how many of these things were things that could not have been foreseen or things that we could not have planned in advance. And how many of these things are things that really were just kind of urgent pop-up day by day, we've got to handle these things as they come in. And don't take for granted, I don't think would be my advice to people that all the things that people are requesting of you are kind of urgent day by day things. There's probably a lot of those things that could have been foreseen and could have been planned. But it takes kind of that after action of retrospecting and trying to figure that out to know the difference.
Kert (07:34)
Beautifully put, I totally agree.
Brian Milner (07:37)
Yeah. So Kert, what are some of the other big challenges that you've heard from people in the shared services space when it comes to just using Scrum?
Kert (07:45)
Well, one of the biggest challenges that I've seen and one of the things that I think is a great solution I heard from one of my mentors, Kevin Rosengren, who worked at Capital One for many years. I worked with him at Applied Frameworks and he's now an airline pilot. He loves to fly. And so he's back doing that commercially. But I worked at Mission Health in Western North Carolina for, I was a contractor there working with the application support team. And I kept using the word intake management. intake management and Kevin got really his kind of the back, back, hairs in his neck kind of bristled and his hackles went up and I'm like, come on, Kevin, what's, what's wrong with intake? And he said, intake implies passivity. You're just kind of standing there waiting for things to come at you. He says, I want my product owner to be proactive. I want them to have a vision, a mission. want them to be out in front of the problems. And so I think one of the biggest challenges for shared services is really, taking ownership of the team. And really be a financial custodian for the investment that the company's making in that team and being more proactive in Kanban. We have this term called shaping demand. And this idea of shape demand implies proactivity. So I'll give you an example. was it Collins aerospace working with a middleware team and they did some demand analysis. They kind of diagnosed their backlog, what's in it. And they, they started to realize they weren't tracking an important backlog item. speaking of kind of unplanned work, there are people with ask him for advice or consulting and they realized over a period of weeks or months that a lot of their capacity was kind of leaking or going out via these, just these consulting hits that they took. Give us advice on this, give us advice on this and it may be three hours here, four hours there, but it would add up and they realized, Hey, we can get more active. But we create a knowledge base. If we have some protocols about how we receive this request, if we make them fill out a form. So those are some. some aspects of really taking ownership of your service and requiring certain, you could say, information or maybe levels of respect coming from the requester that begins to help you feel like you have more power than you might have thought last week or last month. Yeah.
Brian Milner (09:55)
Yeah, that's a good distinction because I agree there is sort of this reactive nature sometimes to that work. if I'm a, I don't know, if I'm a backend shared services team and we're fulfilling requests on a daily basis of people to build servers and install things or whatever, it can feel an awful lot like we're just reacting to what people are giving us. So that, I agree, that's a huge challenge of, know, when you're that kind of product owner, how do you come up with a vision? How do you understand, you know, I get those questions all the time, especially if you're in things like sprint goals, you know, those kinds of things. You know, do we have a sprint goal when what we're doing is just kind of taking things in and responding to people? What do you think are the keys to people becoming more proactive than reactive as a shared services team?
Kert (10:48)
Yeah, that's that I think therein lies the challenge, Brian. I think that's a real challenge because I do think that things come at you and it just feels like you you're a ticket taker, right? You're you're you're just under this deluge of constant work and it's very tactical and it's very kind of, know, it doesn't it lacks sort of that that sense of purpose drive and the ability to say no. Now, some demand is going to be irrefutable, some demand you just have to say yes to. But I think more often or I say There is definitely a category of demand that you should be able to parse through and determine if it's for you and if it fits with the strategic goals that you've been situated, that you've been assigned or your mandate, so to speak. Gosh, it's shifting from, it's kind of like, how do you shift from that fire fighting mode to fire prevention? And I think there's a piece of that is kind of.
Brian Milner (11:35)
Right, right.
Kert (11:37)
I call it scrambling up to the crow's nest, you know, in the old pirate ships. And you've got to have at least someone on the team that's looking out and seeing the big picture and understanding the strategic goals of the business and how we as a shared services team can begin to serve them. But I don't have a, it's not easy because, you know, I think when I was a product owner at Amazon in the early days, and there was a very clear, you know, there was very clear missions like let's grow the number of wishlist creators or number of wishlists in the community. And so there was a kind of a clear, you could say marker and a clear direction for what you're up to. You're serving the community. You're doing things to populate the community, get people more connected. I think there's a lot less clarity and you have to kind of hunt for it, I would say. And I think it does take I think one of the challenges for shared services leadership is to be more connected to the business and to recognize themselves as a more integral part of the business and the ability to actually affect business outcomes. I think, so anyway, connecting to the business and getting those shared outcomes in view, think is a part of that puzzle.
Brian Milner (12:44)
Yeah. Yeah, I think you're making a strong point there because I agree. That's sometimes I think the challenge in that space is you do feel sometimes very disconnected from the business goal because it's not as clear as gain this new set of customers or service this new clientele or anything. It's more support based. It's more infrastructure based. If we don't do our job in that space, then we can't enable the other groups to do what they do well. But that's a layer of abstraction really, even from what the business has as its goal. So I think that's an important point is, if I'm that kind of product owner, I want to make sure that what we do is tied into the business objective and trying to understand fully what it is we're trying to do as a business and how we support that. We talked to, I mentioned a little bit earlier about customers and that being kind of a friction point of understanding customers. And how do you, how does that relate in your mind when you're in a shared services team? Do you, there less emphasis on trying to understand who your customer is if, know, from product ownership, uh, kind of discipline, uh, or, or is it just as important and we were not really understanding what we. should be classifying as our customers.
Kert (14:07)
I think it's the latter, Brian. I definitely think it's the latter. When I was working with this 50 person division at Mission Health, I Mission Health got acquired a couple of years ago, there were requests coming from every department in the hospital system. mean, there was clinics, there was oncology, there was radiology, there was all this, there was this huge landscape of stakeholders that, again, felt like my thing's the most important. And understanding each customer or segment of the, you could say the market, right? The 10,000 person healthcare system was really critical to sequencing work and shaping work and to timing, determining how to kind of decompose it. And so that was a really vital piece. what, you know, I think about a few weeks before I left Mission Health, there was a really strong move from the leader there, Joel, to create what we call strategic engagement partners, which really were these proactive individuals that would go out into the landscape of the hospital system and begin to profile the oncology clinicians or the oncology physicians. And so by doing that, it started to kind of get them to put a finger on the pulse of the bigger, really the customer, which was a variety of customers, but it also helped them recognize, okay, this quarter we're, As a healthcare system, we're falling way behind in MRIs or radiology services. And so we better give some extra attention to that. So let's ensure that that's part of our goal this quarter. And so it really, that strategic engagement with the customer is, think as critical as it is when you're selling a camera or a car. Yeah.
Brian Milner (15:43)
Yeah, yeah, that's awesome. That just brings to mind as well then the idea of making closing that loop with your customer to understand whether what you're doing is actually making impact or not. And I think you gave a good example there, but what about if your shared services team is kind of more internal? And like I said, if we're installing servers, If we're installing some big network system or something, and that's what our team does in various places, how do we close that loop in a more productive way and really make sure that the work we're doing, even though it's somewhat repetitive, even though it's abstracted from your end customer, how do you make sure it's actually doing what's needed?
Kert (16:26)
Yeah, that's, I love that question, Brian. It's a fantastic question. So I live in Canada. moved here, moved here five years ago. There's a data center of excellence, data center of excellence for the government of Alberta. And, the leader of that data center of excellence, a guy named Donnie, he, he came to one of my product owner trainings and he started to kind of put pieces together that I want my 30 person data team to be equipped to not only go out and service, you know, the community of the ministries. there's like 26 ministries. like health, education, kind of like departments here in the US to service them, but also to help recognize that what we're providing is impacting the bottom line of the ministries. And in some cases, it's harder than others. I mean, I'll just like the Ministry of Health Care, for example, if a data center of excellence can go in and be a strategic partner for that data for the health care ministry, they can begin to formulate.
Brian Milner (17:14)
Yeah.
Kert (17:24)
a strategic plan for how they use data. They can begin to equip them with dashboards and other information, other data products, and they can tell a story to the bigger organization that's allocating funding for the data center of excellence. So his drum that he beats is he wants his people to be able to go in and engage strategically and be able to tell a story about the impact they have. Now, some industries are so busy and so inundated with work, they just want a dashboard. Be a ticket taker, give me a dashboard, and don't bother me with strategic stuff. And those are much harder to kind of draw the connect the dots between business impact and our efforts. But there's going to be a subset, I think, of requesters or customers that you're going to be able to start to build a relationship and tell a story. And then those customers become indispensable to, they can become part of your testimonial.
Brian Milner (17:55)
Yeah.
Kert (18:15)
they become indispensable to you justifying your existence the next annual budgeting cycle, so to speak.
Brian Milner (18:21)
Yeah. Yeah. That's so good. One of the other areas I'm thinking about as we're talking about this, because there's a lot of content that comes across in the product in our class about the idea that we should be in an experimentation mindset and look at the things in our backlog more as experiments. We're running these things trying to see if they're going to solve the bigger problem. And then if they don't, we find another experiment. Sometimes I hear a lot from people in classes that are in more shared services places that they have a harder time finding how that would fit in with what they do. It doesn't feel like experimentation. feels like, like we've talked about kind of more order taking. So how does that apply, Kert? How do you, how do you, if you're a product owner in that space, how can you take more of an experimentation mindset if you're in shared services?
Kert (19:10)
Yeah. You know, I love this question. I've never heard this question, Brian. And it's, it's a great question. It's, it's, it's taken me deep down deep, deep thinking about product ownership. I'll throw out my, my, my, I'll kind of expose my thinking and it, cause I don't have, direct experience that I could point to in sort of this experimentation, the application of this mindset to shared services. I can imagine, can imagine if you have a customer that comes and says, you know,
Brian Milner (19:14)
Hahaha. You
Kert (19:39)
I want a purple minivan. And you're in that mindset as a shared service provider, you're going to want to discover the underlying need and sort of begin to kind of tease out, you know, what is it that you're trying, what problem are you trying to solve? What is it that you're after? And maybe, you know, we've all seen that famous, you know, iterative incremental picture of, you know, the skateboard, then the, you know, what is the... thing with the handles on it and then the motorcycle and a bicycle. So that evolution of solutions you could say. And I think if you're in that mindset, you're going to say, Hey, I know you want a pink minivan or a purple minivan. Let's start with, you know, this, which is, which is going to move you in that direction, because I know what you're doing is trying to solve this problem. And let's start with that. And let's see, let's see how it goes. You see, you're enlisting the support and partnership of your customer or requester. And so it takes that willingness to kind of be in a.
Brian Milner (20:03)
Yeah.
Kert (20:30)
experimental mindset with the shared services provider, I would think. So that's my thought. don't know how that question lands for you, but it's a great question.
Brian Milner (20:38)
Yeah. No, I mean, I think this is kind of central to what we're talking about here because, you know, I think there are going to be things that, you know, are just needed and there there's not really going to be an exploration of those things. If we have a government regulation that says we've got to do this and you've got to have this in place by this date or whatever, that's That's not up for question. I don't need to run a rice, you know, kind of a prioritization on that because it's needed, right? It's unquestionable. But I think that sometimes it's sort of that line in product ownership of, I think it's very easy if you're a product owner in the shared services space to maybe shift and consider everything as a needed thing, as being an order taker. And if that's the case, then yeah, you kind of, you kind of abdicate your, responsibility in that case of understanding and prioritization and everything else, because you're just kind of giving it to the people who are demanding things from you. And I think that that's there's, there's a balance there. There's a yin and yang. I think because you've got to understand some of those things are that way. And there are some things that are not. And the things that are not, I've got to understand, as you said, the core need behind it. Because it's very easy to have your stakeholders turn you into just an order taker. And if you allow that to happen, your stakeholders will run over you. But you've got to keep that wall, keep that boundary up, I think, if you're a product owner in that space, to be able to say, now, wait a minute. You're saying you need this. Let me understand why, help me understand what's behind this. What is it that you're trying to do and accomplish with this? It's the whole how versus what kind of discussion, right? We have to understand the how behind it, or we have to understand the what behind it so that we can then talk with the team and find the best how. But if we don't go through that extra work, then I think that we just.
Kert (22:34)
Yeah. Yeah.
Brian Milner (22:51)
quite simply become order takers and get overwhelmed with the volume that's coming at us.
Kert (22:56)
Totally agree. And I think data teams are a prime example because of course everyone these days wants a dashboard. Give me a dashboard. I need a dashboard. And the probing and sort of the con I call it a consultative approach. The consultative hat you wear to go in and discover what's underlying that request. And like you're saying, what is it you're really wanting and why and what need are you trying to, you know, kind of achieve there is often I say undervalued.
Brian Milner (23:01)
Yeah.
Kert (23:22)
And often, you know, not seen because they're under such a deluge of just, you know, okay, just get them something and make them go away. And I think there's a desire to have, I mean, Donnie wanted sort of everyone in the team, his 30 person team to have that capability or that sort of consultative hat that they could wear. And I think that can come with time, but I do think that there's some people, you know, in that What we recognize was in that 30 person team, there were probably six to eight folks that were really sort of ready to step into the role of product owner. And so I think one of the things that's important in any team, specifically in shared services teams is to recognize there's going to be people or a person or people that are sort of inclined towards, you know, being a great listener, being consultative, thinking strategically and sort of bringing, you know, having kind of, I don't like the word gatekeeper, but sort of manning that front gate and ensuring that what's taken in is well understood and well shaped and all that sort of thing.
Brian Milner (24:20)
Yeah Yeah, I agree. don't like gatekeeper as well, but there's a judgment element, right? I mean, you've got to apply judgment. And that's quite frankly something that only humans can do is to apply judgment to decisions and understand the story behind the data. Well, this has been great. I really appreciate you coming on and talking about this topic. As I said, this is something I hear questions about quite often in product owner classes, because there's a huge number of product owners out there that are in this space and sometimes feel like the redheaded stepchild. Maybe we just don't fit in. But I think you made a strong case here. I think there's a lot that can apply.
Kert (25:07)
So, so Brian, I'm really curious when you think about great product owners. I feel like my question to you is, are they made or are they born great product owners? Do you have any thoughts? Like what comes to mind when you think about that question?
Brian Milner (25:16)
Ha ⁓ yeah, I mean, there's, there's, there's talent and skill, is what comes to mind. And I think that we all have some natural abilities in different areas, but I think we all have skills that we acquire and learn and there's discipline to it. There's rigor to that. There's a process to it. And I mean, I, you know, I think there are our product owners that have talent, ⁓ that are, that's kind of innate. but for me, it's mostly in areas that's, things like communication, right? If you're, if you're a poor communicator, ⁓ you can improve your communication skills, but, ⁓ you know, you see this in politicians and things in certain times. I talk about certain politicians as being just really good communicators naturally. Yeah. They, they've, they've studied communication and understand how to do it better. but they had an innate skill in that area already, or innate talent, I should say, since I'm differentiating between the two. ⁓ But yeah, I think I would lean more towards like maybe 90-10 skill over talent, and that it's, you know, it is a lot of practice and learning and discipline that we just, need to study and know our craft, you know, it's a craft. And I think we have to improve on that and get better at it. But yeah, I mean, in this kind of work, think I wouldn't put too much emphasis on the talent side of it. I think that there is some innateness that can be useful, but ⁓ I kind of lean much more to the skill area.
Kert (27:06)
Yeah, yeah. So Donnie's got this 30 person team and he suspected there were six to eight that were suitable candidates to kind of go into a multi-week cohort to kind of become sort of more seasoned or sort of competent product owners. If you had 30 people in front of you and you were asked to choose the six to eight that are most suitable for a product owner program, would you have any thoughts around? how you would do that. mean, I'm guessing you probably wouldn't draw straws, but
Brian Milner (27:38)
No, I mean, I think it comes back to some of the things that we talk about. ⁓ Whenever I go into an organization and try to figure out who's the right product owner for this product, it comes down to a few common things. First of all, do they have the domain knowledge for the product? Do they know enough about that product to be effective, know about the market, the customers, those kind of things? Do they have the availability to do the job? ⁓ Are they constantly going to be involved in other things? Are you splitting this person between 10 teams? ⁓ And then are you going to be able to give them the authority that they need to make the decisions that they need to make in that role? ⁓ if I was trying to decide which is the right person, that would be the rubric I would be using is trying to say which one of these people match best for this product.
Kert (28:34)
Right on. Cool. Thanks, man. Thanks for entertaining that last topic.
Brian Milner (28:39)
Yeah.

#155: Preparing for Interviews the Agile Way with Tali Shlafer

Even the most capable professionals can struggle in interviews. In this episode, Brian and job interview coach Tali Shlafer break down why, and what to do instead.
Overview
In this episode of the Agile Mentors Podcast, Brian welcomes interview coach Tali Shlafer for a practical, clear-eyed conversation about how to approach job interviews as a skill, not a personality trait.
Tali shares why being great at your job doesn’t automatically translate to interview success, especially in collaborative fields like product development, Agile coaching, and project management. She outlines a straightforward way to prepare for interviews by identifying the real challenges behind a role and building stories that speak directly to them, without sounding rehearsed or robotic. From reframing “bragging” as problem-solving to handling tough questions with clarity and self-awareness, this episode is full of grounded advice for professionals navigating their next move.
References and resources mentioned in the show:
Tali Shlafer
Free Job Interview Tip Vault
Tali's LinkedIn
Tali's Instagram
#93: The Rise of Human Skills and Agile Acumen with Evan Leybourn
#111: Adapting to the Future of Work with Heather McGowan
Blog: Entry-Level Scrum Masters: Seven Tips on How to Get Your First Scrum Master Job by Mike Cohn
AI Prompt Pack for Product Owners & Scrum Masters
Subscribe to the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast 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.
Tali Shlafer is a certified interview coach who helps high performers turn nerves into clarity and confidence so they can land roles they’re truly excited about. Her practical frameworks—rooted in psychology, communication, and performance—ditch the gimmicks and empower candidates to show up as their best, most authentic selves.
Auto-generated Transcript:
Brian Milner (00:00)
Welcome in everyone. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have Miss Tali Schläufer with us. Welcome in Tali.
Tali Shlafer (00:11)
Thanks, Brian. I'm excited to be here.
Brian Milner (00:13)
Very excited to have Tali with us. She is a job interview coach so you can kind of See the direction we're going in here one of her tagline is that she she helps you know professionals get offers they're really excited about and She's got some really interesting insights here because I know in today's world in today's environment There is a lot of shifting going on. There's a lot of transitioning between different places of work. And that interview is always kind of the forgotten portion of it, right? You get past all the other stuff, you get to the point where you're in the interview. So Tali, from your perspective, I know you see and help a lot of people with that portion of it. What are some of the biggest mistakes that people make that you see routinely as you help people prepare for their interviews?
Tali Shlafer (01:01)
Yeah, absolutely. I think one of the things that you just mentioned where, you know, people really struggling with the interview piece, you do all this work in your job search to update your resume, update your LinkedIn network, all this stuff, and then you get to the interview and it's like, okay, we're close. It's actually the interview is actually a completely different stage than anything else. And one mistake that I often see people making is just the mindset around interviews. A lot of people think, if I'm great at my job, I'll just interview really well. Like I'm a top performer. I'm good to go. But interviewing is actually a skill that's completely separate from anything else we do in the workplace. It requires you to be able to articulate what you've done in the workplace and the results and the impact that you brought in a way that most of us don't have to do in our day-to-day jobs. And you have to do it better than everybody else. So just because you are a top performer doesn't necessarily mean that that translates into your ability. to talk about yourself and talk about your career, especially in a way that resonates with the specific job culture and the specific job that you're applying for. So I think that's kind of the top mistake that I would just from a mindset level, is seeing interviews as something that you're naturally good at rather than as a skill that you can really develop and build in order to set yourself up for success.
Brian Milner (02:12)
Yeah. Yeah, that's a great point because, know, just because, as you said, just because I'm a top performer in something that I do, have a huge skill set or knowledge area that I'm really good at, doesn't mean that I'm necessarily good at an interview process because it is kind of a whole set of other communication skills that you have to have in that kind of environment. I know when I've talked to people about it sometimes, they feel sort of this, I don't know, dichotomy a little bit back and forth about... I know I'm supposed to plug myself here. I know I'm supposed to kind of brag a little bit, but I also don't want to sound cocky. I don't want to sound, you know, I don't know, just brash or anything. How do you help people or what do you advise people about in that area?
Tali Shlafer (03:06)
Yeah, and I think this is really common for people who are top performers and people who are very team oriented and collaboration oriented. It's really difficult for those folks to go, hey, I did all this stuff by myself and to kind of put themselves in that spotlight. So it's a very common challenge. It's also very common for folks who are really good at their job and have been doing this for a long time to actually be able to articulate. what that secret sauce is, like why they're actually good at their job, which is part of the challenge. Remind me the question that you just asked.
Brian Milner (03:38)
No, I'm just, in talking about kind of like how people prepare for these kind of things, the way they communicate this stuff, sometimes it's kind of more this worry about am I being a little too overbearing or brash in how I'm bragging about myself? Will I come off seeming cocky? or overconfident, how do they walk that fine line?
Tali Shlafer (04:03)
Yeah, I think this is a really big mindset piece where a lot of people who are those top performers and are very collaborative in nature are afraid to talk about themselves and be in the spotlight and kind of take credit where, especially in something like in the agile world or project management, product management, it's a very collaborative space. people are afraid to like, people are afraid to say, here's what I did. And Part of the mindset shift that I really encourage clients and job seekers to have is rather than to see it as, hey, the interview is all about you and the spotlight's on you and you're a used car salesman trying to promo yourself and it feels really icky so we don't want to do it. We end up not doing it at all. Think of it rather as you're trying to help this employer solve a problem. You're on the same side of the table with them. You're essentially a consultant for them. Their problem is... Hey, I've got this role. I have this challenge in my company. I have this opportunity. I have this thing that I need help with and I need to find who's going to be able to help me do that. And so you're essentially being an advisor for them and sharing here's how my previous experiences and what I've done in the past might be able to help you with your challenges. So it's really, it's really a partnership type of conversation where you're exploring, well, what are you struggling with? and how, let me share ways that I think I might be able to help. I think having that mindset is a lot more helpful for people who are more collaborative in nature. I think there's also a part of it that is getting really clear on how your work has actually delivered results. Being really confident, a lot of folks who are more collaborative in nature, which is a lot of people that I work with. tend to really get stuck in the we. So they say, we deliver this, we manage this, we strategize in this way. And then the interviewer ends up losing the thread of, well, what did this person sitting across from me do? What did they lead? What did they manage versus what did they do collaboratively? so getting really clear and even getting some language around how to talk about your contributions with respect to the team. So saying, I led this strategy session or I facilitated the collaboration of this, or I made the suggestion to people who then made a decision. Those kind of nuanced pieces of communication can help us feel more comfortable with actually owning our story in a way that doesn't feel gross.
Brian Milner (06:39)
Yeah, I think you make a great point there about the partnership aspect of it because having been on both sides of the table there, I know when I was hiring people as a software manager of some kind, the thought is always when the person comes in, you want to hire them. When they've reached that stage, when you finally bring them in, you're excited about the people that you decided to bring in and you're pulling for them. You want them to actually be successful. So I think it's important to keep that in mind too, that they want you to be successful. They want that role filled or they wouldn't have put out the job wreck and all the other things. If you, so let's just kind of talk through on a practical level. If you, you've done the work, you've put out the resume, you've got the call, maybe you've even gone through, well, I guess we should talk about that as well. Kind of the difference between a virtual or phone interview and an in-person interview. Is there a difference in level of prep or in how you, you know. tricks to being more successful if it's virtual versus in person.
Tali Shlafer (07:50)
I think the preparation itself should be the same. At the end of the day, your preparation should be about what are the challenges that this company, that this organization is facing and how does this role help solve those challenges? What are the skills? What are the top five skills that I need to demonstrate? Hard and soft skills. And in order to show them that I can be the top performer for this role and what are stories that I can share for each one of those skills. to prove that, I have what it takes, I can actually walk the walk as well. I've gotten results in this area before. So the prep work itself in the days leading up to the interview should be more or less the same. I would say the difference between a virtual interview versus an in-person interview is just people's comfort level. I think a lot of people are really comfortable in in-person interviews because it feels like you're actually talking to a human, right? You have a full-size person sitting across from the table from you. So it's a lot more comfortable. And I think even though through COVID, we had a lot more virtual conversations, there's still a very performative feeling element to it when it comes to virtual interviews. So one of my top tips for virtual interviews is please turn off your self view. So if you're in the Zoom call and if you're in a meeting, because it makes people so nervous and self-conscious. So when you get on that Zoom call, that Teams call, whatever platform you're using, make sure you're in the frame, right? Make sure that your lighting is good, all that stuff, and then turn off that camera so that you're not just watching yourself and being super self-conscious the entire time. Because think about it, in what other context in your life, when you're having a conversation with someone, do you have a mirror that you're looking at?
Brian Milner (09:36)
Right, right, I mean, if you're in their interview room, unless there's a mirror all the way around, you're not really getting that view. And even if you did, you probably wouldn't watch yourself in the mirror the entire time. So yeah, that's a great tip. And I think you're absolutely right. It can lead to being very, very self-conscious then. I think it's, I want to go back a little bit to the prep because I think your tip there is a really important thing is to try to understand the challenges, understand what it is they're looking for. And it just struck me as you were saying that it seems very similar to, in my kind of line of work, I do a lot of consulting work with people. And when I have a client that's a prospective client, it's almost the same thing. where you have to research a little bit about the company ahead of time. If you're doing kind of a sales call prior to the engagement, it's very similar. And I just thought about that. There is an overlap there between that and job interviews because you are selling yourself. You are selling your services to that company.
Tali Shlafer (10:36)
And a lot of people, here's another mistake that a lot of people, a lot of well-meaning people make is as part of their prep work, going online and finding a bunch of questions that they can then prepare for. So it's a very, I kind of call it whack-a-mole where, hey, let me try to figure out all the possible questions I might get asked and write out answers for those.
Brian Milner (10:51)
Ha ha.
Tali Shlafer (10:59)
That might get some people results. And if it's getting you results, that's great. But what I really encourage people to do is really reverse engineer your talking points from the job description, from what you know, even, you know, once you've had the conversation with the recruiter, you know, a little bit more about the position than maybe is even listed on the job description. So compile everything that you know about this opportunity and figure out, okay, what are the most important things for me to be able to articulate rather than just guessing at. random questions that the internet says you might get asked.
Brian Milner (11:32)
Yeah, that's a great point. I know we all want to get past that and get to the job, but I think there's also an element there of, let's say you do memorize these questions and they just happen to ask you the exact questions you had prepared for. If you don't really have that knowledge, then you're not going to really do well in that job even if you get it. So it's almost a blessing to not get that job, you know, if you didn't know that information, because they're going to be counting on you to do that. And you're not going to be a you're not going to do your job well then. Yeah.
Tali Shlafer (12:06)
Yeah, and the memorizing piece that you just mentioned is really, really easy for people to fall into the trap of trying to memorize their answers, especially with chat GPT and AI. Everybody's thinking, well, let's use these AI tools to help us come up with interview answers. so we plug in, job seekers will plug in, here's a bunch of questions that I might get. Look at my resume, tell me how can I answer these questions? And it feels safe. It feels like, this very smart robot or technology is gonna say this in a better way than I can.
Brian Milner (12:36)
you
Tali Shlafer (12:40)
But it really sets people up for failure most of the time because number one, most people aren't good at memorizing things, right? Most of us don't have to do that as our job. So most of us are really bad at memorizing. Number two, it makes you sound like a robot. It doesn't sound human. You lose the attention of the person who you're talking with. And number three, doesn't when you just memorize answers rather than thinking about it as what are talking points that I can riff off, riff on and kind of reuse and recycle and tell stories with. When you memorize, it puts you in the position of, well, yeah, it's great if they ask you that exact question. And some questions you will get asked, like tell me about yourself, you're going to get 99 % of the time. But for the most part, if you memorize a set of 10 questions and one of those questions gets a slight variation, or they ask a question that's not on there, you end up panicking. You don't know how to think on your feet because you're reliant on your tool. You've used AI or you've used your script as a strategy rather than a tool.
Brian Milner (13:42)
Yeah, that's a great point. I'm kind of wanting to get your take on this because this is a big thing that I know often comes up in these kinds of interviews is those questions that we all hate to get that you just know, no one ever knows how to answer these things. So I'm just curious how you advise people, you know, the awful question like, you know, give me some of your weaknesses or give me some of the things that you're not good at. How do you advise people to handle those kind of questions when they get asked in interviews?
Tali Shlafer (14:14)
Yeah, so there are definitely some questions that we tend to hear more often than others, especially when it comes to those recruiter interviews. The tell me about yourself, what are your strengths? What are your weaknesses? Tell me about a time you had to deal with a conflict. Tell me about a time you had to deal with a mistake. Those are pretty common, I would say, in that initial recruiter conversation. It's always an interview in my book. The weakness question I know is one of the that and the tell me about yourself is what really stresses people out.
Brian Milner (14:40)
Ha
Tali Shlafer (14:43)
My general advice for the weakness is actually something that I heard Adam Grant, who's an organizational psychology at Wharton share, which is pick something that is real but not disqualifying. So if you're an Agilist, your weakness should probably not be scrum or not be, you know, understanding business requirements. But it could be something like public speaking.
Brian Milner (15:00)
Ha
Tali Shlafer (15:08)
Or it could be something like delegating, where, you know, it's something real and it's not... It's something authentic. Authenticity is really, really important, especially nowadays in interviews. But it doesn't stop you from being able to perform well. So what I typically advise is pick a weakness, like Adam Grant says, that's real but not disqualifying. And this is important, and where a lot of people miss out, share what are you doing to actually address it? Because what we want to do, the point of that question isn't tell us what's wrong with you so we can judge you and disqualify you from the job. It's the subcontext of it is do you have self-awareness? Are you somebody who is aware enough and humble enough to know your shortcomings? And are you someone who's proactive about fixing them? and about becoming a better person. So the second part of that answer should be, well, what have you done to try to improve? What are specific steps that you've taken in order to improve?
Brian Milner (16:09)
Yeah, that's a great response. I know I've heard the traditional, you try to say one of your strengths as, I guess my weakness is I work too hard, like that kind of thing. Which I agree, it's not sincere. If I'm hearing that and I'm interviewing someone, that could disqualify him in my book, because I could think, this person is not going be honest with me. ⁓
Tali Shlafer (16:20)
Yeah. or the I'm a perfectionist piece? The most common answer to that question.
Brian Milner (16:33)
Alright, I'm a perfectionist, right? Yeah, exactly. Well, you hit on the other big one too, the tell me about yourself. How do you advise people to handle that? Do you have a script in mind? you kind of detail out a couple of things? What's important to hit when someone asks you to just tell me about yourself?
Tali Shlafer (16:54)
Yeah, I'm a big fan of formulas over scripts. So I'll share my formula, but let me share a couple things that derail people. Let's kind of establish what's not helpful. And then we can kind of talk about this formula, which by the way, lots of different career coaches have different formulas. There's not necessarily one that works. It's just pick something and learn to do it really well. A lot of people will go in and start well. I graduated from the University of Washington in 1995, and they give kind of their entire history. And we lose the interviewer right away when we do that. So rather than giving them a chronological history of everything that's happened in your career and asking them, when we do that, we are essentially asking them, hey, here's all this information and data. You make sense of it. You figure out how it's relevant to you. I think it's actually really kind to use a formula to help them understand. Here's everything you need to know about me as it pertains to this role. So taking everything, taking your history and your career through the filter of what is important to demonstrate for this role. So the formula that I teach is sharing a super quick background. Hey, I'm Tali, I've been a project manager for the last 10 years. That's not true, that's not, let me reset that. So I think starting with a very brief.
Brian Milner (18:12)
You
Tali Shlafer (18:16)
sentence about yourself, your relevant role, how long you've had experience. Hey, I'm John. I've been project manager for the last 10 years, sharing the three key skills that you need to have in order to succeed at this job. And for each of those three skills, can you list an accomplishment or a metric or a success story? And we're not telling a whole story. We're just giving them here's the highlight reel, here's the headline, and then you'll click into all of those stories later. So quick little background about yourself, three main skills that you've developed that are relevant for this role, and super high level accomplishment to demonstrate those skills. So that's a little bit, that kind of is the first half, and that talks more about your previous experiences. And then in the second half of this answer, we want to pivot it to the future. So the first half is really about the past, it's about yourself. And then in the second half, we want to pivot to the future. what are you looking for in your next role? And hopefully that thing is also in that, that whatever you're looking for in your next role should dovetail really nicely into what they're offering as a company and as, as a, as an organization. What are you looking for specifically in your next role? And why are you so excited about interviewing with this company? And we want to share something really specific that We want to share something specific that feels personal. Where a lot of people go wrong is they'll share something like, I really want growth in my next role. And I'm excited about this team because I know you guys really value innovation. That doesn't really tell us anything. So we want one level of detail lower. So I'm really excited. What I really want in my next role is more leadership opportunities, so opportunities to mentor. And I'm really excited about this particular opportunities because I looked on your website, I looked at your blog posts, I looked at your, you know, CEO's posts that they share on LinkedIn. And I can tell that this is a really important part of your culture is being able to mentor people up into higher positions, right? Getting that specific, and there's not a right answer. I remember when I was interviewing for... out of college, I was interviewing for T-Mobile for an internship. And my answer was, I've talked to a lot of people, I've networked with a lot of people at T-Mobile. And one thing that really strikes me is the fact that a lot of people will leave for local companies like Microsoft, Amazon, and then they come back. There's a lot of people who spend a lot of time here. really does. There's a lot of loyalty and the culture, like I shared things that are specific to the culture and there's not a right answer here. It just needs to be. specific and it needs to be something that when you talk about it you kind of start getting butterflies because that's contagious.
Brian Milner (21:07)
That's awesome. Well, I want to ask about kind of the other half of the interview or the other portion of the interview as well. They, you know, I often hear people say, you know, you should walk into the interview understanding that it's a two way interview. They're interviewing you, but you're interviewing them as well because you want to know, is this the right place for me? So I can make the right decision about where I'm going to end up. What kind of things do you advise people to ask about or to focus on? What are some things that might expose some hidden things about the organization, warning signs or anything like that that might pop up in an interview to ask about?
Tali Shlafer (21:45)
That's a really good question. think one thing, it really depends on the opportunity and what you're looking for. So I don't think that there's one magic question that if you ask it, oh, the person's gonna be super impressed. Let me back up. What I really like about what you just said, is the framing of the questions that you ask at the end as a two-way conversation and as a way for you to understand more about the company so you can see if it's a good fit. I think a lot of people, especially in tough job markets, tend to kind of close their eyes and hope they get something and they almost blind themselves to the fact that they need to also do the work to make sure that it's a good fit. Or I see a lot of people who go, well, what can I ask that's impressive? What questions can I ask that's going to really wow them at the end, rather than seeing it as an opportunity to really understand what they offer more? So I would sit down and prioritize what is really important for you in a culture. if getting feedback, if growth is important for you, making sure to ask about, can you tell me about recently on your team, somebody who was promoted or how you helped somebody grow in the company? The best way that we can learn about something is through examples. The best proof that somebody values something is through the examples that they share. So we want to ask, kind of like you hear behavioral questions, you get asked, like, tell me about a time when. You can also use that, figure out what's important for you, and then create. Ask questions specifically about those things. One question that I think can be really helpful to get you to get a sense of what kind of person succeeds on this team and what the team really values is kind of the inverse of that. can you tell me about, can you tell me about what type of person doesn't do well here? Because then if they say, you know, The type of person who doesn't do well here isn't committed to working 60 hours a week. They expect to take their vacations and not be able to unplug. That kind of being able to hear who isn't successful gives you some context around some of their values as well.
Brian Milner (24:01)
Yeah, that's an excellent question because I agree. Presumably, this is someone you're going to be working with if you get the job. That immediate relationship, think, is going to really be impactful on the expectations, that sort of thing. Yeah, if I'm interviewing and I ask that kind of question, and they do come back and say, yeah, the person who doesn't work 60 hours or anything. Yeah, that's a good sign that maybe this is, I don't know, unless I enjoy working 60 hours a week, that maybe this is not the right cultural fit for me. So that's an excellent question, because I think that would expose some of that behind the scenes stuff, cultural things. ⁓
Tali Shlafer (24:42)
And you really want to ask about questions about your dynamic with the manager. So what kind of people succeed under them? Because that's the number one people. I believe I'd have to fact check this, but you always hear that the number one people reason people don't like their jobs or people leave their jobs is because of their boss. So you want to understand you're essentially going on a date with them and you want to understand what is it like to hang out with you for 40 hours a week?
Brian Milner (25:05)
you
Tali Shlafer (25:09)
So asking specific questions to really understand what's their working style, what are their expectations, what are their positive experiences, what does feedback look like? Is it a once a year thing? Is it a every time we touch base during our one-on-ones you get feedback? That is really important. The other thing that's important to think about is do you understand the role itself? Like what questions do you have? What gaps in your understanding do you have about the role? Really clarifying to make sure that you know what you're signing up for.
Brian Milner (25:40)
Yeah, that's a great response as well. I know I remember from back in the day getting told that it's a good kind of question to ask what would success look like? If you really got someone to nail this and you were really happy with the hire and it was perfect, what would be the biggest thing that would contribute to that? And I've always liked that approach as well because it kind of gives you the expectation from the start to know here's what's most important in that manager's mind of what they're looking for. Yeah, just in my memory of interviewing people, would say I've never, I don't think I've ever not hired someone because of a question that they asked at the end, but... I have felt sometimes like when they don't ask questions that they're a little unprepared.
Tali Shlafer (26:30)
Yeah, and I think it, I think part of the not asking questions, one is being not prepared, not thinking thoroughly about the job. But it's also a little bit of a sense of desperation, like, I've been applying for four months, I don't care, I'm willing to take anything. So I don't have questions, because let me just take any first job that comes available. There's kind of that mindset. And I think it manifests as, I don't have any questions. And I think
Brian Milner (26:48)
You
Tali Shlafer (26:58)
People can kind of feel that when you're not critical, when you're not trying to figure out, am I really going to be able to succeed here? People kind of pick up on that and it either looks like desperation or it looks like disengagement and disinterest. We want people not, we don't want to hire the first person off the street who can do the job. We want to hire somebody who's excited to be there and who we know isn't going to leave six months later when they find something better.
Brian Milner (27:23)
Yeah, that's really good. Well, this has been really enlightening. I think there's a lot of gems in here that I think people can apply. we all find ourselves in that position from time to time of having to interview for things. As I said, even as a consultant, it's an interview when you talk to a potential new client. So I think these are all really great tips for that. We're going to make sure that there's contact information for Tali at the show notes of this so you can get a hold of her. Anything you want to shout out about, any places you want to point people to to get in contact with you?
Tali Shlafer (27:56)
So for the last few years, I've been posting usually about two short form videos a day to LinkedIn, all the social medias. Over the last couple of years, I've posted over 700 short form videos on social media. I've actually had over a hundred million views on LinkedIn, which is really crazy. Somebody recognized me at the dog park the other day, which was wild. But I created an interview tip-ball that took the best... The most helpful videos the ones that have gone viral received the best feedback gotten people the biggest results in their interviews And I compiled them all in one Interview tip bolt so that's my little thing that I like to share with people You'll see everything in there from how to tell me about yourself To answering why do people ramble and what other mistakes are people making? and also special tips for senior leaders and executives. So that's my little freebie that I like to share out for folks who are interested in the stuff that I'm talking about.
Brian Milner (28:56)
Awesome, awesome. we will definitely make that available to people in the show notes and links to your socials as well so people can follow you and stay on top of your tips as they come out. So thank you so much for coming on, Tali, and I appreciate you spending some time with us and sharing your knowledge with us.
Tali Shlafer (29:13)
Thanks so much, Brian. It was a pleasure.

#154: The Underpowered PO with Barnaby Golden

Join Brian and Barnaby Golden as they dig into a surprisingly common roadblock in Agile teams, the underpowered product owner, and how it quietly derails decision-making, flow, and team momentum.
Overview
In this episode of the Agile Mentors Podcast, Brian welcomes Agile coach and community contributor Barnaby Golden to explore the risks and ripple effects of placing a product owner in the role without the authority to own it.
They discuss the stark difference between empowered and underpowered product owners, why availability without authority is a setup for frustration, and how misalignment at the leadership level creates more theater than agility. From trust gaps to political decision-making, Barnaby and Brian unpack the hidden reasons teams get stuck and what it takes to create real, empowered ownership that delivers actual value.
References and resources mentioned in the show:
Barnaby Golden
#104: Mastering Product Ownership with Mike Cohn
#3: What Makes a Great Product Owner? With Lance Dacy
How to Engage and Help Busy Product Owners by Mike Cohn
What Happens When For Product Owners
Subscribe to the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Barnaby Golden is an experienced Scrum Master and Agile Coach with a knack for helping teams truly live Agile, not just adopt it. Lately, he’s been diving into the real-world use of AI—helping organizations, including nonprofits, turn tech hype into practical, high-impact tools with smart governance
Auto-generated Transcript:
Brian Milner
(00:00) Welcome in Agile Mentors, we're back. This is another episode of the Agile Mentors Podcast. I'm here with you as always, Brian Milner, and we have a very special guest with us today. We have Mr. Barnaby Golden with us. Barnaby, welcome in.
Barnaby Golden (00:14)
Thank you, it's good to be here.
Brian Milner (00:16)
Very excited to have Barnaby here. Barnaby is an Agile coach, also a Scrum Master. He is known to us because he is part of our Agile Mentors community. And he is an active member there and has weighed in on several issues and helped people and mentored people through things there. So we wanted to share some of the wisdom of the crowd that we have there at Agile Mentors. Just a few select people that have really contributed. and giving us some really good advice there with the podcast audience as well. So you guys can kind of hear what kind of stuff is there on the Agile Mentors discussion forums. But we were talking about topics here with Barnaby about what we were going to talk about and he proposed one that I really found intriguing. It was focusing around the underpowered product owner, the underpowered PO. And I think that's probably a good place for us to start then, Barnaby. Why don't you kind of just explain to everyone what that idea is, what you mean by the underpowered PO.
Barnaby Golden (01:12)
Sure, of course. So in fact, what I'll do is I'll explain it by giving you the opposite, which is what does a good, effective, powerful product owner look like? And I was working for an organization a few years back, it was a publishing organization. And we had the head of the editorial team was the product owner for a particular Scrum team.
Brian Milner (01:16)
Okay.
Barnaby Golden (01:38)
And this head of editorial had a lot of power and influence in the organization. They were pretty much a decision maker in terms of the products that the team was building. And I remember a particular conversation where the team was talking to this product owner and the team said, look, we know you want to get this, this release out this week, but we've got some technical debt. really need to fix it. And I remember the, this guy saying, look, okay. I'm going to let me think about this for a second. Okay. I can make the decision on this, which is, yep, you can have your time. I'll communicate with others within the organization. The release will be delayed. And that was such a powerful moment because in that second, the decision was made. The product owner trusted the team, the team completely trusted the product owner. And it felt slick and efficient and worked really well. Conversely, I've worked in organizations where in some way, surprisingly enough, product owner is seen as quite a junior role. So I've seen the situation where you have a whole hierarchy of product people and the most junior role in the product organization is the product owner. And what happens in that scenario is the product owner is powerless to make a lot of decisions. So they have to push them up the tree. And in that situation, the conversation between the team and the product owner is the team says, yeah, we need to do this thing. And the product owner says, okay, give me some time. Might be a day and I'll get back to you. Hopefully I can get in contact with other people within my hierarchy and the flows broken. What's the team going to do now? They're going to maybe find something alternative to work on. It's very frustrating. And you sometimes get the situation as well where the the underpowered product owner will sympathize with something the team is saying, but will not be able to make a change because they haven't got the authority to do the change. So they'll say, yeah, I agree with you. I know what you're saying. This is a really bad idea what's being suggested, but I have no choice. We have a roadmap. We've got to meet the roadmap.
Brian Milner (03:45)
Yeah, that's a clear picture. I agree with you that those are two stark contrasts. And what I like about the explanation is you kind of highlight the effectiveness of one versus the ineffectiveness of the other, right? It's just, it's such a dramatic difference when that person is able to make the decisions on the spot. go forward, and the team is just free to move as quickly as possible. Whereas the other one, it's just holdups. It's just delays and obstacles, roadblocks in the team's way. So yeah, a really clear picture there. Just as you were talking about this, I was thinking to myself, well, maybe one of the worthy paths for us to go down here and talking about this. is trying to understand a little bit about the why behind it. ⁓ Because I think there's, just in thinking about it, I think there's maybe several causes for this or several things that might lead to having an underpowered PO. What's been your experience? What kind of things have you seen that might contribute to an underpowered PO?
Barnaby Golden (04:36)
Hmm. I think the main reason, the biggest driving factor behind it is the feeling that the people with the authority to make decisions do not have time to spend with the team. So you've got your head of product or the real decision makers in the organization. They are saying, I can't spend two, three hours a week with a team. I can't go to a planning meeting. got, you know, I'm a busy person. I've got things on my schedule. So they see the product owner role as a stand-in for themselves with the team. And this stand-in has lots of time to spend with the team, which is good. And that's a powerful thing. But at the same time, if they've not got the authority to make decisions, then maybe that time is not effectively spent.
Brian Milner (05:41)
Yeah, it's almost as if they just want a warm body there. It's a placeholder. You're here as a placeholder for me because I can't be two places at once. I've heard a couple of things that people will frequently point to that a product owner needs to be successful. And there's sort of this dichotomy of these two things that are part of that. And that's the kind of empowered
Barnaby Golden (05:44)
Yeah.
Brian Milner (06:05)
product owner that is empowered to make decisions versus having the availability to actually be present with the team. it's always, it seems like that's a fracture point that sometimes causes this because you have the leaders who, hey, I need to make all the decisions, but I don't have the availability. and the people that they know have the availability, they don't want to empower to make the decisions. So they're kind of setting up their product owners to fail.
Barnaby Golden (06:35)
I think it's a classic example as well with when you want to be an agile organization, you can't just have pockets of agility. You can't just have a scrum team and say, well, that's where we'll be agile in this scrum team. The entire organization as a whole has to think in the agile mindset. And if you want to be able to adapt to change, then one of the ways you're to have to do that is you're going to have to have the decision makers close to the teams that are implementing the decisions. and so you can't have your, your cake and not eat it. If you see what I mean in terms of, you, you can't pick and choose the aspects of agile that you want. need to, as an organization, adopt the whole thing.
Brian Milner (07:17)
Yeah, that's always one thing I try to tell people as well is when you're selecting a product owner, when you're trying to decide who's the right person to be the product owner for this team, those are two of the things you have to really consider strongly is does this person have the availability to be here with the team and is this person empowered to make decisions? I've run up against leaders before that don't want to empower someone and Kind of the counterpoint I give them a lot of times is, I don't know, I think maybe in their head they're thinking this is giving someone free reign to make really long-term decisions on their own when that's not really the case. The product owner can be fully empowered, but the decisions that they're making on the spot are just a couple of week decisions. It's not a six month decision. there's gonna be sprint reviews, we're gonna display stuff and get feedback and we can course correct and all those things. So once you can kind of put it in that frame that it's really just a couple of weeks that you're empowering them to make decisions, I've had more success framing it that way. I don't know, what about you?
Barnaby Golden (08:23)
Yeah, I think that makes a huge amount of sense. The fear is loss of control. So the fear is that by empowering the product owner, they might do something which they would regard as a mistake. And they will often see themselves, because they're in a senior position, they see themselves as being responsible. So if they're responsible and the product owner makes a decision they don't like, perhaps that will reflect poorly on them. So there's a trust issue here. A good product owner is going to be consulting their stakeholders anyway. And I would think the, the senior product leadership team is part of their stakeholders. So you would hope that they were keeping them very, very up to date on their thinking that there would be no great surprises that they wouldn't do something, you know, suddenly switch from one product to a completely different product. They would always be keeping their stakeholders in the loop. And in which case. they would be building up the trust of the people around them and then you would hope that over time that they would become more empowered.
Brian Milner (09:23)
Yeah. Yeah. I just, I kind of wonder if that's maybe part of it, that the, they have a misunderstanding of kind of how the role works. You know, cause maybe they, maybe they see it as completely independent. This person is just making decisions on their own without consulting anyone. Maybe that's because that's how they do their job.
Barnaby Golden (09:35)
Yeah. Yeah.
Brian Milner (09:49)
So they may look at that as, know, this is how I would do it, so why wouldn't this person do it the same way? Well, that's not how it's designed. It's designed to be done in concert.
Barnaby Golden (09:59)
Yeah, absolutely. Yeah, it's a misunderstanding of the product owner role. And it's also a misunderstanding of why the product owner role came about, which is the reason it was there was to solve the problem of too many chefs, of too many people trying to make decisions. So there's huge value in the role. But the value in the role only comes about if that person can actually take ownership of the product. I mean, the clue's in the name, isn't it? They are the owner of the product, so therefore they can make the critical on the ground decisions, but all the time talking to their stakeholders. So, I mean, as with many things in Scrum, it's about a misunderstanding, a general misunderstanding of what the roles are within the Scrum team.
Brian Milner (10:41)
Yeah, I think they also have the fear of the wrong decision that somehow that's going to lock them in or this person's not equipped to make the right decisions that they are the knowledge expert for the product. so they should be the one making all the decisions. They have the authority. I have had a couple of cases where I've had to have difficult conversations with leaders to say, well, let's examine the decision. because you're looking at them as making the wrong decision, but is it the wrong decision? You're disconnected from the day-to-day of the team. This person is fully connected to the day-to-day, and they're more likely to have more current knowledge. And it's not always the case that just because you assume it's the wrong decision that it actually is, they may actually be right and you could be wrong.
Barnaby Golden (11:30)
And funny enough, this brings on to another topic I'm greatly interested in, which is the definition of value. And that is if there is no clear understanding within the organization of value, then decisions become arbitrary. You know, we decide to do X rather than Y in the product. Well, why did you decide to do that? Well, because it was my decision to do that. Yeah, but is there a rationale behind it? Do you have a definition of the value of X and the value of Y? and why you chose one over the other. And I think that's part of the problem as well. The kinds of organizations that don't have empowered product owners also typically don't have a definition of value.
Brian Milner (12:08)
Yeah, I completely agree. I know I've had conversations in classes where I've talked to people about how when you're prioritizing, when you're looking at things in your backlog, and we always say you prioritize according to value. Well, what's the value? What's the value of doing that thing? And so many times, I think there are organizations that can't really identify what it is. Why are we doing this thing? because it sounded cool, because it seemed like the right thing to do, it just felt right? No, we're doing it so that it does something, it creates some outcome for us. And if you can't even really define what that outcome is that you're hoping it achieves, well, isn't that the start of the problem?
Barnaby Golden (12:55)
And I think part of the root cause of that as well is the tendency for these types of organizations to do long-term planning. So what they'll often do is they'll have a roadmap for the year and they'll say in this roadmap for the year, we will achieve all these things. And then it becomes less about delivering value and more about delivering the roadmap. And I've had conversations with product owners where I've said to them, you do realize what we're doing doesn't make sense. And they say, yeah, of course they do, but I'm not being measured. on sense or the delivery of value, I'm being measured on whether or not I meet the roadmap. And that was what's important to me. You can see how all these elements are tied together within the organization.
Brian Milner (13:28)
Right. Right? Yeah. No, that's an excellent point. And you're absolutely right. So much of our metrics and some of the things that we judge teams on or performance by is basically just a volume kind of metric. And it's how much stuff is being produced. that's not value. Volume does not equal value. Value can be achieved with much less a lot of the times. And if we're This is why sometimes I'll advise product owners in classes to say, look, start up your sprint review. Maybe go back and look at some things that you've done recently and show the metric that you're using for that thing to see if it's successful. Because if the team's done something in the past three or four sprints and it's actually moved the value needle some way, it's increased customer satisfaction. added new members to our site, whatever the thing is, right? If you can show that kind of business value to it, my experience is that people stop focusing as much on volume, because that's volumes of means to the end, which is the value.
Barnaby Golden (14:40)
Yeah. Yeah, absolutely. And the other thing I've noticed as well in these types of organizations is that the value they're focused on is the incremental, is not the incremental delivery. It's usually a new feature or something like that competing. And what you often find is that the teams are not end value creators. They're often parts of... the creation of value. rather than the whole creation of value, there may be a component of it. And because of that, people will say, well, there's no direct link between you and value creation in the organization. And I find that is very problematic. And it really flies against the rationale of Scrum, which is that you want within each sprint, you want to deliver some incremental value. And if you can't measure it, if you can't... clearly define what that value is. And as you were saying, if the product owner can't stand in the sprint review and say, well, this is the value we've delivered. How does the team keep motivated? How do they keep passionate about what they're doing?
Brian Milner (15:50)
Yeah. Yeah. I think part of that is just trying to put yourselves in the shoes of your customers and try to look about what they would find as being really valuable. I don't know about you. know, well, I'm sure this applies to you as well. But we all are consumers of different software products, whether that's a business software product or even games or other things that we would use. And when they come out with new releases of those things, they come out with release notes. Now, when they come out with the release notes, are you looking at the release notes and going, wow, I'm satisfied. There's a ton of things that's in this release. Or are you looking through the individual items and going, well, I don't care about that. I don't care about that. I don't care about this. That thing, oh yeah, that's important to me. Right? That's what we do. And that's a clear picture of value over volume.
Barnaby Golden (16:49)
Yeah, I mean, I think the thing that gets in the way here is a lot of it is the pride of the management team. So they often have strong self belief. They believe they make, they believe by definition, the decisions they're making are powerful decisions. So, I, it's also, think one of the reasons why a lot of organizations don't aren't data driven. You would hope they would. produce a feature and then measure whether or not that feature was a success. But that's not as common as it should be. There's very rarely business metrics tracked against deliveries. I mean, I'm generalizing here. There are many organizations do this very well. But I found there's quite a few organizations that don't really do that. And it leads to a disconnect with the customers. I mean, I can think of an example that we're... an organization I was working at where they worked on a feature delivery for six months that was on the roadmap and they got it done and they shipped it. And I think the expected users were tens of thousands and they got 16 users for this feature. And at that point there wasn't even a post-mortem. They didn't even look back and say, well, what are the lessons learned here? It was like, that's shame. Let's move on to the next item on the roadmap and hope that works instead. And it's very frustrating, especially because the feel of a good Scrum team is the connection with the customers and the feeling that you can see the passion in the engineers and in the team's eyes because they're delivering things that people want and they feel connected to it. And it means they work better and they work more effectively.
Brian Milner (18:22)
Yeah, there's no worse feeling than building something no one uses. I used to joke with the team, it's kind of like that old joke about if a tree falls in the woods and no one's around us, makes, if we build software that nobody uses, did we build it? It's not going to be used for anything. So it didn't serve any purpose.
Barnaby Golden (18:31)
You Yeah. Yeah, the way I like to think of it is that an organization should not view people's time spent in the job as important. What they should view is the value that that person has delivered as important. So sometimes people will say, know, yeah, okay, we delivered a feature that nobody really used, but you you did your job, you came in for eight hours a day during that time. And that's hard for people, I think, because they feel like this is my life. I'm investing time and energy into this. Yeah, the money is important, of course. I'm doing it as a career. But at the same time, I also want to feel reward. I want to feel like I'm achieving something. And I think with that element, you get so much better performance from the team if they feel that.
Brian Milner (19:26)
I agree. There's another thing I was thinking of here too, when we were talking about underpowered POs. Another cause I think that maybe you've encountered or seen as well, but screwy things that people do with kind of personnel. Like for example, having multiple product owners for a team, that leads to underpowered product owner or the opposite even putting a product owner on too many teams. That's going lead to underpowered POs as well. What's been your experience with that? Have you seen that? Okay.
Barnaby Golden (19:54)
I have one extreme example where there was an engineering team and the organization was an international organization. And politically within the organization, it was unacceptable to have one backlog. They had to have a backlog for the UK, a backlog for the US, a backlog for Australia, backlog for other areas of the world. And the team then had to... prioritize them kind of in this wild order. So they would say, right, we'll take number one from UK, number one from US. And so there was no coherence to what they were building at all. It was really just about satisfying people within the organization. And it kind of brings you back to that key point about why do we have product owners? Because product owners, they narrow down all the ambiguity, they narrow down all the possibilities to the thing that's most effective for the team to do next.
Brian Milner (20:47)
Yeah, I like your example because it highlights kind of what I think about those scenarios a lot of times is that they're theater. They're an act. They're not really serving the purpose, but they're making someone or helping someone to feel a sense of security about something that really they shouldn't feel. It's not there, but it has the appearance of it. It has the stage set.
Barnaby Golden (20:55)
Hmm. Yeah.
Brian Milner (21:11)
of something that looks secure, you know?
Barnaby Golden (21:13)
Yeah. mean, whenever somebody mentioned that to me, the first thing I always think about is the length of the backlog. I've worked in organizations where they could not achieve the backlog in 10 years if the team kept at it. And yet people within the organization say, yeah, I'm not worried. My feature request is on the backlog. And I'm thinking, yeah, but we're adding 10 new items a week and we're only completing eight. So in fact, you're moving further down the backlog. You're not actually getting closer to. being done. And it's, it's, it's a disconnect to gain. And this is what it's all about. Good agility, good scrum is when there's a strong connection. And if you start having that, that just doing things for appearances sake, then you lose that connection.
Brian Milner (21:55)
Yeah, and it really is kind of that fundamental flaw that we try to address throughout Scrum of transparency. When you do those kind of theater-ish things to give the appearance of something, it's the opposite of being transparent. You're trying to make it more difficult to see the reality. Yeah, it's on the backlog, so you have this false sense of security. It's on the backlog. It's never gonna get done, but... that's not transparent that it's never going to get done because it's on the backlog. Yeah, mean, part of that I put on the product owner a little bit, but that could also be that the organization demands it. Like your example with it having different backlogs across different geographies, does it serve a purpose? Well, maybe the purpose is to make someone feel better. That, hey, my thing's number one on our list, but...
Barnaby Golden (22:39)
Yeah.
Brian Milner (22:43)
That doesn't mean it's number one, that's the next thing that's going get done. It's theater.
Barnaby Golden (22:47)
And it was done exactly for that reason. I mean, it was done because they didn't want to alienate the heads of the individual countries. So they wanted to make them feel like they were going to get something even though they weren't going to get it. Which is really frustrating.
Brian Milner (22:59)
I've seen that as well with the multiple product owners. When there's a team that has multiple product owners, a lot of times that's a theater kind of thing as well, because there's a, I don't know if there's a fear that someone's gonna feel undervalued if they're not called the product owner. But it just seems like, yeah, we want all these voices to be involved with it, which again, maybe it's a misunderstanding of the product owner role. That's okay, you can have multiple voices involved, but you gotta define who's the decision maker. And if a team doesn't know that, that's gonna cause a whole host of problems.
Barnaby Golden (23:34)
Absolutely. I mean, I've been in scenarios where you would have multiple product owners. The team has been instructed by a product owner to go in a direction and then midway through a sprint, the other product owner will come along and say, yeah, that's not really what I had in mind for this sprint. Can you please switch onto this other thing? And as a, you know, I was a scrum master at the time and what I ended up doing in my sprint report was I would say, and the team lost 20 to 30 % of their capacity in switching. between what one product owner wanted and what the other product owner wanted. And that at least got a reaction because people said, well, OK, maybe that's not a good thing if we're losing output from the team. But it's a failure of the organization to make value judgments and make genuine decisions. Instead, it becomes political decisions.
Brian Milner (24:19)
Yeah. Well, I'll give you my trick for when I've encountered it as a consultant a couple of times, I usually just ask one question and it'll clear it up. I'll just go to them and whoever the leader is that's insisting that there's multiple product owners on the team, I'll just go and say, all right, what happens when, let's say it's two, what happens when those two people disagree? And usually the immediate thing I hear back is, oh, no, no, no, they get along. They usually understand.
Barnaby Golden (24:45)
You
Brian Milner (24:47)
And I always just counteract it really quickly and say, yeah, but what happens when they don't? What happens when the day comes when one of the product owners wants something that's number one and the other one wants an entirely different thing as the number one priority, who makes the call? And usually they'll point to one of them and say, push comes to shove that one. right. I mean, at that point, I just say, well, you just told me that's your product owner, right?
Barnaby Golden (25:08)
got a little bit more authority so they make the decision here.
Brian Milner (25:15)
That's the product on the other person's a stakeholder, which is fine. There's nothing devaluing about someone who's a stakeholder. They can work all day every day with that product owner.
Barnaby Golden (25:24)
Yeah, absolutely. I think that people feel if they're not in the product owner role, then they will just be another stakeholder and maybe they won't have as loud a voice. But what's so frustrating about the situation is when you see it done well, when you see it done effectively with a really good empowered product owner, a very motivated team, it's such a powerful thing. And I mean, it's why I stayed in Agile for so long is because I know how good it can be and It's very frustrating and I guess I have sympathy for organizations because maybe if they've never seen it done well, it's difficult for them to understand how just how effective it is.
Brian Milner (26:00)
Yeah, I agree. Well, this has been a great discussion. I really like this topic. It's great to focus on product owners a little bit. And hopefully, maybe there is a leader out there or somebody listening who heard some of these things and thought, you know what? Maybe it is time to give our product owner a little more power. We talk about testing things all the time, inspecting and adapting as we go. Well, leaders, try that.
Barnaby Golden (26:25)
Yeah, maybe just try it as an experiment. You know, if you're concerned, give it a go.
Brian Milner (26:27)
Yeah. Yeah. Give it a shot and see what happens. You may like it, and you may decide this is the best way to go. So yeah, I think that's a great suggestion. Well, Barnaby, this has been great. I really appreciate you making time for this. thanks for not only being on the show, but for the contributions you made in the Agile Mentors community as well.
Barnaby Golden (26:47)
Well thanks a lot Brian, I really enjoyed that, it was a great conversation.

#153: Getting Real Buy-In for Agile Transformation with Scott Dunn

Join Brian and Scott Dunn as they unpack what “buy-in” actually means and what it takes to move from surface-level support to genuine commitment in this episode of the Agile Mentors Podcast.
Overview
In this episode of the Agile Mentors Podcast, Brian is joined once again by Scott Dunn to tackle a listener-chosen topic: how to get real buy-in for Agile initiatives, especially when shifting from a non-Scrum environment.
They explore why buy-in isn’t about enthusiastic cheerleading or deep Agile knowledge, but about leaders and teams aligning on desired outcomes. From the cost of performative support to the emotional side of change, Brian and Scott share practical strategies for securing support at all levels of the organization. Along the way, they dive into influence tactics, the importance of shared purpose, and how co-creation—not compliance—drives lasting change.
Whether you're guiding a large transformation or simply trying to influence up, this episode will help you rethink how to earn trust, build alignment, and inspire meaningful momentum.
References and resources mentioned in the show:
Scott Dunn
Elements of Agile Assessment
Subscribe to the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum.
Auto-generated Transcript:
Brian Milner (00:01)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And I also have with me today someone that you probably know pretty well because he took over this podcast for about a month there. Mr. Scott Dunn is with us. Welcome in, Scott.
Scott Dunn (00:19)
Hey, thanks Brian. Yes, that podcast takeover was a lot of fun. So thank you for that opportunity. That was a hoot. Had a great time.
Brian Milner (00:25)
Absolutely. Well, I don't think I publicly thanked you for that. just ⁓ a public thanks.
Scott Dunn (00:28)
No, you didn't. No, not even an email. Not even a Slack message.
Brian Milner (00:33)
Well, very public thanks to you for doing that. Those episodes were great. I enjoyed them and it was fun to be a listener. It was fun to listen to it and just kind of hear the conversations and be a fly on the wall for those. So thanks again for doing that.
Scott Dunn (00:47)
Yeah. Yeah. It's a real treat.
Brian Milner (00:48)
We're having Scott on we kind of ran an experiment on this one because we were Scott was teaching a class for mountain goat and We thought maybe we'll just see what the class thinks so we pulled the class to see what topic do you want us to talk about and We thought we'd just go with the winner the winner that came out of that class was how to get buy-in How do you get buy-in in a? move from a non-scrum place to a Scrum kind of way of working. How do you get buy-in in the organization and buy-in from others? So when I was thinking about this as a topic, I think the first thing that popped in my head Scott about this was What do we mean by buy-in? So what does that mean to you?
Scott Dunn (01:33)
Right. So sometimes what I'm hearing is people saying like, buy in, you know, they, I would hear a common complaint, like they don't get it. They don't understand. don't, for me, buy in isn't that they need to understand agile or scrum and these types of things and how it works. Buy in is they get, they give their support kind of regardless. So my favorite example of that is walking into, this is a multi vendor effort we're doing on a Salesforce implementation. And we'd asked for the VP of the whole thing to come down and say some words before we had our first retrospective. You can imagine it's going to be kind of heated with different vendors trying to make each other look bad or whatever. And he'd said, yes. So we're coming down into this, you know, big high stakes meeting. And I just remember him saying, you know, I'm so excited to be doing this for you all. It's great. And he kind of falls in and looks at me says, what am I doing again? Cause he didn't, he didn't know, he didn't know what a retrospective was. He just knew he was asked to come and do something around that. And to me, Brian,
Brian Milner (02:21)
Ha
Scott Dunn (02:28)
That's fine. He's showing up. He's letting everyone know this way of working is important. It's important to me. It's important to success. And he probably couldn't tell you any of the meetings or artifacts or anything in scrum, right? But that's still what we need.
Brian Milner (02:39)
So. Yeah, I think that's a good way to think about it because I think a lot of people sometimes think of buy-in, like everyone's clapping and waving scrum flags around and all that stuff. And I don't think that's really buy-in. I think it's just the willingness to honestly try it, to give it a shot and be open about what would work and what doesn't work. The opposite of that is the resistance, know, of just being resistant to it and saying, I'm gonna put up hurdles and walls in the way of this being successful. That's, think, what needs to be avoided.
Scott Dunn (03:18)
Right, right. think that some of what was helped is to give them the, for me, the mindset of their buy-in isn't about doing things right. They're not saying, we're really wanted. We really want a new process. We were getting asked to come in because they're not getting the results they want. So buy-in for me from their perspective is how to help get the results that they're looking for. And they'll support us to get those results. So I don't talk to them about some of the aspects of an empirical process or any of that. I sort of say, you in order to get things faster or in order to improve quality, right? And that's how they get behind that. I think sometimes people are preaching some of the process part, even if they could understand that's not really what they're about. But I think they even struggle to understand what we're talking about. So yeah, it's hard for them to get behind and support us when they're not tracking. They simply know there's a pain point we're having. Can we talk about that and how to get what we need and what do you need from me to get that? Great. But I think we We can do ourselves a favor by helping point to the same target, make sure we're aligned with the same target they want. And maybe they'll give us more support if they feel like, yeah, you're tracking with me. I want to come in talk about, you know, more collaboration. Like we already have enough meetings. That's what, that's what I heard. Right. But I'll come and talk about faster time to market. Well, yeah, now they're interested in talking about what they need to do, you know, that I'm asking them to get behind that. I think that's fair.
Brian Milner (04:28)
Right. Yeah, I think there's also an element there, because I know we're both kind of fans of and users of kind of the path to agility framework from our friend David Hawks. And I love the part of that that's trying to establish the motivation, the purpose from the outset to try to say, What's the thing we hope to get out of this? And I think that's really crucial in getting buy-in that you can't just tell people, hey, we're gonna be a Scrum organization now. Why? Because I tell you that's what we're gonna do, because we're gonna check off the box and say that we're now Scrum. That's not motivating to anyone. if I can say, no, we're gonna... go through this change because here's the end result. Here's what we're trying to get to. Here's what we think will be better. If I can lay that out, then I've got a purpose behind it. And now I have motivation to go forward with this difficult change and learning what's expected of me and all that stuff. But if that's not done, I feel like that's a crucial misstep in that.
Scott Dunn (05:44)
Yeah, I wanted to add to that, that that point about the clarity of the goals is really something that has sticking power. And we had a client, I came and was working with him this year that he had remembered from the last year as the CTO. He's remembering from last year that we had done that same exercise or what are the goals that leadership has. And he remembered it was quality and customer satisfaction. That had been over a year since we had done that, but that not only stuck with him, but we came back to the group and kind of had a fun poll. Like, everyone remember? They remembered. And so every time we're having a decision we're trying to make about should it be this way or that way on the process, the different, were doing the race, the matrix work, et cetera, people kept coming back to, well, is that going to help us in terms of quality? Is that going to help us in terms of customer staff? We're not going into the nuts and bolts of Scrum or these other approaches. It's simply what's the business goal. will that help us hit the goal? And when the leader hears you using their language that they get, like that's my goal, they're feeling like, okay, whatever you need to do, sounds like you understand what I'm after, right? It's really powerful. But I like that you mentioned that, because when we go through that exercise, always super clear, we don't get confused. Times when we lead with, especially on the executives trying to lead with explaining Scrum, you can tell sometimes they're not really tracking or they're following along, okay, so what's the point?
Brian Milner (06:59)
Yeah.
Scott Dunn (06:59)
Yeah, you start off with what's their goals. They're like, great, this is exactly what I want to talk about. And then, Hey, you're not doing the things you need to do to hit those goals. Oh, okay. What are they? I mean, I remember one time a couple of years back, literally when the coach was presenting the results of that assessment towards their goals, they cut them off in the middle of his presentation. Just says, well, why, why is it, you why is that red? Why are we not hitting the goal? What do need to do? And they just started solving the problem right then he couldn't even finish his presentation. Talk about getting support. And he had been there six years saying,
Brian Milner (07:23)
Wow.
Scott Dunn (07:27)
Scott, they're not gonna buy into doing this transformation team and the scrum work. He couldn't even finish, I think, a couple of slides and they gave him everything he wanted, right? Powerful, powerful.
Brian Milner (07:36)
Yeah. Yeah. I think that's a good point. I also think one of the reasons that there's, you know, and that kind of parallels it. One of the reasons there's a lack of buy-in in general is that it's sort of targeted to just one area. You know, like this is a team thing. The teams are going to get trained, but the leaders have no idea really what's going on. They're kind of separated off from this. And I think that's a big part of the problem as well is you get buy-in when they see the leaders have bought in. So are the leaders bought in? Are the leaders on board with this? If they're not, then the rest of the group isn't going to be bought in either.
Scott Dunn (08:18)
People are smart. They're watching which way the wind's blowing. to be honest, Brian, I'd love to hear your thoughts. I tell people, I don't even care if they genuinely believe in that or not. If they're getting behind it because that's the way the politics are going, hey, they're getting out of the way. We're getting things done. Fine by me. Right. So partly when we're getting that by now, so make sure leaders, are you communicating this clearly? Because some of your people are either not on board or they're kind of waiting to see, this a fad or is this going to blow over? I need you to really communicate that clearly, et cetera, to see if people are get on board with that or not. Or, and on the other side, if I feel like some of these folks are not on board and I do feel like I have leadership support, I need to escalate that pretty quickly and make sure you understand, know, because they might get mad at you or me for talking about scrum and changing things. I'm like, I didn't knock down the door and come in myself. I was asked to come in here by someone who has authority. So maybe you need to clarify that with them, whether we're doing this or not. But don't get mad at me.
Brian Milner (09:04)
Right.
Scott Dunn (09:11)
So I will check them on that and clarify with the leadership to say, let's make sure your people are in alignment as well. If we do have that buy-in for sure.
Brian Milner (09:20)
Yeah. I saw another kind of quote about this that really got my brain working a little bit. Cause it was talking about the cost of fake buy-in and it was, it was kind of saying, you know, performative buy-in might actually, you know, it was asking the question, is performative buy-in worse than just outright resistance? And I don't know. Let me ask you that. What do you think? Do you think performative buy-in is worse than just someone who's resistant?
Scott Dunn (09:28)
Interesting. Yeah. As someone that just gave an example of performative buy-in. So if you would ask me a week ago, I might have gave a different answer, but someone was talking about this is a wildly different aspect of this, but you did ask me to join. So you get what you get. ⁓ They're talking about the difference of discrimination in the US versus South Africa. And they said, what's the difference? And they said in South Africa, it was blatant. no, you're a person of color. You cannot buy property here. That's how it is. Here, it's more like
Brian Milner (09:59)
You
Scott Dunn (10:14)
Yeah, we're looking at your loan application and I don't know if you can buy in this way. So it's subtle. And this person actually said, I'll take the outright blatant discrimination of South Africa, where at least you know what the issue is versus the subtle one. So maybe to that point with what you're saying, maybe it is better to have outright resistance and then say, well, at least I know who's on board or not. Rather than the person says they're on board, but every time they're in a meeting, they come out meeting and we don't get the decisions made we need. That's funny.
Brian Milner (10:39)
Yeah. Yeah. When I read this and started to think about it, I kind of had that same conclusion that like when someone's being outright resistant, yeah, it's an obstacle, but it's honest. And, you know, I'd rather have the honesty because they're trying to, they're still acting their way because they have a belief that their way is the right way to do it. And so they're throwing up a resistance because they're honestly resistant to it. Whereas someone who just sort of nods in meetings and claps along and, know, oh yeah, sure, great. But then they're kind of in the quiet, you know, behind the scenes and the hallway conversations. That's insidious. That's something that I can't really deal with. And it's like, you know, let's have the discussion. Let's talk about it. And, you know, if you win, then great. Why not have the courage to just have the conversation and see which idea wins?
Scott Dunn (11:39)
Right. on that note, think for everyone's sake, Brian, if we could be honest for a moment, not that we haven't been honest in these other podcasts, but in this, in this moment, we're really going to be honest. Would you, would, do you feel at times that our culture, our company cultures actually teach people to do just what you said to not be honest, but then like be like, you know, politically savvy, don't say what you really think, but then you're going to kind of be subversive and undermine that thing. And I've dealt with that so many times, I'll show up to a meeting like, I would have swore we were on board. had that one-on-one and now you're not saying in the meeting that you go on board with that. So people might've gotten coached. It's actually not safe to be honest and have good clear spirited debate because there's a price to pay if they do that. And they maybe 10 years in corporate can kind of teach you don't be honest or they're trying to read the tea leaves about what you think it's going to be. And so, yeah, I definitely would rather take it. Maybe it's part of the mindset of trying to really check, you know, where people are at. If I go back to my early days of coaching, those one-on-ones of having the level of honesty to really know where people are at. That was, think, some of the power. And I think some of that came from genuinely caring about the people, wanting them to succeed, wanting them win, even if it wasn't going to be at this company because of all the change or whatever. I did feel people felt like I really was open and honest with them and transparent and had their back. I would hear some real things about how they really felt because they didn't feel like there was a payback for that. And that allowed me to actually say, well, you know what, if you're really not on board, let's see what we can do as far as another opportunity. Maybe it's a positional switch we can do or whatever that was. Because I mean, this did affect people's jobs in some ways. And I think maybe if I don't have those one-on-ones, they're probably just going to give lip service because they don't know if anyone there really has their back in a turbulent time of change. AI is a great example of that, right? Hey, we want to move forward with AI. Well, what's the impact of my job if we do? But no one's really talking about that, right? It's all positive and all that. So I think people are trying to read that too. But you bring up a good point. I think I would take the direct as long as they feel like they can safely be open and honest.
Brian Milner (13:31)
Yeah. Yeah, well, even that question, right? What effect is AI gonna have on my job? And the honest answer I think that someone has to give right now is, don't know. I feel like I understand what it is today, but I don't know that that's gonna be the same way tomorrow because this technology changes so fast, so I can't promise anything. But here's what it is today and this is the paradigm we're trying to live in. So I think that there's an honesty component there that you've got a mirror to say, hey, I'm going to be honest with you. You be honest with me about this. And we'll be upfront with each other as we make our way through this. yeah, so yeah, think that kind of being honest and taking that approach, I think, is the right way to go. I also think that being kind of a reverting back before you get into things like, here's what a Scrum Master is, here's what a product owner is. You've got to start with the basics and mindset kind of culture things. You have to start with transparency, inspection, adaptation. That's really the way to go. And if we buy into those sorts of things initially, then we can start to say, well, here's a practice that supports that. Now you understand why we're doing this practice because it does this thing. Without it, it's just sort of one of those things of do as I tell you, you know, and that doesn't get buy-in. We've got to see the why behind it.
Scott Dunn (14:48)
Yes. Yeah, I think so. That's a great point. I was just making a note because sometimes we come in about agile. Some of the folks when I'm sharing this, it's maybe is new to them that I try to really present it. I want what you want. So even down to the words and then I kind of map back to that. So for example, if if we have quality problems now, I might believe in say an agile practice like mob programming, but I don't want to bring up like, hey, we should try mobbing. because it's cool or because you know, whatever, they don't care about that. But oh, they have a quality concern. Hey, boss, I've been thinking about, you know, these quality issues. I got an idea that I think it really could help with quality. But if I was to ask you, Brian, is is Bobby gonna, does Bobby help with quality? Does Bobby help me with, you know, cross training and tearing down knowledge silos and sharing learning? And I think, well, it does a lot of things, I pitch it towards what management wants. So agile as a means to an end. So I want what you want. And if I can't get that clarity that I want what you want, I need to be listening more because if I feel like I come to them talking, I've seen from my own experience, I come talking about better collaboration. That's not what's on their mind. I'm literally losing credit with them because they're like, why are you bringing this up? Like this isn't even our concern right now. Right. So I'm losing trust. I'm losing political capital. So I listen intently what their concerns are, the things I think that are important or that can get that. Then I'm going to pitch it. I'm going to pitch it in that language even like, you know, that what these are the things that would help on. I want what you want.
Brian Milner (16:00)
Yeah.
Scott Dunn (16:18)
the sport, I'll even research stuff to find out. So maybe I gave an example recently, when I was a manager for a web development, team that they wanted bigger monitors, of course, and I couldn't get approval for the bigger monitors. so I went and researched, I knew that always we had pressure to deliver more. I researched until I found somewhere someone had to study the show that larger monitors help productivity. And then I brought that to him and like, Hey, I'm looking for ways to improve the team productivity. I think I found something. What is it Scott?
Brian Milner (16:30)
Mm-hmm.
Scott Dunn (16:46)
Well, larger monitors, you can tell us, Smollick, really? You've been asking for this for months. I said, no, there's a study that proves it. Now he approved it right then. But partly I wonder, Brian, is I was also giving him air cover for when he gets flack from the other departments. Why does Scott's team get the special monitors? Well, it improves productivity. And right. He's got a reason now. Otherwise, it looks like maybe he's just playing favorites or something else. Right. We're all watching costs. So I will do the research to say, hey, I want what you want. I'll go and I'll go and dig it up.
Brian Milner (17:04)
Yeah.
Scott Dunn (17:13)
Someone somewhere must've said it's gonna help. So I'll bring that to them. It ⁓ worked.
Brian Milner (17:17)
Yeah. Yeah, I think you're right. you're giving him the why behind it. You're telling him, hey, here's something that's in. It's the old outcome argument that the outcome from having larger monitors is this, that we have this productivity. I know you want greater productivity, so here's a means to do that. And I think that's kind of the way that this, you in a nutshell, what we're trying to say here is, you know, I can't go into a company, your boss comes into your company tomorrow and says, hey everyone, we're switching to pens that write in green ink, because we're a green ink company. We just, we want to be known as the green ink company from now on, because it's better. So everyone, make sure you switch to green ink. I mean, they do it. But there's a difference between compliance and real commitment. ⁓ And that's the difference, I think, is, all right, you wanted to switch to green ink, but why? What's the point behind it? I'll do it, but I'll be committed to it if you tell me, well, studies show that when people read in green ink. I mean, that kind of thing can make an impact. But otherwise, it's like you're
Scott Dunn (18:08)
Yes. ⁓ Absolutely.
Brian Milner (18:31)
It's almost like an insult to the intelligence of someone, you know, to say, we're going to do this crazy new thing called a standup, you know, or daily scrum or whatever. And well, why are we doing that? I don't know. Cause right. That they tell us that's what we're supposed to do. Well, we have to stand up for a meeting. Why are we standing up? Why aren't we just sitting down? It's more comfortable. I don't know, but that's what you do in a daily scrum is you stand up. Right. I mean, it's, it's, it's that kind of a thing that I think.
Scott Dunn (18:34)
yeah. Yeah. I don't know.
Brian Milner (18:58)
if you don't lay the groundwork of here's why, then they're gonna just react with the way that you would switch to green ink. ⁓ Scott Dunn (19:05) I love that example. love that. And we've all been there, right? When someone says, why would we do this? I'm like, I actually don't know. It's a terrible feeling. I don't know. We go through all this effort to do just that. And you mentioned that compliance, compliance will never have their heart and soul and energy into this. So think that that's a big deal for them as well. When leaders are, we had something happen where it's a large financial institution and their data engineering group.
Brian Milner (19:11)
You're right. Yeah.
Scott Dunn (19:33)
You're like, yeah, AI is not really, you know, for us, not important to us. Which is interesting, right? Then the next week, like that, the head of that group, their boss's boss says, we need to be using, AI. Well, guess who makes it announced at the very next week. We need to get going with AI, So some of this is like, look, if they're pushing those things, we also want to make sure that they're in a position to look good for their bosses, those types of things. Right? So one, you know, giving them air cover, but two, listen to the winds of those things. If we make them successful, I mean, this is old school, right? Make your boss look good. My goodness. If they feel like that's happening, then you're going to get a lot more support. And this is a good example of a radical change for a whole data engineering team, just because the boss's boss says so. So now we're going to do it. I think looking for even those opportunities and following through on what that might be bringing them ideas that make them look good and generating that as well. I love the green ink one. just now it makes me want to be that we're the green ink company. You're we're going to be known for this.
Brian Milner (20:23)
Yeah.
Scott Dunn (20:29)
⁓ But why?
Brian Milner (20:30)
Yeah. I think it's also kind of important that you acknowledge that there is an emotional impact here. And this gets into kind of the idea of the whole Satir model of change and that kind of thing. And so I think maybe part of the equation of getting buy-in is really comprehending and understanding that you're not going to get buy-in right away. ⁓
Scott Dunn (20:56)
Hmm.
Brian Milner (20:57)
you know, there's going to be chaos and resistance. There's going to be a point where people are going to be resistant to it. And if you do the rest of it well, then that they'll turn that corner. But what makes them turn that corner is, is that they're connected to the purpose behind it. And so if you're, if you're going to try to implement this, if you're to try to do a change, and just expect it's gonna be, know, hunky dory from day one, you're fooling yourself. Humans don't take to change well. It's got an emotional aspect to it. I love the way David Hawks used to always say this. You know, I knew how to be a hero the old way, and I have no idea how to be a hero in this new thing. So I don't feel comfortable with this change because I don't know how to win.
Scott Dunn (21:41)
So true.
Brian Milner (21:47)
And I think that is a really accurate reflection of that emotional kind of impact of it. Everyone wants to do their job well and be seen as a smart person at work and everything else. And I knew how to do that before, but now I don't know how. And so I'm afraid I'm gonna look bad.
Scott Dunn (22:02)
Right? And I think that lack of awareness or knowledge is some of the things that we're asking them to do. Like you said, uncomfortable or new doesn't feel good. And we kind of think that, oh, if I don't feel good, this must be bad. It's just uncomfortable. But I think I love what you're saying. We can map it out and say, by the way, it's going to look like this as we go through that. And that hero part, a lot of our management, like 90 % of the management is going to be in that, you what we call expert or achiever. Like they're the smartest ones in the room, or they're ones that coordinate everything and they know who to talk to. you're trying to introduce something to someone who thinks they already know all the things. So how we're presenting that to them, including the fact that they're human too, right? They're gonna feel some things and maybe uncomfortable. It wouldn't hurt to explain a bit more, even if they're not gonna necessarily admit it, but like, hey, it's gonna feel different. The people might push back on this. So even when you're first beginning that, it reminded me of how I just knew I'd need to ask my boss like five times. Look, lots of people are asking him for stuff. They're partly just going by the simplest way of Who keeps coming to my office the most? And maybe on time five, like, wow, Scott, this sounds like a problem. Well, yeah, I've been here five times. Because they're kind of waiting, like, is it really a problem or do you just come in once or twice? So repeating that and then maybe framing it to say, and doing the change looks like this and that, giving them information so they don't have to admit that they don't know if they're priding themselves on knowing all the things. I really think that's a great addition to that. The Satir change model, knowing that it's going to get uncomfortable. I've seen execs jettison this just because people are bothered or upset or they're uncomfortable. So therefore this must be a bad idea. So I think we can do ourselves a favor by explaining a little bit like it's going to look like this moving forward as far as their support. Some people may not like it and here's why, but here's how I would answer those people. Like you're literally feeding them the responses. And I'll also do the get behind the expert and say, well, this is, this is what Harvard business review says, or this is what this expert says. You might be surprised because Again, back to them being experts, if you ask them what they think they know about Agile, I might have mentioned before, they score themselves on average about 8.5 out of 10. But their people would score them about 4.5 out of 10, right? It was what I've seen when I did the study, the surveys. So they think they know, so they're not gonna admit they don't know, but go ahead and give them the information they wish. If you know they don't know, I like what you're saying, kind of shrink the chain so they can understand, it's gonna look like this and feel like this. People might ask this way. But here's how I'd respond to them. know, remember this is where, you know, 90 % of the companies are doing X, Y, and Z. So they have backing. They can answer to the people. We kind of set them up for success. Otherwise that satiric change curve is going to hit them. They won't have answers. That feels really awkward. This must be a bad idea. And they're going to undo what you just asked for. Right. I've seen that happen. You just got approval and then a week or two later it got put on hold or undone.
Brian Milner (24:44)
Yeah, no, I agree. one of the areas, one of the other kind of things that I found in thinking about this in advance was a quote that was from the five dysfunctions of a team book that we all talk about quite a bit. But there's a quote from that that says, people don't weigh in, they won't buy in. And I love that. And I thought, you know, that really is a good point that there, it's not about
Scott Dunn (25:00)
Woo!
Brian Milner (25:08)
people need to feel like they're co-creating with you. And to do that, you need to be able to listen to them. If they don't feel like they have a voice, mean, put yourself in their shoes. If you felt like there was a big change happening and you had no say in it, that would feel pretty oppressive. But if they felt like they're building the change with you, then I think then that's what kind of can turn people around and say, no, I have a say in this, I'm a part of this. and I get to shape a little bit about what this is going to look like. They're going to shape it a lot. I mean, that's part of just the Azure way of working is that, hey, we're going to individualize this for this company, for this team. It has to fit here. And the more we can help people see, no, you're a co-creator in this. You're not just being told, but you're going to shape this with us.
Scott Dunn (25:54)
Right? Even with the leadership, I mean, it's easy. think everyone listening would agree. If you look at the common leaders, that's, even the, let's say director level and above personality types, right? For, for disc, it's going to be a high D for a strange pattern would be like command, um, computing values framework. They're going to be blue, get results, make it happen. But we need it to be, we need to be their decision for some of these folks. So when I would come to one of my bosses and say, I think we should do X every time he'd say like, yeah, let me think about. I'll get back to you. I kept thinking like, I don't understand because these are my people. I thought you trusted me. I realized, it has to be his decision. So part of what you're saying is invite him into the solution. So then I'd say, hey, we've got three options, good, better, best. What do you think we should do? Or I'd say, hey, I've done all the research, option A looks great, option B looks terrible. What do you think we should do? I mean, I try to simplify it. I tried to make it obvious, but I couldn't tell him I need to do X or we need this from you. It needed to be his input and to decide.
Brian Milner (26:44)
Right.
Scott Dunn (26:51)
once I framed it that way, he agreed every single time. I simply frame it, put it right in front of him so it's kind of an obvious decision, but I had to let him have that voice to decide. I'm really glad you brought that up. That one literally went from zero to 100 % if I changed my approach of how I had addressed it to let him be the one to decide and weigh in on that. Or even pitch it as a sales. Hey, I think it'd be great to move forward. What would that look like to you? Well, now he's talking about moving that change forward. without even realizing it, because you said to move forward, what would we need to do? And now he is co-creating, but it's already a yes, right? But by default, a little bit of sales, a little bit of sales effort there.
Brian Milner (27:24)
Yeah. Yeah, no, that's a, that's a good example. And that's a good example, I think for like the scrum masters listening and other people out here that are, feel like, you know, I'm not the leader in the organization. I'm not way up here and I can't, you know, have my decisions trickle down to other people, but, you know, kind of the, influencing up kind of mentality there. Yeah. It might sound like a little bit of a trick, but you know, if you can help. the boss co-create with you, right? Here's the problem. I've done some research. Here's some solutions. How would this look for you? Or what do you think of these options? Which one do you think sounds best? If I'm a boss and someone comes to me and says that I've researched this, here's the solutions that are possible. Which one do you think sounds best? That's really a service to me because you've just done a lot of work for me and I know that I'm doing my job by making the decision, but you've presented it and now I don't have to do anything but make the call. Yeah.
Scott Dunn (28:24)
Yeah, yeah. Simplify the decision-making or frame the decision-making is, think we might actually be kind of, I don't want to say teasing. I just hear some feedback from people at times like, leadership's was like, bright, shiny squirrel, right? And they get frustrated. But in some ways I'm thinking, well, at least someone in the org is decisive. I'll take that. But we can help them leverage that decisive trait they have.
Brian Milner (28:43)
Yeah.
Scott Dunn (28:48)
But for the good, instead of these random crazy things, you know, when the leader's like, I love Agile, I can change my mind all the time. We can, we can, we can guide them to better decision-making too. I love the influence both up and down what you're saying the Scrum Master can do. I think we miss, that we all have that ability to try to influence decision-making and shape some of this. Maybe there's more agency than we realized, I think for some of these folks, Scrum Masters, product owners, cetera, that you might be surprised. Like run an experiment, try some of these things out that we're talking about and see for yourself. I mean, all these personality types are different and your orgs are different. I totally understand that. Do something, inspect and adapt and see what you get. might, cause once you strike gold, you're like, you know, you're set on getting influence and buy-in from folks. It's really powerful network. Cause we don't need to give you a title or change the org chart in order to have results happen with you involved if you're that kind of a person. And I think you can really write your ticket in your career if you're able to do that soft skill of influence and buy-in up and down. It's great.
Brian Milner (29:43)
Yeah, yeah, that's awesome. Well, I hope that for at least the people that were in your class, this is is hit it right on the nail on the head for what it is they were they were thinking this would be about. But I think this is good. I think this is a good conversation and it's important, I think at all levels, because there's you know, this this affects us whether we're doing a massive transformation in an organization or
Scott Dunn (29:51)
Yeah.
Brian Milner (30:06)
We're just trying to influence up a tiny bit, you know, the food chain.
Scott Dunn (30:10)
Yeah, absolutely. Yeah, I hope that for the folks who were in that class, you better let us know if that was it. If anyone else is interested in other things, absolutely. We love hearing what your what those topics would be and bring on the right people. I will say that Brian, you brought in so many different voices. It's really, really great. So again, influence us. You can practice what we're talking about by putting those ideas up there. Other folks that we'd love to hear, because I love the the slated speakers you brought in. Brian's been really awesome. Thanks for this opportunity.
Brian Milner (30:34)
Thank you. Yeah, absolutely. Thanks for coming on again, Scott.

#152: The Five Pillars of Real Agile Improvement with Mike Cohn

Join Brian and Mike Cohn as they unpack the five essential pillars that take Agile from “just the motions” to meaningful, measurable impact. Plus, get a behind-the-scenes look at their revamped course built for real team transformation.
Overview
In this episode of the Agile Mentors Podcast, Brian is joined by longtime collaborator and Agile thought leader Mike Cohn for a deep dive into what really makes Agile stick.
They explore the five foundational pillars—mindset, practices, roles, teamwork, and support beyond the team—and share stories of what happens when teams get them wrong (like obsessing over story point math or demoing a copyright update in a sprint review). Along the way, they introduce the newly available Working on a Scrum Team public course and explain why it’s designed for entire teams, not just isolated roles.
Whether you're new to Agile or knee-deep in transformation, this episode will help you rethink how to build an Agile approach that actually works.
References and resources mentioned in the show:
Mike Cohn
#80: From Struggling to Success: Reviving Agile Teams with Mike Cohn
Scrum Team Roles and Responsibilities
Working on a Scrum Team Course
Mountain Goat Software Certified Scrum and Agile Training Schedule
Subscribe to the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
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 Milner (00:00)
Welcome in, Agile Mentors. We're back for another episode of the Agile Mentors podcast. Thanks for joining us. I'm with you, as always, Brian Milner. And today, I have the one and only Mike Cohn back with us. Welcome in, Mike.
Mike (00:12)
Thanks, Brian. Good to be here.
Brian Milner (00:14)
Always happy to have Mike on the show and really appreciate Mike making time to come on. Wanted to have Mike on because there's some things Mike's been talking about recently that are really interesting and people have been asking a little bit about this and I thought maybe it'd be just a good opportunity to talk through some of the stuff that Mike's been writing about. I know you spent, Mike, a lot of time helping teams to not just do Agile but to really get solid results from it. to see impact from it. And I know the topic you've been talking about recently is sort of these five pillars of supporting real agile improvements, the mindset, practices, roles, teamwork, and support beyond the team. So I thought maybe we could just dig in and drive through those and maybe learn a little bit about those as we go. Obviously also to talk a little bit about the exciting new course that's being launched here, the working on a Scrum team course, because I know that was originally just for private classes, right? And now it's being open to the public.
Mike (01:23)
Yeah, we've done working on a Scrum team as a private class for probably 20 plus years. It's been kind of our main offering to private clients. But we're hearing from a lot of people that they have one team and they can't really get a private class approved with the budget and such. So what we're doing is going ahead and making that course available as a public course. So two people from your company, five people from another company all in the same class the way we've done our certified courses for decades. And so we're going to start offering this as a public course. And the exciting thing there is that it's really meant to be a team-based class, where things like Scrum Master training, great class, but it's really meant for the Scrum Master, right? And working on a Scrum team is really designed, and you and I helped you and I design this course together, but it's designed to be something that is a whole team training, right? So good for anybody on a team.
Brian Milner (02:16)
Yeah, yeah, it's been really great teaching those in the private classes and I'm excited to think about the public being able to come in and take that now. Let's talk a little bit about these pillars and, I think people are gonna be really intrigued by the concept here. The first one is mindset, I think, and just wanna start there and say, what does it actually mean to... think Agile and what is the found, why is that kind of the foundation for successful transformations?
Mike (02:43)
Remember the kind of the early days of agile and there was a lot of conversation about could you be agile without understanding the principles, right? If you just did the practices, were you agile? Other people were saying, no, you have to start with the principles, right? And so do you start with principles? Do you start with practices? And I remember these early debates and they often devolved into a discussion of the karate kid movie, right? Remember that one, right? And, you know, can you just wax on?
Brian Milner (03:12)
Ha
Mike (03:12)
for long enough, just do the practices. And then all of a sudden, your karate instructor or your agile coach is, OK, you're agile. And it's like, wait, all I know how to do is wax a car, right? And so there were these discussions about practices versus principles. And I was kind of always on the side where you better understand the principles to do this. Just knowing the practices, waxing on all day, is kind of just going through the motions. And so you have to understand the principles. And the idea that I wanted was that if a team truly understood all of the principles underneath Agile, I don't just mean just the manifesto, but all the principles that are there from Lean, from Kanban, from everything, that if you really understood those, you'd kind of invent the practices, right? You do those and you go eventually to go, hey, we should probably meet every day. Or hey, if we tested first, that might be a really good thing.
Brian Milner (03:57)
Yeah.
Mike (04:05)
So you'd invent the practices if you really had that type of agile mindset. And so for me, when we're working with organizations to get them truly agile, and I don't mean like more agile than less agile, but agile in a way that's going to stick, you got to change mindsets, right? You've got to do more than just the wax on. So people have to get the mindset.
Brian Milner (04:27)
Yeah, I love that. I know that I've experienced some things in the course of working with people that's it's sort of like you, if you're not on the same page with the principles, then you start to talk through the practices and you run up against a problem. And really what you find out the core of it was, well, we weren't aligned on really the principle behind this. So why would I want the practices then, right? ⁓
Mike (04:49)
Yeah. Well, that's where you also end up then with a lot of team debates about things, right? Because you're arguing about the practice. if you'll say you and I are arguing about the benefit of some practice, if we agree on the principle, we might just have different views on it. But deep down, we'll probably agree on some practice, or we might find an alternative one. But if you don't agree on the principles, you end up with a lot more of these kind of annoying. mean, team debates are great. I mean, I love.
Brian Milner (04:54)
Yeah.
Mike (05:12)
you know, having a team debate, arguing stuff like that, but not about pointless things, right? And not without some sort of foundation. They just kind of get in the way. It's just frustrating for everybody.
Brian Milner (05:21)
Yeah. Well, I'm kind of curious, what kind of signs or signals do you think teams should look out for to kind of clue in and let them know that what might actually be going on here is more of a mindset issue?
Mike (05:36)
think sometimes it's when you hear the appeal to authority, right? Somebody says, you know, well, we got to do it this way because the scrum guide says, right? Or the one that annoys me is we have to do it this way because Mike Cohn says, ⁓ you know, that was like, no, I, somewhere else also said, think, right? Don't just, you know, don't just, you know, blindly do story points or something. Cause I say they're a good thing. I want you to think too.
Brian Milner (05:50)
You You
Mike (06:01)
And so I think that kind of appeal to authority when teams are debating things. It's where we also see teams who think they're agile because they do a set of practices. We use a particular agile tool, so we must be agile. We do daily meetings. We must be agile. And those are not the things that make you agile. Those are artifacts of being agile. If you're agile, you're going to meet a lot. You're not going meet a lot, but you're going to talk a lot. Um, and so those are the artifacts of behaving in an agile way. And so I want to understand why we're doing those things. So I look for those kind of appeals to authority. Um, you know, emphasis on that type of stuff in an argument talking about how this is the right way saying there's only one right way to do something.
Brian Milner (06:49)
Yeah, yeah, that's great. How does working on the Scrum team deal with this? How does that address it?
Mike (06:55)
Well, one of the things we do, it was actually one of my favorite exercises. We do this exercise at the start of the class where we ask people to kind of map out how the organization talks about certain adsel principles and then how does the organization behave. And so for example, if a company says, people are our greatest asset, and then they treat people like dirt, we've got this kind of problem between what we say and what we do. And so I like to kind of map this out. And so we do this with the principles in the Agile Manifesto. And once we map those out and we start to see things that we say we value, but we don't behave that way, really helps us understand if we've really embraced that mindset. Or are we just doing things because an Agile coach told us to, or a boss told us to, or we did it that way in our prior company. Those are all bad reasons to do something.
Brian Milner (07:48) Y
eah. So this is great. So I agree. The mindset's really foundational. And there is this symbiotic relationship between mindset and practices, which came first and which comes first, as we talked about. I know a lot of teams get stuck doing Agile, though, in really only name only. So when we talk about practices, what makes the difference between going through the motions?
Mike (08:00)
Mm-hmm.
Brian Milner (08:11)
and actually doing things that work.
Mike (08:13)
Well, practices is kind of our second pillar, right? You have to have the mindset, right? But you also have to have the practices that come from having that mindset. so, again, I try to think of that team on a desert island, right? And they're isolated from the world. They've never talked to anybody, but they have an agile mindset. What practices are they going to invent, right? And I think those are kind of the core practices. We see a lot of problems with as an example, teams that misunderstand sprint planning. And I know when I first started teaching about sprint planning, I'd have a slide up there to have a picture of a sprint backlog. And the sprint backlog listed tasks like code this, design this, test this. And then there were estimates next to code this. It's going to take four hours testing. It's going to take three. And so we were able see all these numbers and think the point of a sprint planning was these numbers. And Even in the early days of this, I was always saying, no, it's not about those numbers. It's about deciding what product backlog items you can pick. if taking a, I don't even want to call it an estimate, but taking a wild guess about, it probably can take four hours to code. If that helps you decide how many backlog items you can commit to, great, put those numbers up there. But it was never about the numbers. And it's one of the most common problems that I see with teams in sprint planning is they get obsessed with How many hours did we bring in? How many points did we bring in? And I remember one team I worked with where we did sprint planning. Having those estimates were helpful for them on their sprint back. They were helping. And we finished the meeting. And we're using Google Sheets in a meeting to do this. We've got a row with the estimates in there. And as we start to wind down the meeting, I deleted that column that they'd spent so much time talking about. They're all kind of pissed off at me. Why'd you delete that? We spent all this time talking about it. I said, because we got the benefit, right? You got the benefit of those numbers. The benefit isn't a week from now remembering that you said five hours, because it's going to take what it takes. The benefit was the discussion that it led to of can we take more or are we already full? So I see teams get obsessed with that. This is one example, but that's one of the problems with sprint planning as a practice.
Brian Milner (10:25)
Yeah. Yeah. I think you're absolutely right. And that's one of the things I know I've talked about with people going through the course is sort of understanding the purpose behind the things. Just going back to, know, harkening back to what you said about, don't just do it because someone told you, you know, understand why the purpose behind it. And, know, otherwise we, I'm sure we've all had that experience before where someone just tells you to do something and says, you know, why? Cause I told you so, you know, that, that doesn't, that's not very convincing.
Mike (10:52)
Thanks, Mom.
Brian Milner (10:53)
Right, right, thanks mom. Yeah, not very convincing, but it's much more convincing when they can tell you, well, no, you do this because this is what we're trying to do. And I think you're right, that makes all the difference there. ⁓
Mike (11:05)
It just, don't know anybody that responds well to being told what to do, right? My instant reaction is no, right? mean, you it could be, you know, a really, you it could be a really good thing. Eat more vegetables, you spend more time outside. No, right? Don't tell me what to do. So.
Brian Milner (11:09)
Right. Right. Yeah. It's almost like our default response is no until you convince me. Are there other common practices? We talked about sprint planning. Are there other kind of practices you see teams struggle with?
Mike (11:28)
Yeah, yeah, for a lot of people. think a huge one is product backlog refinement. I don't know what a better word would be than refinement. refinement is about making the backlog better. It's not about making it perfect. And I see teams that get stuck on backlog refinement and feel like they have to resolve every open issue, that everything has to be tiny and answered and buttoned up before we can start a sprint. And that's not the case. For me, the goal in refinement is to make sure things are small enough and sufficiently well understood. I don't want to bring in a backlog that's bigger than my velocity. If our velocity is 25, I don't want bring in a 50-point story. how about the problems of a 50-point story anyway? But I don't want to bring in some massive epic like that into a sprint. And so refinement is about making it small, making sure it's sufficiently well understood. Sufficiently well understood, not perfectly. And so
Brian Milner (12:18)
Yeah.
Mike (12:28)
The problem is these teams, and I know you've seen this, but teams who get in there, want to resolve every open issue. It's like, no, we can resolve that during the sprint. If we think about the goal and planning to make sure we know what to bring into the sprint, not too much, not too little, we're fine just enough that you're at that point. Is the button blue or red? Who cares? If it's a log in story, we're going to lock people out after some number of failed attempts. Who cares how many? Figure that out during the sprint. If it's five or three or eight, who cares? Figure that out later. So I think refinements won. Another big one would be reviews, ⁓ where sometimes teams demo too much in a sprint review. And they feel like they have to justify their existence, show everything you did during the sprint. And the most egregious example of that was this was a handful of years ago. But I literally remember a team showing
Brian Milner (12:58)
Yeah. Yeah.
Mike (13:18)
how they had updated the copyright notice on the footer of the web page, know, copyright, you know, whatever year our company, right? And it's like, my God, you didn't need to show that to stakeholders, right? We all either know there's a copyright notice on the bottom of the web page or we've seen one before. I don't need you to bring it up and scroll down to it. Now only took 15 seconds of the meeting, but that was 15 seconds of people's lives. They were never going to get back. you know, show stuff that you need feedback on, right? If you'd...
Brian Milner (13:41)
Right.
Mike (13:45)
You fixed a bug and you fixed it only way it could be fixed. Mention it perhaps, but you don't need to show it, right?
Brian Milner (13:51)
Yeah, yeah, know teams I've been on often it's just it's suffice it to have a list sometimes and just say here's a list of things if you want to know more about these come talk to us but we're move on to the stuff you care about.
Mike (14:02)
Yeah, I always have like a will show, will not show list. you know, I often, if I'm writing the meetup present, that'll put that up on Zoom or, you know, show it on a screen if we're in person. And often somebody wants to see something that's on the will not show list. Or they just want me to describe what bug was that again? What was that? You know, and I'll explain it really quickly. But if nobody wants to see it, don't bother showing it. So.
Brian Milner (14:26)
Yeah, I know we talk about these scrum practices quite a bit in the working on the scrum team class, but if someone signed up to take this class, what can they expect to hear or what can they expect to learn about these practices in the course?
Mike (14:39)
Well, I think one of the things that you and I did together in creating the newest version of the course was to look at what do you actually need to practice doing, and it's feasible to practice doing in a classroom setting, versus what should you just kind of talk through. And not everything needs to be practiced to get the hang of it, right? Everybody in the world has taken something big and split it up into smaller things before, right? I need to make. spaghetti dinner tonight. What do need to buy? Right? OK. Well, that's that's that's test decomposition by noodles, by sauce, by tomatoes. Let's make it from scratch. Right. By some garlic. Right. So everybody in the world has done decomposition. We've broken a big thing into small things. And I remember, you know, iterating over I'm still on sprint planning, I guess. But I remember iterating over exercises in sprint planning and in courses over the decades by now. And I would have one where you're planning a party for your kid, break it down into tasks. It's like, nobody learns anything from this. And so that's one where I'd rather say, OK, this problem occurs in sprint planning. How could you solve it? Other things like, let's say, splitting user stories or splitting job stories, that's a skill worth practicing together, getting feedback on. And so those type of things we try to practice in the course. other things we just talk about. mean, I'm curious on your thoughts on that. What do you think about some things being worth practicing, some things worth being better talked about?
Brian Milner (16:01)
Yeah, I agree. I agree fully. it's, it's, you know, there's some things, it's kind of like what you said before, there's some things that's not worth spending the time on, and it's better to just have a discussion and move on.
Mike (16:13)
Yeah. Yeah. I guess that's one of the things we always talked about. We always talked about return on investment of the exercise. What's the return on the exercise? And if you're going to have a one hour exercise, cool. One hour exercise. But it better have a pretty healthy return because that's a lot of time in class. And so what's the return on exercise? Is this worth a practice? Is it worth just a discussion? And if we can discuss two hard problems and give people advice on two common problems, they're probably going to face.
Brian Milner (16:21)
Yeah.
Mike (16:41)
Might be better than spending 20 minutes practicing something that they've probably done before.
Brian Milner (16:45)
Yeah, I completely agree. Let's move to the third pillar then, because I know this is a big one, just thinking and talking about the roles. And just as far as communication issues are concerned, even outside of Scrum, I know that's part of the big problem with teams and organizations just not being clearly defined about who does what and who's responsible for each thing. So those misunderstandings are really common failure points. ⁓
Mike (17:09)
Mm-hmm.
Brian Milner (17:10)
How do you see teams getting that wrong and how's that derailing a Scrum team?
Mike (17:15)
Well, think we see it all the time on Scrum teams between Scrum Master and Product Owner and even the development team, right? Who does what? I was responding to some comments on LinkedIn this morning on some post I'd made last week and somebody had some comments. And it had to do with whether the Scrum Master or Product Owner does something. And it was interesting because in the comments on that post, I... I don't remember which one it was, but I shared a certain perspective. I feel pretty strongly that I have it right. I mean, I this is how we do it. But there were other people saying the opposite, right? And so, you know, these are people that are probably fairly experienced with Scrum, if they're following me on LinkedIn and feel comfortable commenting on a post, probably feel comfortable with it. And so there's a lot of confusion about what role does what thing. And I don't think this is something where the Scrum guy is going to have the answers for you. I think it's, I mean, you can look at the Scrum guy, oh, this. Here's my starting point answer, but we always want to play to people's strengths, right? And if you've got a scrum master who's got a lot of skill in one area, maybe they shift a little work from the PO to themselves, right? With the PO's permission, right? And the opposite, right? Between maybe PO and team. So it's fine to have default starting positions on who does what, but you always want to play to people's strengths. So I think PO scrum master, I think we see it with project managers and scrum masters, roll confusion on those type of roles as well.
Brian Milner (18:38)
Yeah, completely agree. A lot of those roles that are not named Scrum team roles and how they interact with the team, that's often a source of confusion as well. What are maybe some signs or symptoms that teams might be having confusion or problems in this area that maybe they don't even recognize or realize they're having an issue with roles?
Mike (18:59)
Any sort of conflicts, right? You know, you and I arguing over which one of us should do something. The other one would be kind of the opposite, which would be like a dropped ball. I was watching some YouTube video. I love baseball. I was watching some YouTube video the other day of like missed catches or something like that. And some team hit a baseball way up in the air and it was landing near three players, right? Three players are all looking at it.
Brian Milner (19:12)
You
Mike (19:23)
One guy waves the other two off, he's going to catch the ball and he must have been blinded by the sun because he's like six feet from the ball when it lands on the ground, right? And, you know, if we have a responsibility to catch the ball, run this meeting, right, right the backlog, the kids dropped, right? And so I think either arguing over who does something, two of us trying to do the same thing or neither of us doing it. I don't mean trying to get out of the work, right? All three players have been happy to catch the ball, but I think you've got it. You think I've got it, right? Those type of things are pretty good signs. think getting clarity around these roles can really optimize how a team works. And I think a really key thing here is that it changes over time. So I'll go back to my example of maybe the Scrubmaster has some skills that can help the product owner early on. Because maybe the product owner is new to the company. The product owner doesn't know the product as well. So they might rely on the Scrubmaster for guidance on things. Well, a year from now, we might shift responsibilities a little bit because now the PO is the expert on all things related to the product. So it's not like we want to establish clarity on roles one time and leave it forever. It's going to change. We get a new tester on the team, things might change. Product owner moves. It's going to change again. So we need to realize these responsibilities are dynamic.
Brian Milner (20:39)
Yeah, that's a great point. Your point about baseball just made me think about how, when you watch any youth sport in the world, when you go watch your kids play a sport, what's the one thing you always hear people scream from the sideline? Talk to each other. Call the ball. Well, that too. That too. Ump your blind. Those kinds of things. Well, let's talk a little bit about
Mike (20:52)
I thought you were going say, put my kid in.
Brian Milner (21:00)
I know this course addresses the roles and how would you say this course really helps address that issue of role confusion?
Mike (21:07)
think a big part of it is that we designed it to be for everybody on the team, right? Suppose you send a scrum master to a class, and it's a great class. Scrum master is going to back to the certain set of impressions about their role. Product owner goes to an equally good class about the product. They might have different impressions. Even if they took the course from the same instructor, they're hearing it a little differently. They're hearing it through their filters, right? And so when they're in a course together, there's more opportunities to clarify their understanding about those things, especially in the classes designed as we did with this one to bring out some of those differences. So I think the course helps with that. we've also designed it to mention the rules we haven't talked about, like managers and things like that.
Brian Milner (21:53)
Yeah, yeah, I think those are so important. And there's a lot of great discussions that come out when we have those topics. ⁓ Let's talk about the fourth pillar then, teamwork, because this, I think, builds really well on what we just talked about. And the idea that there's actually, Scrum is a team sport. ⁓ So beyond just normal human personality conflict type issues, what do you see that gets in the way of teams actually
Mike (21:58)
Mm-hmm. Mm-hmm.
Brian Milner (22:18)
working as a team.
Mike (22:19)
think ego is probably one, right? I can do everything better, just leave me alone. There's an old book that says basically, beware of a lone developer in a room, right? You know, it was referring to the developer who wants to close their door and say, I'll it done in a month, trust me, right? And one of the companies I worked with, and this one's going back like 15 years ago, but it was a really good story.
Brian Milner (22:36)
Yeah.
Mike (22:43)
is they would literally grab one unit of work. Each person on the team would grab a unit of work and take anywhere from three to 12 months to do the thing. So they were big things, but the person would do everything on it. They'd coded, tested everything. And the organization was putting out very little because of this. When they moved to Scrum in the first year, by their estimate, they said they delivered 540 % more work. over five times the amount of new features delivered. And that was through the collaboration, through the short iterations, those type of things. But it was about getting people to collaborate more. So I think there's huge opportunities to do that. One of the problems I see is when we don't overlap work. If we think about that organization I just described, you grab your thing, you're done in six months. I grab mine, I'm done in seven months. If we'd work together on those things, what's not make us any faster? No faster. But you and I could have worked on your one thing and been done in three months. OK, we're delivering value in three months, right? And so one of the things I look for a lot is how much teams are overlapping work, right? And if we're not overlapping work, there's huge opportunities to improve at that. I'll a little example of this. One of my favorite restaurants is, I don't know, barely call it a restaurant. It's a fast food deli. It's called Jimmy John's. Have you been to Jimmy John's, Yeah. Yeah, there's one near my house where I can go there and the wine will be out the door. Right. And you know, normally you see a wine out the door and it's like, crap, I'm going somewhere else. Right. These guys are so fast. They're so fast. When I get to the front, I place my order. I play this little game of can I fill up my cup? You know, I get an iced tea and they give me an empty cup and can I go fill up ice and put the tea in before they hand me my sandwich? And it's about 50-50. Right. It doesn't take long to fill up your iced tea. But the way they do that is the overlap work. As soon as I order my Italian club sandwich, somebody's already got the bread open, somebody's got a slab of meat they're ready to drop on there, somebody else has their hands over the vegetables and they're dropping the vegetables on there, and then a fourth person wraps it up. And so like four or five people touch my sandwich. Hopefully their hands are clean, but four or five people touch my sandwich as opposed to like most delis where I go and it's like you watch one person plod along making the sandwich, right? Overlap work is huge.
Brian Milner (25:07)
Yeah. Yeah, this episode sponsored by, no, just kidding. Use code Mike Cohn when you go to, no, just kidding. Yeah, I agree. And yeah, yeah, I'm familiar with Jimmy John's. Probably too familiar. ⁓ Yes, yeah, no, that's, I think that's part of their shtick is that they're, you know, they're known for being fast. So yeah.
Mike (25:10)
You Is yours just as fast? Yeah. Yeah. They call it Freaky Fast. They actually have a competition. I've seen YouTube videos of this where they get like the best teams at various restaurants race, right? And so they have like the Jimmy John sandwich making Olympics or something, but it's a skill.
Brian Milner (25:36)
wow, wow, yeah. You should pair that up with the hot dog eating challenge in some way and see if we could have a team sport going there. ⁓
Mike (25:48)
Well, that's a good point because think about the hot dog eating. That's one guy, right? That's Joey Chesnett shoving hot dogs down. The Jimmy Johns is a team. They get the best crew at a restaurant and it's a team, right? How fast can the team go? Not how fast can one guy make a sandwich, right?
Brian Milner (25:51)
Yeah. Yeah, yeah. That's awesome. So what are some tips? What are some ways that you can really unite a team, especially those new teams? Because that's the fascination point for me is, how do you take this group of humans that really don't know each other and haven't worked together in the past and unite them together and have them gel as a team? How do you do that?
Mike (26:21)
I'll give you a couple. One, I think having really crisp sprint goals helps. So we all know exactly what we're trying to get done in the sprint. We don't lose sight of that because sometimes in the middle of a sprint, you lose sight of it. And you get myopic and you just focus on a list of tasks. And I'm going to say that it's probably similar to the team doing sprint planning and just getting them assessed with the numbers. It's not about the numbers. It's not about the tasks. It's about the backlog items that lead to some goal. So crisp sprint goals help. That's a hard phrase. Crisp Sprinkles helps. The other one I'd say is having a shared vision about where you're headed over a little bit longer term. Probably the biggest change to the Scrum Guide ever that I've liked is the inclusion of a product goal. And that was something I'd been talking about forever. mean, literally since I started doing Scrum was that sprinkles are great, but they're pretty short, right? You want to have something bigger.
Brian Milner (26:52)
It is.
Mike (27:14)
And so I like having product goals that are a few months out there. And one of the things I like doing for product goals is have teams do something like write a press release that describes their goal or create a vision in some way, write a review that you want to see come out on the App Store, Play Store, and a magazine. And one of my clients made software and they were reviewed by a major magazine and they were given an editor's choice runner up award. And they actually estimated that being runners up for that was probably worth about $10 million. First place, first time was worth about $10 million a year to them. And so they decided to get serious about this and they wrote a review. Their scrum master, she was actually combo scrum master product owner, Erin. She had the team write a review and she said, let's go earn this review. And I literally remember the email I got from her three months later. It was because it was Halloween night. I just like, you know, brought in the candy from outdoors. We're done trick or treating. And I checked my email. I a three word email from her from Erin. said we did it. And the magazine had let her know, hey, we're reviewing you. be out on, you know, like Tuesday's edition. And the review had quotes in there that were from their vision review, right? The things that they had wanted to achieve.
Brian Milner (28:22)
Ha ha.
Mike (28:35)
And that team had just really jelled around that and just became so much more productive and collaborated so much better because of that shared vision.
Brian Milner (28:43)
Yeah, that's amazing. getting back to the course then, I know in the course we're trying to kind of some of those collaboration muscles. What are some of the ways that the course helps to build that?
Mike (28:56)
think one of the key things that we're doing, and I'm excited about this, is that we're, you know, we of course use Zoom breakout rooms, right? You you go talk about this, we'll see you in eight minutes or something like that. And for this course, we're doing something where a group of three or more, when they register, can have a private breakout room. And this to me is exciting because people get the benefit of having a private breakout room. They can have sensitive discussions if they want. They can talk very specifically about. you know, what do we do about our jerk product owner? mean, whatever it is, right? You know, they can talk about their specific issues, yet have the context of a broader class. Because I think in one of the benefits of any public class is hearing how other teams are doing things. And sometimes that's because you get a good advice, you know, how did you solve that problem? We have that problem. Other times, it's just feeling that you're not alone in the world. they've got that problem too, right? And they don't have any solution for me, but I know I'm not alone in the world with this. And so I like these private breakout rooms for three or more. I think it's a novel thing we're doing with this class. And it's with the intent of combining the best of both worlds of private and public training for this. I'd the other thing is probably consistency, having everybody on the team hear the same message, having those discussions with an experienced instructor like you or me in the room to provide guidance when they have questions. know, go back to the role clarity, right? You know, they can talk about it and they're there. Then they're back in the main room with you or me and we can kind of answer questions. So I think that consistency will be huge as well.
Brian Milner (30:25)
Yeah, yeah, I love that idea of the private private breakout rooms that that's that's gonna be huge for a lot of people I know. ⁓
Mike (30:31)
I'm excited to try it with this. This will be the first classes we do that for. I'm excited about it.
Brian Milner (30:36)
Yeah, yeah. Well, let's bring it home then and talk about the fifth pillar because the fifth pillar is really interesting as well. It talks about support beyond the team and teams can only do so much. Every team struggles when they're not supported well. And there's lots of studies that show leadership support is one of the biggest hurdles or obstacles to the adoption.
Mike (30:46)
Mm-hmm.
Brian Milner (30:59)
What does that support look like from outside the team and how can a team influence that?
Mike (31:06)
Yeah, if you're trying to be agile and your HR group has quarterly reviews of personnel that are all based on individual performance and has nothing to do about teamwork in there, it's going to be hard to focus on collaboration. So we have to kind of fix these issues. I think what we have to do here is to have team members educate those outside the organization. And we have information that we share about, you here's how to talk to a boss that's maybe mandating deadlines, things like that. And so we try to coach people through having some of those challenging conversations. And one of things I want teams to do is kind of become an example of what good agile looks like. And if you have a team that's excelling with agile and they're doing it from a kind of principles first, that mindset first approach. You're going to see other groups look at that and let's say the marketing group. They're going to look at that go, hey, that's an interesting way to work. I wonder how we could do that, right? And it's going look different for a marketing group than a tech team. the mindset is going to be the same. Principles will still be the same. And so when we get teams to do really well with this, other parts of the organization start to get interested. And then they stop being as much in our way.
Brian Milner (32:20)
Yeah. I know one of the most important aspects here and that we talk about is, is that you don't need to, to wait, right? If you're the team level, you don't have to just sit around and wait for the organization to make changes. you, you have opportunities to make changes as well. So how does that happen? How's the team change, you know, bring about those changes that, improve the agile process, the results.
Mike (32:42)
I think that's by being the example so that people see it. I think it's by having those conversations. You know, one of the things that we'll get is, you know, it's so common is the product owner that wants to change their mind all the time. I was reading something, I guess this is in our Agile mentors community, I think is where it was, but it was about the, you know, the product owner who said his favorite thing about Agile is that he can reprioritize every week. ⁓ And it's like, you can, you know.
Brian Milner (33:05)
Hmm. Yeah
Mike (33:10)
I'm not sure it's good. And I think about that, a team gets momentum, right? And you're working on a certain feature. Next sprint, it would be nice to work in that same area of this system, right? Your head's there. Just kind of keep going a little bit. And I've often described this as like, let's say you're working on three backlog items that are in a certain area of this system. Let's make it concrete. Let's say it's the spell checker in Microsoft Office, right? And you do three backlog items related to the spell checker this sprint. Next sprint, maybe your top priority is not more spell checker stuff, but maybe items, I don't know, 25, 26, and 27 on the backlog are still in the spell checker. You know what? It might be better to do those. There are probably two or three sprints away. Let's bring them into this sprint. Just get them done while my head's into spell checking. And so getting product owners or stakeholders to stop doing that, one of the ways that I like to talk about doing that is using an example of ordering a meal at a restaurant. I can order, let's say, the chicken entree. And then as the waiter is taking the orders around the table, I change from chicken, no, bring me the fish. Not a big deal. The waiter is going to cross off chicken and write down fish. If the waiter goes away, brings me back my salad, and I change my mind then, I say, hey, bring me the fish. Might not be a big deal. It's going to be a big deal if I've already taken three bites of the chicken. right? Or if he brings me the chicken. So yeah, we can change our mind, but there's a cost, right? And we want to educate stakeholders about that cost. They don't overdo it.
Brian Milner (34:31)
Yeah. Yeah. Well, speaking of the leaders and the organization, managers, leaders, do you think this course is appropriate for managers and leaders to attend as well? you feel like they might need to in order to really have this be an impact?
Mike (34:55)
Yeah, that's a good question. Is it appropriate? Yeah, I think it's appropriate. When we do this privately, we've had plenty of leaders and managers attend. I think it's great. I don't think that's required because they're not on the Scrum team. You said the name of the course is working on a Scrum team. And so they're not on the Scrum team. They benefit by knowing more how their Scrum team works. But I think what we found is that having just a key subset of people who hear the same message work through the training together, and then go back to the organization. That's enough to bring the passion, conviction, and skills that we want. So we don't truly need leaders. They're great. I would never talk a leader out of going, but I wouldn't. If I were a team and I could take the class this month or with my leader next month, I would just get the class done, right? And educate the leader afterwards.
Brian Milner (35:41)
Yeah. Yeah, yeah, I think that's a good plan. All right, well then we've made our way through the five pillars and for people who have come this far with us and are at this point, if they're listening and they're recognizing some of these problems we've been talking about, what would you recommend to them as next steps here?
Mike (35:49)
if Well, take a look at our website. If you go to mountaingoatsoftware.com. And then I think there's a courses link on the top. You can go up there and find the link to this course. It's an exciting one that we're doing. I've literally been teaching this, I think the first time I taught a class called Working on a Scrum Team was 2003 or 2004. it's a time tested course. You and I kind of redesigned it a couple of months ago to make it appropriate for public. or little better just in general and more appropriate for public. But it's a time-tested course that's now designed to be available for public settings instead of, you know, have to have 25 people or something.
Brian Milner (36:36)
Yeah, yeah, that's really exciting. I can't wait to see kind of how people are in, you know, react and interact in the course to some of these concepts and ideas. And we'll, we'll of course link to all these things that we've talked about in our show notes and make it easy for everyone to find the course listing and, and, you know, where the dates and everything that we're going to offer them. So make sure to check that out. Mike, thanks so much for coming on. This has been really enlightening and I appreciate you making time for it.
Mike (37:01)
Of course, thanks for having me, Brian. Always a pleasure.

Pressing Pause: A Summer Break and What’s Coming Next

We’re taking our own advice and hitting pause to recharge this July. While we’re off the mic, revisit past episodes packed with timeless insights and conversations you may have missed.
Overview
This week, we're pressing pause to model the sustainable pace we teach. Brian shares a quick update about our summer break, what’s ahead in August, and how you can make the most of the podcast archive while we’re away.
Whether you’re poolside or simply stepping back from the daily sprint, we hope you’ll join us in creating a little breathing room and we can’t wait to be back with a fresh season soon.
References and resources mentioned in the show:
Subscribe & Listen to Previous Episodes of the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Auto-generated Transcript:
Brian Milner (00:00) Hey there Agile Mentors, this is Brian Milner and I'm just gonna take a moment of your time today because we're actually going to be practicing what we teach here at Agile Mentors and we're gonna be working at a sustainable pace. So for us that means we're gonna take a few weeks off. It's summer and I know many of you are going to be taking time off with your families and we're gonna be doing the same thing.
So we won't be around for the next month. We're gonna be out of here for July, but already have some plans for when we come back in August. So stay tuned when we come back in August, we've got a new season of shows that will begin there in August that I think you'll really enjoy.
While we're off, might I suggest you go back through our archive. Look at some of the previous podcast episodes we've done. There's quite a few now. And maybe you've missed some of the episodes from the past. Go back and find some of our great guests that we've had over the years when we've been doing this. I think you'll find some really great guests and some really interesting topics. So fill your diet of Agile Mentors with that while we're at taking a little bit of a break here at Agile Mentors.
I hope you're having a great summer and we look forward to seeing all of you back here in August. Take care.