Podcasts about daily scrum

Yuval Yeret, founder of Yeret Agility and OG Agile expert, joined me on Ditching Hourly to discuss the current state of Agile as a platform, how it has evolved over the years, and what practitioners should consider when pivoting their careers as the platform matures.About YuvalYuval Yeret is a Product/Scaling/Agility Coach focused on helping product/tech leaders scale their organizations without slowing down, improving outcomes by leveraging flow, agility, and product orientation. (while avoiding the dogma and process BS of Agile Theater). Yuval is a globally recognized expert on scaling w/ agility, a SAFe Fellow, a Professional Scrum Trainer, and a co-author of the Kanban Guide for Scrum Teams. These days Yuval is focused on helping organizations evolve from Feature Factories to Empowered Product Organizations, as well as helping deeper tech organizations develop a pragmatic agility strategy. Yuval shares his insights on scaling w/ agility at https://yuvalyeret.com/scaling-with-agility-newsletter/Chapters(00:00) - Introduction and Guest Welcome (00:17) - Yuval's Background and Journey into Agile (01:35) - Early Days of Agile (03:56) - Transition to Consulting and Coaching (07:21) - Agile's Evolution and Current State (09:46) - Challenges and Criticisms of Agile (17:30) - Future of Agile and Role Adaptation (22:18) - Advice for Agile Practitioners (30:22) - Reflecting on Agile Leadership (31:24) - Anecdote: Transition from FileMaker to Web Development (34:57) - The Future of Agile and Product Operating Models (39:20) - Adapting Skills for New Opportunities (41:48) - Navigating Organizational Change (44:47) - Strategies for Career Pivoting (48:01) - The Role of Scrum Masters in Modern Organizations (52:00) - Consulting and Value Proposition (57:55) - Closing Thoughts and Resources Notable Quotes"What happened over the years is... agile has become mainstream for most of corporate America, technology organizations and product companies. And this created the reality where the people that are, the organizations that are currently adopting agile are the late adopters.""[Late adopters] are slapping names like Scrum Master and Sprint and User Story and Daily Scrum... on the way that they've been doing things already. And it's like lipstick on a pig. It's not really creating any impact other than a bad name for Agile and a bad name for people in these roles.""The biggest issue with Agile... is the over-reliance on specific roles in organizations.""We will have a significantly smaller number of people that dedicate their career to something like agile, whatever it's called. You will need to specialize. You will need to start to think like consultants need to start to think and build your content solar system."Yuval's Links and Other ResourcesYuval's article on "The Future of Agile Roles and Agility"Yuval's private podcast on navigating the landscape of Agile theater, feature factories, and product operating models"Crossing the Chasm" by Geoffrey Moore (book on technology adoption)Netflix culture book (featuring the "Netflix question")The career mini-course that Jonathan mentioned: Unblock Your Career by Shachar Meir ----Do you have questions about how to improve your business? Things like:Value pricing your work instead of billing for your time?Positioning yourself as the go-to person in your space?Productizing your services so you never have to have another awkward sales call or spend hours writing another custom proposal?Book a one-on-one coaching call with me and get answers to these questions and others in the time it takes to get ready for work in the morning.Best of all, you're covered by my 100% satisfaction guarantee. If at the end of the call, you don't feel like it was worth it, just say the word, and I'll refund your purchase in full.To book your one-on-one coaching call, go to: https://jonathanstark.com/callI hope to see you there!

Anuj Ojha: Transforming Agile Team Meetings, Less Time, More Value Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. When Anuj started working with a team that believed asynchronous communication could replace their Daily Scrum, it sparked a journey of meaningful transformation. The team was frustrated with meeting overload and took bold steps to evaluate and modify their meeting structure. They questioned the value of Sprint Reviews and Retrospectives, ultimately creating a more focused approach to meetings. A significant breakthrough came when they removed managers from the Daily Scrum, leading to more effective communication and increased quality time for actual work. The team's success came from creating a backlog of improvements and integrating these directly into their sprint work. Self-reflection Question: How might your team benefit from critically evaluating your current meeting structure and making bold changes? Featured Book of the Week: The Five Dysfunctions of a Team by Patrick Lencioni The Five Dysfunctions of a Team by Patrick Lencioni was a game-changer for Anuj, offering a model for understanding team dynamics. The author's five-level model proved especially valuable during challenging periods, providing insights applicable to teams across all domains. The book's framework helped Anuj better understand and address the fundamental dysfunctions that teams commonly face. [The Scrum Master Toolbox Podcast Recommends]

Three Ways To Refocus In Your Daily Scrum - Standup 1) Actually Stand Up 2) Socialize with Another Human Being 3) Take the Time to Practice Being Creative How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

In this episode of Drunken PM Radio, Dave Prior discusses how to make daily standups more effective for teams that feel they are merely status calls. He shares ten actionable suggestions to enhance the value of these meetings, emphasizing the importance of collaboration, preparation, and maintaining a focused and respectful environment. The conversation also touches on the need for team members to take responsibility for their contributions and the dynamics of remote work. Takeaways • Daily standups should foster conversation, not just status updates. • Avoid rigid structures like the three questions in standups. • Team members should update their work status before the meeting. • Focus on collaboration rather than individual assignments. • Encourage camera use during virtual meetings for better connection. • Limit standup meetings to 15 minutes to maintain efficiency. • Rotate the facilitator to promote collective ownership. • Use inclusive language to reinforce team unity. • Preparation is key to a productive meeting. • Respect your teammates by being prepared and engaged. The Agile Netork's CONVERGE MicroConference January 27-27, 2025 Over 100 Sessions! Free Access During The Conference! Use Discount Code DRUNKENPMCMC33 for 33% of Membership to The Agile Network https://theagilenetwork.com/

