Podcast appearances and mentions of Mike Cohn

Remove From Your Process as Often as You Add To It - Mike CohnCan you imagine being so angry about a team doing something wrong that you institute a rule for them to follow for the next 100 years? Literally 100 years.Queen Victoria was that angry.One day in 1894, the Queen went to the Horse Guards building expecting her Household Cavalry to be ready to escort her back to Buckingham Palace. She instead found the guards either asleep, drunk, or gambling.Infuriated, she commanded that an inspection of the Guards be held at 4:00 p.m. every day for the next 100 years.I'm guessing the Guards got the message to stop sleeping, drinking, and gambling on duty long before 100 years. The 4:00 p.m. inspection could have stopped after perhaps a year or two. Maybe sooner.Things that become part of a team's process sometimes stay there too long, like that inspection of the Queen's Horse Guards.This happened in a company that had a large database that was shared by multiple applications. When one team changed the database, they screwed up the change and left other teams scrambling to quickly change their code in production.They held a multi-team retrospective and agreed that each team would produce a Database Impact Report every sprint. The report would describe how a team's work would affect the database.This doesn't sound horrible yet, except it was rare for most teams to do any work at all in a sprint that would affect the database.These teams were still expected to complete a Database Impact Report each sprint that basically said: No impactNo impactNo impactThese no-impact Impact Reports were emailed to all other teams.After opening a PDF every two weeks that said “no impact,” recipients stopped bothering to even read the reports that were still being generated.Stop. Just stop.These reports were probably useful for a period. They may have helped identify a risk. They certainly made people more aware of the impact a database change could have on other teams.But after a while, they should have been removed from the teams' process, especially once the teams who actually did routinely alter the database had found better ways of communicating potential impacts.In retrospectives, it's always tempting to look for new things to add (“Let's start using AI to inspect our code!”).But make sure you also reserve time in retrospectives to look for things to remove.Unless your team members are all drunk, gambling, or asleep at 4:00 p.m., you can probably find something to remove from your process.A barely sufficient process with unnecessary actions and rules removed will help you succeed with agile How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

What does it look like to lead a 300-person software org inside a 1,000-person company—and still stay focused on people first? Brendan Wovchko shares what he's learned about leadership, agility, and building a culture that actually works. Overview Brendan Wovchko, CTO at Ramsey Solutions, joins Scott Dunn to talk about what it really takes to lead Agile teams inside a large, fast-moving organization. From developing leadership habits to navigating team dynamics and staying grounded in purpose, this conversation is full of thoughtful takeaways for anyone working at the intersection of people, process, and product. References and resources mentioned in the show: Brendan Wovchko Ramsey Solutions #80: From Struggling to Success: Reviving Agile Teams with Mike Cohn #143: What Still Makes Teams Work (and Win) with Jim York What Is a High-Performing Agile Team? by Mike Cohn Four Quick Ways to Gain or Assess Team Consensus by Mike Cohn Elements of Agile Assessment Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: 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. Brendan Wovchko is the CTO of Ramsey Solutions and a lifelong student of what it takes to build great software, lead great people, and scale both with purpose. With roots in engineering and startups, he brings decades of hands-on experience in product, leadership, and agile culture—plus a knack for turning big ideas into results that matter.

Three Ways to Handle Unfinished Work - Mike CohnOver the past three weeks, I've been sending you tips about spillover on agile teams. We've talked in depth about the problem of habitual spillover—when a team routinely rolls unfinished work forward from sprint to sprint.This week, I want to share 3 ways to handle the unfinished work that will occasionally be left over by even a great agile team. 1. If You Want a Guarantee, Buy a ToasterMy first bit of advice for how to handle unfinished work is to remember that even the best agile teams sometimes miss their goals. That's OK and even desirable to a certain extent.Sprint goals are not guarantees. (As Clint Eastwood's character Nick Pulovski says in The Rookie, “If you want a guarantee, buy a toaster!”) Leaders, stakeholders, and even the team themselves might need an occasional reminder about this.A team's commitment to a sprint goal is a promise to do its best to achieve that goal. If team members are perpetually forced instead to make a guarantee, they will guarantee less in order to be safe.Sometimes a team needs to make a guarantee. There might be times when a client or customer needs a capability by a certain date. The finance group may need to run year-end reports in early January, for example.In general, though, we don't want to force a team into a guarantee. We ask a team to commit to something reasonable and then we're understanding if they miss it. Falling short on the occasional commitment is not a failure-–it's usually a sign of bad luck or a team that's striving to do too much. 2. Don't Roll Work Forward AutomaticallyMy second bit of advice is to resist the urge to automatically roll over the unfinished work into the next sprint. Put it in the product backlog instead.The item may be back on the product backlog for a millisecond, but there should be a conscious decision by the product to continue work on it.(Logistically, I don't care if it's easier in your tool of choice to move the item to the next sprint rather than to the product backlog first. The key is that there is a decision to continue the work.)If the product owner decides the team should work on the partly finished item immediately in the next sprint, bring in the product backlog item as is. Don't re-estimate it. Don't rename it. Don't take partial velocity credit. Just bring the item into the next sprint and take the full velocity credit when it's complete.But if the item is deferred for later, go ahead and split the story into what makes sense. Take partial velocity credit for the work you completed last sprint, then write a new story that describes only the missing functionality and estimate that story. 3. Document the CauseMy final bit of advice for dealing with unfinished work is this: Whenever work is unfinished at the end of a sprint, the team should take time in the retrospective to consider whether it was preventable.Sometimes unfinished work is just bad luck or bad timing, such as a team member being ill or a problem being found late in the sprint that could not have been found earlier. Sometimes it's just the result of aiming too high for one sprint.But you might uncover something that is becoming a bad habit.Whatever the cause, it's always worth considering whether something can be done to prevent it from affecting future sprints so that your team can succeed with agile.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

