Podcasts about scrum alliance

In this episode of the Agilists: Aspire and Achieve podcast, host Renae Craven explores how guest Sibila Bijedic has helped non-tech teams understand and apply the agile mindset and principles.   About the Featured Guest Sibila is a passionate coach that strives for agility while cultivating a strong desire for lifelong learning and evolving through collaboration.    Follow Sibila on LinkedIn (https://www.linkedin.com/in/sibilabijedic/)   The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared.   Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org    Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg    Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile.   About our Hosts   Renae Craven has been coaching individuals, teams and organizations for over 15 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel Crave Pilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn (https://www.linkedin.com/in/renaecraven/).

Eine Zertifizierung ist für viele Product Owner ein Thema, das immer wieder aufkommt – oft dann, wenn sie neu in der Rolle sind oder sich weiterentwickeln wollen. Doch was bringt eine Zertifizierung wirklich? Ist sie nur ein Türöffner für den ersten Job oder hilft sie tatsächlich dabei, ein besserer Product Owner zu werden? Gleichzeitig gibt es eine Vielzahl an Anbietern für solche Zertifizierungen – von etablierten Organisationen wie der Scrum Alliance oder scrum.org bis hin zu eher unbekannten Anbietern. Jede Organisation verspricht einen eigenen Mehrwert. Manche Zertifikate lassen sich durch das Bestehen eines Online-Tests erwerben, andere setzen auf Trainings mit erfahrenen Coaches. Doch nicht jede Zertifizierung passt zu jedem Kontext oder Lerntyp. Eine Zertifizierung kann ein guter Einstieg sein, um sich strukturiert mit den Grundlagen des Product Ownership auseinanderzusetzen. Sie gibt Orientierung und zeigt, welche Themen zur Rolle gehören. Aber sie ersetzt nicht die tägliche Praxis, nicht den Austausch im Team, nicht die Auseinandersetzung mit Stakeholdern oder Nutzerbedürfnissen. Wer Product Owner ist, lernt ständig dazu – unabhängig vom Zertifikat auf dem Papier. Besonders spannend wird es, wenn wir uns die Motivation anschauen, warum Menschen überhaupt eine Zertifizierung machen wollen. Geht es um ein besseres Gehalt? Um Sichtbarkeit im Unternehmen? Oder darum, sich selbst sicherer in der Rolle zu fühlen? Je nach Zielsetzung können ganz unterschiedliche Formate sinnvoll sein. Für manche ist zum Beispiel ein Einstiegskurs wie der „Professional Scrum Product Owner“ (PSPO I) ideal, andere profitieren mehr von Advanced-Kursen mit Fokus auf Stakeholder-Management, strategischer Produktentwicklung oder Leadership. Zertifizierungen sind also weder gut noch schlecht – sie sind Werkzeuge. Und wie bei allen Werkzeugen kommt es darauf an, wie man sie einsetzt. Ein Product Owner, der gelernt hat, wie wichtig kontinuierliche Validierung von Hypothesen ist, wird sich nicht auf ein Zertifikat verlassen, sondern im Alltag ausprobieren, verwerfen, neu denken. Genau das macht die Rolle so anspruchsvoll – und so spannend. Am Ende zählt weniger, welches Logo auf dem Zertifikat steht, sondern was die Person daraus macht. Wer bereit ist, kontinuierlich zu lernen, Feedback anzunehmen und sich mit anderen POs zu vernetzen, braucht nicht unbedingt eine Zertifizierung, um gute Arbeit zu leisten. Aber sie kann ein sinnvoller Baustein sein – vor allem dann, wenn sie nicht als Endpunkt, sondern als Anfang verstanden wird.

In this episode, Kate Megaw joins Brian Milner to share simple but powerful techniques that can turn those soul-sucking meetings into dynamic, action-driven conversations. If you're ready to make meetings worth attending, this one’s for you! Overview Brian Milner and Kate Megaw uncover the secrets to running highly effective and engaging meetings. They tackle common facilitation pitfalls, the staggering amount of time wasted in ineffective meetings, and how simple tweaks can transform team collaboration. Kate shares practical strategies for keeping participants engaged, fostering psychological safety, and ensuring meetings lead to real action—because no one has time for another pointless meeting. References and resources mentioned in the show: Kate Megaw ARCLight Agile Katanu Katanu’s Facilitator Certification Course Katanu Resources #44: Transformations Take People with Anu Smalley Advanced Certified ScrumMaster® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Kate Megaw is the Founder and CEO of ARCLight Agile, specializing in helping organizations create empowered, high-performing teams through agility and collaboration. A dynamic Certified Scrum Trainer (CST), Certified Team Coach (CTC), and Project Management Professional (PMP), Kate is a sought-after speaker known for sparking ‘aha’ moments that drive real transformation. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We're back here for another episode of the Agile Mentors Podcast. I'm here as I always am, Brian Milner. I'm with you as your host. But today I have the one and only, amazing Kate McGaw is with us. Kate, thank you for coming on. Kate Megaw (00:17) Thank you for having me. Brian Milner (00:19) Absolutely. If there's some of you out there that aren't familiar with Kate, she is a CST, a Scrum trainer like myself. She's also a certified team coach. And she also has the other side of things, the dark side. She's a PMP. So she has that project management kind of background that she brings to the table as well, which I think is awesome. She's a CEO of a company called Arclight Agile. And she's a co-founder of one of our favorites here that's come on the show, Anu. But they team up together. So it's Kate and Anu. And so their company is Katanu. I love it. love it. So why we decided to have Kate on is because Kate and Anu both have done a lot of work around facilitation. And we did have a user request. Kate Megaw (00:57) That's it. Brian Milner (01:09) to have an episode where we focused on facilitation. And listeners of the show know there's nothing I love more than being able to fulfill listener requests here and try to do those as soon as possible. So let's dive in. Let's talk about facilitation. It's a funny word. There's lots of different misconceptions and things about it, I'm sure. What do you find people misunderstand most about facilitation? Kate Megaw (01:34) think one of the key misunderstandings around facilitation is that you're part of the meeting, you're part of the event, you're actively involved. And when you're facilitating, you're actually, taking a step back because you are accountable for making sure that everyone is speaking and that we're keeping an eye on the agenda and things like that. And if you are actively involved in the discussion, You can't be doing that because you're missing body language. You're missing people who need to talk and who aren't talking. So I think one of the main misconceptions is, or that people forget is a facilitator is neutral. So if, for example, you have a scrum master facilitating a retrospective and they need to be actively involved in the retrospective, they should be inviting somebody else in to facilitate it. and I think We're beginning to see a lot more interest in it now because it's one of these key things. If it's done badly, people generally will notice. If it's done well, hopefully you don't notice that much other than, you know what, that meeting was very efficient. We achieved the goal and I feel as though it was worth my time. One of the things I like to say to people at the end of a meeting is the fist of five, how worth your time was this meeting? And I'm looking for fives or fours. If we're getting threes, twos and ones, we've not facilitated it well, or the meeting didn't achieve its agenda and things like that. think a lot of the statistics around facilitation that have come out recently, and you and I were talking about these briefly before we started that the average at the Microsoft trend index shows us that average time spent in meetings by employees at the moment is 21 and a half hours a week, which is an increase, I know, an increase of 252 % since the pre-pandemic. So. Brian Milner (03:36) That's incredible. Yeah, I mean, that's more than half of a work week, right? I mean, we're spending more than half our work week in just locked in meetings. So you're right. We had this conversation beforehand and you were telling me that stat and it just kind of floored me that we're spending that much time in meetings. But it was the next one you told me that really floored me. And it's a combination of these two, I think, that people need to really grasp onto. So tell them what you told me next. Kate Megaw (03:49) Mm hmm. Yep. Yep. Yeah. So the next one is that the Harvard Business Review indicates their research, 67 % of meetings are considered by executives to be failures. So if we look at the financial impact of that, and this is something I didn't share with you, but the financial impact of that is for a company, imagine you have a company with 100 employees, unproductive meetings are wasting upward of $1.7 million a year. If you have a thousand employees, increase that number. it's one of these things that it is not difficult to do. It is just understanding why we need someone in the facilitator role. And the basics around the basic facilitation, the basic getting ready for the meeting, facilitating during the meeting and properly closing the meeting. takes those unsuccessful numbers up to successful numbers where you're getting those fives and people are sort of, yep, that meeting totally achieved the purpose and the outcome and it finished early. So I've got 20 minutes back before my next meeting. Brian Milner (05:24) Yeah, it's so incredible that combination of those two stats. I thinking that we're spending over half our time in meetings and that 67 % of them are failures, we're having a lot of them and we're not doing them well, clearly. Kate Megaw (05:36) Absolutely. I think with, I don't know with Zoom, well, I think with Zoom, it's got easier to have meetings. So we're probably having meetings where we don't need to have meetings. That's one of my favorite things to ask is, does this need to be a meeting? Or are you just going to talk at me and roll data out? In which case, send it to me in email. Don't tie me up for a meeting. Brian Milner (05:44) Yep. Kate Megaw (06:02) Because so many meetings are a waste of time that a lot of people are spending meetings multitasking. So we're taking an hour for a meeting that we could do in 25 minutes if people were 100 % engaged and following the agenda and things like that. Brian Milner (06:22) Yeah, yeah, that's so fascinating. it seems like such a, it's hard to believe that there's not more of that skill in just basic business training, right? Because if we're having all those meetings, then it would seem natural that there would be more segments that would say, you know, a little facilitation skill for, you know, a, you know, bachelor's in business, you know, like that might be a little helpful, right? Kate Megaw (06:41) Yep. Mm-hmm. Yeah, absolutely. And it's a small investment for something that will make a huge difference. I mean, one of the things Anu and I have been working on is the mnemonic of ready, reach, and wrap in order to make sure we have effective meetings. And the ready part of it is setting the foundation. So before you even get to your meeting, this is ahead of time. You're understanding, okay, what are the Rs? What are the roles and responsibilities? So if I'm facilitating, then who are the decision makers? Who is mandatory? Who's required to be there? Who are the, you can come if you want. Let's stop doing meetings to 30 people and expecting 30 people to show up. So we've got to understand the roles and responsibilities. The other, the E for the ready is expectations and engagement. Brian Milner (07:29) Ha ha ha. Kate Megaw (07:41) So if the expectations are that this is an interactive meeting, we're using Lucid or Mural or Mira, whatever tool we're using, it's going to be collaborative, webcams are going to be on, multitasking is going to be at a minimum, everyone knows going into that meeting what the expectations are. And then the A again is the agenda and the alignment. The agenda should be very clearly saying these are the items that the D is making sure where we have defined the purpose and the outcome. So every meeting, we need to know what the purpose of the meeting is, what the outcome of the meeting is, and they should be included in the agenda. We shouldn't be accepting meetings. Imagine the power of being able to decline a meeting if it didn't have an agenda in it. And if you think about it, why do we attend meetings? Brian Milner (08:27) Ha Yeah. Kate Megaw (08:33) with no agenda and people turn up to the meeting and said, okay, so what's this meeting for? Pretty sure we've all got better things to be doing. So make sure for every meeting we have a defined purpose and outcome. And then the why is making sure we as facilitators have your logistics ready. If it's Zoom, if we're using a remote whiteboard, do people need to practice it? Do we need to set up an environment? Do we need to make sure webcams are on? All that type of thing. So a huge amount of meetings would be better if we did nothing other than better planning with the roles, responsibilities, the expectations, the agenda, the defining the outcome and the logistics. If we just did that. Brian Milner (09:09) Yeah. Kate Megaw (09:23) I bet we're going to see the amount of productive meetings increase considerably. Brian Milner (09:29) Yeah, there's so much transfer here too as well, just to the normal scrum meetings that we have because, you know, one of the things I'll talk about lot in class is just to say, you know, you can't just expect to show up to something like Sprint Planning and have it go smoothly. You have to put in some work beforehand and get ready for it. Same thing with like a Sprint Review. You got to put in some work beforehand and make sure you know who's going when and who's speaking, you know, that speaking order and all that stuff. Kate Megaw (09:42) Yeah. Brian Milner (09:55) goes miles in making those more successful meetings. But the other thing that really interested me in that is you talk a little bit about purpose and that we don't really understand the purpose of the meetings. And that's something that's really stuck out to me is when I talk to people who don't like their Scrum meetings, it feels like 90 % that is just Brian math, but it feels like 90 % of the time, right? Feels like this. It feels like 90 % of the time. Kate Megaw (10:04) Mm-hmm. Brian Milner (10:20) that the people who have a problem with those meetings don't know the purpose of the meeting and that's really the root cause of it, right? If they knew why we were here, then the meeting makes sense. Now I understand what we're trying to do. Kate Megaw (10:26) Yep, absolutely. And I think one of the interesting things, I would love to repeat these numbers around the Scrum events, because I think by default, the Scrum events do have a purpose. They do have an outcome. We know what the roles and responsibilities are. We know what the expectations for engagement are. So I think the Scrum events are much more productive than your average event. Brian Milner (10:41) Yeah. Kate Megaw (10:59) But I do feel if we don't have well-facilitated Scrum events, that's where we get our criticism, or, this meeting was a waste of time. Okay, well, let's look at our facilitation and see, it an error in planning or was it an error in expectations? But it always surprises me when people say, well, Scrum's just so many meetings. And I'm so... No, we should have fewer meetings and if they're well facilitated, we need all of those meetings. So it's not as though we're having a meeting for meeting sake, which I think is unfortunately something we can't say for our non-scrum events. Brian Milner (11:43) Yeah, yeah, I mean, I go so far as to say, if you don't understand the purpose of it, don't show up. I mean, there's really no need to be there if you don't know what we're trying to get out of it. One other little side correlation there too, because this kind of ties in a little bit to some of the stuff I did this last year in kind of studying a little bit about neurodivergency and different neuro types and that kind of thing. And one of the things I found really fascinating was certain neurodivergent types, Kate Megaw (11:48) Mm-hmm. Mm-hmm. Mm-hmm. Brian Milner (12:12) really need to have an agenda in advance. And if they don't, then it just raises their anxiety level. they're just, you even not, you know, neurodivergent types, just regular, normal, you know, neurotypical people. There are those that just don't respond well when you're just throwing out a blank slate and saying, give us your best idea, right? They need time to process and think in advance and Kate Megaw (12:15) Yeah. Mm-hmm. Yep. Yep. Mm-hmm. Yep. Brian Milner (12:38) And so yeah, if we could send out that just the day before, it's not that much work. It's just one day earlier, right? It's actually the same amount of work. It's just doing it a day earlier. Right. Kate Megaw (12:45) Absolutely. Absolutely. It's just better organized. Yeah. I mean, I even on my team meetings, I know some members of my team want to know, because I always like to start them with segue questions and some of my team completely fine. Ask them a question, favorite food or you want to have any sort of segue question and they're fine with it. But I have my thinkers who want to think about it ahead of time. So I think it's important when we're facilitating any event that we understand the audience. How many of the audience are going to want to maybe read a document ahead of time? How many of the audience are, you know what, they can think on the feet, I can throw anything at them, but there are others that do need the preparation. yeah, I think that the planning that we do, if we can do it just slightly ahead. And then things like when we get into the meeting, of the mnemonic that we use for actually facilitating during the meeting is the mnemonic of reach, which is we're guiding the process. The very first thing we do when we go into the meeting is we review the agenda and open the meeting. So here's the agenda. I've got the agenda visible. mean, what the agenda that we use in classes. Is the to do doing and done. I use that for all my meetings. I've got that up on the virtual board and the topics of the meeting are moving across to doing and done because then our visual people can see how we're doing. But the reviewing, at the start of every meeting we said, OK, let's just review the agenda. Let's just remind everyone this is the purpose and this is the desired outcomes. And if the right people are not in the meeting. There's no point having a meeting that we cannot achieve the purpose and the outcomes because we don't have the right people. So, I mean, I always say open it, open it with a segue question and things like that, but level set on the agenda. And then the middle part of the meeting is the bit that people are familiar with, which is the gathering ideas. It's exploring. It's the A is the assessing, making sure we've got the collaboration and the discussion and the... Brian Milner (14:39) Yeah. Yeah. Kate Megaw (15:07) The C is our concluding, are we doing dot voting or is somebody else who makes the final decision? But the H is the one that we often forget at the end, which is let's highlight the action items from the meeting. Let's make sure we know what it is, who's accountable for it, when it's going to be done by, and then close the meeting. mean, you... Brian Milner (15:18) Hmm. Kate Megaw (15:33) you and I will both close out our classes. Maybe we use one word, maybe we use, give us a statement, all sorts of different things, but we forget to close out meetings. go, time's up. Okay. Bye everyone. And we've not reviewed the, this is what we're going to do for next time. And we've not formally closed the meeting, even if it's as simple as one word, but we've got to open and close it. Sorry. Passionate about that. No. Brian Milner (15:44) You You mean that's not how you close out a class? I've been closing classes like that for years. No, I'm just kidding. Yeah, exactly. Ding, sorry. Kate Megaw (16:03) Yes, sorry, time's up, clunk. Yeah, sorry, dog's barking, dog needs to go out. So, but yeah. Brian Milner (16:11) Exactly. Yeah. Yeah, no. And there was something I came across just in trying to put together materials for classes where we have little segments on facilitation in it. Because I think sometimes there's a lot of focus on the different various techniques, like fist to five or thumbs up or whatever. There's different kind of techniques. I'm not trying to belittle those. Those are things we need to know. But. Kate Megaw (16:21) Mm-hmm. Mm-hmm. Mm-hmm. Brian Milner (16:36) One of the things I came across was that the root word of this thing is this Latin word, facilius. stands or it means literally to make easy. And I've always had that kind of in the back of my mind when I'm a facilitator is like, what are they trying to do? And whatever they're trying to do, just, my job is just to make that as easy as possible, right? You know, it's always difficult when you're trying to make a decision and you have no direction about how that decision is going to be made. Kate Megaw (16:46) Yeah. Brian Milner (17:05) But a good facilitator can give the structure to it and say, no, no, no, it's OK, I got you. We're going to go through this little journey together, and we're going to end in this other side, and you're going to have something to take away from it. Kate Megaw (17:16) Yeah, we're going to have heard everyone's voices as we go through. We're not going to let one person dominate the conversation. We're going to use techniques like, that's a great point. Can we also check in on the other side of the table? Let's hear some counter points here. It's pulling people in, it's summarizing. So if I'm hearing you correctly, Brian, you're saying A, B, C, D. It's all of that going into it. And I think one of the other... big has when we teach facilitation is the facilitator is not the scribe. So people say, well, I'm the project manager or I'm the facilitator. need to be taking all the meeting notes. And I'm like, well, what direction is your head pointing when you're taking notes? And it's down at a piece of paper. So you're not seeing who's yawning because you're tired and you need to take a break. You're not seeing people who are confused or wanting to talk and things like that. sort of either you turn on the AI tool and have the AI tool summarize the meeting for you. Do check it before you submit, it out or B have everyone in the meeting as a grown ass adult. They can take their own agenda items. mean, their own action items, have an area on your virtual board or in the room you're having the meeting in that is action items. And again, what is it? Brian Milner (18:18) Sure. Kate Megaw (18:36) Who's gonna be doing it? When's it gonna be done by? And I think one of the key criticisms of meetings is, and you'll hear this as well, particularly by retrospectives is, well, nothing changes. And I'm sort of, well, who has the action item? well, there isn't an action item. And I'm sort of, at the end of every meeting, we should be doing the mnemonic we use here is rap. The first thing is retrospect. Brian Milner (18:53) you Kate Megaw (19:04) How was this meeting? We talked about the fist of five. Give me one word. Anything we need to do differently next time. And then the A is make sure we have all of these action items assigned to someone. And then the P is the one we forget about. Tracking that progress. How are we going to hold each other accountable for making sure that something changes as a result of the meeting? So. Brian Milner (19:22) Mm-hmm. Kate Megaw (19:31) If we're doing retrospectives, if the team is voting whatever technique they're using to choose the one thing they want to do differently, how do we make it visible? Do we put it on our scrum board somewhere? Do we talk about it every day as part of after we've done daily scrum? How are we doing with the communication techniques that we wanted to try and do differently going forward? We've got to have that visibility. Otherwise nothing changes. Brian Milner (19:57) Yeah, yeah, that's so awesome. I completely agree. And that's something that I think you're right is missing, not just from retrospectives, but just a lot of meetings in general. We don't really understand, all right, well, what's the takeaway? What's the thing we need to do as a result of this to make this not a waste of our time, to make this something that was a useful, not the 67 % that were failures, but something that actually leads to success. I want to. Kate Megaw (19:59) Mm-hmm. Mm-hmm. Yep. Yeah, yes, so that we're not having the same meeting again next week and the week after and nothing's changing. Brian Milner (20:30) Exactly. Exactly. I want to ask you one question about facilitation. I've heard this a lot in regards to retrospectives, but probably it's more a facilitation thing than it is a retrospective thing. But I think probably the number one question we get from people about retrospectives is, how do you handle a quiet team? so I'm just kind of curious. When you talk about facilitating and working with individuals who are a little more introverted, Kate Megaw (20:50) Mm-hmm. Brian Milner (20:57) or just not as comfortable speaking out in public, are there special considerations or are there things that you do differently just to try to accommodate and make those people feel more comfortable when you're facilitating them? Kate Megaw (21:09) So yes, several things. So one, I will look at a theme. So do they have a team name and do I want to set up a mnemonic around the team name to gather the data? Are they a visual team? Do I want to do something like the sailboat that's interactive and people can add things to the board? Are they a movie buffs? Do I need to do a Star Wars themed retrospective? So I'll generally try and find something to connect the team. I've done it before where I'm working with airlines. Okay, what is it keeps our planes in the air? What is it that grounds our planes? What are the storm clouds we need to be aware of? What are causing bumps during the air? So all of that type of thing, it's a theme relevant to the team. And I generally will find that if I can start a team talking, I can keep them talking. So if... one of the ways that I will often start a retrospective is if the retrospective, if your last retrospective was a ride at Disney, what ride would it have been? and get them talking or give me one word that describes the last retro or in a scale of one to the, mean, the last sprint, give me one word that describes it or scale of one to 10. How well do you think we did at the last sprint? But I love to get people talking. If I'm in the office, I sort of adapted the Adam Weisbart's retrospective cookies and I'll use candy bars and I'll wrap questions around candy bars and the team grabs a candy bar and there is a question on it which they answer and then other people in the room will then answer as well. Maybe things like, what can I do to better support you as a scrum master? Or, What can we do to better support each other as team members? So I think it's getting people talking, making sure the big reminder for me is as a facilitator, if you did not write the Post-It note, you should not be reading the Post-It note and you should not be moving the Post-It note. The team owns the Post-It notes. Everyone should be adding their own Post-It notes, whether it's virtual or in person. Brian Milner (23:07) Yeah. Kate Megaw (23:28) They should be grouping their own Post-it notes. They should be moving them. And the other one, people always say, well, what happens if there's the elephant in the room and this thing on the board that nobody wants to talk about? And I'm said, well, often I will say, okay, I'm going to add, we're going to do something different for this round. This time, I'm going to ask you to introduce something you did not write on the board. And let's talk about, I'm going to ask you to choose a topic and we're going to talk about that. Just read it, you read it out. Brian Milner (23:39) Yeah. Kate Megaw (23:58) and then we'll have a discussion around it. So as a facilitator, I can uncover the elephants in the room without anyone feeling too uncomfortable. Brian Milner (24:07) Yeah, that's great stuff. of parallel to this, think is kind of, I know we've, I've heard you talk about this, but the sense of safety in the room and just that people feel safe to talk about that. Are there things we can do as facilitators to actually raise that sense of safety? Kate Megaw (24:25) There are absolutely, there's a lot of things we can do. And I, every now and then I will hear something and I will just cringe. And there's, well my team doesn't really like sharing. They're not honest in the retrospective until the CTO disconnects from the retrospective. And I'm sort of, okay, so maybe what do you think this is maybe telling us? I'm sort of retrospectives are Vegas rules. It is the team. I will do retrospectives even with non-scrum teams, but it is the team that is there. There are no visitors. It is the team only. The other thing that makes me cringe is, yes, well we sent out the minutes of the retrospective and I'm sort of, excuse me, the retrospective again, Vegas rules. What is the one thing we're going to do differently as a team in the next sprint? Okay, is everyone okay if I put this up on our scrum board so it's visible? Brian Milner (25:07) Ha Kate Megaw (25:20) Okay, that's the one thing we're taking away. But back to the question you were asking, one of the biggest signs of a lack of psychological safety is that the team just doesn't want to talk. They're worried that the minutes are going to be captured. Somebody, one of the leaders is in there and, well, everyone's fine with my leadership. They're completely open and honest in front of me. And I'm sort of, okay, let's try a retrospective then with you there. Brian Milner (25:32) Yeah. Kate Megaw (25:50) And then we'll also try retrospective without you there. And let's see which one is more comfortable because otherwise it's a, it's a colossal waste of time. If nothing's going to change, why are we wasting sort of 45 minutes to an hour or even doing it? So I think that the psychological safety is a key one, making sure it is the right people, making sure that minutes are not being captured. The other thing is. A lot of times people say, well, I need to capture it because I need to bring all of the information again next time. And I'm sort of, no, you're trashing the Post-it notes. You're trashing the mural board, whatever. You're starting from scratch next time. they're sort of, well, I'm going to lose all this information. I'm sort of, no, if it's important enough, it's going to come up again next time. Brian Milner (26:23) Yeah. Yeah. Yeah. And things change, right? mean, what the universe of things we might identify this sprint could be entirely different for next sprint. I've always loved, Jeff Sutherland had this phrase, he would say about it to say that, you have to remove that one big thing. And when you move that one big thing, then the system adjusts and you don't really know where the next bottleneck is going to come from until you remove that one big thing. Kate Megaw (26:58) Yeah. Brian Milner (27:02) So it's likely to be somewhere you wouldn't expect. so you can't just hang on to your number two issue from one retrospective and then say, well, next retrospective, we'll just do that and we can cut out having the conversation because we identified important things in this one. Kate Megaw (27:14) Yeah. And it anchors the tea. It stops the creativity. that's the other thing with retrospectives. I occasionally will work with a client and there's the, oh yes, we've been doing what's going well and what's not going so well every two weeks for six months. And I'm sort of, it's not really any wonder your team's bored out of their minds at retrospectives and nothing new is coming up. There's so many websites out there. Brian Milner (27:41) Yeah. Kate Megaw (27:42) that retrospective should never, in fact, no meeting should ever be boring because we should always be opening and closing a meeting in a creative way. Even if it's, mean, one of the things that we like to do in the morning of class is have music. So when people are joining, the energy is there so that we're getting that interaction and things like that. So people are starting on a high and then... I mean, you'll notice in the afternoons people begin to yawn, especially after lunch. Okay, you know what? It's been 65 minutes. Let's take a break. Let's do a segue question at break. So when we come back, show us something on your desk that tells us a bit about you. Or one of the ones I like is go stand up, go and look outside and come back and tell us something you saw outside. We have chickens. We have all sorts of things that people are saying. but it's encouraging them to get up and go get some oxygen in their system, take a break and then come back and then it's more engaging. But if as a facilitator, I'm not planning that type of thing, the energy is going to go down and I'm not going to achieve the purpose of my half day event or my one day class, whatever it is. Brian Milner (28:56) Yeah, it doesn't happen by accident. It's all very intentional. Well, this is fascinating. And we could have this conversation for another several hours, I'm sure. I just wanted to let everyone know that in case you were scrambling to write down these mnemonics and other things, we're going to link that in our show notes. So you can go to our show notes, and we'll put you over to Katanu team. Kate Megaw (28:58) No. Yep, absolutely. Yep. Brian Milner (29:20) Katanu, I keep on saying cat and Anu, trying to say it right way. Yeah, but we'll link you over them so you can get those three Rs for meetings and know kind of what each one of those little letters stands for in there. Kate Megaw (29:24) Yeah. Brian Milner (29:33) This has been really eye-opening for me and it just is a fascinating topic and it's so delightful just to hear the intentionality and how we can do simple things. They're not hard things, but simple things that make such a huge difference. Kate Megaw (29:48) Yeah, yeah, mean, that's the key. This is not rocket science. It's one or two simple things that helps us take that if we are going to spend 20 % or 20 hours a week, which is half of our time in meetings, let's at least make sure they're productive meetings so that we're not literally burning money by having unproductive meetings. Brian Milner (30:12) Yeah, absolutely. Well, I also forgot to mention here at the beginning, and we'll put this in the show notes as well, but Team Katanu also has a facilitation course. The Scrum Alliance has a certified Agile facilitator designation that you could obtain if you were interested in that. We'll link that off as well. But yeah, I couldn't recommend any better people for you to take that from than Kate in a new idea. We were saying that she had a, when she was younger, used to have the nickname Cat, and now everyone's calling her Cat from that. Well, thank you again for coming on and sharing your wisdom with us. I really appreciate it. Kate Megaw (30:46) Yep. Yep. Thank you very much for having me, Brian. And I look forward to hearing amazing facilitation stories from everyone once they've implemented some of this stuff. Brian Milner (31:03) Absolutely.

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.

AI is changing the game for Agile Coaches, Scrum Masters, and Project Managers—but do AI micro-certifications from Scrum Alliance and PMI really bring value? In this episode 66, I break down their pros, cons, and real-world impact. A Deep Dive for Scrum Masters & Project Managers You'll learn:
✔️ How AI is reshaping Scrum, Agile Coaching, […] The post AI & Agile: Are Micro-Certifications Worth It? appeared first on Agile Lounge.

In this episode, Brian Milner and Pete Behrens explore the difference between managing and leading, the critical role of middle management in transformation, and how anyone—at any level—can drive real change in their organization. Overview In this episode of the Agile Mentors Podcast, Brian Milner sits down with leadership expert Pete Behrens to unpack what it truly means to be an Agile leader. They dive into the difference between leadership by authority and leadership by respect, the importance of competency in leadership roles, and why middle managers often hold the key to lasting organizational change. Pete shares insights on how leaders can navigate cultural shifts, manage organizational tensions, and empower teams to operate effectively in today’s fast-moving world. Whether you're a Scrum Master, Product Owner, or executive leader, this episode is packed with actionable strategies for leveling up your leadership impact. References and resources mentioned in the show: Pete Behrens Agile For Leaders Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Pete Behrens is a leadership coach and Agile pioneer, shaping organizational agility for over 20 years—long before scaling frameworks took center stage. As the creator of the Scrum Alliance® Certified Enterprise Coach (CEC) and Certified Agile Leadership (CAL) programs, he continues to empower leaders worldwide through Agile Leadership Journey™, a global network dedicated to leadership growth and culture transformation. Auto-generated Transcript: Brian Milner (00:00) Well, welcome back Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have the one and only Mr. Pete Barron's with us. Pete, welcome in. Pete Behrens (00:15) Thank you, Brian, for the invitation and happy to be here. Brian Milner (00:17) Very, very excited to have Pete with us. If you're not familiar with Pete's work, you're in for a treat. Pete has been doing this for a long time and he has been really a foundational person in some of the things that the Scrum Alliance has done over the years as far as being involved with the coaching program and the leadership program and helping to design and put that together. His main focus has been in leadership. for several years now. And that's why we wanted to have Pete on, is to have him talk a little bit about Agile leadership. Because in today's world, in the context of a lot of the things that are shifting and changing in our day and age, I know that there's just a lot to consider in the area of Agile leadership. why don't we start, and I know this is kind of a softball, you probably get this question a lot, how do you define that? How do you define, is Agile leadership different than leadership, or is it... Is it essentially the same thing? Pete Behrens (01:12) Yeah, good, good starting question. So think of leadership as, you know, the ability or capability of influencing others towards a common goal. Right. That's that's what we look at as a behavior, a capability. Some people confuse that with being a leader. And that's actually different. We think of that as being, you know, having a title of authority. Right. So if you think about influence, there's really two aspects. One is I actually have a title that gives me the authority or I have respect. that allows me to do that regardless of title. So we do that a lot with leaders to actually kind of reset some of that and think about, right, this is a capability anybody at any level, any title can do as somebody. Now, the agile, you know, part of that, obviously, you you and I live in an agile industry and world. Why? Because things are changing, right? Things are changing faster than we've seen. Things are more complex. software has created endless possibilities of paths. And we like to use the metaphor of fog. So think of your operating in the fog. You need to sense and respond to make appropriate decisions. It's no longer available to us to kind of leverage the plan, follow the plan. And so Agile is simply a capability of leadership to operate in that complex, fast-changing world. Brian Milner (02:31) Love that. Yeah, I love that analogy. mean, I think about like all the times I've done cross country road trips and you drive into a fog bank, you're a lot more alert. You have to be really on point the whole time versus, you know, driving out in middle of Arizona somewhere where you can see, you know, the next five miles ahead, maybe relax a little bit more behind the wheel. That's a great analogy. So if we have to be kind of There's a difference here between being, I'm a leader in the organization because they've given me a job title and I'm a leader because I'm recognized as a leader. I'm recognized as such. What kind of characteristics, qualities come with that recognition? How do people, what differentiates somebody who is a recognized leader in an organization from someone who's not? Pete Behrens (03:14) Yeah, you know, certainly title is a recognition, right? So it's one way, you know, people and it's in effect, probably the most desired way to become a leader is I want the title. you may have seen this. I know I did when I was, you know, I was a director of engineering, VP of engineering before I became, you know, a coach and consultants. And a lot of times I'd get people coming to me and say, Pete, I want that job. I want that leadership position. I want to be the tech lead. I want to be the development manager. I'm like, well, prove it to me. They're like, well, no, can't until you give me the title. And one of the things we've realized over time as we've been studying leadership and developing leadership programs is people who receive a title before they develop competency actually are worse leaders because they end up depending on the title to influence. And leaders who develop the capability and now where do you get this? You develop respect. How do you get respect? Brian Milner (03:47) Yeah. Pete Behrens (04:11) you develop respect through expertise, right? This is some combination of education and experience that people are willing and choosing to follow your lead. And this is the basis of where most people kind of get into leadership is they've developed a certain respect in the organization. Others are willing to follow them. And so that's a typical starting point, a typical entry into leadership. One of the things we also help leaders understand is that's also a trap. And I'll just pause there to let you reflect on it. We can go into that rabbit hole if you'd like to. Brian Milner (04:48) Yeah, no, let's talk about that because you're right. There's a lot of times when you see someone in an organization that they've been there, they don't necessarily have to have been there for a long time, but they've been there and they've developed the respect of their peers. They're the best programmer on the team. So the organization recognizes that, recognizes that others in the organization see them as being exceptional. So they elevate them. Now they're no longer just programmer where they did an exceptional job. Now they are manager of of the programming team and they've been elevated simply because they were the best among the bunch. Is that the right thing to do? Pete Behrens (05:22) Right. Well, it's definitely a common thing to do. And it's not it's not the wrong thing to do. I think the mistake a lot of organizations make and you know, you can go back to Marshall Goldsmith, who wrote the book What Got You Here Won't Get You There. And what he's alluding to is exactly that. The skills you need to get into leadership aren't the skills you need in leadership. And so the trap that that leaders fall into is, okay, and this is my path. And maybe your path as well is I'm the best engineer. I'm the best salesperson, marketing person, whatever that is. I'm now coming into leadership. What is your comfort? Well, your comfort is in the work itself. And so all this new stuff about working with people and projects and project management and people management culture and, and other things are very uncomfortable. So I go back to my comfort zone and that's when I start to micromanage. start to redo other people's work. I start to get too detailed into the weeds and I'm not doing the job of leadership, which is really influencing others down this path. And this is one of those traps that many leaders fall into is we get these steps up to leadership, but then we're not properly educated and provided the tools we need to do that job. I think the studies we've seen of only about a third of leaders get proper education, mentoring or coaching to be a leader. And the way we look at this is, is, you know, hiring anybody into an organization from the outside world. You would never hire somebody without a detailed resume that outlines every bit of education, every bit of experience. And then you're matching against 30 applicants or 100 applicants picking the best one. Yet every day. We're promoting people with zero expertise, zero education in leadership into those positions, and it's just It's really silly and it's really backwards. And yes, we want to give them opportunities, but we also need to help them. And that's what we're not seeing, is we're not seeing that help. Brian Milner (07:20) Yeah, yeah, I mean, I'm old enough. I know that I remember in my dad's day and age, you know, it was not uncommon for any large organization to have a leadership training program within the organization. You would be recognized as being exceptional. You would be put forward and then you'd enter the leadership training program of the organization that would help you to elevate and become an effective leader. And we don't see that. as much anymore. You just kind of are elevated and hey, kids, you're on your own. Pete Behrens (07:51) Well, and what they're teaching is management, not leadership. And I think one of things we differentiate with leadership is we manage things like projects. We manage programs. We manage technology. We can manage documents and even HR programs, things like that. We lead people. And so, yes, there are a number of things that organizations, HR programs, et cetera, do to kind of help. Oh, you need to do a one-on-one. or you need to do basic communication. Like there is some, but it's not the things we realize help elevate. You know, we separate this concept of vertical development from horizontal development. we often teach or organizations often teach the horizontal. That's the skills. OK, so you need to communicate. You need to delegate. You need to empower. But we're not teaching what we call the vertical development. And so what they're doing is their mindset is stuck in this kind of one stage. They got all this like this toolbox, but they don't know how to use the tools. And what we're trying to do is help them understand and give them a bigger toolbox to help them understand how to use these tools effectively to be better leaders. And that's a much different problem. It gets into self-awareness. gets into my focus as a leader from shifting in terms of the system and what I'm focused on and what my goals are. as well as just the time horizon I work in and how tactical, strategic or visionary am I. Those are harder things to teach, yet that's where leadership starts to emerge. Brian Milner (09:29) Yeah, well, it makes me think back to what you were saying about the person that would come to you and say, I want to be promoted. I want to be put into this next position. And your response of, me, kind of help me see that. I know you're right. There's a lot of times when people will look at things and say, I need the title or I'll be a leader when I am called this or when I'm put in this position. But what I'm hearing from you and what I hope everyone's hearing as well is, this starts far before that. If you're going to be on that road to being a leader, then it's actually something that you begin wherever you're at. And these are skills you can start to build over a lifetime to venture into that vertical area as you describe it. Does that sound correct? Pete Behrens (10:10) Exactly, exactly. And, you know, one of the things that, you know, I want to, you know, maybe warn the listener on here, we get a lot of people who come through and we work with a lot of, you know, agile coaches or leaders who want to become a coach or, you know, we have change agents, right? People who are, you know, their focus is change in the organization, right? This is where you see a lot of scrum coaches and things like that. And one of the things that we've realized over time is this notion of individual as change agent is incredibly challenging. And for the most part, we, the way we visualize or we talk about this to leaders is it's like, you know, you start singing a song and everybody looks at you like, okay, he's crazy. Like he went to like this evangelical school. He drank this Kool-Aid and he's coming back and he's like, yeah, yeah, that's just Tom or that's just Susie. And, and nobody listens to him. And we see this over and over again. And, and You know, one of the things we talk about is we've got to shift that solo into a chorus, right? So the construct of leadership, we think of often as an individual sport, but truly the only way change really starts to take hold in an organization, and that's where we're starting to shift from me to we, is how do we catalyze that choir to start singing? That's when organizations start to excel. And that's one of the things that when I'm starting to work with leadership teams, we start to understand this isn't just something we teach individuals. This is something we've got to collectively act on. mean, you think about any sports team and European football or US football or hockey or whatever that is. Those teams are are are awesome because of that choir element, because they all sing in the same tune, because they're all practicing all the time together. That's the other part of leadership that I want us to kind of focus on as we kind of take this journey. This isn't a solo sport. Brian Milner (12:07) That's such an important point. I can't agree with you more. just the concept there that I hope people kind of pick up on is, yeah, I mean, the Scrum Guide has for years talked about change agent and the Scrum Master being a change agent, but the kind of maybe indirect association from that was, you know, it's your job to take it on yourself to go and do this thing where You're right, it's too big of a job for one person to do this kind of thing by themselves. We have to have help, you have to have compatriots, you have to have someone who comes alongside you, because like you said, otherwise you're singing by yourself and everyone's looking at you like, what's that guy singing? Pete Behrens (12:48) Yeah, unless you're Satya Nadella, know, or somebody who has that capability on top of the org. And we actually see change happen, from people like Satya Nadella is kind of a rare example, I think, in our world and how he shaped Microsoft. But we actually see more change happening from the middle. You know, when we're teaching organizations and working with them, one of the things that I often Brian Milner (12:51) Yeah. Pete Behrens (13:15) I'm speaking to is the middle tier, you know, it's it's the frozen middle. It's the the between the rock and the hard place. They often feel the most pressure because it's the pressure from above, but the incapability of delivering below. But I try to help turn it around for them. And I say, you're the only one in the organization who feel the pain, but have access to the top layer for change. And and when it comes to organizational change. We actually find more change happening from the middle than we do from the top. Just because the top is so risky and they already have so much power, they don't really need or want change so much. They want to push it. But oftentimes that change happens from the middle. Brian Milner (13:54) Well, I know we've all seen the surveys and studies and things that talk about, you know, agile transformations and change movements and stuff and organizations that have identified leadership as being a kind of a ceiling or some kind of a blockage to real change taking place. So I guess what I'm hearing from you a little bit is don't let that become a blocker for us if we're not the top leadership, that doesn't need to be something that we need to look at and say, that's out of my hands. I can't do anything about it. We actually do have a role to play to that in the middle or other layers of our organization that we can affect the change through the leadership. Is that right? Pete Behrens (14:35) It's a perfect, perfect point. something we try to iterate all the time. Yes. You know, the number one thing we hear when we're working with organizations is I wish my manager could hear this, right? Because they are feeling constrained. They are feeling bound by certain rules and policies and governance and, you know, all the things that feel like our constraints. And that is true. And, you know, the only one who has access to these constraints is leaders. You know, we often describe, I call it the two games we play. You know, we get the agile and you get involved in a lot of these agile transformations. So we get the agile game played at the team layer. And maybe we get a little at the program layer, you know, if you've got some some cross team kind of coordination going on. And then we have the leaders and they play a different game, different rules, a different ruleset. And and then they've got the conflict, right? That's happening between these two layers. And I see this so often. right in the organization. Again, it's that middle tier who sees both games, has access to both games. And I think a lot of the problem we have in our agile community is we don't speak leadership. We don't speak the language leaders speak. I've been working, I worked with the organization and I talked to, know, this is like the CFO and the chief risk officer and, you know, the CIO. And I had a comment that came out and he said, Pete, For about three years, I've heard Agile blah, blah, blah. And I just didn't get it. And now I'm starting to understand the value because what we've learned how to do is speak leadership, risk, right? What is the risk in the approaches we're taking that are or aren't Agile? And what are the pros and cons of that risk? know, oftentimes our Agile evangelists. put agile on the good side and traditional on a bad side. And that's not true at all. Agile lives in kind of what I'd call a peak. Aristotle called this the golden mean, right? There's a peak. And on one side, there's a deficit of agility, and that is too much planning, too much rigidity, too much bureaucracy. But there's an excess agility. And this is where a lot of our coaches land. It's like hippie agile. Hey, man, what are you going to be done? I don't know, man. We're agile. Hang with us. hear that and they're like, I don't accept that. And so yeah, we've kind of swung right across this hillset down from deficit to excess and leaders aren't buying that. And I think that's been some of the downside of our agile community, our agile messaging. We've never broken through that ceiling of leadership. Brian Milner (17:12) Yeah, by the way, just I'm going to interject this a couple of times throughout, but if you like what you're hearing here from Pete, you can find out more from his site, agileleadershipjourney.com. Pete does a lot of classes and coaching and teaching and other things. And there's a lot that you can connect with Pete on through that site. And we'll put this in the show notes so you don't have to scramble to write this down. You can get back to this later. So I love that. that explanation, though. And it kind of resonates with me in a way, because I know one of the things I've talked about when I talk to product owners is the idea that product owners sort of serve as translators between the two worlds a little bit, right? Because they have to speak with developers who speak in very tech-speak kind of language. They have to speak to stakeholders who speak in very business-speak kind of language. Are product owners kind of that function? Are we losing the as product owners in doing that? Or is it not really a product owner thing? It's just more of an entire Scrum leadership thing. Pete Behrens (18:13) Well, yeah, take the word Scrum out. It is a leadership thing. Product owners are leaders, right? They are leading product. And again, the role of product ownership is a role of influencing others towards common goals. And I used to teach product ownership. was a certified Scrum teacher and taught product ownership, Scrum Mastership. I found product ownership to be the most challenging role ever because Brian Milner (18:16) Yeah. Pete Behrens (18:39) you're essentially optimizing for a solution that doesn't exist. So you have all these stakeholders who have all these needs and there's no possible way to meet the demand. And so the role of product ownership is how do I find the optimal across this dimension? so it kind of gets us into this world of, in business, there are often no right answers. Should we do strategy A or B? Well, it depends. You know, we're often as leaders chasing answers when there isn't one. I often talk about this as managing tension. And if we can kind of switch our mindset from there is an answer to this is a tension that will never go away and give you an example of this, like product owners struggle between tech debt and features. Well, that's something that will never go away. No matter how much we work on tech debt, no matter how much work on features, they will always be there. This is a tension that We simply need to learn how to manage. It's never a solution we can come up with. The same is true with strategy and tactics. Should a product owner be more tactical, live with the team, or should they be more strategic and sit with the stakeholders? Yes. The answer is yes. And again, this is not something a product owner will ever solve, but it is something that they can learn to manage. And you start to shift this mindset. And all of a sudden, my role as leader Brian Milner (19:50) Ha Pete Behrens (20:01) starts to change. We had one product owner speaking of that that I was working with years and years ago. And she said, Pete, I feel like a tennis ball getting whacked around the court by my stakeholders, you know, and she'd go talk to the state. I need this. Bam. You know, and she got to talk to the team. we can't do this. Bam. And another thing, bam. And she's like, just I can't survive this. And so we talked and we said, OK, let's let's think about your role different. And what she did, she ended up doing is she brought the stakeholders together and she said, OK, stakeholders, you guys can never agree. I'm forming a meeting that you must come to and you must fight each other for the feature prioritization. And if you don't come to the meeting, you're likely not to get prioritized. So that incents you to come. And number two, you got to convince your peers that that's more important than their need. And it just completely changed her association of her role from this. I'm the tennis ball to. Now I'm managing the court and they're all hitting balls back and forth at each other. And she's facilitating, you know, and that's just kind of one of those switch of mindsets where I can start to change my association, my work and get out of this, this sense of, there's an answer and I can figure it out to how do I manage this tension? Brian Milner (21:11) Yeah, 100%. Yeah. I mean, we believe in working in teams as a Scrum team. Why wouldn't we believe in working in a team of stakeholders as well? Right? Yeah, this is such great stuff. So I'll throw out another really loaded term at you because I know that whenever the term, whenever we talk about leadership, whenever we talk about agile leadership, or just leadership in general, you got to talk about culture. You got to talk about the idea of culture and changing culture and affecting culture and Pete Behrens (21:19) Yes, exactly. Brian Milner (21:38) You know, year people talk about, culture's a whole ball game, culture's everything. And other people who say, no, we focus too much on culture. It needs to be more about tactics and actually how we carry things out. And if you just do that, then the culture will follow. What's your take? Are we focused too much on culture? Is culture something that people care too much about? Or are we not focused enough on it? Pete Behrens (22:01) You know, I think as a as a word, just as like words like servant leadership or words like agile to get they get used and abused and people get tired of them. So I do agree culture as a word has is tired. But if you look underneath, what is culture representing? One of the terms we like to use is, you know, culture is like a shadow. It's simply reflecting something about us that we can't touch or change directly, but we can influence it. And people feel it like they feel the shadow of culture. They can sense it. And this is where, you know, again, we get into these tensions. You know, this culture is one of the things I use is culture's attention, not attention, but a tension like this, this fighting between sides. And, know, one of these is empowerment or alignment. You know, do we do things together like. Let's take a safe approach and everybody's in the same framework and the same process and the same RTE and the same rhythm. you we have the same rules and we use the same methods for estimating and that's alignment. But we know that taking alignment too far becomes routine and rigid and a death march and, all those negative sides of being in that heavy rhythm. But then we go the other way. Well, let's empower, let's Spotify, like everybody their own ruleset and they can just follow on principles and And then we know we take that too far and we've had this kind of wild chaos and people like, what's going on? And every team's different and we can't align. And this is like one of those elements of culture. You what we talk about is culture is that representation of that tension we're feeling. And it might be about speed and quality. You know, it might be about this empowerment alignment, but it's there. And whether we talk about it or not, it exists. And it influences. We like to use the metaphor of culture is the opposite side of the coin to leadership. And so we can choose to ignore it, but it is going to influence or it does influence us every day. I don't believe while the term is overused, I don't believe our focus on it is enough. And we've shown over and over again when we work with organizations that when leaders put a spotlight on some aspect, of that tension that's happening to your culture, they improve the system. And whether that's tension between leaders and employees, whether that's tension between quality and speed, whether that's tension between, you know, giving autonomy and freedom to doing things together, we can improve that system. And so what we try to help leaders understand is you need to make this part of your understanding and your focus, because if you don't, it will take care of you. Brian Milner (24:42) Yeah, yeah. Well, if I'm part of that, I mean, we talked about that, you know, people in the middle have kind of the biggest impact or you can have the biggest impact. That's where a lot of change takes place. If I'm in that middle and I recognize the culture of my organization is not what it should be, you know, we're not really in align with some of this stuff and we're definitely out of alignment with several of these things. What can I do? I can't make an edict across the organization, but how can I start to make that change if I'm in that middle section? Pete Behrens (25:13) Yeah, we had a leader that went through a number of our programs for a few years. you know, we have both educational programs, but we also have coaching programs and development programs that can kind of work on developing leaders. He moved to another company and for two years he sought to bring about what he knew to be a better way. Right. He saw the gaps. He saw the tension. He's like, I got it. I know this. But again, single voice. Everybody's looking at him crazy. He hires another person who's been through our programs to help him on his team as an agile coach. Now they got to. OK, now they're starting to sing together. It's a duet. And, know, from him for his perspective, simply it was these these conversation after conversation after conversation, the tenacity, you know, to to to say, give this a shot now. From that, we've been able to provide some more education to some of the HR, some of the senior leaders in this organization. And all of a sudden, the cascade, the dominoes start to fall. And they start to think, now I see what you've been saying all along. And so my message here is everybody can be a catalyst. Everybody can influence. But you're correct in the fact that it is not easy. What we try to help some of these catalysts, these one offs do is simply activate a second step, activate another voice that can help you bring about, you know, a message of change. And that's enough. And I think a lot of leaders get stuck because they like, I can't run a transformation. I can't get focused on this change of metrics or policies or governance. And you're right. You will never probably have access to some of those levers unless you move up the chain enough. But you can influence one other person. You can influence a few people. You can influence one class or, you know, bring someone in to help change our voice. So that's what we try to aim for some of these change agents. Brian Milner (27:12) Yeah, I love that. It's kind of the cascading effect, right? I mean, if you spark that one spark into something else, well, as long as that continues, that chain continues, it can spread. It's the old, if I tell two friends and they tell two friends, then this thing is going to work. Yeah, I love that. And that's a great practical thing too, right? mean, because I think a lot of people in that middle start to feel frozen and feel like, What can I do? I can't do anything. I think that's a great point. If you can just affect that cascade into one other area, one other person, one other department, then that's all it takes for it to start to get rolling. I love that. Well, this has been a great conversation. And it's never long enough. And this one, we could go on for another several hours on this one. If you really like this, I'm Pete Behrens (27:38) It's hard. Brian Milner (27:58) I'm going to encourage you again to visit Pete's site, agileleadershipjourney.com. There's a lot of resources for you there. You can get connected to Pete. And there's a lot of things you can move forward with in your agile leadership journey from Pete. So I can't thank you enough. Thanks, Pete, for taking the time out and sharing your wisdom with us. Pete Behrens (28:16) Thank you, Brian. Appreciate the conversation.

In this episode of the Agilists: Aspire and Achieve podcast, host Renae Craven chats to Emily Lint about her journey into entrepreneurship. Emily shares her insights into how she made the decision to work for herself and how she prepared herself for that. Emily talks about how she finds clients and wins work and what she has learnt about herself and entrepreneurship along the way.   About the Featured Guest Emily Lint is a budding industry leader in the realm of business agility. Energetic and empathetic she leverages her knowledge of psychology, business, technology, and mindfulness to create a cocktail for success for her clients and peers. Her agile journey officially started in 2018 with a big move from Montana to New Mexico going from traditional ITSM and project management methodologies to becoming an agile to project management translator for a big government research laboratory. From then on she was hooked on this new way of working. The constant innovation, change, and retrospection cured her ever present craving to enable organizations to be better, do better, and provide an environment where her co-workers could thrive.    Since then she has started her own company and in partnership with ICON Agility Services serves, coaches, and trains clients of all industries in agile practices, methodologies, and most importantly, mindset. Please check out her website (www.lintagility.com) to learn more.   Follow Emily on LinkedIn https://www.linkedin.com/in/emilylint//) The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared.   Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org    Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg    Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile.   About our Host Renae Craven has been coaching individuals, teams and organizations for over 13 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel Crave Pilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn (https://www.linkedin.com/in/renaecraven/).

In dieser Folge des Produktwerker Podcast diskutieren Oliver und sein Gast Urs Reupke über das Zusammenspiel von OKRs und Scrum. Urs, Unternehmensberater bei it-agile und Certified Scrum Trainer der Scrum Alliance, teilt seine Einblicke in die praktische Anwendung von OKRs und erklärt, wie diese Methode der Zielsetzung und Fortschrittsmessung die agile Produktentwicklung bereichern kann. OKRs, also “Objectives and Key Results”, dienen dazu, klare Ziele zu definieren und den Fortschritt durch messbare Ergebnisse zu überprüfen. Diese Struktur passt sehr gut zur iterativen Natur von Scrum. Insbesondere das Prinzip von Inspect und Adapt, das in Scrum fest verankert ist, findet auf einer höheren Ebene in OKRs seine Entsprechung. Während die Produktvision in Scrum oft schwer operationalisierbar scheint, können OKRs als Brücke dienen, um große strategische Ziele in umsetzbare Zwischenschritte zu übersetzen. Eine zentrale Erkenntnis aus der Diskussion von Urs und Oliver ist, dass OKRs Product Ownern helfen können, sich auf Outcome-Ziele zu konzentrieren, anstatt sich ausschließlich auf Outputs zu fixieren. Diese Fokussierung auf Wirkung eröffnet Product Ownern und ihren Teams mehr Freiräume, eigenverantwortlich Entscheidungen zu treffen und kreative Lösungen zu finden. Die Verbindung von OKRs und Scrum ermöglicht es, strategische Ziele nicht nur zu definieren, sondern auch mit konkreten Aktionen im Sprint voranzutreiben.. Ein weiterer Vorteil von OKRs in der agilen Produktentwicklung liegt in der Möglichkeit, den Diskurs mit Stakeholdern auf eine strategische Ebene zu heben. Anstatt über einzelne Features zu debattieren, können sich Gespräche auf die gewünschte Wirkung und übergeordnete Ziele konzentrieren. Dies kann Product Owner entlasten und gibt ihnen die Freiheit, die Umsetzung eigenständig zu gestalten, ohne dass Stakeholder in die Details eingreifen. Die Folge endet mit Urs' praktischer Empfehlung an alle Product Owner: Einfach anfangen! Auch ohne die gesamte Organisation von OKRs zu überzeugen, können Teams die Methode für sich ausprobieren, um Fokus und Klarheit zu gewinnen.

In this episode of the Agilists: Aspire and Achieve podcast, host Renae Craven and guest Shena Goorawa explore the importance of adapting to tough situations and embracing new challenges to grow your career. We discuss the importance of resilience and how leaning on your support crew can help you through the toughest challenges.   About the Featured Guest Shena, an Agile Delivery Team Lead, began her career in 2006 in the call center industry. After a retrenchment in 2011, she transitioned to IT, starting in testing. Since 2012, Shena has excelled in agile roles, including agile trainer & Head of Agile Test Competency Centre, SA. Despite a layoff in 2020, she now leads Agile Delivery Managers in the FinTech industry, driving innovation and growth. Follow Shena on LinkedIn (https://www.linkedin.com/in/shenagoorawa/) The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org  Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg    Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile.   About our Host Renae Craven has been coaching individuals, teams and organizations for over 13 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel Crave Pilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn (https://www.linkedin.com/in/renaecraven/).  About our Sponsor Scrum.org is the Home of Scrum, founded in 2009 by Scrum co-creator Ken Schwaber focused on helping people and teams solve complex problems by improving how they work through higher levels of professionalism. Scrum.org provides free online resources, consistent experiential live training, ongoing learning paths, and certification for people with all levels of Scrum knowledge. You can learn more about the organization by visiting www.scrum.org.

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

In this episode of the Agilists: Aspire and Achieve podcast, host Renae Craven unpacks guest Rebecca Murphy's career journey and how she found herself in Tech after completing her Literature degree.   About the Featured Guest Rebecca fell into tech after realising that not everyone who graduates with a Literature degree gets a column at the Guardian. She has worked in roles spanning Product Management, agile coaching and leadership across the mobility, ecommerce, and publishing industries, building everything from user-facing products to backend, internal services. All while supporting agility, with a little a. Follow Rebecca on LinkedIn (https://www.linkedin.com/in/rebeccaamir/)   The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org  Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg    Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile.   About our Host Renae Craven has been coaching individuals, teams and organizations for over 14 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel Crave Pilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn (https://www.linkedin.com/in/renaecraven/).    About our Sponsor Scrum.org is the Home of Scrum, founded in 2009 by Scrum co-creator Ken Schwaber focused on helping people and teams solve complex problems by improving how they work through higher levels of professionalism. Scrum.org provides free online resources, consistent experiential live training, ongoing learning paths, and certification for people with all levels of Scrum knowledge. You can learn more about the organization by visiting www.scrum.org.

Die Aussage "Agile is dead" macht aktuell die Runde und sorgt für lebhafte Diskussionen auch in der Product-Owner-Community. Ist das Ende agiler Methoden wirklich erreicht, oder handelt es sich um eine missverstandene These? In dieser Folge der Produktwerker spricht Kai Simons mit Oliver über diese Frage und mögliche Auswirkungen auf Product Owner. Kai Simons, Gründer von Agile Growth und Certified Scrum-Trainer der Scrum Alliance, beleuchtet, warum der Ruf nach dem "Tod von Agilität" in der Luft liegt. Dabei sieht er die Wurzeln dieser Aussage weniger in einem Versagen der agilen Prinzipien, sondern vielmehr in der Art und Weise, wie diese umgesetzt wurden. "Agile Methoden sind leicht zu verstehen, aber schwer zu meistern", betont Kai. Viele Organisationen scheitern nicht an den Ideen, sondern an der konsequenten Transformation und den Rahmenbedingungen, die dafür notwendig sind. Für Product Owner bringt diese Diskussion einige Herausforderungen und Chancen mit sich. Die Rolle erfordert nicht nur fachliche Expertise, sondern auch Leadership-Qualitäten und die Fähigkeit, eine klare Produktvision zu entwickeln und zu kommunizieren. Kai teilt aus seiner Erfahrung, wie oft die falschen Personen diese Verantwortlichkeiten übernehmen, ohne den nötigen Mut, Entscheidungen zu treffen oder die strategische Weitsicht mitzubringen. Dieses Missverständnis trägt zu dem Frust bei, der Agilität als gescheitert erscheinen lässt. Ein zentraler Punkt der Diskussion ist das Vertrauen – sowohl in die eigenen Fähigkeiten als Product Owner als auch in das Team und die Organisation. Nur wenn Product Owner und Teams das Vertrauen aufbauen und halten können, lassen sich agile Prinzipien effektiv umsetzen. Die Verbindung zwischen den agilen Werten und der Realität im Unternehmen ist entscheidend. In vielen Fällen fehlen jedoch die Unterstützung durch Scrum Master oder ein Verständnis dafür, wie die Zusammenarbeit mit Entwicklern gestaltet werden muss, um langfristig erfolgreich zu sein. "Agile is dead" muss nicht das Ende agiler Methoden bedeuten. Vielmehr ist es eine Chance, den ursprünglichen Kern agiler Ansätze wiederzuentdecken und neu zu beleben. Es geht um kontinuierliches Lernen, ehrliches Feedback und die Bereitschaft, an sich selbst und den eigenen Prozessen zu arbeiten. Für Product Owner heißt das konkret: Die Bereitschaft, Führungsqualitäten zu entwickeln, sich mit den Bedürfnissen des Teams auseinanderzusetzen und die agile Transformation aktiv mitzugestalten. Wer also glaubt, Agilität sei tot, sollte genau hinhören: Agilität lebt dort weiter, wo Menschen mutig Verantwortung übernehmen, wo Teams und Organisationen bereit sind, Veränderungen zu wagen, und wo die Prinzipien nicht als Checkliste, sondern als Leitlinien für echte Zusammenarbeit verstanden werden.

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.

What does it take to be an effective Scrum Master? In this episode, Brian Milner and Gary K. Evans, author of The Effective Scrum Master, explore the nuanced role of Scrum Masters, the importance of people skills, and the shift from efficiency to effectiveness. Overview Join Brian Milner as he chats with Agile coach and author Gary K. Evans about the essential qualities of an effective Scrum Master. From fostering self-organizing teams to balancing proactive leadership with people-centered strategies, this conversation unpacks the skills and mindsets needed to thrive in the role. Whether you’re new to Scrum or a seasoned pro, this episode offers fresh perspectives and practical advice for taking your Agile expertise to the next level. References and resources mentioned in the show: Gary K. Evans The Effective Scrum Master: Advancing Your Craft by Gary K Evans Join the Agile Mentors Community Mountain Goat Software Certified Scrum and Agile Training Schedule Certified ScrumMaster® Training and Scrum Certification Advanced Certified ScrumMaster® Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Gary K. Evans is a seasoned Agile Coach and author of The Effective Scrum Master, with over 30 years of experience transforming Fortune 100 and 500 companies through Lean-Agile practices. Known for his expertise in building high-performing teams and training over 15,000 professionals, Gary brings a unique focus on people-centered solutions to complex organizational challenges. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We are back and it's another episode of the Agile Mentors podcast. We're getting towards the end of the year. I am here with you, as always, Brian Milner. And today I have a very special guest with me, Mr. Gary K. Evans is with us. Welcome in, Gary. Gary (00:17) Thank you, Brian. It's great to be here. Brian (00:19) Very glad to have Gary with us. Gary is an agile coach. He's a lean consultant. He owns his own company called Evanetics, but he is also the author of a newly published book that came out this summer. It's called The Effective Scrum Master. And it really is a comprehensive guide. It's a really interesting read. So I thought we'd have him on to talk to us about. what that means, an effective scrum master. So scrum master is this episode, I think it's gonna be really a special one for you. So Gary, let's start with that question. When you say an effective scrum master, what is an effective scrum master? Gary (00:56) In my experience, I've worked with a lot of Scrum Masters who go through the motions, they understand the events, they focus on how to run these Scrum events. But the teams flounder and they struggle with what should I do next? How do I anticipate things? And the Scrum Masters themselves often get very frustrated. One of the complaints that I hear, especially from early to mid-career Scrum Masters is I have this anxiety. How do I know that my team is operating as efficient, as efficiently and effectively as they can because they focus so much on efficiency. So this idea of effectiveness really is much more important. In fact, John Kern, one of the co-authors of the Agile Manifesto, who wrote the foreword for my book, he focused in on that word effective because we spend so much of our energies trying to be efficient. that we aren't accomplishing what we need to do, which is to build self-organizing, mature teams. And that's really the focus of my book. Brian (02:01) That's an awesome distinction, I think, because I like that a lot. There's a conversation that I will have sometimes in class about how that drive or search for trying to be not effective, sorry, what was the other word that you used? Efficient, sorry, sorry, just slipped my mind, ADHD. But the efficient kind of quotient there I think is... Gary (02:18) Efficient. Brian (02:27) something that in business in the business world today is a highly visible term. It's something that everyone seems to think is needed. But, you know, that really dates back to sort of the assembly line and efficiency experts that would stand behind you with a stop clock and try to get you to do something, you know, point two seconds faster so that it would total up to, you know, more productivity over the course of the day. But that's not the kind of work we do. Gary (02:56) I love the fact that you've mentioned that that was really the Frederick Winslow Taylor scientific management approach. And it was very much based on this idea of efficiency. But I have seen so many teams and as an agile coach, I've had multiple experiences of teams that are very, very efficient at going in the wrong direction entirely. They've lost their focus on true north. They don't understand what it is they're actually supposed to do. They think that the Scrum Guide, 14 pages in the Scrum Guide, is their Bible. And that's all that they need to know. And nothing could be further from the truth. Brian (03:37) Yeah. Yeah. And to me that, you're talking about efficiency versus effectiveness. You know, if we were a company that was trying to create a new drug to cure some disease, you know, I want effective. I don't want efficient. I don't want someone, I don't want to produce a million pills that don't work. I want to produce, you I'd rather produce one that works, you know. Gary (03:59) Exactly. Brian (04:05) And that seems to be kind of something that I think a lot of teams are missing today. Gary (04:09) It does indeed. Brian (04:10) Well, good. I like that distinction. I think that's a good distinction and that's a good place for us to start to think about this role as being kind of more effective. I think that they're sort of, I don't know, I'm kind of curious what your take is on this. Is it a marketing problem? Is it an education problem? Why is there so much confusion, I think, about what a scrum master, what a good scrum master is? Gary (04:41) That's a really deep and broad question. Part of it is that in the beginning, when Scrum was introduced into the community and was just beginning to become known, there were two attributes of Scrum Masters that were repeated again and again and again. That was you became a servant leader for the team and you removed impediments. Brian (04:44) Just a light casual one here. Gary (05:09) Unfortunately, most people stopped at that point. And they didn't realize that this, the Scrum Master role, and I'll admit, I take a very expansive view of the Scrum Master role because I've been doing this since 1993, basically, 1994. And I've learned through making lots and lots of mistakes. And the idea that All we have to do is be a servant. Well, what does that mean to be a servant leader? Nobody ever really defined it. I actually wrote an essay a number of years ago on what it meant to not be a servant leader so that I could understand by contradiction what it was that I should be doing. I called it the top 10 scrum master crimes. And really, a lot of them really had to do with crimes because it's very easy for a scrum master to start to merge into making decisions for the team that the scrum master should not be making. Now, there are times when a scrum master should direct the team, should make decisions for the team if the team is not qualified to make certain decisions because they're just too new. But this idea of being a certain leader There's so much more to that. In my expansive view of the Scrum Master role, it is not a process role first. It's a people role. And to be an effective Scrum Master, you have to be an effective people person. I've worked with so many teams and coached Scrum Masters. Scrum Masters just did not like people. They weren't people persons. And the teams responded accordingly. So. A lot of the coaching that I do with my Scrum Masters is you've got to reach deep. You've got to be able to get into people's lives rather than hold them off, you know. And so a lot of it has to do with that. Brian (07:10) I love that. I wholeheartedly concur with that. I've talked on this podcast a little bit about how it seems like we've lost the focus of that first line of the Agile Manifesto, individuals and interactions over process and tools. And I mentioned when I go to Agile conferences sometimes, I feel like the majority of the talks that I see and hear are process and tools talks rather than know, individuals and interactions talks. And I can't agree more. I think that's really a focus for us as Scrum Masters is the individuals and interactions portion, the people portion. You know, our teams are made up of people and if we're not good with helping understand how people work together, we're kind of really missing the value of what it is we deliver to the teams, I think. Gary (08:04) And Brian, the people are all different. And to have a one size fits all because the scrum guy says do X, and Z. Well, that'll work for some people, but it will not work for others. And it may even build resentment within the team because they feel that they're being treated unfairly. The focus, the theme of my book and the reason I wrote the book. Brian (08:06) Right, exactly. Gary (08:30) is that I had seen so many teams that were floundering under Scrum Masters who really didn't understand their own role. And I came up from my experience, I defined four different categories that helped to elaborate what the Scrum Master should be if they want to be effective. And I labeled those as Sherpa, Shepherd, Sheepdog, and Diagnostician. I couldn't really think of a word. I started with an S for diagnosticians. But I have a strong medical background, so diagnostician really helped because the sherpa is the expert. And to be an effective scrum master, you have to be an expert, not at scrum, but at agile. We really want, I want my scrum masters to be agile masters. And as a coach, I'm constantly pushing them. How are you improving your craft? And what is involved in that craft? So you've got to be an expert. Brian (08:58) Hahaha. Gary (09:26) Now for a new scrum master, that's a contradiction in terms. You can't be an expert if you are just at the beginning of the journey. But there are things that you can do. And I discussed this. In order to from exposure, you can gain experience. And from experience, you can generate expertise. And so that's the first one. If ultimately you need to be a master of Agile. Secondly, a Sherpa and then a... a Sherpa and then a Shepherd, you have to be able to guide the team. And you can't guide somebody if you haven't been through that path before. So this is where the issue of longevity, education, and just exposure and experience with different teams on different projects. This is where the maturity comes and you start to develop a depth of understanding. But then there's the hardest part, the hardest persona of the scrum master is the sheepdog. This is where you are the protector of the team. And so many scrum masters fold in this area because a threat will come either from management or from within the team or somebody outside the team like a product owner. And the scrum master doesn't understand how to protect his or her own team. I'll share a little war story with you that is in the book. I had a product owner who one morning came in and just started ripping through several of my team members. I don't know what happened at that point. I stepped between him and the team and I said, do not take another step forward. I was ready to defend my team physically. It didn't come to that. And later I learned the reason for why he was so upset. But if you're going to be a sheepdog and protect your team, it may require personal sacrifice. It may require professional sacrifice. And this is the area where so many scrum masters, they can't deal with that part because they don't have that confidence. So you've got the Sherpa who's the expert, the shepherd who is the guide. The sheepdog who's the protector and finally the diagnostician who is the healer. Things are going to go awry and you have to have a way of diagnosing what the root cause of the problem is. And this is where the issue of metrics and understanding your team members, building a rapport with your team members that quite often is extremely intimate. I have had team members, I have a series of questions I ask all my team members so that I understand their background and such and also things that I need to be aware of. And I will ask them, do you have any medical issues or other accommodations that we might need to consider for you? This is an issue of respect so that we don't put somebody in an uncomfortable situation. It's a strictly private conversation. I've had people share with me that they have a drug problem. that they're caring for an ailing parent, that they're going through a divorce, all kinds of different issues that come out. And we work out special signals so that if they're having an episode someday, they just give me that signal. And I know that I need to either give them space or give them some special consideration. This is what I mean by the people issue. You've got to get to the point where you allow people's lives to splash onto you and you get wet with their issues. And yet you still have to maintain your autonomy and separation in order to work with the whole team together. The Scrum Master role is extremely complex from my perspective because it involves people, as you say, individuals and their interactions. That's where we have to start. Brian (13:33) I agree. And that's a great call out to say, to talk about there, just the idea that, you these are, these are individuals, not, they're not robots, you know, like they're not AIs yet. These are human beings and they have lives outside of work. They have things that affect them. And if they're going through a divorce, like you said, then you think that might affect their work life? Well, of course it will. Cause they're a human, right? And that's gonna... Gary (13:43) Right. Yes. Brian (13:57) that's going to affect their, their mood that day. That's going to affect, you know, how productive they are. It's going to affect lots of things. And, and, you know, we, we've talked here on the podcast a little bit about making accommodations for people with different, neurodivergent traits like ADHD or, autism or other things like that. And, know, I've always loved the idea of, know, putting people in the best position to be successful, you know, trying to understand what is. unique about them, strengths and weaknesses, so that you can help them to be put in a position that they can shine, right? They can really contribute in their own unique way. And we have to allow for both those strengths and weaknesses. We have to help them with the weaknesses. We have to put them in a position to share their strengths. Gary (14:49) And this leads to a slightly different topic if I can move up a little bit. The scrum master role is an endangered species right now. And there's a reason for that. There's several reasons for that. One of which is what we've been talking about. So many scrum masters are not people persons. And as a result, the teams are not accomplishing what the organization needs. And therefore the scrum master is regarded as overhead. Brian (14:52) Yeah, please, please, please. Hmm, yeah. Gary (15:19) as ineffective. And frankly, that's correct. There are currently, if you look at the Scrum Alliance and Scrum.org, I got the figures from these companies as of the beginning of this year, there are about two million Scrum Masters in the world right They're not all equally effective, Many of them are PSN1s from Scrum.org and there are like 625,000 of those, that type of thing. And then you get 39,000 PSN2s and then you get a thousand or so PSN3s. You can see the drop off there, just huge drop off. And the certification issues lead people to think that they're a Scrum master. Scrum two days or? An online examination doesn't prepare you. It simply doesn't. We've not done a good job of helping people understand through these major certification roles. that this is a starting point, but it's not going to make you effective. And part of it is it's become commoditized. And so we have this issue of lots and lots of scrummasters, most of whom really are not people persons and most of whom don't understand how to deal with a team and build a team rather than just an assembly of individuals. I've taken over teams that have been floundering. I've done this multiple times. And on day one, it's a series of isolated individuals. That's the best that they could have. Because there was no cohesion that could be found. And that always takes me a lot of effort and a lot of time to figure out how can I find cohesion within the team. So it's exhausting. The Scrum Master rule is really exhausting at times. And if someone's not tired at the end of the day, they're not doing it right. Brian (17:22) Yeah, I really am in alignment with what you're saying here. And I've thought about this issue a lot as well, and just the idea that we seem to find ourselves in a situation where, as you said, there's a lot of people who have that certification. And as someone who gives people certifications, I have to take my own part in that. I have to accept my own role and what that plays in it. But I think that you're right to... The training is necessary, right? You have to understand the basics. You have to understand these things before you can do anything else. However, I think that the disservice that the industry has done is to make this proclamation that if someone is certified, that they are ready to lead. And that really is what a Scrum Master is, is a leader in the organization. They're a leader for the Scrum process in the organization. And that's just... Gary (17:55) Yes. Yes. Brian (18:23) not true, right? It just takes more ongoing mentoring and coaching for that person to get to a place where they are really a, you know, what we would call a change agent, right? They are there to, you I always like to use the term infect the organization. They're there to spread and infect this mindset, this philosophy. And if we don't understand it ourselves, if we're not really living that philosophy, If we want our team to be experimentation based and we don't experiment ourself and we don't kind of demonstrate to them what it looks like to experiment, to try things, to fail, to figure out why that didn't work and then apply a new change and say, let's try something different. If we don't demonstrate that, not just tell them, but demonstrate it, they're never going to get that. They're going to stay, as you said, a collection of individuals. And I think that's, to me, that seems to be one of the big issues today with Scrum Masters and with Scrum in general is just that we have, you know, in opposition to your book, ineffective Scrum Masters that aren't really helping people see what Scrum should be. Gary (19:41) Exactly. And you've touched on what I call the four E's, which are exposure, experience, expertise, all built through experimentation. And you use that word to experiment. We need to experiment. But experimentation takes courage. Now that is one of the Scrum values. But when you get a young person or a new Scrum master who's in a role in an organization that may have certain, let's say, unsafe environment and cultural factors. It's very difficult for most people to build that courage to say, we've got to change this and become agents of change. Now, obviously they can, they should be diplomatic. They should be respectful, but they should also be persistent. But being able to see that requires a vision. You have to be able to be able to look around and see where are the big problems that we have? Why should I rearrange the deck chairs on the Titanic if the ship is sinking? Brian (20:41) you Gary (20:45) And so having that vision, again, comes from maturity. And the Scrum Masters that I work with, I push them pretty hard because I want them to grow. And every one of them has thanked me. But they didn't thank me during while it was happening. Brian (21:06) Ha Yeah. Yeah, I can understand that. mean, we, you know, one of the analogies I'll use there is like, we, a lot of us that have gone through the process and become a trainer will say it was hell while we went through it, but we look back on it and think that was necessary. We needed to go through that. now that we've gone through it we're on the other side, that was a necessary component of becoming an effective trainer was really seeing it up close and personal and seeing how other people do it. So I completely get that. Gary (21:31) Exactly. Brian (21:36) I want to ask you a question here that I know this is a loaded question. I get this question all the time. But I thought it might be interesting to hear your perspective on this from the effective Scrum Master perspective. People constantly ask, well, what does a Scrum Master do all day? Because when you look at the Scrum Guide and you look at the things that we have as responsibilities, You know, the two main responsibilities we have that are ongoing is to make sure events happen and make sure that the time boxes are kept according to the Scrum Guide. But I try to tell people there's a lot that goes on between those events. It's not just about the events, right? There's a lot that we do. just help our audience. For those people who are listening and don't really have a clear picture of what a Scrum Master does, just give us some samples of what you see as activity that effective Scrum Masters would take on a regular basis. Gary (22:30) What an interesting qualitative question. Brian (22:33) Ha ha ha. Gary (22:34) And I say qualitative on purpose. What does a scrum master do? What a scrum master should do is listen, listen a lot, observe, even if you're remote and virtual. You should be monitoring the Slack channel. You should be having video sessions. You should be attending team discussions whenever you can, but not only to listen, but to be the last one to speak. This is a big issue. So a scrum master often is considered to be doing nothing. But what the scrum master is doing is listening, watching, being the last to speak so that he or she does not taint the conversation among the team members. And it's very easy for that to happen. They should be compiling. team metrics. And I have a very lengthy section in the book on metrics, not only velocity and burn down charts and that type of thing, but a number of other other metrics that I've developed over the years for my own teams. So that the Scrum Master and the team can understand their own performance. They should be training, obviously, as a Sherpa, as an expert. They should be conveying knowledge to the team and they should be teaching every time they're talking to somebody, they should be teaching someone. So it's not a prescribed set of activities in my estimation of what a scrum master does. And I'm going to I'm going to use an analogy here. And it's going to it's going to offend some people because they're going to say, that's a terrible analogy. Well, it's actually a good analogy if you take it as that. The scrum master is like a parent. and needs to nurture the family. How does a parent, what does a parent do? They listen, they observe, they teach, they guide. Sometimes they have to protect, sometimes they have to discipline. And these are all skills that make for a good effective scrum master. So as I say, it's a qualitative issue. But a person who cannot parent well, I'm not saying the team are children, I'm saying they're your family. You need to parent your family. And you need to, as an experienced person who hopefully has a bit more experience and exposure and wisdom. and has better insight into how the world works, even the world of the organization, the Scrum Master has to be able to convey that on a day-to-day, hour-to-hour basis. It is not a part-time job. It is a full-time, exhausting, boots-on-the-ground position that many people just cannot fill. It's sad, but not everybody can do everything. Coming back to the certifications again, job ads always want to know you need to have a CSM or a PSM. You need to have an ACSM, type of thing, advanced certified Scrum Master. These are proxies that companies use because they don't know what a Scrum Master does. They don't know how to qualify it. So they try to quantify it through a certification. And what they have are two million Scrum Masters. who are certified in the world. How many of those are really good? Not all of Brian (26:06) Right. Gary (26:07) So the reason that I dwell on this a little bit, Brian, is my book is there to help people understand. not only the limits, but the expanse of what they should do. And there are limits to what a scrum master should do, but there's also an expansive view of they need to do more than just be a servant leader and remove impediments. Those are important. That's not the end of it. Brian (26:33) I agree. It's kind of interesting because it's a delicate balance, right? Because it's sort of like, you know, there's not a recipe. There's not a clear, hey, here's the 10 things that you do every day. And just when you come in the morning, check this list off and do these things, right? There's not that. But I think that the other mistake that I see some Scrum Masters make sometimes is that they treat it as being a purely reactive kind of position where I'm going to sit back and wait for things. And then when something happens, then I'll, then I'll jump in and I'll do something based on what someone else has done, which I think is a mistake as well. We we're proactive. We were very proactive to, to make an impact and make a difference. And when we recognize something's needed, we, got to jump in there. We got to get in there and do something about it when it's needed. you wouldn't want to have a coach of a team who set back and just, you know, Gary (27:26) It is. Brian (27:30) waited for someone to come to them and ask them for questions. There's no strategy. There's no paying attention to fundamentals. All those things would kind of go out the window if that coach isn't more proactive with his approach towards his or her approach toward the team. Gary (27:45) Exactly. That's a wonderful analogy because I was a soccer coach as well. I'm a soccer player as well. And when I'm coaching youth or that type of thing, I have to teach them how to use this sideline, the touch line in order as a virtual defender. need to have been on the field to know how to teach them how to operate on the field. And if I can't get involved with them, if I just wait until they make a mistake, they're going to make a lot of mistakes. Brian (27:48) Hmm. Gary (28:14) And you've touched on this idea of the passive scrum master. Scrum master is not a passive role. I had a product owner, one of the best that I've ever worked with in my career. We were having a very heated conversation one day, as we often did. And he said, Evans, you're an activist scrum master. And I had never heard that before. And I reflected on it a little bit and I said, Chuck, you're right, I am. But not everybody has that kind of personality. So each scrimmaster has to identify where they may need to improve, maybe some of their assertiveness, some others need to learn how to hold back. It's a learning curve. It's a learning 24-hour-a-day learning session. We're all different. teams are different, the Scrum Masters are different. And as we get more experience and develop more expertise, we handle things differently as a result of that growth. And my role as a coach is to grow the Scrum Masters, to grow the teams. And I've loved it because I love working with people. So you get to work with people, you get to solve problems and you get to see tangible results in people's careers. What more could you ask? Brian (29:36) Right, right. I'm with you. I'm right there with you. I can't agree more. Well, this has been a great discussion. just want to, you know, we mentioned already your book is called The Effective Scrum Master. We're to put links in our show notes to that if people want to go and find that and just, but you can find it on Amazon. Gary K. Evans, The Effective Scrum Master. Gary, how can people find out if they want to get in touch with you or find out more about your work, how can they get in touch with Gary (29:37) Thank Well, appreciate that. I am currently putting up, there is a, we have a website. It's called effectivescrummaster.com. I'll repeat that. Effectivescrummaster.com. There's a sign up link there. It's the page is just under construction at this point. It's live, but people can go up and they can enter an email to be notified when we start to make changes. There'll be some free information there, some resources that they can download. We've got a plan on how we're going to roll this out, but that's just beginning. And so I hope that people will go and visit that and hopefully we'll be able to develop a relationship and they'll be able to reach out to me through that website. Again, effectivescrummaster.com. Brian (30:51) Awesome. Well, thank you so much, Gary, for making the time. It's been a really great conversation and I really appreciate you making the time to come on the show. Gary (30:59) Brian, this has been my privilege and I really appreciate it. Thank you so much.

In this episode of the Agilists: Aspire and Achieve podcast, host Renae Craven chats to Natalia Juszkiewicz about how she became a Scrum Master, how she learnt about the role, and how it fits into an organization. About the Featured Guest Natalia is a Scrum Master and Agile Coach with over 10 years of experience, including 3 years managing other Scrum Masters. Natalia values partnership and openness, specializing in team building and gaining new perspectives from working with top-level management. As a mentor in the Women in Agile program, Natalia met three wonderful women. In her free time, Natalia enjoys reading crime novels. Follow Natalia on LinkedIn (www.linkedin.com/in/natalia-juszkiewicz-949b6aa5) The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org  Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg  Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile. About our Host Renae Craven has been coaching individuals, teams and organizations for over 13 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel Crave Pilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn (https://www.linkedin.com/in/renaecraven/).  About our Sponsor Scrum.org is the Home of Scrum, founded in 2009 by Scrum co-creator Ken Schwaber focused on helping people and teams solve complex problems by improving how they work through higher levels of professionalism. Scrum.org provides free online resources, consistent experiential live training, ongoing learning paths, and certification for people with all levels of Scrum knowledge. You can learn more about the organization by visiting www.scrum.org.

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.

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.

Summary In this episode, Jimmy Fosdick joins Dave for a conversation about his journey from traditional project management to agile. They discuss the challenges of applying traditional project management to software development, the importance of understanding the context and problem domain when choosing project management approaches, and the misuse of the term 'agile' in the consulting industry. They also touch on the legacy of Frederick Taylor and the need for a people-centered approach in project management. The conversation explores the challenges of traditional project management and the need for a more empirical and agile approach. They discuss the problems with big upfront planning, the importance of shorter cycle times, and the fear of failure. The conversation also touches on the need for more humane workspaces and the changing nature of work. The principal themes include the limitations of traditional project management, the benefits of an empirical approach, and the evolving workforce and work environment. Takeaways • Traditional project management is effective for problems that can be solved on paper upfront, but may not work well for software development. • Agile approaches, such as Scrum, are better suited for software development and other complex, empirical problems. • The term 'agile' has become an overloaded and misused brand in the consulting industry. • Hybrid approaches that combine traditional project management and agile practices can be problematic and may not fully embrace the values and principles of agile. • A people-centered approach is essential in project management, and the focus should be on collaboration, respect, and solving the right problems. Traditional project management relies on upfront planning, which can lead to longer cycle times and higher failure rates. • An empirical approach, such as Agile, allows for shorter cycle times and the ability to adapt and change as needed. • The fear of failure often hinders organizations from embracing more agile and iterative approaches. • There is a growing emphasis on creating more humane workspaces and allowing for more flexibility and creativity in the workplace. • The nature of work is changing, and organizations need to adapt to the expectations and needs of the new generation of workers. Titles • The Misuse of the Term 'Agile' in the Consulting Industry • From Traditional Project Management to Agile: Jimmy Fosik's Journey The Changing Nature of Work • Overcoming the Fear of Failure Chapters 02:20 Introduction and Background 05:52 The Challenges of Traditional Project Management in Software Development 08:33 Differentiating Scrum from Traditional Project Management 12:13 The Misuse of the Term 'Agile' 14:38 The Problem with Hybrid Approaches 22:17 Legacy Code in Our Heads: Shifting the Project Management Paradigm 26:21 The Benefits of an Empirical Approach 28:46 Overcoming the Fear of Failure 33:18 Creating More Humane Workspaces 39:03 The Changing Nature of Work Contacting Jimi - Web: https://fearlessagility.com/ - X: https://x.com/FearlessAgility - Facebook: https://www.facebook.com/FearlessAgility/ - Instagram: https://www.instagram.com/realFearlessAgility/ - Courses on the Scrum Alliance site: https://tinyurl.com/yjc2rtmf Links from Dave's Intro - The Art of War for Collaboration Course http://modusinstitute.com/course/art-of-war-collaboration - Guided Personal Kanban (September 2024) http://modusinstitute.com/course/guided-pk-sep-usa The Agile Network* https://go.theagilenetwork.com/l/web-dprior Use the discount codes below to get either 20% or 2 months of free access 2 Free Months - DRUNKENPM10CM 20% off Annual - DRUNKENPM10C20 Contacting Dave Linktree: https://linktr.ee/mrsungo

Explore the hidden barriers to successful Scrum adoption as Brian Milner and Lucy O'Keefe dive into organizational dysfunctions and cultural impediments in this insightful episode of the Agile Mentors Podcast. Overview In this episode of the Agile Mentors Podcast, Brian Milner sits down with Lucy O’Keefe to unpack the organizational dysfunctions highlighted in their talk at the Scrum Gathering. They delve into how culture can significantly hinder Scrum adoption and discuss other common impediments like resistance to change, command and control leadership, and siloed teams. Emphasizing the importance of transparency, inspection, and adaptation, Brian and Lucy offer actionable insights to help organizations overcome these challenges. Listeners will also learn why leadership understanding and stakeholder participation are crucial for successful Agile adoption and the necessity of training in Agile values and principles for true organizational change. References and resources mentioned in the show: Lucy O’Keefe Dart Frog Consulting Path to CTC - Monthly Cohorts #109 Leadership and Culture in DevOps with Claire Clark Agile for Leaders Join the Agile Mentors Community Mountain Goat Software Certified Scrum and Agile Training Schedule Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Lucy O'Keefe has over 28 years of IT experience and has worn multiple hats in the Agile world - developer, Product Owner, Scrum Master, and now, Certified Scrum Trainer® (CST) where she uses her experience to ensure each student has a great training experience. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner, and we have a favorite back with us today. We have Ms. Lucy O 'Keefe with us. Welcome in Lucy. Lucy O'Keefe (00:12) Thank you so much, Brian. Happy to be here again. Brian (00:14) Very happy to have Lucy back with us. Lucy and I saw each other recently. Actually, I think it was the first time we saw each other in person, right? Yeah. We finally saw each other in person at the Scrum Gathering that took place recently in New Orleans. And I had the pleasure of getting to see Lucy's talk that she had there at the Scrum Gathering. And... Lucy O'Keefe (00:22) It was the first time, yep. Finally. Brian (00:41) She gave a talk with Joe Miller called, Scrum Unmasked, Unveiling the Dysfunctions Within Our Organizations. And I thought it would be a good opportunity to bring Lucy back and talk a little bit about this topic, because this is an important topic. And it was a packed room, it was full of people that wanted to know about this as well. So I thought it'd be a good chance for us to share this with the audience. But to start this, actually, before I even begin, I get ahead of myself. myself here a little bit. For those who maybe haven't heard Lucy on the podcast before, Lucy is a CST. She has a CTC. Her company is called Dart Frog Consulting. And she also has started recently this mentoring program with a new smally that is kind of a really interesting concept. It's a CTC mentoring cohort. So if that's something you're interested in, We'll put links into our show notes that you can get in contact with her about that. But if you're interested in pursuing certified team coach certification with the Scrum Alliance, that's a really great way to do that. You get a group of people around it and kind of go on that journey together. But let's talk about this topic. And I thought a good way to start was actually to be a little bit meta about this. I want to go behind the scenes a little bit. and think about where this topic came from, what's the genesis of where this came from and how you and Joe hooked up on this. So give us a little bit of the backstory of where this idea came from. Lucy O'Keefe (02:20) So to start, Joe and I have worked together. We worked at a consulting firm together. And funny enough, we actually were both speakers at a virtual conference a few years ago. He was on the panel and I was an actual speaker, but we never met. Back then we met actually when we started working in the same consulting firm. And of course I left the consulting firm a few years ago to go independent, but we just kept in touch and we always wanted to do something together. so when, when I was trying to figure out topics for the scrum gathering in New Orleans, I reached out to him and I asked if he would want to do a talk with me. A lot of times it's much easier to do it with somebody else. And I thought it would be fun because he and I see eye to eye on a lot of stuff. And I think we, we complement each other pretty well. But when we were talking about what topics we'd want to talk about, I kind of always go back to the things that I've experienced when I've been in organizations. And I think, I think a lot of us have experienced kind of something, something similar where people are going to say, scrum just doesn't work for us. Right. I actually, it was actually one of my first blogs that I wrote probably six, seven years ago was about that, about people saying, it just doesn't work for us. There, you know, it's not something that we can do. So I kind of got this idea that this is what we should be talking about. And I always go back to. Ken Trebers quote, and I said this during the talk, you may recall, you know, scrum is like your mother -in -law, it points out all your faults. So this idea that scrum is holding up this mirror, you know, to the organization is something that I always talk about. And I think it's important for scrum masters and others in organizations to understand that, no, it's not scrum that's the issue. It's that we have all this stuff that's not, going well in our organizations and we're just putting Scrum on top of it without fixing the issues, right? So we're trying to put a band -aid on what's going on in our organization instead of looking at the root cause. So I just thought that that would be a great topic to talk about. Brian (04:27) I love that. And I think that's a great way to look at it because you're right. It's not something that's going to fix everything, but it does make it very revealing. I remember the phrase I've always heard people use is it's not a silver bullet, it's a silver mirror. You know, like it's going to reflect back very honestly to you what's going on. Awesome. Well, that's that. Thank you for the backstory. I really appreciate that because I know a lot of people, you know, if you're listening to this, you may be considering, you know, do I want to submit and try to speak at a conference? So. Lucy O'Keefe (04:41) Yep. Brian (04:57) just to give a little background to where those kind of ideas come from. I thought that would be interesting little sideline there. So let's get into our topic. Let's talk about some of these dysfunctions because I know the main point of this was talking about organizational dysfunctions, kind of some common problem. So hit us up. Give us a few of these big organizational dysfunctions that you guys talked about. Lucy O'Keefe (05:22) So I think the main one and one that's probably going to resonate with a lot of people is culture. For me, culture is always the biggest issue. People are the biggest issue, right? You know, as you know, you probably remember this, right? In the previous Scrum guide, it would say, Scrum is simple to understand, but difficult to master, right? Or difficult to implement because it involves people. So culture is the biggest issue and culture encompasses... quite a few things, right? It could be resistance to change within an organization. It could be a lack of empowerment. It could be command and control, which I'm sure you've seen in plenty of organizations. I've seen plenty of organizations, even though we know that we are hiring the best people, a lot of leaders or managers actually I'll call them, you know, still want to be in control, still want to be the people telling people what to do. And it's very hard to go to... to a way of working where it's like, okay, I need to remove myself from the equation and trust that these people are gonna do what they should be doing. So I think culture encompasses a lot of the other things that we talk about when we're talking about organizational impediments. Another thing is organizational structure. Are we highly hierarchical? Are we a matrixed organization? Do we still have these silo teams, right? That work on just specific skills? And I'm sure you've seen this. I'm sure you've worked in waterfall just like I have in the past, right? You have your business analysts on one side. You have your designers on another side and then your developers and then your testers, right? And they're all reporting into a business analyst or tester or developer or anything like that. So there is no cohesive team that has one. focus or one objective. You know, we're matric, you know, getting these people out of that matrix and putting them into a team. But they're all just interested in their own thing, right? It's a very siloed way of working. So it's very hard to make that transition into, okay, we are a product team and we work together. And we have to be dedicated and stable. Because we're not used to seeing that in a lot of organizations, people are not dedicated to teams. And we're talking about waterfall. I have barely seen any of that. I used to have a team where, and there was already a scrum team, but we had three BAs on the team and they were each 33%. And that's something that is very normal. And even when I'm teaching my classes and I'm sure you have the same questions or comments, a lot of people are like, well, this is very hard for us because we have John Doe here who, you know, he's in five different teams. How is he going to go to all these events? So that's definitely another organizational impediment, which for me kind of goes back to culture as well. Right? So those things are big things. Leadership not understanding. Yeah, sorry. Yeah, no, go ahead. Brian (08:10) Yes. Yeah. I was thinking, I was thinking, sorry, I didn't mean to interrupt you, but I was just, I was thinking the same thing that when you said that, that just, yeah, it is very, the hierarchy of the organization is very cultural. And if you, you know, if we're, we're trying to empower teams and instill in them this idea that, Hey, you need to, in order to move fast, you've got to have autonomy and you've got to have the ability to go and make decisions. that's, that's very. much ingrained in how we structure our organization. If I have to get approval for everything I do, that's going to run counter to what we're trying to do in a Scrum environment. So I love that you made that connection. I absolutely agree with you. It's a very cultural thing. Lucy O'Keefe (08:59) It is, it is. Yeah. And as I said before, I think a lot of the impediments we see go back to culture, leadership, understanding leadership participation, a lot of organizations when they're thinking about agile, they're thinking about scrum. It's like, okay, the teams need to do that. All right. Let's, let's start in IT and our IT teams are going to start doing scrum and who cares about the rest of the organization. We're going to keep thinking the way that, that we've always been thinking. We're going to keep budgeting the way we've always budgeted. And then we have. We have a lot more resistance, a lot more conflict because we have a team that's trying to work in a certain way. And then you have stakeholders and leadership that are expecting things to be the way that they always were. So stakeholder participation, for example, you know, a lot of stakeholders are going to be like, well, I already told you what I want. Why are you coming to me every two weeks or, you know, however long our sprints are, you know, for to get feedback. You know what I want. I shouldn't have to talk to you about it. Right. So there's that lack of understanding of what's in it for them. So back to culture again, right, understanding that this is a whole cultural shift. It's not just a team shift. So leadership needs to understand that. And of course, as you know, you know, we have, you know, certified agile leadership programs that I'm trying not trying to do a plug here for those classes. I don't even teach them. But. Brian (10:03) Yeah. Ha ha ha. Lucy O'Keefe (10:22) it's so important that leadership understands what it means to be an agile organization and what it means to lead in an agile organization. And I think when they do that, when they're able to get that understanding, it's going to make it a lot easier for everybody to succeed. So once again, that is another big impediment that I've seen is the lack of leadership and stakeholder understanding. Brian (10:46) Yeah, absolutely agree. I mean, it's almost like the concept seems to be more, like you said, we'll start from the team and build up when really it should be more of a from a top down or even not even kind of whole, right. Right, it's kind of, it's a whole organization thing. And if we try to compartmentalize it and say, no, we're just gonna do this group. Lucy O'Keefe (10:57) up and down. Or even from both extremes and meet in the middle. Right? Yeah. Brian (11:13) then we're already kind of setting ourselves up to fail a little bit because I can't change the culture of just one segment of my organization. If I do that and they have a different culture than the rest of the organization, then we have cultures at odds with each other and they're set to fail. The more dominant one's gonna overtake the lesser one, which is usually gonna be the scrum side of things. So yeah, I completely agree. Yeah, yeah, frustration. Lucy O'Keefe (11:37) Exactly. Yeah. And it causes a lot of frustration. Yeah. It causes a lot of frustration for the team. Right. So I was actually at a, I was contracting at an agricultural manufacturing company. I may have brought this up before, but like the, the stakeholders didn't understand why they had to come to sprint and review, why, why they had to talk to the product owner instead of just talking to the engineers themselves. And it wasn't until I had. the lunch and learn with the stakeholders and help them understand what's in it for them because that's what's so important. How am I going to, how is it going to improve things for me if I abide by what you're trying to do? It wasn't until we did that, that they were like, I understand now why I need to talk to the product owner. I understand now why I shouldn't be dealing with the developers or the engineers themselves. I understand now why my feedback's needed. Yeah, it's great that now I have a say in the process. I have a say in the outcome. So it's not like people are trying to just be difficult. They just don't know any better, which brings us to one of the other organizational impediments, which is lack of training and understanding. Cause we can't just train the team. We have to, yeah, I mean, we don't have to train everyone in, you know, a CSM or anything like that. That's, that's not it. Right. But they need to understand the basics of how, how agile works. What are the values? What are the principles? What, what are the benefits of working in this manner? Right. It's, it's not about doing the thing, but it's how is this going to impact who is and how, how are things going to be better after you start working this way? Brian (12:52) Yeah. I've had a lot of conversations about this in the CSM class of just talking to different people and saying, you look at these agile manifesto values and principles and if we can't get an alignment on these things, right? If we can't look at these things and say, yeah, I agree. My philosophy is one of that's responding to change over following a plan. I believe that you should be more. able to respond to change, then you should be about following a plan. That's a fundamental kind of core value. And if my organization or if leaders in my organization, that's kind of the key here, right? If the leaders in the organization think, no, no, no, it's about following the plan. We have to establish this amazing plan and then follow the plan. Well, it doesn't really matter what we do at the team level because... somewhere up the chain of command, we're going to have to have that perfect plan that we try to execute on and the leadership is driving that. So we have a mismatch on just our core kind of understanding. Lucy O'Keefe (14:26) Exactly, exactly. So when I go into a new organization, one of the first things I do during my assessment phase, I actually go through every single one of the values and principles with leadership and with the teams. And I ask, which one of these are you doing well? And then we talk about that it's the minority usually. And then it's like, okay, what do we need to do to ensure that we are responding to change or following a plan or that we are... you know, focusing on working software instead of measuring something different. So we go through every single one of those because, as you said, that's where the value is. Understanding those values and principles, it's not about doing scrum, kanban, whatever it is. But if we are following those values and principles, then that's when we're truly going to be algebra and that's when we're going to see the benefits of working in this manner. It's not about the practice, but it's about your beliefs as an organization. Brian (15:24) Yeah, yeah, there's no practice that we're gonna put in place that's gonna solve it all, right? I mean, there's practices that can assist and help us, but the practice isn't the cure, right? The practice is just something that can assist. It's like having crutches, you know? The crutches aren't gonna heal you. Lucy O'Keefe (15:30) Not at all. A way to get there. Yeah. Exactly. Right. Yeah, yeah, yeah. The practice just a vehicle, but you have to do the work to get there for sure. Brian (15:51) Yeah, that's a great point. Lucy O'Keefe (15:53) Yeah, so I think those were the main ones that we talked about there. You know, of course, we only had an hour, so it wasn't, there wasn't a lot of time to talk about every single one. But I think that, you know, and you were there, of course, but a lot of people came up with their own impediments that they were seeing in their organizations. And I think a lot of them aligned to what we had to say as well, because I think it is pretty standard in organizations that are just starting out. Brian (16:02) Sure. Yeah. Lucy O'Keefe (16:22) that you are seeing a lot. I mean, not just starting out actually. I mean, I've seen an organization that they say they've been agile for years and they still have a lot of these issues. So it's pretty clear that the culture again is the biggest issue with being able to adopt Scrum correctly or adopt an agile way of working correctly. Brian (16:43) Yeah, and I think you hit the nail on the head with the fact that it's just, there's not the time always spent to try to get to the root cause. We're a culture of quick fixes. We want to find something that's going to put in place and take this pill, do whatever, and then it's just going to be solved and everything's going to be fine. But you know, it... For instance, we've used this analogy quite often, the idea of weight loss. There are things that can assist you with that. There are things that can give you help along the way, but there's not a silver bullet to do that other than changing the way that your lifestyle is. You have to change. And please, anyone who's listening, don't think I'm saying this because I have this perfect, because I don't. I'm very bad at this. But I know that the way that I change You know, my overall health is by changing the lifestyle, changing what I eat, changing, you know, my exercise patterns. And that's hard work. It's hard to change that kind of core value in my life, but that's what actually makes the impact. The other things are dressing around it. Right. Lucy O'Keefe (17:58) Yeah, that's what's gonna make you change. Exactly. I mean, think about people who go for, and just staying with the same topic, right? For some bariatric surgery, right? So a lot of times, like the doctor will say, I used to watch my 600 pound life, don't judge me, a little bit, just because it's kind of, it's interesting. And yeah, I mean, they'd have to lose weight before they had the surgery. Brian (18:06) Yeah, yeah. Hahaha. Lucy O'Keefe (18:25) And the majority of people after they had the surgery and kind of lost weight, they just went back and balloon back up because they didn't change their lifestyle. So as you said, yeah, it's great that these band -aids exist, but if you're not going to do the work yourself, then it's really not going to work. So what is the root cause in this case, right? We're eating badly and we're not exercising. So that's what we need to change and not just, you know, take a pill or do a fad diet or get a surgery that... It's not gonna work if we don't change our ways. Brian (18:55) Right, and just for the listeners too, I mean, Lucy and I are not medical professionals in any way. So, you know, we do not mean in any way to try to belittle, you know, treatments and therapies that people use for legitimate purposes and all that stuff. Please understand, right? Gotta make that disclaimer. But I think you're right. You know, like I know in my life, there's been times when I thought, there's some diet supplement or there's something else that, you know, is gonna... Lucy O'Keefe (19:01) No. No, no, no. Brian (19:25) be the thing that really cures this and changes it. But what I've experienced time after time is, no, you really just got to do the hard work. You got to go to the gym and you got to get up and you got to change what you eat and that kind of stuff. And that's what really makes the impact. Well, the same thing here with our organizations. There are practices and the things we can put in place. And there's always hot ones that will be the hot one of the day. I remember when DevOps was kind of the... And we just talked about DevOps in our last episode. It is an important thing. It is a very important thing, and it can give you a lot of boost. But it's a set of practices. And our last guest, when we talked about this, talked about how it's really more of a mindset. It really is more about how we have to change the way we see things. So even there, when we approach things like DevOps, yes, there are practices, there are tools we can put in place. But if we don't change kind of our approach to how we do things, then it won't matter. It's just another thing that we have to learn and put into the workflow. Lucy O'Keefe (20:32) Yeah, yeah, exactly. I mean, you know, the definition of insanity, right? Doing the same thing over and over and over again and getting the same results because that's what happens if you just keep putting band -aids on things, you're going to end up, you know, encountering the same issues over and over again. So if we don't have that mindset that we are going to make the change and the foundational change to ensure that everything works out, then, you know, then it's we're going to keep having the same issues and we're going to keep hearing this crime just doesn't work for us. Right. Brian (20:37) Ha ha ha. Lucy O'Keefe (21:02) So, yeah. Brian (21:04) There's something that also comes up in classes sometimes that I think one of the things that I found is that getting back to that transparency inspection adaptation, that if we as an organization really value that process and value the idea that, hey, we're going to be transparent about how we do things. We're going to not just ignore when there's a problem, but we're going to inspect it and get to the root cause. And then we're going to find a new way of doing things. that we can just latch onto that. That's a huge cultural change, right? And just kind of buying into those concepts. And what I found is in a lot of instances, I talked about this in the ACSM, a lot of instances, you can directly relate it back to a lack of one of those three things. Are we not being transparent? Are we not actually inspecting? Are we not actually adapting? Lucy O'Keefe (21:57) Yeah, yeah, yeah, those three pillars are definitely important. And I think that they're the foundation of what we are trying to do. And you're right, if we're not being transparent, inspecting and adapting, then we're not being agile, first of all, but that's something that needs to exist throughout the organization, not just within our work, within our teams, but are we being transparent in our relationships? Are we inspecting and adapting how we are dealing with our employees? Are we inspecting and adapting how we are budgeting? I mean, everything, right? We need to be... using that empiricism on a daily basis to ensure that we are headed in that direction. And if we do that, as you just said, the culture will shift organically when we're employing those three pillars, for sure. Brian (22:42) Yeah, absolutely agree. Well, let's, I want to meta this a little bit more here at the end, because I want to know kind of how it, how the fallout from this happened. So, so you, you have this idea, you work with Joe, you, you come up with this topic, you go, you present this. What kind of a follow -up did you get from this? Did you get a lot of good questions from people afterwards? How did the talk go? What did you, what, what, what kind of learnings did you take away from it after you gave the talk? Lucy O'Keefe (22:47) Yep. So I think it was received very well. There were quite a few people that came up to us afterwards and started asking questions to the point that I was actually late to a meeting after that. But anyway, I've had quite a few people reach out to me on LinkedIn, you know, talking about, we really loved your topic. And I actually, I got my reviews from it. And I think a lot of people appreciated that we had action items at the end. Brian (23:22) Hahaha. Lucy O'Keefe (23:38) So for those of you who are listening, we actually had an action plan where people could create an action plan on how they are going to start dealing with the organizational impediments in their organization. So a few people appreciated that. So it was pretty good, you know, pretty good feedback, I think, that we got from that. I would have loved for it to have been a little longer, so we could have gone a little deeper because it is, there is a lot that we can unpack. when we're talking about organizational impediments, one hour just isn't enough time for that, especially when you're trying to make it a more engaging session and not just talking at people. But I think if I had to do this again, I would probably try to do a little less and maybe go a little deeper instead of trying to talk about maybe so many things and barely touching the surface. But I think it was... Brian (24:28) Yeah. Lucy O'Keefe (24:36) I think it was pretty good. I know you're there, so you let me know. Brian (24:38) It was great. Yeah, no, it was great. And so, yeah, I hope you're encouraged by that. But yeah, it was a great talk. And like I said, I heard a lot of good comments from people afterwards. And I think that's pretty natural for us as speakers to kind of rethink afterward and say, maybe I could have done this a little bit different or I could have done this a different way. But, you know, it's tough. Like you said, you've got an hour. And within that hour, you're trying to work in some... interactivity, so it's not just you talking the whole time and you're trying to keep the group engaged. But then you get a lot of information and you just, I got to share all this stuff and I only have an hour to do it. Especially, as CSTs, we're used to talking for two days at a time. So, yeah, an hour is like, you know. Lucy O'Keefe (25:26) Exactly. So an hour is nothing. Yeah. Yeah. Brian (25:32) the break or something, but yeah, you're not used to trying to fit all that information down into a one hour stretch. Lucy O'Keefe (25:40) Yeah, and for me it's like I love answering questions. Like if I could do a talk and then do an hour of just answering questions, I think I'd be like really, really happy because I mean, even when I've, you know, taught with Mountain Goat and all that, you know, being able to answer questions at the end of class, that's like my favorite and I do that in my classes as well. So not being able to give time to actually answer, you know, Brian (25:47) Yeah. Lucy O'Keefe (26:04) questions from the people who are having the issues for me was very difficult not being able to do that because that's something that I enjoy. And, you know, but at the end of the day, I do love speaking. You know, I just, it's one of my passions now, which is kind of funny because I used to be really introverted. But yeah, I think, I know it was a really good experience. It was my first time speaking at the Scrum Gallery. I've spoken at smaller conferences before, but that was my first big one. So it was, it was great. Brian (26:19) Ha ha. Awesome. Lucy O'Keefe (26:34) I hope I'm able to do it again. Brian (26:36) Awesome. Well, it was great. It was a great talk. And I appreciate you coming on and sharing this information with us, because not everyone can come to the Scrum Gathering. And that's one of the reasons why we try to have some people come on that do speak at it, so we can share some of that information in these small little podcast windows. So. Well, Lucy, thank you again for coming on. I appreciate you sharing your talk with us and kind of the behind the scenes of it. And hopefully we can have you on again soon. Lucy O'Keefe (27:11) Thank you, Brian.

In this episode host Renae Craven chats all things Professional Development with guest Theresa Given, exploring different ways to assess growth opportunities and then how to plan for those opportunities. About the Featured Guest Theresa Given discovered Scrum and Agile ten years ago. She has been exploring and experimenting since. Theresa enjoys the world of possibilities; she's tried each Scrum accountability, tested multiple Agile practices, worked in varied industries across public, private and non-profit sectors. Currently, she coaches new Scrum Masters to explore their role and achieve greater efficacy with their teams. Follow Theresa on LinkedIn (https://www.linkedin.com/in/theresagiven/) Reference(s) The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org  Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg  Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile.   About our Hosts Renae Craven has been coaching individuals, teams and organizations for over 14 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel Crave Pilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn (https://www.linkedin.com/in/renaecraven/).  About our Sponsor Scrum.org is the Home of Scrum, founded in 2009 by Scrum co-creator Ken Schwaber focused on helping people and teams solve complex problems by improving how they work through higher levels of professionalism. Scrum.org provides free online resources, consistent experiential live training, ongoing learning paths, and certification for people with all levels of Scrum knowledge. You can learn more about the organization by visiting www.scrum.org.

In this episode Renae and Sally talk about the inspiration behind her #stopbadagile bird aviary and how they reflect what Sally has learnt along the way.   About the Featured Guest Sally Sloley is an agile coach who specializes in visual solutions. She started her career as a web developer at Microsoft HQ. She loves being part of the agile community, helps organize conferences, and speaks about lean and agile around the world. She started #stopbadagile on LinkedIn in 2023 to help shine a light on the things being sold as agile but aren't.   Follow Sally on LinkedIn (https://www.linkedin.com/in/sallysloley/) https://sallysloley.com/   The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared.   Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org    Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg    Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile.   About our Host Renae Craven has been coaching individuals, teams and organizations for over 14 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel Crave Pilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn (https://www.linkedin.com/in/renaecraven/).    About our Sponsor Scrum.org is the Home of Scrum, founded in 2009 by Scrum co-creator Ken Schwaber focused on helping people and teams solve complex problems by improving how they work through higher levels of professionalism. Scrum.org provides free online resources, consistent experiential live training, ongoing learning paths, and certification for people with all levels of Scrum knowledge. You can learn more about the organization by visiting www.scrum.org.

Join Brian and John Barratt as they delve into the current state of the agile industry, exploring the impact of economic downturns on agile coaches and Scrum Masters, and discover innovative strategies to navigate these challenging times. Overview In this episode, Brian and John Barratt dissect the current state of the agile industry, focusing on the effects of economic downturns on agile coaches and scrum masters. They discuss the reasons behind organizational layoffs and cost-cutting measures, emphasizing the need for innovation to thrive during challenging periods. The conversation shifts to redefining the roles of scrum masters and agile coaches, highlighting the importance of delivering value and outcomes rather than merely facilitating meetings. John introduces two essential resources—the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics—to support agile practitioners in their professional development. The episode concludes with a discussion on the significance of mentorship and continuous improvement within the agile community. Tune in for invaluable insights and practical tools to enhance your agile journey. Listen Now to Discover: [1:08] - Brian welcomes Certified Scrum Trainer®, Certified Team Coach®, & Certified Enterprise Coach®, and host of the Clean At Work podcast, John Barratt. [4:42] - John reveals the core issues behind struggling organizations and shares how innovation can allow an organization to thrive during challenging times. [5:50] - Brian and John analyze the impact of economic downturns on organizations and agility, offering strategies to navigate these challenging times successfully. [10:04] - Brian and John explore the role of Scrum and Agile in an economic downturn. [16:08] - Join Brian and the Mountain Goat Software team for not only a Certified ScrumMaster® class but a full year of membership, learning, and support from Mike Cohn, Brian, and the Agile Mentors Community. You don’t have to lead alone. [17:09] - Brian poses an opportunity to expand the definition of done of Scrum leadership. [19:43] - John introduces the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics as powerful resources to help Agile practitioners and leaders enhance their skills and progress in their development. [23:42] - John shares the tool of Agile Scoping, based on From Contempt to Curiosity by Caitlin Walker, to lean into Scrum success within an organization. [32:25] - Brian shares a big thank you to John for joining him on the show. [33:04] - We invite you to share this episode with a friend and subscribe to the Agile Mentors Podcast. [33:57] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. [34:16] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here. References and resources mentioned in the show: John Barratt Clean At Work podcast Scrum Events Meetup #93: The Rise of Human Skills and Agile Acumen with Evan Leyburn The Agile Army - John Barratt Agile Coaching Growth Wheel Agile Coaching Code of Ethics Agile Scoping From Contempt to Curiosity by Caitlin Walker Agile 2024 - The European Experience - Manchester Agile Coach Camp UK Certified ScrumMaster® Training and Scrum Certification Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Mountain Goat Software Certified Scrum and Agile Training Schedule Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. John Barratt is a Certified Enterprise Coach® (CEC) and Certified Scrum Trainer® (CST), passionate about helping individuals, teams, and organizations achieve their best through agile coaching approaches. With a background in the military and a keen interest in systemic modeling, John constantly seeks new ideas and innovations to support organizational resilience and agility. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We are here for another episode of the Agile Mentors podcast. I am with you as always, Brian Milner, and with me today, I have a good friend of mine that I've been trying to get on the show for a while. Mr. John Barrett is with us. Welcome in, John. John Barratt (00:14) Thank you for having me Brian. It's been a while. We've been trying. We're here today. I'm really pleased. Brian (00:18) Yeah, very, very excited. John and I have seen each other at conferences for years. We've crossed paths. And I kind of jokingly said to him, I'm threatening to have a conversation with you not at a conference at some point. And that was kind of how we started this. For those who aren't familiar with John and his work, John works with a company called Agile Affinity. John Barratt (00:34) Hahaha! Brian (00:43) He is a certified Scrum trainer, a certified team coach, and certified enterprise coach. So he has the holy trifecta of Scrum Alliance certifications there from the guide community. He's a coach and trainer. Couple of interesting things. First of all, we'll talk a little bit about this, but John has his own podcast called the Clean at Work podcast that we can talk about here a little bit. But another interesting thing that he told me before, I didn't realize this, but John actually started in the military. So do you want to say anything about that? How long were you in the military? John Barratt (01:19) Yeah, so I was in the military for six years, joined accidentally when I was 18. So I went into the career office with a friend who was joining. And they were like, you're a bright lad, you can earn all of this money. So it was either go to university and getting lots of debt or join the army, get lots of training and get paid and see the world. So no thoughts of joining before that day accidentally joined. Did six years including a tour of Iraq. And the important thing about that for me is when I left, I felt really isolated. So Army is all about team, right? Team focus. Left the Army, was in IT, and it felt totally different. People were there stabbing me in the back, not supporting me. And then I found this thing called Agile, which was about teams again. And this thing called Scrum, where it was a team game. I was like, this is what I've been missing. Where's this been for the last two years since I left the army? And the rest is history. I did do a keynote at Central Agile Spain. I'm not sure what year, but it is on YouTube for anyone who's interested in hearing more about how the army is actually rather agile in my humble opinion. Brian (02:22) Yeah. That's awesome. We'll find that and put that in the show notes here. So if people are interested in finding that, they can go and watch that. John Barratt (02:45) Yeah, we'll have to dust it out of the archives. Brian (02:48) Well, yeah, yeah, I'm sure we can find it. But we were talking before this about our topic and I think this is going to be a topic that's interesting to a lot of people. Really, really kind of diving into the state of the industry right now and what we're seeing as far as the economy in the agile industry. You know, there's there's several organizations that have laid people off You know, there's there's less demand at the moment in the coaching kind of realm So kind of what's behind that the the shifts and you know What might be driving this kind of thing? So I know John you got some opinions on this. So let us have it John Barratt (03:18) Mm -hmm. Yeah, so I don't want to talk too much about the global economics. I don't pretend to be an expert on why we're seeing a recession. We can talk about, you know, COVID and the cost of that and also the war in Ukraine and, you know, all of the pain and suffering that that's caused much more than, you know, what we're seeing, which is, you know, a few people being laid off. So I don't want to go into that. But what I do want to really explore is, so if an organization is struggling, there's two elements. for that. Do they try and cut back as much cost as possible or do they try and innovate themselves out of that recession? Do they try and do something different and in a unique way? Unfortunately what I'm seeing a lot of is the first one which is cut back, reduce cost as much as possible and that's to the detriment of the the Scrim masses and and agile coaches that we see and I'm going to talk a little bit why they are the ones that often are in danger in a minute. Instead of where they should go, which my bias opinion should go, right? What I'm trying to do in the company that I run is to actually lean into that as an opportunity and try and innovate and see, well, what is possible in this new, exciting world that we're perhaps moving into? Where do we need to go when organizations are struggling? What are the opportunities, an example, AI that we've seen and what difference will that make in the next few years? I mean, who knows? Brian (05:14) Yeah, yeah, I think it's fascinating and you know, there's something I've talked about with some friends for several years and that is that I think there's sort of a, boy, I don't know how deep we want to go on this, but you know, you have a lot of executives now that get hired to come into a company and it's gamesmanship because the idea is I've got to increase our... our stock price by however many percentage points. And my bonus is tied to that. The more I can increase it, the more I get a bonus. Well, it's kind of like if you go to a team and tell them, hey, can you do more story points? They can certainly game that and all of a sudden have more story points. Well, the same thing with a short -term kind of executive. If you're in an organization and you're only going to be there for a couple of years, And you know your site is, if I can raise it three percentage points, I get a bonus. Well, there's a lot of easy cuts I can make that all of a sudden I've gone up three percentage points. But the long term of that company has not benefited. It's only the short term. And it just feels like, I don't know if it's a day trader thing, if that's really why this is kind of becoming more prevalent or not. But it seems like investing is kind of more of the short term. Now, and it used to be when you buy a stock, you'd buy it for 10, 20 years because you believed in that company and you expected to pay off over the long run. There's still a little of that, but it seems much more short -sighted. And I think that's trickled down to our, like I said, I don't know how deep we want to get on this. I think that's trickled down to our executives. And I think from the executive, that's trickled down to the employees. And that's really affected how... John Barratt (06:41) Mm -hmm. Brian (07:06) you know, when we've had layoffs and we've had downturns in the economy that just, hey, this is an easy way for us to show an increase in profits. John Barratt (07:15) Yeah, I think that's a really good point. It reminds me of Craig Lammon's laws, structure leads culture. And when we talk about structure, we don't ever just mean the hierarchy, we mean the bonus system, how people are rewarded and paid and all of those things. And so if you're rewarding shortism by giving these execs bonuses based on Brian (07:34) Yeah. John Barratt (07:41) profit for this year or as you said stock increase by 3 % then they will cut costs because what looks good for short term and for stocks is to have the minimum operational expense possible right if they can keep that as low as possible then that looks like a solid company because they're keeping controlling costs they talk about and and If they're working on margins and profits start to go down, which is what we're seeing as a trend at least UK, US, I can't say if it's completely global, but it seems like a large percent of the company and the organizations are going in that way, then what they do is to keep their margins so that they get their bonus is they start to reduce that, right? Because they need to keep that buffer. If they were to do what I'm suggesting, which is to lean into that and perhaps spend a little bit, spend some money to make some money, or at least keep it lying and try some innovative stuff, then that's high risk for them. Hmm. Brian (08:50) Yeah. Yeah, I've seen things before that have said that when there is economic downturns, that their evidence shows that the companies that invest more during the economic downturns actually end up increasing their positions to a much greater extent when the downturn starts to turn around because... John Barratt (09:02) Mm -hmm. Brian (09:14) they haven't just set idle or they haven't tried to reduce, they've tried to invest and now they're positioned to really take advantage of it once the economy starts flowing again. I'm not like you, I'm no economic expert, I'm no economist. So I don't know all the ins and outs of what's causing that. But it certainly has caused pain in our sector. And I think a lot of sectors, because I have I know lots of people who have gone through layoffs, not just in the tech industry recently. So I guess kind of the question that I ask about this as far as the agile community is concerned is, if we were delivering value, right? If it was undeniable that what we were doing was increasing profits, increasing value to our customers, I think that would make it a lot. harder for these kind of layoffs to happen. So I don't want to entirely say, hey, it's bad leadership, right? I think we have to take ownership a little bit. John Barratt (10:23) Yeah, and I'm going to say something I think is quite controversial here, which I actually blame servant leadership for this. So I know in the latest version of the Scrum Guide, we use the word true leadership, but I still like the word servant leadership. And I've actually changed my mindset and how I teach these things over the last few years because of this, because we've started to see this trend. Brian (10:28) Go for it. All right. John Barratt (10:51) And I've seen it in organizations where I've worked, I've left one year later, and then they've made all the agile coaches redundant. And I think it's down to how we use and perceive servant leadership. So historically, I was always, you know, Scrum Master or Agile Coach is the great person in the background. They let everyone else take the credit. They're there to help and support the team and to do all of that stuff, which is great, right? until someone with a balance sheet comes along and goes, what are all these scrum masters who aren't delivering any value, right? They're an overhead. They're seen as an overhead. Not delivering any value. No one can even tell me what value they've created. These developers over here, they're doing great. And the product owner is really maximizing the value of this product. But these scrum masters, they don't add any value. Because that's what we told them to do, right? We taught them to... Brian (11:29) Yeah. John Barratt (11:49) give everyone else the credit and serve everyone else and be in the background. So I think we've got a lot to blame, Brian, as trainers for, well, I don't know how you've taught it in the past, but I feel a little bit guilty. Don't worry, I've got the answer, but I just want to hear from you, what you, where you are with that one. Brian (12:04) No, no, no, no. Yeah. I'll tell you my opinion and you'll tell me if I'm correct or not. Yeah, no, I agree. I definitely think that's part of it. But maybe this will be a little controversial. I kind of spoke about this recently at the Scrum Gathering in my talk. In the trend that we've seen, John Barratt (12:15) Yeah! Brian (12:40) that I kind of talk about the diminishing of the perception of value of the Scrum Master. And I think that there's kind of multiple parts to that. I think part of it could be, hey, leadership doesn't really understand the value. But I think that there is a secondary part of that, that they're not seeing the value. And if they're not seeing the value, then I think that that's John Barratt (12:48) Mm -hmm. Mm -hmm. Brian (13:08) that rest on us. I think that we have to partly do a better job of helping them to understand it, but partly doing a better job of delivering it. And again, don't want to get too controversial here, but in our industry, in our training industry, You know, we've done lots of two day classes. We've done lots of things where we get people out the door and then they're in place and they're doing things. And the follow -up, you and I both know the follow -up is so important. You can't just take a two day class and then you're set for life. It's two days, but that's a kickoff and you got to continue that. and if I, if I take a two day class and I kind of slide backwards a little bit from that class and I get in and I'm a scrum master, there's, John Barratt (13:43) Mm -hmm. Yeah. Brian (14:01) Unfortunately, I think there's a lot of scrum masters out there who see their job as meeting scheduler. I'm here to schedule meetings, and that's the value I bring. Well, I can't blame a leader for letting that person go, because anybody can schedule meetings. It doesn't really take a lot of skill to do that. John Barratt (14:08) Mm -hmm. Yeah. Brian (14:26) The skills that we should be adding are those soft skills, the conflict resolution and understanding the personality types that make up our team. And essentially what I talked about in my talk was that first phrase of the Agile Manifesto, individuals and interactions over processes and tools. It's about individuals and interactions. We have to know the people that make up our team, not every team in the world, but our team. And we have to know. how they work best together. And I think people who do that, there's enormous value for that. So I would propose to you there's a shared blame, right? I think there's a blame there that we need to do a better job of showing the executives, but we also need to do a better job of actually providing value for the executives. John Barratt (14:58) Mm -hmm. Yeah. Yeah, yeah, I'm just, I was just, you know, I'm new to running CSMs and things like that. And one of the things I've brought in is a follow -up session. So, you know, a month after the training, they can have 30 minutes and we can talk about stuff. And that's really where you appreciate that the CSM isn't enough, right, to be a Scrum Master because you... There's only so much you can do, but the thing that always lacks, at least I haven't managed to perfect it yet, is those soft skills, right, which are the things that are important because you can't cover that in half an hour, an hour, right? All of those things are a full one, two, well, I'm being generous, just touching the sides with a one, two day course in some of those. And it's good to see the Scrim Alliance moving into some of those, you know, competency based or what they call skills based. courses where we can go a bit deeper into those key things. Because they're talking about, well, how can I do this? And in my head, it's obvious, but it's clearly not. So there's a huge gap between putting someone on a two -day course and thinking they can be a scrum master. And we do see a lot of bad scrum masters in the industry. And it certainly does cost everyone, even the good ones, some credibility. Right? Because... And if there's more ones, and it's not bad because they're bad people or trying to do a bad job, it's just that they haven't been equipped to do the job, right? Yeah, it's as simple as that. Brian (17:03) Yeah. At one of the tables I was at at the recent guide retreat at the Scrum gathering, we were having a discussion around this. And one of the things that kind of struck me as that was going on was, you know what it sounds like? It sounds like we don't have a stringent enough definition of done. Like when we think about someone who's you're now ready to be a Scrum master, well, that definition of done right now is a two day class. Right? And. John Barratt (17:22) Mm -hmm. Brian (17:32) I think we have to put in the expectation that, no, this is a component of that definition of done, but there's actually more that you need in order to, you know, this is an important role. This is somebody who is shepherding and guiding a team to be successful in this. So if someone's not qualified in doing that, it's no wonder that we see a bunch of bad scum out there because the person leading it isn't qualified, you know? John Barratt (17:38) Hmm. Yeah, and actually, I was just thinking an apprenticeship approach would be a much better idea, right, for this type of work. I often give the metaphor in my classes that agile coaching is a craft, Scrum Mastery is a craft. And imagine you're a carpenter, you don't get better at being a carpenter by reading lots of theory about good joints and all of this stuff. You know, you pick up a few things, you get better at Scrum Mastery or agile coaching. Brian (18:07) Yeah. John Barratt (18:29) by working and getting feedback. Our work is with the people, right? And people are a lot more complex than would, so we have to do even more of it to get any good. And of course, in carpentry, you wouldn't think about, we'll do a two -day training course. You would do an apprenticeship, right? And they do it for years before they become like a master carpenter. Yet we have scrimmasters after two days. Brian (18:58) Yeah. Yeah, no, I completely agree. And for the organization, I know when you've seen organizations that have sort of that layer, that hierarchy of we have Scrum Masters, but we have coaches, and we have enterprise coaches. When you have that kind of structure where you can have the phrase we use as mentor and be mentored. And if you can be in that place where you mentor others and you're also being mentored, John Barratt (19:21) Mm -hmm. Brian (19:28) That I think is really key to reaching the next level, to being able to kind of grow into what it is that you want to become in this industry. John Barratt (19:39) Yeah, I mean, I can't solve that problem very easily myself. You know, we've got a certified team coach and enterprise coach in the Scrim Alliance. It needs to be a bit more of a gap, I think, between that and CSPSM and we'll see what comes out in the next few years. But there is a couple of resources that I have worked on to try and help with this. So I've been on a mission to try and professionalize the world of agile coaching for at least five years. And the two things that I've found that have helped most people, is something called the Agile Coaching Growth Wheel, which you may have heard of. We'll put the link in the chat to that, which has kind of all of the competencies that we think you need in Agile Coaching, which is the set of competencies that a Scrum Master needs. So not Agile Coach, Agile Coaching, Scrum Master, Agile Coach, or any, you know, job title could be anything, right? It doesn't really matter. So that's a really useful tool. gives you all the areas, but it also gives you guidance, like a one to five guidance that almost uses the apprenticeship type thing. I can't remember all the levels, I think it uses like the Drift for scale, but it says at level one, you should be able to do these sorts of things. At level two, you should be able to do these sorts of things. And that gives people at least a starting point. You don't know what you don't know, right? Brian (20:58) Right. No, I think that's awesome. And we definitely will put that in our links and make sure that people can find that. Yeah, you're right. That kind of apprenticeship idea, I know that I could not have gotten to where I am without the mentors I've had. John Barratt (21:15) Mmm. Brian (21:18) And it's people who have, for no benefit of their own, have taken their own time to say, I'm going to invest time in this person and help them reach the next level. And I've tried to carry that forward as I've grown in this career as well, because I think it's important. I think we have to help the next group that's coming along. Yeah. John Barratt (21:44) Mm -hmm. I was thinking becoming a CST is almost like that apprenticeship type system, right? Where you have to do the co -trains with different people. They're like mentors, right? Different diversity, different types and groups. And you learn, both people learn from doing the co -train. And I think personally, it'd be a shame if they ever... Brian (21:54) Yeah. John Barratt (22:16) remove that concept because I think it's the closest we've got to an apprenticeship. Brian (22:21) Yeah. Yeah, and it works, right? I mean, I think that it does a good job of getting people to the level they need to be. There's still a lot, I mean, that doesn't do it all on its own, but it is, you know, I think anyone who's been through it, I think you would probably agree with this as well, is, you know, that was a foundational part of becoming a CST for me, is being able to observe and watch others and learn from them and... get feedback on how I was doing it. So I think you're right. That could be a very intriguing addition if there was someone who kind of incorporated that into the process. And I think that would give organizations kind of a confidence to say, I can trust this person. John Barratt (23:10) Which is what we really want with the CCCTCs, right? It's that stamp. I can trust that person. Second tool I wanted to highlight was the Agile Coaching Code of Ethics. So this was an initiative we did with the Agile Alliance. And the beauty of when we created this code of ethics, it was for people who were just starting out as well as experienced professionals. So you can read through that and that's kind of your rule sheet of Brian (23:25) Yeah. John Barratt (23:40) I'm new to this. This is the minimum standard we expect from a Scrum Master or an Agile coach in this industry. Because you don't know what you don't know again. But we've tried to make it as simple as possible. A simple list of these are the things you should definitely do if you want to be ethical in your work. Brian (24:00) Yeah. Yeah, that's a good resource as well. And we'll make sure we have that linked. Was there another resource as well that you wanted to mention, or is it just those two? John Barratt (24:12) So it's the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics. So we've talked a lot about the problem of where we're at, and we've given a couple of pointers. I wanted to talk a little bit about how I've changed my direction from this original kind of servant leadership type focus, which seems to be having some... Brian (24:36) Yeah. John Barratt (24:40) traction and benefit and value to people. And it's a couple of tools combined. So I created something a couple of years ago called Agile Scoping, which was based on Clean Scoping. So Clean Scoping is something that Caitlin Walker created based on Clean Language around how she scoped out a new piece of work. If you want to know more, then I highly recommend her book from Content Curiosity. Brian (24:44) Awesome. John Barratt (25:10) Bit biased, but one of the best books I've ever read. Not an agile book at all, but just a truly incredible story about how she's used clean language and something we call systemic modeling, which is using clean language in groups, with youths that have been kicked out of school, for example, and how they went from all individuals to suddenly kind of helping and supporting and understanding each other. Brian (25:31) Hmm, yeah. John Barratt (25:40) So great book. But anyway, Agile Scoping was based on that and it starts off with a discovery phase. We call that initial scoping, which is setting out kind of, is this work set up for success? So is the person in charge actually got enough influence over the system to actually make any change? So if you are doing Scrum. Do they have permission to actually change the structure into something that is actually going to help Scrum succeed? Have they tried different things before? And also this thing called congruency. So it's what they're saying aligned to what they're doing. So asking for those examples of, okay, you're saying that this, have you tried that before? Those sort of things. Very high level, just checking it out. And you can do that in an interview as well. So this isn't just for an external person. I always think that interviews should be two -way, right? It's not just a one -way thing. I want to check that if I'm signing up 40 hours a week or however many, that this is an organization that actually wants to be agile. I mean, I always put my hand out to the people on my training and people I meet at conferences where they're really struggling, right? And it's a really hard environment. And I always think, wow, you've got way more patience than I have. I really respect that. but my patients' levels are very low. So if I'm going to work with a client, I need to have a feeling that they can work at a pace, right? Brian (27:20) Yeah, right. Right. John Barratt (27:21) So that's level one and that's fine. Then we do an organizational scoping phase where you work with as many people as possible. You're looking at the problems that the organization says they've got, what the culture is now, where they want it to be, running some workshops, finding out what's happening. And again, we call it scoping because you can scope it to the level that you've been brought into. So if you're a Scrum Master working with one team and it's... One product owner, small product, that's fine. That's your scope if it's a whole organization, much wider. At the end of that, you create a coaching plan with the organization. So you have a session and you agree up to four outcomes is what I've found. So we move into outcome -based approach. So even if you skip all of the other stuff, what I would say is move away from any output thinking. As a scrum -rosterer, Brian (28:10) Yeah. John Barratt (28:18) even if it's just in your yearly appraisal, make it clear these are the outcomes that we're looking for. And these are more business related outcomes or things that are going to actually make a difference to the organization. So it could be things like make more money for the organization, could be increase employee engagement, increase customer engagement, number of active users in your mobile app, whatever those are. But they're nothing to really do with Agile, they're to do with... Brian (28:42) Yeah. John Barratt (28:47) that the organization wants to set. Those go into a coaching plan. We have a coaching agreement canvas that you can use to put all of that in. And then it's really clear, like these are the things that I'm going to help and support you with as a Scrim Master or Agile coach. There's a bit more risk, right? Because if you don't meet them, then you've got to have a conversation, but at least then it's visible, right? These are what I'm saying I'm going to help with. This is what you've said you want help with. And now we're going to do a number of experiments to try and get there. And that's where we get into that continuous improvement cycle of trying to involve, adapt, inspect, work on all of those things that are happening within your team, within your department, within your organization, depending on where your scope is, constantly evolving and looking at. where we're at. We might have some lead -in indicators as well, perhaps in there to help us cycle time, lead time, throughput. Those can be useful, but really we're looking at end value and we're measuring our performance of a Scrum Master Agile Coach based on the value being given. We're not letting the product owner take all of that praise and credit. Of course, we don't want to be too arrogant and go too far the other way. It's a team effort. but we're at least putting our, you know, more, I think skin in the game is the thing. What I've seen in the past is, you know, bit of a puppy dog type thing, Scrum Master, ooh, shiny over here, great, shiny over there, no, skin in the game, this is a partnership, and we're gonna work on this together. Sorry, I spoke for a long time, though. Brian (30:16) Yeah. Love that. No, no, no. I love that. You were saying great stuff. And I mean, I love the bit about outcome -based kind of approaches to it. I think that's really, really important. I've always thought, you know, like the performance, I'm always really hesitant about performance -based kind of metrics. And I always want to shift more to output outcome -based kind of metrics, not output. And I think that because that's, You're right. A business doesn't care how agile we are. A business cares if we're increasing our bottom line, if we're increasing our membership, all the business goals that you might have. That's what they care about. And agile -ism means to that. John Barratt (31:17) Yeah, I have a big shiver when teams have like agile maturity models. Like the word maturity, first of all, like if I say to you, Brian, you're immature, Brian. You know, that's just like, why would you do that? And also if I, you know, it's many people have said agile is never the goal, right? We're never trying to be agile for agile sake. We're doing it to help organizations and, you know. Brian (31:23) Ha ha ha. John Barratt (31:44) Therefore, why would you want to know how mature a team is when that's not actually that important, right? Could be a very leading indicator, perhaps, of where you're trying to get to, but it scares me when I see those sort of things. Brian (32:04) Yeah, this is great. This is great stuff. And there's so I mean, from what you've said, there's so many good links that we're going to be able to put in our show notes for this. We'll also, by the way, make sure that people can get in touch with you, John, if they want to follow up and learn more individually from you, because that's always really important here as well. And I know it's conference season. There's a lot of conferences going on. And you were telling me you're going to be at the Europe. John Barratt (32:12) Mm -hmm. Brian (32:33) Agile 24 conference, right? John Barratt (32:36) Yeah, so I've decided to do my part for the environment and not fly out to America for the third time this year. So I'm going to be in the Agile Alliance Manchester in July. I'm doing two sessions there. One looking at product refinement using clean language and the other one how to help and support self -managing teams with Caitlin herself. So if you like the idea of the stuff I was talking with Caitlin. and that's the session for you. Also going to be in Agile Prague this year, Agile Coach Camp UK, which I run, but unfortunately that is full. So there is a waiting list if you did want to try and sneak into that. And I'm sure I'll be at a few other places as well. There's also my monthly meetup that I run with a number of other colleagues called Scrum Event. It's actually the second largest Scrum Alliance user group in the world. Brian (33:33) Awesome. John Barratt (33:34) and we tend to have some pretty cool speakers there, so watch out for that. Brian (33:40) That's awesome. Yeah. We'll try to link to all of that so that people can find it. But yeah, if you're going to be at any of those conferences or if you're on the fence about going to the conference, you can hear great speakers like John there. So make sure that if you do, that you go up and say hello and tell them that you were listening to the podcast and heard this and were interested. And that's why you're there. Well, John, I appreciate your time. We're recording this on a Friday afternoon for you. And I know that's really precious time at the end of a week. So I really appreciate you giving us your time here and sharing your knowledge with us. John Barratt (34:19) Thank you for inviting me and having me. It's been a blast. Brian (34:24) Absolutely.

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

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

My buddy Dave Prior, CST (drunkenpm@gmail.com) visited, and we talked about his fun podcasts. Specifically we mentioned these two episodes of Agile and Project Management - DrunkenPM Radio: Human Hacking with Christopher Hadnagy and Dr. Abbie Marono The Art of War with Gary Gagliardi Dave is also a CST with the Scrum Alliance and active with Project Management Institute. Until recently, we had both been working for LeadingAgile. We also talked about Lithespeed's recent Global Agility + Innovation Summit. Dave was interviewing some luminaries for the event. We spoke briefly about Vic's Coach's Toolkit, A-CSM classes, and the renovations to his YouTube Coffeehouse studio.

In this episode Renae and Sarah talk about the art of asking a dumb question and how modelling that helps others to feel more confident to ask their own ‘dumb' questions. About the Featured Guest Having spent most of her career in Human Resources and Learning and Development, Sarah came across Agile as a philosophy and way of working, and LOVED IT! She jumped ship and moved into a customer experience team working in agile philosophy, and has now become a Scrum Master. Follow Sarah on LinkedIn  The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org  Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg  Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile.   About our Host Renae Craven has been coaching individuals, teams and organizations for over 14 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel Crave Pilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn.   About our Sponsor Scrum.org is the Home of Scrum, founded in 2009 by Scrum co-creator Ken Schwaber focused on helping people and teams solve complex problems by improving how they work through higher levels of professionalism. Scrum.org provides free online resources, consistent experiential live training, ongoing learning paths, and certification for people with all levels of Scrum knowledge. You can learn more about the organization by visiting www.scrum.org.

Business coach Anton Skornyakov has made a career out of helping organizations manage unpredictability. Passionate about Agile methodologies, Anton holds the esteemed Certified Scrum Trainer certification, a distinction shared by only 250 individuals globally, awarded by the Scrum Alliance®. Connect with Bert:  YouTube |  Twitter  |  Instagram Get a Free Copy of Dominating Your Mind: https://amzn.to/2XuM9Xr - While supplies last, limited time.  

Welcome to the PMO Strategies Podcast + Blog, where PMO leaders become IMPACT Drivers! PMI Talent Triangle: Power Skills Hey, IMPACT Driver!   Did you know that currently only 26.7% of tech jobs are filled by women? The majority of those are entry-level positions, which means an even smaller percentage of women are in leadership roles in the industry.    All too often, women find themselves struggling to balance personal and professional demands, lacking the necessary support to thrive in their careers. I know this all too well, spending many of my earlier years working in PMOs and building my company as a single mom!   Some would say that the odds are stacked against women in the workplace, but I'm not OK with that.    What can we do to fix this problem and give everyone the support they need to thrive in the workplace?    In this episode, IMPACT Summit speaker and a Certified Enterprise Agile Coach (CEC) with the Scrum Alliance, Apriel Biggs, and I will have an honest conversation about women in project leadership. She will share empowering insights from her career that will help you overcome any setbacks you may face in the professional world.    This podcast episode isn't only for women! It's for anyone who wants to create opportunities for their teams to thrive. In fact, you might be surprised by what I share regarding how I was treated in the workplace by men and women.    Check it out now.   Enjoy!   Connect with Apriel Biggs Find Apriel Biggs in LinkedIn P.S. International PMO Day is just around the corner. That's right, on Tuesday, May 14th, 2024, we'll be celebrating the vital role that Project Management Offices play in organizations across the globe. Reserve your seat today and learn more about how you can participate! Thanks for taking the time to check out the podcast! I welcome your feedback and insights!  I'd love to know what you think and if you love it, please leave a rating and review in your favorite podcast player. Please leave a comment below to share your thoughts. See you online! Warmly, Laura Barnard     GET NOTIFIED ABOUT NEW EPISODES  TELL US WHAT YOU WANT TO LEARN PDU REPORTING INSTRUCTIONS                                      

Thursday Night Interview Program with Duane Hill, Jr. We'll be discussing Duane's life as a scrum master, coach, and the proud creator of ScrumBuddies Coaching in Interview No. 17. Duane's goal is to help emerging scrum masters grab their next role. Duane Hill, Jr. Former educator turned Scrum Master turned Scrum Master Coach. My goal is to create space for agile in school systems across the United States to increase buy-in with students and retain teachers. Now a Scrum Master at Scrum Alliance. Until then he helps empower and equip new and aspiring scrum masters through ScrumBuddies. Driving the mentality that Your Experience Is Enough and that our past careers and interests make us amazing and effective Scrum Masters today!  https://www.linkedin.com/in/duanehilljrcsm/ The Thursday Night show will start at 8pm EST with the podcast version to follow up at 9pm EST.  Please stay tune for more interviews with agile people and change agents. Please reach out if you want to be on the show.  Happy Scrumming, Please don't forget to sign up for out weekly mailing list with its freebees. Social Media: - search 5amMesterScrum or #5amMesterScrum  and you should find us and if not please let us know LinkedIn, Youtube, Facebook, Instagram, Twitter, TikTok     Podcasts: (search 5amMesterScrum)

#5amMesterScrum Lightning Talk 1,177 Live - Communications Top Skill - use Sprint Review to develop that skill (3R Thursdays) - Today's topics: (1) Report on Skills in the New World of Work by Scrum Alliance and Business Agility Institute share that Communications is the highest sought after skill by employers. .  Please like and subscribe and share 5amMesterScrum.  Please send me your topics.   You are are doing Great Please Keep on Sharing. 5am Mester Scrum 5am Mester Scrum Lightning Talk 1,177 went live on Youtube, LinkedIn and Facebook 3R (Requirements, Reviews, Retros) Thursday 4/11/2024 from Philadelphia, PA  Happy Scrumming, Please Don't forget to sign up to our 5amMesterScrum newsletter for freebies.  Watch the video in our YouTube Library as well. Social Media: - search 5amMesterScrum or #5amMesterScrum  and you should find us and if not please let us know LinkedIn, Youtube, Facebook, Instagram, Twitter, TikTok     Podcasts: (search 5amMesterScrum) 

You've decided to take a Scrum certification class. Now the question is, which one? If you are looking for something like Certified Scrum Master or Certified Scrum Product Owner, there are so many options to choose from that it can be overwhelming. All of them should result in certification and price is certainly a concern. But there are a number of other factors to consider when trying to find the Scrum training that is right for you. When you take a certification class, whether its focus is on Scrum, Lean, Kanban, Project Management, whatever… you are investing in yourself and your future. In this podcast, Vic Bonacci and I talk through some of the key things you should consider when selecting a certification course. You are spending your time and money to obtain knowledge and validation (through certification) that you have a certain degree of expertise. Choose wisely… it's your future. Contacting Vic LinkedIn: https://www.linkedin.com/in/vbonacci/ AgileCoffee Podcast: https://agilecoffee.com Online Scrum Class: https://onlinescrumclass.com Contacting Dave Linktree: https://linktr.ee/mrsungo Dave's Classes listed on Scrum Alliance site: https://tinyurl.com/35pzsk5j

Thursday Night Interview Program with Anton Skornyakov discussing his journey from Coach to Entrepreneur to Author in Interview No. 16 and we talk about his new book "The Art of Slicing Work: How to Navigate Unpredictable Projects".  This is a part of our Thursday Night line up of interviews agile people, change agents and business people seeking Transformation. Anton Skornyakov was born in Moscow, Russia before relocating to Germany at the age of 12. Trained as a mathematician and physicist, Anton earned a degree equivalent to a master's in mathematics from Cambridge, a diploma in physics from Humboldt University Berlin, and an MBA from Collége des Ingènieurs in Paris. His professional trajectory reflects an entrepreneurial spirit, with roles as the Founder and Co-Founder of several startups. Passionate about Agile methodologies, Anton holds the esteemed Certified Scrum Trainer certification, a distinction shared by approximately 250 individuals globally, awarded by the Scrum Alliance®. Anton's dedication to organizational collaboration and Agile principles in the public and nonprofit sectors led him to his current role as co-founder and managing director of Agile.Coach. In this capacity, he has coached nearly a hundred organizations and thousands of individuals in the art of slicing work. His upcoming book, The Art of Slicing Work, encapsulates the culmination of numerous stories, lessons, and principles gathered throughout his coaching journey. https://www.linkedin.com/in/antonskornyakov/ https://slicingwork.com/ The Thursday Night show will start at 8pm EST with the podcast version to follow up at 9pm EST.  Please stay tune for more interviews with agile people and change agents. Please reach out if you want to be on the show.  Happy Scrumming, Please don't forget to sign up for out weekly mailing list with its freebees. Social Media: - search 5amMesterScrum or #5amMesterScrum  and you should find us and if not please let us know LinkedIn, Youtube, Facebook, Instagram, Twitter, TikTok     Podcasts: (search 5amMesterScrum)    Spotify, Pandora, Google Podcasts, PodBean, iTunes, Stitcher, iCatcher, Airr, PlayerFM, Breaker, Apple, Amazon, Alexa, iHeartRadio, Listen Notes, Firefox, Overcast, radio de, PodcastAddict, Bullhorn, iVoox, Podchaser

Summary Anton Skornyakov, the co-founder and managing director of Agile.Coach, discussed his role in coaching organizations and individuals on agile project management methodologies. He emphasized the importance of delivering small, useful pieces of a project to customers for feedback and the challenges encountered when implementing new ERP systems. Anton also shared his admiration for Russian political activist Alexei Navalny, calling him a hero due to his successful and agile campaigning. Lastly, Anton provided information about how one could contact him through his website, Slicingwork.com.   About Anton Passionate about Agile methodologies, Anton Skornyakov holds the esteemed Certified Scrum Trainer certification, a distinction shared by only 250 individuals globally, awarded by the Scrum Alliance®. Anton's dedication to organizational collaboration and Agile principles in the public and nonprofit sectors led him to his current role as co-founder and managing director of Agile.Coach. In this capacity, he has coached nearly a hundred organizations and thousands of individuals in the art of slicing work. Anton is also the author of the upcoming book The Art of Slicing Work: How to Navigate Unpredictable Projects, which is the subject of our conversation today. 

Keeping up with what is happening in AI is no small task. You probably know some folks who spend a lot of free time learning how to bend (insert AI flavor of the week) to their will, there are folks who are preaching to anyone who will listen about all the amazing things that are right around the corner, and then there are the folks who just periodically peek over their shoulder and say “Yeah, um… let me know when you've got this bit actually working.” And then there are people like Snehal Talati. I met Snehal last year at the Scrum Gathering and we did a podcast about http://aiagile.org, the community he started to bring Agilists together to ensure that the intersection between the Agile space and AI happens in an intentional and thoughtful way. It's been 8 months since that podcast was posted and that's like 20 years in the AI space. So Snehal is back to share what's been happening in AI and Agile. and to talk about the free course he built for the Scrum Alliance to help folks get started. During our conversation, Snehal gives an update on some of the newer changes and challenges in AI and he also offers real-life examples of how AI is becoming a powerful part of his personal productivity. If you'd like to check out the Scrum Alliance's AI course, that is here: • AI & Agility: A Comprehensive Introduction: https://resources.scrumalliance.org/Course/ai-agility-comprehensive-introduction AI Links to get you started: • AI Agile: https://www.aiagile.org/ • Agile GPT: https://www.agilegpt.com/ • ChatGPT: https://openai.com/blog/chatgpt CONTACTING SNEHAL • Web: https://www.boostaro.com • LinkedIn: https://www.linkedin.com/in/snehal-talati-124a38b6/

Scrum, you ask. Are we talking here about Rugby? Not at all. My guest on this episode is Rodrigo Quezada. Rod says he grew up with a pretty normal childhood until, during college, he was in a serious automobile accident that effected his ability to easily draw on childhood memories. I leave it to Rod to tell you about this. He went to college and graduated after which he entered the workforce. In 2015 Rod discovered a book entitled “Scrum, The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland. I will not attempt here to describe what “Scrum” is. Rod is much more articulate about it than I. What I will say is that the art of Scrum takes creating and enabling teamwork to a new level. Scrum is all about teams working as cohesive units. I personally can see why one can say that using the Scrum model well may be a cause for more efficiency. This episode is to me quite engaging and worth the hearing. I think you will learn more about teamwork and perhaps you will discover a way to enhance how you work on projects. About the Guest: My name is Rodrigo Quezada from Mexico and I currently work as Principal Project Management at AT&T. During high school had a near-death experience at a car accident that compressed most of my childhood memories. They are there and can be retrieved by external triggers yet not by myself. Overall have awareness that had a childhood and within normal parameters as far as I can remember. Started my career path at the century start in procurement and was having a good time yet by 2015 a pivotal event happened when I ran across a book by Jeff Sutherland called Scrum, The Art of Doing Twice the Work in Half the Time. As failing at implementing traveled to the USA for training by Scrum.org and a new career path emerged. Implemented in the most empiric and lean way possible which aligns with the pillar of the Scrum system. Began a new undergraduate as computer engineering which was followed by a masters in data science and now a Phd in progress along with several professional certifications and a lot of learning. At this point in time would like to share this out as find it very beneficial to both individuals and organizations as, per the Scrum guide definition, it aims at “adaptive solutions for complex problems”. Ways to connect with Rodrigo: Linkedin: www.linkedin.com/in/rodrigoquezadareyes About the Host: Michael Hingson is a New York Times best-selling author, international lecturer, and Chief Vision Officer for accessiBe. Michael, blind since birth, survived the 9/11 attacks with the help of his guide dog Roselle. This story is the subject of his best-selling book, Thunder Dog. Michael gives over 100 presentations around the world each year speaking to influential groups such as Exxon Mobile, AT&T, Federal Express, Scripps College, Rutgers University, Children's Hospital, and the American Red Cross just to name a few. He is Ambassador for the National Braille Literacy Campaign for the National Federation of the Blind and also serves as Ambassador for the American Humane Association's 2012 Hero Dog Awards. https://michaelhingson.com https://www.facebook.com/michael.hingson.author.speaker/ https://twitter.com/mhingson https://www.youtube.com/user/mhingson https://www.linkedin.com/in/michaelhingson/ accessiBe Links https://accessibe.com/ https://www.youtube.com/c/accessiBe https://www.linkedin.com/company/accessibe/mycompany/ https://www.facebook.com/accessibe/ Thanks for listening! Thanks so much for listening to our podcast! If you enjoyed this episode and think that others could benefit from listening, please share it using the social media buttons on this page. Do you have some feedback or questions about this episode? Leave a comment in the section below! Subscribe to the podcast If you would like to get automatic updates of new podcast episodes, you can subscribe to the podcast on Apple Podcasts or Stitcher. You can also subscribe in your favorite podcast app. Leave us an Apple Podcasts review Ratings and reviews from our listeners are extremely valuable to us and greatly appreciated. They help our podcast rank higher on Apple Podcasts, which exposes our show to more awesome listeners like you. If you have a minute, please leave an honest review on Apple Podcasts. Transcription Notes Michael Hingson ** 00:00 Access Cast and accessiBe Initiative presents Unstoppable Mindset. The podcast where inclusion, diversity and the unexpected meet. Hi, I'm Michael Hingson, Chief Vision Officer for accessiBe and the author of the number one New York Times bestselling book, Thunder dog, the story of a blind man, his guide dog and the triumph of trust. Thanks for joining me on my podcast as we explore our own blinding fears of inclusion unacceptance and our resistance to change. We will discover the idea that no matter the situation, or the people we encounter, our own fears, and prejudices often are our strongest barriers to moving forward. The unstoppable mindset podcast is sponsored by accessiBe, that's a c c e s s i capital B e. Visit www.accessibe.com to learn how you can make your website accessible for persons with disabilities. And to help make the internet fully inclusive by the year 2025. Glad you dropped by we're happy to meet you and to have you here with us.   Michael Hingson ** 01:21 Welcome to another episode of unstoppable mindset. Thanks for being here. And for listening. We really appreciate it. Today, we get to introduce and interview Rodrigo Quezada. But we're gonna call him Rod and he said, That's okay. He asked me if I preferred Mike or Michael. And I said absolutely. So he's going to call me Mike. And I'm going to call him Rod. And I guess that works out pretty well. Rod has an interesting story to tell both about life in in his childhood and what he's doing now. And he's going to talk to us a lot about Scrum. And I'm not talking about rugby, necessarily. But we'll get to that. Anyway. Rod, I want to welcome you to and thank you for joining us here on unstoppable mindset.   Rodrigo Quezada ** 02:05 Thank you so much for inviting me, Mike. I'm very excited to be here, I think this opportunity to be able to share this out with with the team at large. I'm super excited about it. So then again, thank you. Well, absolutely.   Michael Hingson ** 02:19 And you're You're most welcome. And we're really glad that you're here. Rod, by the way, is in Mexico City. So I get to learn new things and refine old things every day. So Mexico City is an hour ahead of us. So it is about 1134 in the morning where I am and it's 12:34pm where he is so he's he's doing this during lunch. So I don't know whether you had lunch? Or we'll have to get through this. So you can go eat lunch, but we'll get there. Sure. Well, let's start by kind of going back and talking like I love to do about you growing up the early rod. So tell us about childhood and kind of what your experiences were like and and a little bit about you growing up?   Rodrigo Quezada ** 03:09 Absolutely. I think of myself as a fairly normal childhood. I however, during college, I had a car accident where most of my memories were, I'm not gonna say wipe out because they're there. They're just word kind of compressed somewhere in my mind. So I'm able to access memories of my childhood as long as somebody else triggers them. And happens a similar situation with music, I'm able to pretty much sing a song as long as the music starts. But as soon as the music ends, I cannot go ahead and play it again. And I cannot sing it. But if the music starts again, I can see it again completely. So it's very similar with my memories from my childhood. So as far as I know, it was a normal, happy childhood childhood. And that's as far as I can go.   Michael Hingson ** 03:58 Yeah. Did you so were you always in Mexico City? Is that where you grew up? Or where did you grow up? Yes,   Rodrigo Quezada ** 04:04 I was born. Yes, I was born and I live in Mexico City. Most of my life. There have been a few projects for work where I have been in the in the US for a couple of it was a couple of weeks and every now and then a couple of months. But but basically that and coming back. Yes. remote work for a long time. But but you based basically in Mexico City. Yes.   Michael Hingson ** 04:27 So you're pretty used to doing remote work already?   Rodrigo Quezada ** 04:31 Yes, actually, I was long before the pandemic that we had the COVID in the year. I believe that was 2020. Right? Before that as communications start to become more accessible. It was becoming much much more easier to talk around people around the globe at a fairly unexpensive way. So because of that it was fairly easy to work from pretty much anywhere. So I had the I guess I was lucky He enough to consider myself a knowledge worker and start doing that since probably say about year 2020 10 When I was working in the automotive industry,   Michael Hingson ** 05:10 what did you do in the automotive industry,   Rodrigo Quezada ** 05:12 I used to be a buyer, which later turned into a global responsibility bility becoming a Category Manager, specifically for rubber, later on adding plastics and gaskets. So I was in charge of global supply in order to make sure our facilities in Mexico in the US had the materials they needed in order for us to assemble the products for for commercial vehicles. Right.   Michael Hingson ** 05:42 Okay. And that kept you busy. What, when you were in college, what was your degree? And what were you studying? Well,   Rodrigo Quezada ** 05:49 my original major was in international business. Back then, by the time that I was just about to select my major, the we start getting some of these agreements like NAFTA, where we were able to start sending goods back and forth, because before that, there was not a lot of trading among at least not along among Mexican other countries. After that, it opened what it is wide open. And now we have globalization is a whole different landscape right now. But back then, there were not as many commercial agreements, and it was pretty trendy. And I thought that was interesting. And it started out in that route.   Michael Hingson ** 06:29 So did you end up getting your bachelor's degree in that?   Rodrigo Quezada ** 06:32 Originally? Yes. And once we unfold the story on Scrum, then everything changed. And I see a very different career path. Yes,   Michael Hingson ** 06:42 I gather and we'll we'll definitely get to that. But so when did you graduate? What year did you graduate from college?   Rodrigo Quezada ** 06:48 That was me in year 2000.   Michael Hingson ** 06:54 That was around the time you had your auto accident?   Rodrigo Quezada ** 06:57 Yeah, like, before I graduated, like it's probably happened somewhere along the lines of 9697.   Michael Hingson ** 07:04 All right, so it was a little bit before you graduated anyway. But yes, that was certainly a major change in your life. Where you were you laid up for a while, or our, how did it affect you other than suppressing memories? Well,   Rodrigo Quezada ** 07:22 I think on the bright side, it allowed me to have a visitor give life a much broader meaning I was I was super grateful that I was able to make it. The heat came in my on my side, I was driving, it was my fault. I started moving forward in order to cross and then a car was coming, and there was no way that he can be avoided. And it was interesting, because I look into this person, that driver, it was I look at her eyes. And it was almost like communication, that it's I think of it out of this world. It was like talking through through without talking if you know what I mean, there was like a moment where I was pretty much saying please, please, I want to I want to still be here a little longer. And I start watching a movie. Before that I start watching a movie of my life, like a lot of kind of pictures in a super fast space. And and that's when I realized that I was just about to no longer be here in this world. And that's when I was like, oh, no, please, I read a Ruby. And that's when I make these super quick communication and eat work and and she seared the wheels. And it still hit me for sure. But not not in my door. If he had been in my door, I would not be fortunate enough to be talking to a and sharing all of this. So once once they helped me realize what happened, I realized how fortunate I am to having a second chance in this life to make the best out of it and and validate and savor as much as possible. Of course, it's not always easy, but but definitely worth attempting to to enjoy it.   Michael Hingson ** 08:58 Well, and it's interesting, I've talked to a number of people who have had major crises in their lives, and have had to, to deal with that. And so many people have said, sort of the same thing, that having a second chance and really having the opportunity to go back and think about it. They realize that the second chance gives them the opportunity to try to do more meaningful things and to be hopefully better people but certainly gives them the opportunity to go off and better value life and what it brings.   Rodrigo Quezada ** 09:39 Yes, fully agree.   Michael Hingson ** 09:41 Yeah. And you know, I'm, of course, I had my own experience with that, needless to say, surviving being in the World Trade Center on September 11. And, and we had discussions about it my wife and I, especially when the press started getting our story and the decision that that I'm made and my wife agreed was that if we could help people move on from September 11, by me doing interviews and, and also, eventually also starting a speaking career. And if we could teach people a little bit more about blindness and disabilities and guide dogs and other things, and it was worthwhile. And I love to tell people now being in large part of keynote speaker traveling the world to speak. It's much more fun to sell philosophy of life than it is to sell computer hardware. So   Rodrigo Quezada ** 10:36 yes, it's   Michael Hingson ** 10:37 a whole lot more fun to do that. So I will always do that if I can. It's much more fun to do computer stuff. So I can't complain a bit. Well, so I'm, well, I'm very much glad that you're here. So we could do this podcast. So I really appreciate it, though, that you have learned to value life more. And that's a good thing to do. But you went into the to the automotive world, and how long were you doing that? I   Rodrigo Quezada ** 11:07 was in that industry for 13 years. Wow. And then what happened? Okay, he gets interesting, I was into project management handling these different kinds of prod projects. And I was looking for ways to be a little bit more productive. So I was doing that. And then I spotted a name, a title of a book that was called doing twice the work in half the time by the author, Jeff Sutherland. And I was like, Oh, this sounds like a book that I need to get into. Right. So I started reading it. And I was a pivotal moment in my life, or at least, yeah, no, it was in many different ways. So I start reading the book. And I was I have, I had almost, I have to try it at least. So I tried to implement it. And I wasn't not being lucky enough to say that I was successful. So I realized I needed additional understanding of it, and then I seek out for training back then, right now is certain it's a bit more accessible to have training online. But back then it was not in like late year 2015. But I was able to find a place called scrum.org that had this workshop. And that was lovely. That sounds about perfect. And so So I did, I traveled to the US got this training. And it was it was amazing that the environment was very energizing. And I was like, oh, gosh, this is so definitely it. And I was able to connect the dots that I was missing prior to just reading the book. And I came back super excited. And I told my boss, I know this is gonna sound really, really weird, but I want to go ahead and implement it even I still not an expert on this, but I want to give it a try. And if you don't mind, we're gonna play roles. And we can make it happen if you're willing to allow me to. And that's the way I started pioneering on using Scrum. So where were you working at the time? Yeah, I was working for Bendix, commercial vehicle systems. Bendix, I was based on Mexico City would enough is here. But eventually, I also got an office in our corporate facility. Back then it was located in Elyria, Ohio, very close to the Cleveland airport, about 30 minutes from there. And now they move over to Avon the corporate move over. So back then I was like, why don't, why don't we don't have a kind of like a team like the scrum team that I can refer to, but I was like, let me make you the product owner. And I'm going to be a little bit of a mix of a developer and a scrum master. Because our organization, I don't know if has changed ever since. But it used to be kind of like a matrix. So the the way the teams were set up, were very dynamic. So it was not a this is a specific team that we can call scrum team. But even then, that was enough raw material where to get started. And it was the most empirical way to do it. I was back then I was even using Excel as a way to visually track the work that was meant to be done.   Michael Hingson ** 14:10 Well, so far, first of all, what did your boss say when you said I want to try to put this into effect and so on? What was your boss's position?   Rodrigo Quezada ** 14:23 He was one of the directors for purchasing and aside of the fact of thinking that I was kind of crazy of doing something so something and nobody else seemed to be doing around us. I think he was more of why not? You already went through this training. So let's let's give it a shot. And interesting enough later on. I don't think I don't know if it was because of me or pretty disconnected. But the company has eventually moved over to using Scrum, which I was super happy when I heard they were about you about then I was at that point in time. I was no longer with the company but but it was I was super excited to hear that they weren't going to do that.   Michael Hingson ** 14:59 So, why Scrum? That is? Why, why that word. Give us a little bit of the origins and kind of maybe start to fill us in a little bit about what this is all about.   Rodrigo Quezada ** 15:14 Absolutely. A scrum comms. Scrum is the framework right? grandslam to atheris, with our Kench, whoever and Jeff Sutherland. So they together created this framework, and they have refine it and make it better and better over time. Were these idea of giving these a specific name, they describe it as referring to the game of rugby, rugby, where the team is very cross functional in that like, you go like here and I go here and we stay in an each position is more alpha, we transition into whatever needs to happen in order to make this work. So that's what they thought this is almost like, like, like doing Scrum when you when you're playing rugby. And that's the reason why they gave his name off a scrum to the framework. And what it happens is that within this framework, you set up yourself in small teams, but each team has everything it needs in order to accomplish its goals. So basically, is a small unit of people 10 or less, usually, that set up a scope and, and become or are allowed to become self organized in order to make everything work.   Michael Hingson ** 16:29 So does that team then work on a specific job a specific function? Or is it more general, kind of trying to understand a little bit about what the framework is and the whole process? Absolutely,   Rodrigo Quezada ** 16:44 the team is meant to be cross functional, because it has to handle the order or has to have all the resources needed to accomplish the goals that are set for for that specific team. Now, there will be times where a project is extremely complex, and one single team is not going to be able to do everything. So that's where you're able to what is called as scale or scaling, which basically means different teams are working on a small portion of a larger goal. But the outputs of the different teams combined allow for these one big thing for a company to be able to go happen. Maybe Maybe if I go ahead and describe how the framework breaks down into its components, that could be helpful to share. Let's do that. Okay, sounds good. So So basically, there's three roles, three artifacts, and five, it has changed names over time, sometimes we call them events, we call them ceremonies, or commitments, I think the most recent way to to frame them. And basically, within a team, you're going to have three roles. And there's going to be a product owner, who is the person in charge of maximizing value for the team. And that is a person that is a bridge between the customers or stakeholders and the team that is actually doing the work. So So that's more related to what we usually think of as a project manager. But this position in the scrum team becomes quite complex. And that's why there's a second role that is created that is called the scrum master. The scrum master accountability is efficiency of the team. So it's more geared towards the inside of the team, which is the communication with the product owner and the auditor role, which is the developer. So when we think of developer, it can pretty much be any function. Because scrum can be used in any industry, although it has a natural, a natural fit with anything related to technology and software and all of that, however, it can be expanded to pretty much any industry. So that will change the scope and therefore the composition of of a team. So for instance, let's say in a non tech kind of team, you could have somebody from marketing and somebody from accounting and somebody from I don't know, some sort of operations and that team combined is going to go and reach a given amount of goals. And and then that's kind of like the three roles of the team. The product owner, the scrum master and developer and the developer are the the people that actually make the work happen. The the go getters, let's think of it that way. And the team works as a cohesive unit, which means there's got to be a clear direction of what needs to be done. The supporting coaching by the scrum master and the team actually making that work happen. Once we transition from the roles to the artifacts, that's where pretty much how the work gets managed. You create what we call a backlog of work or product backlog items within this product backlog which is everything you can build or create or accomplish. Basically your list of goals are Wish List. And so far, I'm not going to find that you want me to elaborate on any of the points that already talked about?   Michael Hingson ** 20:07 No, I think you're, you're doing fine. Let me let me ask you a question though. Typically, in a team environment, there's a team leader, is that the scrum master in this case?   Rodrigo Quezada ** 20:18 Ah, that's a? That's a great question. It's a complicated question, by the way, that's fair, as us as a scrum master and product owner sharing that leadership accountability. But if you think of, if a stakeholder or a customer has a question, Who were they gonna direct their question to, that's gonna be the product owner. So in that classic regard, I think I'm gonna have to lean more towards the product owner would be that lead. However, from a team standpoint, kind of like the leadership tends to gravitate more towards the scrum master, because the scrum master is is willing and able to help the team, figure out or solve, actually understand which which impediments you might have, and find a way to solve them. Now, in a great scenario, when you're coaching as a Scrum Master, you're not trying to solve the problem for the team, you're just trying to help the team being able to solve it by themselves. So it's more of a facilitator. But it's also a leadership role. Okay,   Michael Hingson ** 21:22 so if the scrum master is more of a coach and a facilitator, in sort of the typical language of teams, and so on, then what is the product corner person,   Rodrigo Quezada ** 21:38 it's also a leader. But the broker will be more centered around the product itself than than the team or the team efficiency, because that's where the support from the scrum master comes from. So the product owner will be more more related to to figuring out the requirements and needs from the customers slash stakeholders, and translate that into a team in order for the team to work on that value maximizing goal. Okay.   Michael Hingson ** 22:08 All right, well, go ahead and continue sort of the explanation of how the whole the whole process works, then?   Rodrigo Quezada ** 22:14 Absolutely. So from the goals, we go to what are called the artifacts, and there are three, one of them is the product backlog, which is basically your inventory of everything that that we can go ahead and build related to a given product. From there, what you're going to do is that you're going to break him down in a small in a smaller chunk, which is where from everything that we could do, where are we actually going to commit to do and that's when you go into what we call the sprint backlog, which is basically a smaller one, wait a given timeframe in order to be accomplished. And once it is that will usually refer in in traditional project management as deliverable. We call it an increment in Scrum, which is the outcome of work from the team within a given timeframe. Now, that will take us over to the ceremonies because that timeframe happens to be one of those. But before I move over to the events or ceremonies, any any questions you might have regarding the in the artifacts, or the rolls?   Michael Hingson ** 23:20 I don't think so at this point. I'll keep thinking about it. But I'm just fascinated to hear this explanation.   Rodrigo Quezada ** 23:28 Thank you so much. So moving into the ceremonies, there's there's the container for the word, it's called a sprint. And it comes from from racing, right like like a short race called Sprint. So what you're going to do is that you're going to work on something, and it's going to be a month or less, usually in increments of weeks. So usually you're going to use the sprint stuff one week, two weeks, three weeks, or up to four weeks. But no more than four reason being you want to keep it a as a scope of work that is no longer than that. In order for you to make sure you collect feedback, which is one of the I think biggest benefits of using Scrum. You're not working on something for a long time. And then in the end, come back and say a marketplace live, what I got is more of I work in a little something and I collect feedback. And based on that feedback, I'm able to inspect and adapt. So the team is always working on the highest customer priority or value, value or valuable item. So that being said, you set up a cadence of your sprint, which can go from one week up until four. And that's it. Once you have the spring. You start your spring with a sprint planning meeting, which basically do us collectively as a team commit to a given amount of work and therefore an increment or increments by the end of the sprint. Once that happens, you have a daily meeting which too it's wondering it's worth it happens On a daily basis, and it's a meeting where you're going to synchronize with a team, you want to make sure that everybody is working towards the goal, and basically keeping the eyes on the ball. And then by the end, the close to the end of the sprint, you're going to have what is called a sprint review, which is where you showcase the work that has been completed to the customers largest stakeholders. And it's a great place for interaction and collaboration, because basically, you're promising something, then you are showing what you have committed to what you promise, and then you get understanding of the path moving forward. Sometimes the customer know exactly what they want. And sometimes they think they want something but then once they start to seeing that as something they can actually inspect, they might want something different. And that's great timing, because this chrome allows for rapid changes or ongoing changes. So I might go one a given route, but I want to change route. Absolutely, let's do it. And that's what these sessions are for is kind of like a working session where collaborate the team or the scrum team and the people that are going to be using the outcome of the work, meet to review and, and provide feedback to each other. And the last event, once that happens is a what is called a retrospective or retro where basically just the scrum team gathers and understand what are the what is the team doing right? What is the team, that what the team can improve, and basically include those small improvements. And that's where the continuous improvement portion comes in. Because every single sprint, if the team is working properly, the team is growing better and better over time.   Michael Hingson ** 26:44 Well, okay, so this is clearly a very structured organizational process, which I can appreciate. But you said a lot earlier that that what you really got intrigued about and what intrigued you with the the whole idea of Scrum, even before you necessarily knew the name was do twice the work in half the time. So why does this process really increase workflow?   Rodrigo Quezada ** 27:13 Great question. One, one of the answers is because of the communication flow, the fact that you are keeping keeping teams small enough allows every team member to be able to understand each other, if the team is too weak, like when you go to a party, right? If there's too many people in the table, you can talk to a few that are close to you, but you cannot understand what is happening by the end of the table. So it's very similar, because the team is small enough communication flows properly. And therefore you avoid misunderstandings. And you're able to communicate faster and better. Therefore, you become far more productive. The other thing that I think is a part of the answer is the level of autonomy of a scrum team is fairly large. So that allows the team to organize to better suit their own needs, which allows each of the team members to bring in the best of them, and then combine them into the pool of resources. So the fact that everybody is able to work in such a pace, and the team either failing or succeeding as one. I think that's part of the reason why it makes a team so productive. And last but not least, you you every spring, you work towards the goal. So there's no misunderstanding of Yeah, everybody's doing a little something. Now, by the end of the sprint, we're going to show the work that we have completed. So so we keep focused, and we make sure it happens.   Michael Hingson ** 28:46 So it sounds like in any company, where you have a fairly decent number of people, you're going to have a number of different Scrum teams. And each one is is working on a project or maybe a few teams are working on different parts of the same project. But who coordinates all of that. So it sounds like there could be essentially a scrum within a scrum then that you've got somebody who is overseeing what the various teams are doing.   Rodrigo Quezada ** 29:21 Yeah, interesting question that's probably gonna change from from company to company or industry to industry. Think probably should explain that. A Scrum is a framework is meant to work as a whole. I mean, you don't escape roles or escape ceremonies or increments, you use all of those elements. But once you have that basic foundation, which is basically the framework, pretty much the rest of the field is very flexible. It allows for us I was explaining like scaling for instance, if I have a larger project, one team is not going to be able to accomplish everything then we can Scale to two teams or three teams or four teams. Now, if we are to go that route, then yes, your point, we're probably going to need to use as an organization, some additional tools for managing that complexity across different teams. But as long as the teams are not working on the exact same thing, potentially, you're pretty much just setting goals, and letting them go work towards those goals. So so the self organization of the teams allows a lot of flexibility for the organizations as well, they just need to set the goals. And then the teams go work to make those goals happen.   Michael Hingson ** 30:34 Well, let me maybe phrased the question slightly differently, who sets the goals?   Rodrigo Quezada ** 30:41 Well, that's what we usually refer to as the stakeholders, but stakeholder can be pretty much usually is going to be like senior leadership levels, that are saying this is what we need. So depending on the size of the company, that's kind of like which level is setting which goals, but I think is gonna probably cascade down, it's going to be most likely many of these pros is going to be top down. Eventually, if there are some mature Scrum teams, you can actually let them run wild with Can you set up your own goals of what you can actually accomplish and make that kind of proposals bottoms up? That's definitely something that can be done as well.   Michael Hingson ** 31:17 Sure that and I can appreciate that. But in general, what you're saying is that there, there is someone or there is some part of the organization, as you said that the top leadership that essentially stakeholders sets the goals. And that's where the process begins, and then assigns or works with the people below them to decide what team is responsible for what goals?   Rodrigo Quezada ** 31:49 Yes, and that's where the communication takes place between these stakeholders and the product owner, in order to break it down for the team to work in that. Right.   Michael Hingson ** 32:00 Okay. And so, once the goals are assigned, then is it also true that someone keeps the the leadership informed as to how the team is going? Or is the idea you have to trust the team and let them do their job for a month, and not interfere with the dynamic of the team?   Rodrigo Quezada ** 32:25 What I'm saying? Absolutely, yes, I guess potentially, that sometimes that can actually happen, in my experience is more of less ongoing communication between the product owner and the stakeholders, even though we're working on a given set goal for each sprint, yeah, is usually potentially having these communication helps towards the same point in time, good practice to have a roadmap of what you're doing. And eventually the roadmap can as I said, it can change because of what we think of discoveries, right, or validated learning and, and kind of think of, there's an amazing book about that by Eric, oh, gosh, he's like, I almost could swear it's Reyes, it's called the lean startup. And there's something concept that brings that comes from this book called validated learning, which is sometimes and the reason why the scope of this team says is small, is because there's a lot of unknowns when you start a project. So there's things and assumptions that that kind of like could hold true over time. But the more the larger the project, the less likely they are. So you have a certain degree of assumptions, and you want to go try to test them as fast and early as you can. Which leads to a concept that we refer to in this Agile world as your fail fast, which doesn't mean you're trying to intentionally fail. But if you are going to fail, it's better to do it as fast as you can and get your lesson learn and move forward. Because that allows you to experiment a little bit, which pairs well with the empirical nature of this process. And it also helps on the Lean thinking, because you don't want to waste resources. So if a project is going to be canceled six months from now, I rather know what would not let leave that padding to that project and cancel six months from now and cancel it, let's say two weeks after getting started, right. And I'm thinking worst case scenario, right with a project canceled, more often than not, your project is gonna change paths in order to arrive to one that is actually your successful path. So you go from something good to I guess I'm learning this from a title of a book, right? But what kind of going from good to great, right? Because you are understanding your product better as you are building it. And that takes me over to a concept which I think is in the core of everything we're talking, which is the iterative and incremental nature of Scrum. So what you're doing is building a little something, you do an iteration, and then you stop. You inspect and adapt and based on your findings, and Next time around your next iteration is going to build on top of that. So that's what we call the incremental nature because you're always delivering something. And it's always better than the, the version you delivered before. Can   Michael Hingson ** 35:15 you give us an example and tell maybe a story of, of a project and how Scrum, really enhanced getting the project done? Can you actually, is it easy enough to tell an actual story and talk about your experiences with it?   Rodrigo Quezada ** 35:35 Yeah, absolutely. I'm kind of thinking across I know, I'd see for an example is like, oh, gosh, it's been a couple of years. So I mean, I've collecting experiences. Sure. And, yeah, plus the NDAs. Right, what I can and can't share about Sure.   Michael Hingson ** 35:54 When you just sort of in general.   Rodrigo Quezada ** 35:58 Okay, got it. Yeah, well, let me share this example. It happened in one team, where we had these cross functional setup of the team members. So each of them having a speciality or kind of like being a specialist with one thing. And what happened, eventually, when we started doing the work, there were a couple of team members that were doing a lot of work. And there were some of them that we, we see working every now and then. And that makes it kind of complex, because as long as every, you have like two options, right? If you're going to be cross functional allele, everybody, there's a little bit of everything now, that for sure, nobody's going to be as proficient as the specialist. But the whole idea is that we can rely on each other. So for example, if our our programmer gets a stock, and he can get some help from the tester, then the tester gets the program a little bit with some shadowing are helped by the programmer, and then they can both program a little bit. And that's an example of clean Croc cross function. But if you're not able to do that kind of thing, because of whatever risk management policies or even willingness by the team members to go outside of their usual line of work. And that was the case here. There were team members that said, this is what I do, this is what I want to keep doing. So what we end up doing is if if these team members are don't have some tech skills that we need, but there's this other activities that they can do, as long as they don't have to mess up with the complexity, complexity of programming, or managing certain technology tools, what we did was simplify that and create a web application for for low to no code, tech team members to be able to produce work in that application. And that helped because now they can do work in an ongoing basis, as opposed to having to wait until there was some no tech work for them. And that helped the team increases the throughput dramatically, because now different team members could actually be producing work in parallel, kind of like everybody working on something at the same time, and the output was increased significantly. So   Michael Hingson ** 38:14 with those team members that really were not very technically inclined in the process, it sounds like they may not have really embraced the whole scrum idea at the beginning. But what did they think by the end of the project?   Rodrigo Quezada ** 38:30 Well, I think by providing them tools and make their life easier, and they can actually contribute to the whole, I think that that was a pretty amazing experience for us all because it is great if everybody can like go ahead and do different functions, but it's not always possible. So if it is not, how can we think outside of the box and seal provide a solution that allows the team to be more productive? And that's what we did. And it was an amazing experience.   Michael Hingson ** 38:55 And I think that's really the issue here isn't that what you're really promoting is people thinking and innovative in different ways, collectively, so that you are able to fashion and create a solution may be where you didn't think there was one. But by working together by functioning as a team, and by valuing the team, you figured out? Well, we've got to do these additional kinds of tasks to make it possible for everybody to be productive. But that's what it's really all about, isn't it is everybody needs to be involved in the team and be be productive? And the team has to be concerned about that and really work to make that happen.   Rodrigo Quezada ** 39:39 Yes, I'm glad you mentioned that. It's almost like as simple as saving the best for last. The definition of a scrum includes the fact that it is creating adaptive solutions to complex problems. And where it connects very well. What you just mentioned is that it is more of a mindset. It works within a framework. Yes. But but all the pieces working together, it is really about a mindset of problem solving in a way that that, let's say sets up the field in order for you to be very successful. So it is a tool that embraces change and innovation and problem solving, I think to a whole new level, and that's what I think we need in this day and age. Because as we have evolved as a human species, we have also been facing challenges that we didn't have before, like, like, like global warming, and are things that that are like, gosh, how are we going to solve that, right? But we gotta find a solution. Because if we don't, our our, our future is compromised. So how do we manage and handle all these projects, and I think this might not be the only way to do it. But it's definitely one way to do it. And that's the reason what I consider myself such an advocate for Scrum. I think once you do it and understand what it's coming from, you cannot stop using it, I can't.   Michael Hingson ** 41:05 So you use it in, in work and everything that you do, what do you do now? Or are you working for a company now? Or, or what's your current job environment like?   Rodrigo Quezada ** 41:15 Yes, eventually, as I started gravitating towards technology related words and phrasing and things like that, I start exploring into a new career path. And by year 2018, I started a new undergraduate program for computer engineering. And I finished that when in 2020. And then I got into a master's in data science. And about that same timeframe, I was lucky enough to join at&t, where I currently work as a principal project manager working with Scrum teams. And And most recently, I also getting engaged pursuing a PhD in computer science as well. So once I started gravitating towards technology, I realized my passion for it. And that process Grom. And it started ignited me into a very different career path, which is what I currently do.   Michael Hingson ** 42:12 So did you bring scrum to a TNT or was AT and T already embracing that as a concept?   Rodrigo Quezada ** 42:18 Because fine, I think they're really for this specific project is something that was about to get started. So pretty much. There were a few people getting started with it with a project. And then eventually, there was a significant amount of additional of team members that were hired. When I started with them, I started actually as a scrum master. And eventually, by doing the work, I transition over to product owner. So I'm fairly familiar with with with all the roles as I was leaving doing development when I got started on a very empirical way since early 2015. Yes,   Michael Hingson ** 42:56 so as a product owner or as a scrum master. When I mean that, that isn't a full time job as such, that is, you don't just sit in monitor other people, you're directly involved in doing a lot of the work yourself, right?   Rodrigo Quezada ** 43:14 Yes, absolutely. Regardless of the role, yes. Right. And   Michael Hingson ** 43:18 so you are just as much a part of the working team as anyone else. Even though you have the additional responsibilities of being the product owner, the scrum master, which is understandable when a project is done. This is a question I've always found interesting with different kinds of teams, because a lot of times when there is a team effort to do something, when it's all over and it comes time to recognize the teams, the team leader gets recognition and the rest of the team doesn't necessarily get the same amount of visibility. How does that work in a scrum environment? Is it just the project owner, product owner or the scrum master that gets recognized or is is the company or the process such that it's understood that it's really the whole team that needs to get recognized not just one or one or two people,   Rodrigo Quezada ** 44:12 it has to be the whole team if you ask me, because everybody is pushing towards this successful outcome that is a team outcome. So So collaboration and teamwork is is kind of like the glue that binds everything together. So even though the product owner is representing the team and helping the requirements and understanding and communicating with stakeholders, interestingly enough, as we are used to traditional management positions, item kind of think of off meter or scrum master or product owner as we can think of them as managers, however, from my view is almost like not giving yourself that managerial title. In some words, maybe you're doing it but you are so part of a team that is hard to tell apart. I'm kind of like, am I am I like, like overseeing? Or am I actually kind of like silly and bold, but I feel that I'm part of the team. If the scrum team is working properly, you are part of the team. So so it's not like different layers of people managing and people doing even though Yeah, true developers are doing. But you're so close to them that that that line gets kind of blurry, if you know what I mean. It's like, there's no way I could accomplish this by myself, I needed the team to backup whatever I'm supporting as a product owner. And similar thing with with the scrum master, if I'm helping a team become more efficient over time, the team is better than better. And that serves a higher purpose for both the team and the whole organization. Maybe   Michael Hingson ** 45:44 more like viewing yourself as if you will, a senior member of the team in terms of experience or knowledge level subject matter expert that you're bringing to it. But that doesn't make you better, or a a person who is separate from the team. And I think that's a wonderful concept that you're still really part of the team. And it's all about how you best add value to the team. Yes,   Rodrigo Quezada ** 46:06 it's all about maximizing value as a team. Yes.   Michael Hingson ** 46:12 Yeah, that's, that's extremely important. Because in so many teams, in so many job situations, the boss regards themselves as the boss and everybody works for them. The team leaders, the team leader, everybody works for them. But they're not in a sense, as much a part of the team is they really ought to be   Rodrigo Quezada ** 46:33 Yes, true indeed. And actually, that remember that, when they, when they created this framework, they they took away titles, they didn't want to say you're the senior de surgir, the junior dad, because that's more related to a hierarchical kind of structure. They wanted to make it as if you're a developer, you're helping with creating and crafting and adding value to the product. So you are a developer. And that's it, you don't need to have a specific title as you are a QA or you are a software engineer, or you are a site reliability engineer, SRE is like you're part of the team. And that's it, you might have a speciality. And there's something that I almost forgot to mention. Within this world, we're very used to I do one thing, and I do that one thing very well. But there's this concept of a T and are m shaped professional, which basically means you're extremely good at more than one thing. So So you have a broad understanding of several things, but you're good at at one or more things. So in that regard, there's no limit also to your potential as somebody doing the work. So kind of, is kind of like a path to mastery and fulfillment. So if you're doing these just like well, then then eventually that takes you to higher levels. And that in turn, moves over to your personal life. And then suddenly you have a virtuous, virtuous, virtuous cycle. I believe there's a right way to say it, Mike. Yeah, so so it's kind of like, like, it's fun. And then work doesn't feel as well, kind of like the way we think of work, right? Because work becomes far more fun, and you enjoy it. And then you do what you like. And then you happen to do even better, because now you aren't kind of like, completely nursing what you're doing. But aren't   Michael Hingson ** 48:24 scrum master and product owner titles in of themselves? Or how, how is that in the scheme of things different than then having some other kind of title?   Rodrigo Quezada ** 48:37 No, no, that's fair enough. That's where I think Trump is making an exception. We have these two, these two positions that are having kind of like extremely specific accountabilities within the team, because, for example, right, we only want one point of contact with the team to talk to stakeholders, because otherwise it could be 10 people sense from a stakeholder standpoint, right? You want to talk with one person from the team? And that's why it's specific to the scrum I'm sorry, to the product owner. Right.   Michael Hingson ** 49:08 Okay. And, again, I think that gets back to what I said before, which is really, although they are titles, it's really talking more about your level of experience and some of the expertise that you bring to the team.   Rodrigo Quezada ** 49:24 Yes, absolutely. It's a cohesive, cohesive unit of professionals working together, which breaks down silos, right, because you're trying to collectively achieve something opposed to this is my part of the word. And that's the only part I care for. And this is more of approach of this is what we are working towards building together.   Michael Hingson ** 49:43 Right. And that's what teamwork is really all about, or should be really all about. And so often we we tend to really miss the whole point of what the value of the team is, and we pay more lip service to teamwork. then actually doing things to embody it and make it really a part of what we do. I know that when I hired salespeople and worked with salespeople, one of the things that I always said is my job is not to boss you around, because I hired you expecting that you already know what to do and how to do it. But my job is to add value to make you more successful. And it sounds like that is what you're really seeking in the whole scrum process as well. And why you have a scrum master and product owner.   Rodrigo Quezada ** 50:33 Yes, indeed. And previously, you mentioned something about when the project ends. And I think that comes to a different concept that I found extremely interesting, which is, with your teams being kind of like a group of people working together, and the longer they can work together better, they can read each other's mind and, and, and talk to each other without even talking. If you happen to have a team like that, that is happy working together. The other thing that happens is, your cost and time is pretty much fixed. So so the team from a company standpoint has the keeping costs, right. And time is pretty much going going in a pretty linear way. What I'm trying to explain is, the scope is what's changing over time with the team. So you can you can start adding new or different things to the teams. And if one project ends, a new one can begin. As long as you have a problem to solve. You can leverage on on on a scrum team or several Scrum teams in order to make sure you keep addressing the problems that you want to tackle as a as an organization or as a group, right. It doesn't have to be a company always. But we can certainly use companies as a quick reference point for Scrum teams.   Michael Hingson ** 51:47 You mentioned to me in the past that Scrum teams don't in Scrum and doesn't embrace as much some of the traditional tools like Gantt charts and so on, why is that?   Rodrigo Quezada ** 52:00 Correct. The Gantt charts are mainly used within traditional project management when you are considering that all your assumptions are gonna are going to hold true through the whole lifecycle of your project. And therefore your planning is perfect at the beginning. But as soon as US bottlenecks that were not foreseen in time, or, or potentially, let's say technical difficulties that you find along the way. And those were not accounted for in the original Gantt chart. So usually what ends up happening is that the Gantt chart starts to deviate along from the actual planning or actual action in place. So eventually you depart from somewhere very different from where you intended to arrive. So what what is scrum does, there's there's some metrics that are used, usually referred to as velocity, which is very subjective, because it means something different to different teams. So one team have a 50 story points velocity, and our team can have a 500 story points velocity, which might seem that 501 is much faster than the team which 50 points but it's so subjective that from a working standpoint, that one was 50 points can be actually delivering more work to the to the to the organization. But anyway, you can have these kind of like burn downs, or burn up charts that you can use to track sort of metrics of how the team is doing against the planning. But remember, that is based on short spans of time, so no more than four weeks. So even if you're meeting or missing your targets, it just meant to be contained within a small or short timeframe for you to understand, learn, adjust, and do it again. But do it better.   Michael Hingson ** 53:36 If you don't get a project done in the four week time that you originally set based on the scrum rules.   Rodrigo Quezada ** 53:44 That would be a problem. Most of the time, what you do is you break down into small chunks that are achievable within a sprint, we we can think of and then again, this might come back to if I remember correctly, this Eric Ries and the Lean Startup, there's something called an MVP or minimum viable product, which is basically from everything we can do, what is the minimum we can achieve. So if you plan yourself to at least achieve a little something, and then everything you can add on top of that before the sprint is over, I think there's a safe path to always have something to show for you as a team accomplishing something because if you if you kind of lean towards the all or nothing approach, either I believe or everything or I don't have nothing to show, there could be points in time where the risk is high. And you're going to show up to the review saying I didn't complete it my work, right? There's nothing to show. So what I'll probably suggest is, is take the MVP path, always have a little something that is something you can guarantee as a team that you can deliver. And then if you happen to have extra time within your sprint, go build on top of that and add more things to here's what we have completed by the sprint review.   Michael Hingson ** 54:53 So if something doesn't get done in the appropriate time, you really We have two potential reasons for that, that I can think of one is, you made the goal too large, or too, the team isn't functioning nearly as well as it should be. And that's an in both cases, that's something for someone to go back and reevaluate.   Rodrigo Quezada ** 55:20 And that's where the rhetoric comes in. Because every by the end of every sprint, you need to collectively as a team say, Okay, where do we miss? Where do we waste? And what do we knew earlier? What do we need to do a little bit different to fix that in the future? So you're always looking for ways to becoming better and better as a team, which is one of the things that I definitely love about this framework.   Michael Hingson ** 55:41 Yeah. And that was why I asked the question, because, again, it's all about the team making a collective decision or creating a collective understanding. And again, is all about the team. Yes, it is, which then can communicate with the stakeholders and so on. In case it's the stakeholder that screwed up. And the stakeholder hopefully understands what the scrum team is all about. And we'll accept the observations when that happens as well. Yes.   Rodrigo Quezada ** 56:18 And there was something else that you mentioned that it triggered. Yeah, at one point in time, you mentioned about the team recognition. The sprint review is not only between this, the product owner and the stakeholders for the sprint review, you have to have the whole team. So the product owner can be presenting. Yes. But the team is there. So there's kind of like very specific questions about things on the, of how the product was built, or how the product is working, or any What if coming from the either end users, customers or stakeholders. That's where the team can bring in their expertise, because they build it together. Right? So the team has a voice as well within the Sprint Review isn't is not necessarily only a steal your point like like just who is managing the team, it's more off. Here's the whole team that builds together. And any questions, here's a whole team in order to be able to answer as a team.   Michael Hingson ** 57:10 And that's what really makes this such an exciting concept, because it's all about the team. And and hopefully, when the team completes a project, if they really work together, then no one tries to separate the team and put different people from one team on to another team. They allow the team to continue to operate and be a cohesive unit. Yes.   Rodrigo Quezada ** 57:35 And there's one more thing that also Bond's things together, which is one of the pillars of Scrum, which is called transparency. The process is extremely visible to everybody in the organization. So what the team is working on what progress are having, everybody can actually go see. So whether the team is working these working items, which you should refer to, or at least I'm used to referring to them as PBIS, or product backlog items. Everybody can go see what the team is working on and how they're communicating and their evidences of work completed and everything else. So stakeholders don't always have to rely on whatever the product owner says. They can actually go and see what the team is doing. Because the process is extremely transparent to everybody. And for sure, the team as well. So So usually the work is not a sign that work is is kind of taken, right? How can I help? How can I contribute? So I go to the to the sprint backlog, and I grab a working item. And let's say me as a developer, I go work on that. And every now and then it's not, it's not. It's not recommended that it's done. But every now and then even other roles such as a scrum master can go ahead and take a little bit of work, even though it's not recommended can be done. So. Yeah.   Michael Hingson ** 58:49 Why should more people embrace the scrum concept of doing work?   Rodrigo Quezada ** 58:55 God, gosh, first and foremost, because, aside from the fact that it, it's fosters teamwork, and increases happiness levels on and promotes mastery from team members, which makes it ever more exciting, it helps you deal with that the solutions to complex problems borrowing from the definition of Scrum. So as long as you have complex problems to solve it, what you want to solve is pretty repetitive and fairly and linear and straightforward. Yearning, you're probably not going to need Scrum. But as long as it starts to deviate from something that is that predictable. You can rely on group of professionals working together as a unit in order to tackle together those those problems and come out with adaptive solutions. Cool.   Michael Hingson ** 59:46 If people want to learn more about Scrum and the process, how can they do that?   Rodrigo Quezada ** 59:54 I'll probably say start out with information that is already provided. it on the scrum guide. You look at it as that the scrum guide. It was created by Ken Ken Shriver and Jeff Sutherland, the creators of Scrum. It's out there on the internet. So so I'll probably say start there, because that's the guideline for the whole framework. And   Michael Hingson ** 1:00:16 what is it called   Rodrigo Quezada ** 1:00:18 the scrum guideline, okay. It's even trademarked. But it is open to the public, you don't have to even pay to in order to be able to read or things like that. And it's been translated to different languages as well. So I'll probably say start there, because that's, that's pretty much the epicenter from for the whole framework. However, if you want to learn a little more, there's different books out there and different organizations that can help in the process, including certifications and everything else. Guess one of them, for sure, is this book that started me with Scrum, which is called doing twice the work and half the time by Jeff Sutherland is definitely one of my top recommendations for Scrum. There's also two websites that I think of that are that are scrum.org. And there's other ways to that is called Scrum Alliance. Dot I believe that.com. But if I'm incorrect that.org Both both promote a lot of conversations and best practices on Scrum. So a lot, those are great resources. There's a lot more out there. But those are the ones that come top of mind.   Michael Hingson ** 1:01:23 And is there a way if people want to talk to you and kind of get more thoughts from you about all this or just get to meet you? Is there a way for them to do that?   Rodrigo Quezada ** 1:01:32 Yeah, we could probably use LinkedIn for that. I haven't had a lot of civility. But I don't mind if I do because the whole purpose of this podcast was sharing this out loud with more people. I know what I know what up what I want that to be spread out, because I'm definitely a scrum enthusiast. So if there's way that I can help somebody else I'll I'll be happy to. So   Michael Hingson ** 1:01:59 how can they reach you on LinkedIn? What? What do they look for?   Rodrigo Quezada ** 1:02:06 Let me go seek my gosh, would it be okay if I sent it to you, I don't have it handy. Kind of like but but you can look for my name, Rodrigo. Queszada Queszada with a Z and Reyes with a Y in the end. And it's I think it's fairly accessible. Once you're into Lincoln system. Go ahead and spell all that for me. So sure, no problem. Rodrigo says spelled R o d r i g o, my first life name. Last name is Queszada. Which is Q u e z as in Zebra a d as in Daddy a. My other last name it which is Reyes R e y e s   Michael Hingson ** 1:02:51 There we go. So we can search for you on LinkedIn with that. So what are you doing? You're not working?   Rodrigo Quezada ** 1:03:00 Guys, I would rather work I'm usually doing some training. And aside of that, for sure. It's spending time with friends and family. It's a mix of of those. I have these reckless pursuit of understanding and training and eventually I'll find my purpose in life. I'm still in debt that I cannot say I have it. What I always feel I'm getting a little bit closer. So I hope I get there before. Before my end of   Michael Hingson ** 1:03:24 life. There you go. Do you do you have a family? Are you married or anything like that? Yes.   Rodrigo Quezada ** 1:03:28 I'm married. Two kids. Almost 10. Actually, they're just about to be 10. And, yeah, and also two bucks. So So yeah, I think.   Michael Hingson ** 1:03:41 Yeah, so So that's six in the family. If you get four more, you can have a scrum team.   Rodrigo Quezada ** 1:03:48 Yeah, getting close. Yeah, keep   Michael Hingson ** 1:03:50 keep working on that. Well, Rod, this has really been very much fun and enjoyable. And I really appreciate you coming on and talking about Scrum. It's a concept I have not been familiar with. But I'm going to go learn more about it. I think it's fascinating. I think there are parts of it that as I listen to you tell it that I have used in the course of my life, although I never understood it and call it Scrum. But I appreciate it. And I think it's an extremely valuable thing. Anything to promote teamwork is always a good thing. So I want to thank you once again for being here. And I want to thank you for li

Today, I am blessed to have Bjoern Woltermann here with me. He began his career in 1995 as Woltermann Datentechnik's founder, providing IT infrastructure for small and medium enterprises. In 2006, he took on the role of Head of Social Media Services and Head of Product Management Holiday Real Estate at ImmobilienScout24. In 2009, he became the Head of Competence Centre Social Web at Scout24 Holding GmbH, where he created, collected, and shared knowledge in Social Media, Social Networks, Realtime Communication, and Personalization. In 2010, he joined Deutsche Telekom as Vice President Emerging Technologies and Project Owner of "Global Customer Platforms". He incubated emerging products and technologies and built the technological foundation to bring new and existing products and services to new customers and users globally. In 2015, he founded Katalyst Interactive Inc. and Katalyst Fitness OHG, where he combined the latest exercise science and tech to empower people to live healthier lives. Bjoern E. Woltermann attended Bessel Gymnasium Minden from 1987 to 1996, where he obtained a high school degree in Mathematics, History, English, and Biology. In 2002, he earned a Master's Degree in International Economics from Paderborn University. In 2010, he obtained a Certified Scrum Product Owner certification from the Scrum Alliance, and in 2011, he obtained a Certified Scrum Master certification from the same institution. Bjoern's journey from pain and sedentary living to strength through Electro Muscle Stimulation (EMS) training underscores the transformative power of exercise. Introduced to EMS technology, he experienced remarkable improvements in physical well-being, including relief from back pain and enhanced body awareness. Recognizing the broader benefits of exercise for aging and overall health, Bjoern advocates for proactive training with EMS, emphasizing its potential for optimizing performance. He challenges conventional fitness norms, promoting a user-friendly approach prioritizing tangible outcomes over struggle. Through innovative design and thoughtful care recommendations, Bjoern aims to revolutionize the fitness experience with Katalyst EMS technology, fostering convenience, longevity, and reliability.  Purchase your Katalyst here: www.katalyst.com/ketokamp Diabetes Method Program: https://diabetesmethod.com/ 

In the final episode of the Code of Ethical Conduct for Agile Coaching series, guests Renee Troughton and Craig Smith discuss the Code of Ethics and how to put the Code into practice. About the Featured Guests Renee Troughton is one of the most experienced Enterprise Agile Transformation Coaches in the southern hemisphere, with extensive experience working in small to large organisations across many sectors including finance, insurance, superannuation, government and telecommunications. Craig Smith has been an Agile Practitioner, Coach and one of Australia's premier Agile Trainers for over twenty years. As the Business Agility Product Lead for SoftEd, co-organiser of the Agile Brisbane Meetup Group, co-chair of the Agile Coaching Ethics initiative, co-host The Agile Revolution podcast and an Agile Editor for InfoQ, Craig is a long time contributor to the Agile community. Follow Renee on LinkedIn Follow Craig on LinkedIn  Reference(s) Code of Ethical Conduct for Agile Coaching https://www.agilealliance.org/resources/initiatives/agile-coaching-ethics/   The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org  Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg    Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile.   About our Hosts Renae Craven has been coaching individuals, teams and organizations for over 13 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel https://www.youtube.com/@cravepilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn 

It's Lee here, your host from the Daily Standup Podcast, and I'm absolutely thrilled to share something extraordinary with you. We've just hit a milestone that's both humbling and exhilarating – our 1000th episode!

Have you ever returned to an old User Story and wondered, “what was I thinking?” On today’s episode, Mike Cohn, walks us through how and why he recently revisited and updated 200 Real Life User Story Examples from his past projects and updated a resource for you! Listen in as Mike and Brian share what worked and what didn’t work from the past, in an effort to make their user story writing skills stronger. Overview What makes a user or job story great? In this episode of the Agile Mentors Podcast, Brian Milner and Mike Cohn of Mountain Goat Software, share Mike’s recent updates and edit to 200 Real Life User Story Examples. Listen as they revisit 200 older user stories, breaking down their analysis through the lens of more experience and an evolving technological landscape. Plus, in true iterative fashion, Mike shares how he is still working to write better user stories after years of perfecting and teaching the art of story writing. Tune in to learn what makes a great clear user story, and what makes a story that stinks. Listen Now to Discover: [00:57] - Brian is joined today by Mike Cohn who will be revisiting user stories. [02:58] - Mike talks about how he came back to these 200 user stories and decided that some of them sucked and needed updating. [04:42] - When writing user stories, Mike talks about prioritizing meaningful conversations over perfect user stories. [06:35] - Brian underscores the importance of efficient communication with developers through unconventional yet practical user stories. [07:22] - Brian points to previous podcast episodes with Mike that delve into the basics of writing user stories, in episode, #10 Why User Stories are the Best Way to Capture Requirements with Mike Cohn and #39 The Art of Writing User Stories with Mike Cohn [08:22] - Mike walks through a story written for the development of the Scrum Alliance website, noting it is framed well within the site's premise. [09:10] - Brian raises considerations about inserting information mid-story. [09:57] - Mike finds the story intriguing but suggests simplifying it by moving details into acceptance criteria, a notion that didn’t exist at the time, for clarity. [12:03] - Mike advocates for concise user stories, suggesting omitting unnecessary details and using acceptance criteria for specifics. [13:52] - In a job story example, Mike and Brian point out common mistakes from an era without distinct fields. [16:34] - Brian understands the attempt to prompt discussion in the job story but finds it normal overall. [17:32] - Mike critiques a job story for site admins approving job postings, suggesting modernizing language for notification methods and flexibility. [19:34] - Reflecting on a story about user authentication, Mike acknowledges a bias toward email-centric perspectives, and questions if this story goes too far separating the what and the how. [21:22] - Mike highlights story #42, recognizing a potential mistake in specifying UI details in a story about navigating job listings. [23:24] - If you’re struggling to get your team or organization on the same Agile page from team members to senior executives. Mountain Goat Software can help you Build a Common Understanding of Agile on your team! [24:17] - If you’re a visual learner or you’d like to follow along, you can find the pdf of all the user and job stories discussed in this episode, plus many more, right here. [25:12] - Mike defends a story about viewing detailed course pages, acknowledging UI implications but justifying the necessity of the detail. [27:13] - Mike critiques a user story about creating user accounts, cautioning against a potentially misleading "so that" clause with a specific example. [29:18] - Reflecting on the evolution of user stories, Mike emphasizes a shift from stating "I can" or "I want to" to a more neutral "I." [30:40] - Critiquing a user story about browser compatibility, Mike suggests that it's a nonfunctional requirement and better suited as part of the definition of done. [33:18] - Brian presents a user story for Mountain Goat Software’s Planning Poker tool about database indexes, expressing reservations about the commonality of developer-focused stories. [34:00] - Mike reflects on the “as a developer” story and expresses uncertainty about its inclusion, considering it potentially problematic. [36:22] - Mike critiques a story about database analysis, acknowledging its verbosity but justifying the detail as necessary for clarifying the researcher's role and objectives. [38:03] - Brian appreciates the brevity of the "I want" part of a user story and finds the "so that" clause acceptable as it provides examples and context for developers. [38:39] - Considering a story about storing results, Mike deems it not bad but potentially too long. [40:00] - Mike highlights that the best way to get better at writing stories is to write a bunch of them, acknowledging that his early stories taught him valuable lessons. [41:03] - Brian thanks listeners and invites them to share and subscribe to the Agile Mentors Podcast on Apple Podcasts. [41:29] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. References and resources mentioned in the show: Free download: 200 User Story Examples #10 Why User Stories are the Best Way to Capture Requirements with Mike Cohn #39 The Art of Writing User Stories with Mike Cohn User Stories Applied: For Agile Software Development by Mike Cohn Job Stories Offer a Viable Alternative to User Stories by Mike Cohn Mountain Goat Software’s Planning Poker Better User Stories Course Build a Common Understanding of Agile Subscribe to the Agile Mentors Podcast on Apple Podcasts Mountain Goat Software Certified Scrum and Agile Training Schedule Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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.

In this week’s episode, Brian is joined by the legendary Ken Rubin, the author of Essential Scrum. Together, they dive deep into the world of dependencies in larger organizations and scaling, drawing from Ken's extensive experience since the early days of Scrum. If you're navigating the complexities of dependencies and looking to optimize your team's flow, this episode is a must-listen. Overview In this episode of the Agile Mentors Podcast, Brian welcomes the iconic Ken Rubin to explore the intricate realm of dependencies at scale. They dive into the impact of dependencies on flow, the challenges of scaling, and the effectiveness of feature teams in managing structural dependencies. Ken shares valuable insights into the myths surrounding dependencies and practical strategies for minimizing their impact, whether they involve external partners, scarce specialized roles, or deliberate component teams. As a bonus, Ken announces his upcoming one-day live online course where you’ll dive deeper into effective dependency management strategies, Dependencies are Killing Your Agility: Learn to Fight Back! Tune in as Ken and Brian provide practical wisdom, actionable strategies, and a wealth of knowledge. Listen Now to Discover: [01:16] - In today’s episode, Brian sits down with the first director of the Scrum Alliance and author of Essential Scrum, Ken Rubin. [03:03] - Ken defines dependencies as a relationship between two or more entities that requires collaboration or coordination. [04:31] - Ken distinguishes two dependency types: structural and instantiated. [06:48] - Brian emphasizes addressing the root cause of dependencies, comparing it to optimizing water flow in plumbing systems. [08:06] - Ken stresses the importance of addressing structural dependencies to prevent them from becoming blockers and impeding flow. [10:18] - Brian highlights an upcoming one-day live online course with Ken titled Dependencies are Killing Your Agility: Learn to Fight Back! on March 14th, emphasizing its relevance for Scrum Masters and product owners. [11:10] - Ken defines the concept of flow and compares it to the concept of utilization. [13:04] - Leaders listening should prioritize optimizing flow over squeezing individuals for efficiency. [14:23] - Ken underscores the importance of managing structural dependencies by balancing system-level WIP. [16:28] - Ken debunks the myth that 100% feature teams can eliminate all dependency issues. [19:14] - Ken shares how feature teams are compelling but face exponential challenges. [21:45] - Ken explores the need for specialized roles in scaling feature teams, proposing a threshold approach. [24:57] - Discover why Ken advocates for a combined feature and component team model, suggesting systemic swarming for specialized roles. [26:55] - Today's episode of the Agile Mentors Podcast is brought to you by Mountain Goat Software's Private Training for Agile transformations. Get your team on the same page through subject-specific training, coaching, and mentoring. For more information, visit the Mountain Goat Software’s Private Training page. [28:06] - Ken challenges the idea of a one-size-fits-all solution for dependency problems, cautioning about tool limitations. [30:25] - Ken proposes expanding the concept of working agreements to include inter-team arrangements. [33:55] - Ken highlights the misconception of solving external dependencies through internal escalation, stressing the limitations and challenges. [35:40] - Ken dispels the myth that identifying dependencies means solving the problem, emphasizing the need for control. [38:35] - Brian highlights the significant impact of waiting time, using the example of ordering a t-shirt online. [39:36] - Addressing flow problems in scaling challenges is crucial. [42:35] - Brian underscores the impact of addressing flow issues and promotes Ken's upcoming one-day live online course, Dependencies are Killing Your Agility: Learn to Fight Back! on March 14th [43:24] - Brian highlights the value of Ken's insights on dependencies and provides helpful resources and links. [43:50] - Brian thanks listeners and invites them to share and subscribe to the Agile Mentors Podcast on Apple Podcasts. [47:26] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, such as CSM or CSPO. We also have Advanced Certified ScrumMaster® and Advanced Certified Scrum Product Owner®. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here. [48:12] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. References and resources mentioned in the show: Dependencies are Killing Your Agility: Learn to Fight Back! Essential Scrum by Kenneth Rubin Innolution Dependencies Are Killing Your Agile Flow at Scale by Ken Rubin #47 Exploring Lean Thinking In Agile Development with Bob Payne Subscribe to the Agile Mentors Podcast on Apple Podcasts Mountain Goat Software’s Private Training Certified ScrumMaster® Training and Scrum Certification Certified Scrum Product Owner® Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Ken Rubin is the #1 best-selling author of Essential Scrum and world-renowned Agile trainer and coach. Ken focuses on full end-to-end business agility, applying agile ways of working with your development teams, technical and business leaders, executives, as well as the important non-development groups that are critical to providing your whole product solutions.

In this episode we unpack the eighth commitment of the Code of Ethical Conduct for Agile Coaching: Managing differences in status and power. We uncover the thinking behind the section, its inclusion in the Code of Ethic and its application in coaching.   About the Featured Guest Georgina has an expansive 20+ global IT career having worked in Australia, London and the US in IT, telecommunications, banking, sales and marketing. She specializes in designing agile enterprise organizations by bringing together design, development and go-to-market teams to operate seamlessly. She also enjoys being an executive strategic advisor and coach.    Follow Georgina on LinkedIn (https://www.linkedin.com/in/georginapuli/)   Mishkin Berteig is an Agile pioneer and Certified Scrum Trainer. He co-founded BERTEIG, transforming work environments. Now as CEO of MaxGood.work, he merges human potential and AI. Advocating love as the change driver and truth as progress's base, he infuses these values into his work.   Follow Mishkin on LinkedIn (https://www.linkedin.com/in/mishkinberteig/) Follow Mishkin on Twitter @mberteig (https://twitter.com/mberteig)   Reference(s) Code of Ethical Conduct for Agile Coaching https://www.agilealliance.org/resources/initiatives/agile-coaching-ethics/ The Righteous Mind: Why Good People Are Divided by Politics and Religion by Jonathan Haidt Lessons in Chemistry by Bonnie Garmus Paper Constellations, a tool from Organization & Relationship Systems Coaching (ORSC)   The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared.   Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org    Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg    Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile.   About our Hosts Renae Craven has been coaching individuals, teams and organizations for over 13 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel https://www.youtube.com/@renaecraven. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn (https://www.linkedin.com/in/renaecraven/).  About our Sponsor Scrum.org is the Home of Scrum, founded in 2009 by Scrum co-creator Ken Schwaber focused on helping people and teams solve complex problems by improving how they work through higher levels of professionalism. Scrum.org provides free online resources, consistent experiential live training, ongoing learning paths, and certification for people with all levels of Scrum knowledge. You can learn more about the organization by visiting www.scrum.org.

Introducing The Agile Coaching Skills - Certified Facilitator Workshop! FACILITATORS ARE IN VERY HIGH DEMAND!! Facilitation supports groups of people as they collaborate, create, and make decisions. The Agile Coaching Skills - Certified Facilitator (ACS-CF) course provides training for anyone interested in developing their facilitation mindset and knowledge while learning from experienced agile practitioners. Completing this course is also a way forward on the path for those who want to become Certified Agile Coaches or Trainers. Facilitation is one of the many tools essential to coaching, and this course will equip you to develop and hone the skill. This certification is new and we are in the process of adding more classes. If you don't see a course in your area, please email LearnMore@AgileDad.Com and we can get a course lined up for your organization. Learning objectives: Discover what a facilitator is and what they do Practice the mindset of a neutral facilitator Learn how to facilitate teams through conflict Understand the needs of different teams Apply the skillset before, during, and after a facilitation event This course is designed to: Make sure all voices are heard. Establish psychological safety. Create better meetings. If you're passionate about facilitation, the ACS-CF course lets you follow your passion so you can make a real difference. Many careers, industries, and teams need people who know how to facilitate. The ACS-CF course is right for: Anyone who wants to be an empowering and impactful facilitator Anyone interested in growing their career with facilitation skills Anyone who believes in happier teams and better meetings Benefits of the certification: Deep dive of an in-demand skill that goes beyond technique alone and explores the mindset of a facilitator Live, immersive facilitation practice Scrum Alliance-approved agile instructor V. Lee Henson delivering the material Contributes to evidence of facilitation experience when you apply to become a CEC, CTC, or CST 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 conversation Renae and Vinnie explore their common love of Pilates and the alignment between Agile and Pilates. About the Featured Guest Vinnie Gill puts people and culture first. She enjoys connecting with people and companies to find their purpose, walking alongside them in their organizational growth journey. Her passion is influencing change at the Enterprise level. She is deeply involved in the Agile community, speaks at international conferences and has a special interest in educating and education being the tool that empowers people. Follow Vinnie on LinkedIn References Pilates for the Office Worker series  The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org  Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg    Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile.   About our Host Renae Craven has been coaching individuals, teams and organizations for over 13 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel Crave Pilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn   About our Sponsor Scrum.org is the Home of Scrum, founded in 2009 by Scrum co-creator Ken Schwaber focused on helping people and teams solve complex problems by improving how they work through higher levels of professionalism. Scrum.org provides free online resources, consistent experiential live training, ongoing learning paths, and certification for people with all levels of Scrum knowledge. You can learn more about the organization by visiting www.scrum.org.

Are you part of a struggling Agile team? Join Mike Cohn and Brian Milner in this episode as they uncover the primary signs of a team in distress. Listen in as they share the common causes of underperforming teams, and what to do to boost morale, enhance collaboration, and transform your Agile team from struggling to thriving! Overview What is the primary sign of a struggling Agile team? It's when the energy in the room feels like a deflated balloon, and laughter is a distant memory. In this episode of the Agile Mentors Podcast, Brian Milner and Mike Cohn of Mountain Goat Software help listeners identify the signs of a struggling Agile team and the common culprits. Listen in as they unveil the key principles of cultivating a positive work environment and the vital importance of addressing CYA behavior. Plus, they share their top-notch tips on boosting team morale and enhancing collaboration, all while preventing unfinished projects and ensuring consistent delivery. Tune in to transform your Agile team from struggling to thriving! Listen Now to Discover: [01:23] - Brian welcomes back Mike Cohn to the show to discuss how to identify the signs that your team is struggling and what to do about it. [01:54] - Common causes of unfinished work. [04:45] - Do developers use Scrum as an excuse to be lazy? No—that’s rare but can be easily corrected. [07:36] - How to manage underperforming teams. [09:04] - Teams that lack excitement and laughter may be struggling. Work should be fun and enjoyable. How to create a positive work environment. [10:32] - How to break the habit of rolling unfinished work forward. [12:44] - The power of small wins to improve job satisfaction. [14:12] - How to boost morale and deliver small wins that create a sense of accomplishment. [14:30] - The Agile Mentors Podcast is brought to you by Mountain Goat Software and their Certified Scrum Training Classes. Whether you want to be a Scrum Master, Product Owner, or even take an advanced certification, all courses are designed to give you the skills that agile teams and organizations value so you’ll stand out in the market. For more information click on the Mountain Goat Software Certified Scrum and Agile Training Schedule. [15:35] - What CYA is really telling you about your team. [16:59] - The role of managers in creating an environment of openness and collaboration [19:03] - How individualistic behavior—working in isolation, not collaborating—hinders teamwork. [21:08] - Introducing Swarming—a horrible way to work, you’ll get less done—but a great drill to help teams discover new ways to collaborate. [27:54] - Thank you to Mike Cohn for joining us on the show. [28:18] - Please share this episode with others if you found it useful. Send feedback and suggestions for future episodes to podcast@mountaingoatsoftware.com. And don’t forget to subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode. [27:54] - If this topic was impactful to you and you want to continue the discussion, join the Agile Mentors Community, where we have a topic discussion for each podcast episode. References and resources mentioned in the show: #70: The Role of a Leader in Agile with Mike Cohn #39: The Art of Writing User Stories with Mike Cohn Subscribe to the Agile Mentors Podcast on Apple Podcasts Certified ScrumMaster Training and Scrum Certification Certified Scrum Product Owner Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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.

In this episode Chithra and Steve unpack commitment 7 of the Code of Ethical Conduct for Agile Coaching; Agreeing on Boundaries and the challenges that Coaches can have when establishing boundaries with their clients.  About the Featured Guests Chithra Ramachandran is a technologist at heart, offering over 19 years of software product development experience, leading global technology teams and delivery of impact oriented high value programs. As a lead Coach in her role, Chithra loves designing coaching interventions, workshops for Lean-Agile DevOps Transformations & Code Craftsmanship.   Steve Hoyler serves non-profit organisations, NGOs, companies, and teams on a mission. He's an agile coach, facilitator, speaker & penguins' friend helping organisations hone collaboration & agile practice. He's helped environmental activists, conservationists, late-stage pharmaceutical drug developers, product teams & computer system developers. Based in Switzerland, he works in Europe and Africa. Follow Chithra on LinkedIn  Follow Steve on LinkedIn Reference(s) Code of Ethical Conduct for Agile Coaching https://www.agilealliance.org/resources/initiatives/agile-coaching-ethics/ The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org    Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg  Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile.   About our Host Renae Craven has been coaching individuals, teams and organizations for over 13 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel Crave Pilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn (https://www.linkedin.com/in/renaecraven/).    About our Sponsor Scrum.org is the Home of Scrum, founded in 2009 by Scrum co-creator Ken Schwaber focused on helping people and teams solve complex problems by improving how they work through higher levels of professionalism. Scrum.org provides free online resources, consistent experiential live training, ongoing learning paths, and certification for people with all levels of Scrum knowledge. You can learn more about the organization by visiting www.scrum.org.

Discover the mindset and courage it takes to be truly agile. Listen in as Ryan Gottfredson sits down with Brian to explore the four common fears that hinder agility. In this episode of the Agile Mentors Podcast, Ryan Gottfredson, an expert on the psychology of agility and author of the bestselling book "Success Mindsets," sits down with Brian to explore the four common fears that hinder agility. Listen in as Brian and Ryan walk listeners through examples of how these fears manifest in the workplace, sharing valuable insights on how recognizing and reshaping your mindset can lead to more effective agile, and more personal and professional growth. Listen Now to Discover: [01:18] - Brian introduces his guest, Ryan Gottfredson, a leadership and management professor at the College of Business and Economics at California State University, Fullerton to walk us through his talk from Agile 2023 in Orlando called The Four Fears that Undermine Agility. [06:07] - Brian reflects on the evolving understanding of agility as one progresses in their Agile journey, emphasizing the importance of interpersonal dynamics and human psychology in Agile work. [07:47] - The mindset and courage it takes to be truly agile. [09:23] - Ryan offers up some indicators of agility. [10:11] - Ryan introduces the four fears that undermine agility. [12:02] - How fear of failure and reluctance to try new things can lead to resistance to change, ultimately undermining agility. [12:16] -The importance of leadership in fostering agility with an example of Satya Nadella at Microsoft. [15:03] - Ryan discusses the first fear inhibiting agility, the fear of failure, and how it can significantly impede agility. [15:27] - The conversation then delves into the second fear, the fear of being wrong, and how this fear can obstruct agility by hindering the acceptance of diverse perspectives. [17:03] - The Agile Mentors Podcast is brought to you by Mountain Goat Software and their Certified Scrum Training Classes. These classes were designed and developed by the Co-founder of the Scrum Alliance, Mike Cohn. Mike taught his first Scrum class in 1997, and since then, more than 24,000 people have chosen to train with Mountain Goat Software. To join them, click on the Mountain Goat Software Certified Scrum and Agile Training Schedule. [18:13] - Is your expert mindset holding you back? Brian and Ryan explore the importance of shifting from an expert mindset to a truth-seeking mindset to foster agility by being open to the possibility of being wrong. [20:04] - Brian shares a personal experience related to the "no estimates" movement.v [21:28] - The value of conversations that focus on embracing the complexities of a topic. [22:09] - Ryan introduces the third fear inhibiting agility, the fear of having problems. Ryan shares an analogy of reacting to a mouse like it's a bear to illustrate his point. [24:29] - The "window of tolerance" for handling problems effectively. [25:43] - Ryan explains the fourth fear that hinders agility, the fear of getting passed up or not being recognized. [26:22] - The difference between a limited mindset, and a more open mindset that acknowledges the value of giving and sharing. [27:10] - Ryan shares a real-life example of an executive who initially shut down his employees' ideas to keep from being viewed as dispensable. [28:23] - Ryan reflects on the prevalence of these fears in organizations, and how they can collectively hinder agility. [30:03] - Ryan shares the four mindsets related to the four fears: fixed vs. growth, closed vs. open, prevention vs. promotion, and inward vs. outward. [31:33] - Brian thanks Ryan for sharing his insights on the show. You can find Ryan’s mindset assessment on his website, Ryan Gottfredson. You can also find his book, "Success Mindsets," or take his FREE Personal Mindset Assessment on his website or connect with him via LinkedIn. [36:45] - We invite you to subscribe to the Agile Mentors Podcast on Apple Podcasts. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. And if you’d like to continue this discussion, join the Agile Mentors Community. References and resources mentioned in the show: Ryan Gottfredson Success Mindsets by Ryan Gottfredson Ryan Gottfredson on LinkedIn Ryan's talk from Agile 2023 Ryan Gottfredson's FREE Personal Mindset Assessment #33 Mob Programming with Woody Zuill Subscribe to the Agile Mentors Podcast on Apple Podcasts Certified Scrum Master Training and Scrum Certification Certified Scrum Product Owner Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. ● Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. ● Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Ryan Gottfredson, Ph.D., is a renowned mindset expert, author, and consultant. Through his work at California State University-Fullerton, his talk called, The Four Fears that Undermine Agility, and his bestselling book "Success Mindsets," Ryan helps organizations and leaders thrive through mindset improvement.

In this conversation Karen shares her story of how she went from ‘Fancy Karen' to Karen who is now living her best life, one that she never imagined she could. Karen shares how she quit her full time employment and the life she now leads.    About the Featured Guest After working in a few companies doing Scrum, in 2012 Karen Greaves started Growing Agile with Sam Laing to fulfill their dream of helping more companies become agile. In 2018, Karen moved to New Zealand and started a new chapter working internally in organizations. In 2022 Karen quit working full time, sold nearly everything she owned and started living fulltime in a van.   Follow Karen on LinkedIn (https://www.linkedin.com/in/karengreaves/) Follow Karen on Twitter (@karen_greaves) Follow Karen's van life on Instagram (@nakedtruth_vanlife)   References Conscious Business. How to Build Value Through Values by Fred Kofman https://www.fredkofman.org/lec-ing.php Digital Minimalism by Cal Newport https://www.amazon.com/Digital-Minimalism-Choosing-Focused-Noisy/dp/0525536515   The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared.   Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org    Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg    Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile.   About our Host Renae Craven has been coaching individuals, teams and organizations for over 13 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel Crave Pilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn (https://www.linkedin.com/in/renaecraven/).    About our Sponsor Scrum.org is the Home of Scrum, founded in 2009 by Scrum co-creator Ken Schwaber focused on helping people and teams solve complex problems by improving how they work through higher levels of professionalism. Scrum.org provides free online resources, consistent experiential live training, ongoing learning paths, and certification for people with all levels of Scrum knowledge. You can learn more about the organization by visiting www.scrum.org.

Today, Brian sits down with Melissa Boggs to explore the parallels between roller skating and workplace challenges as she shares her four-stage framework for personal and professional growth. Overview Today, on the Agile Mentors Podcast, Brian sits down with Melissa Boggs, host of the Wild Hearts at Work podcast to explore the parallels between roller skating and workplace challenges. Listen in as Melissa shares her experiences in the rink and in the workplace as she introduces her four-stage framework for personal and professional growth and the essential mental preparation required to embrace audacity and approach challenges with courage and curiosity. Listen Now to Discover: [01:33] - Brian introduces Melissa Boggs, a keynote speaker, leadership coach, and the host of the Wild Hearts at Work podcast to discuss moving from caution to courage. [03:57] - Melissa shares where the resistance to Agile concepts comes from and the inspiration for the Wild Hearts at Work podcast. [05:44] - The parallels between Melissa's roller skating journey and workplace challenges and how the distinct stages of personal and professional growth inspired her talk, "From Cautious to Courageous: A Live Roller-Skating Journey." [06:47] - Melissa introduces the fourth container, audacious, emphasizing the willingness to make dramatic and transformative moves to make major changes. [08:05] - The true meaning of audacity. [09:03] - Melissa walks listeners through the journey from cautious to audacious by fearlessly facing challenges that are bigger than you. [11:17] - The Agile Mentors Podcast is brought to you by Mountain Goat Software. If you want to get your Certified Scrum Product Owner Training or another certified training, here is the Mountain Goat Software Certified Scrum and Agile Training Schedule. [11:45] - How to distinguish between a growth opportunity or genuine danger. [13:58] - Melissa emphasizes the importance of the "Curious" stage in her framework, to tap into your intuition when transitioning from cautious to courageous. [14:30] - Melissa shares a specific example from her skating experience, highlighting the role of curiosity in addressing her caution and fear when attempting a challenging move. [15:06] - Melissa shares the elusive puzzle piece that was the final piece of her framework to show up, shedding newfound clarity on the journey from caution to audacity. [17:19] - “Danger Will Robinson.” The importance of exploring the reasons behind discomfort and discerning when it's a valid response. [20:51] - Identifying the true source of a fear to gain control over it—the role of reason in guiding human actions. [22:02] - The danger of remaining perpetually in the caution container. [22:51] - Brian shares a pivotal moment in his journey to become a CST (Certified Scrum Trainer) and the importance of acknowledging setbacks and mistakes when they occur in order to move forward. [25:08] - How jam skating can help you learn to fall gracefully. Melissa underscores the mental preparation involved in facing challenges. [28:14] - Brian sends a special thanks to Melissa Boggs. To continue the discussion, join the Agile Mentors Community. [29:07] – We invite you to subscribe to the Agile Mentors Podcast on Apple Podcasts. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. References and resources mentioned in the show: Wild Hearts at Work podcast Melissa Boggs Melissa Boggs on LinkedIn The Audacity of Hope: Thoughts on Reclaiming the American Dream Subscribe to the Agile Mentors Podcast on Apple Podcasts Certified Scrum Master Training and Scrum Certification Certified Scrum Product Owner Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Melissa Boggs is an Agile advocate with experience serving on the Boards of Scrum Alliance and Agile Denver and serving as a keynote speaker at several global conferences. As a Certified Enterprise Coach and the host of the Wild Hearts at Work podcast, she specializes in bridging generational, cultural, and societal gaps to enhance workplace engagement.

In this episode we unpack section 3 of the Code of Ethical Conduct for Agile Coaching;  Introspection and Continuing Professional Development.  Together we explore the importance of remaining curious about our abilities as coaches and how the community can help with that. About the Featured Guests Theresa Given discovered Scrum and Agile ten years ago. She has been exploring and experimenting since. Tere enjoys the world of possibilities; she's tried each Scrum accountability, tested multiple Agile practices, worked in varied industries across public, private and non-profit sectors. Currently, she coaches new Scrum Masters to explore their role and achieve greater efficacy with their teams. Dave Prior has been leading technology projects for over 20 years. His journey from waterfall to Agile was not an easy one and he shows up every day with one simple goal: “...make the journey from waterfall to Agile suck less for others than it did for me." Dave has been podcasting since 2008 and produces LeadingAgile's SoundNotes and drunkenPM Radio's Reluctant Agilist. Follow Tere on LinkedIn  Follow Dave on LinkedIn  Follow Dave on Twitter (@mrsungo)   Reference(s) Code of Ethical Conduct for Agile Coaching https://www.agilealliance.org/resources/initiatives/agile-coaching-ethics/ Drunken pm radio Podcast https://soundcloud.com/drunkenpmradio The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org  Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg    Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile.   About our Hosts Renae Craven has been coaching individuals, teams and organizations for over 13 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel Crave Pilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn (https://www.linkedin.com/in/renaecraven/).    About our Sponsor Scrum.org is the Home of Scrum, founded in 2009 by Scrum co-creator Ken Schwaber focused on helping people and teams solve complex problems by improving how they work through higher levels of professionalism. Scrum.org provides free online resources, consistent experiential live training, ongoing learning paths, and certification for people with all levels of Scrum knowledge. You can learn more about the organization by visiting www.scrum.org.