O que não fazer em uma Daily Scrum: Dicas para uma reunião produtiva A Daily Scrum é um momento crucial para o alinhamento da equipe Scrum. Para garantir que essa reunião seja eficaz e produtiva, é importante evitar alguns comportamentos que podem prejudicar o seu objetivo. O que não fazer: Chegar atrasado ou não comparecer: A Daily Scrum é uma reunião diária e curta, por isso a pontualidade de todos os membros é fundamental. A ausência de alguém pode prejudicar a comunicação e a colaboração da equipe. Não se preparar: Antes da reunião, cada membro da equipe deve ter em mente o que fez no dia anterior, o que fará no dia seguinte e quais são os impedimentos que estão enfrentando. Isso garante que a reunião seja focada e objetiva. Falar demais: A Daily Scrum não é o momento para discussões longas e detalhadas. Cada membro deve se limitar a responder às três perguntas clássicas: O que você fez ontem? O que você fará hoje? Quais são seus impedimentos? Ser negativo: Um ambiente positivo e colaborativo é essencial para o sucesso da equipe. Evite comentários negativos ou queixas excessivas, pois isso pode desmotivar os outros membros. Não seguir as regras: A Daily Scrum tem um formato específico e um tempo limitado. É importante que todos os membros respeitem essas regras para que a reunião seja eficiente. Resolver problemas: A Daily Scrum serve para identificar os problemas, não para resolvê-los. Discussões longas sobre como solucionar um impedimento devem ser realizadas em outro momento. Usar a Daily Scrum como reunião de status: A Daily Scrum não é uma reunião de status para o cliente ou para a gerência. O foco deve estar no alinhamento da equipe e na identificação de impedimentos. Por que evitar esses comportamentos? Perda de tempo: Comportamentos como falar demais ou discutir problemas em detalhes podem prolongar a reunião além do tempo limite de 15 minutos, prejudicando a produtividade da equipe. Desmotivação: Um ambiente negativo ou falta de foco podem desmotivar os membros da equipe e prejudicar a colaboração. Falta de alinhamento: Se os membros da equipe não estiverem preparados ou não seguirem as regras, a reunião pode se tornar caótica e dificultar o alinhamento da equipe. Em resumo: A Daily Scrum é uma ferramenta poderosa para o sucesso do seu projeto. Ao evitar os comportamentos mencionados acima, você garante que a reunião seja produtiva e contribua para o bom funcionamento da sua equipe.

PILULA ÁGIL - Daily Scrum - Você sabe fazer uma?

9 Myths About The Daily Scrum Meeting The daily stand-up, also known as the daily huddle or Scrum meeting, is a cornerstone of agile practices. Despite its simplicity, this brief daily meeting is often misunderstood which can undermine its effectiveness. 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 our 100th episode, we dive into the vital role of stakeholders in Scrum. We explore who stakeholders are—anyone impacted by the team's work, like customers, internal leaders, or other teams—and why they matter. Weak product ownership can lead to building features that miss stakeholder needs, so we discuss balancing their involvement. While we encourage stakeholders to join sprint reviews, we caution against interference in meetings like the Daily Scrum. Transparency and communication are crucial to aligning expectations, and we highlight the product owner's role in managing requests and saying 'not yet' when needed. Join us as we share tips for managing your stakeholder relationships!

#5amMesterScrum Lightning Talk 1,229 Live - Scrum Masters use Daily Scrum as a Tool in your Coaching toolbox  (4R Thursdays) - Today's topics: (1) Continuing on from yesterday's show on Daily Scrum but this time from the Scrum Master Role point of view.  And how we can use the daily scrum when we coach people. 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,229 went live on Youtube, LinkedIn and Facebook 4R (Requirements, Reviews, Retros, Roles) Thursday 11/21/2024 from Philadelphia, PA  Happy Scrumming, Please Don't forget to sign up to our 5amMesterScrum newsletter for freebies.  Definitely a free copy of Change Volume 20 in PDF form.  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)

#5amMesterScrum Lightning Talk 1,228 Live -DAily Scrum is a Chance for the Team of Individuals to pull their heads out of the Sand of Individual Work (We Team & HR Wednesdays) - Today's topics: (1) Daily Scrum is an opportunity every day for individuals to see how the team is doing.  We are a diverse mindset and not everyone spends time seeing how the team is doing via chat or email or smoke signals. 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 Show 1,228 went live on Youtube, LinkedIn and Facebook We Team & HR Wednesday 11/20/2024 from Philadelphia, PA  Happy Scrumming, Please Don't forget to sign up to our 5amMesterScrum newsletter for freebies.  Definitely a free copy of Change Volume 20 in PDF form  Watch the video in our YouTube Library 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) 

What do you think about today's podcast?In this episode of the Agile Matrix podcast, host Temi dives deep into the Daily Scrum, a crucial agile event. Temi discusses the common pitfalls teams face during their daily scrums, such as turning it into a status meeting, going off-topic, and ignoring blockers. The episode emphasizes the importance of synchronizing efforts towards the sprint goal and provides practical strategies to improve the effectiveness of daily scrums. Temi encourages teams to focus on collaboration, maintain a time box, and address blockers promptly to transform their daily scrums into energizing and productive meetings.TakeawaysThe Daily Scrum is a 15-minute event for team synchronization.Avoid turning the Daily Scrum into a status meeting.Focus on the sprint goal during discussions.Use strategies like the parking lot method to stay on topic.Address blockers immediately to maintain team momentum.Daily scrums should be energizing and empowering for the team.Encourage collaboration rather than reporting.Time box the Daily Scrum to keep it effective.Elevate the importance of the sprint goal in conversations.The Scrum Master should facilitate, not dominate, the meeting.Support the showSupport the show via Patreon:https://www.patreon.com/TheAgileMatrixPodcastExplore our website to discover our comprehensive course and training schedule.https://www.agilematrix.org/upcoming-courses/Check out the Scrum Master Optimisation courses here: https://courses.agilematrix.org/collectionsInterested in Agile themed Shirts? Check out our store:https://www.etsy.com/shop/TemmieDesigns?ref=search_shop_redirect

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.

Neste episódio, Ricardo fala sobre o Daily Scrum, uma reunião curta de até 15 minutos, onde cada membro da equipe compartilha o que fez ontem, o que fará hoje e os obstáculos enfrentados. Ele destaca que essa prática, comum no Ágil, também é útil em projetos fora dessa metodologia, como na construção civil. Os principais benefícios são: melhora na comunicação, detecção antecipada de problemas, aumento da responsabilidade individual, decisões mais rápidas e foco no progresso diário. Ricardo incentiva o uso do Daily Scrum, independentemente da metodologia do projeto, por sua eficiência e simplicidade. Escute o podcast para saber mais.