How to Break the Spillover Habit - Mike CohnFor the past two weeks, I've been writing about the problem of habitual spillover—when a team routinely rolls over unfinished work from sprint to sprint.So far, we've talked about why spillover happens, and why it's a problem, plus I've given steps to start a reduction in your team's spillovers.This week, I want to share two ways to break your team's rollover habit. Sometimes teams miss their goals. That's OK. Sometimes teams miss when they aim high and fall a little short. Don't try to fix those teams—celebrate their effort.Other times teams miss because they just hit a run of bad luck for a handful of sprints. Again, no need to intervene there. (Next week, I'll share what to do with the unfinished work that results from either of these first two scenarios.)Most often, though, teams miss because they are overly optimistic about what they can achieve. They plan each sprint to be a best-case scenario.If you think that could be your team, in your next sprint planning meetings try asking questions like these: What could go wrong that could cause the team to miss its goal?What has to go right to achieve this goal? These questions can help a team see any risky assumptions they're making about how easy the planned work will be.  As most of us who made New Year's resolutions at the beginning of 2025 have re-discovered by now, old habits die hard. Sometimes you have to take drastic action to realize lasting results, and to succeed with agile.Curb Their Enthusiasm   Drastically Under-commitIf these kinds of questions don't help the team make more realistic guesses about what they can accomplish, you might have to resort to drastically reducing what the team commits to achieving.At the next sprint planning, encourage your team to truly under-commit. I'm not talking about cutting the sprint goal by some small amount, like 10–20%. I'm saying you limit team members to committing to only 50% of what they believe they can accomplish.The team may push back on this. They are used to filling up their sprint and will be optimistic that they can get a lot more done than the items they've chosen. Don't give in.When team members push back, remind them that if they run out of work to do, they can always bring more in. But hold firm that no work will come in until the sprint goal is achieved and all the work planned into the sprint is complete.(You'll likely need to have a talk with the product owner prior to sprint planning so they too can be prepared to hear that the team is bringing only a few items into the sprint.)The goal in under-committing is to let the team feel what it's like to add work into a sprint rather than always needing to drop work.After they feel this, they'll likely want to feel it again.Encourage them to plan a bit more work into the next few sprints until they get close to missing their goals and rolling over again. Incorporate the enthusiasm-curbing questions as needed.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

What do Spotify, Google Meet, and your expense report tool have in common? They could all delight your users—if you design for more than just function. In this episode, Dr. Nesrine Changuel breaks down the emotional motivators that transform average products into unforgettable ones. Overview What separates a good product from a great one? According to Dr. Nesrine Changuel, it's not just meeting functional needs—it's creating emotional delight. In this episode of the Agile Mentors Podcast, Brian Milner sits down with Nesrine, a former product leader at Google, Spotify, and Microsoft, to explore how emotional connection is the secret sauce behind the world’s most beloved products. They dive into Nesrine’s “Delight Framework,” reveal how seemingly mundane tools (like time-tracking software or toothbrush apps!) can create joy, and explain why delight isn’t a nice-to-have—it’s a competitive edge. Whether you're a product owner, product manager, or just want to build better user experiences, this episode will change how you think about your backlog forever. References and resources mentioned in the show: Dr. Nesrine Changuel Product Delight by Dr. Nesrine Changuel Blog: What is a Product? by Mike Cohn #116: Turning Weird User Actions into Big Wins with Gojko Adzic #124: How to Avoid Common Product Team Pitfalls with David Pereira Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Dr. Nesrine Changuel is a product coach, advisor, and speaker with over a decade of senior product management experience at Google, Spotify, and Microsoft, where she led major consumer products like Chrome, Meet, Spotify, and Skype. She holds a Master’s in Electrical Engineering and a PhD in Media Processing and Telecommunications and is based in Paris. Auto-generated Transcript: Brian Milner (00:00) Welcome back Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always Brian Milner and today I have a very special guest with me. I have Dr. Nesrine Changuel with me. Welcome in Nesrine. Nesrine (00:14) Hi, Brian. Thanks for having me. Brian Milner (00:16) I'm very excited to have Nesreen with us. I think this is going to be a really, really great episode for all of you product owners out there or product specialists, anybody who works in the product area. I think you're going to find this really interesting and you're going to want to bookmark this one. Maybe even come back to this a little bit. Nesreen is a coach, a speaker, particularly in the product area. She has previously worked at Google. She's worked at Spotify, at Microsoft, so no stranger to large enterprise, very high profile products that she's worked on in the past. She has a book coming out in May, so look for this book. It's called Product Delight. And that's really what we're going to be focusing on here is the concept of eliciting or generating kind of an emotional response to our product. I guess I'll start by, did you stumble upon this? What drew your interest to people's emotional response to products? Nesrine (01:19) Yes, so maybe I can share the story how I came to this topic and how I became so vocal about it. So in addition to being a product manager and leader over the last decade, I was always and I always enjoyed being a speaker. So I always wanted to go on stage and share insight. This is probably coming from my research background, because when I used to be a researcher, I traveled the world to go and present my research work and When I became a product manager, I kept this habit with me. So I always been on stage and I spoke about different topics like product discovery, product operation, different topics. Until one day I got reached out by a conference organizer and he said, Hey, Nisri, we want you on stage, but we have an idea for a topic for you. I'm not that used. Usually I come up with idea myself, but I said, okay, what do want me to talk about? And he said, Hey, Nusreen, you have been working for Spotify, for Microsoft, for Google Chrome and Google Meet, and we all admire those products and we consider them very successful products. What if you come and tell us what's the common thing that probably is there any common thing that made those products successful? Being an insider, being within those company, could you share with us something that you consider in common between those products? To be honest with you, I found it challenging at the same time interesting as an exercise. I was not, by the way, able at that time to answer the question, what's in common? So I sat down and I did the exercise myself and I started to think what was really in common? What made Skype Skype? What made Spotify Spotify and those Google products so successful? And I came to the following conclusion. I found that what made those products so successful is that they don't only solve for functional needs, but they also solve for emotional needs. So when we use a particular product, we use it for a certain functional need, but we also use it for an emotional need. And without even knowing that I have been doing it for more than 12 years, I came to the conclusion that, my God, during all those years, I have been focusing so much into users need from both angle, functional and emotional. So I came on stage and I spoke about that topic and from that day, I started to give it a name. I'm calling it emotional connection. I'm calling it product delight. And I'm here to share more about it as well. Brian Milner (03:50) That's awesome, yeah. I mean, I think we do hear a lot and we focus a lot on that functional kind of need, the way you differentiate there. think that's a good differentiation, functional and emotional kind of needs or motivators there. yeah, I mean, I've always heard, know, kind of that kind of general product advice is, you know, find the things that... people really, really have as huge needs, the things they would pay someone to do for them. And that's the key to success is finding those huge needs. But we're actually going beyond that to say, yeah, those are important. It's not to say that we should skip that, but it's when there's the emotional connection to a feature or to something that we do that really the light bulb kind of comes on for our customers. Is that kind of what your research is leading to? Nesrine (04:40) you're getting it right. Don't get me wrong. Of course you have to honor the functional needs and serve the functional feature, but the delight or the emotional connection happens when you go beyond exactly how you said it. Let me explain. If you serve only functional needs, you know what you get? You get satisfied users because they are asking for something and they are satisfied about what they are receiving. Now, Brian Milner (04:41) Okay, okay. Haha. Nesrine (05:05) If you surprise them by going beyond, by anticipating their need, by exceeding their expectation, you're not only satisfying them, you're surprising them in a positive way and delight is the combination of surprise and joy. Actually, the theoretical definition of delight is a combination of two emotions, surprise and joy. So going beyond, anticipate need and exceed expectation. is what we should aim for in addition to the functional needs. Brian Milner (05:35) That's awesome. Yeah, I use this example sometimes in, we use this example in the agile world to talk about, you know, the part of the agile manifesto that says customer collaboration over contract negotiation. And, you know, there's an example I use from my past where I used to work at a company that was very contract driven. And, you know, the thing that I always used to kind of take away from that was the very best we could ever do or hope to do. was to meet our customers' expectations. We could never, ever exceed it because we were only doing exactly what they told us to do. So I think this is a really important distinction here to make that just meeting the customer's needs, just meeting the minimal customer satisfaction bar, that's not going to keep you with loyal customers. That's not going to have repeat customers, or they're not going to tell their friends about, you know. That product did exactly what I hoped it would do. But it didn't really surprise me. It didn't really go beyond that. I know you talked about, because I've read your blog and a little bit of the discussion about this. So I know you talk about in the blog kind of the connection to Kano analysis. And I've always thought that's a really great way to try to determine things to target and go after. So talk to us a little bit about that, about Kano analysis and kind of what that uncovers and how that connects to what your research has shown. Nesrine (06:51) Yes. I love Kano by the way. I, I mean, that's one of the framework I have been considering throughout most of my product career. But this framework comes with a limitation and let me explain. So first of all, for those who are not very familiar with Kano, Kano is a visualization or categorization, let's call it. It's a categorization framework that allows to categorize features among different categories. One of them is must have. So these are the things that absolutely have to be in the product. Other that are performances, which are the more you have, the more satisfied users are, the less they less satisfied they are. And of course there are the delighters and delighters are those feature that when they are in the product, users are surprisingly happy. And when they are not, are not even the satisfaction is not even impacted. So the limitation of Kano is that it doesn't tell you how to achieve delight. Let me explain. I think we live in a world that everyone agree that we should delight our users. I mean, this, this concept is now globalized and everyone is talking about delighting users. The issue is that we don't know how to delight them. So we know category, there's a category that called delight, but we don't know how to. So the, the framework that I'm introducing and I'm calling it the delight framework is the framework that allows to first identify. So it's usually, represented into three steps. The first step is to start by identifying the emotional and functional motivators. So let me give you an example. I've been working at Spotify for about four years and as a Spotify user, imagine yourself, you are a Spotify user. You do have, of course, functional motivators. What could be the functional motivators? Listening to music, listening to podcasts, maybe listening to an audiobook. So all those are functional motivators. Now, what could be the emotional motivators as a Spotify user? It could be feeling less lonely. It could be feeling more productive because when you're working you need to listen to something. It could be about changing your mood. It could be about feeling connected. So all those are emotional motivators that drive users to use a product like Spotify. So what I encourage every product manager or every product team to do at first is to dig into identifying, of course, the functional need. And everyone is good, by the way, in identifying the functional needs. But also, while doing that exercise, pay attention to what could be the emotional motivators. So that's step number one is about listing the functional and the emotional motivators. Once you have those, Now we get to the second part of the framework, which is look at your backlog. And I guess you have a very busy backlog and take those features one by one and see for this particular feature, which motivator am I solving for among the functional ones and among the emotional ones as well. So the delight grid, for example, is a visualization tool that I came and created in order to allow product teams to visualize their backlog and see how many of my features are only solving for functional motivators. In that case, we call that category low delight. How many of my features are only solving for emotional motivators? These are very rare, but the best example I would call is, for example, I'm having an Apple watch and one month ago it was New Year Eve and at midnight I get fireworks popping out of my Brian Milner (10:35) Ha Nesrine (10:36) Apple watch and it was a happy new year there's nothing functional in there but it's all about creating some smile I call this surface delight and then how many of your features are solving for both functional and emotional motivators and I call this deep delight so maybe I deviated a bit from your question compared to canoe but it's actually about adding this dimension of connecting features to the real motivators of the users. Brian Milner (11:07) No, maybe a little bit, but you connected it to where we end up going anyway. So I think that's a great connection there. And by the way, for anyone listening, we'll link to all of this so that you can find this and follow up. But I like that differentiation between surface delight and deep delight. I know some of the examples that I've heard used kind of frequently in looking at Kano analysis and kind of trying to find those delighters. And that is kind of the area that it specifies there in Canoe, right? You're trying to find those things that are not expected, but when people find that they're there, they like that it's there, but they don't expect it's there. So if it's not there, there's no negative response that it's not there, but there's a positive response if it's there because they like seeing it. And my boss, Mike Cohn, tells this story about this Nesrine (11:59) Yes. Brian Milner (12:03) There's a hotel in California that became famous because at the pool, they have a phone that's by the pool that's the Popsicle Hotline. And you can pick up the phone and you can order a Popsicle to be brought to the pool. And it's the kind of thing where you're not going to go search for a hotel. Does this hotel have a Popsicle Hotline? I'm only going to stay at hotels with Popsicle Hotlines. It's not that kind of a normal feature. It's a delight feature because when you see it and you find out it's there, it's like, that's really cool. And it can be the kind of thing that says, yeah, I want to search that hotel out again next time I'm in this area because I really thought that was a nice little attention to detail and it was fun. But I think what I'm hearing from you is that might be more of what we would classify as a surface delight. It's not really meeting a deep need. Nesrine (12:35) Yes. Brian Milner (12:56) But it's fun, it's exciting, it's not expected, but it doesn't really cross that threshold into, but it also meets kind of functional delights. Is that kind of what you're saying there? Okay. Okay. Nesrine (13:08) Yes, actually I heard about that hotel story just to tell you how much viral it went. It came to me. So actually you get it correct that I consider that as surface delight and I have nothing against by the way, surface delight. You can add surface delight. The issue is you can end up doing only surface delight and that's not enough. So the idea is to do a combination and I do have two stories to share with you just to compliment on this hotel story. One is personal and one is professional. Brian Milner (13:21) Yeah. Okay. Nesrine (13:37) The personal one just happened to me a month ago. I went to Sweden and I went to Stockholm. That's where I worked for eight years. And I went there for business and I decided to meet some friends and some ex-colleagues. So we all gathered and went to a restaurant, a very nice restaurant in Sweden. And came the time where we had to say goodbye and to pay. And I guess you can feel it immediately when it's about paying and we are a large group and you start to get that anxiety about who's paying what and what did I order? What did I drink? What? I mean, I honestly hate that moment, especially in a large group where you don't necessarily have a lot of affinity with us. Like, should we split in 10? Should we pay each one paying its piece anyway? So that was a moment of frustration, of anxiety. Brian Milner (14:09) right. Yeah. Nesrine (14:28) And I loved how the restaurant solved it for it. You know how they solve for it? I mean, maybe it exists in the U.S., but for me, that's something I never seen before. The waiter came with a QR code on a piece of paper and you scan the QR code. And when you scan your QR code, you get the list of items that got purchased by the table. And all you have is to pick, and that happens automatically real time. Everyone is picking at the same time. You pick the things from the list and you pay. for the things that you order. You can even tip on the bottom. You can give feedback. Everything happened on that QR code. And you can guess how much that anxiety could be removed. So that's the personal story I wanted to share. The second story, which is more professional, I want to share how we try to improve experience at Google Chrome. So I've been the product manager at Google Chrome. Brian Milner (15:13) Yeah. Nesrine (15:25) And we started from the observation that people do have plenty of open tabs. I guess you are one of them, especially on mobile. Like on mobile, you go and check how many open tabs you do have on Chrome and you realize that they are have, we realized at least out of numbers, out of data that people do have plenty of open tabs. So it started as Brian Milner (15:32) You Nesrine (15:47) technical issue. Of course, the more tab you have, the heavier the app is, the slower the app could be, et cetera. So we wanted to reduce the number of unnecessary open tabs in Chrome. So we interviewed users and we started to check with them, why do they even leave their tabs open? So some of them leave tabs because they consider them as a reminder. I mean, if tab is open, it means that you need to finish a task there. Some people really leave tabs just for ignorance. mean, they moved from a tab to another and they completely forget about them. Actually, we realized that the fact of leaving tab open, the reason for leaving tab could be completely different from a person to another. And the other interesting observation, and when I say identify emotional motivators, you will realize that people feel a bit ashamed when they show to us that they do have plenty of open tabs. Some of them would say, sorry, I usually don't even have so many open tabs. It's only now. And I'm like, it's okay. But the point is, if you have this mindset of trying to track the emotional insight from your users, you will take note. And the note was anxiety, feeling ashamed, blah, blah, blah, blah, blah. And that was in introduction for in... Brian Milner (16:42) You Yeah, right. Nesrine (17:04) improving the tab management experience later on in Chrome. Brian Milner (17:07) That's actually a really good parallel, though. I think that's a good example because it reminds me, too, even going back, I remember one of the things, and I'm going way back here, but I remember one of the things about Gmail that was kind of a selling point initially was the concept there of you don't have to worry about maintaining an inbox. keep all your mails and search. And you can search through your mails and find whatever it is. And I remember prior to that, most people would use something like Outlook or something like that to have their mail, there was always this constant struggle of, I've got to keep it down. I've got to delete things. I've got to categorize things. And Google had this different approach of, don't worry about it. Just leave it. And that's a good, I think, example as well of kind of that emotional response of, Nesrine (17:48) Yes. Brian Milner (17:56) Gosh, I'm kind of anxious. I feel bad that my inbox is so big. And I know that's bad, but Google comes along and says, don't worry about it. You're not bad. It's OK. Yeah. Nesrine (18:05) Yeah, yeah. And by the way, I think Gmail is filled with plenty of deep delight features. One of them I can quickly highlight is, you know, when you send an email, we're saying attached file and the file is not there. And when you try to hit send, you get that pop up like a be careful or like a mind, there is no attached file inside. These are for me like very attached to the fact that You don't want to feel ashamed. You don't want to look stupid later on saying, Hey, sorry, I forgot the file. Here's the file. That's, that's a great example. And the other example that come to mind again in Gmail, you know, that smart compose when you're trying to answer an email and you can just hit tab, tab, tab to complete the sentence. I mean, the functional need is to write an email. The emotional need is to get it in a relaxed way. And the combination would allow for something like. Brian Milner (18:49) Yeah. Nesrine (19:00) Smart Compose. Brian Milner (19:01) That's awesome. Yeah, so I guess that leads to the question though, when we're talking about something like Spotify, mean, music intrinsically is emotional anyway, right? It's something that you have an emotional connection to and you feel a certain way when you hear music. But if my product is a, I don't know, expense reporting software, right? Nesrine (19:23) Mm-hmm. Brian Milner (19:25) I can just hear people out there kind of asking, know, and kind of thinking to themselves, yeah, but my product, right, my product is not that kind of, it doesn't elicit that kind of emotional response in people the same way music would. So does this apply to me as well? So how would you answer those people who feel like my products might be a little bit more bland or boring and don't really intrinsically have an emotional connection to them? Nesrine (19:47) Mm-hmm. So my answer is that if your product is boring, then it's even more priority now to focus on emotional connection. But let me elaborate. So that's one of the reflections that came to my mind while writing the book. So while writing the book, I wanted the book to be a storytelling book. So I was writing a lot of my stories, stories from Skype at the time, Spotify and all the Google product. But at some point I said, hey, hey, Nisreen, you need to get more insight from other people and other experiences. So I get to interview product leaders from completely different industries and completely different domain. I interviewed leaders from B2B like Atlassian or Intuit and so many other companies that I don't have so much insight from. I even interviewed people from hardware, like I interviewed someone from Dyson and I was, hey, what makes Dyson so emotionally attractive for me? Cause I love my Dyson vacuum cleaner. But let me get to your point because when I interviewed someone from Intuit, that person told me something super interesting. She told me that at some point she was working at a tool called Tsheet. And Tsheet is a tool that allows you to enter your time report. There is nothing more boring than that. I think I'm picking the one that you're looking for here because it's, it's as a user. The only reason I would use this tool is to report my time so I can get paid. Brian Milner (21:06) Hmm. Right. Yeah. Nesrine (21:19) There is nothing exciting, nothing emotional. And what I got out of that product leader who used to be the head of product at the time, she told me that they were completely aware about the fact that the product is not that attractive. And instead of living with that observation, they did all what they could do to make it even more attractive. So they added some fun. They made the messaging less aggressive and less about enter your time. report but rather into more playful and even the images are more playful. When you press the enter time report you get the congratulation and some confetti if needed. So they explicitly turned and that's a strategy. They turned that boring moment into something even more attractive and they had to do that otherwise the experience will keep on becoming more more boring and the perception of users toward the product will be even less, more and more gray, I would say. Brian Milner (22:22) Yeah, yeah, just that little dopamine kind of kick, right? Just that little bit of chemical reaction in your brain can make a huge difference. That's awesome. That's a great story and a great answer to that question. So I'm curious, we're talking about trying to find these things and trying to see, your matrix here, it thinks about the emotional motivators, the functional motivators, and trying to find those things that kind of cross both planes. Nesrine (22:24) Yep. Brian Milner (22:52) How do you verify at the end? Because if you're lining your features up and think, I think this solves this emotional thing. I think this solves this functional thing. Is there a way to follow up to ensure that it actually is doing that? How do you follow up to make sure it's really doing what you thought it would do? Nesrine (23:09) Yes, so let's imagine you did the exercise well, you filled in the delight grade and you observed that you do have plenty of low delights, which is most of the cases by the way. The very first thing I recommend is to see opportunities for moving or transforming these features into deep delight. And in the book, for example, I talk about the nine delighters. Nine delighters are ways that could be sometimes cheap even to introduce. in order to make those low delight features into more deep delight. This could be, for example, through personalization. We love when the features are personalized, and that's one of the reasons, for example, why Spotify is so successful, is through features like Discover Weekly or RAPT or these kinds of super personalization related features. It could be through seasonality. That's, for me, the cheapest and the most delightful feature you can or aspect of feature you can add to your product. So for example, when I worked at Google Meet, I've been working at the background replace features. So we have been, of course, introducing static image. We have been introducing video backgrounds as well. But from time to time, we always use seasonality to introduce what we call seasonal background. So when it's Easter, we introduce Easter background. When it's Christmas, we introduce Christmas background. Guess what? Even like for Olympic game, we introduce Olympic game background. When it's the Earth Day, we introduced Earth Day background. So there is always an opportunity to introduce some seasonality to the product. And guess what? We relate to those, especially if the product is global. We relate like last, when was it? Like last Wednesday. It was the new year, the Chinese new year. And I was checking when is exactly the exact date for the new year, the Chinese new day. And I put that and you know what happened in Chrome? It got these dragons and those like the celebration within the product, like within Chrome. These of course are surface delight, but you know what? Why not? You see? So there are some tools. Some of them are not that... Brian Milner (25:17) Right. Nesrine (25:22) expensive to introduce to the product. Some would require a bit more thoughtful and thought into it, but there are ways that I detail in the book in order to introduce more delight. And then if you want to validate through metrics, and I guess that's your question where it's heading to, then the good news, and that's something that I discovered recently because there's been a study that was conducted by McKinsey. And you know what they studied? They studied the impact of emotional connection on product adoption. So they actually studied over, I don't know how many industries die, like tourism, IT, energy, whatever. And they interviewed more than 100,000 users or whatever. So the conclusion that they found out of that very interesting study is that emotionally connected users will get you more twice as more revenue, twice as more referral, and twice as more retention compared to satisfied users. I'm not talking about the non-satisfied. So if you take two groups of users, those that you satisfy their needs and those that you go beyond and they are emotionally connected, those that are emotionally connected get you twice revenue, referral and retention. Brian Milner (26:19) Hmm. Nesrine (26:43) So this is just to highlight that for people who say, no, but this is the cherry on the top. This is just like the extra. It's not the extra, it's the way to stand out. I don't know any company that is standing out nowadays without investing into emotional connection, none. Brian Milner (26:54) Yeah. That's a really good point. Yeah, I mean, the example that comes to my mind when you talked about seasonality and other things like that, know, I love my, you know, they're not a sponsor, Oral-B toothbrush, you know, the electronic toothbrush, and you know, there's an app with it and it keeps track of, you know, did you get all the areas of your teeth and did you hold it there long enough and... One of the things I always love about it is when it gets to December, the opening screen when you open up the app starts having snowfall. It's kind of a funny little emotional response, but you look at that and you think, that's cool. Yeah, it is kind of that season where now it's time to get ready for Christmas and it's that special. It's only this month that it's going to be like that. It's going to go away at the end of the month. Nesrine (27:45) Yes. Brian Milner (27:49) feel little sad when it's gone, it's back to normal. But it's such a silly little thing. Does that make any difference in really brushing my teeth at all? Does it change how well I brush my Not really. It's just a fun little thing that when it pops up there. And think how little that took from someone to do that. It's a little animation that they just pop up on a loading screen. But that little tiny bit, think, again, maybe a little bit surface. Nesrine (28:10) Yes. Brian Milner (28:16) but it takes something that would have been routine. It takes something that would have been kind of boring otherwise, and it just added a little bit of fun to it, you know? And I think you're right, that emotional connection is really, really important in situations like that, yeah. Nesrine (28:21) Yes. Yes. Yes, yeah. And the thing that I'm very vocal about nowadays is the fact that this emotional connection is actually not a new topic. It's something that has been extremely popular among marketers. For example, if you think about the best marketing campaign, they are all very emotional. The most successful marketing campaign are. If you think about designers, there are plenty of resources about emotional design. There is a great book by Don Norman. It was called emotional design. Aaron Walter as well wrote something called Designing for Emotion. But you know, the problem is that among engineers and among product manager, we don't talk that much about that. And you know what happened when we are not informed about this topic? There is a gap between the language of marketers, designers, and the engineers and product manager. And that gap doesn't allow things to succeed. I'm trying to educate the engineers and the product world towards this well-known domain outside of the product in order to have this consistency and start making real impactful products. Brian Milner (29:40) Yeah, yeah, this is such a really deep topic and it just encourages me, think, even more to recommend the book there. It's not out yet, time of this recording it's not out, but it's going to be in May of 2025. That's when this book is coming out. And I know it's gonna have a lot of really good information in it. Again, the book is gonna be called Product Delight. by Nesrine Changuel, Dr. Nesrine Changuel. I should make sure I say that. But I really appreciate you coming on because this is fascinating stuff. And I think the product managers, the product owners that are listening here are going to find this really fascinating. So I appreciate you sharing your time and your insights with us, Nesrine. Nesrine (30:26) Thank you, it's my pleasure. I love talking about this topic. Brian Milner (30:29) Ha

Lead an Agile Team With Context and ControlYou can only get so far by attempting to manage the performance of people through control. It is far better to lead or manage people by defining the context of their work.I was fortunate to learn this lesson early on when I worked in...a fast food restaurant. My manager, Jim, trained me that each burger was to be dressed with: 2 leaves of lettuce2 tomatoes3 slices of onion3 picklesdefining the wildly important goal (WIG) the team is working towardhelping people deeply understand and empathize with usersguiding a team in defining its igniting purpose, an intrinsic motivation that inspires exceptional performanceunderstanding the strengths and weaknesses of competitive productsHe didn't drill this into my head. He didn't inspect my burgers. He didn't pop-quiz me.Instead, he explained the context, the reason why our burgers should be dressed exactly that way.He told me to imagine a customer who orders a burger with extra pickles and a cook who loves pickles and puts five on each burger by default. When asked for extra pickles, that cook puts on seven.That's too many for the customer who, on a return visit, asks for “light pickles.” That burger is made by a different cook who would normally put on three pickles and so puts just one on when asked for light pickles.My boss gave me a vision of hapless customers alternately ordering extra or light pickles and never getting what they want due to the preferences of the cooks.I remember the context he defined 40+ years later. How long would pimply-faced me have remembered these amounts if my boss had merely presented them as rules?My manager defined the context of my customer—a hungry person seeking consistency. And that was enough.Leading through context can involve of mix of things such as: Leading an agile team—whether as a manager, executive, Scrum Master, product owner, team lead or other leader—is different. It requires new skills.A self-organizing team resists rules and thrives on creativity and freedom. Leading such a team by providing context can also cause it to excel,How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Why a Spillover Habit Is So Harmful - Mike CohnWelcome to the second email in the spillover series. We're talking today about why habitual spillover—the phenomenon of unfinished work piling up and carrying forward sprint after sprint—is so harmful to teams.As a reminder, Last week, I explained why spillover happensThis week, I'll describe why habitual spillover is a problemNext week, I'll give you some ideas for how to break your team's rollover habitFinally, I'll talk about what to do with unfinished work when spillover happens Why is Habitual Spillover a Problem?As we talked about last week, teams will sometimes miss their sprint goal, especially when that team is ambitious and aiming high. And that's OK.But teams that develop a consistent pattern of overcommitting and then carrying work forward cause problems for themselves and for the organization as a whole.Teams That Deliver Routinely Are Predictably DependableThe main problem with habitual spillover is Lack of Predictability / Dependability.Every organization benefits from some level of predictability. I worked with a company once that was preparing for its IPO. Despite the tremendous pressure to meet revenue goals prior to going public, the CEO told me he'd happily trade some revenue for greater predictability. Being predictable is that important.Predictability shouldn't be the primary goal for an agile team, but it should be a goal.It's the same in sports. Basketball players strive to make every free throw. But a player who sinks the ball in the basket about 80% of the time is considered a high performer. That player can be reliably counted on to make most of their free throws.Baseball players also strive to get a hit every time they're at bat. And believe it or not, they are considered great, highly predictable hitters, if they manage a hit about 35% of the time—reflected in their .350 batting average.Like those sports players, agile teams are expected to try to deliver everything they think they can, every time. But realistically, if an agile team achieves its goal 60–80% of the time, they are providing a high level of predictability.Teams That Demonstrate Frequent Progress Are Happier & More CreativeA second, related reason your teams want to finish what they've started most of the time is a phenomenon called the power of small wins. In a 2011 study, Amabile and Kramer found that tangible, visible progress is a key factor in people's enjoyment of work, and by extension their level of creativity.It's almost impossible to get a true sense of progress on “mostly done” work because until it's fully done, you can't really gauge the amount of work remaining.This is known as the 90% syndrome. Software projects are 90% done for 90% of their schedule, and that's hard on everyone.When progress stalls and work rolls over, teams lose their sense of accomplishment from making measurable, demonstrable progress. (Want to know more? Read this blog and discover several reasons why it's so important for teams to get to done.)Teams that routinely fail to deliver on their goals lose trust with the organization and miss the sense of accomplishment that comes from finishing. That's why next week's tip will be things you can do to help break your team of the spillover habit so they can succeed with agile,How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

A key agile principle is the value of getting work done by the end of each iteration.Yet one of the biggest complaints I get from agile leaders is that teams never finish what they say they will during a sprint. Instead, teams consistently let the unfinished work spill over (AKA roll over or carry over) from sprint to sprint.Spillover is such a prevalent problem for agile teams that I want to devote several tips to talking about it.  First, I'll explain what spillover is and how to know if it's a problem Next, I'll describe why habitual spillover is so bad Third, I'll give you some ideas for how to break your team's rollover habit Finally, I'll talk about what to do with unfinished work when spillover happens. After all, while spillover shouldn't be a habit, every team will occasionally have unfinished work at the end of the sprint  Team members were too optimistic and brought too much into the iteration The team was interrupted more often during the sprint than expected Some of the work took longer than expected Externally: A boss or important stakeholder can exert pressure by telling a team what must be done or by establishing unrealistic expectations. Internally: Some teams allow their optimism and high expectations of themselves to create pressure to do more than is reasonable.What Is Spillover? Why Does It Happen?Spillover is when a team arrives at the end of one sprint with some unfinished work that needs to be finished in a later sprint. It happens when a team overcommits to what they can achieve during the iteration timebox. This is usually because: Spillover is not a bad thing in and of itself. It's unrealistic to expect a team to finish everything it starts, every sprint. In fact, it's normal and desirable for a team to occasionally aim a little high for what they can accomplish in a sprint, and come up short. When Does Spillover Become a Problem?Habitual spillover, though, is different. Habitual spillover is when a team almost always commits to more than they can finish in the sprint. These teams rarely finish what they think they will.As a result, the end of the sprint becomes an arbitrary date, and work is just carried over into the next sprint as if it's no big deal.It is a big deal. (I'll talk more about why it is a big deal in next week's tip).The most common reason teams develop a habit of taking on more work than they can finish is pressure. That pressure can originate:  One Thing to Do This SprintOne thing you can do right away to help stop habitual spillover is to make the problem visible.At the next sprint end, make a note of how many items the team committed to versus how many were 100% done. Even better: look back and do this for a handful of prior sprints.Bring this information to the retrospective and ask the team why they think unfinished work has become a pattern for them. Then ask them for one thing they could try next sprint to prevent it from happening.Don't forget to hold them accountable to trying that idea (whatever it is) during sprint planning and as the sprint progresses.While you're doing that, I'll be getting my next tip ready for you. Next week I'll be writing about why spillover is such a bad habit to fall into and how breaking that habit can help you succeed with agile.How to connect with AgileDad:- [website] ⁠⁠https://www.agiledad.com/⁠⁠- [instagram] ⁠⁠https://www.instagram.com/agile_coach/⁠⁠- [facebook] ⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠- [Linkedin] ⁠⁠https://www.linkedin.com/in/leehenson/

What’s next for Agile coaching? Brian Milner and Andreas Schliep dive into the shifting landscape of Agile coaching, the differences between Scrum Masters and Agile Coaches, and how to carve out a sustainable career in a changing industry. Overview In this episode of the Agile Mentors Podcast, Brian Milner and Andreas Schliep explore the evolving role of Agile coaching, the challenges coaches face in today’s market, and the skills needed to thrive in a shifting industry. They break down the differences between Scrum Masters and Agile Coaches, discuss how to develop a personal coaching style, and emphasize the importance of integrity and resilience. From navigating layoffs to redefining what it means to be an Agile leader, this conversation offers valuable insights for anyone looking to grow in their Agile career. References and resources mentioned in the show: Andreas Schliep Certified ScrumMaster® Training and Scrum Certification Certified Scrum Product Owner® Training Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Andreas Schliep is a Certified Scrum Trainer and executive partner at DasScrumTeam AG, helping organizations navigate complex projects with agile methodologies. A thought leader and co-author on Enterprise Scrum, he empowers teams—from startups to Fortune 500 companies—through high-impact coaching, training, and a passion for continuous learning. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We are back here for another episode of the Agile Mentors Podcast. I'm here as always, Brian Milner, and today I have someone we've been trying to get on here for a little bit, and I'm excited to have him here. Mr. Andreas Schliepp is with us. Andreas, thank you for being on. Andreas Schliep (00:17) Thank you for inviting me. Brian Milner (00:19) Yeah, very excited to have Andreas on here. Andreas has been in the community here for a long, time. He's been just really generous with his time and he's mentored a lot of people. He's a CST, a Scrum trainer. He's also a certified enterprise coach. So he has kind of those dual high level certifications with the Scrum Alliance. But he mentioned to me earlier, he's kind of always considered himself a Scrum trainer. But he's also a coach in this group called the Leadership Gift, or there's also another name here that they've used recently, Responsibility Immersion. So that might come to play in our conversation here because we wanted to talk about sort of the future of agile coaching and agile coaches in general. There's a lot of turmoil, there's a lot of upheaval and things that are shifting and changing every day in our profession. So I guess, you know, let's just dive into the topic here. Andreas, how do you see things currently? And, you know, in a broad sense, where do you see them going? Andreas Schliep (01:18) Yeah, so first of all, why am I concerned? So typically I say that I kind of, train coaches and I coach trainers. So most of my work is centered around the path of scrum masters and how they can kind of acquire the necessarily skills and insights to become actual coaches themselves. Or scrum coaches as I would prefer to say it. And that includes a lot of stuff like we want to equip them with facilitation, with training skills, with coaching skills, with systemic observations and other methods. And we've been doing that for a couple of years. And so of course we came across lots of good people, good coaches and good trainers, good consultants out there. And we kind of kept our community open. So it's not like people attend our classes and then we forget them or we only have closer relationships to our corporate customers. It's like we kind of managed to build some kind of little community. People keep coming back and we keep chatting about what's going on, what's happening in their environment. And as a mainly training focused company, one of the first effects that we notice is that our classes are getting emptier and emptier. So what's going on, especially advanced classes are not that well. So we still have some, well, yeah. basic attendance, but it's not as it used to be. well, a couple of years ago, we had like full classes and everything, and then COVID hit and we could say, okay, so COVID kind of reduced the demand for edutraining. And then the next crisis came and the next catastrophe and the next disaster. But there have also been some structural changes. I think that we are currently experiencing two effects that happen at the same time. So the one thing is that, well, Diana Larsen put it that way, Agile has won. So there's no doubt that organizations employ Agile methods and want to use Agile practices, some of them with, some of them without any clue about what that even means or what Agile thinking or Agile attitude behind it is, but still, there's no shortage on like the use of Agile or the, but there's also no shortage of the Agile basic training or educational videos, content or whatever. So people get lots of more resources than we used to get back then when we had like this one scrum book by Ken Schwabe. So read this and then you went out and said, how do I do that? So. And then came the second book by Mike Cohen and the third book and so on. had to, had all these puzzle pieces coming together where we needed to find our own way and build our proficiency. And now you get a flood of books and stuff going on, which is fine. So the one thing is that of course our profession is developing and it's kind of natural that you will notice some kind of within that. But there's another effect and this is one thing where we scrum trainers can kind of take responsibility for our own contribution. It's the fact that organizations can hire an unlimited number of low-level agile coaches nowadays. There's been no quality control. Anyone who went through a two-day CSM class could call themselves agile coaches and they got hired for lots of money and eventually produced nothing. some of them, some agile coaches or people who call themselves agile coaches even caused chaos. So, and the systems. that they were affecting started to kind of fix themselves and heal themselves from the Agile coaches by expelling those. So, and of course, maybe you have a third effect, which is sometimes it just doesn't work and you blame the Agile coaches. So if you just lay on your couch and you do nothing and your doctor tells you, you have to get moving, you have to get up and get moving and say, yeah, it's a bad doctor because... I still lie on my couch and my health is deteriorating and this doctor doesn't help me. He doesn't give me what I want. What do you want? Yeah, I want just, I would just want a pill that I can swallow that I'm healthy. It doesn't work that way. And then we had those people who were selling those pills, yeah, who were telling people, here we got a, we got a safe way that you can do this. All you need to do is implement this process, hire our consultants. Brian Milner (05:26) Yeah. Andreas Schliep (05:43) We kind of made all the thoughts and the heavy thinking ourselves beforehand and you just need to install it. Here's the roadmap, here's the process manual, here's the 300 page guide. Just do it this way. And this is also detrimental. now we have, I've been talking to many people, many great people, you've been laid off, who are looking for a new orientation. Brian Milner (06:05) Yeah, yeah, I agree. I mean, I think you laid that out really, really well because there's I think you're right. It's kind of a multi effect scenario. There's a lot of things affecting it. And I know I've had conversations with with friends and colleagues about this. And, you know, we've talked a lot about the I think more kind of the second thing that you're talking about, just that and It's sort of a chicken and egg thing because the industry has built up and spread agile concepts through offerings of usually two day classes. You and I both do those quite regularly. And I think we probably both would say that's a very valuable thing. to go through sort of that immersion kind of a couple of days to learn it and get a foundation in it. But there may have been sort of a misconception or it may have been sold incorrectly to say, now you're ready to lead an organization and transforming from zero to 60 in Agile. when you're not, right? I mean, you've got a good grounding. You're ready to begin learning with a team, but it's the first step. There's gotta be some sort of ongoing support system that when you come up against something that you don't really know how to handle, that you have someone to ask. You have somewhere to go to get help and get answers. Even the, you I work with Mike Cohn, I think he's a great trainer. But even a two day class with Mike Cohn, I don't think is gonna make anyone an expert that now you're ready to, you know, take on the huge challenge of cultural change within the organization, you know? Andreas Schliep (07:53) Yeah, yeah, it's like with anything agile, these classes are a starting point or a waypoint and not a designation. It's not the goal. So when I made my driving license, my driving instructor told me, and in Germany you have to spend lots of hours with your driving instructor. And my driving instructor told me gladly, now you can get to practice on your own. He was happy that he didn't have to co-practice with me any longer because I wasn't the best driver. So I actually aced the theory test, but the practical driving was a little more difficult and kind of probably was bad for the blood pressure of my driving instructor. yeah. And that way, but I never thought about this. So the idea was I get the permission or I get the next level to the next step. And the next step will be, I want to learn proper driving. And that's something that you need to do on your own. And with this understanding, we try to kind of provide a path for people to become better scrum masters and agile coaches by kind of revamping the CSP path, the scrum aligns and other things. A glorious project that also failed gloriously. I'm still not entirely sure why, but probably because the Scrum Alliance and many other people failed to understand the similarities between Agile Coach as a profession and the Scrum Master as a role. So they claimed that there were two different things. And I think that's also a structural issue in organizations. Brian Milner (09:16) Yeah. Andreas Schliep (09:25) that they see Scrum Masters and Edge of Coaches as different things. So the Scrum Masters work on the team level and they just know their Scrum and they facilitate the meetings and then they come up with nice cookies for the retrospective so that everybody on the team is happy. And occasionally they take one of the team members aside when they have some issues and help them go through that. That's totally fine, but the Edge of Coaches do the real stuff. release train engineers and the others, do the organizational thing and they don't bother with what's happening on the team level because they need to do the important things on the higher level. And with this attitude somehow fueled by some decisions by Scrum Alliance and other organizations like, yeah, in order to become a certified team coach or certified enterprise coach, you have to kind of prove that you're... had coached like 2000 hours or 2500 hours. But by the way, the scrum master worked. It doesn't count towards this coaching, which is totally ridiculous. So that means the misunderstanding of the role is a structural problem. Another structural problem is that the organizations that would need the most experienced scrum masters, they attract all the rookies. Brian Milner (10:16) you Andreas Schliep (10:34) because they don't even know what a good scrum master would cost like. They have those two day or even less day. I heard about a transformation at a large automobile builder in Germany. They had something like a half day class for scrum master training within the safe environment. And they wonder why they fail. They wonder why they're failing. Brian Milner (10:53) Ha Andreas Schliep (10:54) On the other hand, we have organizations, even here in Germany, they have great leadership and coaching concepts. So they develop the Scrum Masters. They have the finest Scrum Masters ever on such a high level that the teams actually don't need them because the teams also evolved by taking care and taking responsibility for themselves and paying attention to the work. So they're kind of over-coached. So like, I think it was at Rally 10 or 15 years ago. There was a period when the external rally coaches didn't get so many contracts. And so they went inside and coach all the software teams and rallies at Rally. And after three or four months, the software team said, please, please give us a timeout, give us a break. We over coach. It's just too much. We just want to do some work and maybe not get better for like a month or two before we, because it's Brian Milner (11:42) Yeah. Andreas Schliep (11:47) It's hard always to get better and even better and you're so excellent coaches, cut us some slack. So that's so, but this is the structure. So on the individual level, it's just the same as with any major shift in any kind of industry. If your current profession or your current job title doesn't fit any longer, focus on what you're good at and see that you Brian Milner (11:54) Yeah, yeah, yeah, right. Andreas Schliep (12:13) become excellent at that. So that's, it's an old formula. It's an old formula and it can be different things. So I know about some scrum trainers who go and went into software development again, because they said, actually, I'm passionate about software development. I can understand that. I have a developer background as well. So sometimes I'm not that unhappy about taking care of a website and other stuff. It's a nice distraction. But some are really great facilitators. But if they only go out with a label, agile coach, and do not let the facilitation skills and experience shine, then they might get a mis-hired. So we have great personal coaches in there. So people with various skill sets. And if you take a look at the agile coaching growth, we have Biomark, some of them others. Brian Milner (12:37) Right. Andreas Schliep (13:00) You see that it's a vast field. So you cannot expect anyone, maybe the two of us, but you cannot expect anyone to be, not even me, so anyone to be excellent in all these knowledge areas and to be such a light and catalyst in everything. So the idea is to find your own way how you can contribute best. and then collaborate with others in their fields. So for me, the most interesting areas in that field are training and facilitation. Because I think that's the main thing that agile coaches or scrum masters can shine in. Brian Milner (13:41) Yeah, I've always loved, know, Lisa Atkins has that kind of different aspects of a coaching stance. And one of the ones that she had there that I've always loved is the idea of having a signature presence. And I remember when I first kind of encountered that, was, when it kind of sunk in, it was a very freeing idea for me. Andreas Schliep (13:49) See you. Brian Milner (14:01) to, you know, kind of like you're describing there, there's so many different aspects that you could, you know, try to do and you could do well, but it's too much for any one person to do all of it. So that signature presence to me, one of the things that I really kind of took away from that was know what you're good at, right? I mean, there's something about you that you bring from your own personality and your history and and everything that's made you who you are that is unique. And when you can find what that is, then it's almost like prior to that recognition to me, I was almost even a little ashamed that that was where my strength was. And I felt like I had to make up on these other areas that I struggle with or I didn't do as well. But that concept to me, Andreas Schliep (14:47) Mm-hmm. Brian Milner (14:52) kind of help me see, no, there's something that's really unique about how you approach things. And if you recognize that, lean into it because nobody else can offer that, right? Nobody else brings that to the table because that's uniquely you. Andreas Schliep (15:06) Yeah. Yeah. I have to admit, well, we're both with Scrum Alliance and I've been with Scrum Alliance for more than 20 years now. But some of the biggest insights about Scrum and the role of Scrum Master were some things that I actually learned by looking through the Scrum.org certification parts. So just out of curiosity, I started digging into the... Professional Scrum Master Series by Scrum.psm1. Okay, PSM1 is a walking part, so that's no big deal. 50 minutes without preparation, A's are done. Okay, next thing, PSM2, was a little more chilling. Okay, there are some different concepts in the way they address Scrum. And I completely faded PSM3. So that's interesting. So I should have known that. And the point is that... Brian Milner (15:52) Huh. Yeah. Andreas Schliep (15:58) There are differences in the message and the Scrum Master and the Scrum.org framing of Scrum is far more of a leader. So they take far more responsibilities. They are much closer to a sports team coach actually, even taking care of the crew and even throwing people out of the team if necessary. Then the fluffy Scrum Master social worker thing. with no real responsibility always in the background that we appear to propagate sometimes that I even have propagated lots of times. And I see this in my own style as well. So I'm rather strong at the facilitation part and working from the side of the background of people. But sometimes I see, and I think that's a big challenge for many agile coaching scrummers out there. Brian Milner (16:32) Yeah. Andreas Schliep (16:48) When it comes to the situation where I should take the lead, I'm still reluctant when I say, okay, yeah, somehow I don't want to step under the feet of others. I want to give them room. I want to be in my facilitator stance because I love that stance and that's my personal brand or whatever. The calm way and listening to people and integrating all voices. But all of a sudden, I encounter situations where say, my voice first. So, yeah. So let's do it that way. this week, I kind of stopped the client workshop in the middle. I said, so yeah, what is that? here you booked me for the entire day, but I noticed that you're very upset about important stakeholders missing. Brian Milner (17:19) Yeah. Andreas Schliep (17:39) I also noticed that you don't see the point in reiterating some other concepts that I prepared. you could use these methods and then talk to your stakeholders, but you rather want me in this room with your stakeholders and have this discussion together. So let's just stop this now. And I offer you a gift. I will come back for another half of days. So we stop this half day. You can use your time for something else. I can use my time for something else. And then I come back, but only if you have your manager in here. So if you bring your boss, I will come for another half day and then we finish this and deal with these questions. And they were kind of impressed that I was offering them. But where's the point? I needed to change the mode. I couldn't stay and I think this is something Brian Milner (18:20) you Yeah. Andreas Schliep (18:29) which is another great opportunity for Scrum Masters or agricultural coaches to say, what if I stepped into this leadership role? Brian Milner (18:37) Yeah. Yeah, that's a great kind of approach to it. And I know we've had some similar things at Mountain Goat as well, where we've worked with some clients and you kind of show up and you start to get into the things. Or even sometimes in the kind of just pre-work calls where you're trying to arrange things and talk through what is it you want to get out of this. And you sort of get that feedback and understanding that this is really just checking a box, right? They wanna check the box that they did this, but really making the change. No, they really don't wanna make the change. They really don't wanna have to change what they do on a day-to-day basis. you kind of are, as a coach or a trainer, you kind of get to that decision point where you have to say, at what point do I call this out? At what point do I say, you know what? You're gonna waste your money. Right? mean, I can come and do this. I can take your check. I can go away, but it's not going to make any difference. And you're not ready for it yet. and, that's, that's always a really hard decision. When you get to that point, when you realize, you know what? It's not serving your needs for me to, move forward here. You know, it's, it's, you're not going to be happy with me. Andreas Schliep (19:48) Yeah. I think it's important to maintain the personal integrity. the whole point about resilience is that you kind of are able to change while you maintain your own identity. So the path that you are trying to. And this change can mean a lot of things. So if someone would tell me, you've got to stop with Scrum now because Scrum is now forbidden everywhere. I would kind of dig into the facilitation. So I joined the IAF, the International Association for Facilitators. I don't have a credential there yet, but this is something if I would go into more facilitation gigs, this would be very interesting for me. I also became a coach in the responsibility program with Christopher Avery. First of all, I think that was a nice addition to my training or to my work with leaders. But then I also discovered that this is kind of navigation aid for myself. So whenever I do something, I start with what do I want? So what do I want? How do I want the situation to evolve? What is the outcome that I want to achieve? And how am I blocking myself from that? So what is kind of my inner blocker that prevents me from getting what I want? Brian Milner (21:03) Yeah. Andreas Schliep (21:04) So I could also talk about external blockers, but these external blockers are sometimes just things on my path that I choose to say, okay, I can't go there because there's this blocker. And when I found these two things, so what do I really want and what is blocking me? I can go and make a decision. I can confront myself. And with this ability, I'm pretty sure that I'm able to respond to any kind of situation. So, and... whether I pursue the facilitator part further or whether I go into the coaching way. I love to work with groups so that just the one-on-one coaching is not so interesting for me. But these are kind of independent from what I'm doing now, but also based on what I'm doing now. So I can derive lots of good skills and insights and approaches from what I did as a scrum trainer so far, what I have done as a scrum trainer. Brian Milner (21:58) Yeah. Well, I think when I'm hearing and tell me if I'm misquoting this or saying it or misunderstanding, but it feels like there's sort of an element here that, you know, I think a lot of us sometimes, have some kind of a title that we've earned. and we, we sort of inherit from that, set of, activities or things that we feel empowered to do. based on that title. And what it sounds like I'm hearing from you is it should kind of be the reverse. You should think about what you do well and the titles may come and go. They may change the descriptors that people use to describe what you do, it might change, but what you love to do with the activity, what you're good at, that can shift and change a little bit and don't be so concerned with the title. Andreas Schliep (22:45) Yeah, so edge-hired coaches still can keep this kind of title for the tribe to identify a peer group. And I've also joined edge-hired coach camps even as a scrum trainer. because this identification is important to say, okay, I know a couple of people who have different skills or different things who are some more similar to me, but I don't think we should stick to Agile Coach as a job title and only look for Agile Coach offers. But rather go out and see what's out there, what opportunities do we see. Apply for weird stuff. So at the beginning of this year, I applied as a facilitator for United Nations volunteer program and even made an extra language proficiency exam before that because I had to kind of prove that I'm at least at level C1. for this job. I just did it because it was there because this opportunity came through the International Association for Facilitators. I just said, okay, I don't know. They didn't even throw me back. I don't have anything, but I just, I want to apply for this. I want to get this material together. I want to show that I'm potentially able to do this. I will be far too expensive with my current rate, but yeah. And I think anyone currently in the situation as an edge on coach being laid off or looking for another job should kind of step back and go through these steps. So what do I want? What are the activities that I'm really passionate about? Brian Milner (24:13) Yeah. Andreas Schliep (24:13) And the answer might be surprising. So sometimes, it's actually coding. Maybe we'll get back to the basics. Brian Milner (24:19) Yeah, yeah, you're right. I've known a lot of people or I've known several people, I guess I should say, that have kind of maybe migrated backwards. If you think of it in that way, I don't know that's backwards, but migrated to their roots a little bit more, you know, and maybe left training, but went back to doing, you know, managing software teams or even coding just because they enjoy it. And I think that's a great thing if that's... Andreas Schliep (24:41) Yeah. Brian Milner (24:45) brings them happiness, you know? Andreas Schliep (24:47) Yeah, you know, when the whole agile thing started, they came up with a little website and the website says something like, we're discovering better ways to sort fire customers or so. I don't have a probably and helping others to do it. And if even if you go back or if you go to actually start working as a developer again. You still bring the edge of spirit and you still bring the ideas and methods of collaboration. It's going to be so helpful in your environment. Especially with new technologies, AI stuff and remote work and all these things kicking in. Everything looks like it's making your work more difficult. Massive layers like even media firing developers now, not only edge of coaches. So we have... so many disruptions to deal with. And I think that, well, kind of resilient HR coaching tribe stance is helpful in whatever role you fulfill afterwards. Brian Milner (25:43) That's really good. Yeah. Well, this has been great. I really enjoyed the conversation. Sometimes you're not really quite sure where we're going to end up and where we're going to travel, but I've really enjoyed all the directions we've taken here, Andreas. So I can't thank you enough. Thank you for making time and coming on and sharing your experience and wisdom with everyone. Andreas Schliep (26:00) Mm-hmm. Yeah, was great fun and thanks for the opportunity and I hope that this will help some people find little more guidance, least a little more confidence if they don't find guidance yet. Brian Milner (26:13) Yeah, I agree. Thank you very much. Andreas Schliep (26:15) Thank you.

3 Ways To Help Your Team Succeed In 2025 - Mike Cohn Join us as we discuss these three amazing techniques and how they can impact your teams. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Is workplace stress just about long hours? Not quite. Brian and Marcus Lagré unpack the real equation behind stress—how pressure, complexity, and security interact—and why your team’s performance depends on getting the balance right. Overview In this episode of the Agile Mentors Podcast, Brian Milner sits down with Marcus Lagré, product organization coach and author of The Stress Equation, to break down the science of workplace stress. They explore the differences between mental and emotional stress, how pressure and complexity impact teams, and why security in the workplace is a game-changer for performance. Marcus shares research-backed insights on interruptions, stress contagion, and how leaders can create an environment where teams thrive without burning out. References and resources mentioned in the show: Marcus Lagré The Stress Equation by Marcus Lagré Certified ScrumMaster® Training and Scrum Certification Mountain Goat Software Certified Scrum and Agile Training Schedule Subscribe to the Agile Mentors Podcast Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Marcus Lagré is an author, speaker, and consultant with 20 years of experience in software development, from small-team Scrum to massive 50+ team LeSS transformations. Creator of The Stress Equation, he helps organizations tackle workplace stress systematically, ensuring teams thrive under pressure without burning out. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm here as I usually am, Brian Milner. And today we have with us a really special guest, Marcus LeGray is with us. Welcome in, Marcus. Marcus Lagre (00:13) Thanks, Brian, pleasure to be here. Brian Milner (00:15) We were saying before that I'm actually kind of butchering or Americanizing his last name. Marcus Lagre (00:20) Nah, Americanizing, yes, but butchering, no. I wouldn't say that. Brian Milner (00:24) So I'm gonna give you a chance to set the record straight. Why don't you tell us the actually the correct pronunciation? Because I probably can't do it. Marcus Lagre (00:31) Well, my... I would say La Gré, but that's with a Swedish southern accent and not even most Swedes do that, so... Brian Milner (00:34) Okay. OK. Do the Swedish people look on people in the South like we do here in America? Like they're kind of more laid back and slower and... That's funny. OK. Well, we have Marcus on because, first of all, Marcus is a product organization coach. He's an author. He's a speaker. Marcus Lagre (00:48) Yeah, yeah, I would I would say so I would I would say so yeah Brian Milner (01:03) And he has a really great book that we wanted to kind of dive into the topic of here. Because in this day and age, this is a really important topic, but his book is called The Stress Equation. So you can kind of see where we might be going there with that. Well, so let's dive in. Let's talk about that a little bit. And I think probably a good place to start would be, how would you define then stress, when you, if we're talking about stress and the stress equation, how do you define stress? Marcus Lagre (01:30) I usually use the definition of stress because I let's start like this. I think that most people have like a too narrow perspective of what stress is. Like most people probably see it as working long hours and you know, spending a lot of time at work, but it doesn't necessarily have to. And there's this definition of stress from the Oxford English Dictionary that I found really well that stress is the result of, of, of, emotional or mental strain due to adverse or demanding circumstances. So yeah, so there's differences there. And I think that most people, if you're not in a very toxic environment, you don't suffer from emotional stress a lot at work, but mental strain is probably what we're looking at most often. Brian Milner (02:04) Yeah. Okay. Yeah, I mean, I, you know, I wouldn't discount that entirely. I think that there's probably a lot of people out there that have the emotional strain of a bad boss or manager or something like that, right? But yeah, hopefully, you know, hopefully you're right that the majority might not be, you know, dealing with that. It might be more of the mental side of this. So what is mental stress then? What is a mental strain? Marcus Lagre (02:38) Well, mental strain is usually diversified by saying like emotional strain is like the stress from being like in a toxic environment, for example, which is more common than it should be. But mental strain is more of the when you have too much of a mental load, like you're trying to solve a complex problem, like you have high cognitive load in order to solve it, or you need to Brian Milner (02:48) Hmm. Marcus Lagre (03:03) Well, it's also related to cognitive load that you have a lot of context switching. So you need to change information in your working memory quite often and a lot. And that can lead to mental strain. And the problem with mental strain, as I see it in white collar worker or knowledge workers, is that most of us are, we like mental challenges. We like puzzles, we like solving problems. So we're not great at identifying when a mental challenge becomes a mental strain for us. We're used to just pushing on. we try to just, you know, it's just something that I haven't figured out yet. If I push myself just a little harder, I'll crack it. Yeah. Brian Milner (03:42) Yeah. Yeah, that's great. Yeah, I mean, I think you're right. We do like puzzles. We do like challenges. I I know one of the popular things here in the US is the escape room kind of thing. I don't know if you guys have that there as well, but we actually pay people in our free time to give us puzzles and challenges that for fun, we'll go and put ourselves under some mental duress and try to figure out. So I think you're right. there is part of us that really wants to do that. Well, if that's true, then the other side of that is, shouldn't we all be under some kind of mental stress then, since work is challenging and complex and hopefully. Marcus Lagre (04:20) Well, yeah, I mean, not all stress is bad. So I usually say that the stress that we feel at work usually comes from two different sources. So this is the equation. Like the mental strain comes from the complexity that we need to, now that we need to handle. Either the complexity of the problem that we need to solve, or if we're working in, the complexity could also be like the frustration of working in an inefficient organization. That could be part of the complexity. Brian Milner (04:23) Yeah. Marcus Lagre (04:46) So I usually say that pressure is our sense of urgency. The pressure comes from our sense of urgency in order to finish the work that we're, the task that we have at hand or whatever it is that we're trying to solve. And the complexity is whatever makes it harder for us to actually finish that work. So to relate back to what you were saying, shouldn't we be under some kind of stress? Yes, we should. If we don't have any sense of urgency, we're probably not delivering at all. And if there's zero complexity in what we're doing, That should probably be an automated task long ago. We will probably suffer from severe boredom if there's zero complexity in what we're doing. Brian Milner (05:25) Yeah, I always, you know, this comes up sometimes in classes where, I think, you know, I want to find those people who are under zero pressure at work, because I've never been in that situation. I've never had any kind of boss or organization that was like, just take as long as you need. It doesn't matter. There's always some pressure and some places it's more than others and some places it's extreme. But yeah, I think you're right. There's a right amount of pressure. that can be applied. Marcus Lagre (05:48) And there's also constructive stress. I usually diversify like constructive stress is when you try to achieve something because if you're under a lot of pressure solving something very complex, there's also pleasure in actually solving it. So there's some kind of release in the end. But if you're constantly under a lot of pressure or... Brian Milner (05:51) Hmm. Marcus Lagre (06:09) I usually say that the pressure usually comes from things like how we set deadlines, how we handle our backlog. So if you have two short deadlines, then you're under negative stress or unconstructive stress, or we have an ever-expanding backlog. We can never finish everything in this backlog. have no way of saying no to things. They just keep piling on. That's unconstructive stress, but... Brian Milner (06:30) Yeah. Marcus Lagre (06:34) A sense of urgency to reach like a goal? That's more of positive kind of stress. Brian Milner (06:39) Yeah. Yeah. I I've heard, my boss, Mike Cohn talk about before how scrum has just the right amount of pressure that it's, it's not, you know, it's, it's not the kind of, when we think about commitment and stuff inside of a sprint, it's not the kind of thing of, you're going to lose your job if you don't make this sprint commitment. But it is kind of, you know, my, my word is on the line. My name is on the line. And if I don't deliver. I'm letting down my team, I'm letting down those around me. So that's way he describes it. It's kind of just the right amount of pressure that's kind of baked into the way Scrum works. I've always liked that. I've always thought that's kind of a good take on that. So we're kind of in these pressure cookers a little bit, right? We've got pressure and sometimes more than others and we do need some kind of pressure. So we have some sense of urgency in what we're doing. How does this align with our Agile Manifesto kind of ideal of working at a sustainable pace? Is the pressure going to crack us under trying to keep a sustainable pace? And what if we don't have any say over the amount of pressure we have? Marcus Lagre (07:46) Well, if you don't have any say, then I usually say that the pressure isn't a force of nature, that it usually stems from someone's decisions. And if we don't have a say in it, then we can't influence that pressure really as a team maybe. But from a leadership perspective, if you put unlimited pressure on the team, you're gonna see decreasing results anyway. It's not... constructive, you're going to burn your people, you're going to lose, worst case, lose them from the company, either because they change jobs or because they burn out and they have to go on sick leave. So and that's going to cost you in the end. But also that you're going to see either a lot more well, as I said, either a lot of people leaving or people doing quite quitting. That's that's what's going to be because once caring about your own performance becomes dangerous, people are gonna put in the bare minimum. That's the people you're gonna keep. Brian Milner (08:41) Yeah. Yeah. I'm sure there's lots of research baked into this and you've probably crossed a lot of different studies and things that have kind of jumped out at you. And to me, that's always one of the things that's the most interesting when I dive into a topic like this and go really, you know, kind of knee deep into it. what, was there any kind of research that you stumbled upon as you were preparing for this or, you know, creating this book? that really kind of surprised you or that you found extremely interesting? Any studies out there around the effects of stress that kind of shocked you even maybe? Marcus Lagre (09:18) I wouldn't say shocked, but one thing that surprised me was that there was this study that showed, because I talk in the book about complexity, and I mentioned earlier that if you need to change the information in your working memory a lot, that leads to mental strain. But there were actually studies that showed that interruptions in work does not lower the quality of the work. It does, however, increase the sense of stress. But it doesn't necessarily lower the quality of work, which was something that I was absolutely convinced it would. However, there was a correlation between how far if you got interrupted, if it was on topic, so to speak, so that you didn't have to throw everything out of your working memory, then the quality level was still on par with what you would have seen if you weren't interrupted. However, Brian Milner (09:48) Yeah. Marcus Lagre (10:06) if it was something that was diametrically different to what you were actually doing, then yes, the quality would also drop. But I actually thought there would be like a clear correlation between interruptions and lower quality of work. And it wasn't. Brian Milner (10:20) Yeah. So it's not, I mean, what I'm hearing is it's not necessarily the interruption itself. It's the content of the interruption. And if the interruption is, you know, taking you wildly off track from your thought process, that's higher stress kind of a reaction to it. And that leads to more problems. But if it's, if it's an interruption that's near in the same area of what it is you're working on and thinking about, then it's not as hard to get back to it. Less stress, less, let's kind of end result effect, right? Marcus Lagre (10:52) Yeah, there's less mental strain in that scenario. However, you do often feel like you're less efficient, that you get less joy out of what you're doing if you get constantly interrupted, and that the workload is heavier than it actually is. So there's negative sides to getting interrupted a lot, but as long as it's sort of on topic, as you say, it's not really that harmful. Brian Milner (10:54) Okay. Yeah. Well, I know you do a lot of work with organizations and with leaders and organizations. And I know one of the difficult things, difficult kind of parts of having these conversations with leadership is trying to help them to understand the importance and kind of the impact and why this is important in a business sense to them. Not just that, you know, the way I phrase it in classes, it's not just that it makes you a better person, right? which there's value in that. not negating that being a good person is bad. I'm just saying from a business sense, oftentimes leaders want more than just saying, yeah, I'm a better human by doing that, but is it better for the business? So how do you have that conversation with leaders, with organizations to say, this is actually an important thing to focus on. This makes an impact on your business. Marcus Lagre (12:07) usually the challenge is to get leaders to understand that they are also affected by this. Because a lot of the challenges I see in organizations is that I come in and I usually do like an analysis of the organizations, ask around, do interviews and analyze everything. And what I come up with is rarely news to the leadership. They have seen the same thing. The problem is that they never had the time to just sit down and figure things out because they're constantly rushing between meetings. They're constantly rushing to do various budgets, updates, stuff like this, just keeping the mill going. So I usually say that they're too operationally occupied to take a look at the strategic goals and the strategic direction that they need to be going in for the business to run smoothly over a period of time. And so I usually tell them that the most important thing that you can get yourself is like an hour, at least every week that you just sit on your rear end and just contemplate things. I usually use a different word than rear end when I tell them this, just to drive the point home. But yeah, they need to find time. where they can just like no phone, no computer, just sit down for an hour and let whatever enters your head, enter your head because otherwise you will never figure this out. And you don't have to pay people like me premium to come in and tell you things that you are actually clever enough to figure out yourself. Brian Milner (13:41) Right, right. Yeah, so that's so interesting. So it's hard to convince them that stress plays a big impact on their work. I hadn't really thought of it from that perspective, but that's a great point to make. If you can help them understand the impact it has on their work, maybe it's an easier conversation than to say the impact it has on your teams or on your employees' work. Yeah. Marcus Lagre (14:06) I have never, mean, stress is contagious and it ripples down. If you have a really stressed out management, you're gonna have stress in the rest of the organization as well, like on the floor and in your teams. That's just a given, I would say. Brian Milner (14:11) Yeah. Yeah. All right. Well, so I'm following along. I think this is good. So we're talking about how you kind of explain this a little bit more to leaders and help them understand the impact. What about when you get one of those leaders who's just, and I know I've had these before where they're kind of more old school and they look at things and think, you know, you... Well, on your graph of pressure, right? They're much more leaning towards the higher pressure side to place on employees because they take that attitude of, you know, the old phrase that we all hate, work expands to fill the time allowed or whatever that thing is, right? How do you convince that person that, you know, there's an okay amount, but you're kind of really skewing it to the high end and this is now going to have an adverse effect? Marcus Lagre (15:00) yeah, yeah, Brian Milner (15:12) on what you're ultimately trying to do. Marcus Lagre (15:14) My usual angle of attack is to address the complexity of the part of the equation. I probably can't get them to understand or accept that they're applying too much pressure, but what they're actually trying to achieve is to get more output. I mean, that's the goal of their actions. And so I try to get them to understand the complexity that their teams are working under and try to get them to understand that you need to reduce this in order to free up more time and mental bandwidth for output. And that's usually a better way forward than trying to get them to accept that you only get so far with a whip. Once you've whipped one time too many, people are going to just stop caring. Brian Milner (16:02) Yeah. Yeah, you can't come back and use that tool over and over again. It's going to have kind of the opposite effect that you're hoping it will have eventually, right? Marcus Lagre (16:14) People are going to start telling you about problems, for example, because these people are usually the same people who don't want to hear about problems. Don't tell me about problems, tell me your solutions kind of attitude. And I usually get them to understand that you have absolutely no idea what the problems of this organization is, because people are afraid to tell you. Brian Milner (16:22) Yeah. Right. Yeah, that's such a huge point, I think, for leaders to kind of soak in and understand. If you have that culture, if you are generating that culture of fear in the organization of, don't come to me with problems, only come to me with solutions, then you're right. You're absolutely right. You're closing yourself off. And you're kind of establishing the norm that if there is an issue, The last thing to do is to raise it, to let people know about it, live with it, right? Just kind of exist with a status quo. If there's a problem, then you just have to learn to live with the problem. Marcus Lagre (17:09) Live with the problem or game the system so the problem isn't apparent. Brian Milner (17:13) Right, right. So back to the equation then. So your equation here, pressure times complexity over security. I don't know what we've talked much about security so far. So how does that come into play when you calculate this kind of pressure equation, stress equation? Marcus Lagre (17:25) Bye! Yeah, well, we kind of touched on it now, like with leaders who act in a way that lowers the security or the sense of security. So I define security as the freedom from fear at work. And psychological safety is one part of that. But it's also that you feel that you have... I'm sort of reluctant to use the words servant leadership anymore because there's sort of... sort of become a tainted word in some ways. People see it as a passive leadership style, which is not really, I don't quite agree with that, but security is in essence that you are able to take high pressure and high complexity if you feel that you have the management in your back, that you're taking it on as a team, that you're not alone with all of that pressure and all of that complexity, but you have people around you who you can rely on and ask for help. If you have that, then your security is higher and then you can take more pressure, you can take more complexity without burning out. Brian Milner (18:32) Yeah, yeah, that makes complete sense because if I have the kind of that sense of security that I'm not at risk, I don't feel like I'm being put in a position to fail so that I'm now in danger, but I've been given difficult problems because I have been trusted to conquer them. I've been trusted and empowered to kind of overcome them. That's such a different approach and mindset from an employee standpoint than, my gosh, I got to do this or I'm going to get fired. Marcus Lagre (19:05) Exactly, there's probably, management has probably let me know that we understand, we're handing you like a really tough thing to solve. if you need anything, if you need any resources, if you need any extra help, just ask us for it and we'll solve it. And in that situation, you're a lot more likely to... be able to get into that without burning out simply because you know that I have the management backing me up. Brian Milner (19:37) if I'm one of those employees who's under a high pressure environment, and I don't really feel like I have the power or authority to make that change, what can I do about it? Marcus Lagre (19:50) I mean, the thing that you can do is to change what I usually, one of the reasons why I wrote this book is that stress is one of the leading causes of mental illness and sick leave in our line of work, which is software. So if something is the leading cause of a problem, it's probably systemic, it's not individual. So one of the most important thing, that you can do is to identify what in the system is causing the stress in me, because ultimately stress is a subjective feeling. it manifests itself in people, but you can get the tools to identify what in the system is causing the stress in me. that can be quite a relief to not put that... I mean, put additional pressure on yourself by thinking that you're the one who's bad at your job or you're the one who don't have the correct coping mechanisms for the situation. The situation might actually be insane. Brian Milner (20:51) Yeah. Yeah, it's that subjective nature, I think, that is kind of a variable that I would throw into this equation. It's sort of like, I know one of the things I found really fascinating in kind of the earlier history of Agile and the idea of a sustainable pace was originally there was kind of talk about saying, using words like, no one should work more than 40 hours a week. But then that got changed to sustainable pace because of the realization that for some people 40 hours was too much and for other people 40 hours was not enough. And so that idea of sustainable pace was, it's individual, it's different to different people and that's part of what we got to do is know ourselves enough to know, hey, I'm kind of slipping beyond that point where I can sustain this indefinitely. Marcus Lagre (21:37) Yeah, and I think that's one of the myths that I want to bust a little bit is that, you know, it's not about 40 hours. It's not about the hours. I mean, there are some people who can work 60, 80 hours without burning out. So it's not the hours. It's something else. You know, so it's the end of the... Maybe it's the pressure that we have too much pressure. Maybe it's that we have too high complexity in combination with pressure. Maybe it's that we are in a toxic environment. So it's like how much mental energy do I need to handle the context that I'm in? That's. Brian Milner (22:13) It's almost like there needs to be kind of this balance between those three things that you've got to, one thing might go a little higher, but the others then have to drop a little bit so that it kind of equals out, right? Marcus Lagre (22:22) Yeah. That's what I, like, I always say that if you want to put high pressure on your teams, on your organization, you have to reduce the complexity because you can't do both at the same time. Those are the two variables that increases the stress. But then as we mentioned, like feeling of security is the lowering factor. So you always do well working with Brian Milner (22:38) Yeah. Marcus Lagre (22:46) the sense of security within your teams and working with your culture and making sure that toxic behavior is simply not acceptable in this organization, for example. And so that's always, you always get a reduced level of stress from that kind of work. But as I said, if you have high complexity and you put too high pressure on something, it's gonna break sooner or later. You're either gonna break your people or you're gonna break your product. because you're going to reduce the quality of the work because you have to stress through everything. And quite frankly, I don't care about your product. You're free to break it if you want to, but breaking people, that's just not okay. Brian Milner (23:18) Ha ha. Yeah, now we're back to being a good human, right? mean, these are humans. They're not AI programs, at least not yet. And they have lives. the more that you, like you're talking about, the more that you increase that pressure on them or decrease their sense of security, the less complexity they can handle. And you know, You have diminishing returns on your employees, on their productivity. Marcus Lagre (23:48) It is unsound business. Brian Milner (23:50) Yeah, yeah, absolutely. Well, this is fascinating. I really appreciate you coming on and talking about this. Again, for anyone listening, if this topic is interesting to you, highly recommend you check out the book, The Stress Equation by Marcus Le Gray, even though that's not actually the way to say the name. it's L-A-G-R-E, just so everyone knows. I don't want you to struggle searching for it if you're looking for it. We will put the links to it in the show notes for this episode so that you don't miss out if you're trying to contact Marcus or you want to know more about the book. We'll make sure you find a way to do it. So Marcus, I really appreciate you coming on. This has been a fascinating topic and I appreciate you sharing your wisdom, your research and your knowledge on this with us. Marcus Lagre (24:31) The pleasure was all mine, Brian.

What to Do When Scrum Meetings Go Wrong - Mike Cohn I hate getting stuck in traffic. I grew up in Los Angeles and lived in New York, so I should probably be used to it. I'm not.As frustrating as I find traffic, I've never gotten angry at the lines on the highway.The lines on the highway are there to help me and the other drivers go faster than we could without them. They tell us which direction we can go, where to position our cars, when it's safe to change lanes or turn, and more.The meetings of Scrum are like those lines on the road—there to help us go fast. All too often, though, Scrum can feel bloated because teams allow the meetings to take too long.A good way to prevent this is by keeping each meeting focused on its purpose. One meeting that often seems to stray from its purpose is sprint planning. Let's look at some ways you can keep that meeting moving in the right direction, starting with a refresher on the purpose.Purpose of sprint planning: To establish the sprint goal and choose the relevant product backlog items the team will tackle.As part of choosing the product backlog items for a sprint, team members typically discuss the tasks required to complete the product backlog item. Often these tasks are given estimates (in terms of hours). The result is captured in the sprint backlog.When things go wrong: While these discussions are helpful, they should last only long enough to help choose the appropriate work. If, on the other hand, team members get hung up in lengthy debates over which approach to use or how long each task will take, the meeting can quickly get out of hand.How to fix it: To bring the team back to the purpose of the meeting, remind them that you only have to decide if the item will fit in the sprint, not agree completely on how to approach it, or precisely how much time each task will take.Remind them that you can discuss implementation details at the beginning of the sprint. Offer to set up time with the relevant team members after sprint planning to dive into implementation specifics.For more on what to do when teams complain that Scrum has too many meetings, check out the blog "Do Scrum Teams Meet Too Much."Scrum Meetings Shouldn't Be a BurdenThe meetings of Scrum should not be a burden. Rather they are like the lines on a highway: there to help a team move more quickly. If it feels like the meetings are slowing your team down, try making the changes I've described.Shortening meetings while still achieving the purpose of each will help you succeed with agile. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Is Your Agile Training Worth The Money? - Mike Cohn Providing agile training to teams is an investment. With any investment, it is wise to assess the return you can expect. So let me ask you:How much value did your last team training deliver? What benefits did you receive? What tangible improvements did your team realize?If you can't answer these questions, you shouldn't spend another dime on training until you establish a set of metrics you want to see change after the training. What metrics am I talking about specifically?You can expect many proven benefits from training. I tend to focus on three.  Well-trained agile teams realize productivity gains of at least 30-50% Most teams see faster time to value just from switching to an agile way of working. Well-trained teams should move 5–10x faster Organizations can expect well-trained and well-structured agile teams to be around 40% more predictable (See the blog “Do the Proven Benefits of Agile Training Justify the Costs” for the data behind these claims)In addition to these three, you might want to consider other benefits as well: improved innovation, higher user and stakeholder satisfaction, and better quality products.Before your next team training, get a baseline of where your teams stand now in terms of these metrics. Then, measure how much they improve in the three months after training.Proving ROI is important both for your own peace of mind in knowing whether the training was effective, and also to help justify future investments in training. Let me help you do just that.We've created a free Agile Training ROI calculator you can use to help you think through the value you can expect from training. I've included instructions and an example to help you get the most from it. Take a look and see what you think.Investing in the right training for your teams, and measuring the improvements you receive, will help you succeed with agile. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

This episode was inspired by an email I received from Mike Cohn. It is my turn to challenge you.. "Hi, I'm Joel, and I'll be your server tonight.”I was out to dinner last week, and that was how the waiter introduced himself. Actually, he wasn't our waiter. As he'd said, he was to be our server.A small distinction perhaps, but as a writer I think words are important. The difference here struck me for some reason that night.Throughout the meal, Joel did serve us. He had help with things like carrying plates from the kitchen and filling the wine and water glasses. But he was clearly interested in serving.He recommended wines, subtly steered us away from some menu choices (“I prefer our fish dishes”), encouraged splitting one of the salads but ordering two appetizer choices, and did everything he could to ensure we had a great meal.As the year winds down and I think about the emails I'll send you next year, the YouTube videos I'll create, the blog posts I'll write, and the new courses I'll create, I want to make sure I am serving you.  What topics would you most like to hear from me about next year? Are there specific questions you'd like addressed? Please comment below and let me know. I can't bring you an appetizer or recommend a good Pinot to pair with your next retrospective, but I can promise to address topics that will help you succeed with agile. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Missed some episodes this year? Don’t worry—Brian’s got you covered with a highlight reel of 2024’s most memorable moments, featuring game-changing insights from Agile thought leaders and innovators. Tune in to catch up, reflect, and set your sights on a stellar 2025! Overview In this special year-end episode of the Agile Mentors Podcast, Brian takes us on a trip down memory lane, sharing highlights from some of the most impactful conversations of the year. Featuring insights from Agile legends like Mike Cohn, Clinton Keith, Heather McGowan, and more, this curated selection is packed with golden nuggets that you can revisit or discover for the first time. Whether you missed an episode or want to relive the best moments, this recap is a perfect way to close out 2024 and prepare for what’s ahead. References and resources mentioned in the show: #79 Navigating Agile Trends and Challenges in 2024 with Lance Dacy #86 Revisiting User Stories with Mike Cohn #90 Mastering Agile Coaching with Cherie Silas #93 The Rise of Human Skills and Agile Acumen with Evan Leybourn #100 Navigating the Future of Agile and Scrum with Lance Dacy & Scott Dunn #111 Adapting to the Future of Work with Heather McGowan #120 Agile in Gaming with Clinton Keith #123 Unlocking Team Intelligence with Linda Rising Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Auto-generated Transcript: Brian Milner (00:00.622) I'm Brian Milner and this is the Agile Mentors Podcast, a show about both the personal and organizational journey towards agility. My friends and I will be sharing with you what we've collectively learned from seeing thousands of companies Agile implementations, apparels and pitfalls, as well as the secrets to success. We'll share our personal in the trenches experiences so that you can apply what we've learned in a practical way in your careers. We also hope to hear and learn from you as well. If you're like us and are always in search of better ways of working together, you're in the right place. Join us, mentor, and be mentored. Let's get started. Brian Milner (00:53.288) Welcome in Agile Mentors. We are back for the final episode of 2024. Believe it or not, we have reached all the way to the end. You might be thinking, wait, there's a few more weeks left. Yeah, there's a few more weeks left, but the next release date would have been on Christmas Day itself and the one following would have been on New Year's Day. So we're gonna take two weeks off to be with our families after this episode. And we encourage you to enjoy that time, take the time with your family as well and friends, and truly wish you the best over that time period. But before we get there, we do have one more episode for you. We thought what we'd do for today's episode might be tiny bit different than normal. In fact, I don't think we've done anything like this before. What I wanted to do is, since it is the last episode of the year, is to look back over the past year and play you some portions of some of the really fantastic discussions that we had over this past year. Just pull out a handful of these to talk to you about. If they sound interesting to you, maybe you can go back and take a listen to those episodes. So let's get right into it, because I don't want to waste time setting it up any more than that. For starters, I want to go back to something that's now kind of a tradition for us, and the next one you'll hear from us after this episode will be the continuation of that. The beginning of this year in 2024, we started things off and we kicked it off with friend of the show, Lance Dacey. And that episode was really about looking forward into 2024. And for us to talk about what we maybe thought was coming and what we saw in the future, and then trying to somehow make some predictions or give some advice about how we might be better prepared for it. And one of the areas that came out in that discussion was really talking about how leadership affected an Agile transformation and Agile with the culture of an organization. So I'll play you a little clip here from Lance's discussion. One of the thoughts that he had in that episode, really talking more about how we need to go to the next level with our organizations and with the leadership in our organization. Take a listen. We've been trying to scale Scrum and Agile for a long time and we've written the practices on how to do it. Brian Milner (03:13.23) but we're not allowing the people to practice that. You know, just got through coaching. My youngest son is in fifth grade and we coach his football team. It's like, we're going to sit down and tell you during this play, here's the stance that you take to block. You're basically a robot. Do everything that we say, even if you don't understand it, because the whole scheme for that play is built on everybody doing their job exactly as prescribed. But as you evolve into professional football or high school football, they've learned so much about those mechanics. that's really fun now because they've got the IQ to respond to what's in front of them. That's agile. And that to me is what we have to start learning in organizations, is we know how to run the play at the team level, but how do we build up the people to run the play correctly in challenges when there's adaptations that need to be made? And a lot of times management and leadership is the suffocating part of that where they don't allow for that. It's always interesting to go back and look at those conversations that we have at beginning of the year. and see kind of how it played out. Were we right? Were we wrong? So if you're interested in that, check out that. That was just episode 79 was the first one that we did in 2024. Next up, I'm gonna jump to episode 86. This was one with our very own Mike Cohn. Mike had come back on because quite frankly, we've had for many years a set of user stories that were sample user stories that you could come to our website and download just as a resource for people if they wanted to see what... samples of user stories look like, try to imagine what that would look like in their particular context. So that's why we had this collection of user stories. Well, Mike went back to re-edit those recently, and then he took kind of another look at it and had forced him to kind of reconsider some things, wanted to share some thoughts about those new ideas and thoughts he had about user stories, just in re-examining ones that he had put together previously. So in this next clip, what you'll hear Mike talk about is really kind of a controversy maybe just his own controversy internally, but kind of a shift that he had over the years and really the template itself for a user story. So take a listen to this. I had a bunch of slides. I looked at them a few years ago to confirm this. I looked at them and they all said, I want to blank, right? And it was what the user wants. And sometimes it's not what the user wants. So if you look at slide decks that I create today, they all say, I. Brian Milner (05:36.866) They don't say I can, they don't say I want to, they just say I, and then you fill in the verb. For example, as user, I am required to enter a strong password. I don't want to enter a strong password. I want to type in my dog's name and let the system know it's me, right? So I am required to enter a strong password that doesn't fit with I want to or I can. I can enter a strong password? Well, that doesn't really help. I don't want to. I can enter a strong password. I can enter a weak password. Is that possible? So I do think there's problems with I can, but I leave all of that out of the template and I let the situation determine what that verb should be. Always an interesting conversation there with Mike Cohn. Very, very lucky and fortunate to have him come on usually multiple times per year. And that was just one of the times that Mike came on our show this last year, but really, really interesting stuff there about user stories. If that's something you're interested in, I encourage you to check out that. That was episode 86 with Mike Cohn on user stories. Now we're gonna jump ahead to episode 90. Episode 90, we had a friend of mine, Sheree Silas, come on. Sheree is a very authoritative, knowledgeable person on Agile coaching. In fact, she is the person that I most likely am going to point you to if you come to me and want to find out more about Agile coaching. She has some really great classes and other things that she teaches. And we had her on to talk about Agile coaching, obviously. And one of the things that came up is something that I hear sometimes in classes that Some of this coaching stuff you talk about sounds a little bit like counseling a little bit. Is there a crossover there with counseling? Is this a counseling job? So take a listen to what Shree had to say in response to that question. As an adult coach, you are not an organizational psychologist. You are not a counselor. You are not an organizational therapist or any of those things. That is not the job. The job is consulting, mentoring, training. and some coaching, helping people how to learn how to negotiate, learn how to collaborate, learn how to have good, healthy conflict. And there's helping them to get the business results they want. And it's very frustrating when you kind of hear this taking all the way to the other end of, we're just there to do woo-woo touchy feely stuff. I'm the psychologist. No, that's not your job. And you're not trained to do that. And that's part of the coaching work. Brian Milner (08:03.136) is to help them understand what they need and what they don't. And even as a professional coach, it is my job to make sure my client understands what coaching is and what it's not. And as an Agile coach, that's part of the work is to make sure the client understands what this work is and what it's not. Yeah, really good stuff there about Agile coaching. If you're interested in finding out more about that, listen to that episode. You'll hear more from Sheree on episode 90 about Agile coaching. Next up, I have a relatively new friend of mine, but one that, you know, feel like brother from another mother. Mr. Evan Layborn was on and he came on to talk about some research that his organization had done in partnership with the Scrum Alliance. And in particular, there was one component of that that I wanted to question him about because when I initially read it, it gave me a little bit of some misgivings about it. One of the things I mentioned was that traditionally we have always talked about being a T-shaped individual on a Scrum team that had a depth of experience in one area. but a breadth of experience in other areas that you just weren't an expert in. You were only really looking to be an expert in one area. But this report kind of brought to bear this idea of what they're calling a pie-shaped individual. So think about the mathematical symbol pie and how it has two lines going down. It's kind of like a T with two lines going down from it, right? And when I saw that, initially my first thought was, well, is this just organizations trying to get by with less head count? Take a listen to what Evan had to say about that. I want to be clear that when we're talking about pie-shaped individuals and companies looking for pi-shaped individuals, we're not talking about companies who are looking for one person to do two jobs. They're not looking for someone who's got two skills because they're trying to fill two roles. They're trying to fill two jobs. We're talking about one person, one job, and using multiple skill sets to do that job better. more effectively. In the technology world, we've had a word for this in the tech world for 10 years, full stack developer. A full stack developer is a pie-shaping, it's a developer with test competence and operations competence. They can deploy a DevOps environment. That full stack developer is a prime example of a pie-shaped person. It's not one person doing two jobs. It's one person doing one job with a variety of skill sets. Brian Milner (10:30.752) and doing that job better, exponentially better because of it. There's some really interesting other insights that Evan had in that episode. highly recommend that to you. That was episode 93 with Mr. Evan Layborne. Next up, well, we celebrated a milestone. We had our hundredth episode, if you can believe it or not. And we thought it would be appropriate to celebrate by having two people that we have on quite frequently on the podcast, Mr. Lance Dacey. and Mr. Scott Dunn. So we had something that we don't often have here on the show where we had multiple guests, but we had Lance and Scott on to really look back over the past 100 episodes and look ahead a little bit into what we thought might be coming. And one of the interesting kind of conversations we had there was thinking about some of the changes taking place in the workplace today. You'll hear Scott kind of start in on this with. thinking about the kind of dilemma organizations are facing with the work from home versus work from office kind of situation. And then Lance will come in and kind of relate it more to some larger agility issues as well. Take a listen. Thinking back to the time when people didn't really want to go agile because they thought it was a fad. And it didn't take but a few years, like, I could be wrong. Maybe that is a thing we need to do, right? And then everyone gets on board. But there was a lot of kicking and screaming and doubting the early years. I think we're going to see that with remote work is made like the proving ground of do you really work this way or not as a manager? you get this or not? You cannot lead and manage people currently how you are going to in the future because they were talking about how the new generation. is coming on board and they just won't tolerate certain things. And I think you hit it on the head with that Scott, that if these managers don't learn how to lead and manage with this newer generation, two or three removed from what I'm talking about, you're not going to have any employees because they will not tolerate it. They do not work that way. It was always such fun to have both those people on our podcast and it was even more fun to have them both on at the same time. So I really appreciate both Lance and Scott really helping us celebrate there. The fact that we crossed that threshold into a Brian Milner (12:38.326) our 100th episode. Next up is someone that I found really fascinating. is Miss Heather McGowan. And she was the keynote speaker at the Scrum Gathering this year in New Orleans. And she was so gracious to come on the podcast and talk with us a little bit. She had some really great insights. Just listen to what she had to say here in thinking about sort of the place of work in general as a part of our lives today. But what I think what's really happening is we've outsized what work is in our lives. So community used to consist of social interactions, religious affiliations, clubs and groups we belong to, all of those kind of, if you think of them as circles, because everything's visual to me, all those circles shrank and work became bigger. So now part of this generational change, but more and more people are looking for work to provide their purpose. work to provide most of their relationships, work to fill these. It's a little bit in terms of how we're interacting with each other that's causing illness, but it's also an outsize expectation we have around work. So now it becomes table stakes for a lot of organizations for work to be my self-expression, work to be my sense of purpose, work to be where I think about my values. And it wasn't like that a few decades ago. I heard from a couple of people after this episode, just friends of mine talking about it. I want to make sure I'm clear about something here that Heather was saying, she's not saying that we should find our values from those places. She's just saying that's kind of how society has shifted a little bit. So you can debate whether it's good or bad, whether the other circles that she mentioned had shrunk or grown or anything like that. But really that's kind of the reality we're left with is that there's a lot of people who find their belongingness from work today, as I said, whether that's a good or bad thing, you can debate. but that's certainly a reality I think we have to live with. And this was a really interesting discussion. So I highly encourage you to check that out if you want to. That was episode number 111 with Heather McGowan. Next up was someone I found really interesting as well. This was Mr. Clinton Keith. Clinton is a veteran of the gaming industry. And I know there's always some interest in that in our listeners and in the Agile community about how you really can apply some of these Agile principles and things. Brian Milner (14:55.704) to an industry that's so fast moving like the gaming industry. Well, as I said, Clint has worked in that industry for a very long time and he's seen pretty much everything there. He's worked in all different kinds of gaming companies. He's helped them to learn and apply these agile principles along the way. So I'll just share a snippet of the conversation that we had. In this clip, he's talking really about how some of these principles we talk about like, individuals and interactions over processes and tools and are we letting something like a new technology drive how we do things or is it really more about what's the value we're trying to deliver, right? And in the gaming industry, it's fun. It's delivering something that's fun. So take a listen to what he had to say about kind of one of these experiences he had about really finding the fun. The big light bulb moment was having a short deadline on showing something of value. led to people making better choices from the player's perspective, not this challenge of, what can I do with artificial intelligence over the next two years? That's part of the big challenge with these big, huge games of saying, it's like, hey, if there's not a payoff, if you can't see value, and this was an early lesson I learned working with Nintendo of Japan, the guy that made Mario and Donkey Kong, we worked with him directly, Miyamoto. You always had this thing, it's like, the fun fast, show the value of it. And it always stuck with me. When you have these short deadlines, you want to encourage the teams and the product owners is judge the game. Not what you see in the potential in two years. Judge your vision of the two years against what you're seeing every other week and adjust your expectations. Don't fall in love with your vision. Judge the game. Don't fall in love with your vision. Such great advice there, and I think it's so applicable to really industry. Don't get caught up in that word game, right? Judge the product. Think about it that way. I think sometimes, especially for us as product owners, sometimes we can look at that and say, we've got these grand visions and grand designs for our product, in two years we're gonna have this incredible product that's gonna do all these things. Well, you may not make it to two years. You may not make it to two years if you don't. Brian Milner (17:16.897) deliver a value earlier, right? If you don't capture the imagination and attention of your customers, if you don't solve a problem for them upfront, we know the big idea is gonna take longer to get to, but I think what Clinton is saying here, and it's really an important point, I think, is that that's part of what we kind of focus on as Agilist is trying to find the value and deliver it early. So just a really fascinating episode there as well with Clinton. Encourage you to check that out, especially if you have interest in the gaming industry, lots of good content there from him in episode 120. Lastly today, I'm gonna leave you with one last one that wasn't too long ago here, but we had someone that is kind of a beloved figure in the Agile community. She's often referred to as an Agile visionary. That's Ms. Linda Rising. And she came on to talk about multiple things with us, but one of the things that she talked about in our conversation, was about a research project that Google did several years back called Project Aristotle. They were trying to figure out kind of the components, what went into making a high-performing team. So just listen to what Linda has to say about what their scientific research kind of uncovered about really what goes into making a team high-performing. All these different researchers made the same mistake in the beginning. and it's the same mistake organizations make. They thought in the beginning that what makes a smart team is smart people. Wrong. Not that you don't want smart people. You can have a team of very smart people that doesn't have any of these other characteristics that is not intelligent as a group. We really have to wake up and realize, first of all, that we're doing that, that we're valuing IQ or individual intelligence, smartness, you went to this school or you got that particular SAT score. It has nothing to do with that. It's not that there's no correlation, but it's weak. It's much better to have people who have these other characteristics. I just have to say Brian Milner (19:38.444) We are so spoiled Agile mentors with some of the great people like Linda Rising that we get to hear on this podcast and learn from really as sort of a masterclass from some of the best thinkers in this industry. And I know I'm very thankful for them taking their time and thankful for people like Linda Rising coming on the show. If that dialogue that you just heard there sounds interesting, check out that episode. It was episode 123. Linda talks about a lot of lot more great stuff there in that episode. But yeah, we get so many great guests on our show and that was just a handful. It's hard to even pick out just, I think we just had eight of them there. It's hard to pick out just eight over the past year, because there were just so many. And any of the other guests on here, I hope you don't feel like you were not in the top eight or anything. This was just a sampling. I just wanted to pull some different kinds of episodes and I think there was quite a variety of guests and topics and things that we had on the show this year. It just makes me excited about thinking about what's possible in the next year. I know we're gonna be trying some new things. I've been interacting with some of you at the Agile Mentors Community and you've been talking to me about some suggestions about things that maybe we can do. And we're gonna try that. We're gonna try some new things going into the new year. So you may see some shifts from time to time of just a few experiments that we might be trying. As always, we'd love to hear your feedback on any of those things, but we're always in search of making this the most valuable use of your time. We think that the quality of the people, like you just heard, is pretty good. We're pretty happy with the people that really decide to come on the show, and we're very humbled by the fact that they choose to come on our show. I just wanna always make it the most valuable use of your time. We want this to be the most valuable Agile podcast that's out there. As always, if there's anything we can do to change that, I'll go ahead and just say that now. email us podcast at mountegoatsoftware.com. Put that at the end of every episode. Truly mean it. If there's things that you want us to experiment with or try, if there's guests you want to hear, in addition to some of these great guests you heard today, there's other people that maybe that you think would be good on the podcast, send us an email, podcast at mountegoatsoftware.com. Or if there's a topic that you want us to cover, let us know that as well. We'd be more than happy to try and put that in. In our planning, Brian Milner (22:01.666) we try to always put the listener's suggestion kind of towards the top of our backlog. It may not be the very next thing we do, but we try to make that as soon as possible. Oftentimes we have to find the right guest, but as soon as we find the right guest, we want to get that listener suggestion on as soon as possible. So thank you for those that have made suggestions in the past and keep them coming. I'll just go into a few other things then and wrap up and get you on your way. It's been fun looking back over the last year. And as I said, I'm excited about seeing where we go next year. Speaking of that, just make sure that you like and subscribe to the podcast. That way you don't miss any of these things, like any of these great episodes that you heard little snippets of here in this podcast episode. And with that, I guess that'll be a wrap for another year. So Agile Mentors, my heartfelt happy holidays to you. Whatever you celebrate this season, I truly, truly hope that you get to spend some time with your family, your friends, your loved ones. truly hope that you get some time to reflect on what you're grateful and thankful for. I hope you come back next year refreshed, ready to go. I hope that's part of your sustainable pace, that time of renewing with the people in your life that are closest to you. We look forward to seeing what happens with you in the new year. So join us back next year. We'll kick things off. We'll be back here in just a few weeks. And on the 8th of January will be our next episode that we release. And we'll have our... of annual sit down with Lance Dacey to look ahead to 2025 and see what's coming up then. So join us and hope you have a very, very happy holidays. See you next time on another episode of the Agile Mentors Podcast.

Does Every User Story Need to Be Small? Small user stories are essential to success with agile. When it's time to bring stories into an iteration, I always want them to be small.But larger stories have their place as well–especially for something you're not going to work on imminently.Suppose you have just begun work on a new product that will include a set of reports. Because this is a new product, there is nothing to be gained by writing a bunch of small user stories around each one of those reports at this point, especially since you don't yet even know all of the reports that will be needed.At this stage of the project, having one big reporting story rather than a bunch of little ones keeps the size of the backlog more manageable. You'll have one entry in your tool instead of 15 or 20. That's much easier to manage.Further, if you do write all the small user stories, one per report, it gives the impression that you've thought of everything. Early in a project, that's probably not true. New reports will be identified and some that are asked for initially may not be necessary.Don't fall into the trap of thinking every story needs to be small from the beginning. They don't. Instead, plan for stories to shrink in size and grow in detail as they move closer to being brought into a sprint. For most teams, this will happen during the product backlog refinement meeting one or two sprints before the iteration planning where they'll be considered.Letting timing dictate story size will help you succeed with user stories and with agile. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Last week a client mentioned they were using feedback they'd received on an MVP to make “course corrections.”My ears bristle whenever someone talks about correcting course on an agile project.There's no such thing as course correcting in agile.Am I crazy? After all, a fundamental part of agile is acting on feedback to improve a product.My problem with the concept of course corrections is the way it presupposes there is one correct course and that it's possible to know it in advance.That's not the case.Sure, many products begin with a product backlog that describes what the product owner thinks will be the right combination of features to achieve the desired outcomes.But on any non-trivial product, this recipe cannot be fully known in advance.Successful products are created by iteratively homing in on the right combination of features. And that set of features can only be discovered through trial and error.No matter how much research a team does before developing a feature, they never know how users will respond to the new feature.Will they love it? Will they hate it? Will they use it? Will they use it as intended?So a product owner or manager places a sequence of bets. The result of each bet guides the product owner in placing the next bet.Course-correcting means there was a single, correct course. It implies that development has somehow deviated from this correct course and must be brought back in line.Instead of talking about course corrections, I talk about course adjustments. As a team learns more, it adjusts course—which is the way to succeed with agile, How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Get ready for a special Thanksgiving episode where Brian Milner shares what he’s most grateful for this year and why a little reflection on gratitude can go a long way. It’s time to embrace the positives and celebrate the connections that keep us growing. Overview In this special Thanksgiving episode, Brian Milner takes a heartfelt pause to reflect on gratitude, expressing thanks for his listeners, cherished friendships, and the fresh ideas that continue to shape his Agile journey. He invites everyone to join him in acknowledging the positive aspects of their lives and to practice gratitude, especially during difficult times. References and resources mentioned in the show: Subscribe to the Agile Mentors Podcast Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Auto-generated Transcript: Brian (00:00) Hey there, Agile Mentors. Yes, I'm not saying my typical opening because this isn't a typical episode. I don't want to make anything cheesy here. It is Thanksgiving. It is around Thanksgiving time here in the US. And traditionally, I've given a little message around this time that's just me. And I won't take a lot of your time here today. But I do want to just kind of focus in a little bit on that concept of being thankful because I do think it's important for us to try to understand and be thankful for the things that we have in our life that maybe we don't always take time to kind of recognize. And this year has been a very kind of challenging years in some ways for our industry, for the profession, but it's also been exciting in some ways as well. And rather than dwelling on just things that would be kind of hypercritical or negative, I think it's important for us to maybe focus in on some of those positive things. So I'll just give you a quick hit list here of things that I, I just wanted to think about about three specific things that I thought were things that I am extremely thankful for this year at this point in my life. and in my interactions with people. The first and foremost, I'm not saving the best for last, I'm doing the best first. That's you, the listeners of this podcast. I can't thank you enough for tuning in and listening. You put out a podcast like this, you have no idea. It's kind of like you're shouting into the void. And you have no idea who is listening and who is not listening, what their desires are, what they want from you. That's why I beg you all the time for feedback, because I just want to know how it can be better for you. I just want to know how I can make this a better use of your time. But I've had the pleasure this year of getting to go to several conferences and going to those conferences is always my chance to kind of talk to face to face some of the people who listen to this podcast. And it is such a thrill. it, just excites me to no end when I'm at those conferences and someone comes up to me and says, Hey, I listened to the podcast. I really liked the stuff you put out there on that. And it really makes an impact for me. Or, you know, I'll hear someone come up and say, Hey, I just found it. I started listening from episode one. I'm now on episode 10 and, it's all been really, really impactful. And I just really appreciate, what you're doing there. So I, I just want to say a huge thanks to you. I mean, we couldn't keep doing this if we didn't have listeners. So I just, I really appreciate you. I appreciate that you're on this journey with me. We're kind of both learning together as we go through this because every episode I learn something from these guests that come through. And I know that you are as well. You're learning things as we go through these topics. So I just want to thank you for being along the ride with me. And especially thank you for those who have come up and introduced yourself and said hello to me over this past year. Really, really appreciate getting to meet you and learn a little bit more about you, about the things that you want and the things that you need. So thank you for being listeners. Thank you for being, for the people who send feedback and email us over our podcast at mountaingoatsoftware.com address. I really, really appreciate you. because we wouldn't be here without you. Another thing I thought I was really, really thankful for this year, the kind of in line with that is just new friends. We do a lot of this stuff, or least I should say, I do a lot of this stuff as a trainer out of my home office and spend several days with people in classes. And I make a lot of new friends through those classes just from people that I connect with and people who stay in contact with me. So I'm highly appreciative of those people that are kind of still on my radar and people that have come through classes with me and have stayed connected with me. But I'm appreciative of the people that I've gotten to spend some quality time with at the different conferences I've been at this year. There's been several conversations that I've had with people that have been so impactful to me, just really, really personal, sometimes emotional conversations I've had with individuals. And it just reminds you that it's human beings that are at the core of this, It's people. getting to know and understand people, I think, one of the joys of getting to do this kind of work. That you get to meet new people and get to hear their stories and learn how they see the world. So I'm really thankful for the new friends that have come into my life. through the course of the last year. And then I'm really thankful for new ideas. The guests that have come through here have, you know, many of them have kind of given me new ways of seeing things, kind of seeing things through a new lens that has challenged me. And I'm always really grateful. when an assumption or an opinion I have is challenged, I don't think of that as being kind of an aggressive thing towards me. I think of it as, well, that's kind of pushing my boundaries a little bit. I thought that I knew and understood this in this way, but now someone's challenged me to look at this from a different perspective. I look at this from a different viewpoint. And I am just enormously thankful that as I've... grown in this profession as I've been doing this now for, gosh, I've been a software developer maybe 25 years now, I'm that old. But given that, there are still plenty of concepts and ideas that they're never ending. There's never an end to the things that would challenge my assumptions or my beliefs about things and get me to really re-examine them. That doesn't mean I'm going to change all of them. But I tell people who come through the class, I don't have any problem with you challenging an idea. The idea isn't me. The idea is an idea. And I change ideas all the time. If I get presented with better information, if there's new data that comes out that says, hey, know that way we've been thinking about this, that's actually wrong, I embrace that. I welcome that. Because it's the reality. Right? And I don't want to continue down the road that's false. So I just really, really appreciate that idea that these ideas are not stale. These aren't ideas, aren't things that would just go by the wayside. These are things that constantly challenge us and get us to look at things in a new light. This isn't an awards acceptance speech, so I'm not going to go through the list of specific people. There's lots of people that I would thank and they know who they are. There's lots of people who work really hard for this podcast to work. And people like Mike Cohn who have mentored me and helped me to understand things that I would never have if I had not come in contact with them. So just really, really am thankful for all of those things. And I encourage you, it may sound like a silly thing, But take five minutes, take 10 minutes and just sit down with a blank piece of paper and just write out, if you were gonna make your top 10, right? What are the top 10 things that this year that you're thankful for, right? You don't have to go through, you know, just the stereotypical things that you might put down, but you know, if you were to think back over the past year, what would be the things that you are most thankful for over the past year? And as I said, I know it's been a hard year for a lot of people. But I think that when we are able to stop and do that and really understand, hey, here are the things that really have gone well. Here are the things I'm really thankful that I encountered or that happened to me in this last year. It really can have a dramatic impact on your outlook and how you see things and really what you look for moving forward, what you focus on moving forward. So I just encourage you, it's a week for that. It's a time when we do that here in the US especially, but if you're somewhere international and maybe you have a Thanksgiving on a different part of the year or a different day, or maybe you don't have one in your country, I encourage you to just take time out to do it. I think you'll appreciate it. I think it'll make an impact for you. So that's really all I got for you today. As I said, short little message, kind of traditional for us to do a little brief little Thanksgiving message here. again, I just want to thank you. Thank you for tuning in. Thank you for being with me on this journey, especially this past year. And I'm excited. I can't wait to see where we go from this point forward. Who knows, right? We might do changes. We might try some new things. All kind of depends on what you guys want to see in here. So thank you so much for where we've come so far. And we'll call it. So. We won't do any of typical outro stuff I normally do, but you know what I normally say. So just kind of think that in your head. Thanks, everybody. I really appreciate you listening to this special message. And next week, we'll be back with just a regular episode. You're going to really enjoy it. So talk to you next time on another episode of the Agile Mentors Podcast.

Curious if your product team is caught in common traps that limit success? Join Brian and David Pereira as they explore how to simplify workflows, make smarter bets with prioritization, and shift from output-driven thinking to delivering real value. Overview In this episode of the Agile Mentors Podcast, host Brian Milner chats with David Pereira, author of Untrapping Product Teams. Together, they dive into the common traps product teams face, the differences between project and product management, and practical strategies for prioritization. David shares insights from his book, offering advice on building healthier backlogs, creating adaptable roadmaps, and moving beyond a feature-obsessed mindset to focus on delivering true value. References and resources mentioned in the show: David Pereira Untrapping Product Teams by David Pereira Certified Scrum Product Owner® Training Advanced Certified Scrum Product Owner® Mountain Goat Software Certified Scrum and Agile Training Schedule Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. David Pereira is a seasoned Product Leader with over 15 years of experience guiding Agile teams to deliver real value faster. As CEO of omoqo GmbH and a top writer on product management, David is passionate about helping teams overcome challenges, unlock their potential, and simplify their workflows to drive meaningful outcomes. Auto-generated Transcript: Brian (00:00) Welcome back Agile Mentors. We are here for yet another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have Mr. David Pereira with us. Welcome in, David. David Pereira (00:12) Let's be here. Brian (00:14) Very excited to have David here with us. David is the author of a new book called, Untrapping Product Teams. So product owners, this is going to be a discussion that I know you're going to find very interesting. We're going to be talking about a lot of things that have to do with product teams and sort of the ins and outs of working with your products. So David, just for starters, what inspired you to write the book? What was the main problem you were trying to address when you sat down to write this? David Pereira (00:42) pain. I have worked as a product person for many companies throughout the years, different countries, different sides. And one thing that I realized is that there many things going wrong. And sometimes we just don't know that it's wrong and it hurts. Then when we realize the question is, what are we going to do about it? So I started writing about untrapped products. From this perspective, Brian (00:43) Ha ha ha ha. David Pereira (01:12) of there's something wrong, we might not see, but let's start from this and then maybe we can transform how we work for the better. Brian (01:23) Awesome. Yeah, that's a great take on it. Cause I agree. There's certain times when as a product owner, know I've, you you're kind of chugging along and things are going okay, but then something happens and it's sort of like, wow, this is painful. I don't know where it's, I can't put my finger on what's going wrong, but there's something happening here. And you you try to push through it and just get past it sometimes. And it's, that's not always the best strategy. I know you talk about there being sort of these dangerous traps that are kind of typical traps that product people fall into. Can you share any of those with us? What are some of the dangerous traps you identified here? David Pereira (02:01) Sure, there's the classic one called the gigantic backlog. So the team looked at it and we're talking about product owners, but sometimes product owners get demoted to backlog owners and they don't even notice that. So that's one of the most classic traps, but there's also another I call the calendar driven framework. You may think you work with agile, but then you realize that you only do what is in your calendar. So that digitates what you're doing and so on. And you fall prey to what I call as a meeting marathon. Brian (02:38) Yeah. I want to go back a little bit to your, to the big backlog kind of, idea there, because I, I know that's a issue I've talked with people about in class a lot. And, I just want to get your take on this. Cause I, one of the things, you know, we'll, we'll discuss in classes sometimes just the idea of having too big of a backlog and, and kind of wrestling with it and trying to get it in shape. But the question always comes up, you know, you what's the. the right number. We ask a question in class and say, how big is your backlog? And you'll see different reactions from people. Some people, less than 50, other people 250, other people 1,000 plus items. Is there a number? Is there a number that beyond which it's all of sudden now too big? David Pereira (03:24) Yeah, for sure. So for me, first is understanding what is the backlog about. It is a vehicle to drive whether when you look at the backlog, should be able to tell a story. You should know where you're heading to. But when you look there, if you see a 60 year old Christmas wishlist that has everything in but you cannot connect anything, that's when it starts smelling. So for me, a good backlog will have no more than I would say two, three things ahead of us. There might be some things that are directions that we will continue refine and get it better and so on. But if we would have something that takes us like six months of work to get it through, maybe we are doing project management. Brian (04:12) So that's an interesting distinction. if we're moving into product, how would you define that then if we're saying project management versus product management, how do you define that difference? David Pereira (04:23) So project management in general, we assume we know what needs to happen. So we start planning on when we do what and how long we're gonna invest in this and so on. Product management is more about starting what is value, what do we want to achieve? And then we start embracing the unknown, facing reality, learning from it. And then the backlog will emerge from our learnings. So it means we know where we want to land, but how we're gonna get there. We know where to start, but not the next 3, 4, 5 steps. Brian (04:56) Love that. So that gets us kind of into talking about road mapping a little bit because I know that's one of the things you talk about in your book and kind of the idea of trying to plan a little bit far in advance. So if we have a backlog, it's really more two to three sprints versus six months. Do you recommend the product owners roadmap for longer than two to three sprints or is the roadmap just a two to three sprint roadmap? David Pereira (05:24) Sure. So the roadmap for me, it is about a different flight level. So the backlog is the now. What are we doing right now in the next two sprints as we talked about? The roadmap, we're looking at what is the overarching goal we are pursuing. So that could be, for example, a milestone that we aim to achieve for the next two, three months. And then the backlog will march towards that. But for the roadmap, I think it's still important to have something like, what is the direction for six months that maybe we are considering. But the farther we go, the more I would say blurry it becomes. It's more like a direction and we can feel free to adapt that. Brian (06:13) So help me understand here, because one of the things I think that I hear a lot of questions about in class is, since 2020, the Scrum Guide has added this idea of a product goal. And we've always traditionally thought about having a vision for the product. So now we have sort of this nested nature of having a vision, a product goal. And of course, we've always had sprinkles. How do you see those things related? relating to some sort of road mapping. David Pereira (06:45) Let's take a company here as an example. I like looking at the SpaceX. What is the vision? The vision is something audacious, inspiring, that people can connect with. Might be very hard to achieve, but it gives us guidance. For SpaceX, would say two words, populate Mars. That's the vision. It's very far. And what would be a roadmap goal? For example, something they achieved already. It's a step to get closer to the vision. Build a reusable rocket. That's something they spent a lot of time doing, and that could be a roadmap item. Then when you go to the sprint ghost, it's just a smaller step towards that. Brian (07:35) Gotcha. Yeah, that's great way to put it. I like that idea and I appreciate you using kind of a real world example. I think that kind of drives it home for everybody. I think it's obviously one of the things we talk about quite a bit in Agile is that idea of that we don't have any problem with planning. Planning is a good thing. What we have a problem with is plans that are so concrete that they're inflexible. So when we... I've always thought as a product owner, when we try to create these roadmaps, the further we get out from today, the looser, the less defined it is, the more rough the idea is, and the less people should count on there being any date that's going to be met based off of that longer term horizon. Of course, there are exceptions to this. You mentioned SpaceX, mean, SpaceX has a multi-year goal. I mean, they have something that's kind of further out to the future. So I think that there are some exceptions that we probably could make in there. But I think you're right. Think about them in that steps as far as vision to product goal to sprinkle. One of the other things that I found kind of interesting in reading up and thinking about your book is you talk about the difference between coordinated and collaborative workflows. Can you define those? Tell us a little bit about what you meant by that, the difference between those two. David Pereira (08:31) Yeah, of course. I start with a question. When we are talking about coordinative development flow, step back and then reflect. Do you talk more about work than you do it? Or you just go and do work on it? If you feel like you are all the time talking about work, everyone is talking about it, you have so many meetings discussing and so on, but then you wonder who is doing the work, then there's a chance you are in the coordinative development flow. The collaborative development flow, it's a little bit chaotic. There are many things happening. Teams are looking at what can we do right now? What can we do next? They are adapting all the time and so on. Plans are actually means to an end. They are not reached. They point a direction. Teams may have a plan, but it's very simple. It is not a predictive thing. When you are in the coordinative development flow, things take long. For example, you may have a lot of ideas in the beginning, then that means you need to find the most promising idea, speculation. So you may use frameworks to have the best scoring and understand what is the idea most promising. Then you invest time and crafting high fidelity prototypes and so on. There's a lot of coordination back on Perf. But if you go to a collaborative, you say, all right, I have all of these ideas here. Which ideas are worth? That's the first question. Then you say, how do they meet our, for example, product vision? How do they relate to our strategy? How do they contribute to our goal? And if you don't have answers to that, you use your friend called trash bin. So you put the things in your trash bin and then you start moving forward. And you say, all right, how do I know this has desirability? It's viable from the business. How do I know we can do it? then start running experiment. And then some things you realize, actually customers don't need it, then you don't pursue. So that's why it looks like chaos because you don't know what will get to the end, because things will fall apart on the way because you learned they don't make sense. On the coordinate, you know what gets to the end. You just don't know if it's the right thing. Brian (11:18) That's a great point. And you're right. If we think of this from an experimental mindset, the product development game here as more experimentation, think you're right. There's going to be things that don't, the experiments that don't turn out the way we expected, just like there is in any kind of experimentation. that can be some of the most productive moments actually is when you have those experiments that turn out differently than you anticipated because that can lead you in areas that are surprising and new and have value that you might not have otherwise recognized, I think. So yeah, I love that. I think that's a great way to talk about it. It makes me think a lot about prioritization as well because I know that's a big area for us as product owners and... You know, someone sent me an article the other day that, that I share sometimes with people that's, it's a blog post that someone put out there. was like 127 different ways to prioritize your backlog. It's just, they're all methods, right? They're all the things that you probably, all of us have probably heard and, you know, things like Moscow and, and other things like that, that people are typically use, to prioritize their backlog or rice or. relative weighting or something like that. But one of the things that I find kind of interesting with that, and I want to get your take on this David, is sometimes when I will use something like relative weighting, for example, or rice, very much more of an analytical approach, right? And we're trying to try to analyze it based on several factors and see what the score comes out at the end, which one's higher than the other. but one of the interesting kind of a sideline effects that I've noticed in myself as a product owner is sometimes I'll find that I'll run that kind of a process on several features and I'll get to the end and you know, I've got three features and know, a feature, a, and C and, you know, I'll take a look at the results and look, you know, it looks like feature B is number one feature C is two and, and a is three and Sort of in my head, I kind of feel this dialogue happen where I think, huh, really B is number one. Wow. would have never thought that would have been the case. That's surprising. I can't believe B came out as number one, but maybe I answered those questions incorrectly. Maybe I should go back and change my answers in doing this analysis because that can't be right. B shouldn't be one. B should maybe be two or three. And I kind of call it the the gut instinct, you know, it's kind of that gut instinct moment where you look at the results and it feels wrong, right? And I know you talk in your book kind of about, you know, opinions without evidence and kind of the idea of, know, it made me kind of think about that scenario where sometimes you'll run it through some kind of a prioritization technique and there'll be a definitive answer, but you kind of have that instinctual moment that feels like maybe this is not right. How do you handle those moments, David? Do you have any problem overriding results or do you always take the results of some kind of a prioritization technique that you've tried to use? David Pereira (14:44) Mm-hmm. So prioritization is something quite interesting. What I see is many companies search for certainty. We need to ensure that we find what drives value. So we take some time analyzing that. The problem is that we start injecting a lot of speculation. We think what it's right, but we don't. What I see is prioritization is a bet. So I think about placing bets. Say, all right, so there are all of these cool ideas here. I try looking, for example, at potential. As of now, what do we know about it? How many customers would care about it? How much would they care about it? Can we deliver something of that? I say, all right, let's invest one day and see what we can learn about it. Then we can move to the next. And then we can invest maybe two days. And if we don't like what we learn, then we just stop. And if you like what we learned, then we say, let's invest another week. And then we keep going to the point we say, this looks cool. And then we can do something about it. So I say like, let's have a bias toward actions. We can face reality as fast as possible. Then we can learn what makes sense and what doesn't. And I give you a concrete example. When I started about the book, I was thinking, Does it make sense for me to write a book? How do I know that? I got invited to give a keynote. I said, I'm going to speak about something that I would write and I will see how it resonates. I gave this talk 10 times. And then what happens after each talk? Few people would come to me and say, Hey, I like this thing. I like this. I like this. And everything you didn't mention, I started questioning. And then what they like to explore. And after the 10th talk, someone said, when are you writing a book about it? said, aha, now it's coming. I said, I need you to do another experiment. I posted on LinkedIn. said, I'm writing a book. And I had in my mind, if at least 200 people show interest in that, I'm going to interview people to understand their challenge. So I did that. When I decided to write a book, I didn't write the book. I explored. where to write and so on and all of this. Because I was placing bets, small investments that give me information that I can use as evidence. And that's the same what I do with digital products. It is about learning from reality, not from a meeting room. Brian (17:25) I love that. Yeah. I think we've, I know that I've heard that language used quite often, the idea of making small bets or making bets on things, but it really is a revolution. And you're worried way to think about it. like your, your concept of, of thinking, is it worth a day? Right. Is it worth a day to do this? Is it worth me betting a day on, on trying to find out more information about this? is that really how you look at prioritization then is, is, is you prioritize it? Is it, is it kind of, Is it worth the effort to do what it's gonna take to do this thing and think of it that way as a bet? David Pereira (18:01) Yeah, in this direction, because for example, when we explore what is the potential outcome, how many users would care, how much do they care about it? I say, let's see if that is true or not. Let's start learning about it. Then we can have a better understanding of the expected result. Because the danger is when you start talking about these things, it just do a scoring, like a rise, eyes or something else. then you get false confidence. So I want to move away from the false confidence to get closer to reality because in the end of the day, we don't know what we don't know. Brian (18:41) Yeah, I think that's a really good point to make. I know I've run an experiment sometimes in classes where we'll have a couple of different ways of prioritization. I'll give them something complicated like relative weighting or rice. And then I'll give them something, you know, ultra simple, like stack ranking and, you know, have them compare and say how, what's the difference. I know you talking to your book about kind of how important it is to simplify the decision-making process. And so I'm just, what are some of your strategies for that, for trying to simplify that decision making process? David Pereira (19:19) So you need to know what is priority right now. So you can filter out things. For example, if your product is scaling, what matters most? Is it retention? Is it growth? Customer satisfaction? Which is the game you are playing? Because if you don't know the game you're playing, everything is a priority. Then you need to discuss everything. So that's the reason I like starting with what matters most. Because then you remove everything else. then you can look at, so if growth is what matters most, let's think about what will contribute to that. Then we go from this. Brian (19:56) Yeah, that's a great way to look at it. I think you're right. I it's the outcome that we're trying to drive, right? I mean, we're rebuilding features or we're proposing to build something so that we have this outcome. And if we're not really driving that outcome, then we're wasting our time. We're not really doing what we're trying to do. Yeah, that's a great point. I know one of the other points you talked about in your book is kind of this idea of periodically doing product health checks. David Pereira (20:12) Exactly. Brian (20:23) And that was kind of an interesting new concept for me. I not heard that really spelled out in any way. Can you help the listeners kind of understand what you mean by a product health check? David Pereira (20:34) For me, it's a falling. We may start doing things without challenging them. We don't know if they are good, we don't know if they are bad. We know how to do them. And then that becomes our routine, our habit. On Monday we do this, on Tuesday we do that, on Wednesday we do the other. And we keep doing, and they give some results. But the problem is, is it the right thing? So I like stepping back. and looking at a few aspects so we can say, where do we stand? And then you may uncover something that is, I'm not doing it or something that I'm doing that contributes to a bad result. I always ask teams, when was the last time you retired a feature? And sometimes I hear only crickets. And then I say, when was the last time? I say, we never retired a feature. Said, what is your definition of a good product? And some people tell me, well, a good product is the one you have all features you need. There's nothing else to add. We're not there yet. And then I asked them, can you open Google? How many features do you see in the homepage? For me a good product is the one you have nothing else to remove. It's a bit different. So when you have these health checks, you have the moment of challenging, having a different perspective. And then you have the chance of saying, I want to change. I want to do different. Then you can improve how you work. Brian (22:10) Yeah, that's a great way to look at it too, because you're right. we're, you know, I think about this oftentimes when I talk to people about, you know, kind of their vision or even their customers and users. And really, if you can't understand or you can't really define who it is you're targeting or what it is you're trying to achieve, we shouldn't be doing it, right? We should stop and understand those things first before we move forward. I know one of the other things that you'll you talk about in the book is kind the feature obsessed or feature focused mindset. And just kind of wondering, you what kind of practical advice could you give to different product owners, product managers that are struggling in some way with that feature focused mindset? David Pereira (22:57) Ask more questions. That's where I start. Whenever you come with a feature, you say, what is that for? What does it enable the user? What would be the other options? Let me give you an example. In one of the places I worked, we realized that we had trouble with signup. And then someone came with an idea. Of course we have a problem. Because, let me do this again. Of course we have a problem. Because... We have to create a login all the time. If we have social login, then it's amazing. And then we put the Google login there. And we said, with Google login, we will simplify the sign up process. Nothing happened. Sign up rate remained the same. Then I started interviewing people who came to our website, but didn't sign up. What I learned from them was, I don't understand your value proposition. And then you asked me to create a user, you're going to load me with emails. Why am I going to do that? I'm not going to do it. And then I realized that the friction was something else. The value proposition was unclear and they didn't want to give their data. So we could put whatever login method, it would not help. We started with the wrong question. Brian (24:17) Yeah, that's a great example. I appreciate you sharing that because I think that's a common problem I think we have in the product area is kind of we see a response or we see that something's not going the way that we thought. And I know I can have the inclination at least to jump to what I think is the reason behind it. without actually verifying that that's the reason behind it. And that's a great example, right? mean, hey, we thought if we add a sign up and do it through Google, that's going to remove friction. It'll make it easier for people to sign up and we'll get more signups. Well, not if they don't really understand what your value is and why would I come back to this site? Why do I want to get emails from you? I'm not clicking on the button to go through giving you my Google information if you haven't sold me. Right? Yeah. Yeah, that's a great point to make. Well, the only other thing I'd say is I know one of the kind of time-honored discussion topics here when we talk about this stuff is really people who focus more on the output and getting distracted by outputs versus really focusing on value. What kind of advice would you give to people who either don't really understand the difference or find themselves kind of slipping back into being more focused on output versus value. David Pereira (25:53) Talk about assumptions. We all assume something is gonna happen. Sometimes it's just in our subconscious. We need to bring to our conscious level. For example, we say, this feature is gonna be a success because, then come your assumption, because customers want, because customers will understand how to use it, because the business can collect value. These are assumptions. And then you can say, How can I test these assumptions before I invest time into creating the feature? Then you learn. Brian (26:29) Yeah, I agree. That's so important. Honestly, that's one of the biggest paradigm shifts I think I went through as a product owner is that kind of shift in understanding these things in my backlog, they're assumptions. They're not requirements. They're not things that have to happen. They are things that could possibly happen. And the idea is to determine if they're the right thing to happen or not. And if not, then we should move on. Well, this is awesome. I think the books, the topic of your book sounds really fascinating and I hope everyone goes to check that out. It's called, Untrapping Product Teams. And again, David Pereira is the author here. We're put links to all this into our show notes. So if you wanna click on that and find out more, we'll put you in the right place so you can find out more. just, I'll give you kind of a sampling here just so you kind of understand my... My own boss here, Mike Cohn, has a quote here about it that says it's his new favorite product management book. So it's just, he's got people like Marty Kagan, Martin Dalmigeon that's kind of weighed in on this. Petra Willie has given quotes about this. So there's lots of big names that have read this and given it good reviews and said this is a really important work in the product area. Really encourage you to check that out. David, I can't thank you enough. Thanks for making time to come on the show. David Pereira (27:59) Glad to be here.

Happy Halloween! What do you like best about the holiday: the candy, the costumes, or the scariness?The scariness wins for me, although a fun-size Snickers is hard to resist.But there's good scary and bad. I've seen that adopting an agile approach to product development can be as scary as a good Halloween movie or ghost story. One thing that can be scary to some is the assumption that agile is more stressful.And if true, that would suck—no one wants more stress in their life. But let's take a closer look at those practices or aspects of agile that seem like they could increase stress.For example, collaborating with others more frequently and intensely could take away the quiet, recharging time needed by some, especially introverts.This can be frightening and a good Scrum Master or coach should assess whether team members are getting enough time for solo work. Designated hours for this can go a long way.Similarly, having to report daily on yesterday's progress and today's plan can feel like nonstop pressure, which would be frightening.A good Scrum Master or coach can address this, too: by ensuring that daily meetings are for team members to synchronize their work rather than allowing the creepy impression that everyone is checking up on them.Sometimes this message needs to be shared with those outside the team; other times, team members themselves need to be reminded that the purpose is merely to synchronize and coordinate effort.One of the more frightening stresses of agile is that deadlines are never more than a few weeks away.However, because of their frequency, these deadlines are generally less important than the one big deadline of a traditionally managed project.I sometimes think about the differences in these deadlines in terms of running on a treadmill.A traditionally managed, or waterfall, project with its one big deadline is like running a hill profile. It's nice and easy for a while until a big hill starts and then it's extremely difficult and stressful.And then the pattern repeats: pretty low stress for a long time and then really stressful at the end when the team tries to get the project over the big hill.In contrast, agile is like setting the treadmill at a 2% incline and leaving it there for the duration of your run. It's moderately stressful but never excessively so.As team members become accustomed to the smaller deadlines that conclude each iteration, these become far less frightening. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Pumpkin Spice Season - Mike Cohn Pumpkin spice season is upon us.It seems every company jumps on the pumpkin spice bandwagon. I enjoy the humorous memes such as for pumpkin spice tacos and even a pumpkin spice muffler for your car.I think pumpkin spice is so popular because it can be added to so many things. (But please keep it off my tacos.)In that way, pumpkin spice is like agile. A little agility can be added to many things.That's why we've seen agile move beyond its initial application in software development. Agile moved quickly to all forms of product development. Today, we see agile in education, marketing, construction, law firms, and more.A few years ago, a bank called itself “your agile bank.” I'm not sure I want my bank to be agile. Teams at the bank can be agile, but I want money at my bank to mostly just sit there sedately earning interest with no need for agility.We even see agile for managing our personal and family lives. I hear regularly about family backlogs. One former course participant contacted me to say he'd become engaged after he and his girlfriend began holding a relationship retrospective every Friday.Agile, like pumpkin spice, is everywhere. Many human endeavors benefit from less rigid planning, from emphasizing the human component of success, responding to change, iterating, continuously improving, and more.Like pumpkin spice, these bits of agile can be mixed into many things we do.Perhaps, too, like pumpkin spice, they can be overdone. A little pumpkin spice goes a long way. In some endeavors, so may a little agility.If you haven't already, try adding a little agility to your non-development or even non-work activities.It's worth a try. Just like I guess those pumpkin spice tacos may be, How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Converting Story Points to Money - Mike Cohn It's often worthless to tell a boss, client, or customer that a project will be done in, say, 142 story points.Even if stakeholders fully understand what a story point is, telling them how many points a project will take or cost isn't awfully helpful to them.These stakeholders are accustomed to hearing how much time and money a project will take. And it's important that teams and their leaders communicate with stakeholders in the terms those stakeholders prefer.Fortunately, it is quite straightforward to convert an estimate of points into money. Here's how. From Points to DollarsTo start, gather data on how much the team has been paid over a period of time. Ideally this should be at least a few months, but you could start with as little as one sprint.Next, divide total team compensation by the number of story points delivered by the team in that period. This gives you a cost per point.For example, suppose a team has been paid $100,000 over some period. During the same period, the team delivered 100 story points. Dividing $100,000 by 100 gives a cost per point of $1,000.This can then be multiplied by the total expected size of the project to give an estimate of the total financial cost. Getting Fancy (If You Want)You can get fancy with this calculation, if you'd like. Instead of using compensation as I did in this example, you might want to use fully loaded labor cost. As its name implies, this includes compensation as well as other costs such as benefits, overhead, and payroll expenses (taxes, Social Security in the U.S., etc.).A company controller can easily (and usually immediately) provide this as a percentage. It will typically be in the range of 25–40% added to compensation.You can get fancy by trying to adjust for seasonality or team size changes. However, that's usually not worth the effort: it shouldn't significantly impact the cost per point.Keep it simple.Clearly communicating expected costs with your stakeholders will improve your relationship with them. Everyone appreciates being communicated with in terms they understand. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Can Agile tools really teach you Agile practices, or are they just supporting players? Join Brian and Steve Spearman as they unpack the myths surrounding tools like Jira and discover why the process should always come before the tool. Overview In this episode of the Agile Mentors Podcast, Brian Milner and Steve Spearman debunk common myths about Agile tools, with a special focus on Jira. They stress that tools are not a replacement for Agile principles, and the process should guide the choice of tools, not the reverse. The conversation dives into how Agile tools can enhance transparency, why communication is key to effective Agile practices, and the importance of adapting tools to fit unique team workflows. References and resources mentioned in the show: Steve Spearman #43: Cultivating Agile Team Culture in a Virtual World with Richard Cheng #29: Influencing Up with Scott Dunn #71: The World of DevOps with Carlos Nunez Jira Miro Mural Trello SAFe LeSS Certified ScrumMaster® Training and Scrum Certification Certified Scrum Product Owner® Training Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Steve Spearman is a Certified Scrum Trainer® and Agile coach, passionate about helping teams thrive, drive business improvements, and master the art of managing change. With expertise in Agile training, scaled Agile, and leadership, Steve empowers organizations to navigate their Agile journeys smoothly and effectively. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have a very good friend of mine, a mentor of mine, Mr. Steve Spearman is with me. Welcome to the podcast, Steve. Steve (00:14) Thank you, Brian. It's great to be here with you. Nice to see you. Brian (00:17) Nice to see you as well. Yeah, Steve helped me out when I was trying to become a CST and I got to learn a lot from him, watching him teach his classes. So he's a pro. He's a CST, he's a coach and trainer and if you're interested, I recommend his classes. I think he's an excellent trainer and would have no hesitation sending anyone to one of Steve's classes. We wanted to have Steve on because we had this topic that got, actually, this is a listener suggestion. So we're always happy to take listener suggestions. And this is one that one of you sent in saying that you wanted us to kind of dive into and discuss a little bit about myths that are out there about Agile tools. So Steve, what does that mean to you? are some of the, is there a main kind of myth that you? you've heard more often than others about Agile tools. Steve (01:16) I think, Brian, the one we hear all the time, right, is this one that essentially Jira is Agile, right? And we're like, well, Jira is a very popular tool for people to use with Agile. It's might or might not be like most of us who do this. That may not be our favorite, honestly, but it is very popular for some pretty good reasons. So that's, I think, the most common one. And then just the idea that somehow it gets to the confusion people have about being a methodology and stuff, right? That essentially, if you just would implement the tool, then you'd be doing Scrum well, right? And that would be the important thing when in fact, I think most of our recommendations would be a little bit the opposite of that, right? Which is to come up with your own approach to doing things in Scrum and then maybe figure out a tool that helps you with that. Brian (02:06) Yeah, I agree. I've heard that quite often. And I've encountered organizations in my career where I'll ask them if they're Agile or if they are familiar with or no Agile. yeah, we have JIRA. OK, well, not quite what I was asking, but I appreciate the sentiment. But yeah, I mean, I agree. There's probably some mixed reviews on that as a tool. Steve (02:24) Yeah. Brian (02:36) I mean, personally, I'll say I've used it to run, you know, Agile organizations before. I'm not a hater of it. I think it's fine. I think it works. I mean, I don't know what your opinion here is, Steve, but people often ask me if there's a tool I recommend to kind of run projects and. You know, my standard answer is there's not one that I think is better and outshines all the rest. I think they all have their strengths and weaknesses and you just kind of have to tweak and adjust them to make them match, you know, your process. But that's the key, right? Is that process over the tool. Steve (03:17) Yeah. I've, you know, Jira I think is popular for a lot of reasons. One is, usually it's about half the per seat cost of a lot of the other ones. And so that for a lot of companies right there, that's that's a pretty big factor thing. I liked about it. Maybe similar to your experience, Brian was that if you're a little bit more of a techie, it's pretty programmable. You can go in and you could tweak it and you can make it do all kinds of things. And so that's maybe it's strength and it's weakness that it takes a little more investment, but you can do quite a bit with. Brian (03:47) Yeah, I agree. It is pretty flexible. The main thing I try to tell people who use it and are asking about, this going to be viable? Will it work for our purposes? The main thing I think they have to understand is the history of it. The Jira is really a bug tracking software. Well, let me be clear. It was created as a bug tracking software, right? Right. Steve (04:12) Yeah, ticketing system in general, yeah. Brian (04:15) Right, a ticket system. And when you know that, and then you get into the nomenclature and you look at the layout of how everything is within it, that makes sense. can see, cause you know, like the standard thing there is an issue, right? There's different issue types, but the standard thing is an issue. Well, that's because it was meant to handle support issues. Steve (04:35) Yeah. And also the, you know, we commonly use the word tasks, of course, in Scrum, not an official thing, but a very common thing we talk about. And Jira speak is subtasks. And that's just history again, of, know, where it came from. And, you know, a long, long time ago, you had to have a plugin to Jira to do Agile. It was originally called, I believe, Grasshopper many, many years ago. And then they ended up just calling it like Jira Agile for a very long time. And then as... Brian (04:57) Yep. Steve (05:04) it became a bigger and bigger piece of their market, they just kind of wrapped it all up in JIRA now, I think. Brian (05:09) Yeah, we both been around long enough to have been part of those days. So I remember those very well. Yeah, I mean, like I said, I think JIRA will do a fine job for you if that's what you're with. wouldn't, you some organizations using it, I wouldn't say, by all means stop and use something else. I think you can make it work. I think you just have to look at it and say, all right, I understand this is based on this. So now I just need to configure it and adapt it. really for the process we want to do. And I know from my standpoint, I've used it multiple times where when you configure it the right way, it will handle things the way that you, at least from my perspective, the way I usually think is the right way to implement it with a team or an organization. So it works. I can make it work. It just takes some tweaking. I guess for mine, but yeah, it's not Agile. It's not being Agile just because you're using Jira. Steve (06:11) Yeah, and it's kind of the good and the bad thing about tools. think people like them because, you know, I can assign people tickets and things like that, you know, and so like, you know, people, it's clear who's got things and stuff. That's also a weakness though, too, because it, you might say, all I have to do is assign it in the tool and I don't have to talk to you now. I just say, look, you, I signed you this ticket or something. And that's not great from my perspective. And then the other one is that when you, when you, change states and things in the tool. That lets everybody know where things are, and that's good, and it gives you tons of reports and things, and people like those. But it's also less visual than a lot of us are, which back in the day, we liked sticky notes on a board. I that was the thing. That was the thing. And so what I'm leaning toward myself a little more these days is tools like Muro and Mural and so forth that are very visual, and they're often sticky note-based kind of things. Brian (06:55) Yeah. Steve (07:09) And that allows you to do a lot of the stuff we used to do physically, but they don't have the same reporting capabilities. And so that's where we get these trade-offs that I think we're going to see with these tools. Brian (07:22) Yeah, I agree. I agree. Yeah. I'm, I'm, I'm the same way. And in fact, you know, when I said that earlier, someone asked me what my favorite tool is, you know, I said, my default answer is usually I don't have a favorite, but, if they push me, what I'll tell them is my favorite is just no cards or post-it notes, you know, like that's really, that's really what I, I have found works best. But, yeah, something like Miro or mural, I think is a, is a great, kind of virtual replacement for that. Cause it's just so open. and you can configure it however you want. It's not going to pull a report for you. You have to understand that. But it is the equivalent of having a virtual wipe. Steve (08:05) Exactly. And that's just, it's kind of a halfway physical feeling thing for our virtual world, which I think is helpful. Another interesting thing that I haven't played with a lot myself is that I know now in Miro, a sticky note in Miro can now be tied directly to a ticket in Jira. And so effectively you could have like the backend framework of Jira with a pretty front end on top of it or something is kind of how that looks like to me. So Brian (08:23) wow. Steve (08:32) I think that's got some promise maybe to give us both that physical thing that some of us miss while still having that reporting structure that a lot of our companies kind of want. Brian (08:41) Yeah, that's awesome. Yeah, that speaks to what you were saying earlier about that it's highly configurable. can make it do a lot of things. You just have to get into the guts of it a little bit. Steve (08:52) You know, another thing about the tool market here, know, Brian, I was just looking this up, not like I knew this, but apparently it's a $5 billion market this year, Agile tool, and it is projected to go up to 13 in the next 10 or 12 years. So it's serious money. And this is why there are so many players now, right? I mean, the number of tools out there now is just, I've lost track of them. I know it's easily 20 plus tools out there. Now there are... Brian (08:57) Haha. Steve (09:19) Certainly the most common ones that we think about, Jira is probably number one. Asana comes up a lot. Rally is a long time one that comes up quite a bit. Interestingly, one of our biggest ones from years ago that did such great reporting out on the network for us and great Agile materials was version one. It was a super, super popular one. Brian (09:43) Yeah. Steve (09:45) And when you look now, they are a fairly small player percentage-wise in the market. So there's been a lot of shifting here. And of course, Microsoft shops tend to go toward Microsoft tools. And so there's that factor that goes on here, too. So it's not trivial to figure out which tool you would want to use here. Brian (10:02) Yeah, that often drives a lot of even discussion in the classes, I know, from people who say, what do you, you know, they'll bring up a term like feature and say, what's, how does Scrum define? Well, Scrum doesn't define what a feature is, you know, like that's, that's a term that comes from your tool. And, know, that your tool might have a definition for it, but you know, Scrum doesn't. So, yeah. Steve (10:23) One of the challenges I think is also that because scaled Agile has become such a big factor these days, almost all the tools have adopted their terminology. so terms like epics and features and things, most of these come from scaled Agile. And if you're doing scaled Agile, that's great, right? If you're not, it can be a little confusing. So for example, I think it was, Mike Cohn maybe, who said that epic, he famously defined as being a story too big to fit into a script. That was sort of the definition of an epic. And now in most of the tools, an epic is something giant that you have a handful of in three months or something. So yeah, there is some terminology confusion out there now as well. Brian (11:16) Yeah, which may have all come from just the tools. You hit on something a little bit earlier that I had as one of my kind of common myths here around tools. And that was that these Agile tools replace the need for just the typical communication that we have. Because as you said, I can assign something to someone else. that way, I don't have to talk to them. I just put it in their queue. And it's there. And I think that's a huge myth here with the Agile tools is, you know, my, my, my goal with any kind of tool, whether it's a software tool or whether it's a, a template or something that I'm using for a specific thing, like story mapping or whatever, my, my goal for any of those things is that it drives conversation, right? That it is an encourager of conversation, not that it is something that takes away from or detracts. from conversation and communication. So I think that's a big myth sometimes is that people, even if it's unspoken, right, there's just sort of with some people an assumption that because the tool communicates and because the tool can communicate between people, I don't have to actually talk to anyone. And that's that couldn't be further from the truth to do Scrum well. Steve (12:33) I think it gets us to another subtle thing in the scrum that you know scrum that could say more clearly maybe than it does. But that is shown as a good pattern in our pattern site, you know, the one called scrumplop.org. The idea that we should swarm as teams, you know, is something that I think a lot of us feel is a really important concept. And swarming is this kind of strange idea that says you know, don't give everybody their own work item and then just say disappear, go do it, you know, good luck. Instead, we try to work more closely like teams on the same items, divided up, work together closely. And this of course involves a lot of communication, a lot of needing to talk to each other. And so sometimes people say, well, can we just send out a Slack message or something, you know, every now and then and say, hey, you know, I'm done with mine. You can, but I think it's sort of missing the the really cool back and forth of a true swarming culture where it's like, hey, is anybody ready to pick up a piece of code and run the testing on this one? I'm gonna move on to the next one. Swarming was this idea of doing things in short cycles and gets into issues of test-driven development and things like this. so none of the tools really help you with that concept at all. And they may even hurt you with it little bit, in my opinion. Brian (13:49) Yeah, absolutely agree. And I'm absolutely on board with you. I think that's such a vital component of it. I tell people in classes, you know, I know sometimes people get a little frustrated with sports analogies, but I tell them, you know, Scrum is a sports analogy at its core. You know, it's a rugby thing. the other thing I kind of think about is if you've ever gone to see, and I know lots of us have done this in our life, but you've ever seen a kid sport kind of team sport. If you ever stand on the sidelines of a kid's soccer or most of you out there, most of the world would say football. But you know, if you ever stand on a side of a field like that, what the coaches are constantly yelling at the kids is talk to each other, right? Communicate, talk to each other. And they recognize, you you recognize in that kind of a team sport how important it is to, you know, call for the ball or or just let people know where you are or where you're going. And that same thing is what we want with our Scrum teams. We want people to be able to just constantly talk to each other. So you're right. I think sometimes the tool might actually get in the way of that communication and just could create some communication problems. Which tool are we talking on? Which tool do I look for for that kind of a conversation or whatever? And it just can get lost in the shuffle sometimes. Steve (15:13) You know, the rugby analogy is such a core one for us, but it's getting to be kind of old history now because the whole rugby analogy came out of this original lean paper, right? Long, long time ago. And the reason they chose rugby, you know, is one of the reasons they chose rugby. Rugby is such an interactive thing. So unlike American football where, you know, you run down the field and you can, you know, you can only throw the ball once and then you run and try not to get tackled. In rugby, you throw the ball back and forth constantly. Continuous interaction and basically the guys from Toyota said look we got to learn to treat our teams like rugby teams When they're on the field don't be on the sideline yelling throw it to Brian You know let them figure it out themselves, and that's the whole concept of a self-managing team Which you know is a really big concept for us in scrum and one that a lot of companies struggle with Brian (15:54) You By the way, if there was anything being yelled with my name on it from the sideline, would not be throw it to Brian. It would be don't throw it to Brian. That would be the response. Yeah, absolutely agree. What else, Steve? What other kind of myths have you heard or do you commonly hear about Agile tools? Steve (16:24) I think one of them is the idea that there is a right tool because there are real pros and cons to all the tools and some of them are much more advanced than others and yet some of them are a lot more expensive than others. Some of them are tuned for people who work in Microsoft shops. Some of them are tied to particular tools like GitHub or something like that. So figuring out the right tool is a non-trivial exercise, I guess is what I would say. And especially if you're going to wedge yourself to a tool, I think doing some prototyping, some research. The good news is the vast majority of them have free versions. You can go out and try. I often get asked things like, are you going to teach us Jira in this class or something? And the answer is no. No, I'm not. It's just one of 20 plus tools. But the other thing is that The good news is tools are a lot simpler than Scrum and Agile are. Scrum and Agile are tricky, they're subtle, they're hard to understand. They're a lot about humans and interactions and patterns and these tricky things. Tools are relatively straightforward and there are free videos on how to use Jira out there. There's a public version of it you can go get and it's true for the others too. So anybody who's really looking for a tool, that'd be my recommendation. Go out and... Find a few of popular ones, go check them out, get a free version, watch some videos. I don't think you'll probably find you a class for that. Brian (17:54) Yeah, I agree. I mean, and if you do, know, you know, again, don't want to make this sound like we're only talking about Jira, but I know for things like that, I've seen, you know, meetup groups that are dedicated to those purposes that you can find on like meetup.com or other things where you can, you know, maybe go once a month or so and learn something about it for free. So there's lots of stuff like that that's out there. But yeah, I absolutely agree that, you know, As I said, I don't recommend one specific tool. And I think the thing that's kind of really important there when you're selecting a tool is to know what your process is first. Don't get the tool to set your process, find what your process should be, and then find the tool that's going to fit with that. It's the whole individuals and interactions over processes and tools. We don't want the tool to drive what we do. And unfortunately, I've been a part of several organizations where, hey, we use this tool and the tool only works this way. So that's the way we work, whether it's right or wrong for us. And that's just a terrible way going about it. Steve (19:03) Yeah. And unfortunately, most of the tools do force you to some degree into their approach, right? Because there is a struggle, I'm sure, for toolmakers between you could make it completely general, like here's some sticky notes, just go do whatever with them, you know, which is kind of what you do with a Miro or a Miro board. But most of them have tried to make it more, you know, you do this and then you do this and then you do this and it kind of leads you through it. And that seems like it would be helpful, right? But at the same time, it means they've already decided that the right sequence is to do this and to do this and to do this. And so just got to watch out for when is the tool prescribing your approach and when is it there to facilitate your approach. Brian (19:50) Yeah, I agree. I'll tell you another one that I've heard quite often that I always kind of makes the hair on my spine kind of stand on end is when people seem to take this approach that the Agile tool itself is going to teach them how to become Agile. You know, it's kind of akin to the idea of because we have Jira, we're Agile or some, you know, fill in the blank or whatever tool it is that you would be using. But yeah, I've seen different teams or organizations that take that approach of, well, we're buying this software. And so we'll learn by using this software how to be Agile because it's an Agile tool. It's an Agile software. So everything we need will just be, we'll come by osmosis because we have this tool in place. yeah, I found that to be just a terrible approach. If you don't have some kind of a some guide, right? If you don't have somebody to guide you through that in any way, shape or form, then you're lost in the wilderness. You just don't have anyone to help you find your way. And the fact that you have a tool that could be useful doesn't mean it's going to teach you how to be useful, right? You have to know, knowing Agile is not knowing the tool. Steve (21:11) It's like, imagine going to a Ferrari dealer and deciding you're going to buy a Ferrari. And you've driven a Honda Civic, so you feel pretty comfortable with driving. And they give you a 10-minute overview of the dashboard of the Ferrari that you just purchased. And they say, I hear you're planning on racing professionally next month. Good luck with that. Brian (21:17) Right. Steve (21:37) And because I can sort of drive the car, I can therefore win races, you know, at the, no, right? No. So now we both are going to be a little biased here as trainers, obviously, but I think we pretty strongly feel like without somebody to help guide you through the subtleties of things like Scrum and Agile thinking, you may let the tools dictate and that's not the intent at all. It should be your team comes up with what makes your team be amazing. Brian (21:48) Right. Steve (22:05) And we own our own processes in Scrum, right? That's a key concept is that Scrum tries not to dictate processes and it wants you to continually evolve them. And so even the thinking that says there's a right way to do it is actually incorrect Agile thinking. so, yeah, tools are not gonna be a lot of Brian (22:24) Yeah, I agree. We might be a little biased because of what we do, but you know, I like your analogy. I'll give you another one. if you are just because you buy a parachute doesn't mean you know how to skydive, right? And no one would would buy a parachute and think, I know everything. Just I'll just use it and I'll learn how to do it because I'll jump out the plane and you know, I'll learn how to skydive. Well, no, you go through training. figure it out, you probably do a lot of tests and things, so that by the time you get up there, you know exactly what you're doing. you've gone through all the safety checks and all those other kind of things. Nobody would see those things as being synonymous, but somehow we do that in the Agile community sometimes, as we see the tool as synonymous with knowing Agile. Steve (23:12) It's a really good example, though I like the parachute. I have never parachuted because I find it terrifying. But if you were going to be a skydiver, this is an area where there is a high cost of failure. It's like one of these things where a certain kind of failure you can only do once because you won't have a second opportunity. And so one of the things that is kind of an integral idea in Agile thinking is that we like to make Brian (23:18) Neither have I. You Steve (23:41) experimentation and failure inexpensive. And so one of the whole concepts of why we often encourage things like short sprints and scrum is the idea that we want you to feel free to experiment with your processes and to make mistakes. And I'm sure many of you out there have heard the fail fast thing we say all the time, right? And all of this comes out of this mindset of making failure affordable and learning part of the culture. And so all of that is very different than any of these kind of instruction-based follow a tool sheet, follow a standard methodology of Agile or something. None of that is really the right thinking according to the way the Agile Scrum people see the world. Brian (24:26) Yeah, I agree. Any others that have crossed your path that you would call out? Steve (24:33) You know, it's really hard to avoid the thousand pound gorilla here, which is safe, because safe has so dictated the tools and things that you just have to think through that. I don't want to get us off into scaling, because that's obviously another very large conversation of its own. I have come to think of safe this way. that scaled Agile is as Agile as many large companies can tolerate. Which is to say, it's not my favorite, but it is very prevalent out there. And so, you know, in some cases, you're not going to have a choice, right? Your company will have dictated a thing, whether it's safe or whether it's whatever it is. And just be aware that that decision is also reasonably tightly tied to these tools and things because... You know, you can get a really nice lightweight tool like say Trello, which is, you know, even free sometimes still. And that can be perfectly acceptable in, you know, nice small scrum team environments. But if you're going to do, you know, giant, you know, release train planning exercises, and you want the ability to put all this stuff into tools, then that will constrain you to a certain class of tools. Now it's a lot of them these days, but just be aware that how you choose to approach this and how heavy of a method you use. will also impact your tool choices. Brian (26:00) Yeah, I agree. I don't want to get, I know we're not going to dive off into the pros and cons of safe, but the kind of picture in my head that I always think about with safe is it's kind of like one of those Swiss Army knives that has a million different blades and attachments and things in there. It's designed to solve any possible problem. that you could encounter in that arena. you know, just like when you use a Swiss Army knife, you don't open all of them up and say, all right, well, I got to try to use them all at once. You find the one that you need and you use that one. So I don't think it's a problem to have the choice to use these various things. And when I've talked to really, you know, lifelong, safe trainers that really are successful with this, I find a similar attitude from them that it's not intended for you to have to implement every component. It's intended for you to find the things that fix the problems that you're encountering and then implement those things. And if you start to encounter other new problems, well, there's other parts of the framework that you can implement then that will help solve those issues for you. And I think that's one of the mistakes people make with SAFe sometimes is that they just You know, they take the whole, it's all or nothing. And while Scrum does say, hey, you have to implement all of this or you don't get the benefits of it, SAFe, I don't believe says that. At least I haven't heard trainers say that who teach it. So, yeah, yeah. Steve (27:43) It's more like a smorgasbord effectively, right? know, if you know different choices and maybe it's worth saying a word about why that is compared to because Scrum tries so hard to be a minimalist framework that it's sort of like saying, you know, I could choose not to eat vegetables and you know, that could be a good choice for me and the answer is no, that's not a good choice for you it turns out. You know, so Scrum, because it tries to tell you so little, it's basically telling you the stuff that is basically essential. You you just can't get along without it. So it's a super minimalist framework. Some of you, I'm sure, are familiar with what happened in the last version of the Scrum Guide, where, you know, typically, like with SAFe, when they add a new one, it gets bigger and bigger and bigger over time, right? And they add more and more details. And that's what people love about SAFe, right? You can go open up a page. and click on a keyword and open up another massive page of exactly how to do everything. And Scrum has taken the exact opposite philosophy to make it the most minimal framework they could. And they actually went from 18 pages to 13 pages in the last version of the Scrum Guide, taking all of the advice out, basically. And so we're just looking at two very different philosophies here. So Scrum is a minimalist framework. SAFe is the... I guess the Swiss army knife, if you will. I would like to say one comment about a Swiss army knife. I used to carry those many years ago, but essentially you have every tool in them and none of them are great, right? So every one of them is basically a tuned down version of the tool. So yeah, there's a corkscrew in there. It's not a very good corkscrew. And yes, there's a screwdriver in there. It's not a very good screwdriver. Brian (29:06) Ha ha ha. Steve (29:29) So I think sometimes over time we start to learn that you should have the right tool for the right job and not try to get by with the Swiss Army. Brian (29:38) Yeah, always whenever I saw, you know, whenever I would see a Swiss Army knife that would have the the kind of saw component of it, I always think, you know, it's it's it's it's, you know, two inches, three inches long. What kind of tree am I going to saw through? Steve (29:53) you have to be desperate, right? This would be like, I'm cutting my parachute cord or something, but. Brian (29:57) Right, exactly. Exactly. Well, I'll throw one more and then we'll we can call this. But there's one that I've heard that I just thought was I don't hear this as often, but I have started to hear it more. And that's just sort of it's kind of an attitude. It's this attitude of, hey, we're having a problem with and seems specifically around transparency. Right. The team is not being transparent. We're not having much transparency into how the work is going on. And so sometimes I've heard people kind of take this attitude of, well, you know, we're gonna implement this tool. And so by default, we're gonna increase our transparency, because now we're using this tool. And I would caution people on that as well, say that that's not true at all. You know, it's the old phrase we used in computers, you know, way, way back when I was in elementary school was garbage in garbage out. And I think that applies to our tools as well, you know. We can get greater transparency through a tool, but it takes the right input. It takes the right effort. And you could still have the attitude of, I'm going to obscure the way that the work is really happening and do that through any tool. So the tool itself, I don't think it's going to do that. The tool could help you with it, but you have to deliberately seek that out. Steve (31:21) You know, I, it's such a mindset for me, this concept of things like transparency and how that relates to how we work as a team and swarming concepts and all these things kind of come together to make scrum a really an effective thing. And the problem sometimes is when you try to force things, it has the opposite effect. I'm, don't disagree with the scrum authors very often, but I very much do with what they did with the daily scrum, you know, and the daily scrum. used to have the three questions, And the three questions, you know, what did you do yesterday? What am I going to do today? You know, do I have any impediments? And then they made it longer. They added more words to it to try to clarify things, which was just more structure effectively. And then finally, in the last version of the Scrum Guide, they threw out the three questions. And I was really happy to see those go. because they sounded like a status report. And so guess what was happening to most organizations? They think of the Daily Scrum as a status report, which developers hate. And now as soon as there's this status call, then the managers are talking and they say, hey, did you hear there's a daily status call we can come to? And now they start coming to another meeting. And now you have completely destroyed the concept of this really simple meeting, which was effectively just to let team members coordinate their plans for the day. It's kind of a swarming based thing. And so it makes beautiful sense once you understand that, but it's misunderstood 90 % of the time because it just sounded like status. Brian (32:55) Now, but hey, pass the plate, because I'm a member of that church. I agree with you on that wholeheartedly. I've always said that, you know, I think it's just one of the things I try to tell people to come through classes. Hey, Scrum Masters, if you don't remember anything else about these events, right? If you forget, you know, six months from now, what the exact time box is on something, I'm not as concerned with that. Make sure you understand the purpose of each one. Make sure that you embed that and print that in your memory. I know what each of these meetings is there for, why we are meeting in that situation. And if you know that, then I don't care about the format. The format will flow from that, but we're accomplishing this purpose and we're gonna figure out the best way to do it. Steve (33:42) Yep, and we can even take that back to the tools and say, can make most tools work, right? As long as you get the freedom to use it as you, as a team, see fit. You know, one of the guys, the guy who created the kind of the opposite end of the spectrum scaling approach, Craig Larmann with LESS, he says, why do you need more than just a shared Google Doc to do everything? You know, why couldn't you just have your, you know, all your stuff up there in a spreadsheet and, know, good enough for what you needed to have visible and you can generate a few reports and maybe that's all you need and maybe you don't need a heavy tool. that, you know, so there's a spectrum of possibilities. Brian (34:21) Yeah, I mean, when teams started out, there weren't any tools, and that's what everyone was using, was things like that. So, yes, it's entirely possible. Very cheap. And you don't have to be a big organization. You don't have to have a massive budget for software. can use the tools available to you and get by very well. Well, this has been great. I really appreciate you taking the time, Steve. I love this discussion, and I hope that... Steve (34:43) Absolutely. Brian (34:51) For our listener who suggested this, that we kind of hit the nail on the head and gave you what you were hoping for in this one. But yeah, when it comes to Agile tools, Agile should drive the tool, not the other way around. The tool shouldn't drive how you do Agile. And I think that's kind of where I would sum it up. Any last thoughts? Steve (35:10) So if I was going to quote Craig Larvin one more time here, less is more sometimes. And so the concept of minimalism and being more about how you and your team work together and how your meetings work and how you respect each other and how you learn how to work effectively together, way more important than your tools. ideally, let your approaches dictate the tool. Try not to let the tool dictate your approaches. Brian (35:40) Awesome, yeah, completely agree. If you've been listening to Steve and feel like, I really clicked with that guy, I really resonate with the ways he's speaking on this stuff, I encourage you check out his course schedule. You can find that at the Scrum Alliance website and see what courses he's teaching and sign up for one. Because as I said, Steve's an excellent instructor. So Steve, thank you so much for coming on the podcast. Steve (36:04) Thanks, Brian. It's been a pleasure to be here with you.

The Surprising Cost of Bad Estimates - Mike Cohn Bad plans lead to many well-known problems. Teams deliver later than expected. Or the budget is blown by adding people in the hope that will help. Sometimes a deadline is met but by dropping important features. Or the deadline is met by team members working overtime, causing burnout, frustration, and usually introducing bugs. Inaccurate plans frustrate both team members and stakeholders. But one of the worst, and perhaps most overlooked, impacts of a poor project plan is that the team loses credibility with its stakeholders. As an example of how poor planning affects credibility, I've got a friend whom I'll occasionally meet for lunch. He's always 5 to 10 minutes late. If he emails me today and suggests meeting at noon, I'm going to arrive 5 minutes late myself. I no longer trust him to be on time. His plans just aren't reliable. And that's OK because it's just lunch. But the credibility gap caused by unreliable plans is much worse on projects. Consider a team that is either consistently late or always has to drop scope to meet a deadline. The project stakeholders ask this team if they can deliver a new project in 3 months. Team members think about it and decide they can't deliver it in 3 months, but could do it in 4 months. When the team members tell the stakeholders they need an extra month, the stakeholders don't believe them. Why should they? The team has been consistently wrong on all prior projects. At this point, stakeholders may tell the team to do it in 3 months anyway. And why not? If a team never meets its stated deadlines, stakeholders may reason that they'll stick with the 3-month deadline to apply some pressure, which has limited effectiveness. (And like me with my friend, they might also quietly expect it to be done later, in perhaps 4 months.) Here's the bottom line: stakeholders will not treat a team as an equal partner if the team consistently provides bad plans and inaccurate estimates. Credibility is such an important factor that I include it as the first of four reasons agile teams estimate product backlog items in the first place! Consider how things may have played out differently if the team instead had established a track record of providing decent plans. Note I said decent. Plans don't have to be perfect to be reliable. When a consistently decent team tells stakeholders a project will take an extra month, stakeholders are likely to engage in a conversation about options to meet the desired, earlier deadline: Would it help to enlarge the team? Is there a feature or two that could be dropped or deferred? Would it help if team members were allowed to focus solely on this product instead of also supporting some old product? When a team has a track record of presenting reasonably accurate plans, they will be treated as equal partners by the rest of the organization. Many teams try to solve the problem of inaccurate plans by padding their next plans. This usually makes things worse as the team now has two things to estimate: The plan, and How much to pad the plan When stakeholders call the team on padding the plan, the padding is often removed unless team members can present solid logic and evidence for the size of the padding. A better solution would be for team members to assess why their plans have consistently been wrong. Sometimes the problem is due to poor agile estimation. If that's the case, there are many things team members can do to improve estimates of story size. I'll share just one technique now that's especially helpful for teams who chronically underestimate the amount of work involved in a particular product backlog item. It's called unpacking. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

How does Agile fit into the fast-paced, high-stakes world of game development? Clinton Keith, author of Agile Game Development, spills the secrets from his time working with some of the top studios in the industry and explains why adapting Agile to gaming is both a challenge and a game-changer. Overview In this episode of the Agile Mentors Podcast, Brian Milner and Clinton Keith dive into the unique dynamics of Agile in the gaming industry. Clinton shares stories from his decades-long career in game development, explaining how Agile methodologies have evolved in the industry and why traditional approaches often fail. They discuss the impact of deadlines, the influence of digital distribution, and how finding the "fun" in games is crucial for successful development. Clinton also provides valuable insights into modifying Agile practices to better fit the gaming world and the critical role leadership plays in fostering a productive Agile culture. References and resources mentioned in the show: Clinton Keith Agile Game Development: Build, Play, Repeat by Clinton Keith Mike Cohn’s Better User Stories Course Accurate Agile Planning Course Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Clinton Keith is a seasoned game industry veteran turned Agile coach and author of Agile Game Development, 2nd Edition. With 25 years of experience as a programmer, CTO, and production director, Clinton now helps creative teams and studio leaders build better games through effective Scrum, Lean, and Kanban. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. Glad to have you back. We're here for another episode of the Agile Mentors podcast. I am with you as always, Brian Milner. Today, have a very special guest. A very special guest was the word I was looking for, but somehow it came out wrong. A very special guest that I'm very excited about having with us, Mr. Clinton Keith is with us. Clinton Keith (00:17) You got it right the first time. Brian (00:23) Welcome in, Clinton. Clinton Keith (00:25) Hey Brian, thank you so much for the invitation. Brian (00:27) Yeah, very, very psyched, very excited to have Clinton on. Clinton is a CST, but more importantly, he's the author of a book called Agile Game Development. And he has been in the video game industry and working with different video game makers and production houses and things for a long, long time. And he told me he's been a video game maker since the seventies. So I said, well, that's great. Cause I've been a video game player since the seventies. So I'm sure we could cross. and have some overlapping stories here. Me from the consumer side. I wanted to have Clinton on because he's got this unique perspective of really how Agile has developed and how Agile is kind of implemented and works well in the gaming industry. So let me start with just asking you, Clinton, when you work with gaming companies and they are interested curious about Agile, what is sort of the main holdup or the main objection that they present to you when they first start working with you? Clinton Keith (01:37) Well, it's changed. mean, I've been an independent trainer CST since 2008. And back then it was like, this agile stuff doesn't, know, this won't work for us or it won't work for our role playing game or massively multiplayer online game. might work for these small games. But I think since then, what you've seen is there's just such a lot of bad implementations. We call cargo cult implementations of Agile, where we think that standing around in a circle and answering three questions a day is going to result in some productivity fairy flying over our heads and sprinkling this methodology dust on us and wonderful things will happen, where there's a discipline and a change in culture. And so people have seen a lot of poor agile implementations. But at the same time, continuing on with more traditional approaches as games get larger, teams get larger, projects get bigger, that they're saving the worst failures on not adopting a more iterative approach to game development. Brian (02:54) Yeah. Yeah. Yeah, I mentioned that there's probably a lot of objection. There's a lot of the companies that kind of take that fixed scope, fixed schedule kind of approach to doing work and kind of think maybe Agile doesn't align to what we do or our industry or how we do things. Hopefully I'm not putting you on the spot too much, but do have any interesting stories or examples of things like that where you've worked with a company that maybe was just very, very resistant that you kind of, that they kind of turned around in the time you worked with them? Clinton Keith (03:36) Well, think one of the more clear examples and, and, know, I, being a project manager and someone who's a, started as a programmer and ran studios, you know, and we ended up shipping successful titles on schedule, on budget. that, when I work with teams that have true deadlines, you know, these are teams that, especially sports titles where. You know, if, you know, Madden football misses the launch of their next title at the beginning of the NFL season, they're going to lose half their sales as opposed to, you know, being told it's so called, have a deadline, but you know, that just to put pressure on the team. so when you have that kind of deadline, a do or die deadline, then it gets them serious about doing things like prioritizing scope. Brian (04:11) Yeah. Yeah. Clinton Keith (04:30) We're saying, it's like, hey, we have this new engine to render crowds in the stadium and this is going to be beautiful. And, and it's going to look like these are real stadiums filled with people. They're less willing to take that risk if it has to come out on that specific date. And so we prioritize scope by saying, Hey, we have 32 teams, you know, it be baseball or NFL or whatever. have so many stadiums, we have rosters, we have uniforms that have changed from year to year. Those are things that we have to get in. The things that are like a new technology for mud on the uniforms, well, we can take a different approach to that and say, those would be nice to have, but we're not going to bet our schedule on that. So those were the teams on what we call AAA games. They're games that have large staffs, huge budgets, hundreds of millions of dollars. They kind of learned those lessons early on and it really became proof that an agile approach of saying, prioritizing scope and managing scope and delivering things that work and that show increased value in terms of player fun on iteration, iteration basis was really the best approach to hitting those targets. Which again is really difficult for teams that really have those so -called hard deadlines. but was still with a fixed scope, that they want all those things and at the last minute, end up compromising quality, get those all the, to hit all those goals. Brian (06:06) I'm kind of curious about kind of the teaming aspect within the gaming industry because it seems like, and maybe I'm wrong here, so correct me if I'm wrong, but it seems like more than some of the other industries in software development that it's a little more of the mercenary kind of attitude of, you know, kind of have the gun for hire that you bring in or guns for hire that you bring in to do some project or some game and then... then when the project wraps, they're gone. People float from place to place. Is it tough to generate, have teams go through stages of formation in that kind of environment? Clinton Keith (06:46) Right. Yeah, no, it's less so with now that we had mobile games, these mobile platforms come out where a lot of most of the effort actually is maintaining and building a live product and growing it over time, where it's like, instead of saying, you know, on traditional large games, we're going to spend two years with no customers, no feedback. We're going to build this huge game and then launch it all at once on a disc or on a cartridge. and then cross our fingers. And with that approach, usually with game development, the traditional approach is to have a documentation phase, a planning phase, a design phase, and then a pre -production phase where we build all the mechanics. And then a production phase where we create all the levels, build the storyline, something that people can play through 20, 30 hours. And then at the end of it, alpha beta phase where we fix all the bugs, make it run fast, find, know, make it fun and polish it and then get it out the door. and in terms of staffing, like what you described was very, yeah, it was the big challenge because in pre -production we, you know, we might want 50 people, 30 people. but then when we're building all this content and building the worlds, then we're growing to a couple hundred people and then you ship it on the disk. What do you do with those 200 people that are sitting around? And that's still on large games. You know, I work with some teams that are over a thousand people developing the game. And they're trying to address that problem by having, you know, large publishers or acquiring studios. And they'll have up to half a dozen studios in various locations around the world working on that, especially on building those worlds in that, that production phase. But then that introduces the problem of communication and overhead and time zones. And yeah, it's a very challenging problem that when I started in the game industry, know, a AAA game took less than 10 people, you know, sitting in a single room. Brian (08:53) Yeah, kind of, it's such a different paradigm now than it was. And the industry has changed so much, it seems like to me because, well, like for instance, my oldest daughter is a pretty avid gamer now as well. And when we were helping her get settled for her second year of college, we had to replace her monitor, know, so she had something to play on. And we walked in the Best Buy and I tried to explain to her that, Best Buy used to be a mecca for gamers. I remember going there regularly to stroll through the shelves of the boxes and kind of see what was on sale. Now, I can't remember the last time that I bought a physical media for a game. It's all downloaded. How has that changed just the process of developing games? I'm sure that's, previously when you had to have the gold disk version or whatever that was released. I'm sure there was much tighter timeframes, right? Is it much different now with being able to update over longer periods of time? Clinton Keith (10:03) Well, just from an Agile perspective, it's gotten much better. You know, we introduced Agile to our studio back 20 years ago, over 20 years ago. And, you know, back then, really, the retailers dominated the industry so much in terms of you had to sell Walmart on the game you were proposing to make, which meant that you had to write the 300 page document that they would approve. Brian (10:25) Yeah. Clinton Keith (10:32) before you even knew it was fun. It's even worse with some of the larger first party companies that own the consoles, that they would say, well, we have a slot for making this type of game, so you have to stay within that slot. And at the end of it, we will determine how many cartridges that we will manufacture for your first release. And so it's very restrictive in terms of how much change we could introduce into the game over the course of development and say, well, the game that we're making is kind of boring. But that's the agreement that we made with Target or Walmart. And so we have to kind of stick with that game. Whereas now you can get early versions, like in Steam, for example, early release. And you can start to get metrics or that if you're a a game that's already out on a platform like iPhone, you can introduce the idea of a new mechanic to a limited number of users to say, it's like, hey, let's release a version of this mechanic to people in the state of New York and see, observe how they're playing it, measure how they're playing it, how many times they come back to it, and then use that information to tweak the next two week iteration or release dozens of different versions of our game you know, to millions of people and see which version that's out there in the wild is getting more response. So we have the ability to, you know, be much more agile and actually measuring what our customers, our players are doing with our game. Brian (12:07) That's so interesting. You spoke earlier about kind of like the AAA games with like sports games and how they have much tighter deadlines and they're, they kind of, there's a big, big hit to them if they miss that deadline. What about the opposite? What about the teams that don't have those harsh deadlines? And I would imagine there's an entirely different problem for the product owners of just good enough. how do you... How do those product owners determine, yeah, we have enough or this is in good enough shape that we can release it and we can patch things later? Clinton Keith (12:44) think one of the biggest problems you see when you don't have a deadline is this. There's this famous quote, I forget the exact wording of it, is that really tight deadlines, know, kind of restricted, know, restricted, to call it use the word resources, but in terms of money and schedule and things like that, or how many people you have working on it, really focuses you on delivering. And this is something that is a problem for AAA games with no serious deadline is that to say it's the, get these incredibly vast ideas that take years to really show the benefit. And I had this big light bulb moment in my career. I was, I was, I did a lot of racing games really in my career and I was on a game. that had a racing mechanic is based on a movie like what some of the Bourne movies where you have like a 15 minute racing mechanic, know, chasing in the middle of the movie. So late in the development of the game, we had a little bit of extra time and our publisher said, hey, can you throw in like a very short 15 minute car chasing and with police chasing you through an open city. Now that mechanic, police chasing you through an open city, used to take us years to develop with artificial intelligence, know, with police chasing you through crowded traffic streets. And even after years of development, it didn't quite work right. The police would crash into everything and drive on walls and we couldn't get the physics right. You know, we're on a PlayStation or Xbox. You know, you couldn't spend a lot of AI effort, artificial intelligence, on getting that just right. So, but we only had like a month. And so we're sitting around thinking, what can we do? How can we get police chasing us? And so we started asking ourselves questions that we never did ask in the past. Like, why do we have police? You know, why do we have police chasing you? And the answer was that, well, it's to make you drive fast. You know, if you didn't have police chasing you, you know, it's a boring game. And so all we did was we just, instead we just had Brian (14:47) Mm. Right. Clinton Keith (15:02) We just monitored how fast the player was driving. And if he was driving a little bit too slow, we'd start playing a siren sound. They kept driving slow. started playing flashing lights off the geometry of the buildings around you, blue and red. And then if you continue driving slow, we just played a video of you being arrested. And that took like a couple of days instead of a couple of years. And when we focus tested it, pretty much, half of everyone thought they were really being chased by the police. The other half said, I thought I was being chased by police, but when I looked in the rear view mirror, I didn't see any police. And so we just took out the rear view mirror, tested it the next night. Everyone thought they were being chased by police. And we're like, I guess, and it was actually a better result in the two years of trying to get artificial intelligence right. And so the big light bulb moment was, just like having, Brian (15:53) Yeah. Clinton Keith (15:56) a short deadline on showing something of value led to people making better choices from the player's perspective, not this challenge of, what can I do with artificial intelligence over the next two years? So I think that's part of the big challenge with these big, huge games of saying it's like, if there's not a payoff, if you can't see value, and this was an early lesson I learned, Brian (16:11) Yeah. Clinton Keith (16:24) working with Nintendo Japan was the guy that made Mario and Donkey Kong. We worked with him directly, Miyamoto. He always had this thing. It's like, find the fun fast, show the value of it. And it always stuck with me. And so when you have these short deadlines, you want to encourage the teams and the product owners is judge the game, not what you see in Brian (16:40) Yeah. Clinton Keith (16:49) with the potential in two years. Judge your vision of the two years against what you're seeing every other week and adjust your expectations. Don't fall in love with your vision. Brian (16:59) That's so interesting. So I kind of want to dig into this. This is an agile podcast, obviously. And we have lots of people from different walks of life and that they're implementing agile in different ways. And it's always interesting, I think, for people to hear how things kind of fit in other realms, right? In other kind of industries and how that changes a little bit industry by industry. So I'm kind of curious when you are talking about agile and Scrum and in a gaming game development environment, what are some typical kind of modifications that you recommend or that you've seen that are needed or work well that are specific to the gaming industry? Clinton Keith (17:44) So as I mentioned, a lot of teams, even Agile teams that are truly Agile, like the sports titles, we still have that separation of discovering what new mechanics we want to put into the game and then building all that content, your stadium. So let's use sports titles for example. Let's say we do alter how we draw or render the stadiums. And we're making much more beautiful, more detailed stadiums because we have a new platform that can draw 10 times as much like a next generation PlayStation or Xbox. So we still want to come out with the new sports title at the start of the season. So we'll, we'll do more of our risky exploration of stadiums and what it's going to take to, to render these stadiums. and how many polygons, how many triangles we're going to use to build these stadiums and how much it's going to cost. Because we do have 32 stadiums. We do have a budget. We do have so many artists that can build these stadiums. So we have to figure that out ahead of time. And then, you know, once we figure that out and say, all right, we have, you know, we've built an example stadium. This is an example of what we want to ship at the start of the season. Now we have to build all the other 31 stadiums to that quality. And we've judged the risk and the cost and the schedule and how many people we have to the artists to build those things. And then we go into that production pipeline with those studios. And that's where, you know, it's like the scrum every two weeks model doesn't quite work. know, a stadium might take. 21 .2 days to build. And it's a pipeline of handoffs of things. Somebody doing the concept art for the stadium and then building the geometry for the stadium and then lighting it, you know, and all the audio effects. And so it becomes more of a production factory pipeline where practices like Kanban and lean come into play. That still have those underlying values of getting things through the pipeline as quickly as possible, continually looking at how we can improve that pipeline. And then judging instead of how much we can get done every fixed time box is judging how long that stadium takes from concept to in -game and trying to refine that to get improvements in the quality of the stadiums and the productivity of that entire pipeline. which leads to, you know, things that we see in Scrum is disciplines talking to each other and improving how they work together. Brian (20:32) Yeah. I would imagine the culture, like there's potential culture clash kind of things here with Agile in the gaming industry. Like one of the things I was thinking about is, you find it's a little tougher to get buy -in on a concept like working at a sustainable pace? Is that something that's in the gaming industry, people... Because I've seen a lot of... I've been around some small companies that are working on gaming, and they seem to work all the time. It's like late nights, weekends, it's just like it's non -stop. Is that kind of a difficult concept in the gaming industry? Clinton Keith (21:18) Well, mean, the gaming industries had quite a few scandals in terms of crunch time. And a lot of that has to do with not seeing that actual game until the end. As I mentioned, it's like we have these in pre -agile development, still goes on quite a bit, is that, we write this big, huge document up front. We get the buy -off on the stakeholders. We go off and the engineers go off over here, the artists go off over here. And then towards the end of the game, when we finally get all the elements of a story together, we can first start to play it. Then we start to get it so instead of it crashing every two minutes, we're starting to get the game playable and we're out of time. We have to ship this game in three to six months. It's not fun. It's a disaster. Brian (22:06) Yeah. Clinton Keith (22:13) and then what, unfortunately what happens is we've, we put that accountability on the developers and say, well, now you, and, know, as, as a studio director, pre -agile, I was guilty of this as well as to say, Hey, we got it. We, we, we have no choice, but to come in here seven days a week, 10 to 12 hours a day. And, and as it, yeah, as a team we'll, we'll, you know, we'll, we'll get this thing done. And it destroyed. destroyed marriages, harmed families. I mean, I went through that. didn't see my, one of my newborns for the first three months of his life, pretty much, except when he was sleeping, when I came home late. And it simply doesn't, I mean, it's harmful primarily to the working life and these people that leave the game industry, but it's also harmful to the game is that, you do whatever it takes to get this Brian (22:45) Ha Clinton Keith (23:12) terrible game across the deadline that you were very passionate about in this first couple years of development. And we've seen disasters, even in recent history of games being released that, you know, it's just unplayable, but they had to get out for a deadline and they've spent hundreds of millions of dollars. And they've just felt like, well, nowadays we can patch games, you know, and, and, and, you know, it, it, it, it kills them from a financial point of view. Brian (23:41) Yeah. Yeah. It's so interesting. you know, I think this, to me, this is where it kind of, it is so relatable to, to anyone who's, who's trying to do this kind of work. Because I think there that we've all had scenarios and situations where, know, as an agile coach or trainer that we've, we've, you know, we've been up against a constraint of some kind. We've been up against something that is not really the way we would. hope would be the way that the organization would operate or that the team would be run. And we've had to make those compromises in order to continue the work and continue trying to move that organization forward. So I'm kind of curious, I know there's probably lots of people listening who are in those situations and maybe even kind of some self -doubt there about, hey, am I really? Am I really doing this the right way? And am I kind of a sellout and that I'm giving in to the management and how they're making us do this? Would you have any advice or anything that you would say to people in that position that could maybe help them kind of navigate that? Clinton Keith (24:56) I mean, yeah, think, I mean, a lot of it is, is, it's a tough question to answer because, you know, a lot of it is, I mean, I, I've been in that position myself where, yeah, I was promoted to studio director and my first studio. It's like, okay, now you're responsible for all these games, seven games in development. And, you know, I committed, I said, all right, we're going to stop doing stupid things. Which means like going to a team that's working very well and saying, this other team, they're in a bad place. So I'm going to take half of your team and move them over there. You know, the old Fred Brooks thing is just like, you know, it's like, Hey, you know, it's like, you know, we're going to double their staff, you know, which is going to make it even worse for them, but it's also going to harm you. We're going to stop doing those things because now I'm in charge. I've been through that. I've run individual games and I know the impact. of what that does. And so I wasn't in the job more than two weeks before the CEO came in and said, hey, we don't have enough money to pay payroll this Friday. And I went into a panic because I was like, I just got promoted to a studio that's going out of business. I go half the people are going to leave if they don't get paid this Friday. And he goes, well, just calm down, relax. You know, what we're going to do is we're going to get a loan because Brian (26:10) Yeah. Clinton Keith (26:21) but we have to accelerate this milestone payment. I need you to, we need to start a new team, an eighth game. And I was like, well, we don't have the people for it to start an eighth game. It says, well, you need to go out to the teams and take people from their teams and populate a whole new team so we can get this payment from this publisher who wants to start a game. And it was such a bad idea to do, but I couldn't go to the teams and say, Brian (26:46) You Clinton Keith (26:49) Hey, I need to take some of your staff so we don't go out of business. I just said, you know, it's like, Hey, we have to take some people off your team. And they're like, you very publicly said you weren't going to do stupid things and here you are. You know, so I think, you know, as part of it is it's, it's, it's the culture, it's the leadership. You know, I started about five, six years ago, starting to do leadership training. Yeah. And because it's like, you know what? I keep seeing these. Brian (26:55) Yeah. Clinton Keith (27:19) You know, the team's adopting these practices, but the leadership not knowing what to do with this transparency, with what to do when your game isn't fun early on, and how it's so hard to build an agile culture, but so easy to destroy overnight from leadership doing things like I did. So I built a leadership course that was like, I wish this was the training I had got. 20 years ago when I was put into this position to help navigate some of these issues and help these teams. I there's, I mean, there's, mean, occasionally see cultures that just kind of like beyond, you know, their, ability to recover just too late, you know, to make some of these, make some of these changes, because like I said, we have to get this title. Brian (27:49) Right. Clinton Keith (28:15) Out the door in three months. In fact, these days I just refuse to, I used, I refuse to train a team that's within six months of shipping a, having a big title to ship because it's like, yeah, that sounds great. You know, we'd love to do it, but you know, we're just in the trenches for the next six months. Brian (28:35) Yeah, that kind of heads down and then can't, how do you learn a new process, you know, while you're in heads down mode, right? Well, this is fascinating. And I, you know, I'm tempted to take more of your time. I just don't want to, I want to be respectful of your time and in our listeners time. So it's probably a good place for us to stop. I want to just point out to people, again, your book, Agile Games Development, where you talk about a lot of this stuff. If I'm reading this correctly, it was originally out in 2020, right? Is that correct? Second edition, second edition was 2020. So you've added some new stories and some new elements to it in 2020, right? Clinton Keith (29:09) The second edition, Well, I mean, it was between 2008 when the first edition came out, we had mobile. You know, it's like the iPhone came out and mobile came out and the entire industry turned upside down. So, and I just, we've just learned so much from working with all these studios and what they have discovered is just incredible. it's, mean, it's, I mean, the industry was very agile early on. You know, the console, the arcade developers used to like sneak out prototype versions and Brian (29:22) Yeah. Clinton Keith (29:47) count quarters they collected. When then the 90s and early 2000s, things got so huge, we went away from Agile. And so it was a difficult sell. But in the last, yeah, the last dozen years, it's been fantastic with all these platforms, all these new opportunities, all these new markets. It's almost as if we're not using the word Agile anymore. It's just the way to develop. Brian (30:14) That's awesome. Yeah, that's what Mike said sometimes. Mike Cohn, when we talk about this, he's like, that was my goal initially was to not have Agile be something we even had to name. It just would be software development. And that's just the way that would be the default in doing things. So it's good to hear that at least in some places that is the case, right? It does feel like that's more of the default. That's great. Clinton Keith (30:38) Well, it's no coincidence. Mike was our first coach 20 years ago and my mentor. And I think that I stole that quote from him and glad to see that it's, it's, it's coming true. Brian (30:41) Yeah You That's awesome. That's awesome. Well, we'll put all these links in the show notes for everybody. But again, the book is called Agile Game Development. And Clinton, I really appreciate you coming on. Thanks for taking your time and chatting with us. Clinton Keith (31:02) Thanks for the invite, Brian. Enjoyed it a lot.

Lessons From Barbie for When a Project Absolutely MUST Succeed - Mike Cohn I finally watched Barbie. I enjoyed it, which doesn't surprise me. It had to be good. Barbie was a must-succeed project. If the movie had flopped, it would probably be a decade before anyone could try again to make a Barbie movie. But a successful movie would serve as a platform for sequels. While watching Barbie (and singing along to “I'm Just Ken”) I was struck by a few important lessons that apply to any must-succeed project. The first tip for successful project management is to solicit and act on as much fast feedback as you can get on preliminary versions of your product. For Barbie, the filmmakers ran test screenings in multiple cities, analyzed feedback, and ran more test screenings. In our words, they iterated toward making a great movie. The second tip for managing projects successfully? Leave things out. Not every scene that's filmed makes it to the final movie. During test screenings of Barbie, the filmmakers performed what product development teams call A/B testing. Different versions of the movie were shown to different audiences to see which were best received. They used this feedback to remove scenes or shots that weren't necessary to the flow or humor of the film. Not every feature a team builds should remain in the product. The sunk cost fallacy often clouds our judgment—when we spend time building that feature, we think we might as well leave it in just in case someone wants it. But no. Unneeded and rarely used features clutter the user interface just as unneeded scenes can ruin a movie. Third, have a visionary who keeps the project focused but engage others for increased creativity. Greta Gerwig was that visionary for Barbie. She directed the movie and co-wrote the script. Her vision drove what we experience when watching the film. Agile projects have product owners who should act as visionaries for their products. They should see the future and guide others toward it. But no visionary, even an auteur filmmaker such as Gerwig, does it alone. The best welcome creativity from others on the project (including stakeholders and developers). During the production of 2001: A Space Odyssey, director Stanley Kubrick used a novel idea from his team. It was critical that HAL, the spaceship's onboard computer, overhear that crew members Poole and Bowman were going to disconnect him. Kubrick brainstormed ideas of how HAL could overhear those private conversations but could find no good solution. The solution came from his associate producer, Victor Lyndon, whose job had mostly been filing insurance paperwork for the film. Lyndon casually suggested that HAL can read lips. The vision for the film adaptation of Arthur C. Clarke's story remained very much Kubrick's, but he knew to use great ideas without regard for their origin. Finally, if you are working on a project that absolutely must succeed, include Ryan Gosling and Margot Robbie as team members. OK, their coding, design, and database skills are probably lacking, but they were perfect as Ken and Barbie. Project Success Tip 1: Solicit Feedback as Early as PossibleProject Success Tip 2: Leave Some Features OutProject Success Tip 3: Have a Visionary But Find Good Ideas AnywhereProject Success Tip 4: Have the Right Team How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

In this episode of the Agile Mentors Podcast, Brian Milner and Mike Cohn reveal the keys to achieving lasting success with Agile methodologies. From embracing experimentation and fostering a culture of continuous improvement to improving communication with consistent vocabulary, they offer practical, relatable insights for Agile practitioners at all levels. Overview Brian and Mike discuss the essential ingredients to Agile success, touching on the power of experimentation, the need for flexible coaching, and building a culture of continuous improvement. The conversation dives deep into the importance of effective communication within teams, especially through user stories and consistent vocabulary, ensuring that Agile teams stay aligned. With personal anecdotes and actionable tips, this episode provides a roadmap for anyone looking to excel with Agile. References and resources mentioned in the show: Mike Cohn Essential Scrum by Ken Rubin Agile & Scrum Glossary #85: Effectively Managing Dependencies with Ken Rubin Dependencies Are Killing Your Agile Flow at Scale by Ken Rubin Creating a Software Engineering Culture by Karl Wiegers Private Scrum & Agile Training Agile For Leaders Working on a Scrum Team Classes Story Writing Workshop Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today we have our favorite back with us, Mike Cohn is here. Welcome back, Mike. Mike (00:12) Thanks, Brian. It's good to be here. Hi, everybody. Brian (00:15) So happy when Mike can make time and be with us here on the show. Obviously Mike has a lot of wisdom and experience to share with us. So we wanted to bring him in because we were talking about doing an episode titled The Secret Staggile Success. I remember back in the day in the 80s, was a movie called The Secret to My Success. There was a really obscure movie. was Michael J. Fox. Yes, it was Michael J. Fox. Mike (00:37) Michael J. Fox? Yeah, so it's not that obscure. Brian (00:41) But I still hear that theme song in my head. when we talked about this title, that's what I thought about. But we wanted to talk about maybe some hidden things or things that aren't as immediately apparent to people that are crucial to being successful when you go agile or if your teams are working in an agile way. So let's just open things up, Mike. What's one of the things you had thought about when we talked about this? Mike (01:10) think the number one secret to Agile success for me is being willing to experiment, to try new things. And if you think back, Agile itself, Scrum itself, began as experiments. They were probably teams going, know, this waterfall stuff we've been doing doesn't work. Let's try something different. Somebody else went, yeah, let's do something unusual, and let's try iterating or something. And so Agile itself began as experiments. And yet I see teams kind of get stuck in the mud and not willing to experiment. And I think that's to their detriment. We want to try things out. And silly, trivial examples, try different sprint links. Don't do a one -week sprint link and go, Agile doesn't work. It's not for us. No. Brian (01:52) Yeah. Mike (01:59) Maybe one week sprints are for you. Try a three week iteration or I try something different. And I think the the idea of experimentation is how we come up with new ideas. It's how we learn. It's how we get better. And so if you're going to succeed, you better have that that focus on experimentation. Brian (02:19) Yeah, there's a surprising number of Scrum Masters I've encountered that I'll hear stories about how they run the same exact retrospective, every single retrospective. And I just think, what are you doing? How can you be trying to communicate this and teach the team that this whole thing is based on doing little small experiments and seeing what the result is, when you're not willing to try something new in just how you run a retrospective? So yeah, I completely agree. I think the key there for me is demonstrate it. If you want them to pick up on that, then do it yourself. Mike (02:56) worked with a company years ago that fired their scrum master for basically for being too rigid. He had read something in Ken Schwaber's second book, and I don't want to pick on Ken's book, but he has this wacky sentence in there, and there are wacky sentences in my books, right? So somebody can go find those, and I mean, I get it. But anyway, Ken wrote that the daily scrum must be conducted left to right, starting with the person on the left of the scrum master. And it's like, what? Why is this mandatory? It must be left to right. Anyway, this guy read that in the book and insisted that the Daily Scrum be left to right, starting with the person on left of the Scrum Master. And his team knew that was insane, right? It's just nuts. And so they would mess with him. They would do things like he would call on the person to his left and the person on the right would start talking. he would point to the person on the left to start and they were standing in a semi -circle. They would move, right? So the person on the left was no longer on the left. And they were just messing with him over this. And he would just get mad and insisted it had to be left right because the book said so. And I don't know what it was with him, but he was just stuck on this. Ultimately ended up getting fired for it. Yeah, I heard this story because I ran into him at a conference and I saw him there and he Brian (04:14) Wow. Mike (04:20) looked a little down. It's like, you know, said his name and how are you doing? And he told me this story. And he said, you know, he'd gotten better since then. But, you know, don't get stuck on things. It's just not the it's just not a very agile mindset. Brian (04:34) Yeah. I mean, if you can't, no matter what it is too, I think that if you can't point to what you hope to achieve from doing it that way, or what's the purpose behind us doing it that way, that's questionable part of your process to just say, I can't point to any reason why this, any good that this thing does going left to right person by person, but. Ken said we should do it. I guess, no, I mean, if there's no reason, if you don't see the benefit in it, why would we do that? Mike (05:07) Knowing Ken, I think he was just trying to make it easier for people. Here's one less thing you got to think about. Start on your left and go around the room. But the way it's written and the way this guy interpreted it was like, shalt go left to right. It's like you've got to be willing to, I think, out the way that a known proven way start out that way. So yeah, go ahead and start left to right. It says so. I don't know any different. Might as well go this way. Brian (05:17) You Mike (05:35) But then experiment, learn, figure it out for yourselves. I I can't think of a successful company or team that I've worked with that ever quoted this Scrum Guide at me, right? You know, they may start out exactly the way a Scrum Guide says, or my favorite is Ken Rubin's Essential Scrum Book, start out in a known proven way, but then experiment, make agile your own. Don't throw away the important stuff, and that's why you have to start in a known proven way, but as you get experience, experiment, throw things out. Brian (05:46) Yeah. I love that. Yeah, I think that's a really good one. So a good one to start us off. Thanks for that. Mike (06:12) Yeah, that's, that's what I'm buying. Brian, can I ask you for one of your secrets to agile success? Brian (06:17) Sure. Well, and this one I know it's going to be a little, know, boy, it'd be nice if I could do that, but I, you know, we can't do that. And I understand that this is not going to be for everyone, but one of the things that I think is important is to have some kind of a coaching presence. Now, just to be clear about this, this doesn't mean that you have to, you know, fight tooth and nail to hire some outside consultant or anything like that. I understand budgets are tight and there may not be an ability to do that. But I think if I, you know, if you're a scrum master, then I think that having the ability to continue your learning journey and grow is really important and, and having someone you can go and bounce things off of. So if you can't have someone, if you, if you can't have someone on staff or someone there that's an outside consultant that can help you and coach you through the early stages, I think that could be really, really helpful. And to me, it's an accelerator. I think that kind of thing is something that can really, yes, we will go through training. We understand kind of the basics, but then the coach is sort of like pouring gasoline on that fire to say, now we're going to go from zero to 60 and I'm going to help you get there because I know the pitfalls to look out for and I know how to get you there. But if you don't have that ability, I think it's important to maintain some of those mentorship relationships that you can find through different community groups. Mike (07:18) Mm Brian (07:44) Maybe you'd find some kind of a weekly meetup or a monthly meetup or something that you could go to. Even if it's just a meetup of peers, right? There's not someone that you would say, that person's been in this for 10 years. No, we're all kind of in the same place. But if we can meet up in their network of my peers and let's talk about what's going on at your place, I'll talk about what's going on at my place, and we can share with each other and... help each other find the best solutions. Even that level, I think of coaching is really imperative and can really make an impact on how successful your implementation is. Mike (08:25) I think you're right. I think back to the earliest days of Agile, and at least of Agile training. And I'm thinking back to when I was teaching public courses on Agile in 2003, 2004, 2000, actually, the early days. One of the big benefits of the class, beyond whatever learning somebody had in the class, one of the big benefits was just feeling like you weren't alone in the world. And I remember people describing a problem, whatever it was. Like, my bosses aren't on board with this. and somebody would describe a problem and then somebody else in the class would just merely sympathize. Right. Yeah, mine too. I'm struggling with that too. That was like one level of support that was awesome. It was even better if there was somebody in the class who said something like, yeah, we had that problem and here's what we did. Right. But these were not people who were any smarter than each other. It wasn't like the person who'd worked through the problem was that much smarter. They probably just had a six month head start and Having that ability to go into a class and hear that you weren't alone and that your problems were not that unique was extremely valuable for people even way back then when there were not a lot of people doing this. Brian (09:32) Yeah, and I've said this before, and I probably said this to you, Mike, but one of the things I think people love the most when they come to the advanced classes that we offer is really being able to get sympathy from others, the camaraderie of talking to somebody else and saying, yeah, I've gone through that. It's not, I tell people at beginning of the class, it's Mike (09:48) Mm -hmm. Brian (09:59) likely not going to be a teaching point that sticks with you as much as it's going to be hearing from your peers and actually getting to learn from each other that's going to stick with you as much through those classes. to me, I think that's one of the reasons why those classes are so much fun is because I learned from the people who come to them. Mike (10:20) absolutely, absolutely. Some of what you're describing is why we set up our Agile mentors community years ago. Agile mentors community, not just the podcast, is a community we have where people who take one of our courses get a free membership. I hired a consultant to kind of give me advice on some business stuff years ago. he used the try. And I asked him, hey, we're thinking about starting this community. What do you think? I don't remember if he said do it or don't, but I do remember a term he used. He called it a continuity program. And it was a way to continue a relationship with people who taken our courses. And like I said, we give it away free to people who take classes because we know that a class isn't enough to get people successful, but it's a start. It gets people over some hurdles. It gives them the foundations of the education they need. But they're going to have ongoing questions. And our community has been wonderful because we have so many good people in there who helped each other out. And again, they're often somebody who's just six months ahead in their journey, helping somebody who's right behind them or, you know, there's somebody just in a similar industry and can sympathize or give advice on how they worked through a problem. Brian (11:29) Yeah, that's awesome. So we talked about experimentation, we talked about coaching. Mike, what was another one that was on your list? Mike (11:36) One for me is to focus more on practices than frameworks. The frameworks get all the attention. Should we do Scrum or should we do Kanban? Should we do extreme programming, going back a little bit more when that was extremely popular, still around, but not as popular? Should we do safe? And so people focus on their frameworks because they're these big, visible things. And I think what we want to do more is pick the right practices for us. Now, that's not to diminish frameworks. I think the frameworks are good. They're a good starting point. But I've said for years, if I have a team and they start with Scrum or if they start with Kanban, if they're doing the good old inspect and adapt thing, they're going to end up in the same place. They're going to invent the right Agile for them. And very likely, that's going to be some elements of Scrum, some elements of Kanban, perhaps some elements of Safe if it's big. I don't think it matters all that much where you start. I think it's worthy of some consideration. But if you're inspecting and adapting, you're going to end up in the same place. And that means that Agile needs to be thought of more as a set of practices rather than we do Scrum or we do Kanban. Brian (12:49) Yeah. Yeah, I love that. And, and, you know, we've talked about the kind of that concept before of, you know, trying to fit the right practices in place. I know when even on this podcast, when we talked about scaling and then couple of those episodes, we talked about how, you know, it may be better for you to, to, find the unique collection of practices that fits your situation. because, know, a lot of these frameworks, they're designed to handle everything. They're designed to handle any possible scenario and. Mike (13:14) Mm -hmm. Brian (13:18) You're not going to encounter every possible scenario. You're going to encounter the ones that are only particular to you. Yeah. Mike (13:24) Yeah, absolutely. Yeah, I've thought that there's I don't want to do this. I've never taken the time to really run this as an initiative. But I felt like there are a core set of practices that kind of everybody should do be iterative, right? know, inspect and adapt, right? Those type of things. But then there's a set of practices that are good for startups, let's say there's another set of practices that are good for people in the banking industry. Right. And that everybody in the banking industry should be doing a certain set of practices, and those will differ a little bit than perhaps every company in the game industry. And so there's these set of practices out there that can be grouped, but they do also need to be kind of tailored and hand -chosen for your particular organization. Brian (14:11) Yeah, yeah, I like that kind of the idea like a template, right? I mean, like when you use the template on a software program, that's a starting place, but you're expected to kind of customize it a little bit to your specific needs. Yeah, I like that. Mike (14:25) Yeah, wouldn't it be great if you're a startup and somebody said, here are the 20 practices you really got to do if you're to be successful as a startup. Here are the 10 you should think about, and then the rest, see if you like them. Same thing, bank. the bank, might have 30 practices you start with. Ivar Jakobson, who's the inventor of use cases, part of the unified method back with Bucin Rumba. He's had an initiative going on the last handful of years where he talks about method prisons and that the practices are all kind of locked up in these methodology prisons like Scrum and Kanban and everything else. And he talks about like free the practices, right? Let the practices loose of these method prisons and let people just more readily select the set of practices that are best for them. Brian (15:15) Love it. Yeah, I love it. That's a great concept. Mike (15:17) Yeah, I think it's a great, it's a great approach. It's got some traction, but it's something that more people need to hear and do. Brian (15:22) Yeah, I think that there's also maybe some stuff mixed in there with what you were saying that I've heard from the heart of Agile people. There's a lot of good stuff that's overlapped there as well. So that's awesome. Mike (15:32) Absolutely. What's another secret you can reveal Brian? Brian (15:37) Sure. Now, this is a big one, but what I would say is maybe moving in a different direction, the idea of how important the culture is and just setting the right culture even more so than trying to get things like time boxes correct. I was talking with a friend of mine at a conference recently and one of the things we kind of discussed was that whole inspect and adapt process, how important that just getting that ingrained into the DNA of what the team does. And Mike, like you said earlier, if they have that inspect and adapt built into who they are, then the practices come. The practices will actually kind of coincide with those because they'll find the right things to do. Like you said, they'll end up at the same place, right? They'll end up at the things that really are important to them. But I've seen lots of places where they go straight to the rule book and want to implement all the rules as quickly and possibly as they can. If the teams don't understand, when something goes wrong, when something does not happen the way that we thought it should, then that's a target to inspect. and dig in and find out why it happened that way, and then find a new way of doing it. I've told the story in classes before that I've encountered multiple situations, scenarios where I've worked with teams where they'll be doing something that they've identified as a problem. They've said, hey, yeah, this is wrong, this doesn't work. well, that's what I'm saying. Mike (17:26) Why are they doing it then? Brian (17:32) They'll identify something and say, yeah, that's not good. We need to do something else. But then they'll stop and say, all right, so let's really, we want to find the right thing to do to replace that with. So let's take the next two months and really investigate, find, and then we'll come back and we'll change in two months over this new thing. And my advice to them is always, so you're gonna just intentionally do the wrong thing for two months? Right. Mike (17:59) for two more months. Brian (18:01) You know, like you should try one of the other possibilities because you could get lucky and that could be the first thing you try. You know, and oftentimes it is something that is better because your gut instinct is usually pretty good about that kind of stuff. So yeah, try it. Something's not going well, all right? Then we're not doing that again, right? We're gonna try something new, whatever that is, and we're gonna try something new and then we'll do the same thing at the end of the next sprint. Mike (18:27) Mm -hmm. Yep. One of my favorite comedians, this guy named Bob Newhart died early, he was earlier this year. And he has this one comedy routine that he does where he's a psychiatrist and somebody walks into his office and she describes some problem he has. And he's like, okay, I'm going to give you the advice. It boils down to two words. And she goes like, should I take notes? Should I write the two words down? It's like, nope, you'll remember them. And he just looks her really like stern in the eye and says, stop it. Brian (18:54) you You Mike (18:59) She has a phone question. He's like, just stop it, right? Whatever you're doing, just stop it. And which is like just hilarious, right? Imagining, you know, some psychiatrist or therapist giving the advice of just stop doing whatever it is you're doing. But it's so reminiscent of what I've seen with agile teams, right? And with what you're describing here, you know, we're doing the wrong thing. We need to change, but we're going to stall looking for the perfect answer instead of just stopping and figuring out something, right? Just try something different. Brian (19:28) Yeah. And if our culture is a culture of always inspecting and adapting, then like you said, we'll end up at the right place because when something's wrong, we'll change it. And we won't just sit on something that we, I don't know how many times I've seen the organizations where you talk to people and take them out for a beer and they'll say, well, here's the real problems. everyone knows what the problems are. So why not fix it? Why not change it? Mike (19:41) Mm -hmm. Yeah. It's hard. It's hard in a lot of organizations. You and I both do sessions where we'll talk to executives, right? And to me, it's a really fun, like 90 minute training session that we have because the way we deliberately set that up was to talk about the benefits of agile. So we get people kind of interested, right? you know, those benefits. But then we tell them why it's going to be hard and what they're as executives, what was leaders, what they're going to have to change. And what I find is when we do that, if the leader starts arguing with me, because I tell them, look, here's going be hard. You're going to have to change this. You're going have to stop doing this. If they start arguing with me, we'll change that behavior if we get those benefits, then we know we've got them hooked and they want to be agile. But if I say agile's great, here are hard things you're going to have to change personally. And they're like, yeah, that'd be hard. We probably wouldn't make those changes. I don't want to go anywhere near working with that company. They're not going to succeed. They don't have a culture that's going to make those changes. And so I love doing those executive sessions because we hear it's just so instant, it's instant feedback on whether this company has a chance of being successful or not. Brian (21:06) Love him. Is there another one on from your list, Mike (21:10) One that I want to add is a little bit more about not just having one team be successful, but if you're working to get a set of teams, your department, your group, something like that. I think it's really important to have a consistent vocabulary across teams. Because we're talking about this idea of continuous improvement. And if your team and my team are using words differently, how do we share ideas back and forth? And that sharing of ideas is really important. if we don't have a consistent vocabulary, think it's hard to do. I worked with a team a couple years ago. I worked with this team, and I'm there for like two or three days. I think I'm there on the second day. And they've been using the words sprint and iteration interchangeably, just both words. And I'm sure you've encountered that. It's kind of normal. I think it kind of depends on if you grew up in the Scrum world, you call them sprints. If you grew up more generically agile, you call them iterations. They're using both words. And the second day I'm in a meeting and somebody says, well, yeah, that's how we do it in a sprint, but it's totally different when we're in an iteration. And I'm like, huh? What's the difference? And the guy had a really great answer. He said, a sprint is when we're working overtime and iteration is when we're going at a sustainable pace. That actually, there's a lot of logic to that. It's kind of a cool idea. I could see that. Brian (22:17) Ha ha ha. Mike (22:37) But I could tell by looking around the room that others were surprised as well. They'd been using the words interchangeably too. They didn't know there was this specific meaning that, I don't know, three Algel coaches had decided three years ago, this is how we use the words. But it wasn't part of, to your word, moment ago, culture. It wasn't part of their culture. And so some teams were calling them sprints, some teams were calling them iterations, and it was just creating a lot of confusion. when we found out that there were different meanings and different rules for whether you were in a sprint or iteration. So. Brian (23:08) Yeah. It reminds me of a Dilbert cartoon I saw a while ago, or it's been several years now, it was about, were talking to their big dumb boss, right? And they were saying, yeah, we're in the middle of a project and we're about halfway through, but we need, you know, six more months to complete this. All right. What's the project you're working on? We're taking all of our website addresses and we are transforming them into URLs. Right. Yeah. It's yeah. Okay. Yeah. Obviously, the boss didn't know the difference, right? Mike (23:37) That's a nice project, right? That's my assignment next month. Yeah, the vocabulary just creates confusion. like how Ken Rubin, I mentioned him earlier, the author of Essential Scrum, my favorite book on Scrum. You've had him as a guest before. I love how he writes his books. He starts out, I just start out, I just plunge in. just like, just start writing. And I have an outline, but I just start writing. Ken sits down for seriously months, I think it is. Brian (23:39) Right. Right. Mike (24:07) and defines a glossary, right? Here's how I'm gonna use certain words. then he, man, if he says a word means a certain thing, he uses it that way every single time. And he has a wonderful, agile glossary on his website, inolution .com. And so he's like defined every kind of agile word you could look for. He's got it defined there. But that's how he starts, right? So he defines all these words. And then if he writes a book and he... Brian (24:10) Wow. Mike (24:33) wants to use the term sprint, he knows exactly how he's going to use it. That's an easy one, but he will define all those words so they're clear up front. We do these working on a Scrum team classes for companies, which is a of a private whole team training class. And some of the feedback we get is that it really helped them get their vocabulary consistent. It allowed them to talk about ways to improve that were challenging until they had a common vocabulary. What is a Scrum master? What are the responsibilities of a Scrum Master? And that's not just defining the word sprint, but it's defining a more complex word and saying, what does it really mean? But if you don't have agreement on what a Scrum Master is or who is on the team or things like that, it's really hard to talk about that across a larger group. And so that, to me, is one of the secrets to Agile success is that consistent vocabulary. Brian (25:25) Yeah, I'm glad you mentioned that class because one of the things that that that we do periodically when we are not here every time. One of things that we do when we have one of those classes is I'll meet with their with a company in advance and have a conversation about what is it that you really want to get out of this. And one of the most consistent things that I hear over and over again from companies that come to us is we want consistent vocabulary. We want a consistent language that people use across this so that When we say something, means the same thing across all our teams. Mike (25:58) I think it's become more of an issue the last, I don't know, five, 10 years or whatever it is because we've got so many people that know Agile by now, right? But of course, they were trained by different people. They were trained in different ways. And so they'll be coming to it and using terms slightly differently. I'm going give a little example here. Velocity, right? Velocity can really mean two different things to people. Velocity can mean the amount of forward progress you made. in a sprint, right? How much forward progress did we get? Instead, velocity could mean capacity to do work. How much work did we get done in the last sprint? And forward progress, capacity to do work are slightly different things, right? And if we don't have agreement on that term, we're going to get into those fights about, bugs count towards velocity, right? Well, if you're using velocity to mean capacity to do work, yeah, bugs should count. If you're using velocity to mean forward progress, no. Bugs shouldn't count. And defining velocity, having that conversation with the team, once you get that figured out, a whole set of problems go away. All those discussions about what gets points, they all go away instantly. But most teams don't think to have that conversation. And they will have some team members using velocity one way, others another way. Important to get that defined. It's not hard, but it's important to get that consistency. Brian, do you have another secret, or have we revealed all the secrets? Brian (27:24) Yeah, I got one more. I got one more. you might, you know, if you're listening this far, you may notice that I have a sickness. I picked all C words. I don't know why, but that's just what I had to do. But my last C word was communicate. And really just the idea here was, you know, if you've ever gone to see a youth sports team, you know, a kid's soccer, kids basketball, whatever, right? If you ever go to see any of those things, one of the things that you will hear over and over screamed from the sideline from the coaches is, talk to each other. And it's a really important part of learning how to play that sport is, hey, I've got a call for the ball. I've got to let everyone else know, hey, here's what I need. And I think that's an important part of Scrum as well. Scrum is a team sport. It's a... Mike (28:02) Haha. Brian (28:19) You know, I apologize to people in classes and say, apologize for the sports analogy, but scrum is a sports analogy. You know, it comes from rugby and, it's, it's intentionally there as a team sports so that people can, can recognize and look at that and say, yeah, we're not, we're not playing golf, right? We're, we're, playing this as a team altogether at the same time with the same goal. And so you got to talk to each other. You got to have communication. I know, you know, Mike (28:24) Yeah, itself, Brian (28:47) One of the main ways that we try to help that here at Mountain Goat is when we talk about things like user stories. That's a main tool that the teams will use in their communication back and forth between the business and the developers. And I know in your Better User Stories course, we go in detail about that. And we also have this thing that we do occasionally called a story writing workshop that's kind of more coaching, where we'll sit down with people and kind of Mike (29:01) Mm -hmm. Brian (29:17) actually work through stories that they're writing to help them effectively communicate what they're trying to get across to the developers. Any communication takes practice. Any relationship, the communication grows and gets better the more you do it. Mike (29:36) I think it's a good point about using user stories as an example, because one of the user story mistakes people make is to think that user stories exist to document an agreement. They don't. They exist to facilitate a conversation. And then the conversation is where we're going to figure out the specific needs and things like that. Yeah, maybe we could document that. It's got to be documented for various reasons. in many organizations, but the story itself is there's a reminder to have a conversation, right? It's not there to document an agreement, which is different from things that came before, like a use case or IEEE 830 document, right? Those did document agreements. User stories, they're there to make sure we talk. Brian (30:13) Right, right. Those were in essence contracts, right? I mean, they were, you shall do this, the system shall and whatever. But yeah, user stories, not that. I love the way that you put that and I've said that for years as well. It's a placeholder for the conversation. Mike (30:28) Well, let's add one more C then. didn't realize you were on a C theme here. So let's add one more secret to Agile success with a C. Crack the whip, right? Yell at your team, make them work harder, right? That's the secret to Agile success. I shouldn't say that because you'll pull that out as a little clip. crack the whip on your Agile team. That's how you get them successful, right? Brian (30:30) Hahaha! Hahaha. I can guarantee you that's gonna be the cold open here for our show. It's Mike Cone saying, the secret is cracking the whip. I love it. Well. Mike (30:59) So there was a great book by a guy named Carl Weigers on culture. is like creating a software engineering culture. And he has these little gray boxes in there. There are things not to do, right? Don't do this. But the boxes don't say don't do this, right? You have to have read like the intro to like, hey, don't do the things in the gray boxes. But he also has like anti -patterns in there. And I just remember being a, a, I think it was a director, VP at the company. And I showed it to one of the directors. I'm like, man, look at this. He's got guys highlighted all the things to do in the boxes here. And he was like, really? We should do that? Okay. And he was like, ready to go do these things. I was like, no, no, no, these are the things not to do. So you gotta be careful with things like crack the whip, right? It's, you know, a direct quote. It sounds pretty horrible. It's a joke. It's like, hopefully people understand. So. Brian (31:42) That's hilarious. Yeah, yeah, I think everyone who's, you know, listening to this would understand that, right? Would understand that that's a joke, but and just in case. Mike (31:56) As a guy who had the whip cracked on me as a young developer, I've always been a very much do not crack the whip. I'd rather I'm always after people's energy rather than their time. Right. It's kind of like we do four day work weeks, right? I'd rather have energy than time. And so, don't think cracking the whip is the way to succeed. Brian (32:15) Yeah, I'm in the same boat. remember having a boss once that used to take me into the server room to yell at me because he could raise his voice in there and nobody would hear it. So, that was fun. Right, right. Well, this has been great, Mike. I really appreciate you making time for this. And I think everyone's going to get a of good tips out of this. Mike (32:23) You I gotta remember that. Great, thanks for having me, Brian. Bye.

Richard Coplan: The Impact of Product Owner Pressure on Agile Team Morale Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Richard shares his experience working in a toxic team environment at an insurance company. Brought in to replace a beloved Scrum Master, he found himself navigating a strained relationship between the Product Owner (PO) and the team. The PO's aggressive push for deliverables demotivated the team, and management sided with the PO, creating a vicious cycle of disengagement. How can a PO's leadership style make or break a team's performance? Richard explores this anti-pattern of PO-driven disengagement. Featured Book of the Week: Lean Enterprise by Jez Humble, et al. Richard reflects on how the book "Lean Enterprise" helped shape his approach as an Agile Coach, offering a holistic view of organizations. He also discusses "Team Topologies" and the importance of stream-aligned teams with CI/CD pipelines. What role does organizational agility play in the success of Scrum teams? Richard suggests that while many teams practice Scrum, organizations themselves are often not truly Agile.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Richard Coplan Richard joins us from the UK. He has been a software developer for many years and later became data-centric, eventually transitioning into the role of Scrum Master. Over the past decade, Richard has specialized as a Scrum Master and Agile Coach, with a focus on collaboration tools like Miro and helping firms streamline their team structures. You can link with Richard Coplan on LinkedIn.

Five Factors to Consider when Prioritizing - Mike Cohn Not only do you need to build the right features, you have to build them in the right order. I want to share five key factors you should consider when prioritizing a product backlog. ValueNaturally, you need to consider how valuable a feature will be, value is a nebulous term. Most work a team will pursue will be valuable to users. But other work may be valuable just to the team. Still other work may be valuable to both users and team members.For example, consider refactoring: improving the structure but not the behavior of code. Because this makes code more maintainable or easier to change, developers value refactoring and often request time for it.Still, the cost of refactoring is usually justified by the way it benefits users, too. If code is more maintainable, users should experience fewer bugs. Similarly, improved code means that users should receive new features in that area of the product a bit more quickly. LearningWhen prioritizing a product backlog, consider how much the team will learn by developing each backlog item.For example, when a team develops a preliminary version of a feature, team members get feedback on whether users like it and how they're using it. If users love a feature, enhance the feature or consider other things like it.Other learning is about how to build the product. This might occur when a team uses a new technology for the first time. They might learn if the tech works as promised, or they can develop as quickly with it as they thought, or whether it might be useful elsewhere in the product.Learning about what to build and how to build it are both valuable. CostThe third thing to consider when prioritizing is the cost. The largest cost is usually the team's effort to develop a feature. Most teams estimate the effort product backlog items in story points but some estimate in person-days, ideal time, or other similar units.In some cases there may be additional costs that should be considered. A current common consideration is the ongoing cost of delivering features that rely on various AI products. These products often include small per-use fees but those can certainly add up at scale.Regardless of the unit in which a team estimates their product backlog items, and that cost to develop and support a feature should factor into an item's priority. For example, an item a team estimates as 5 should be prioritized higher than a feature estimated at 20 if all else is equal. This is true whether these are story points, person days, person hours, ideal time, or any other unit. RiskThe fourth factor to consider when prioritizing is the risk inherent in developing the product backlog item. If something is risky and you need to do it, do it early. You want to know whether that risk is going to materialize.On the other hand, if a feature is risky and you may not need to develop it, delay working on it until it becomes clear you need to do it. DependenciesThe final factor you should consider when prioritizing is dependencies between product backlog items. Some items may not be high priority on their own, but they're necessary for delivering other items. When that's the case, the enabling but lower-priority item needs to be moved higher on the backlog in order to be done before the item dependent on it. How to Combine These FactorsWhile all five factors are important, I don't recommend combining them through some fancy formula.The value of a feature and its cost–our first and second factors–are the most important.I recommend continuing to prioritize based on these but then using the other three factors to adjust priorities and resolve conflicts.For example, suppose a product owner or product manager has prioritized an item such that it won't be done for another three or four iterations based on its value and risk.

Anita Kalmane-Boot: Rebuilding Bridges Between an Agile Team and Their Manager Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Anita shares a story about a team that was paralyzed by fear of their own manager. Despite the manager's care for the team, communication had broken down entirely. Anita focused on mediating and rebuilding trust between the team and the manager. She reflects on the importance of understanding team dynamics and continuously defining the role of a Scrum Master. Featured Book of the Week: NeuroTribes by Steve Silberman In this episode, Anita introduces "NeuroTribes" by Steve Silberman, a book that explores the history of autism. Anita highlights the importance of understanding neurodiversity, especially in Scrum teams, where the percentage of neurodiverse individuals can be significant. She discusses how this book is a valuable resource for Scrum Masters to better understand and support their team members.  [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Anita Kalmane-Boot Anita is a neurodiversity advocate and considers herself European, not bound to one single country. Anita is passionate about Agile but is losing hope in corporate organizations and their adaptation of Scrum. You can link with Anita Kalmane-Boot on LinkedIn.

Does Every User Story Have To Be Small? Small user stories are essential to success with agile. When it's time to bring stories into an iteration, I always want them to be small.But larger stories have their place as well–especially for something you're not going to work on imminently.Suppose you have just begun work on a new product that will include a set of reports. Because this is a new product, there is nothing to be gained by writing a bunch of small user stories around each one of those reports at this point, especially since you don't yet even know all of the reports that will be needed.At this stage of the project, having one big reporting story rather than a bunch of little ones keeps the size of the backlog more manageable. You'll have one entry in your tool instead of 15 or 20. That's much easier to manage.Further, if you do write all the small user stories, one per report, it gives the impression that you've thought of everything. Early in a project, that's probably not true. New reports will be identified and some that are asked for initially may not be necessary.Don't fall into the trap of thinking every story needs to be small from the beginning. They don't. Instead, plan for stories to shrink in size and grow in detail as they move closer to being brought into a sprint. For most teams, this will happen during the product backlog refinement meeting one or two sprints before the iteration planning where they'll be considered.Letting timing dictate story size will help you succeed with user stories and with agile, How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Johann Botha: When Agile Teams Become The Reason Agile Fails in Organizations Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. When Agile teams push too hard for transformation, they risk becoming the enemy. Johann explains how corporate "immune systems" react against new ideas, even when they're beneficial. What strategies can Agile teams use to navigate organizational resistance and avoid self-sabotage? Johann emphasizes the importance of listening, finding safe spaces to experiment, and avoiding the trap of making Agile seem like an invasive force. Featured Book of the Week: No Rules Rules by Reed Hastings and Erin Meyer Johann shares his journey through influential books that shaped his approach to management, from Tom Peters' Liberation Management to Netflix's story in No Rules Rules. How do these books provide a roadmap for progressive management practices in today's fast-paced world? Johann also highlights key texts like Accelerate by Nicole Forsgren et al., and his own work, Competing in a Digital Future, offering listeners a rich library to explore. [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!   About Johann Botha Johann joins us from South Africa, helping build digital-age capabilities by developing practical skills to solve problems, grow people, and facilitate difficult change. A long-time proponent of Lean and Agile, Johann consults, coaches, speaks, and writes on the topic. He is also the chief examiner for the EXIN Agile Scrum product. You can link with Johann on LinkedIn and connect with Johann on Twitter.

I just had groceries delivered. One of the items I ordered was a four-pack of square tissues. The store must have been out of those because they substituted an eight-pack of small travel tissues.You might say the store delivered less value than I expected.And I'm only a bit disappointed, but imagine how disappointed stakeholders are when teams deliver less value than they should. That's more frustrating because what our teams deliver is nothing to sneeze at.One reason teams deliver less value than they could is that they don't have a medium-term goal to guide their efforts.A long-term goal is great. It can provide excitement to spur a team to greater creativity, novel solutions, and breakthrough products.But it's hard to feel progress against a long-term goal that won't be achieved for maybe two, three, or more years.And short-term goals, such as sprint goals, are great at gauging daily progress and keeping everyone focused.It's the medium-term goal, perhaps two or three months into the future, that I often find missing. And that I find the most compelling.This is why I was excited in 2020 when the product goal became an official part of Scrum. The Scrum Guide is silent on how far out a product goal should be, simply calling it a “long-term objective.”Two problems arise without a goal a few months into the future:1) Each sprint is prioritized anew. The product owner considers whatever is urgent—that is, whatever stakeholders are yelling about at the moment—and sets the team to work on that.The urgent is not always that important. My email has been dinging while I write this. I probably need to at least read my new messages today, so they're urgent. But they're not as important as writing this email is to me.Without a medium-term goal to weigh against whatever stakeholders are asking for this red-hot moment, those urgent items will always win.When a team works on what's urgent rather than on what's important, they don't deliver as much value as they could.2) Without a medium-term goal to guide it, a team will often bounce from one top priority to the next. Teams, and especially their product owners, can succumb to shiny-object syndrome.An agile team should absolutely shift away from its current top priority capability once the next work on that item is of lower value than work on some other capability. A product goal achievable in a few months helps a team decide when that's the case.As the team begins each new iteration, everyone should be open to abandoning or altering the medium-term goal.Using a medium-term goal to guide rather than dictate its priorities will help your team succeed with agile. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

CTO Series: Andrea Goulet On How To Lead with Empathy in Software Development In this special BONUS episode of the CTO Series, Andrea Goulet, an innovative software executive, shares her mission to change the tech industry by making empathy a core technical skill. Andrea's insights reveal how empathy can transform leadership, foster collaboration, and drive success in software development. Through personal stories and practical tips, she illustrates the power of empathy in navigating complex challenges, from aligning mental models to enhancing communication between teams and leaders. Defining Leadership Through Empathy "Empathy isn't just credible in the software industry; it's crucial for innovation and collaboration." Andrea reflects on her journey from a communications background where psychology played a pivotal role, to becoming a software executive who champions empathy. Despite initial skepticism from industry consultants, Andrea stuck to her belief that empathy was essential for success in tech. She shares a transformative experience with Scott Hanselman that highlighted the importance of understanding mental models and developing new communication strategies. This experience solidified her approach to leadership, emphasizing empathy as a vital skill for effective collaboration. "Pause, reappraise, and think before you act – empathy in action is the key to navigating complex interactions in tech." Enhancing Team Dynamics Through Empathy "Developers can be as empathic as business leaders, breaking down traditional communication barriers." Andrea delves into the importance of empathy between teams and their leaders, particularly when dealing with mismatched mental models. She discusses the protocols she has developed based on real-life situations, which prioritize empathy in decision-making and feedback processes. By advocating for her team members and facilitating conversations between executives and developers, Andrea demonstrates how empathy can lead to more effective problem-solving and collaboration. "Facilitate conversations that shift from confrontation to collaboration – empathy is the bridge to solving shared problems." Bridging Communication Gaps in Agile Environments "The communication infrastructure is the 'plumbing' that allows information to flow seamlessly across your organization." Andrea explains how the book Team of Teams by General Stanley McChrystal influenced her understanding of agile methodologies. Struggling with the lingo of Agile, she found clarity in McChrystal's discussion of complex systems and the importance of managing interdependencies. Andrea emphasizes the need for a robust communication infrastructure to ensure that information flows freely within an organization, enabling teams to respond quickly to changing circumstances and align their efforts with broader business goals. "Build communication loops that enable agility – the right infrastructure supports the flow of information and decision-making." [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!   About Andrea Goulet Andrea Goulet is on a mission to change the way the world thinks about empathy by leading a scientific revolution and making empathy a core technical skill for all technologists. She is a sought-after international keynote speaker, experienced software entrepreneur, and award-winning industry leader. Her expertise centers on using empathy and effective communication to modernize legacy and mission-critical software systems. Andrea has taught over 75,000 students through her online courses on empathy and communication. She is the author of the forthcoming book, Empathy-Driven Software Development, and the founder of Empathy in Tech and Legacy Code Rocks, two online communities where code and compassion connect. You can link with Andrea Goulet on LinkedIn.

Join Brian Milner as he talks with leadership expert Christopher DiBella about mastering the art of influencing without authority. Learn how to lead with respect, empathy, and compassion to inspire your team, even when you don’t hold the official title. Overview In this episode of the Agile Mentors Podcast, Brian interviews Christopher DiBella, an expert in leadership and organizational development, about the power of influencing without authority. They explore how Agile leaders, especially Scrum Masters, can effectively guide teams and influence organizational culture through respect, empathy, and compassion. Chris shares practical strategies for building trust, navigating generational differences, and leading through relationships rather than formal authority. The discussion also emphasizes the critical importance of understanding the motivations and needs of others to achieve lasting influence. Whether you're an Agile coach, Scrum Master, or organizational leader, this episode provides actionable advice for leading in a way that inspires collaboration and growth. References and resources mentioned in the show: Christopher DiBella The Leadership Survival Guide: A Blueprint for Leading with Purpose and Impact by Christopher DiBella, PH.D. #37 Servant Leadership, Not Spineless Leadership with Brad Swanson #70 The Role of a Leader in Agile with Mike Cohn #109 Leadership and Culture in DevOps with Claire Clark Short Answers to Big Questions About Agile Leaders by Mike Cohn Certified ScrumMaster® Training and Scrum Certification Certified Scrum Product Owner® Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® Mike Cohn’s Better User Stories Course Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Christopher DiBella is a leadership coach dedicated to empowering aspiring leaders by teaching influential leadership practices that streamline processes and maximize potential. As the founder of the Institute of Leadership Coaching and Development, Chris is committed to helping others lead with respect, empathy, and compassion to build engaged, high-performing teams. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have a very special guest with me. I have Mr. Chris DiBella with us. Welcome in, Chris. Chris (00:13) Thanks so much, Brian. I appreciate you guys having me. Brian (00:15) Absolutely. We're very excited to have Chris on. Chris, if you're not familiar with Chris and his work, just a brief little introduction here for you. Chris has an MBA in project management. has a PhD in organizational leadership. He's an author and speaker. He's the founder of something called, actually founder and president, excuse me, of the Institute of Leadership, Coaching and Development. And he has a book that should be out right about now while you're listening to this called the leadership survival guide quotes to keep you from going extinct as a leader. So very, very interesting title there. I can't wait to read that. That sounds amazing. But the reason we wanted to have Chris on was one of the topics that Chris focuses on and talks about from time to time is the topic of influencing without authority. And I thought that's really, really interesting in the Agile world and how that relates to things like Scrum Masters and how we work within the organization and stuff. So let's start there, Chris. Let's just talk about where that, what does that title mean to you influencing without authority? Where did that come from? How did that enter your sphere? Chris (01:27) Well, I mean, for the last couple of years, it's a topic that's just been gaining a lot of momentum within the workplace. I guess the easiest way for me to describe the topic is to say that influencing without authority is simply the ability to motivate others to get them to take your direction. But we all know that the real world doesn't work that way. And it's not so easy to get people on board with our ideas and thought processes. So we just need to be more methodical in our approach. when it comes to influencing others. And it's more important now, particularly because when dealing with the different generational and personal generational differences and personalities in the workplace. Brian (02:06) I'm kind of curious how you define that difference. What does influencing with authority look like? What does influencing without authority look like? Chris (02:18) So they kind of both the same. think people sometimes fail to realize that influence is what actually provides power, right? And not authority. So they both kind of fall on the same lines for me. So when you're trying to influence others, you got to remember that with or without authority, you're trying to get somebody, you're persuading somebody, recently you're coercing them to try to get onto your thought process. So you just got to remember that. When you're dealing with them, that you have the capacity to impact what happens next in their lives. Their lives, sorry, not lives. like you have the ability to shape their actions and their behaviors and their opinions, but you also have the ability to have an effect on their character or their continued development. Right. And kind of adding a little bit more to that question is Ken Blanchard, said that the key to successful leadership in today's workplace is influence and not authority. So for someone to be an influential leader, they just need to learn the skills of confidence and clarity and communication. So that to me implies that even if you're not in a formal position of authority, you can still have an influence on those around you. So it's kind of just bouncing off. You know, there's a thin line of with or without authority. It's just understanding people and understanding how to get the best out of them. And you don't need to be called leader or manager to get that out of people. Brian (03:48) I'm kind of curious because especially with your background in project management, kind of more traditional project management, how does that play in project management? I mean, I've gotten in trouble sometimes in talking in class about this issue because I've, know, in my work history, my experience with traditional project management was very much one of... authority. was very much that that person who was the project manager, basically there was a date, a set of work that we're trying to accomplish. it seemed as if the project manager's job was to kind of drive the team, push the team, be the parent of the team, and make sure that they come in on time, on scope, on budget. How does the project management community in today's environment see this dichotomy between leading with influence or with authority. Chris (04:50) So that's a great question because I think, can I even touch on Scrum teams with this? Cause, cause I think they're, kind of go hand in hand for me. Right. and I, you know, from, if we use project management or Scrum teams as an example, right. No one, even as a project manager, right. No one has any real form of authority on the people side of things. Project managers really are just people put in place just to get things done. Right. They don't, they don't have an official title to get things done. Right. So it can be argued that. Brian (04:54) Yeah, yeah, yeah, please. Chris (05:20) while these individuals on a Scrum team or a project management team have no formal authority at all, that they're still ultimately responsible for project outcomes, right? Or it can be argued that an authority is inherently given to them based on their ability to act on behalf of all those objectives. Right. But the bigger point for me is that if there's no formal authority given, this could just limit the influence that someone has on the people in the processes side. Right. But that doesn't mean that you still can't be an effective leader who others look to. And this type of authority is based more on who you are as a person and how you treat others, as opposed to simply being viewed by that title that you possess. So I think there's there's a very strong connection there between Scrumteam and project managers. Brian (06:04) Yeah, I mean, it's a tricky thing because I mean, I think about this, like a lot of things, I'll make sports analogies and how I think about these relationships. And when I think about like the coach of a team, the coach can't make the players perform better. It has to be their own personal decision to do what they need to do. But on the other hand, we definitely hold the coach accountable if the team isn't doing well. And it seems almost like slightly unfair, you know, to think about this, that I can't really, I don't really have the authority to make that person do something. I have to, as we said, influence them to do it. Chris (06:50) So can I touch on that real quick? Cause you brought up a great analogy that I like to talk about from coaching perspective. So I used to coach soccer and if I start rambling, just tell me to shut up, but I'm licensed to coach up to a college level, right? But I always opted to coach at about the 12 and 13 year age group for boys and girls. And I chose this age group because I believe that this is just where I could have the most influence on them in their development and in their soccer growth, right? Brian (06:59) You Chris (07:20) The high school level and college level, they could still learn, but they've already got it in there at that age, right? They they've already established who they are on the field, their own identity, right? And they have a good enough skillset to go out there and play the game. But I wanted to be a part of getting them to that point. So I decided that coaching at a younger age group would just give me a better opportunity to mold those players into those high school and college athletes. And anyone listening to this with kids understands. how much influence we have on them at that age. But we also know how difficult it is to effectively influence them in a way that allows them to develop into their own person. So whether we're coaching 12 and 13 year olds, or if we're trying to coach and mentor our peers or our followers, there are just a lot of similar attributes that can be used to influence others to get them to achieve their goals and their successes and those outcomes. Brian (08:11) Yeah. Yeah, I completely agree. you know, it kind of, it kind of brings to mind the, mean, we've talked, we talked a little bit about project managers, but, and, and touched a little bit on Scrum teams, but you know, that, that relationship with a, a, a Scrum master, think is also really interesting to consider in light of this, because I know one of the phrases that we use as trainers a lot when we talk about the Scrum master is a Scrum master leads through influence, not authority. And that that's kind of a defining characteristic of what a scrum master does. What does that mean to you? Because I know you speak about scrum as well and you have a lot of knowledge in this area. So how does that translate into the role a scrum master would play? Chris (08:58) So if you take it from a Scrum Master perspective, right? mean, that's kind of positional influence, right? So that can come from someone's job title or depending on the hierarchical level of that role, you know, that can have an effect on how influence is also portrayed, either positively or negatively. So whether you're a Scrum Master or some other form of positional leader, it just means that you're followed by other people. So how you choose to impact their life. from an influential aspect will determine the level of followership that you're able to acquire from them. Right. And then kind of going along with that, again, you know, there's really no formal authority in that role, but the influence can stem from expertise and just being competent. Right. That provides you with the background and the experience needed to be recognized for people to go to you for that advice, the leadership advice. But if you also have the available resources that your team needs and you know how to acquire them as well as deploy them, then you're going to have an impact on their success as well, right? If you have the necessary tools to provide them, that's also going to increase the likelihood of them trusting in you as those relationships are developed because that's really what influence is. It's about building relationships and developing those bonds, you know, and then influence. The biggest thing for me with influence is being direct and transparent in your approach. Whether you're a scrum master, project manager, anybody with or without authority, if you're direct and you're transparent and you seem genuine to people and you have a firm, a fair, and a professional tone, that's just going to let other people know that you can be counted on, right? And that you genuinely have their best interests at heart. So that's kind of where earned influence will begin to develop. Brian (10:50) Yeah. You know, I, there's a, there's a kind of aspect of this I try to draw out too, when we talk about this in class and that influence, as you said, trust relationship, right? It takes, it takes investment. It's not, influence doesn't come instantaneously. When you think about just in general in your life, the people who influenced you. Right, to use that word influence, that's a shift, that's a big shift. And when you think about the people that influence you versus the people who tell you what to do. And from my perspective, most of the people I would say, yeah, I'm heavily influenced by this or by that. It generally comes from the fact that I have, even if they're a public figure, even if it's, know, you know, Simon Sinek or Gary Vanderchuck, you know, I would say they influenced me not because I just heard one quote, but because I've consistently heard what they speak on and consistently say, yeah, I'm aligned to that. And this is really influencing the way I think about stuff. So how would you advise, especially someone like a scrum master, you know, if they say, yeah, I want to lead through influence, not authority, but... I've got a job to do. How do they start paving that road so that the influence is invited? Chris (12:26) Yeah. I love the Gary V shout out because I love Gary. He swears a lot like I do. So I'm actually being pretty good right now. I mean, I guess the first question to ask is, you know, when you think of the term influencer leadership, not for you, but in general, like when you think about it, what's the first thing that comes to mind, right? What are you hoping to get or achieve through that influence? Are you trying to get people on the same wavelength as you? Are you doing it only to get people to see things your way? Brian (12:28) You Yeah. Chris (12:54) Or are you doing it to expand their perceptions and their realizations? Right. And again, there's often the assumption that if someone doesn't have authority, then they don't, or they can't have any influence. Right. And this goes back to with or without authority, but even with formal authority, it's still possible not to have any influence. Right. Influencing without authority begins with first identifying where that influence comes from. And then looking at how others perceive your level of influence. So. regardless of where that influence comes from, you still just need to build those relationships on that platform of trust and respect if you want to have those successful results achieved. It's tricky though, because depending on where that influence comes from, that's what's going to help to guide and even determine how those relationships and those bonds progress. Brian (13:40) So that kind of leads to the area of thinking about, if a Scrum Master is going to do that, we can kind of see how that fits in. And one of the things that I hear quite often with people in the classes is, especially when we come upon the section where we talk about Scrum Masters having an influence in the organization, that we have a responsibility to help the organization. understand Scrum and to get the benefits of Scrum. There's often a double take when that happens and the students in class think, well, I don't understand how can I do that? I'm not the CEO. I'm not a manager. I'm a Scrum master. How am I going to be able to change the culture? How am I going to be able to influence what the leadership thinks? about this stuff. What kind of advice would you give from that perspective? Chris (14:42) Well, much like I kind of take the leadership perspective, there's no one size fits all, right? To this and influence the same way. Sorry. Influencing is the same way. So there's different approaches that you can take to influencing, right? There's rational approaches where you kind of legitimize the use of like fact -based logic to influence others, right? And you could use within that rational influencing, you could use exchanging, right? As a form of bartering or trading where you do something for someone and they gives you something in return, right? Give and take. And that builds trust levels, but it's also an effective approach since each party is still committed to achieving that common goal. In addition to the rational, right? Again, different, different approaches that you can take social approaches, right? Think about the breakfast club, right? The movie, the breakfast club. Sure. Everybody who's listening to that. to this has seen that movie, right? To me, this is the perfect analogy for trying to influence somebody from a social perspective, because that movie just embodies the epitome of social approaches to influencing. If you think about it, you got five high school kids in detention from completely different backgrounds, right? And they're trying to outsmart their lesson inspiring principle. So they're essentially forced to have to work with one another to achieve that common goal. So when you socialize, That's essential when it comes to building that relationship and that trust, but that also helps to appeal to those relationships as those bonds are developed. Right. And then you kind of use consulting, which helps just to deliver like a collaborative working relationship that not only produces those results, but that also improves the dynamic and the relationships and the culture of the team and the organization. Right. And then if you add onto that, like in the movie, you know, that's just going to lead to the Alliance building, which kind of is like the creation of a team structure that'll enhance the growth and development of everyone involved. So I don't, you know, then there's also emotional approaches. There's what I call the dark side approach, which I don't recommend because it's, always think Darth Vader, right? The dark side, you, you lead by avoiding issues with your followers or your teams, right? You want to manipulate and you want to intimidate and you want to threaten, but those only serve the need of the person trying to get what they want. Right now. Brian (16:42) Hahaha Chris (17:00) Kind of be an effective way to get results, to get results. Sure. To influence others and build relationships. Absolutely not. Brian (17:09) Yeah, fear leads to anger, right? Right, exactly. Yeah, Chris, you are speaking my language, talking about breakfast club, 80s movies and Star Wars. I come on, this is my wheelhouse here. Yeah, no, I agree. it's, you have that great example. I'm gonna go into the analogy here. Chris (17:12) It does, know, resentment, you know, it's... huh. Bye! Brian (17:38) You have that great example with that principal or vice principal, whatever position he had, that he came in with the authority figure approach. I'm in charge, you are underneath me, you will do what I say during this time. And it wasn't, hey, let's get through this, let's figure out the best way to make the Saturday go by. It was very much, are in need of my My heavy -handed approach otherwise you're gonna go off the rails and You know, there was no respect there was no relationship there It was it was purely, you know prison guard kind of mentality and you know, there's a There's an example. I always think back to You know, I played football in my high school days. I didn't I played some football I didn't I didn't play all the way through high school, but I played some football. So if anyone happens to be from my high school, no, I did not play my whole high school career. I know that I'm admitting it. Okay. But I remember, you know, for most of my football career, which was very short, I had coaches that were all of one type, which was the screaming head, right? They were the person that would yell at you and chew you out and try to motivate you in that way. Chris (18:35) you Brian (19:05) but I had one coach and he was the last coach that I had who was the head coach of our team. And he was a very soft spoken, quiet man. And I remember him in one practice pulling me aside and saying, hey, look, you're gonna have to do it this way. You're not gonna be able to do it this way. It's not gonna work. If you wanna be successful with this, this is what you're gonna have to do. And I just remember in that moment that I... paid more attention in that moment to anything anyone had ever tried to coach me in the past. And I remember feeling earnestly this desire that I want to please this man. Like I really want this guy to think highly of me and I want to give him my best. over the years since that moment, I've thought back to it lot and thought, that's a clear contrast. since the majority are the other way, that that one person who took this different approach really had this different impression on me of, yeah, this is, and to me that was a great example of leadership. Chris (20:17) Yeah. It's funny. Like you mentioned that when you had that cool, calm and collected approach, right? But that can also kind of be taken the other direction. And the first thing I think about with that kind of approach in a negative way is, Bill Lumberg office space, right? Right. Yeah. If you guys can just come in and come in on Saturday or Sunday, blah, blah, blah. Right. So again, so like that type of leader and, know, to stand on the negative, cause I like to focus on negative stuff because it kind of gets people thinking about what not to do. Brian (20:31) Yeah. Okay? Yeah. Chris (20:45) So like that type of leader, you know, they focused on that power, that title to impose their will on others. Right? So like you had what sounded like an influential kind of perspective from that cool, common, collected tone. Bill Longberg was cool, common, collected, but he was just a jerk. I'll say it without swearing. He was just a jerk. Right. But it's when we're at moving into a position of leadership or someone who wants to influence others. Right. It's we look at people like that and they, it's. Brian (21:02) Yeah. Chris (21:15) They look to lead from a place of authoritarian status, right? Again, the, my way or the highway approach, but this may stand from two different schools of thought, right? Because either it's the only way they've been taught to lead others or it's to intimidate others into submission. And I'll be completely honest with this by my own admission, I was that type of leader when I took on my first leadership role. Right. I'm Gen X. I had observed this leadership mentality throughout my early career. And I just assume that that was the attitude that got others to follow direction and achieve results. And it wasn't until that I realized this approach was not in fact effective and that there didn't need to be a brutish mentality, but I just needed to transform my mindset and adapt to the individual needs of each person on my team so that I could figure out how to get the best and the most out of them. So it's a learning curve. I mean, you're not going to get it the first time you get put into a position of leadership or the first time that you're tasked to influence people, right? You're not going to know what to do. But our leaders that we grew up with are going to be a huge inspiration. And I always tell anybody, no matter what, you can be an authoritarian leader or you can be a transformation leader. You are a person of influence, no matter what you do. And I always say that anybody in a company can be a person of influence. But if you're tasked with that, if you, you're given that role, whether you want it or not, you are a person of influence and you're going to have an effect on someone's character or continued development. whether that's good or bad. It's up to us as we evolve and we mature and we grow and we develop to figure out the good from the bad and figure out how to move forward in a positive, more positive direction to get the best out of the people that we're now influencing and that we're leading. Brian (22:54) Yeah. Yeah. It's such an interesting dynamic because I think you're right. There's authority that people have sometimes that just is sort of a natural thing. This is a very loose analogy, but I know I've been involved with groups of people who are tasked with doing something kind of ad hoc things thrown together for volunteer things or whatever, kind of things where you're not really in an organizational structure. but a group of people come together to do something. Maybe it's in a class or whatever. you know, sometimes you have that one person in the group that, sort of starts a little bit to be the leader of the group. And I've been in the case where the person sort of takes leadership, right? Where they, kind of try to, to just grasp it and control it and tell people what to do. But I've also been in a situation where that person sort of just emerges and the rest of the team is not reluctant to follow them. They're actually thankful that they have someone that can lead and guide them. And there've been occasions when I've been in those situations where that one jerk in the group will speak and say, hey, well, who made you boss? again, I understand if the person really is being bossy. But I've been in situations where the person's not being bossy and someone has said that, and the rest of the group actually turns hostile on that person. Because they're like, what are you talking about? They're doing what we need someone to do. And they just naturally kind of float into that. So I always think about that when I think about when people ask, how am I going to influence this organization when I don't have any authority in the organization? Well, leadership isn't about a title. It's about a how you approach things, right? Chris (24:53) Not anymore. used to be about a title, but it's not in today's workplace. It's just not, you know, again, I grew up in a different time where it was pull up your big boy pants, do your job. You know, my boss could talk to me any way they wanted. I wasn't going to take offense to it. wasn't going to take three days off to have a safe space. You can edit that out if you want, but I, you know, I just, you know, but it kind of speak adding onto what you just said about that, right? You had somebody who wanted to take that charge, but you had somebody else who wanted to. Brian (25:10) Yep. No, no, no. Chris (25:23) you know, who made you boss, right? So how do you influence through tension and conflict? Right? Because if you have somebody who wants to take the reins, but you have somebody combating them, now you're going to, it's going to create, somebody outwardly speaks against that person, that's going to create that tension. Right? So, you know, it comes down to like, how do you influence others when you don't agree with their choices or how they approach things in an influential. approach, right? Particularly when it comes again to those cultural and those generational differences. Right. And this is going to sound harsh, but how do you influence people when you just don't like them? Right. We don't like everybody that we work with. Right. And you're going to have to work with these people. And if you expect to be a person of influence, you got to suck it up and you just got to figure out how to get the best and the most out of them. Right. So again, it's during those times, right? It's just important to identify why it is that you want to influence people in the first place. Brian (25:59) Yeah, yeah. Yeah, that's why I'm glad that like a scrum value is not like everyone on your team, right? I mean, it's respect and you should have respect for people even if they have a difference of opinion with you, which we were talking about this a little bit before we started, just the idea that, you know, we can exchange ideas and we can have a difference of opinion on ideas. That's not a problem, right? That's just trying to figure out the best idea. We're challenging the idea to see which one is the best approach. It's only when that becomes a personal thing, when it starts to become about the person, not the idea, that's when it's, well, that's when it turns into a destructive conflict. Chris (27:04) Yeah, it's, you I always like to say, think leadership or influence comes down to three simple words. Respect, empathy, compassion. If you can figure out how to master those three words, which I think it's virtually impossible to master them. But if you could figure out how to have some sort of ability to figure out how to use those words, you can lead anybody. Right? It doesn't matter. As long as you can have respect for them, show empathy, put yourself in their shoes for why they might be feeling a certain way. and have compassion for why they feel that way. Try to understand where they're coming from. Brian (27:37) That's awesome. I love that. Respect, empathy, compassion. I think that's a great place to end it. So Chris, thank you so much for coming on. I really appreciate you sharing your thoughts and wisdom with us on this. And just again, I'll mention this in the outro, but look for Chris's book that's out now, Leadership Survival Guide Quotes to Keep You from Going Extinct as a Leader. So Chris, thank you so much for coming on. Chris (28:03) Awesome, man, I appreciate you having me. It was fun.

Pooja Gupta: Aligning Team Members With Their Strengths, The Key to Agile Team Success Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Pooja shares the story of a team filled with competent individuals but plagued by conflict because they were not in roles that helped them express their strengths. She discusses the importance of aligning team members' skills with the right stages of the project and introduces the Shape-Up methodology (also available in print from Basecamp) as a framework for navigating these challenges. Pooja highlights how understanding the team's goals and using conflict management frameworks like the Grow model can lead to a more harmonious and productive team environment. What strategies can you use to align your team's strengths with their roles and avoid destructive conflicts? Listen to find out!   Featured Book of the Week: "Reinventing Your Life" by Jeffrey Young et al. In this episode, Pooja discusses the profound impact the book "Reinventing Your Life" had on her personal and professional growth. She explains how understanding different personality types has helped her stop trying to change others and focus on her own behaviors instead. Pooja emphasizes the importance of self-awareness and non-judgmental perspectives in working with diverse teams.    [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!   About Pooja Gupta Pooja is an Agile Coach at Visma Solutions and Agile Community Lead for Visma Group. With a passion for "limitless learning" and "selfless teaching," she brings empathy and a people-centric approach to her work and everyday life. Based in Helsinki for 9 years, she finds balance through yoga, meditation, and family life. You can link with Pooja Gupta on LinkedIn.

Discover how recognizing and accommodating different collaboration styles can transform your Agile team dynamics. Join Brian Milner and Jessica Guistolise as they delve into the key to effective and inclusive collaboration. Overview In this episode of the Agile Mentors Podcast, Brian interviews Jessica Guistolise about the diverse collaboration styles that impact team dynamics. They explore the importance of recognizing and accommodating different collaboration styles—relational, expressive, and introspective—to create effective and inclusive collaborative environments. Jessica provides practical tips for Scrum Masters and facilitators to cater to these styles during meetings and retrospectives. The discussion emphasizes the value of diversity in collaboration styles, which brings different perspectives and ideas to the table, fostering creativity and innovation. References and resources mentioned in the show: Jessica Guistolise Lucid The Collaboration Style Quiz & Report The Global Scrum Gathering Advanced Certified ScrumMaster® Certified ScrumMaster® Training and Scrum Certification Advanced Certified Scrum Product Owner® Certified Scrum Product Owner® Training Join the Agile Mentors Community Mountain Goat Software Certified Scrum and Agile Training Schedule Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Jessica Guistolise is an Agile Evangelist and coach at Lucid who excels in helping organizations deliver continuous value to their customers. With a passion for people over process, she specializes in change adoption, gaining critical buy-in, and establishing trust in Agile methodologies across various industries. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have a special guest with us. have Jessica Gastolis with us. Did I say that correctly? Jessica Guistolise (00:14) You did. Thank you so much. It's a mouthful. I am so happy to be here. Thank you so much for inviting Brian (00:21) Absolutely, incredibly excited to have you here. For those who aren't familiar with Jessica, she is an evangelist at Lucid. So I'm sure we'll hear a little bit about that as we talk. She is an agile coach and she has the credentials to back that up. She has from the Coaches Training Institute, a professional coach certification and also she's an ORSC coach, if you are familiar with that. I'm familiar with that. I know there's a lot that goes into getting those. So it's not just, you know, filling out a, sending in some box stops and, you know, getting it back in the mail. and, so the reason I wanted to have Jessica on is because she was speaking at, or she did speak at the scrum gathering that just took place, back in May. And, she had a couple of talks actually that she did with, Brian Stallings there. but one of them really caught my And I thought it would be interesting here to the audience. And that's about collaboration styles. So let's dive into that topic. When we talk about collaboration styles, Jessica, don't we all collaborate the same? Jessica Guistolise (01:33) You know, it's funny, we don't actually. Though, although there is a kind of a misconception that we do because we collaborate in the way that we collaborate, but not everybody collaborates in the same way. And so for us to create really amazing collaborative environments, it's helpful to have an awareness of those different styles. And if we facilitate in such a way that cares to each one of those styles, you're gonna get so much more in the room than you would if you only stick with, well, here's how I collaborate. So obviously this is the way to do it. Brian (02:09) Right. Yeah, I think this is such an important topic because I know one of the questions I'll get a lot in classes or just even in Q &A sessions when we talk about retrospectives is, I'm having a hard time facilitating my retrospective and my team doesn't want to talk or my team's quiet and shy. And to me, this is all kind of indicative of this concept of you're probably not recognizing that they have different collaboration styles than you do. Jessica Guistolise (02:41) Yeah, absolutely. And it's so amazing because I think as Scrum Masters, as Agile Coaches, this is a really important piece to recognize because as the facilitator, you're really building the container. think of these events as like the containers and the folks who are doing the work, they're all the content. But if you build a container that's going to allow for that content to emerge in a healthy way, you just, I mean, Anything's possible. Brian (03:10) Right, right. And you know, one of the things I love to say in classes is just that, you know, that facilitation, that's the root goes back to this phrase, it means to make easy. And you know, that's our job is to make whatever that thing is easy. And if we are, if we're not aware of our own personal preference and style and how we collaborate, then it's harder for us to even be empathetic or recognize that other people have different styles and much less how to accommodate them and be inclusive of them in those environments. So I just think it's a really important Jessica Guistolise (03:51) Well, and the interesting thing too, besides easy, there's also an element of safety. Because if you're asking me to collaborate in a way that makes me really uncomfortable, then I'm spending all of that time in my discomfort and trying to put forth ideas. Those two things are so, they clash. And so there's also an element of just creating an environment of not just easy because this is the way that I collaborate, but I feel safe in collaborating in a that make sense to me. In fact, there's some, there are a couple of styles that are almost opposites. So if you're asking me to collaborate in that way, ooh, I am not sharing anything with you. Brian (04:31) Right, right, you have that amygdala hijack going on. You're kind of, you're in that fight or flight mode of just, my gosh, I'm panicked. I don't want to do this. I feel highly uncomfortable. you know, it's, can, you know, literally it's blocking those neural pathways of actually being able to collaborate and access, you know, the parts of your brain that would allow you to, to contribute in that kind of environment. Jessica Guistolise (04:59) Yeah, it's fascinating actually, right before the study that was done came out, I was in a collaboration with a group of people who were collaborating in a way that was wildly uncomfortable. And I came out of that meeting feeling dumb. Like I really was like, wow, I didn't, I just gave nothing. But then, you know, a little while later I was like, well, but I have this idea and this idea and this, wait a minute. I was just stuck because this isn't a way that's very comfortable for me. Brian (05:28) Yeah. Well, you know, I know you probably know this, but for anyone else listening out there as well, I have definitely felt that way as well in sessions that were kind of contrary to, you know, opposite of what I prefer. And, you know, the way I always describe it is I don't, I'm not a person who thinks out loud. I think internally, I think quietly and then express it later. I need time to process and work through things. But I recognize there are others who are verbal processors who need to speak out loud and and You know if you're in a meeting with a bunch of those Types of people who have that collaboration style and and yours is a quiet one Then you know I've walked out of those rooms before feeling like gosh I'm the dumb one in this meeting because I didn't have anything to contribute Jessica Guistolise (06:12) Yeah, I didn't provide any value in that, but there is, there's so important to recognize that. And I think there's, there's, there are ways to create these containers and to create these collaboration sales that really help to make it so that everyone can feel comfortable collaborating in the way that is going to be comfortable for them. And it just, it's, you know, it's the facilitator work of being prepared. Brian (06:16) Right, right. Jessica Guistolise (06:38) preparing for the meeting or the event, creating the container in a way that's going to be safe, comfortable, and easy for everyone. Brian (06:45) Yeah, absolutely. All right, well, let's get to the meat of that then, because I know there are a few, you kind of delineated these in the presentation that you had. So walk us through, what are the differences in these different kinds of collaboration styles? Jessica Guistolise (06:59) Yeah, so the study was done, Lucid did a really interesting study. I was so excited by this. And what they found was over half of knowledge workers identify with one of three collaboration styles. And the other part of that is you may not land fully in one of the three and you may have kind of a blend of them, but these are the ones that we see most often. And one of the things that I always like to point out too is that none of these are Like it's just the way that you feel comfortable. They're all really helpful and healthy and really great ways of coming together. So I'll start with the one that I most identify with because it makes the most sense to me. That's we normally create collaboration is we see how do I collaborate and I'll collaborate with you. So the first is relational. And so relational collaborators really want that human connection. Like they want to be, they want to spend some time. How was your weekend? Or just if it's a brand new person, let's get to know each other a little bit before we dive into trying to solve problems. there's it's, it's almost like, for me, I just feel like I need to be in relation with, in relationship with someone before I'm comfortable collaborating. It's like, the metaphor I like to use is, is like baking bread. If I'm in relationship with you, I'm gonna bring you ingredients and recipes and stuff that I'm playing with and trying to figure out. But if I'm not in relationship with you, I will have that entire thing baked and then bring it out and see if you like it. But that's not collaboration, right? That's me by myself and how much better is the bread gonna be if somebody says, well, let's try this and let's try this and let's try this. So that's a relational Brian (08:49) So that sounds like that one in particular needs just a tremendous amount of trust to be effective. Jessica Guistolise (08:55) It does. really does. And I actually, I'll tell you a story about this because, so I, I was working with, an individual who had an interesting problem to solve another agile coach. and he'd come up to me and he was like, I have this interesting problem. Do you have anything in your coaching toolbox or knapsack that you can pull out for me really quickly? And I was like, Hmm, you know what? actually don't. but let me think about And so I went, was doing some other things and sort of in the back of my brain. And then I had just an absolutely ridiculous idea. I mean, it was like, I, I felt silly even thinking it, let alone saying it out loud, but I was in really great relationship with this other individual. So I ran across the hall and I said, okay, I have a really dumb idea. And he goes, okay, let's hear it. And I told him, and he goes, wow, that's really dumb. Let's play with it. And so we played with it and got it into something and he took it back to the team and it worked spectacularly. And I think he's still using it today as an exercise that'll help with the team's collaboration. but if I hadn't been in relationship with him, I would have had that dumb idea and then I would have let it go. Brian (10:10) Right, right, because you know, you don't want to get made fun of or you don't want to be made to feel dumb or anything. So yeah, absolutely. You got to have that trust and sense of safety with them to be able to bring it up. That's a great Jessica Guistolise (10:23) Yeah. The second one is one that I wish I had more of and I just don't. So some people identify as expressives. If you're an expressive collaborator, you are ready to dive in at any moment. Like somebody can throw out a topic and you've got, you're the first voice in the room. You love using visuals and drawing out your ideas and throwing up sticky notes and emojis. You're one of those people that's I'm ready to, I'm just ready to share. I really wish I had more of that. Sometimes I think of them as blerters. Like they're just willing to blurt it out. Whatever is there on top of mind and a brainstorm. And I just, think that's so admirable and it's just not a skill that I have. Brian (11:09) So less of that filter then. mean, it sounds like they don't necessarily need to have that basis of trust. They're just sort of always willing to say what's on the top of their mind and get it out in the open. Jessica Guistolise (11:22) Yeah, yeah, I think it's a great way of expressing themselves. And they also have maybe a harder time spending that time getting into relationship and all of that ooey gooey stuff. And they're like, let's get to the work, you know. But if we have an awareness that I as an expressive am working with a relational collaborator, some of the work is getting into relationship. So now I feel more comfortable spending that time because I know that the work we're going to do after that is going to be greatly Brian (11:57) And correct me here if I'm wrong, because I'm just trying to make sure that we're understanding all speaking the same terminology here, but it sounds like the way you describe this, that expressives are not necessarily verbal expressives. Like you mentioned, someone who's more sketch note based or anything like that. So they may not feel comfortable speaking, but they're very comfortable with the concept of getting an idea out of their head quickly in one way, or Jessica Guistolise (12:26) Yes, exactly. It could be in visual form. think of like people who always have memes or GIFs at their fingertips. Like they're just ready to go and send out these their ideas into the world and not hold on to them tightly. know, they hold them on, hold on to them, Lucy, please, because they're coming out in the world. Brian (12:44) Hold on loosely, but don't let go. Awesome, I love that. Okay, and then was there another one? Jessica Guistolise (12:52) There is. So the last one is introspective. So an introspective collaborator, I dip my toe in introspective collaboration as well. Deep work is really, you love deep work. Spending time really processing, thinking through, chewing on an idea, tossing, playing with it a little bit yourself before beginning to share. It's the opportunity to do some research, do some brain writing, spend some time in ideation. And you might even feel comfortable having a conversation with one person rather than if you have a giant group of people sending them into breakouts to have individual conversations. sending out thoughts about what's going to happen before the meeting or the event so that they've got that time to themselves to say, here's what I'm thinking about this topic. before throwing them into a room with a whole bunch of people and expect them to just go. Brian (13:57) Right, right. Yeah, no, I mean, of these three, yeah, that one sounds very close to what I would identify with for sure. And yeah, I mean, I think one of the characteristics I would kind of try to relay that home to everybody is I love when a collaboration session spills over across days because I love having the ability to go home and sleep on it Jessica Guistolise (14:18) Yes. Brian (14:24) you know, when I'm walking my dog or getting ready in the morning and the shower or something that that's when the brilliant idea will strike is when my brain is actually distracted and thinking of something else. That's when I can really think about things. And I, I feel like I need that time to sort of let it percolate and kind of, you know, seep in a little bit before I can come back and really contribute. Jessica Guistolise (14:46) Totally. One of the things that I really appreciate that we do at Lucid. So that meeting that I was talking about where I walked out and I went, I provided zero value in that meeting. We've got an open board for that for after. And there's an expectation that if you have ideas afterwards that you have the opportunity to come back to it the next day or the day after that. It's not, okay, we collaborated, close this. That's it, we're done. but you actually get the chance to do some of that asynchronous follow on day, day after kind of collaboration. Brian (15:20) Love that. Well, and two, Scrum Masters out there, hear that, listen to that, right? Think about that from that kind of a meeting. This is just a normal meeting, right? But we sometimes can get so structured into the idea of a retrospective being only at this time and this confines, and we have our time boxes and everything else. But yeah, if we can have some spillover time as well, pre or post, right? Just having that ability Jessica Guistolise (15:30) Hm. Brian (15:49) let people think through and contribute after the fact, that can really deliver some great results and allow you to include all these different collaboration styles. So then relational, expressive, introspective, these are kind of the three styles that you guys highlighted in your talk. All right. So let's say I'm a Scrum Master and I might identify with one of these. How does that help me? How does that help me to do my work with my Jessica Guistolise (16:23) Yeah, fantastic. So Brian, you immediately recognize your own sort of tendencies or collaborative tendencies, collaboration styles. But if you think about those you work with, do think you could kind of identify what different styles other people you work with on a regular basis might have? Brian (16:43) Yeah, I think so. mean, most people who are listening to this know my boss. I would, it's kind of funny. If I was going to try to pin Mike Cohn down in one of these three. Gosh, you know what's funny is I'm not sure because he sort of has a blend of all three. Jessica Guistolise (17:08) Well, that's absolutely like I mentioned, I'm sort of I'm a relational with an introspective kind of toe in introspection. And so I think there's a lot of people who are a little bit of a mix. And so the easiest thing to way to find out is to ask, share what these styles are, and ask what find out what's going on with your team, if they were to self identify, because it's easier to self identify, obviously, And then now you've got a great understanding of what's going on with the rest of your group. It was so fascinating to me when we did the conference talk, we had everybody self -identify and then collect in your self -identified group. So all of the expressives were together, all of the relationals were together and all of the introspectives were together. And then we had them do some work together and they were describing what helps them. to collaborate best. And the expressives were loud and they were right away writing all over the sheets of paper that we had for them. were, you I mean, it was like, it was a boisterous part of the room. The relationals immediately, hi, I don't think we've met yet. Let's get to know one another very quickly. You know, what do you love about your collaboration style? I mean, they really spent that time getting to know one another. And they were kind of coming to consensus before, Brian (18:23) Hahaha Jessica Guistolise (18:35) before writing anything on their page, because they were making sure that everyone was relating and getting their voice in. The introspectives, quiet, quiet, quiet part of the room, and they all had sticky notes and they were writing their ideas and then they were putting the ideas next to each other that might be similar, and then they started having conversations. So as a scrum master, as a facilitator, to know what your team's style is, is again, going to help you create the experience of inviting each one of those styles to collaborate in ways that best work for them. I mentioned introspectives, send out the agenda beforehand, make sure that they know the topics, have some silent brain writing time, because expressives are going to start putting their stickies out anyway, but allow that quiet moment to be there to accommodate those styles. You may put them into breakout rooms or have them meet with one other person. Especially if you've got like a larger collaborative of that, where you've got a bunch of people together, one -on -one first, then maybe four -on -one, know, one, two, four -all kinds of experiences are going to help those introspectives be able to bring their voice forward. You'll also have a moment of connection. Nobody likes icebreakers, so I think of them more as like relationship activities. If we're going to have a relationship activity, that feels way better than an icebreaker. Brian (19:52) Ha Jessica Guistolise (20:00) And spending time really allowing for, how are we feeling today? Let's bring some awareness to what's going on collectively as a group. All of that is helpful because then your relations, they've gotten their relationship moment. They feel connected to the people that they're working with, which means they're going to feel connected to the work that they're doing. So that connection before content allows the contact to be significantly improved. and expressives, give them the space to do it. mean, really allow them to be that voice in the room that jumps in and gets everyone excited. They bring people along. So building your events in ways that allow people to bring, be their best collaborative self is so helpful. The other thing that I think is really helpful trying to make sure you've got diversity of collaboration styles on your team. I'm a huge proponent of DEI and diversity and bringing together wildly different perspectives and ideas. And I just think that all of these interesting and complicated human problems that we're trying to solve need interesting, complicated humans and interesting, complicated teams. Brian (21:20) Hahaha Jessica Guistolise (21:22) And if you've only got introspectives on your team, there's going to be these relation, relationship type thoughts that are going to be missed and same with expressives. And so I think as you're building out a team, or if you have a team, just thinking about like, Ooh, do we have a diversity of collaboration on our team? And am I making sure that each one of those styles are cared Brian (21:44) Yeah. Yeah. I mean, like we, I know we talked about this quite a bit on our podcast. know, there are different neuro types, people think in different ways, people have different preferences and you're absolutely right. You know, what, what we need is people who see things from different angles. you know, if we all see things from the same perspective, then we're, don't have anything really to share. We all can just observe one thing and give our own perspective on it. But how much better is it if you have someone who's standing on the opposite side and says, wait a minute. There's actually another dimension to this that you guys aren't really able to see and bringing that to the table can make all the difference in the Jessica Guistolise (22:20) complete difference. And isn't it more fun? Everybody thought the same things that I did. Boy, the whole, it would just be boring. And it's a delight to see the ways in which other people see things and to go wander over and see their perspective. like you said, it brings more dimension to the things that we're working on. Brian (22:45) Yeah, and at the end of the day, we need some of that conflict. It's not all conflict is bad conflict, If I have a different viewpoint than you, then you're challenging my way of thinking and I'm challenging yours. And hopefully we end up at an endpoint that is a better endpoint because it's been challenged, because we haven't just accepted as rote what somebody thought. Jessica Guistolise (23:14) Absolutely. I'm totally agree. I think healthy conflict, healthy conflict and collaboration is, is helpful. I collab. I should have said in that moment, I don't collaborate like this. Can we get to know one another? And I probably would have met some folks in the organization that I, because it was, it was not people that I spend a lot of time with on a regular basis, I would have met people across the organization that I would have. Brian (23:28) Right. Jessica Guistolise (23:43) would have liked a number. Brian (23:45) Well, and I think it's amazing how powerful it is to have a name for something and be able to just kind of say, hey, this is what this means and this is what this is behind this. And if I know I am relational, then I know kind of what I need to be successful. I know what's gonna set me off. I know what's gonna be difficult for me. And I have a much higher likelihood of being productive in that kind of environment because I'm aware of those sorts of things. I think I know the way that you guys started was to try to get people to understand a little bit about where they were first before thinking about others. And I think that that was a genius way to approach that because I think you're right. You kind of know where you are on the map a little So yeah, we've talked about this a little bit when I kind of did my research and work on neurodiversity and different neuro types and stuff and how these different things relate. yeah, it's just like we were saying, right? You need different perspectives. You need different kind of approaches to problems if you're going to solve them and think in different ways when you approach issues. All right. If we understand there's relational, there's expressive, there's introspective, we kind of can pin where we are. We're starting to see where others are. How do I put this into practice? If I'm designing a retrospective, let's just say, and I know my team is made up of, I got five people, I got, you know, of three introspectives and two relationals on my team and no expressives. How's that gonna change how I prepare my Jessica Guistolise (25:36) yeah. Well, probably don't just have them start talking about it. I mean, so, you know, as you're thinking through the as you're thinking through the five stages of a retrospective, what you might do is like, okay, so if I'm going to open the retrospective, how might I open the retrospective in a way that's going to cater to my relational? That's an easy one to grab on to, right? Let's let's talk about Brian (25:41) No open discussion, Jessica Guistolise (26:04) What's something interesting that's in your wallet or your purse or just something that's gonna help the group begin to be in relationship with one another? You'll wanna have some quiet time. Allow them to spend some time on their own thinking about what happened over the course of the last week before you even start throwing things up. You might have just a five minute, close your eyes walk yourself through the last sprint and think about what were the big things that happened before even going into the writing. There's some really nice introspective time to chew on what happened, what's going on. You may put them, like I said, in small groups of two or three instead of having them come together to try to come up with experiments as a whole wide group right off the bat. So when When you figure out, here's the things that we want, here's the topics, here's what the data is telling us, and here's what we want to run an experiment on. Again, allow for that time to go back and really chew on. So we have this thing that we want to work on in the next iteration. So I'm going to spend some time thinking about maybe 10 different ways that we might experiment on that instead of having the whole group have that conversation right off the bat. So there's a whole bunch of different things you could do. to kind of unlock the collaboration in all of your team members. Brian (27:37) Yeah. Yeah. We were talking a little bit before our podcast about how we're music nuts and, you know, really get into that world. you know, the ideas crossed my mind. It's sort of like, you know, when you think about composing music or you think about a piece of music, right? If everything wasn't a major key, that would get boring. You know, we like to have minor keys on occasion or sometimes augments. augmented keys or different time signatures and different rhythms and things that kind of come to play in a piece of music. And sometimes we'll even shift those in the course of a single song. So if you think about a retrospective kind of in that or a facilitation session even larger than a retrospective, but just any facilitation session, right? You don't want it to get boring. You don't want to just cater to one thing. You want to be able to have some variety and that makes it interesting that keeps people's attention. Jessica Guistolise (28:32) Please. It does. mean, think about just even how you might shift things up in a daily scrum. Every day come to it, okay, so today we're gonna do an expressive scrum. Warn your introspectives that that's coming. Today we're gonna do a relational scrum, daily scrum. Think about how you might add these elements into your planning session, because that's a deeply collaborative session, and you wanna make sure that there's space for each one of your collaborative. collaboration style team members to have the ability to you I think everybody would be surprised how much more information comes when we feel comfortable collaborating in these different styles and There's edges in each of us right so helping to kind of Walk those edges I've I have been working really hard on trying to be more expressive I asked expressives. How do you do that? And really a lot of it is I don't hold my expresses, the things that I express tightly. They're just ideas and I'm willing to just throw them out. And so for me, that's an edge for me that I can walk up to. And so you can help your team members because they're not always gonna be on a team that has an understanding all of these styles exist. Although as a team member, I might say, hey, let's all talk about our collaboration styles real quick as a part of our working agreement. But you may find yourself on a team that doesn't have that same understanding of the collaboration styles. And so if you work on kind of moving that edge further and further, you're stepping into it a bit, then you're going to be more comfortable collaborating in multitudes of environments. And ladies and gentlemen, and all of those in between, We want to hear your voice. so doing the self work in some of that I think is also really important. Brian (30:37) Absolutely, yeah, I couldn't agree more. Well, I can't thank you enough, Jessica. Thank you for taking time out and coming in and explaining this to us. It's just, one of the joys of getting to do this kind of thing that I get to have these kinds of conversations with the Agile community and different members of our community. So thank you for making time and sharing your wisdom on this with everyone. Jessica Guistolise (31:00) Yeah, thanks, Brian. This has been an absolutely delightful conversation. And if people want more information on the collaboration styles, there is a report out there. And with the report, there is also a quiz you could take that says, wait a minute, what is my collaboration style? And you could have your whole team take the collaboration style quiz. And then you'd really have an understanding of where is everybody at? And how can we make sure that their voice is in the system? Brian (31:22) That's an awesome suggestion. We'll definitely put that in our show notes, too. So we'll make sure everyone can just find that in our show notes and not have to hunt for it or anything. But that's an awesome suggestion. Well, again, thanks, Jessica. I appreciate you coming on and speaking with us. Jessica Guistolise (31:39) Yeah, thank you so much for having me. It's been a delight.

Keir Lumsden: When Feedback Loops Fail, And What Scrum Masters Can Do To Help Their Teams Apply Empirical Processes Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Keir shares a story about a team struggling with a lack of empiricism, where feedback loops were missing, and progress was unclear. Despite having a bonus on the line, the team couldn't grasp their situation. Keir used visual tools like a burn-up chart to create the necessary transparency, ultimately sparking the critical conversations that led to change. Are your sprint reviews providing the feedback your team needs? Keir shares tips on fostering transparency and ensuring teams can showcase tangible progress. Featured Book of the Week: "Adapt: Why Success Always Starts with Failure" by Tim Harford Keir discusses "Adapt" by Tim Harford, a book that explores why success often starts with failure. Harford argues that solving complex problems requires practical experimentation rather than theoretical plans. How do you approach problem-solving in your team? Keir highlights key insights from the book, emphasizing the value of hands-on solutions and the lessons that come from iterative learning. [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Keir Lumsden Keir Lumsden joins us from the UK. A former developer, Keir has been fully immersed in Agile practices for the past 10 years. With a mind that constantly seeks lessons beyond the realm of software development, he enjoys writing and speaking about these insights. You can link with Keir Lumsden on LinkedIn.

Being Too Precise Hurts Your Plans - Mike Cohn I need a new backup drive. I don't need a 40 TB drive but the site I buy from listed one available. I thought I might as well click on it to see the price.The price seemed reasonable for that much storage, but what caught my attention is that the drive ships in 205 days.Seriously, what are they thinking? How can they possibly know the drive will ship in 205 days, not 204 or 206?This website fell into what I call the precision trap, which is applying a false level of precision to some estimate or plan. We often fall into the precision trap because of the math involved in planning.Let me clarify this with an example. Suppose a team has estimated that it needs to deliver 100 story points of work to achieve some objective. They've already calculated their velocity to be 15. Someone on the team does the simple math of 100 divided by 15 and gets 6.66. Team members then proclaim that they will be done in 6.66 sprints. Or hopefully someone decides to round that up and say it will take 7 sprints.But math like this leads to the precision trap. You can see from this how the website decided the drive would ship in 205 days.The precision trap persists because we seem wired to like precision. It feels good to say we'll be done in 6.66 sprints. We must be really smart to know that.But we need to favor being accurate over being precise. Accuracy is about being right. The easiest way to be right is to be less precise.For example, that website could have told me the drive would ship in “about 7 or 8 months.” That would have been enough precision for me to decide whether to buy it.When math tells a team they can deliver in 6.66 sprints, that is very precise. But it's probably not very accurate. Just like the ship date of the hard drive, that estimate should be conveyed as a range. Instead of 6.66 sprints, maybe it's 6 to 9 sprints or even 7 to 10 sprints.Avoid falling into the precision trap if you want to succeed with agile How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

James Gifford: When Autonomy Becomes Anarchy, Navigating Agile Team Independence Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. James shares a story from a healthcare company formed through acquisitions. He explores what happens when team autonomy goes too far and becomes anarchy. James also describes how one team's culture shifted from a focus on quality to a lack of basic practices, leading to degrading product quality. What non-negotiables did James identify as crucial for balancing team autonomy with organizational standards? How can leadership play a role in setting appropriate constraints for autonomous teams? Listen to find out! Featured Book of the Week: "Turn the Ship Around" by David Marquet James discusses the profound impact of "Turn the Ship Around" by David Marquet on his approach to leadership development. How does this book's principles apply to creating effective leadership at all levels of an organization? James shares insights from his experience developing a leadership curriculum aimed at empowering decision-making at the front lines. What key patterns does he highlight for leaders looking to succeed across various organizational levels? Listen to find out. Note that David Marquet has been a previous guest on the podcast. [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About James Gifford James Gifford, a notable Agile/Lean coach and ProKanban Certified Trainer, is also a co-founder of Agile Uprising. He envisions a future where companies integrate Lean principles and Agile methodologies effortlessly, cultivating organizations that are dynamic, resilient, and centered around customer-focused products. You can link with James Gifford on LinkedIn and connect with James Gifford on Twitter.

Sofi Simonyan: The Dangers of Overcommitting, and How it May Lead to Agile Team Burnout Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Sofi shares the story of a high-performing team that overcommitted. Despite their successes, and maybe because of them, the team had developed an unhealthy self-confidence that led to trouble. Initially praised for their can-do attitude and high-quality releases, the team began to struggle with burnout. Sofi highlights the dangers of overcommitment and the importance of sustainable pace, transparent stakeholder communication, and the need for fresh projects to prevent burnout. Featured Book of the Week: How to Speak Tech by Vinay Trivedi In this segment, Sofi introduces How to Speak Tech: The Non-Techie's Guide to Key Technology Concepts by Vinay Trivedi, a must-read guide for anyone navigating the tech industry. The book simplifies complex tech jargon, making it accessible to everyone, from beginners to seasoned professionals. Sofi discusses the importance of understanding these terms, particularly for non-tech team members, to enhance collaboration and communication within tech teams. [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Sofi Simonyan Sofi is a Scrum Master with 6 years of experience in tech startups and a diverse work background. Passionate about people, her mission is to build teams where active listening and growth mindset are essential values. Currently on maternity leave, Sofi practices agility in a completely different dimension. You can link with Sofi Simonyan on LinkedIn and connect with Sofi Simonyan on Twitter.

How Your Agile Team Could Compete In The Olympics - Mike Cohn Let the games begin! Are you and your team ready for the Olympics? I hope so, since the games start tomorrow.I want to share a few Olympic events at which I think agile teams would excel.First are the speed events: swimming, sprint canoeing, the marathon, and the shorter running events. The emphasis agile teams place on going faster and seeking continuous improvement will serve them well in competing in these.Some of these events, such as the swimming and running relays, require handoffs. Good agile teams become adept at small, frequent handoffs (such as from programmer to tester). This skill will serve an agile team well when participating in Olympic relays.Good agile teams are cross functional. That is, individuals with different but complementary skills collaborate. Cross-functional agile teams would excel at the many sports that require different types of players such as football, hockey, cricket, volleyball, and water polo (my personal favorite).These sports include experts who are highly skilled in one dimension. But these single-function aces need to be balanced with the skills of other team members.While a cross-functional Olympic team can include specialist experts, the team will benefit from multi-skilled members. These pi- or m-shaped people are proficient at two, three, or more skills needed by the team. Sign these folks up for the triathlon, pentathlon, heptathlon, or decathlon!The best agile teams collaborate and synchronize their work. We see this when testers create test plans while programmers are still coding rather than waiting for the programmers to finish. Agile teams who have mastered collaboration and synchronization could look for Olympic success in events such as rowing or artistic (synchronized) swimming.A team's Scrum Master would do well running the hurdles. Who better to clear obstacles?And good agile teams excel in delivering the outcomes expected of them in the time frames desired. Teams who hit the bull's eye should give archery a try.Finally, I have to add that I'd like all agile teams to compete in the Olympic trampoline event. Shouldn't work be a bit more fun? And what's more fun than bouncing on a trampoline and winning a gold medal at agile, How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Karina Margole: When Agile Teams Sprint into Burnout, and How to Avoid the Burnout Trap! Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Karina shares her experience managing multiple teams in a high-pressure game development project. With continuous sprints and mounting technical debt, the teams faced burnout and tunnel vision. She stresses the importance of maintaining a sustainable work pace and periodically stepping back to assess long-term goals. Are your teams sprinting toward burnout? Learn how to balance productivity and sustainability in agile projects. Featured Book of the Week: System Coaching and Constellations by John Whittington Karina explores the complexities of working within systems and the significant impact of external systems on our work. Systemic Coaching and Constellations: The Principles, Practices and Application for Individuals, Teams and Groups enlightened her about systemic issues, modeling systems, and focusing on manageable influences. She also highlights "Crucial Conversations" by Patterson et al., a must-read for Scrum Masters, which equips them to handle any conversation with confidence.    [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Karina Margole Karina Margole is an Agile Coach with over a decade of experience, based in the UK. She has ADHD and a passion for creating an environment where everyone can do their best work. Karina approaches her work with a holistic, systemic view while also paying attention to individuals on a personal level. You can link with Karina Margole on LinkedIn.

Stop Doing So Many Spikes - Mike Cohn One of the more common mistakes I see teams make is relying too much on spikes. A spike is an activity a team performs to get smarter about something. With a spike, a team isn't trying to immediately deliver a new capability; instead, they are building the knowledge that will allow them to deliver the new capability later.Spikes are a great tool, and I'd expect every team to use them...but not on everything they work on.The best use of a spike is to reduce excess uncertainty. This could be uncertainty about how a feature should work or about how it will be built.A team may opt, for example, to spike the user interface for a particular feature. Or it may use a spike to determine if a technical approach is feasible or will perform at the required level.Each of these can be a good use of a spike. The problem comes when a team wants to use a spike on everything. Spikes should be used only in cases of extreme or excessive amounts of uncertainty. Spikes should not be used to reduce the typical, garden-variety uncertainty that exists in all work.Further, spikes should not be used to eliminate uncertainty. Teams need to be comfortable bringing work into their sprints or iterations with open issues remaining.Is your team reluctant to allow work into a sprint with any remaining uncertainty? That's sometimes the result of team members feeling excessive pressure to estimate perfectly, to always achieve the sprint goal, or to always deliver everything that they brought into a sprint.If that is happening, a Scrum Master or coach needs to work with outside stakeholders or whomever is creating these unrealistic expectations. Sometimes it's even the team members putting this pressure on themselves.But what's the problem with frequent spikes anyway? It's that overuse of spikes extends your time to value. This is especially true when the spike is done in one iteration and the rest of the work in a subsequent iteration.Overuse of spikes also reduces the extent to which teams overlap work. This can increase the burden on testers.For example, consider the case of a programmer who uses a spike to reduce the uncertainty of a backlog item. If that item is brought into the next sprint, the programmer's work has been made simpler by the spike, but the tester's has not.If your testers are struggling to keep current with the programmers, consider whether the team is doing too many spikes. It's a good question to ask yourself even when the testers don't seem overburdened, if you want to succeed with agile. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Kevin Hoey: Fostering Agile Team Collaboration in Remote Settings Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Kevin describes a team struggling with collaboration, where members worked in isolation and did not work towards a sprint goal. This led to over-the-wall work handoffs and blame in the team. Kevin emphasizes the importance of having cameras on during remote meetings to foster team connection. He shares that effective scrum masters unlock team productivity by focusing on people first, ensuring everyone is aligned and engaged in their work. Featured Book of the Week: Drive by Dan Pink Kevin shares that his greatest influence isn't a book, but the Agile podcasts such as this one and others. As a new scrum master, it was the insights from experienced professionals that shaped his journey. However, he recommends "Drive" by Dan Pink, which emphasizes intrinsic motivation through mastery, purpose, and autonomy. Kevin's company has long embraced autonomy, helping him reflect on his role in fostering these qualities within his teams. He highlights the importance of enabling autonomy, purpose, and mastery to drive motivation and success in the teams we work with.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Kevin Hoey Kevin is the lead scrum master at Domestic and General, with 10 years' experience in project management before moving into scrum mastery. He now heads up a team of scrum masters, whilst continuing to support his own squads. Kevin believes scrum masters need to focus on self-improvement to turbocharge their ability to better support teams and the wider business on the journey to effectiveness. You can link with Kevin Hoey on LinkedIn.

Stella Ihenacho: Breaking the Blame Cycle in Agile Teams With Coaching and Customer Collaboration Stella shates the story of a high-stakes project team plagued by blame-shifting and management interference. The project's tight deadlines and high complexity led to fear and blame culture in the team. Upon investigation, Stella became aware of some customer agreements made without team input. To overcome these anti-patterns, Stella's strategy involved separate retrospectives for different groups and resetting customer expectations. Listen in to learn about fostering a blame-free culture and aligning team and customer expectations. Featured Book of the Week: Atomic Habits by James Clear Stella shows how transformative power of small, incremental changes helped her. She found out about that approach from the book "Atomic Habits" by James Clear. She explains how these principles apply to agile transformations, emphasizing that success is built over time, not through quick fixes. Stella shares tips on focusing on small wins, the importance of vision, and the need to explain metrics clearly.  [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Stella Ihenacho Stella is the Manager of the Continuous Improvement and Agility team at RedHat and Agile Faculty Lead at NSTAR Technologies. Dedicated to transforming organizations and individuals through an agile mindset, she believes there's always room for improvement, even when things aren't broken. You can link with Stella Ihenacho on LinkedIn and connect with Stella Ihenacho on Instagram.

What to Do Before Adding Items to the Backlog - Mike Cohn Have you seen “The Princess Bride” movie?I love it. (And the book is even better.)The film tells the love story of Buttercup and Westley. Westley works on Buttercup's family's farm and any time she asks him to do something, he responds, “As you wish.”This is *not* how a team should respond when a product owner asks a team to do something.Before doing what their product owner requests, team members should ask questions. This ensures they understand what's needed, but also confirms the product owner has thought through the request sufficiently.I've seen many situations in which product owners ultimately realize they never really wanted the thing they initially asked for.I think team members should even go so far as to push back slightly if they have doubts about the benefit of something a product owner has requested.Product owners are meant to be the authority on their products, the wise and most knowledgeable voice. But team members' opinions should not be discounted.Team members are valuable stakeholders who may have unique insights into how a product works. If they have concerns about a request, they deserve to be heard. And product owners owe it to users to listen.Ideally, a product owner asks a team to achieve some goal rather than simply perform a simple task.“Fetch that” may have worked for Buttercup telling Westley what to do. And a simple task like that may warrant an “As you wish” response.On an agile project, however, asking questions before possibly telling the product owner, “As you wish” is the way to succeed with agile. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Esther Schmit: Bridging Communication Gaps Between Agile Teams, The Communication Challenge Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Esther shares a challenging experience with two teams that struggled due to poor communication and unwillingness to collaborate. She provides tips on facilitating retrospectives and one-on-one conversations to address communication issues and set clear expectations. Listen to learn a method to improve communication in your teams. Featured Book of the Week: Mister Mindset by Michael Pilarczyk Esther discusses "Master your Mindset, Live a Meaningful Life: A book about mental health and personal success" by Michael Pilarczyk, a book focused on changing your mindset to improve the quality of life. She explains how understanding and altering one's mindset can positively influence professional and personal lives, especially for Scrum Masters who facilitate and support teams.    [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Esther Schmit Esther is a freelance Agile Coach and Scrum Master, leading Agile Pro Center, which provides online Agile Coaching, Training, and Mentoring for Scrum Masters. Esther also hosts the Online Scrum Master Summit. You can link with Esther Schmit on LinkedIn, and visit her site Agile Gatherings.

Milica Lubinic: How to Foster Long-lasting Change for Agile Teams Without Micromanagement Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Milica tells the story of a team's struggle with sustainable change. Despite good intentions, the team lead's constant reminders about incomplete actions led to a lack of ownership. She emphasizes the importance of developing habits for sustainable improvement and allowing teams to maintain ownership of changes. How can teams foster long-lasting change without micromanagement? Featured Book of the Week: The Power of Vulnerability by Brené Brown Milica discusses Brené Brown's "The Power of Vulnerability" (audiobook) and how it transformed her understanding of belonging versus fitting in. This distinction helped her foster true belonging in her teams, where members felt safe to be themselves and contribute their best. This book addresses a question that is critical for Scrum Masters: How can we create environments that nurture genuine belonging?   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Milica Lubinic Milica is a Mom and Professional and Organizational Coach who is all about dealing with complexity, whether it's child development or organizational/team/individual transformation and growth. She found her true calling in the world of Agile, Cynefin, and Progressive organizational cultures. Creating safe spaces for innovation, nurturing trust, and sparking engagement is her true passion. You can link with Milica Lubinic on LinkedIn.

Avipaul Bhandari: Why Agile Processes Matter, And Help Avoid Deathmarch Projects Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Avipaul shares the story of a team working on an iPad app under tight deadlines. They skipped Scrum events, leading to chaos and missed deadlines. In this episode, we explore some of the most common anti-patterns that come from skipping or avoiding Agile processes and the importance of structure for teams, especially when under tight deadlines.  Featured Book of the Week: The Coaching Habit by Michael Bungay Stanier In this segment, Avipaul shares how "The Coaching Habit" by Michael Bungay Stanier,  transformed his approach as a Scrum Master. The book's seven powerful coaching questions, especially "And what else?", helped him enhance his coaching skills and deepen his 1:1 interactions.    [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Avipaul Bhandari Avipaul is a seasoned Agile Coach with extensive experience helping teams and organizations implement Agile practices effectively. His expertise spans various domains, and he is passionate about fostering collaboration and continuous improvement. You can link with Avipaul Bhandari on LinkedIn and connect with Avipaul Bhandari on Twitter.