What To Do When Your Team Says They Do Not Need The Daily Scrum? When your team pushes back against the daily stand-up, responding with thoughtfulness and adaptability is essential. The daily collaboration meeting, whether you call it a stand-up or something else, plays a crucial role in Agile success. However, it's not just about keeping the meeting-it's about ensuring it serves its true purpose of fostering alignment, communication, and collaboration. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

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

Peter Müller: Improving Scrum Daily Stand-Ups That Have Lost Focus And Become Long And Cluttered Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. When Peter took over a larger team, the daily stand-ups became cluttered with discussions that made the stand-ups long and unfocused. Stakeholders joined in, turning these meetings into mini-conferences that were even less focused. Peter initially thought he had a solution, but the team quickly reverted to old habits.  Does the Scrum Master need to step in to fix this anti-pattern? Or would it complicate things further? This episode dives into the nuances of managing a large team's dynamics and the importance of discerning which battles to fight. Peter shares crucial coaching tips, reflecting on why asking "why" might not always unearth the underlying issues. Discover how a solution-focused approach can redirect team efforts towards more productive outcomes.   [IMAGE HERE] Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story - How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company.   About Peter Müller Peter is a seasoned Agile coach and transformation consultant with extensive experience in fostering agile environments and enhancing team dynamics. His expertise in solution-focused coaching has helped numerous teams optimize their operational efficiency and adapt to agile methodologies effectively.   You can link with Peter on LinkedIn and connect with Peter on Twitter.

In this episode, we're joined by Ed Martin to discuss and debate the benefits and challenges of asynchronous daily scrum meetings. Listen as we explore the reasons teams may want to go async, potential pitfalls to avoid, and best practices to make async standups effective. If your team is struggling with async practices, listen as we explore ways to optimize your async workflow, including:The top reasons teams switch to async standupsAnti-patterns and pitfalls to watch out for Best practices and tools to enable effective async collaborationHow to maintain team alignment without meeting in real-timeLet us know your thoughts! Have you tried async standups with your team?#agile #scrum #remotework #asynccollaboration #productmanagement= = = = = = = = = = = =Watch it on YouTube= = = = = = = = = = = =Subscribe to our YouTube Channel:https://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1Apple Podcasts:https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596Spotify:https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3Amazon Music:https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast= = = = = = = = = = = =Toronto Is My Beat (Music Sample)By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Whether or not you are a fan of Star Trek, you've likely heard of the Captain of the U.S.S Enterprise asking some form of this question: “Engineering, status report?” or “Spock, status report?” (It's such a common trope that Season 2, episode 9 of Star Trek: Brave New Worlds, “Subspace Rhapsody,” features an iconic scene where the crew has encountered something that is making them all sing their status reports.)On a ship, even a spaceship, status reports are a quick and efficient way to check that all systems are running as expected or to report problems. On waterfall software projects, status reports often were an effective but often tedious way for a manager to update their Gantt chart to reflect the progress (or lack thereof) for each plan element.Unfortunately the idea of status reports is so embedded in our psyches that many people on agile teams treat a daily scrum as a time to give a status report to the Scrum Master.The daily scrum is meant to be a synchronization meeting for the whole team, not a status report solely for the benefit of the Scrum Master. So how did we end up here?I suspect some people missed the message that a daily scrum is an inspect and adapt activity for the team. And I wonder if the three traditional questions of the daily scrum are to blame as well. The template, “What did you do yesterday? What will you do today? Any blockers?” just sounds like a robotic status report Spock would give.Two Ways to Bring Sync Back to Daily ScrumsWant to break your team out of the status report mindset? Try these two tips.First, eliminate the three questions and experiment with structures that work for your team. At your next retrospective, tell the team you want to dispose of the three questions (and why). Remind them of the purpose of daily scrums: to inspect and adapt the team's progress. And that the goal is to make each daily scrum about synching their work, rather than reporting status, while staying inside the 15-minute timebox.Then invite the team to come up with experiments to try (like going PBI by PBI instead of person by person).Second, for one sprint try to avoid eye contact with anyone giving an update during a daily scrum, especially doing them in person. Making eye contact is human nature. When we speak, we make eye contact with someone. Many teams, especially those new to Scrum, will naturally look at the ScrumMaster when speaking rather than one another.By not making eye contact with someone giving an update, ScrumMasters can signal that the speaker should be talking to the rest of the team, rather than directly to the Scrum Master.If your daily scrums are so dull that the team is silently begging to be beamed up, you aren't alone. Bringing a collaborative spirit back to your daily scrums is one way to help your team succeed with agile. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Join Brian and Stefan Wolpers as they explore the labyrinth of Scrum anti-patterns, shedding light on the crucial shifts needed in communication, event understanding, and organizational empowerment for Agile success. Overview Brian welcomes special guest Stefan Wolpers as they explore the maze of Scrum anti-patterns. Discover the art of tackling communication breakdowns, unravel the misunderstandings that plague Scrum events, confront the systemic issues of organizational anti-patterns, and challenge the rigidity of dogmatism in Agile practices. Whether you're a seasoned Scrum practitioner or new to the Agile philosophy, this conversation between Brian and Stefan will arm you with the insights needed to navigate the complexities of Scrum, enhance team collaboration, and drive successful Agile transformations. Tune in to transform your understanding and practice of Scrum, and take a step towards mastering the dynamic world of Agile. Listen Now to Discover: [1:06] - ​​Join Brian as he sits down with Stefan Wolpers, a seasoned Professional Scrum Trainer and the mastermind behind ‘The Scrum Anti-Patterns Guide,’ for a deep dive into the pitfalls to avoid for Scrum success. [2:33] - Discover the power of inversion with Stefan, as he elucidates this groundbreaking learning principle, challenging traditional methods and revolutionizing our approach to personal and professional development. [5:21] - Stefan delves into the critical issue of communication breakdown and assumptions among teams, revealing effective strategies to address and navigate these common pain points. [10:01] - Listen as Stefan highlights the transformative impact of trust building and team bonding, revealing their significance as key elements in bridging cultural differences and bringing remote teams closer together. [12:02] - Brought to you by Mountain Goat Software, the Agile Mentors Podcast invites you to enhance your Scrum skills through the Certified Scrum Product Owner® course. Explore a world of Agile learning opportunities by checking out Mountain Goat Software's extensive training schedule. [13:03] - Join Stefan as he delves into the Scrum framework, highlighting the Daily Scrum and Sprint Planning as events ripe with anti-patterns, and providing guidance on overcoming these obstacles for smoother sprints. [18:10] - Listen as Stefan illuminates the critical anti-pattern of lacking empowerment within organizations, emphasizing its widespread impact and proposing pathways to cultivate a more empowered workforce. [22:08] - Explore with Brian the significance of an anti-dogmatic stance, highlighting its role as a pivotal anti-pattern in fostering innovation and adaptability in Agile environments. [26:14] - Brian shares a big thank you to Stefan for joining him on the show. [29:01] - If you’d like to continue this discussion, join the Agile Mentors Community. [30:01] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback, a question, or a great idea for an episode of the show? Great! Just send us an email. References and resources mentioned in the show: Stefan Wolpers The Scrum Anti-Patterns Guide by Stefan Wolpers Certified Scrum Product Owner® Training Mountain Goat Software Certified Scrum and Agile Training Schedule Mike Cohn’s Letting Go of Knowing Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Stefan Wolpers is the author behind "The Scrum Anti-Pattern Guide" and a celebrated Professional Scrum Trainer known for his unparalleled expertise in Agile methodologies. Stefan has dedicated his career to empowering professionals around the globe.

This week, Dan Neumann and Justin Thatil are joined by Rich Hundhausen for the second part of a deep conversation about Nexus. Rich is a software developer, Professional Scrum Trainer, and co-creator of the Nexus Framework for scaling Scrum.   In this episode, they dive deep into how to deliver value in the form of a working integrated increment of product, the role of the Integration Team, and the characteristics of each Nexus Event. They share valuable stories exemplifying how Nexus works for an improved scaling experience.   Key Takeaways Scale Scrum is still Scrum (plus additional features). The Nexus Integration Team is not in the original Scrum framework. The Integration Team is actually the Nexus's Scrum Master. This team is responsible for ensuring that Scrum is followed as established in the Scrum Guide and that its work is effective. The Integration Team works in a Scrum way by coaching, facilitating, teaching, and mentoring, but not hands-on (unless absolutely necessary). The Scrum Team's Developers do the work. The Integration Team does not do the integration, but it is accountable for it. Integration can mean lots of different things. Integration means solving any kind of dependency. The Nexus Integration Team does not have to meet daily but only when required. Everyone on the Integration Nexus Team has a daily job on the Scrum Teams and/or is the Product Owner, so when something does not go as planned, they bring it to the attention of the Integration Team when possible. The Nexus Events: First Event: Nexus Sprint Planning. This event aims to take another look at the upcoming work to ensure the organization of Teams and consider any last-minute changes. Big Room Planning takes place during this stage. All the planning at this moment is only for the current sprint (never beyond that). The output for the Nexus Sprint Planning is the Nexus Sprint Backlog for each Team, and the goal is to make any dependencies transparent to mitigate them daily. Scrum of Scrums: Scrum Team members are allowed to talk at any given moment. Second Event: The Nexus Daily Scrum. It is a Scrum of Scrums that occurs before the Daily Scrum. At this mandatory event, dependencies and integration issues are discussed. Third Event: The Nexus Sprint Review is where Stakeholders give feedback on the done increment but in a big room event. This event is the time to share feedback on potential cross-team work. The Last Event: The Nexus Sprint Retrospective. This event is an opportunity for the Scrum Team to inspect and adapt how they work, first through a pre-meeting with the representatives, then Teams have their individual retrospectives, and after, representatives meet again to make transparent any new experiments or improvements so the bottom-up intelligence can then be shared with the other Teams. There are around 60 complementary practices to Nexus (but none are new). Mentioned in this Episode: The Nexus Guide Listen to “Continuous Learning: Professional Scrum Facilitation Skills Training with Patricia Kong” and “The Nexus Framework for Scaling Scrum with the Scrum.org Team”   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

What do you do when your Scrum Master's understanding of their role seems to be less about acting as a servant leader to the Scrum Team and more about making the team to work in a way that is most convenient for them? In this episode of the podcast, Jeff Howey joins me to talk through the real-life case of a Scrum Master who seems to have lost their way. Here are some of the concerns shared in the podcast: - Dev Team is offshore and holds a Daily Scrum before 8 AM in Scrum Master's time zone. Scrum Master requires that they hold a second Daily Scrum to provide status to Scrum Master. - SM does not attend Sprint Planning. They require the PO to run it. - SM requires the PO to run the Retrospective. All topics must be submitted in advance of the meeting and must be positive comments (not negative). - Scrum Master does not like the way the Developers have set up their Task Board and requires that they change it to a format that works better for the Scrum Master. During the conversation, Jeff and I unpack these and a number of additional concerns, talk through how they are out of alignment with Scrum and the role of the Scrum Master, and discuss suggestions we'd offer to help reset the understanding of what it means to be a Scrum Master who acts as a servant leader for a Scrum Team. If you'd like to contact Jeff Howey. LinkedIn: www.linkedin.com/in/jeffhowey/ Newsletter: https://www.linkedin.com/newsletters/the-agile-alchemist-7018992829091778560

The Daily Scrum Defined - What does the Scrum Guide say about the daily Scrum? The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management. Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings. The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint's work. How to connect with AgileDad: - [website] ⁠https://www.agiledad.com/⁠ - [instagram] ⁠https://www.instagram.com/agile_coach/⁠ - [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠ - [Linkedin] ⁠https://www.linkedin.com/in/leehenson/⁠

This week, Dan Neumann is joined by his colleague, Phillip Lisenba. In this episode, they explore the value that a Scrum Master can provide. Often, organizations reach a moment in their transformation when they question whether or not a Scrum Master is needed and how significant their role is. Listen to Dan and Phillip diving deep into the heart of the role of a Scrum Master and how it is essential for an organization's success.   Key Takeaways The Scrum Master Role: The primary purpose of a Scrum Master is not administrative; it is to empower and help the Team self-organize and self-manage. In a Daily Scrum, a Scrum Master is optional. A Scrum Master should do more coaching from the back of the room than he does from the front. The Scrum Master empowers the Team to the point where they run the meetings independently. At the beginning of his career, a Scrum Master can tend to do all administrative tasks and more to prove his value but later realizes his job is to empower the Team and set it up for success even when he is not around. The Scrum Master role also reminds the Team that they are all together, not about pointing fingers but solving problems together. Servant Leadership: A Scrum Master must know how to influence the Team while serving them. A Scrum Master finds ways to improve continuously. The Team wants to create what the customer requested and innovate on the architecture to support that. Everyone needs to be on the same page and also be willing to pivot. A Scrum Master needs to know the Team's needs: What does the Team need? More ownership? More Process? How do we know if the Team is actually improving? Don't confuse activity with results. A Scrum Master should ask himself: Are we getting a good return on the investment? Are we getting increments of value? The importance of conducting a Sprint Review: The Sprint review is an opportunity for the Team to check on the work they delivered and work with the Product Owner, the business, and the stakeholders to verify they are receiving what they expected.   Mentioned in this Episode: Renew your certification at Scrum.org OKR Institute Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

Everyone agrees that in complex work, clear goals give guidance to what needs attention and what doesn't (right now). They also see how goals are the glue that binds individuals into a team by giving them a shared purpose. A shared goal gives Scrum teams focus on what is important during a Sprint while allowing flexibility to adjust course and avoid emerging obstacles as needed. Shared goals are the foundation of the Scrum framework. It is what pulls everything together, and gives meaning and purpose to everything that happens in Scrum. In addition to a Sprint Goal, we would also define a daily goal. These teams not only focused each Sprint on one Sprint Goal, but they also identified one daily goal for the entire team, each day! Seems impossible? Maybe… But it's definitely worth a try. It's a great way to improve collaboration, focus, and commitment. In general, it's a perfect booster for team morale. It's probably not difficult to find reasons why this won't work for your team, but those reasons might also be symptoms of deeper problems in your team. How to connect with AgileDad: - [website] ⁠https://www.agiledad.com/⁠ - [instagram] ⁠https://www.instagram.com/agile_coach/⁠ - [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠ - [Linkedin] ⁠https://www.linkedin.com/in/leehenson/⁠

Here are the 5 symptoms: Your ScrumMaster has become the Master of Ceremonies and is speaking WAY too much: When the ScrumMaster puts on a glitter jacket and or has a bedazzled microphone, this is your sign that they have taken things WAY too far. It is important that the SM work closely with the Development Team to drive value, but they also must be in control without saying many words. Monologues Over Dialogues: Are team members simply reporting their updates, or are they engaging in a discussion? The Daily Scrum should encourage interaction, not just broadcasting. Problem-Solving Takes a Backseat: The Daily Scrum is a platform to highlight and assign ownership to problems, not necessarily to solve ALL of them completely. If it can be solved in 30 seconds or less, do not call for another meeting... Solve the freaking problem! If issues are merely reported but not addressed, the meeting isn't serving its purpose. Attendance and Engagement Dwindles: If team members are regularly missing the meeting or not actively participating, it's an indication that they don't see value in it, signaling that changes are needed. Misconception of the Meeting's Purpose: If the Daily Scrum has turned into a status report to the Product Owner or the Scrum Master, it's a clear sign that the meeting has strayed from its purpose. The Daily Scrum is for the Development Team to synchronize their efforts and plan their work, not to report progress to the Product Owner or the Scrum Master. 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 session of Ask A Professional Scrum Trainer, Lavaneesh Gautam answers questions about the Daily Scrum, performance measurement, facilitating the Sprint Retrospective, Scrum with Kanban and more!

Thank you all for watching To sign up for my upcoming coaching program- click here .https://www.scrummasteryplaybook.com/courses/copy-of-scrum-mastery-playbook-course-1#agile #scrum #scrummaster #agilecoaching if you have any questions, kindly drop in the comment section or send an email to onlineagilecoach@gmail.com if you want to connect on other platforms, we are on LinkedIn and Instagram IG: @youragilecoach LinkedIn- Yinka Okunlade

5 Keys to Keep Your Daily Scrum On Track Time-boxed: The meeting is time-boxed to a maximum of 15 minutes. This encourages team members to stay focused and to keep their updates concise and relevant. 30 seconds per person not to exceed 15 minutes. Daily: The meeting is held daily, typically at the same time and place. This helps to establish a routine and keeps the team on track. Stand-up: The meeting is conducted while standing up, which helps to keep the meeting brief and focused. (Plank is an option) Three Questions - The meeting typically follows a set format, where each team member answers three questions. Focus on Collaboration: The meeting is designed to encourage collaboration and communication within the team. Team members are encouraged to ask questions and offer help to their colleagues.

The latest episode of the Truest Fan Podcast is all about the importance of great leadership when it comes to building a successful team. Co-hosts Rob Brown and Phil Calandra share their insights on this topic, which was inspired by a listener's inquiry on how to improve team performance. In today's world, with everything that's going on around us, there's an unusual amount of tension and uneasiness. So it's crucial to assess how these factors are affecting your team members. As a business leader, you may not always be the one handling client inquiries and concerns - that's where your team comes in. So, when they feel overwhelmed by these challenges, it's up to you to step up and provide strong leadership. Remember, your team's reaction to challenging times is heavily influenced by how you respond. When you appreciate and value your team, it motivates them to do their best and work towards achieving success. That's why practices like daily scrums and leadership by walking around can make a big difference in strengthening teamwork and overall business operations. Podcast highlights the importance of regularly recognizing team members, the impact of steady leadership, and the benefits of implementing daily routines for fostering better teamwork. So, give it a listen and take away some valuable insights on how to lead your team to success! Show Highlights: Why it's important to understand your team's response to difficult times [01:50] The value of leadership by walking around [05:20] The impact of great leadership and appreciating each team member  [08:20] Daily Scrum and how it strengthens teamwork [11:45] Start the 7-STEP "QUICK START" CHALLENGE Connect with Phil CalandraConnect on LinkedIn https://www.linkedin.com/in/phil-calandra-79425a26/ Connect with Rob Website: http://truestfan.com/ Connect on Facebook https://www.facebook.com/truestfan Connect on LinkedIn https://www.linkedin.com/in/truestfan/ For more information go to: truestfan.com

The latest episode of the Truest Fan Podcast is all about the importance of great leadership when it comes to building a successful team. Co-hosts Rob Brown and Phil Calandra share their insights on this topic, which was inspired by a listener's inquiry on how to improve team performance. In today's world, with everything that's going on around us, there's an unusual amount of tension and uneasiness. So it's crucial to assess how these factors are affecting your team members. As a business leader, you may not always be the one handling client inquiries and concerns - that's where your team comes in. So, when they feel overwhelmed by these challenges, it's up to you to step up and provide strong leadership. Remember, your team's reaction to challenging times is heavily influenced by how you respond. When you appreciate and value your team, it motivates them to do their best and work towards achieving success. That's why practices like daily scrums and leadership by walking around can make a big difference in strengthening teamwork and overall business operations. Podcast highlights the importance of regularly recognizing team members, the impact of steady leadership, and the benefits of implementing daily routines for fostering better teamwork. So, give it a listen and take away some valuable insights on how to lead your team to success! Show Highlights: Why it's important to understand your team's response to difficult times [01:50] The value of leadership by walking around [05:20] The impact of great leadership and appreciating each team member  [08:20] Daily Scrum and how it strengthens teamwork [11:45] Start the 7-STEP "QUICK START" CHALLENGE Connect with Phil CalandraConnect on LinkedIn https://www.linkedin.com/in/phil-calandra-79425a26/ Connect with Rob Website: http://truestfan.com/ Connect on Facebook https://www.facebook.com/truestfan Connect on LinkedIn https://www.linkedin.com/in/truestfan/ For more information go to: truestfan.com

60 Second Sprints on The 5 Scrum Events... Ready? GO! The first event is the Sprint. The Sprint is a time-boxed period where the team works to deliver a potentially releasable product increment. A Sprint usually lasts between one and four weeks. During the Sprint, the team plans, designs, develops, and tests the product increment. The Sprint is a crucial event because it provides a fixed time frame for the team to work within and allows them to focus on delivering a specific set of features. The second event is Sprint Planning. Sprint Planning is a time-boxed meeting where the team plans the work they will do during the upcoming Sprint. During this meeting, the team decides what items from the Product Backlog they will work on and how they will achieve their Sprint Goal. The Sprint Goal is a statement that describes what the team will accomplish during the Sprint. Sprint Planning helps the team understand what they need to do and how they will do it. The third event is the Daily Scrum. The Daily Scrum is a daily meeting where the team comes together to plan their work for the day. During this meeting, each team member answers three questions: What did I do yesterday? What will I do today? Are there any impediments in my way? The Daily Scrum is a quick meeting that helps the team stay focused and aligned on their work. The fourth event is the Sprint Review. The Sprint Review is a time-boxed meeting where the team demonstrates the product increment they have built during the Sprint. The team presents the product increment to stakeholders and receives feedback. The feedback is used to help the team improve the product increment and plan for the next Sprint. The Sprint Review is a crucial event because it provides an opportunity for the team to receive feedback and make changes to the product. The fifth and final event is the Sprint Retrospective. The Sprint Retrospective is a time-boxed meeting where the team reflects on the Sprint and identifies what went well and what could be improved. During this meeting, the team discusses their processes and identifies areas where they can make changes to improve their performance. The Sprint Retrospective is an important event because it helps the team continuously improve their processes and work together more effectively.

This video is about the use of flow metrics in the Daily Scrum, a 15-minute time-boxed event where the scrum team gets together to plan their collaboration for the day and inspect their progress towards the Sprint goal. As a reminder, The four flow metrics are cycle time, throughput, WIP limits, and work item age. Prateek, Todd, and Ryan recommend using work item age and cycle time in the daily scrum, with work item age being the elapsed time between when work starts and the current time. The scrum team should clearly define work item age's starting and endpoints. Give these techniques a try, and let us know how it goes in the comment section. ⏩ Join Ryan and Todd for a Scrum.org course: https://buytickets.at/agileforhumansllc Todd and Ryan also co-authored a book - Fixing Your Scrum: Practical Solutions to Common Scrum Problems.

#5amMesterScrum Show 980 Live - Work Yourself out of a Job is so Weak  Scrum Master Not In Daily Scrum, is Not True - Today's topics: (1) Scrum Masters should be Neutral in Daily Scrum but not absent.  The Why's behind the thoughts. 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 Show 980 went live on Youtube, LinkedIn and Facebook Wednesday 3/15/2023 from Philadelphia, PA  Happy Scrumming, video version: https://youtube.com/live/zmQ0uisQuqU 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) 

We recently received a letter from Mike Cohn which reads: Back in 1975, Fred Brooks managed the IBM OS/360 project. This was one of the first software projects to be notoriously late. In fact, it was a year late. Brooks was asked, I suspect with shock and incredulity, “How does a project get to be a year late?” Brooks replied famously, “One day at a time.” I believe that daily scrums help our projects from having similar fates. By meeting daily, issues are raised sooner than they would be any other way. And that helps prevent the day-at-a-time slips that led to Brooks' project being a year late. But, do we really need to meet every day? Yes, most teams do. I do believe there are two exceptions to a daily meeting: The first applies only to teams that are widely distributed across time zones–say when 8:00 am for some team members is 8:00 pm for others. You might not want to hold daily scrums on Friday if it means some team members will have to attend on a Friday night. The second time you may not need a daily scrum is on sprint planning day. ​​Sprint planning usually ends with some discussion that mimics a daily scrum—what tasks from the sprint backlog will each person work on initially? That might make a separate daily scrum redundant. Many teams believe there's a third instance where they don't need daily scrums: when they “talk a lot, anyway.” Talking frequently isn't the same thing as a daily scrum. First of all, the daily scrum may be the only time each day when everyone participates in the discussion. Most other conversations include just a subset of the team. And secondly, when a team does talk frequently outside the daily scrum, the daily scrum will be extremely short. And so it's hardly worth complaining about. Daily scrums are an important inspect-and-adapt activity. Aside from a couple of times when skipping the daily scrum makes sense, holding a daily scrum every working day will help you succeed with agile,

#5amMesterScrum Show 970 Live - What Time for Daily Scrum?  1st Thing Myth - Today's topics: (1) Looking at Daily Scrum Start time and the myth that scrum classes teach and how technology changes it around. 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 Show 970 went live on Youtube, LinkedIn and Facebook Tuesday 2/28/2023 from Philadelphia, PA  Happy Scrumming, video version: https://youtube.com/live/IjHYPbITDxc 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)   

Don't scroll past. This is a really good episode for the agile product owner, scrum master and team. Even the managers will like it. For one or more reasons you are not getting value from your daily scrum or daily standup. Let's get some ideas around how to extract more value from this critical feedback loop. This episode speaks to some ways to leverage the daily standup and get some big time results out of your team work, collaboration and delivery! Reorientation is important and we can always improve by learning from old lessons --- Send in a voice message: https://anchor.fm/planetproductowner/message

#5amMesterScrum Show 946 Live - A Simple Little Exercise for Daily Scrum to minimize long talkers and get faster - Today's topics: (1) An idea taken from the elevator speech idea creating an exercise to speed up Daily Scrum by writing things down a head of time. 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 Show 946 went live on Youtube, LinkedIn and Facebook Tuesday 1/24/2023 from Philadelphia, PA  Our new Slack Channel. https://5ammesterscrum.com/5ammesterscrum-slack-channel/ Happy Scrumming, video version: https://youtu.be/y0-HkWnLBgM 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) 

Get access to the Most Successful PMP Course in PMP History.  Free trial Accelerator Join Trial – PM Master Prep   (NO credit card required) Let me help you!.  Just click this button and tell me your story!  Contact | PM Master Prep OR Email me directly at scott@pmmasterprep.com OR Call me directly 757-759-5282 www.pmmasterprep.com

#5amMesterScrum Show 934 Live - Daily Scrum Simple Habit much like drinking water - Today's topics: (1) Too Many People want to make Daily Scrum complicated but is supposed to be a simple habit that people miss when they don't do it. 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 Show 934 went live on Youtube, LinkedIn and Facebook Thursday 1/5/2023 from Philadelphia, PA  Happy Scrumming, video version: https://youtu.be/HpcAFW0HHm0 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) 

A recent email from Mike Cohn covers the top 10 mistakes ScrumMasters commonly make: Trying to facilitate meetings using someone else's style Holding meetings or events at the wrong time Telling people what to do Staying Silent Not asking enough questions Forgoing the usual meetings due to team size Not 'pushing' the team a little harder towards improvements they commit to make Allowing too much solutioning in the Daily Scrum meeting. Letting a story into a sprint without enough clarity Not letting go of mistakes

Ron Lichty, Interim VP of Engineering, SW Dev Advisor, Agile consultant, and author, shares tips and best practices for conducting effective stand-up meetings. Also known as daily scrums, stand-ups are a crucial way for teams to stay on track and communicate with each other. In this conversation, Ron covers common misconceptions about stand-ups, the frequency of stand-ups, how to make them effective, the best time of day for stand-ups, and more. Whether you're a team leader or a team member, these tips will help you get the most out of your stand-up meetings. Plus, learn about the Fist to Five technique and how to make stand-ups more engaging and interactive. Don't miss this valuable video on stand-up meetings! Episode transcript: https://managersclub.com/how-to-run-daily-scrum-meetings/ RESOURCES ⭐️ https://www.linkedin.com/in/ronlichty/ ⭐️ https://ronlichty.com/ ⭐️ https://managingtheunmanageable.net/ #scrum #agile #projectmanagement

How Do We Hold The PERFECT Daily Scrum Meeting! Here are guidelines that I use to make certain this happens; Daily Meeting 15 minutes or less per day - (30 seconds per person not to exceed 15 minutes) Same time same place same zoom or teams link everyday No pontificating to solve problems - problems that can be resolved in 30 seconds or less should be resolved No electronics of any kind - Yes this includes the Jira Board No Pen or paper to record - no output to the meeting Team rules/guidelines should be clearly posted Do not be late Fines go to a reputable charity Team stands in a circle Visitors around the outside as they do not participate Visitors follow the same rules to be present Always end on time Stick to the REAL three questions Allow exceptions for remote teams

Whether you call it a Stand-Up, a Daily Scrum, a Huddle, or a Roll Call this daily check-in is a powerful tool you and your team can use to maximize productivity. During today's episode, you will learn how to do a Stand-Up, what a Stand-Up consists of, and some pitfalls that you may be deterred by along the way. Most importantly, you need to keep a Stand-Up as simple as you can, based on three basic questions. That's it! Sometimes you'll include Parking Lots as modifiers. Tune in to hear what that means, along with why there is no reason to ask questions during the Stand-Up. Thanks for tuning in! 

Have you ever been asked to invite someone outside of the Scrum Team to one or more of the Scrum Team's Events?On this episode, Product Manager Brian Orlando and Enterprise Agile Coach Om Patel go event by event to talk about when it is right to invite stakeholders to your Scrum Events, and when it is "not right!"0:00 Topic Intro0:20 Daily Scrum, by the Book2:48 Daily Scrum, the Real World6:49 Uninvited Guests9:58 Disciplined & Undisciplined Stakeholders14:35 Sprint Retrospective16:56 Outsiders in the Retro18:51 Sprint Review23:03 External vs Internal Stakeholders26:48 Sprint Planning, by the Book28:05 Sprint Planning, the Real World31:47 Backlog Refinement34:42 Optional Scrum Team Attendees at Refinement37:22 Wrap-up= = = = = = = = = = = =Watch it on YoutubePlease Subscribe to our YouTube Channel:https://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1= = = = = = = = = = = =Apple Podcasts:https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596Google Podcasts:https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5idXp6c3Byb3V0LmNvbS8xNzgxMzE5LnJzcwSpotify:https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3Amazon Music:https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-PodcastStitcher:https://www.stitcher.com/show/agile-podcast-2= = = = = = = = = = = = AA84 - Stakeholders in the Scrum Events

Why Is the Daily Scrum Time-Boxed To Fifteen Minutes? Because the scrum guide says so? LOL.. Not really. Whether we discuss attention span, how long a person can plank for, the content of each team members report, or the age of accountability, no single answer will prevail as to why. This episode will allow you to better understand what to look for and what to look out for.

So an Executive walks into a Daily Scrum and demands Team Member X who must immediately begin work on something that is not part of the Scrum Team's commitment for the Sprint. If you are a Scrum Master, this has either happened to you, or it is going to… soon. What do you do?  You know this is not ok. The Executive, who may have the power to fired you on the spot. should know better too, but apparently, they are “extra-agile”. Your job is to protect the team from interruptions just like this. But your job is also not to get fired. In the heat of this moment, you may not have time to work on developing and evaluating different theories. What do you do? In this episode of SoundNotes, Vic Bonacci joins me to talk through some of the options a Scrum Master has in this situation. We explore different choices available to the SM and the potential impact of each option. And, Vic and I both came at this challenge from different angles, so it gave us an excellent opportunity to talk through how we see it through different lenses.

Mike and Brian take audience questions in the “best of” from the Agile Mentors Community’s monthly coaching calls. Overview Twice a month, there is an open Q&A session we offer as part of the Agile Mentors Community where anyone from the community can join in and ask either Mike or Brian questions. These are open discussions and allow the users to ask their own questions that are unique to their situations. We call these “Coaching Calls” because they are there to help coach the members and help them overcome obstacles along the way. Everyone who takes a class with Mountain Goat Software receives 12 months membership in the Agile Mentors Community and they are able to attend these calls and ask questions. Take a listen to some of the best questions we’ve received over the past few months to get an idea of what these sessions are all about. By the way, we are aware there are a few places where the audio is not perfect in this episode and apologize for the less-than-ideal audio in several places. This is because these answers come from live sessions and there were a few streaming hiccups while delivering them. Listen now to discover: 3:10 - Brian: How to conduct fun retrospectives when you aren’t allowed to use cloud-based tools? 7:40 - Mike: How much planning is needed to ensure we complete items in a Sprint? 11:50 - Brian: Do you change the story points on an item if it turns out to be bigger than you thought? 14:50 - Mike: Why use Fibonacci numbers to estimate? 18:05 - Brian: Should Product Owners attend a Daily Scrum? 20:25 - Mike: What’s the best practice for capturing Non-Functional Requirements? 23:00 - Brian: How do you get your first experience as a Scrum Master if you have none? 26:46 - Mike: Tips for starting out with a new team? Listen next time when we’ll be discussing… Next week we will be taking a very short break of just one week. We are trying to practice a sustainable pace approach and are taking just one week off in order to do that. References and resources mentioned in the show Funretrospectives.com Agilementors.com Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? It would be great if you left a rating and a review. It really helps, and we read every single one. Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us as 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 is co-founder of the Scrum Alliance, and founder of Mountain Goat Software. He’s a veteran of applying Scrum and agile principles and practices to help organizations build better products and ship them on time.

Mike and Brian take audience questions in the “best of” from the Agile Mentors Community’s monthly coaching calls. Twice a month, there is an open Q&A session we offer as part of the Agile Mentors Community where anyone from the community can join in and ask either Mike or Brian questions. These are open discussions and allow the users to ask their own questions that are unique to their situations. We call these “Coaching Calls” because they are there to help coach the members and help them overcome obstacles along the way. Everyone who takes a class with Mountain Goat Software receives 12 months membership in the Agile Mentors Community and they are able to attend these calls and ask questions. Take a listen to some of the best questions we’ve received over the past few months to get an idea of what these sessions are all about. By the way, we are aware there are a few places where the audio is not perfect in this episode and apologize for the less-than-ideal audio in several places. This is because these answers come from live sessions and there were a few streaming hiccups while delivering them. Listen now to discover: 3:10 - Brian: How to conduct fun retrospectives when you aren’t allowed to use cloud-based tools? 7:40 - Mike: How much planning is needed to ensure we complete items in a Sprint? 11:50 - Brian: Do you change the story points on an item if it turns out to be bigger than you thought? 14:50 - Mike: Why use Fibonacci numbers to estimate? 18:05 - Brian: Should Product Owners attend a Daily Scrum? 20:25 - Mike: What’s the best practice for capturing Non-Functional Requirements? 23:00 - Brian: How do you get your first experience as a Scrum Master if you have none? 26:46 - Mike: Tips for starting out with a new team? Listen next time when we’ll be discussing… Next week we will be taking a very short break of just one week. We are trying to practice a sustainable pace approach and are taking just one week off in order to do that. References and resources mentioned in the show Funretrospectives.com Agilementors.com Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? It would be great if you left a rating and a review. It really helps, and we read every single one. Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us as 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 is co-founder of the Scrum Alliance, and founder of Mountain Goat Software. He’s a veteran of applying Scrum and agile principles and practices to help organizations build better products and ship them on time.

TOP 10 REWIND: How to run a Daily Scrum without the 3 Questions? Let's explore the options this situation presents. All of this and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley.   ⏩ Check out the Full Scrum Framework course with added bonus materials, guides, murals, resources, and LIVE INTERACTION with Ryan, Todd, and Daria: https://community.agileforhumans.com/share/z2K_YMahKAiXn9T9?utm_source=manual

As the pandemic wanes, many teams are still not back in the office—some not every day and some not at all. Other teams were remote pre-pandemic and always will be. Whether your team is distributed temporarily or it's your default, your team members need time to get to know one another personally. When teams are in-person, they get to know one another through their daily interactions. You and I get in the elevator together and ask each other innocuous but friendly questions: Do anything this weekend? How old are your kids now? And so on. This type of water-cooler conversation doesn't happen as naturally with distributed teams. Here's one way you can encourage some casual chitchat. Every so often, throw the daily scrum timebox out the window and start the day with a little facilitated small talk. I've gone so far as to tell teams that their daily scrums are required to start with five minutes of mandatory small talk. No mention of the project is allowed. Team members share anecdotes about their hobbies, what their kids did the night before, the great movie they saw, and things like that. After that mandatory five minutes chatting, we start the normal part of the daily scrum, which is timeboxed to a further fifteen minutes. One of my favorite things to hear about during this part of a daily scrum is how team members in a different country will be celebrating a holiday. When on the phone with members of a London-based team recently, I got to find out what the Queen's Jubilee was all about. (Seventy years as Queen–can you believe it?) Until hearing more about some holidays from coworkers, I had no idea what the festivities were like or why they were important. I've learned about all manner of holidays from working with distributed teams this way. More importantly, though, I learned little details about the lives of my remote teammates. And that helped us all work together better. So while I fully support a fifteen-minute timebox to the daily scrum, for some teams, I will occasionally break that rule by starting with five minutes of mandatory small talk. I suggest you try it. I bet you'll learn a great deal more about your remote teammates and find yourselves more naturally able to be honest and comfortable with each other in all of your interactions–which will help all of you succeed with agile. ~ Mike Cohn