Podcasts about scrum guide

Play Episode Listen Later Mar 18, 2025 17:27

Karen Suarez: How to Design Communication Channels to Protect Agile Team Focus, and Avoid Interruptions 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. As a first-time Scrum Master managing a team of 15-20 people, Karen focused primarily on protecting them from constant interruptions in their open office space. However, she soon realized this approach was creating barriers between the team and stakeholders. Karen developed strategies to balance protection with accessibility by establishing "office hours" when the team could be interrupted, creating dedicated communication channels (like Slack) to collect stakeholder questions, and always including the Product Owner when change requests came in. This balanced approach maintained team focus while keeping communication lines open. In this segment, we refer to the Coach Your Product Owner e-course, available to all who need to support their product owners with understanding, and adopting an Agile way of working. Self-reflection Question: How might creating structured interruption times help your team maintain focus while still remaining accessible to stakeholders? Featured Book of the Week: The Scrum Guide Karen recommends repeatedly reading The Scrum Guide throughout your Agile journey. She finds she learns something new with each reading as her interpretation evolves with experience. Karen also highlights "Inspired: How to Create Tech Products Customers Love" by Marty Cagan, which helped her better understand the Product Owner role and gave her practical tools to support POs in their responsibilities. About Karen Suarez Karen is a dedicated Scrum Master with a long experience driving agile transformations and fostering high-performing teams. She is passionate about continuous learning, and excels in aligning agile practices with organizational innovation. You can link with Karen Suarez on LinkedIn.

leadership team balancing slack agile pos product managers stakeholders suarez scrum interruptions office hours team dynamics open space product owners scrum masters team success stakeholder engagement marty cagan scrum guide create tech products customers love inspired how scrum master toolbox podcast

From Process Police to People Partner, Self-Accountability and Self-Awareness for Scrum Masters | Anuj Ojha

Play Episode Listen Later Mar 3, 2025 16:45

Anuj Ojha: From Process Police to People Partner, Self-Accountability and Self-Awareness for Scrum Masters 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. In this insightful episode, Anuj shares a powerful story of personal growth as a Scrum Master. Initially caught up in the mechanics of Scrum, he found himself trying to control situations and please everyone while rigidly adhering to the Scrum Guide. Through a three-step journey of self-awareness, feedback-seeking, and actualization, Anuj discovered that his true challenge lay in understanding himself and his purpose. He learned to shift his focus from velocity and burndown charts to delivering value, and from being process-oriented to being people-oriented. This transformation led him to become more of a listener than a talker, embracing conflict as a natural part of growth. Self-reflection Question: How might your current focus on processes or metrics be affecting your ability to connect with and serve your team members? [The Scrum Master Toolbox Podcast Recommends]

learning failure partner transformation police personal growth self awareness agile self reflection scrum scrum masters lead consultant self accountability anuj scrum guide will angela scrum master toolbox podcast

How To Be A Data-Driven Scrum Master Or Agile Coach | Season Hughes

Play Episode Listen Later Feb 27, 2025 15:09

Season Hughes: How To Be A Data-Driven Scrum Master Or Agile Coach 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. Season approaches Scrum Master success by regularly referring back to the Scrum Guide and measuring progress against its principles. She emphasizes the importance of collecting data and measuring key indicators like self-management, which she tests by occasionally stepping back from daily Scrum meetings to observe team autonomy. Season also stresses the value of one-on-one conversations to understand individual goals and assess team event effectiveness. Self-reflection Question: How do you measure the effectiveness of your role as a Scrum Master beyond just following ceremonies? Featured Retrospective Format for the Week: Lean Coffee Season recommends the Lean Coffee format for retrospectives as it puts control directly in the hands of participants who decide the discussion topics. This approach naturally increases engagement and ownership of the retrospective process. She emphasizes the importance of including warm-up activities to set the right mood and ensuring everyone speaks early in the session, while also following up on previous retrospective actions. [The Scrum Master Toolbox Podcast Recommends]

success reflection personal growth hughes metrics agile data driven scrum self management scrum masters agile coach scrum guide lean coffee tomorrowland transit authority will angela scrum master toolbox podcast

Understanding the "Why" Behind Agile Transformation | Season Hughes

Play Episode Listen Later Feb 26, 2025 15:00

Season Hughes: Understanding the "Why" Behind Agile Transformation 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. Drawing from her consulting experience, Season shares valuable insights about leading successful Agile transformations. Rather than simply implementing Scrum, she emphasizes the importance of understanding organizational motivations by asking crucial questions like "Why do you want this change?" and "What does success look like?" She outlines a comprehensive approach that begins with foundational training using the Scrum Guide, followed by Liftoff workshops to establish team foundations, working agreements, and regular check-ins to support continuous improvement. In this segment, we refer to the Liftoff book, by Diana Larsen and Ainsley Niles. Self-reflection Question: What steps are you taking to understand and align with your organization's transformation goals? [The Scrum Master Toolbox Podcast Recommends]

training change drawing hughes agile change management scrum change agents liftoff organizational change change leadership agile transformation scrum guide diana larsen tomorrowland transit authority will angela scrum master toolbox podcast

#135: Leading Without Authority with Pete Behrens

Play Episode Listen Later Feb 26, 2025 33:33

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

Transforming Workgroups into High-Performing Teams | Season Hughes

Play Episode Listen Later Feb 25, 2025 20:19

Season Hughes: Transforming Workgroups into High-Performing Teams 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. Season shares insights about a common anti-pattern she's observed across organizations: calling a group of people a team doesn't automatically make them one. She discusses how many supposed teams are actually workgroups - collections of independent contributors rewarded for individual rather than collective achievements. Season provides specific criteria to distinguish between workgroups and real teams, emphasizing the importance of shared goals and collaborative success metrics. In this segment, we also refer to the One-Team, One-Goal (OTOG) article by Vasco. Featured Book of the Week: The Scrum Guide Season emphasizes the fundamental importance of The Scrum Guide as essential reading for Scrum Masters. She stresses that since Scrum Masters are accountable for coaching Scrum, they should regularly revisit the guide and stay current with updates. She specifically highlights how many Scrum Masters might miss crucial elements like "product goals," demonstrating why continuous engagement with this foundational document is vital for effective Scrum coaching. Self-reflection Question: How often do you revisit and reflect on the fundamental principles in the Scrum Guide? [The Scrum Master Toolbox Podcast Recommends]

team collaboration transforming hughes agile vasco scrum team dynamics high performing teams scrum masters one team team success scrum guide tomorrowland transit authority will angela scrum master toolbox podcast

Wie umgehen mit Backlog Items unterschiedlicher Granularität?

Die Produktwerker

Play Episode Listen Later Feb 3, 2025 33:09

Die Granularität, oder auch Kleinteiligkeit, von Product Backlog Items ist eine ständige Herausforderung für Product Owner. Manchmal sind die Product Backlog Items zu groß oder man leider unter viel zusätzlicher Verwaltungsarbeit, weil immer wieder ganze Pakete an kleinteiligen Items repriorisiert werden müssen. Das zentrale Thema der Folge ist also die Größe eines Backlog Items. Während der Scrum Guide lediglich fordert, dass Einträge innerhalb eines Sprints abgeschlossen sein sollten, empfehlen Dominique und Oliver eine zusätzliche Regel: Ein Item sollte nicht mehr als die Hälfte des Sprints in Anspruch nehmen. Diese Daumenregel hilft dabei, das Risiko zu minimieren, dass sich ein einzelnes Item über den gesamten Sprint zieht und zu wenig Spielraum für Anpassungen bleibt. Doch Granularität ist nicht nur eine Frage der Planung, sondern auch der langfristigen Produktstrategie. Items, die erst in ferner Zukunft relevant sind, können zunächst grob formuliert sein. Je näher der Umsetzungstermin rückt, desto feiner werden sie definiert. Oliver betont, dass eine zu frühe Detailierung oft überflüssig ist, weil sich Prioritäten im Laufe der Zeit ändern. Das Zusammenfassen und Neuformulieren von Items kann deshalb ebenso sinnvoll sein wie das Zerteilen größerer Einträge. Ein weiteres Thema ist die Handhabung von Granularität im Sprint. Unterschiedlich große Items innerhalb eines Sprints sind kein Problem, solange sie alle einen Mehrwert liefern und das Team die Zusammenhänge versteht. Eine gesunde Mischung aus kleinen, mittleren und größeren Items kann sogar dabei helfen, besser zu lernen und das Forecasting zu verbessern. Ein rein auf gleich große Einträge ausgerichtetes Backlog – wie es beim No Estimates-Ansatz oft gefordert wird – kann zwar die Vorhersagbarkeit erhöhen, schränkt aber unter Umständen die Flexibilität ein. Die Diskussion zeigt, dass Product Owner die Granularität ihrer Backlog Items bewusst steuern sollten. Refinement-Aktivitäten sind notwendig, um sicherzustellen, dass ein gemeinsames Verständnis im Team herrscht. Dabei ist jedoch auch Mut zur Lücke gefragt: Nicht jedes Item muss bis ins kleinste Detail ausformuliert werden. Gerade bei sehr kleinen Verbesserungen kann es sinnvoller sein, sie direkt umzusetzen, anstatt sie ins Backlog aufzunehmen. Letztlich ist die optimale Granularität immer vom jeweiligen Produkt und Team abhängig. Product Owner sollten sich bewusst machen, dass sie nicht nur für den Inhalt des Backlogs verantwortlich sind, sondern auch für seine Struktur und Handhabbarkeit.

#126: Mastering the Scrum Master Role with Gary K. Evans

Play Episode Listen Later Dec 4, 2024 34:30

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

#124: How to Avoid Common Product Team Pitfalls with David Pereira

Lenny's Podcast: Product | Growth | Career

Play Episode Listen Later Nov 13, 2024 29:28

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

Everything you've ever wanted to know about SAFe and the product owner role | Melissa Perri (author, founder of Product Institute)

Play Episode Listen Later Nov 10, 2024 84:19

Melissa Perri is the founder of Product Institute, author of Escaping the Build Trap, and host of the Product Thinking Podcast. She has worked with startups, Fortune 50 companies, and everything in between to help them build better products and level up their product teams. In our conversation, we discuss:• The history of the product owner role• The differences between product owners and product managers• How to transition from product owner to product manager• The evolution of and problems with the SAFe framework• How large non-tech companies can improve their product practices• Much more—Brought to you by:• Pendo—The only all-in-one product experience platform for any type of application• OneSchema—Import CSV data 10x faster• Coda—The all-in-one collaborative workspace—Find the transcript at: https://www.lennysnewsletter.com/p/product-owners-melissa-perri—Where to find Melissa Perri:• X: https://twitter.com/lissijean• LinkedIn: https://www.linkedin.com/in/melissajeanperri/• Website: https://melissaperri.com/• Product Institute: https://productinstitute.com/• Podcast: https://www.produxlabs.com/product-thinking—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• X: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Melissa's background(02:12) The rise of the product owner role(06:37) Understanding Agile and Scrum(08:27) Challenges in Agile transformations(10:41) The history of the product owner role(13:58) The Scrum Guide(15:43) Product owner responsibilities(21:01) Adopting Scrum in organizations(26:21) The origins and implementation of SAFe(35:20) Why Melissa doesn't recommend SAFe(40:33) Advice for implementing a digital transformation(49:12) An example of SAFe adoption(51:27) The value of experienced product leaders(56:53) Career paths for product owners(01:04:14) Transitioning from product owner to product manager(01:06:41) Be careful relying on certifications(01:11:43) Evaluating existing product owners(01:16:55) Final thoughts on Agile and product management—Referenced:• Escaping the Build Trap: How Effective Product Management Creates Real Value: https://www.amazon.com/Escaping-Build-Trap-Effective-Management/dp/149197379X• Lean UX: https://leanuxnyc.co/• Scrum: https://www.scrum.org/• What is Extreme Programming? https://www.agilealliance.org/glossary/xp/• Capital One: https://www.capitalone.com/• The Agile Manifesto: https://www.atlassian.com/agile/manifesto• Ken Schwaber on X: https://x.com/kschwaber• Jeff Sutherland on X: https://x.com/jeffsutherland• Kanban: https://www.atlassian.com/agile/kanban• What is a kanban board?: https://www.atlassian.com/agile/kanban/boards• Ron Jeffries's website: https://www.ronjeffries.com/• Jeff Patton on X: https://x.com/jeffpatton• The Scrum Guide: https://www.scrum.org/resources/scrum-guide• OpenSky: https://www.openskycc.com/• SAFe: https://scaledagileframework.com/• Dean Leffingwell on LinkedIn: https://www.linkedin.com/in/deanleffingwell/• Capital One scraps 1,100 tech positions: https://www.reuters.com/technology/capital-one-scraps-1100-tech-positions-source-2023-01-19/• Product management theater | Marty Cagan (Silicon Valley Product Group): https://www.lennysnewsletter.com/p/product-management-theater-marty• Marty Cagan on LinkedIn: https://www.linkedin.com/in/cagan/• Jeff Gothelf on X: https://x.com/jboogie• Shruti Patel on LinkedIn: https://www.linkedin.com/in/shruti-patel-32bb573a/• Product Thinking Podcast: Mastering Product Focus: Balancing Legacy and Innovation with Shruti Patel: https://www.produxlabs.com/product-thinking-blog/2024/9/25/episode-190-mastering-product-focus-balancing-legacy-and-innovation-with-shruti-patel• Melissa Douros on LinkedIn: https://www.linkedin.com/in/melissadouros/• Mind the Product: https://www.mindtheproduct.com/• Athenahealth: https://www.athenahealth.com/• McKinsey: https://www.mckinsey.com/—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.—Lenny may be an investor in the companies discussed. Get full access to Lenny's Newsletter at www.lennysnewsletter.com/subscribe

#121: Busting the Biggest Myths About Agile Tools with Steve Spearman

Play Episode Listen Later Oct 23, 2024 38:29

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.

#118: The Secrets to Agile Success with Mike Cohn

Play Episode Listen Later Oct 2, 2024 33:33

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.

Planung und Umsetzung großer Releases

Die Produktwerker

Play Episode Listen Later Sep 23, 2024 43:53

In dieser Folge unseres Podcasts dreht sich alles um die Herausforderungen und Best Practices rund um die Releaseplanung, insbesondere der Planung und Umsetzung großer Releases. Wir beleuchten dabei, wie wichtig es für Product Owner ist, die Releaseplanung bewusst und vorausschauend zu gestalten. Gerade in agilen Teams, die nach Scrum arbeiten, gibt es oft das Missverständnis, dass am Ende eines jeden Sprints ein Release erfolgen muss, obwohl es doch lediglich heißt, dass das Inkrement potentiell auslieferungsfähig ist (es erfüllt laut Scrum Guide die Definition of Done). Es ist also möglich das Ende eines Sprints und den Zeitpunkt eines Releases voneinander zu entkoppeln. Denn nicht jede potenziell auslieferbare Funktion muss ja sofort live gehen. Ein zentrales Thema ist diesmal die Frage, wann ein Release sinnvoll ist. Product Owner müssen einen klaren Mehrwert für die Nutzer*innen identifizieren , bevor sie den finalen Schritt gehen. Ein Release ist mehr als nur das Bereitstellen von neuen Funktionen. Es erfordert eine detaillierte Planung, um den tatsächlichen Nutzen und Wert zu maximieren. Dabei gilt es, Abhängigkeiten zwischen verschiedenen Teams und Systemen im Auge zu behalten. Ein weiterer wichtiger Punkt, den wir in der Folge ansprechen, ist die Kommunikation während der Releaseplanung. Sowohl intern als auch extern müssen alle Beteiligten – von Entwickler*innen über Support-Teams bis hin zu Stakeholder:innen – auf den gleichen Wissensstand gebracht werden. Oft gibt es während eines Releases eine Downtime, die Nutzer*innen vorher mitgeteilt werden muss. Hierbei sollte der Zeitpunkt für das Release so gewählt werden, dass möglichst wenige Nutzer*innen betroffen sind, wie etwa mitten in der Nacht. Wir diskutieren auch, wie man mit Problemen umgeht, die während eines Releases auftreten können. Es ist wichtig, dass bereits vor dem Release einen klaren Entscheidungsprozess definiert wird, falls unerwartete Schwierigkeiten auftreten. Für große Releases empfiehlt sich außerdem das Konzept des Feature-Toggles, mit dem bestimmte Funktionen gezielt aktiviert oder deaktiviert werden können, um potenzielle Probleme schnell zu identifizieren. Ehrlicherweise sind wir eher Freunde von kontinuierlicher Bereitstellung von Produktveränderungen statt von großen Releases. Aber auch unserer Erfahrung nach gibt es manchmal einfach gute Gründe. Wir würde uns aber wirklich über eure Erfahrungen rund um die Planug großer Releases freuen, denn so können wir besser voneinander lernen. Teilt eure Erfahrungen und Tipps gerne auf unserer Website in den Kommentaren. :-)

Why Scrum's Product Goal is essential - Mike Cohn

Play Episode Listen Later Sep 4, 2024 8:08

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

essential scrum scrum guide mike cohn product goal

#108: Adaptive Organizations with Ken Rickard

Play Episode Listen Later Jul 24, 2024 19:58

Join Brian and Ken Rickard as they delve into why agile transformations get stuck and uncover strategies for creating adaptive, resilient organizations and people. Overview In this episode, Brian sits down with coach, author, and Lean Change agent, Ken Rickard to explore the common pitfalls of agile transformations and the commodification of agile practices. Ken emphasizes the need to focus on people rather than processes and introduces the art of change, which includes self-awareness and adaptability. And shares the six big ideas of adaptive organizations, such as sense-making strategies and leadership agility. Tune in to learn how to navigate transformation challenges and create an environment that fosters resilience and adaptability. References and resources mentioned in the show: Ken Rickard Insight The Six Big Ideas of Adaptive Organizations: From Frameworks to Sensemaking by Ken Rickard and Jason Little Agile Manifesto For Software Development Lean Change Mountain Goat Software’s Agile for Leaders Training Join the Agile Mentors Community Mountain Goat Software Certified Scrum and Agile Training Schedule Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Ken Rickard is a spark for transformative good — a change alchemist, deep thinker, and a catalyst for personal growth and organizational evolution. With over 15 years in the agile community, he's honed the art of navigating change and embracing adaptation as the true essence of agility. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have a really special guest with us. I have Mr. Ken Ricard with us. Welcome in, Ken. Ken Rickard (00:12) Thank you. Nice to be here. Brian (00:14) Glad to have Ken here with us. Ken recently spoke at the the global Scrum Gathering, in New Orleans that I was at as well and had a really interesting, actually had a workshop slot there for a workshop titled Humans Agile and Change, How to Get Your Transformation Unstuck. And wanted to have Ken on to kind of talk through that a little bit. But before we do, for those people who aren't familiar with Ken, let me give you a little bit of an introduction here. Ken is an enterprise coach and change alchemist. I love that. At a company called Insight, he co -authored a book called The Six Big Ideas of Adaptive Organizations, which I know we're going to get into here in this conversation. He's a licensed facilitator of Lean Change. He's an IC Agile authorized instructor. So he's got just a load of credentials and a load of experience to bring to the table here with this. So Ken, let's get into this. Let's talk about humans agile and change and how to get transformations unstuck. What do you think is the main cause of transformations getting stuck? Ken Rickard (01:31) Yeah. So I think, you know, we're all feeling the effects of the high of agile. And I think now we're, we're starting to come down a little bit in the industry. I think everyone's feeling that effect. I mean, I see so many agile coaches on LinkedIn that are still looking for roles and whatnot, scrum masters, you know, a good bit of that, though, I think it's a blowback from the industry and just companies in general who, when they need to tighten the belt, they're actually beginning to look at the roles they've got and figure out which ones that they can do without for now. Or maybe they can do with roles they've already got. And so the effect of that, I think is coming from this idea that, you know, the agile industry, let's even narrow that a little bit more and talk about scrum specifically, has really kind of in the industry has become commodified around this idea that it's a process. And that we just like, we used to do this thing over here and we can just go to the shelf and purchase like scrum in a way. And then like. take that and just drop it into the spot and the practices we used to do. And so when it was only viewed as a process replacement for what they're doing now, it's very easy when, things get rough or tough in the industry as they've been over the past year, year and a half, two years, that our natural, you know, kind of inclination is to kind of hunker down and that hunkering down is to go back to what's comfortable to us, which is typically non -agile, non edge. things because that edge is actually kind of uncomfortable. And so we want to kind of go back and go back into our hole and actually like do the things that we're most comfortable with as an organization or as leaders. And so, yeah, I think that's been kind of what's been happening. And it's just, you know, the follow up from that, I think it's just now hitting the industry, I think in the current times now. Brian (03:10) Yeah. Yeah, I agree. I mean, you talk about it being a commodity and I can definitely see that across the different organizations that do certifications with this, and we're both trainers, we both do trainings. The hard part for me as a trainer is that I don't wanna... discourage people from getting training because I think the training is an important step, right? I think it's you know, you got to know the basics before you can play a sport and You know, if this is the team sport, but it's it's so much easier for me to tell someone all right Well, there's these roles these events and these artifacts Ken Rickard (03:49) Mm -hmm. Brian (04:05) and they can just go, you know, start putting it into their schedule. Here's the events we're going to do, and we have these meetings at this time. It's easy to do that, but it's hard to say, all right, what is openness? And how do we operate in an open environment, you know, or how do we treat each other with respect as we go through this kind of thing? That's hard to train, you know? Ken Rickard (04:10) Right. Right. Yeah. Yeah. Yeah. And coming from the, you know, I've spent a three and a half, almost four years now, I think with lean change and Jason little, and, and obviously we co -wrote co -wrote the, the book together, but the, I think the thing that I've learned from all that is, I mean, I want to say that at the beginning, the intention of the folks that created the agile manifesto for software development, their intention was really to help the industry change, but from a software development and probably an adjacent request would have been that the project management kind of behavioral patterns that were there and existing already. They could have actually kind of caused that trajectory to start to shift. And they obviously did over time. I think the one thing, if I had a time machine and I could go back and I could just plant a little seed with those 17 folks, it would be to not look so narrowly at the organization, like just the software development part. Because I think that's what's caused agile and scrum to become that thing that those IT developers do. And it's actually in a way done a disservice, I believe, to the industry at large and then just kind of the trajectory over time and where we kind of landed over these past few years. And it's why with lean change, what I'm trying to do, and I'm not the only one trying to do this. There's a number of folks out there trying to do this as well. But I think Jason and I, what we're trying to do and all the lean change facilitators is to get people to realize. that at the end of the day, everything is really about change. So scrum is just a process. It has all these, like behavioral patterns that come along with it. You're going to need to change, but those things aren't laid out necessarily exactly explicitly in the scrum guide. So you can read through that with your current understanding and your current lens of the world. And you can go, okay, I got this. And okay, all I need to do is go and create a scrum master position and I need a product owner and we need to do these events and then we need to set up these artifacts. And, and that can very easily lead to that kind of mechanical approach to scrum because that's kind of the world they've come from, right? If they've come from kind of project management world where everything is very laid out, very kind of straightforward and linear and then sequentially executed. And I think what we would all probably agree is that what's really missing is that mentality shift and. and the perspective shift. And to get there, we got to really focus on people change. Like, and I don't mean just like, Hey, we're doing a new process. So what do I need to do differently? Or, Hey, we put, we installed this new piece of governance software. So what buttons do I need to push differently? I'm talking about like actual evolution of the individual, their beliefs, their behavioral patterns, and the rituals that match up to those behaviors and beliefs that set underneath them as a person. Brian (06:52) Yeah. Yeah. Ken Rickard (07:14) And so that's what we're really trying to focus on from Lean Change is we're really trying to help people understand that, that to do those things well, to do things like Scrum well, you really have to focus not just on the process change or the technology change, but actually on the people change. You may even have to focus on structures and strategies as well. Brian (07:31) So I'm trying to channel my inner listener and try to think of what they might be asking or thinking about in hearing this. And I mean, what I think about is, all right, well, let's say I'm an organization and I buy an end to all this stuff. And I'm like, yeah, yeah, yeah, we've tried that. We've tried to implement this stuff and it's all about process and we'd rather not do that. We want to do it the right way. Where do you start? How do you start to... Ken Rickard (07:38) Yeah. That's it. Yeah. Brian (08:00) you come in and just say, hey everybody, we're gonna change how you think and how you, how do you start to get the organization to shift like that? Ken Rickard (08:06) Yeah, that's tough. Yeah. Yeah. And I would actually, I would point the finger right back at ourselves first. I mean, this is the journey I've been on for the past five years. You know, I mean, I, I actually talked about this in the session at the global scrum, scrum gathering. I told the crowd there. I was like, like five years ago, Ken, like if anybody challenged anything or didn't understand how scrum worked, I would essentially kind of like, Brian (08:14) Ha ha ha. Ken Rickard (08:34) just picture this idea of Ken taking them by the arm and leading them over to the Scrum Guide and being like, look, here's what the Scrum Guide says. And that was kind of my go -to thing in a way, variations on that, obviously. But at that time, it was mentality -wise, I was just like, okay, well, we just need to do Scrum. If we just do it well and we do it like it says we're supposed to do it, then it'll fix all the things. And that didn't really get the best response out of it. everyone. You know, it wasn't until I started to shift myself and my own perspective and start to really understand that, okay, I'm not the snake oil salesperson that they probably think I am. I'm actually somebody who's trying to help them change. And so if I look at it from that perspective, now it becomes less about the process or the framework and all the specifics of the framework. And it becomes more about, okay, where are they now? Brian (09:18) Yeah. Ken Rickard (09:29) What mentality do they have now? What are the attitudes that they have about the things that I would hope to put in front of them? Like, are they, are they like, yeah, this is great. Let's do it. Or are they like, no, I don't know. Not so sure. Or are they like, no, that's a stupidest thing I've ever heard of. Like we would never do that here. so better understanding them as an individual and then being able to better show up in a way that is going to be conducive for them to see the need to change is actually the very first. Brian (09:42) Yeah. Ken Rickard (09:55) best thing that I ever did in the way that I shifted my own perspective and how I showed up. And then that started to actually unlock them and their ability to actually pay attention and realize how they needed to change. And then therefore the change started to go. It's a much slower route because you can just go take stuff off the shelf and be like, Hey, we need to do it like this. And you probably will get some traction with some folks, but you're probably going to miss a good bit of them too. So. Brian (10:20) Well, let me, let me ask you this because this is something I've kind of been wrestling with with some other guests on the podcast as well. It's just this, this concept that, you know, partly, I think what's behind some of the problems with this is, is also the short kind of nature of, of how we view change in organizations. And, you know, we want quick results. We, you know, we have a change initiative to do something and we want to see that, that, that benefit of that change in the next three months. Ken Rickard (10:42) Sure. Brian (10:49) And all of a sudden things are going to be completely turned around and we're going to do things differently. But that's driven a lot from this short -sighted nature of, you know, we got to increase our profits quarter by quarter. We got to, you know, please our shareholders and they don't have the long vision that we used to have in companies of, you know, 10 years or something. Ken Rickard (10:54) Yeah. Yeah. Yeah, I'm going to, I'm going to say something and I'm going to meet it in a completely different way. Planning. Let me explain what I mean by this. all right. And I don't want to make this into the lean change show either, but I'm going to talk about a concept, from lean change real quick. so bear with me, but, so there's this idea that has been created in lean change. It's called, we, we, we refer to it as a big next now. Really what it is is it's like. Brian (11:17) Okay? Hahaha. Ken Rickard (11:42) Think of like an overarching rainbow at the top of like, Hey, what's the largest, biggest thing we're trying to accomplish? And what's the strategy around that? And if we can define a high level strategy around that, it will help us be, get like an orientation towards what outcomes are trying to seek it at the grandiose level. Let's say it's an agile transformation. All right. Underneath there are like a series of smaller humps that are like, okay, what are the goals we might want to actually achieve? Let's make sure those are really loose. except for the ones that are in the very beginning. Does this sound familiar? I'm basically describing breaking down and iterating incrementally changing the organization, right? So, underneath that you'd have like what's referred to as like the lean change cycle. This idea that we go out and actually look at the organization and get data back on what might need to change instead of actually telling people what needs to change. Like, Hey, we're becoming a scrum team, or this is what scrum is, and this is how it works. Brian (12:21) Yeah, yeah. Ken Rickard (12:41) well, what if they just start where they are and maybe the first thing I add is like a daily, you know, maybe they don't have any kind of coordination events at all right now. And then their tolerance level to change is just minimal. So, okay. So as a coach or as a less even a scrum master, the first thing I might help them do is to actually just put in some frequency of a regular sink. That could wind up turning into something that we would recognize as a daily scrum or a daily standup, but. In the beginning, maybe they don't have the tolerance to go right directly to the thing. Maybe they'll reject that or resist that. So as, as a coach or as a scrum master who's focused on change and not the process of the framework, I would go in and actually help them figure out what the best changes for them right now. And that's the approach I've been using and it just works. It works pretty well. versus coming in and being like, Hey, here's what scrum is. Here's how it works. Let's go through this training. You know, we got to get all these things set up. We need, here's what perfect looks like. Brian (13:14) Yeah. Ken Rickard (13:39) guess what we can't get there. So yeah. Brian (13:43) Yeah, I mean, as I'm listening to you, I'm thinking, you know, it's a difference of listening versus telling, you know, like there's a, there's kind of a telling mindset of going in for a lot of coaching of, you know, what we would typically frame more as a consulting approach. You know, I have answers. Here's the answers for you. Just do the way that I've always done it and everything will be fine versus let's actually hear what your situation is. And. Ken Rickard (13:59) Yeah. Brian (14:10) what your needs are and what you're seeing going wrong and how can we address those issues? I love that. Yeah, yeah, exactly. Ken Rickard (14:14) Yeah, and experimenting through it and honestly showing up, showing up as, or knowing when to show up in a coaching stance, who is going to be more empathetic and more understanding and not going to give them all the answers and it's going to let them explore and figure it out. And it's going to shine the light in the dark corners of the room versus the consultant stance, which is going to show up in more of an advisory. Hey, If I see you all struggling, I'm going to kind of tell you what to do or show you what to do. And they may not be ready for that. So it's about knowing when to actually do one stance or the other and be able to be very fluid in those things. Brian (14:47) Yeah. Yeah, there's a, there's a phrase I'll use often in class when I talk about the coaching kind of mindset to say, you know, what we're trying to do is not build knowledge, but build capability. And if you build the capability, then people can then adapt and change when, when something similar comes along or something in the same realm, they can say, yeah, I remember last time when we had something like this, here's how I responded. So that, that ability, I think to. deal with change like you're saying. And if we have it ingrained in our mindset that, hey, we identify problems, we inspect them and we adapt as we go along, to me, that's so much more important to build into how we do things than it is to know, we got these four meetings or five meetings that we're gonna make sure we hold at a certain time. Awesome. Well, you know, I'd like to hear a little bit because I know, you know, your talk is somewhat loosely based on your book as well. And, you know, with a title like the six big ideas, help us understand. We may not have time for all six, but give us some of these big ideas. Ken Rickard (16:00) Yeah. Yeah. Sure. Yeah. Yeah. I'm also still, I think Jason and I are still trying to figure out if, how the word or the phrase big ideas is resonating with folks too, because in the agile community, you know, big, big is not a word that I think people will gravitate to very quickly, but, we're also trying to straddle the fence on the change community and the agile community. Honestly, what we're trying to do is I was joking around and I think we, I'm. Brian (16:21) Yeah. Yeah. Ken Rickard (16:31) might've wrote this either in the book that's out now or the bigger book that we're working on for later this fall. But I wrote somewhere that really the change community and the agile community should really go on a blind date because they never should have really been two separate communities in my opinion. And I think Jason would hold the same opinions and a lot of our lean change facilitators, I think would hold the same opinions. So yeah, so the book is really about trying to get Agilist to understand that their role is really about change. Brian (16:47) Yeah. Ken Rickard (17:02) They already know the agile bits and the iterative incremental and all that kind of stuff. And that the change community really needs to better understand the agility community and take some of those practices and apply it to the change. And if both sides do those things, we're going to wind up in the middle and everybody's going to be the same type of person or the same type of thing. Because at the end of the day, getting to agility, like this idea of the characteristics of being nimble and being able to adapt to what's going on with a certain grace and resilience. Brian (17:25) Yeah. Ken Rickard (17:31) that set of characteristics is really, I think what the agile industry is hoping to go for. And yet a lot of the folks that find these things come to it with their current understanding and they don't really, aren't really looking to change themselves and how they see things, their perspective. And so that's how we get into this commodified kind of off the shelf version of it. And so I think we're just trying to get people to realize that. Look, if you look at these big, these six big ideas, which are really just sense making strategies. At the end of the day, that's what they are. You should be able to sense your way through what your context, your organization, given the changes that are going on. you know, what are those circumstances? How well do you know those circumstances? If you can understand those things in a sense making way, you'll be able to show up in a way that it actually be conducive to help that organization change, no matter what the scope of the changes. Let's say you're a store master. It could be your scope of your change is essentially your team or teams. Brian (18:25) Yeah. Ken Rickard (18:29) And the product that they're building, let's say you're an agile coach. Okay. Maybe it's somewhat wider than that. I don't know. I'm still on the fence about what the difference between agile coaching and scrum master is. That's another podcast though. I think, or let's say you're somewhere higher up in the organization. So whatever your purview is, whatever your scope is, that context is really what we're trying to do. We're trying to help you and the others around you understand what it is that you're not paying attention to, what it is that you don't understand. Brian (18:39) Yeah. Ken Rickard (18:58) or that you might think you understand about your organization. So it's really six ideas to help people kind of unravel that about their organization and themselves. Because like, for instance, one of the six big ideas is something that Jason had created quite a long time ago called the four dimensions of change. And what it says is that there's four things that you really probably need to focus on as, as a agent of change. And that is yourself. So like, Brian (19:07) Yeah. Ken Rickard (19:26) Your set of beliefs about things, you know, how you show up because how you show up actually affects how others receive or perceive you. And then that impacts your ability to influence others and actually help them change. And then it goes on to say there's, the big ideas or strategies that you can deploy from, from a change perspective, typically minimally viable practices, or strategies. And then the last bucket in that four dimensions is, tools and practices. You know, the things that we have the most affinity for and tend to go to first, and kind of ignore the other three things. So it's, so that particular big idea is trying to get people to recognize that, no, there's like a bigger kind of art and science here to helping people change. It's not just about the science, like the strategy and the tools and practices to be good at those things. Most likely you got to focus on the art of change, which is yourself and your stance or how you show up. Brian (19:59) Right. Right. Yeah, I'm gonna share one of my geeky subdivisions here in making this quote, but it reminds me of in the musical Hamilton, there's a line in there that George Washington says to Hamilton where he's talking about, you know, Hamilton has these visions of going off and dying like a martyr and George Washington says, dying is easy young man, living is harder. And. Ken Rickard (20:30) Yeah. Yeah. Brian (20:51) That's kind of how I see this. I'm not saying we're dying or making a choice between dying or not, but I am saying that the practices side of thing, practice is easy young man, culture is harder. It's just harder to try to implement those things. And I think a lot of times, I don't know if it's, I think individually sometimes as coaches we can get lazy. Ken Rickard (20:55) Yeah. Brian (21:18) and go to the things that's easier to tell people about. But I also think that it's an institutional thing because it's much easier for me to certify somebody or give them a credential saying that, hey, this person knows their stuff when I can test them on facts and figures and how long is that meeting and that sort of stuff versus. Ken Rickard (21:20) Mm -hmm. somebody. Yeah. Please. Brian (21:41) you know, how do you change the mindset of the culture of the organization when they're really into quick solutions and they're into trying to get things out the door as fast as possible and not focus on quality. It's harder, right? It's just, it's more difficult. Ken Rickard (21:55) Yeah. Yeah. Yeah. Yeah. Yeah. You're hitting on one of the other six big ideas right now. Actually two of them, but we can start out with the explain the one. So there's another one that we made called the, the two change strategies of effective organizations. And so what this one says is that there's two ways that you can probably improve or change your organization. And that's a fractal statement in an organization because again, we're only talking about whatever context you have. Brian (22:06) Hahaha. Ken Rickard (22:27) Cause if you're a SCAR master, we're talking about the context you have of the teams you're working with. Agile coach or something higher up than that, whatever context you have. So, okay. So within your context, you probably have two ways to think about and try to help your organization change. And those two ways are either optimizing what they already do to make it better, faster, cheaper, or evolving the way they think about what they do so that they can actually succeed in ways that they never have before. And I'd be, I'll go out on a limb and say that every, at the very least, every single company I've come across that's doing agile and whatever way they call it, is really trying to do it from the purpose of the optimization, better, faster, cheaper. I think there are very few companies around the world that are actually taking it seriously enough to do the evolution part to actually change the way they think about how they do things in such ways that they're actually elevating. their set of beliefs and behavioral patterns, not just as individuals, sorry, as individuals, but as a collective and then ultimately as an organization. And so it's really trying to get you to, to focus on what is it that we actually are trying to improve? Is it just that we're trying to optimize what we're doing now? Cause that's a take scram off the shelf and just drop it in, you know, or that's send people to training and like come back and be like, cool, you're certified. Brian (23:33) Chief. Ken Rickard (23:49) But if we don't ask the hard questions around, okay, well, what are you gonna change about your behaviors? Then they're likely not focusing on evolution. And if we're not coaching them through that, yeah, not really going anywhere. Brian (24:01) Yeah, do you think organizations just don't know what they don't know? I mean, because I know you're right, they do want better, faster, cheaper. And that's sort of the end goal that they're coming at a lot of this stuff with. They just not recognize that it's really the change capability that they should prioritize. Ken Rickard (24:05) It's like. Well, I think it's because they focus. So what's really easy for a lot of organizations to change. There's a, we're going to keep tying these five, sorry, these six big ideas together, I guess, because there's another one called the five levers of change. And what that one is, is a, it's a circle of five things with people being the biggest circle in the center. And then on the four corners of it, it's basically process and technology strategies and structures. Brian (24:32) No, that's great. Ken Rickard (24:48) And so if we look at that as a systems approach to changing an organization, the reason why it's called the five levers is because they can pull any levers in any combination they want in order to try to change their organization. But the easiest levers to pull are process and technology. So, Hey, let's do scrum and we need to install Jira or Azure DevOps. Right. And that's generally where these kinds of things start because it's within the control of the teams oftentimes to make those changes. It doesn't impact a larger organization to, well, it can, but probably to a lesser extent initially. So the teams have some level of autonomy or local control to start making those changes. They don't run into problems or impediments or just kind of organizational dysfunction until a little bit down the road so they can kick that can down the road. And so I think it's, I think it's that that causes us to gravitate towards a process and then just pull that lever pretty easily. And, and that's an optimization lever. So if you tie those two ideas together, it takes the other side of those five levers, the structure and the strategies, which are all built on beliefs. You know, like if I'm a leader in a hierarchy who's worked 20 years to get to my lofty management position, I'm going to be a lot less likely to take a empathetic kind of delegated approach to my management style because I put in a lot of hard work to get to where I am now. And there's no way you're going to tell me now. Brian (25:48) Yeah. Ken Rickard (26:18) 20 years that I now have to change the way I operate? Like, no, I'm in control here. So I think we're also battling that a little bit too. Brian (26:20) Right. Yeah, what I've done got me here. So why would I do something different now? Right? Ken Rickard (26:32) Right. Exactly. Brian (26:34) Yeah, I've battled that in multiple occasions, for sure. One of the places I worked was a newspaper. And if you want to talk about people not wanting to change their mindsets of, hey, what do you mean that people don't want to have delivery of their newspaper on their front doorstep every day like they've done their whole life? Yeah, it's crazy. Well, this is great stuff. I'm really enjoying this. Ken Rickard (26:49) Yeah. Yeah. Brian (27:03) Do you have one last big thought, big idea to leave us with here? Because we're almost out of time, but what have we missed in these big ideas? Ken Rickard (27:13) Yeah, probably the other big one that comes up a lot. one of the other six that I haven't talked about yet is the, what I call the three agilities. And we'll tend to focus on the delivery agility, which is like, Hey, we, we can help you team better and people better at the team level where you're delivering. And we can help you become more product led. And we can also help you with your technical excellence, you know, like DevOps types things, right? Brian (27:21) Okay? Ken Rickard (27:38) And I think we could probably draw a circle around those three things and go, you know what, for the vast majority of the agile industry, this is what they think agile is. But in my opinion, that's only one of the agilities an organization needs in order to actually possess the characteristics of agility. And the other two would be change agility. The idea that we are adaptable to the change that we cannot control and that we actually can adapt well in a resilient way to the change we can control within our organization. And that we're constantly evolving to get better at that so that we can sustain change in a graceful way over time. So that's change agility. And then the third one is probably possibly the most important one. And that is leadership agility. This idea that if we don't create the environment for change to take place in a conducive way that is productive and adaptable. then we won't change and we'll stay stagnant and we'll stick to our standardized approaches in a stagnant way. And then delivery will suffer even though we can put new things on top of it and we can call things new words, it won't actually change. And the leadership agility is really about not just trying to teach leaders to be more competent. That's generally what management consulting and a lot of other folks are focused on. It's really about trying to help leaders address their ability. to actually have a consciousness about themselves, that they can show up in ways that are actually enabling and empowering the organization to be adaptable and flexible and to be able to deliver and change in ways that are graceful and resilient. And so in my opinion, it kind of starts there even though a lot of them don't start. Brian (29:14) I love that. No, I love that. I think that's great because, you know, a lot of times you hear the complaints of people who come through classes that are kind of more team level in the organization. And it's, there's a lot of complaints about how management just doesn't understand, or we're bumping up against the glass ceiling, you know, kind of in our organization, we can't really Institute change or make the change permanent because, you know, leadership still wants things exactly in the old way. They haven't actually shifted. how they think about things. So I love that, I love that concept. I would agree there. Well, this is great stuff. And obviously, like I said, the workshop that Ken did at the Scrum Gathering was an hour and a half. And this is just a short little taste in half an hour. So there's no way we're gonna be able to cover it all here. I strongly encourage people, if they're really interested in this topic, if they're really interested in what Ken is saying, Ken Rickard (29:53) Thank you. Yeah. Brian (30:15) Check out the book the six big ideas of adaptive organizations. It's a great book And it'll go into detail on all of these these six big ideas that we talked about here And what we're gonna put lots of the links in our show notes here so if you want to just head on over our show notes you'll find links over not only that but to to Ken's organization the six big ideas network and you can find the website there and find the the Ken Rickard (30:24) Mm -hmm. Brian (30:44) classes and trainings that Ken is doing in this area. So we'll make sure that everybody can get to that. Ken, I can't thank you enough. Thanks for coming on and sharing your knowledge with us today. Yeah. Ken Rickard (30:54) Yeah, thanks for having me. It was fun.

#106: Innovating Through Economic Downturns with John Barratt

Play Episode Listen Later Jul 10, 2024 35:03

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

Complementary Practices in Scrum with Mike Guiler

Play Episode Listen Later Jun 21, 2024 30:50

This week, your host, Justin Thatil, is joined by Mike Guiler to explore complementary practices in Scrum. The Scrum Guide intentionally left many open questions for users to adapt and practice flexibility. In this episode, Justin and Mike outline several practices, such as identifying the product vision, adapting the Kanban Board, and providing visual information regarding the production process. They also discuss the benefits of using Kanban's lead and cycle time metrics and close this conversation by diving deep into the importance of identifying a shared definition of ready. Key Takeaways Product Vision: Scrum is always about outcomes. How do we find the right outcome to deliver to our customers? First, we need to be clear about the product vision and what the organization considers a priority. Second, the Team comes up with a plan to achieve that vision, which unlocks an organization's power. Adapt a Kanban board. The Kanban board helps to visualize the process at a particular sprint timebox. Many benefits result from visualizing the steps in the Kanban Board. Scrum with Kanban: Stop starting and start finishing! Look at what you are doing and implement better Teamwork. Kanban's lead time and cycle time metrics give an indication of the system's progress and whether it is getting better. The cycle time measures the time it takes an idea since it enters a print backlog until it is delivered to the customer, while the lead time gives more of a system view. Find your definition of “ready.” What has to happen to make a product backlog ready? Get to a shared understanding of what is considered ready within a Team. Reduce the ambiguity about what should and shouldn't be in the product backlog, resulting in a better sprint plan. Mentioned in this Episode: Listen to Episodes 277 and 279 of The Agile Coaches Corner. Scrum with Kanban Sprint: How to Solve Big Problems and Set New Ideas in Just Five Days, by Jake Knapp 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!

team touch practices reduce adapt teamwork scrum complementary kanban solve big problems kanban boards scrum guide just five days agilethought

From The Archives: Jeff Sutherland on Doing Twice the Work in Half the Time with Scrum

Agile Innovation Leaders

Play Episode Listen Later Apr 21, 2024 49:48

Bio Dr. Jeff Sutherland is the inventor and co-creator of Scrum, the most widely used Agile framework across the globe. Originally used for software development, Jeff has also pioneered the application of the framework to multiple industries and disciplines. Today, Scrum is applied to solve complex projects in start-ups and Fortune 100 companies. Scrum companies consistently respond to market demand, to get results and drive performance at speeds they never thought possible. Jeff is committed to developing the Agile leadership practices that allow Scrum to scale across an enterprise. Dr. Sutherland is the chairman and founder of Scrum Inc. He is a signatory of the Agile manifesto and coauthor of the Scrum Guide and the creator Scrum@Scale. Jeff continues to teach, create new curriculum in the Agile Education Program and share best practices with organizations around the globe. He is the founder of Scrum Inc. and coauthor of, Scrum: The Art of Doing Twice the Work in Half the Time, that has sold over 100,000 copies worldwide. Social Media: LinkedIn: linkedin.com/in/jeffsutherland Twitter: @jeffsutherland Website: Scrum Inc https://scruminc.com Books/ Articles: The Scrum Guide by Jeff Sutherland and Ken Schwaber http://www.scrumguides.org/index.html Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland The Scrum Fieldbook by JJ Sutherland Agile Competitors and Virtual Organisations by Steven Goldman, Roger Nagel and Kenneth Preiss https://www.amazon.co.uk/Agile-Competitors-Virtual-Organizations-Engineering/dp/0471286508 Accelerate: Building Strategic Agility for a Faster Moving World by John P. Kotter Leading Change by John P. Kotter Process Dynamics, Modeling and Control by Babatunde A. Ogunnaike and Harmon W. Ray A Scrum Book: The Spirit of the Game by Jeff Sutherland, James Coplien, Mark den Hollander, et al Interview Transcript Ula Ojiaku: Hello everyone, my guest today is Dr Jeff Sutherland. He is the inventor and co-creator of Scrum, the most widely used Agile Framework across the globe. Originally used for Software Development, Jeff has also pioneered the application of the framework to multiple industries and disciplines. Today, Scrum is applied to deliver complex projects in startups and Fortune 100 companies. Dr Jeff Sutherland is the Chairman and Founder of Scrum Inc. He is a signatory of the Agile Manifesto and co-author of the Scrum Guide and the creator of Scrum at Scale. Jeff continues to teach, create new curriculum in the Agile education programme and share best practices with organisations around the globe. He has authored and co-authored a number of books which include Scrum: The Art of Doing Twice the Work in Half the Time – which has sold over 100,000 copies worldwide. In this episode, Dr Sutherland shares the backstory of how he and Ken Schwaber developed the Scrum framework. I was pleasantly surprised and proud to learn that one of the inspirations behind the current Scrum framework we now have was the work of Prof Babatunde Ogunnike, given my Nigerian heritage. Dr Sutherland also talked about the importance of Agile Leadership and his current focus on helping organisations fix bad Scrum implementations. I'm sure you'll uncover some useful nuggets in this episode. Without further ado, ladies and gentlemen, my conversation with Dr Sutherland. Ula Ojiaku: Thank you, Dr. Sutherland, for joining us on the Agile Innovation Leaders podcast. It's a great pleasure to have you here. Jeff Sutherland: Glad to be here. Looking forward to it. Ula Ojiaku: Fantastic. So could you tell us about yourself? Jeff Sutherland: Well, I grew up in a small town in Massachusetts. And I always felt that I would go to West Point of the United States Military Academy, even at a very young age. And I finally made it there. I spent four years there. And I went on to a program where a certain number of cadets could join the Air Force. And I told the Air Force, if they made me a fighter pilot, I would move into the Air Force, which I did. I spent 11 years as a fighter pilot in the Air Force. And most of the operational aspects of Scrum actually come from that training. My last tour in the Air Force was actually at the US Air Force Academy, I was a professor of mathematics. And I had gone to Stanford University in preparation for that position. And I had worked closely with the, at the time he was Head of the Department of Psychiatry, became the Dean of Stanford who had studied under my father-in-law, he had become an MD under my father-in-law, who was a brilliant physician. And I was working on research papers with him, both at Stanford and at the Air Force Academy. And I asked him for guidance. And I said, I'm thinking about, given all the work we've done in the medical area. Starting in Stanford, I'm thinking maybe becoming a doctor - become an MD. And he strongly recommended against that he said, ‘you'll just go backwards in your career, what you need to do is you build on everything you've done so far. And what you have is your fighter pilot experience, your experience as a statistician, and a mathematician, you want to build on that.' So, I had already started into a doctoral program at the University of Colorado School of Medicine, which was not far from the Air Force Academy. And so, I talked to my department Chairman there who offered me a position in the department running a large research grant, funded by the National Cancer Institute and so, I decided to exit the Airforce and join the medical school. While I was finishing up my doctoral degree. And as soon as my doctorate was finished, I became a professor of Radiology, preventive medicine and biometrics. I was a joint across multiple departments. And I was doing mathematical research on modeling, particularly the human cell on a supercomputer, (to) determine what caused cancer. And to do that required extensive mathematical research as well as the medical research. But at the end of the day, what we found was for any complex adaptive system, like a human cell, or a person or a team, they go through different states. And they're moved from one state to the next by some kind of intervention. And so, if you understand what causes those changes… turned out in the case of cancer, there were four different states that led to a tumor. And in every state, there were certain interventions, and if you knew what they were, you could prevent them and prevent cancer. Or you could even, to my surprise, take a cancer cell and make it go backward into a normal cell. So, this fundamental understanding is the theory behind Scrum. So, while I'm doing this all at the medical school, a large banking company came by and said, ‘you know, over the medical school, you guys have all the knowledge about the technologies; the new technology, we're using (for) banking, you're using for research.' And they said, ‘you guys have all the knowledge but we have all the money and they made me an offer to come join the bank' Ula Ojiaku: [Laughs]You couldn't refuse Jeff Sutherland: Not just me, it was my family. So, I wind up as Vice President for Advanced Systems, which was effectively was the CTO for 150 banks that we were running across North America. Each was, you know, a dozen, 50, 100 branches. And of course, we were mainly doing the software, installation and support to run the banking operation, which is largely computer stuff – (this) is what banks run off. And as we're building these systems with hundreds and hundreds of developers, one of the first things I noticed is that all the projects were late. And I look at what they're doing. And they're using this process where they spend, you know, six months defining requirements, and then they put all the requirements into a Gantt chart. And then they, they plan on taking six months to build something, but it's never done. Because as soon as they start testing that they find there's all kinds of things that are broken. So, virtually every single project of the bank is late. So, as a head of technology, one day I walked into the CEO's office and I said, ‘Ron, have you noticed all your projects are late?' He said, ‘Yes'. He says, ‘Every morning at least five CIOs or CEOs of the banks, they call me up.' And he says, ‘they scream at me.' I said, ‘wow', I said, ‘You know, it's going to get worse, not better. Because these guys are using this, these Gantt Charts.' And I showed him one. And then being a mathematician, I mathematically proved that every project would be late at the bank. And he was stunned. And he said, ‘what should I do?' I said, ‘we need a completely different operating system in the bank.' This is back in 1983. ‘Let's take one business unit. Let's take the one that's losing the most money, okay, the worst business unit' Ula Ojiaku: They have nothing to lose then. Jeff Sutherland: And it was the automated teller division that was rolling out cash machines all over North America. It was a new technology and they had a ton of problems. So, I said, ‘let's take that unit and every one, sales, market, support, installation, we're going to split them down into small teams. And we're going to have Product Marketing come in on Monday with a backlog prioritized by business value. And at the end of the week, on Friday, we're going to deploy to 150 banks.' ‘And I'm going to train them how to land a project every week, just like I trained fighter pilots to land aircraft. I'm going to give them a burndown chart, we're going to throw away the Gantt Chart, I'm going to give them a burndown chart to show them how to land the project.' So, he said, ‘Well, that's gonna be a big headache.' I said, ‘look, the bank needs to be fixed.' He said, ‘Okay, you got it.' So, I took that unit. I told them, ‘I know it's gonna take several weeks,' today we call them sprints, ‘for you to be successful.' Because as new pilots, trained to land, these high-performance jets, they tend to come in high and then they have to come around and try to land again, they over and over, they practice until they can nail it. And it took them six weeks, six sprints to actually nail the end of the week (and) deploy (to) 150 banks. But within six months, it became… it went from the worst business unit in the bank to the most profitable business unit in the bank. And the senior management said, ‘you know, Jeff, here's another 20 million dollars to throw at whatever that thing you're doing it's the most profitable thing in the bank, we're gonna put more money in that. So that was the first prototype of what we call today Scrum at Scale. Now, I've been CTO of 11, or CTO or CEO of 11 different companies. And for the next 10 years, I prototyped that model and advanced technology teams until in 1993, at a company called Easel Corporation, we found that because of the tooling we were building and selling to customers, we needed to build the tool with what today we call Agile Practice. Ula Ojiaku: Yes Jeff Sutherland: And we need to train the customer to use the tool by having teams do an agile practice. So, in order to train our customers properly in 1993, we actually had to formalize what I've been prototyping for 10 years. And we wrote it down and at the time we were reading this paper, we're going through 1000 papers in the journals I, you know, I had done many new technology. And, in every one of them, you have to read everything that's ever been done so that you can go beyond. You can use everything that's been done, but then you go beyond, okay? Ula Ojiaku: Yeah Jeff Sutherland: So, it's a tremendous amount of research to launch new technology. And at about the 300th paper in our file, it was a paper out of the Harvard Business Review, which really surprised me, by two Japanese Business School professors, Professors Takeuchi and Nonaka. And in there, they described the best teams in the world. They were lean hardware teams that reminded them of a game of rugby, they said, ‘we're going to call what they're doing Scrum Project Management.' So, I said to the team, ‘we need a name for this thing that we're going to train our customers in, and let's call it Scrum.' And off we went. So, for the next two years, we were actually using Scrum within Easel deploying products. But it was not public, to the general industry. And Easel got acquired by a larger company. And at that time, I felt that this needed to be rolled out into the industry because we had benchmarked it with the best tooling in the world from the leading productivity company, and showed that it was… that (it) went 10 times faster. The quality was 10 times better, which is what you need for a new technology innovation. And so, I felt it was ready to go to the industry as a whole. So, I called up an old friend, Ken Schwaber. And he was a CEO of a traditional Project Management software company, a waterfall (methodology). He sold these methodologies with 303 ring binders, a software package that would make Gantt Charts. So, I said, ‘Ken, I want you to come up and see the Scrum, because it actually works and that stuff you're selling doesn't work – it makes projects late.' And he agreed to come in, he actually came up, he met with me. He stayed for two weeks inside the company, working, observing the Scrum team. And at the end of those two weeks, he said, ‘Jeff, you're right. This really works - it's pretty much the way I run my company.' He said, ‘if I ran my company with a Gantt Chart, we would have been bankrupt a long time ago.' So, I said, ‘well, why don't you sell something to work that works instead of inflicting more damage on the industry?' So, he said so we said ‘okay, how (do) we do it?' I said, ‘it needs to be open source, it needs to be free.' Ken felt we needed to take the engineering practices, many of which appear today in extreme programming… Ula Ojiaku: Yes Jeff Sutherland: …and let Kent Beck (creator of eXtreme Programming, XP) run with them because Kent had been sending me emails, ‘Jeff, send me every...', he had been following the development of Scrum, ‘…send me everything on Scrum, I'm building a new process. I want to use anything that you've done before and not try to reinvent anything.' So, he (Ken Schwaber) said, ‘let Kent take the engineering practices, we'll focus on the team process itself.' And we agreed to write the first paper on this to present at a big conference later that year. And writing that paper was quite interesting. Ken visited DuPont Chemical Corporation, the leading Chemical Process Engineers there that they had hired out of academia to stop chemical plants from blowing up. And when Ken met with them, they said, describe what we were doing in the software domain. They said, ‘you know, well, that process that traditional project management is a Predictive Process Control System. We have that in the chemical industry.' ‘But it's only useful if the variation in the process running is less than 4%.' They said, ‘do you have less than 4% change in requirements while you're building software?' Ken says, ‘no, of course not! It's over 50%!' And they started laughing at him. They said, ‘your project's going to be exploding all over the place.' ‘Because every chemical plant that has blown up has been somebody applying a predictive control system to a system that has high variability. You need to completely retrain industry to use Empirical Process Control, which will stop your projects from blowing up. And they said, here it is, here's the book, they had the standard reference book for Chemical Process Engineering. And in there, there's a chapter on Empirical Process Control, which is based on transparency, inspection, and adapting to what's happening in real time. Okay, so those are the three pillars of Scrum that are today at the base of the Scrum guide. Ula Ojiaku: Do you still remember the title of the book that the chemical engineers recommended to Mr. Schwaber by any chance? Jeff Sutherland: Yeah, so I have a, when I do training, I have a slide that has a picture of the book (Process Dynamics, Modelling and Control). It's written by Ogunnaike and Ray. But that is the root of the change that's gone on in the industry. And so then from 1995, forward, Ken and I started working together, I was still CTO of companies. And I would get him to come in as a consultant and work with me. And we'd implement and enhance the Scrum implementations in company after company after company. Until 2001, of course, Scrum was expanding but Extreme Programming in 2001, was actually the most widely deployed. They were only two widely-deployed agile processes at the time of Scrum and Extreme Programming. Extreme Programming was the biggest. And so, the Agile Manifesto meeting was convened. And it had 17 people there, but three of them were Scrum guys - that had started up Scrum, implemented it in companies, four of them were the founders of Extreme Programming. And the other 10 were experts who have written books on adaptive software development or, you know, lightweight processes, so, industry experts. And we, we talked for a day and everybody explained what they were doing and there was a lot of arguments and debate. And at the end of the day, we agreed because of this book, Agile Competitors, a book about 100 hardware companies - lean hardware companies, that have taken Lean to the next level, by involving the customer in the creation of the product. And we said, ‘we think that we all need to run under one umbrella. And we should call that Agile.' Ula Ojiaku: So, did you actually use the word umbrella in your (statement)? Oh, okay. Jeff Sutherland: Often, people use that right? Ula Ojiaku: Yes, yes Jeff Sutherland: Because at the time, we had Agile and Extreme Programming, and now everybody's trying to come up with their own flavor, right? All under the same umbrella of ‘Agile'. And that caused the both Scrum and Extreme Programming started to expand even more, and then other kinds of processes also. But Scrum rapidly began to take dominant market share, Scrum today is about 80% of what people call Agile. The reason being, number one, it was a technology that was invented and created to be 10 times better. So, it was a traditional new technology developed based on massive amounts of research. So, it worked. But number two, it also scaled it worked very well for many teams. I mean, there are many companies today like Amazon that have thousands of Scrum teams. And Extreme Programming was really more towards one team. And (reason number) three, you could distribute it across the world. So, some of the highest performing teams are actually dozens of teams or hundreds across multiple continents. And because of those three characteristics, it's (Scrum has) dominated the market. So that brings us to in 2006, I was asked by a Venture Capital firm to help them implement Scrum in their companies, they felt that Scrum was a strategic advantage for investment. And not only that, they figured out that it should be implemented everywhere they implemented it within the venture group, everybody doing Scrum. And their goal was to double their return on investment compared to any other venture capital firm. They pretty much have done that by using Scrum, but then they said, ‘Jeff, you know, we're hiring you as a consultant into our companies. And you're a CTO of a healthcare company right now. And we don't want to build a healthcare company, we want to build a Scrum company.' ‘So, why don't you create Scrum Inc. right here in the venture group? We'll support it, we'll do the administrative support. We'll write you a check - whatever you want.' So, I said, ‘well, I'm not going to take any money because I don't need it. I understand how that works. If the venture capital firm owns your company, then (in the) long term, you're essentially their slave for several years. So, I'm not taking any money. But I will create the company within the venture group. If you provide the administrative support, I'll give you 10% of the revenue and you can do all the finances and all that kind of stuff. So, that's the way Scrum Inc. was started to enable an investment firm to launch or support or invest in many dozens of Scrum companies. Ula Ojiaku: That's awesome Jeff Sutherland: And today, we're on the sixth round of investment at OpenView Venture Partners, which was the company the six round is 525 million. There's a spin out from OpenView that I'm working with, that has around this year, 25 million. And over the years, just co-investing with the venture group I have my own investment fund of 50 million. So, we have $570 million, right this year 2021 that we're putting into Scrum companies. Agile companies, preferably Scrum. Ula Ojiaku: Now when you say Scrum companies is it that they facilitate the (Scrum) training and offer consulting services in Scrum or is it that those companies operate and you know, do what they do by adopting Scrum processes? Jeff Sutherland: Today, Scrum Inc sometimes help some of those companies, but in general, those companies are independently implementing Scrum in their organizations. Ula Ojiaku: Right Jeff Sutherland: And okay, some of them may come to Scrum training, maybe not. But since Scrum is so widely deployed in the industry, Scrum Inc, is only one of 1000 companies doing Scrum training and that sort of stuff. So, they have a wide variety, wide area of where they can get training and also many of the startups, they already know Scrum before they started the company. They are already Agile. So, what we're interested in is to find the company that understands Agile and has the right team players, particularly at the executive level, to actually execute on it. Ula Ojiaku: No matter what the product or services (are)… Jeff Sutherland: Products or services, a lot of them are software tooling companies, but some of them are way beyond that, right? So, turns out that during COVID… COVID was a watershed. The companies that were not agile, they either went bankrupt, or they were crippled. That meant all the Agile companies that could really do this, started grabbing all the market share. And so, many of our companies, their stock price was headed for the moon during COVID. While the non-agile companies were flatlined, or are going out of business, and so the year of COVID was the best business year in the history of venture capital because of Agility. So, as a result, I'm spending half my time really working, investing in companies, and half of my time, working with Scrum (Inc.) and supporting them, helping them move forward. Ula Ojiaku: That's a very impressive resume and career story really Dr. Sutherland. I have a few questions: as you were speaking, you've called Scrum in this conversation, a process, a tooling, the technology. And you know, so for some hardcore Agilists, some people will say, you know, Agile is all about the mindset for you, what would you say that Scrum is it all of these things you've called it or would it be, you know, or it's something (else)...? Jeff Sutherland: So, certainly the (Agile) mindset is important. But from an investment point of view, if the organization can't deliver real value, quickly, agile is just a bunch of nonsense. And we have a huge amount of nonsense out there. In fact, the Standish group has been publishing for decades. 58% of Agile teams are late over budget with unhappy customers. So, when you get these hardcore Agilist, that are talking about mindset, you have to figure out ‘are they in the 42% that actually can do it or are they in the 58% that are crippled?' My major work with Scrum Inc. today is to try to get to fix the bad Scrum out there. That is the biggest problem in the Agile community. People picking up pieces of things, people picking up ideas, and then putting together and then it doesn't work. That is going to that's going to be really bad for agile in the future. If 58% of it continues not to work. So, what we found, I mean, it was really interesting. Several years ago, the senior executive (of) one of the biggest Japanese companies flew to Boston wanted meet with me. And he said to me, ‘the training is not working in Japan for Scrum.' He said, ‘I spent 10 years with Google, in Silicon Valley. So, I know what it looks like what actually works. And I can tell you, it's not working in Japan, because the training is… it's not the training of the Scrum that is high performing. And in fact, our company is 20% owned by Toyota, and we are going to be the trainers of Toyota. And we cannot deliver the training that's currently being given to Toyota, it will not work, it will not fly. And we want to create a company called Scrum Inc. Japan. And we're a multibillion-dollar company, we're ready to invest whatever it takes to make that happen.' To give them the kind of training that will produce the teams that Takeuchi and Nonaka were writing about in the first paper on Scrum. And as we work with them to figure out what needs to be in that training, we found that the Scrum Guide was only 25% of the training. Another 25% was basic Lean concepts and tooling, right? Because the original Scrum paper was all about Lean hardware companies. So Lean is fundamental to Scrum. If you don't understand it, you can't do it. And then third, there are certain patterns of performance that we've developed over the years, we spent 10 years writing a book on patterns - Scrum patterns. And there's about a dozen of those patterns that have to be implemented to get a high performing team. And finally, scaling to multiple teams. It turns out, right about this time I started working with the Japanese, I was at a conference with the Agile Leadership from Intel. And they told me that they'd introduced Scaling Frameworks into Intel division, some of which had more than 500 Scrum teams in the divisions and the Scaling Frameworks had slowed them down. And it made the senior executives furious and they threw them all out and they said, we did not want to hear the word Scrum at Intel anymore. But you guys need to go twice as fast as you're going now. So, they came to me, they said, ‘we're desperate. We have to go twice as fast. We can't even use the word “Scrum”. What should we do?' And they blamed me, they said, ‘Sutherland you're responsible you caused problem, you need to fix it.' So, I started writing down how to do what today we call Scrum at Scale. And everybody, you know, most of those people in the industry were implementing IT scaling frameworks. They were all upset. ‘Why are you writing down another framework?' Well, it's because those IT frameworks do not enable the organization to show Business Agility, and win in the market. And in the best companies in the world, they're being thrown out. So, I've had to write down how do you add, how do you go to hundreds and thousands of Scrum teams - and never slow down as you're adding more and more teams. You know, every team you add is as fast as the first team when you start. Yeah, that's what Scrum at Scale is all about. So, there's two primary things that I'm focused on today. One is to fix all this bad Scrum. Second is to fix the scaling problem. Because it turns out that if you look at the latest surveys from Forbes magazine, and the Scrum Alliance on successful Agile transformations - I learned recently, that almost every company in the world of any significance is going through an Agile transformation or continuing transformation they'd already started years ago. And 53% of them do not meet management expectations. And the MIT Sloan Business Review did an analysis of what happens if an agile transformation fails, and 67% of those companies go out of business. So, this is becoming really serious, right? To be successful today, if you're competing in any significant way, you have to be agile. And number two, if you try to be agile and fail, you have a 67% chance going out of business. And the failure rate is 53%. So, this is the problem that we're wrestling with. And half of that 53% failure is due to the bad Scrum we talked about, but the other half is due because of the leadership not being Agile. Ula Ojiaku: I was just going to say, as you said something about the leadership not being agile. In my experience, you know, as an agile coach in some organizations whilst the teams would embrace you know, Scrum and embrace Agility - the practices and the processes and everything. There's a limit to, you know, how much they can get done… Jeff Sutherland: Absolutely… Ula Ojiaku: …if the leadership are not on board. So… Jeff Sutherland: …you hit this glass ceiling. So, I've been, you know, giving presentations on Agile Transformations around the world. And I can remember multiple times I've had 300 people in the room, say, and I say okay, ‘How many of you are agile, in Agile transformations or continuing the ones you'd started?' Of course, everybody raises their hand. ‘How many of you have waterfall traditional management that expects you to deliver all the old Gantt Chart reports that we always got, and don't understand what you're doing?' There's 300 people in the room and 297 people raised their hand. I said, ‘you need to give your leadership the book by Professor Kotter called Accelerate.' Professor Kotter is one of the leading change experts of the world. Ula Ojiaku: And he also, yeah, He also wrote ‘Leading Change' as well - the book, yes. Jeff Sutherland: And in that book, he says, if the leadership of the Agile part of the organization is traditional in their mindset and requirements, the Agile Transformation will eventually fail 100% of the time. Ula Ojiaku: Those are sobering statistics in terms of, you know, the failure rate and how much of you know the success hinges on business agility and the leadership being agile as well and taking the time to know and care what it means. Yeah. Jeff Sutherland: And what's happening is that the Agile Leadership today, if you look at some of the companies that have been most successful during COVID, one of them is John Deere Corporation, the biggest farm equipment manufacturer in the world, probably the oldest. Their stock price went up more than Amazon during COVID. And the board of directors gave their Agile Leadership, the Agile Coaches, Scrum Masters, the highest award in the Corporation for producing that result. So that's another reason I'm trying to communicate to Agile people. The success and survival of your company depends on you. You think your management's going to save you but no, if they are old-style people, they are going to run that company out of business. And you need to either save it before it goes out of business or run to another company before bad things happen. Ula Ojiaku: It's impressive that, you know, John Deere being a farm equipment manufacturer… I think they were ahead of the curve you know, (compared to some of their contemporaries in that industry as well) and embraced agile ways of working. Do you know how their Agile Leadership were able to quantify their contributions to the company? Jeff Sutherland: John Deere started to get Agile more than 10 years ago. So, they've been at it a long time. But in recent years, they really started to build… build internally… Agile leadership, you know, based on my work and they started applying that across the company. I mean, the major focus has not been software actually – it's been in other parts of the company. What has to happen to run a company that's building tractors? Well, there's all kinds of things that have to happen, you know - purchasing, there's legal, there's acquiring all the pieces, it's putting them together at the assembly line, you know, software is a piece of it. You know, that's probably the easiest piece to fix with Agile, it's the rest of the company that's the challenge. They have started doing that really well which is reflected in their stock price. Ula Ojiaku: Amazing. So, you said something about you know, you're out to fix a couple of things, the problem with bad Scrum out there. And, you know, the problem with scaling agile. Jeff Sutherland: Right Ula Ojiaku: So, with respect to the first one, the point about bad Scrum, what in your experience would be the root cause of bad Scrum implementations in organizations? Jeff Sutherland: There're about 11 things, that if you fix them, the team will go twice as fast. And it's multiplicative. So, you know, we have extensive data on, you know, really big companies. What's the difference between the fastest team and the slowest teams? The fastest teams are 2000 times faster than the slowest teams. So why is that? Well, first, the team has to be small. The optimal team size is four or five people. If you have a 10-person team, that's going to take at least 50% longer to get anything done. If you go out, look at the team size, you'll see companies have even not only ten-people teams, they have 15 people in a team, 25 people in a team, okay? Those teams are never gonna meet Agile performance. Second, the backlog needs to be really ready in a sense of small, it's clearly understood, it's properly prioritized. So, you need somebody managing that backlog that can get it right, because we have extensive data for multiple case studies showing the team's production doubles immediately. As soon as you get that backlog right. So you go into many companies, you'll see, there's still arguing about what's the top priority, right? Or everything's top priority. That's just gonna create a massive mess. Third, teams are constantly interrupted. You know, the only teams I know that aren't interrupted are people… these teams and defense contractors working on top secret stuff. And they work in a locked room, the door, it says ‘no managers can enter' and they don't get interrupted. But for the rest of us, there's always somebody coming in wanting something else done. And there's a way to manage that using a pattern we call the interrupt buffer. And if you don't have that pattern implemented properly, you're gonna go half as fast. If you're lucky, you might go half as fast. Ula Ojiaku: And what do you say the Scrum Master has a part to play in making sure the interrupt buffer is there and it's enforced? Jeff Sutherland: The scrum master needs to set this all up. Fifth, in high performing teams, we see this pattern called swarming, where multiple people are working on a story together. That increases the process efficiency, which doubles the performance of the team. So, if people are specialists working independently, that team is going to be really slow. So I'm up to number five, there are six more things, but you probably want to go through them. It's very clear, what makes agile teams suck, we know exactly why. And it needs to be fixed. So, I appeal to anyone listening to this help fix bad agile, it's hurting us all. Ula Ojiaku: Thank you for sharing that. Would this be in any of any of your books or in any of your articles that you've written? Jeff Sutherland: Yeah, it's everywhere and (in) everything I've written, but the best summary, it's the red book Scrum … Scrum, The Art of Doing Twice the Work and Half the Time And we've had people pick, pick this up. A CEO in Kenya came to New York to one of my courses, he said, ‘Jeff, I just read your book. And I'm CEO with three new energy startups in Kenya. And my teams implemented that, and they're going… they're doing three times the work and a third of the time. So, your book is too conservative.' He says to me, this guy, he only read the book, he had no training. So, this book is enough to really get off on the right foot. And if you're having problems, it's enough to fix things. In fact, recently before COVID when we could get everybody together, we had an Apple employee in the class and she said, Jeff, do you know why Apple always meet its states? I said, no, you know, Apple is really secretive. They don't tell anybody anything. She says ‘it's because they do Scrum by the book.' So, I said, ‘What book?' She says, ‘The Red Book - Scrum, The Art of Doing Twice the Work and Half the Time - they do it exactly by the book.' So, again, my message to the Agilists out there: Apple is winning. They are the most valuable company in the world. And it's because they do Scrum exactly by that book. So, you probably should read it. Ula Ojiaku: Definitely. So going by the book, would you say there's any wriggle room for adapting to one's context, or is it about you know, going, ‘check- we've done page 123…' Jeff Sutherland: Well, the whole thing about adapting is fundamental to Scrum. So, one of the things I'm constantly doing in my talks, training, is I'm going back to before Scrum and reading a paper from the leading researchers on complex adaptive systems, in which they mathematically proved, you model things on the computer, that systems evolve more quickly, if they have more degrees of freedom, up until you hit a boundary where the system goes into a chaotic state. So, from the very beginning in Scrum, maximizing the freedom and the decision capability of the team has been fundamental. And we talked about this as self-organization. Now, unfortunately, that term has been so misused, misunderstood that we had to take self-organization out of the Scrum guide. And what we inserted was self-managing. And we put next to it goals, okay, the theme is self-managing to achieve a goal. And to make that happen, they need a commitment to do that. And so, this is one of the fundamental things for Agile teams that work that they have that self-managing commitment to achieve a goal. And the teams that are not working, they're fuzzy about that, right. So, we want the maximum degree of adaptation, the thing that they don't want to change is the basic structure that's in the red book, if they change that, it has the control mechanisms to allow the maximum degree of self-organization - not to go off the rails. Ula Ojiaku: Right. Jeff Sutherland: So, we see a lot of Agilists, ‘oh, you know, let's just tweak the framework this way or that way.' And then the self-organization takes a team off the rails, and then they fall into that 58% that can't deliver, they're late, they're over budget, the customers aren't happy. And so, this is the really one of the hardest things to communicate to people. There're certain things that you absolutely have to be disciplined about. You have to be more disciplined to get a great Agile team than in all ways of working. And that discipline is what allows the maximum degree of self-organization and self-determination, right? So, understanding those two things together, you know, it makes it makes people's brain explode, right? It's hard. Ula Ojiaku: But it works. Jeff Sutherland: But it works right. Ula Ojiaku: You've already mentioned a lot of books in the course of this interview session, and these would be in the show notes. So, would there be anything any final word of advice you'd have for the leaders that would be listening to this podcast in terms of their transformation journey? Jeff Sutherland: So, one of the things we did to Scrum at Scale is that the difference between that and most of the other scaling frameworks is that it's all about the leadership. So, we need an operating leadership team, that is a Scrum team that needs a Scrum Master, a Product Owner, backlog. And its objective is to improve the Agile implementation of the organization. On the prioritization side, we need a leadership team that, led by a Chief Product Owner, that is prioritizing backlog across the organization. So, you know, I've had the Chief Product Owner of Hewlett Packard in my course, he had a $200 billion portfolio. He learned from that class. Says this class is pretty good.' He said, ‘In just one slide I figured out how to get $20 billion more a year with no additional resources'. Just by understanding how to work the framework right? At the $200 billion level. Ula Ojiaku: And you're talking about the Scrum at Scale course, right? Jeff Sutherland: No, this was a product owner course. Product Owner course. He came to it. We're now doing a Scrum at Scale… we're actually doing a Chief Product Owner course. So, a Product Owners at Scale course which it has been really well received by the leading Agile Practitioners. (They) really like that because they need to work more in the large than in the small often. Ula Ojiaku: Definitely. That means this available on the Scrum Inc site? Jeff Sutherland: Yes. Ula Ojiaku: Okay. Jeff Sutherland: So, one of the things I would recommend I would really recommend is the Scrum Field Book. It's a bunch of case studies for organizations, large and small, that have tried to take the whole organization to Scrum. Well, thank you so much, Dr. Sutherland - it's been a great pleasure having you and hopefully we could have a you know, follow up conversation sometime. Jeff Sutherland: Yes. Thanks for inviting me and glad to do it again. Ula Ojiaku: That's all we have for now. Thanks for listening. If you liked this show, do subscribe at www.agileinnovationleaders.com. Also share with friends and leave a review. This would help others find the show. I'd also love to hear from you, so please drop me an email at ula@agileinnovationleaders.com. Till next time, take care and God bless!

covid-19 god ceo new york university amazon time founders head game art google starting apple work japan innovation japanese vice president medicine north america forbes fortune massachusetts md silicon valley ceos scale stanford kenya air force kent stanford university intel cto corporations nigerians toyota archives psychiatry modeling venture capital agile harvard business review accelerate west point cios project management agility scrum sutherland modelling john deere hewlett packard product marketing xp software development air force academy radiology united states military academy leading change colorado school product owners scrum masters national cancer institute hollander gantt business agility ail agile transformation agile manifesto standish agile leadership extreme programming jeff sutherland easel openview kent beck covid covid scrum alliance takeuchi agile coaches scrum guide doing twice agilist ken schwaber scrum the art steven goldman openview venture partners scrum inc agilists scrum scale scrum scrum

Are User Stories & Story Points Required? No... - Mike Cohn

story points required user scrum scrum masters user stories scrum guide story points mike cohn

Play Episode Listen Later Mar 5, 2024 8:25

Are User Stories & Story Points Required? No... - Mike Cohn I'm often asked if user stories are part of Scrum.No, they're not. You can have a phenomenally successful team and never work with user stories at all.At its core Scrum is a very small set of rules. The Scrum rules are defined in the Scrum Guide, and they're things like keeping sprints short, no longer than a month.Outside this core of rules are the generally accepted Scrum practices. These are good ideas every Scrum Master should be aware of, but that a team doesn't necessarily need to do. User stories fit here.A great Scrum Master should know what user stories are. They may think stories are awful and not recommend using them for a team, but they should at least know what they are.What about Story Points?Story points are another generally accepted Scrum practice that isn't officially part of Scrum.Story points are a useful way for team members to agree on an estimate. Points get around a common problem: A senior team member thinks something will take one day, a junior team member thinks two days, and they're both right depending on who does the task.I think story points are great because they help you avoid pointless debates, they save time, and they increase the chances that your estimates will be accurate. They are my recommended unit for estimating product backlog items.But not every team needs to estimate! And you certainly don't have to use story points if you do estimate–you can use person days or some other unit if you prefer.I do, however, think that you should give story points and user stories a try. For the majority of teams, they are both great practices that will help you succeed with agile, How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Why Are We Afraid Of The Word “Do”?

Badass Agile

Play Episode Listen Later Feb 29, 2024 14:08

In this episode, "Why Are We Afraid of the word 'DO,'" I want to talk to you about accountability and commitment in the agile leadership space. You're not paid to obey the Scrum Guide...you're paid to deliver promises to your team and ultimately your customer...

afraid scrum guide

EPISODE 19: Fun With Purpose: A Scrum Guide!

Compromising Positions - A Cyber Security Podcast

Play Episode Listen Later Feb 29, 2024 38:53

Welcome to Compromising Positions! The tech podcast that asks non-cybersecurity professionals what we in the industry can do to make their lives easier and help make our organisations more prepared to face ever-changing human-centric cyber threats! This Episode we are joined by Amy Kouppas, a Scrum Master, D&I lead, and founder of a Women's Health & Wellbeing group at Sky. We are talking about all things agile and scrum! Most organisations have some form of agile methodologies, and the likelihood is, yours does too but what is it? What is Kanban? What is Scrum? What does a Scrum master do and why are they always sprinting? Amy helps us answer these questions and more in this episode: Fun with Purpose - A Scrum Guide! In this Episode we cover:Scrum Master: Coach, Not Boss: Ditch the project manager stereotype. A scrum master is a facilitator, coach, and mentor, guiding the team towards self-organisation and autonomy. Their ultimate goal? To make themselves obsolete by fostering a team that thrives independently.Empowerment & Creativity: Scrum unleashes the full potential of your team. They become accountable, empowered, and free to be creative within the sprint framework. This fosters a culture of continuous improvement where everyone contributes to success.Documentation - Enough is Enough: The agile manifesto doesn't advocate for zero documentation. It emphasises "just enough" documentation. Focus on clear, concise information that supports transparency and efficient collaboration.Retrospectives with a Twist: Retrospectives are the beating heart of scrum. Make them engaging and fun with themes, games, and even time capsules. This playful approach fosters honest reflection and continuous improvement.Links to everything we discussed in this episode can be found in the show notes and if you liked the show, please do leave us a review. Follow us on all good podcasting platforms and via our YouTube channel, and don't forget to share on LinkedIn and in your teams.It really helps us spread the word and get high-quality guests, on future episodes. We hope you enjoyed this episode - See you next time, keep secure, and don't forget to ask yourself, ‘Am I the compromising position here?' Show NotesThe Agile ManifestoJeff's quote source for ‘If You're Not Keeping Score, You're Just Practicing' is attributed to Chris McChesneyA Video of Lianne and Jeff's talk on Ab(user) Stories and Ab(use) casesThe stat 1 cybersecurity professional per 100 developers can be found in Toby Irvine's article The RatioAbout AMY KOUPPASAmy Kouppas is a Scrum Master and D&I Lead for Digital technology at Sky, with a passion for squad wellbeing. She is also a Cribologist and Founder of the Leeds Site Women's Health and Wellbeing Group. Amy's personal brand is "fun with purpose," and she aspires to be a mentor and coach to others and champion her women's wellbeing group and festival one day. In addition, she dreams of owning an animal shelter.LINKS FOR AMY KOUpPASAmy's LinkedInKeywords: cybersecurity, scrum, agile, team management, empowerment, continuous improvement, retrospectives, collaboration, documentation

women founders health stories digital fun focus empowerment ab wellbeing scrum kanban scrum masters retrospectives scrum guide ilead

How can I scale Scrum? The Nexus Framework (Part 2) with Rich Hundhausen

Play Episode Listen Later Feb 2, 2024 32:23

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!

rich team touch scale integration framework developers nexus stakeholders scrum product owners scrum masters nexus event scrums scrum teams scrum guide daily scrum patricia kong agilethought

#78 A Year in Review: The Best Moments and Insights of 2023

Play Episode Listen Later Dec 13, 2023 34:36

Embark on a captivating journey through the Agile Mentors Podcast in 2023 with Brian Milner. Explore a spectrum of Agile topics, from Scrum Master challenges to leadership insights. Join Brian for insightful summaries, memorable moments, and a walk through the rich tapestry of Agile wisdom on the show. Overview In this episode of the Agile Mentors Podcast, Brian embarks on a retrospective journey through the standout moments of the podcast in 2023. Explore carefully curated episodes, offering solutions to the common challenges and then delving into the world of Agile beyond software development. Listen in as Brian shares insightful summaries featuring memorable moments and a diverse landscape of Agile wisdom shared by his esteemed guests. Categorized into topics like Scrum Masters, Product Owners, Developers, Agile’s use beyond software, general career advice, and leadership and coaching, this retrospective is a treasure trove of practical advice, actionable insights, and real-world experiences. Tune in for an inspiring tour through the rich tapestry of the Agile Mentors Podcast 2023 episodes. Listen Now to Discover: [01:16] - Brian introduces the episode and invites listeners to join him in a retrospective of the year's episodes, highlighting ones that may have been missed or are hidden gems worth revisiting, which he will group by listener preferences and areas of interest. [02:39] - For Scrum Masters: Brian begins discussing the first episodes tailored for Scrum Masters, kicking things off with #47, "Exploring Lean Thinking and Agile Development," featuring guest Bob Payne, who shares insights into lean thinking, a foundational principle in agile development. Brian recommends this episode for Scrum Masters aiming to enhance their understanding of Agile's fundamentals. [03:34] - Episode #52, "The Birth of Agile: How 17 Adventurous Techies Changed the World," features Agile icon Mr. Jim Highsmith, one of the authors of the Agile Manifesto. Jim provides a glimpse into the past and offers insights into the future of Agile. [04:06] - Episode #59, "Revising the Scrum Guide," features Don McGreal, who played a key role in the guide's revision, shedding light on the thinking behind the revisions. [05:31] - In Episode #62, "Effective Sprint Goals," Maarten Dalmijn delves into effective crafting techniques and the finer details of achieving success with Sprint Goals. [06:12] - In Episode #69, "Should Scrum Masters Be Technical with Allison Pollard," Allison and Brian explore the question of whether Scrum Masters should possess technical skills. If you grapple with how technical a Scrum Master should be, this episode provides valuable insights and perspectives. [06:51] - In Episode #39, Mike Cohn, an authority on user stories, shares valuable insights into the art of crafting effective user stories. [07:15] - In Episode #65 with Randy Hale titled "Unlocking Lean Portfolio Management," Brian and Randy explore the concept of moving beyond a single-team focus as a product owner, delving into the realm of lean portfolio management building upon insights shared by Bob in episode #47. [07:50] - For Product Owners: Must listen bonus from last year, Episode #22, with Roman Pichler, who shares his insights on "How to Create Helpful Product Roadmaps," addressing challenges commonly faced by product owners in dealing with the nuanced aspects of their role. The episode covers strategies to avoid pitfalls, especially the dangers of rigidly locking into scope and schedule timelines. [08:54] - For Developers: Episode #33, "Mob Programming with Woody Zuill," introduces developers to the transformative practice of mob programming. Woody Zuill, a pioneer in this way of working, shares insights and a practical and thoughtful approach that makes it worth exploring. [10:00] - In Episode #48, Brian hosts a unique episode featuring the renowned Lisa Crispin and Janet Gregory, experts in Agile testing, in a show called "Holistic Agile Testing." This episode is particularly recommended for developers specializing in testing or involved in testing within a Scrum team. [11:00] - In Episode #54, "Unlocking Agile's Power in the World of Data Science," Brian and Lance Dacy explore the intersection of Agile methodologies and data science. The popularity of this episode prompted a sequel, Episode #63, on the fusion of Agile and data science. [11:58] - In the final developer-focused episode, Carlos Nunez joins Brian to delve into the world of DevOps. Carlos, a speaker at Agile 2023, shares insights on the significance of DevOps in today's Agile landscape, emphasizing DevOps as a means of empowerment rather than gatekeeping. [12:38] - Agile Outside of Software: Episode #32 with Cort Sharp focuses on Scrum in High School Sports—specifically high school swimming. Cort shares his experience applying Scrum principles to create practice schedules and routines for the swim team he coaches, providing valuable insights for those interested in using Agile beyond the software realm. [13:24] - In #38: "Using Agile for Social and Societal Transformation with Kubair Shirazee," Kubair walks listeners through how his nonprofit employs Agile methodologies to empower micro-entrepreneurs in developing countries. The episode highlights success stories, such as a barber's journey from a rented spot to owning a professional store, demonstrating Agile's transformative impact beyond the tech industry. [14:40] - Episode #45 with Scott Dunn explores "Overcoming Agile Challenges in Regulatory Environments." This crucial topic addresses the unique challenges faced in tightly regulated sectors like government, legal, and medical professions, offering a compelling dialogue on navigating regulatory hurdles within an agile framework. [16:00] - Episode #64 features John Grant discussing "How Agile Methodologies Reshape Legal Practices." This episode reveals the transformative impact of Agile in the legal profession and offers a unique perspective on Agile as a philosophy rather than just a practice, illustrating its broader applicability beyond the software realm. [17:00] - Today's episode is brought to you by Mountain Goat Software's Certified Scrum Product Owner (CSPO) course. This is a two-day training course taught by one of our certified Scrum trainers that teaches you how to use the product backlog as a tool for project success and how to respond to changes in business conditions by restructuring the product backlog. For the schedule, visit the Mountain Goat Training Schedule. [17:27] - General Career Advice: #34: "I'm Trained, Now What? with Julie Chickering" addresses the post-training phase for Scrum Masters and Product Owners. Julie shares insights on taking the next steps, implementing knowledge, and finding opportunities to build a resume in Agile roles. [18:29] - In #40: "Is it Time to Go Out on Your Own? Tips and Insights with Chris Li" Brian and Chris Li discuss considerations for those at later stages of their careers contemplating the transition to independent consulting. If you're pondering whether it's time to establish your consultancy, this episode provides valuable insights and considerations to guide your decision-making process. [19:00] - In #42: "The Importance of Self-Mastery with Bob Galen," Bob emphasizes the value of constant learning, even after years of experience, highlighting the importance of staying open to new discoveries and others' experiences. This episode serves as a compelling guide for personal growth and continuous improvement. [20:28] - Episode #46 with Christina Ambers: In this episode, Christina shares insights on "How to Assess Company Culture Before Accepting a Job Offer." As the year closes and people consider new job opportunities, Christina guides listeners through the crucial step of evaluating company culture and the importance of understanding if a company truly embraces Agile values or merely pays lip service to them. [21:14] - Episode #50 celebrated the milestone of the 50th episode. Lance Dacy was on the show to discuss "Choosing Your Path: Exploring the Roles of Scrum Master and Product Owner." The episode offers guidance for individuals at crossroads, helping them decide between Scrum Master and Product Owner roles. It serves as a valuable resource for those navigating career decisions in the Agile landscape. [22:13] - Leadership and Coaching: In the Leadership and Coaching category, Episode #37 features Brad Swanson discussing "Servant Leadership, Not Spineless Leadership." Brad dispels misconceptions and offers valuable insights into the essence of servant leadership, making it a compelling resource for those interested in effective leadership approaches. [23:28] - In Episode 41, Karim Harbott explores "Cultural Transformations in Organizations." The episode delves into the challenges of changing organizational culture, emphasizing the time and effort required beyond implementing specific practices. [24:00] - In "#44: Transformations Take People with Anu Smalley", Anu highlights the often-overlooked aspect of involving people in organizational transformations, shedding light on the human dynamics that can either support or hinder the process. [24:35] - In Episode #53, "Debunking Myths in Agile Coaching with Lucy O'Keefe," we tackle the common myths surrounding Agile coaching and provide insights on unlocking excellence in Agile coaching practices. [25:01] - Episode #66 is a solo episode where Brian shares his insights into navigating team conflicts, laying the foundation for understanding and mastering the essential skill of conflict navigation. [26:00] - In Episode #68, Brian hosts Mike Hall for a discussion of "The Pros and Cons and Real-World Applications of SAFe." Whether you're new to SAFe or deeply involved, Mike's expertise provides valuable perspectives and tips for navigating this framework. [26:42] - In Episode #70, Mike Cohn joins Brian to explore "The Role of a Leader in Agile." Here, Mike shares valuable insights based on his extensive experience, offering sound advice and perspective on the crucial role of leaders in self-organizing teams. [28:10] - Brian encourages listeners, especially newcomers, to explore relevant episodes based on their roles, with the goal being to offer practical advice and solutions on specific issues rather than lengthy discussions. All episodes are available in the show notes for convenient access. [29:33] - Brian expresses gratitude to listeners for the past year, reflecting on the unique nature of podcasting and letting listeners know he cherishes the encouragement and connections made, especially at events like Agile 2023. [31:00] - What do you want to hear in 2024? What are some of the hot-button topics that haven’t been covered on the show or guests you want to hear from? Send Brian an email with your ideas. [32:28] - And don’t forget to share and subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode. [33:00] - We also have our Agile Mentors Community, where we have discussions about every podcast [33:24] - Wishing you a Happy Holiday Season! We'll see you early again in 2024. References and resources mentioned in the show: #47: Exploring Lean Thinking in Agile Development with Bob Payne #52: The Birth of Agile: How 17 Adventurous Techies Changed the World with Jim Highsmith #59: Revising the Scrum Guide with Don McGreal #62: Effective Sprint Goals with Maarten Dalmijn #69: Should Scrum Masters Be Technical with Allison Pollard #39: The Art of Writing User Stories with Mike Cohn #65: Unlocking Lean Portfolio Management with Randy Hale #22: How to Create Helpful Product Roadmaps with Roman Pichler #33 Mob Programming with Woody Zuill #48: Holistic Agile Testing with Lisa Crispin and Janet Gregory #54 Unlocking Agile's Power in the World of Data Science #63: The Interplay Between Data Science and Agile with Lance Dacy #71: The World of DevOps with Carlos Nunez #32: Scrum in High School Sports with Cort Sharp #38: Using Agile for Social and Societal Transformation with Kubair Shirazee #45: Overcoming the Challenges of Agile in Regulatory Environments with Scott Dunn #64: How Agile Methodologies are Reshaping Legal Practices with John Grant #34: I'm Trained, Now What? with Julie Chickering #40: Is it Time to Go Out on Your Own? Tips and Insights with Chris Li #42: The Importance of Self-Mastery with Bob Galen #46: How to Assess Company Culture Before Accepting a Job Offer with Christina Ambers #50: Choosing Your Path: Exploring the Roles of Scrum Master and Product Owner with Lance Dacy #37: Servant Leadership, Not Spineless Leadership with Brad Swanson #41: Cultural Transformation in Organizations with Karim Harbott #53: Agile Coaching: Debunking Myths and Unlocking Excellence with Lucy O'Keefe #66: Successful Strategies for Navigating Team Conflicts #68: The Pros and Cons and Real World Applications of SAFe with Mike Hall #70: The Role of a Leader in Agile with Mike Cohn #49: Celebrating One Year: A Look Back at 50 Episodes of the Agile Mentor Podcast Certified Scrum Master Training and Scrum Certification Certified Scrum Product Owner Training Advanced Certified ScrumMaster® Advanced Certified Scrum Product Owner® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast on Apple Podcasts Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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.

Scrum Guide Update!? Scrum Master Now Scrum Manager? Don McGreal

The Agile Wire

Play Episode Listen Later Nov 29, 2023 34:11

00:00 Intro 01:06 Tasty Cupcakes 02:30 Creation of the PSPO Course 05:40 Product Ownership for Executives 13:51 Scaling the Product Owner 15:18 Project vs Product 17:33 The WIP Disease 22:50 Agile Coaching 26:36 Scrum Master or Manager? 32:32 improving.com ---------------------------------------------------------------- Connect with us at the following places: Wisconsin Agility Training: https://wisconsinagility.com/training Advising: https://wisconsinagility.com/advising Merch: https://wisconsinagility.com/merch Jeff Bubolz Jeff Bubolz LinkedIn: https://www.linkedin.com/in/jeffbubolz/ Jeff Bubolz Twitter: https://twitter.com/JeffBubolz Chad Beier Chad Beier LinkedIn: https://www.linkedin.com/in/chadbeier/ Agile Songs YouTube: https://www.youtube.com/@agilesongs Agile Songs Shorts: https://www.youtube.com/@agilesongs/shorts Agile Songs Twitter: https://twitter.com/AgileSongs The Agile Wire Web: https://theagilewire.com Spotify: https://open.spotify.com/show/0YKEHJtcJXZ55ohsUOvklI Apple Podcasts: https://podcasts.apple.com/us/podcast/the-agile-wire/id1455057621 Agile Wire Clips: https://www.youtube.com/playlist?list=PLLl0ryedF7y7HWTsbur4ysdpUcY7tniSG Agile Wire Twitter: https://twitter.com/AgileWire Make sure you subscribe to the channel! #Scrum #Agile #ProfessionalScrum #Kanban #BusinessAgility

project scaling scrum masters scrum guide product ownership mcgreal scrum manager

From Agile Coach to Manager with Hal Hogue

Play Episode Listen Later Nov 10, 2023 38:21

This week, Dan Neumann and his co-host Justin Thatil are joined by Hal Hogue, who has transitioned from an Agile Coach position to a Managing role and today shares the features of such a shift. In this episode, Hal discusses his journey from working with managing engineers to becoming one of them. He mentions the particularities of both of these roles, the overlaps between them, and how these positions can work together to advocate for Agility and fast flow. Key Takeaways What are Agile Coaches? The Agile Coach is a leader (just like the Manager). Agile Coaches are focused on letting others grow (individuals or Teams). Agile Coaches also serve as teachers. Coaches teach the true meaning of being Agile by living the values and principles specified in the Manifesto. Agile Coaches are change agents, helping organizations avoid becoming stagnant. The manager role is not defined in the Scrum Guide, but that does not mean it cannot exit. Manager accountabilities: A Manager's first responsibility is to know about the people part of the Team. A Manager needs to know what motivates the Team and their aspirations. It requires a lot of active listening and asking questions. A Manager should set clear expectations and roles for the Team. The Team should clearly know the reasons why they do their jobs. There is a critical relationship between the Engineering Manager and the Product Owner. These two roles need constant communication, aligning goals not only for the product but also around quality. A Manager should not decide things for the Team but should take essential matters to the Team and let them be part of designing the solution by giving them options and tools; this requires a lot of trust in both directions. Managers can help with impediment escalation or performance issues. The Engineering Manager and Product Owner is a critical relationship, as well as the Manager and Agile Coach or Scrum Master. A leader must be a coach and a servant leader for the Team but also for the Product Owner. A Coach can help a Manager understand what Agility is, its principles, and its values. Mentioned in this Episode: Team Topologies: Organizing Business and Technology Teams for Fast Flow, by Matthew Skelton and Manuel Pais 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!

coach managing team touch coaches managers manifesto agile hal agility product owners scrum masters engineering manager agile coach hogue agile coaches scrum guide technology teams fast flow agilethought

Redundant But NOT Irrelevant - The Mission of a ScrumMaster

mission chatgpt accountability tasks agile scrum irrelevant scrum masters redundant agile coaches scrum guide

Play Episode Listen Later Oct 30, 2023 9:12

Making One's Self Redundant “The goal of a Scrum Master is to make themselves redundant” So I preached this mantra, and always managed to get a good deal of nods by those around me. Then came along one day when I was made redundant. Literally. I was hit by a wave of lay offs, and this made me reflect thoroughly on what I had been preaching for so long. In the time I was given to work in that organization, did I succeed in making myself redundant, or did I push myself to the fringes, making myself irrelevant? In the latest version of the Scrum Guide, the authors changed the term “roles” to “accountabilities”. It is because a role has to be filled, an accountability needs to be carried. Often we see organizations looking to “fill in the role” of Scrum Master in order to fix a bureaucratic void, a bucket of disparate and non-value adding tasks that someone needs to carry out but none of the existing personnel are actually willing to. Tasks like “running daily standups” and “updating the team board” top the list. In these situations, organizations are looking to create roles to give such tasks a home, and they call these roles Scrum Masters or Agile Coaches, or any other related fancy name. Accountability demands more than executing such tasks. I link accountability to the impact on outcome. I think Scrum Masters are accountable to keep mastery of Scrum alive among the team members. By this I mean the mastery of thinking about the client, the potentially shippable increments, the prevention of waste generation, the championing of courage, focus, respect, commitment and openness. They do so by coaching, teaching, facilitating and mentoring, and they develop other team and organization members into Scrum Masters. They succeed when most or some of it is done by someone else in the team and not just them. Their own redundancy, in that sense, is part of the accountability Scrum Masters need to carry. I have done my share of slipping into irrelevance myself. Here are some of the ways this irrelevance can manifest itself, and some questions to help mitigate it: When we allow ourselves to calcify in our stances, turning ourselves into uninspired masters of ceremonies. What was the initial objective of this meeting? Is it still relevant to the team's or organization's current situation? If so, in what ways can I help the group remain true and connected to this objective? If not, how can I bring this to the group's eyes in a way that invites them to play a more central part of the meeting's running? When we hold a sentence or phrase from the Scrum Guide above the team's will to experiment and adapt. If we look at the Scrum Guide in its full context, how does the team's idea break any of the values or principles? How can we use the team's enthusiasm and initiative to turn this situation into a learning opportunity, conserving their appetite for experimentation? When we position our opinions and knowledge on Agile above everyone else's, overriding the voice of the team and of the organization. In what ways can we give more space to the team's voice to emerge? What pearls of wisdom can we take away from the team's voice so our teaching stances are more aligned to the their mindset, challenges and innate ideas? When we resist to embrace new ideas, new technologies, like ChatGPT, and remain orthodox in our craft of promoting the habit of learning through experimentation. What is the real challenge behind the method of learning? Why does new technology seem to be a threat? How can we embrace technology to reinforce our teaching message, even if this means dealing with our inner uncertainties and possible failure? https://medium.com/serious-scrum/redundant-but-not-irrelevant-the-mission-of-a-scrum-master-e39ac26d528a 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/

Balancing Technical Prowess with Product Ownership with Erica Menendez and Phillip Lisenba

LeadingAgile SoundNotes: an Agile Podcast

Play Episode Listen Later Oct 13, 2023 29:33

This week, Dan Neumann is joined by Erica Menendez and Phillip Lisenba to explore the Product Owner's accountabilities, especially when they are filled by a highly technical professional, and how this can impact the Team's work in positive and negative ways. They share their own Agile experiences dealing with mature Product Owners and what the Agile and the Scrum framework proposes for these cases. Key Takeaways Challenges and opportunities of dealing with a highly technical Product Owner: The Product Owner's relationship with the Team will determine the extent of the accountabilities on each side. A strong Scrum Master can help balance the Team out due to the collaboration of a technical Product Owner who has brought a lot to the table and helped the Team create a solution. The Team and Product Owner working in a psychologically safe environment grow together in constant intercommunication. A mature Product Owner helps maintain the balance. A very technical Product Owner can be highly prescriptive and fall into the mistake of making highly predictive sprint plans, and, as a result, developers turn more into coders. The Product Owner has to be able to transfer some of their knowledge to the Team since they won't always be there to help them. The Scrum Guide remarks that the Product Owner is the “what” person, and the Team is the “how.” The entire Scrum Team is accountable for creating a valuable, helpful increment every sprint. The Product Owner is responsible for a backlog that optimizes value, and there could be a dysfunction if the Product Owner is disconnected and can't contribute as a partner for a valuable sprint plan. When the Product Owner and the Team can communicate directly, they can take advantage of everyone's skills; that way, they can leverage everything the Team brings. Everything depends on relationships and communication. Mentioned in this Episode: Listen to Podcast Ep 197. Approaching Vacations with an Agile Perspective Get SAFe certified! 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!

team balancing touch technical agile scrum menendez product owners scrum masters prowess scrum teams scrum guide product ownership agilethought

Exploring the Pros and Cons of Product Goals

Play Episode Listen Later Oct 5, 2023 13:00

In 2020, the Scrum Guide introduced the idea of the Product Goal, but left out anything about Vision. Was this move better or worse for Scrum teams?In this short podcast, Vic Bonacci and Dave Prior, our two resident CSTs, sit down to discuss the difference between product goals and vision and the impact this change is making on Scrum Teams. Contacting Vic Bonacci If you'd like to contact Vic you can reach him at: LeadingAgile: https://www.leadingagile.com/guides/victor-bonacci LinkedIn: https://www.linkedin.com/in/vbonacci/ Email: Victor.Bonacci@leadingagile.com Contacting Dave Prior If you'd like to contact Dave, you can reach him at: LeadingAgile: www.leadingagile.com/guides/dave-prior/ LinkedIn: www.linkedin.com/in/mrsungo Twitter: twitter.com/mrsungo Email: dave.prior@leadingagile.com If you have a question you'd like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com Interested in CSM or CSPO Training? You can find all the details at www.leadingagile.com/scrum-training/

vision pros and cons vic scrum csm scrum teams scrum guide bonacci csts leadingagile product goals dave prior product goal

The Daily Scrum Defined

Play Episode Listen Later Aug 16, 2023 8:53

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/⁠

developers sprint defined scrum product owners scrum masters scrum teams scrum guide daily scrum sprint backlog

Is There Ever a Good Time For Multiple Product Owners?

Play Episode Listen Later Aug 15, 2023 6:55

Is There Ever a Good Time For Multiple Product Owners? According to the scrum guide, there should be one product owner who is in charge of the product vision and decides what to do, to create a better product (Not how to do it!) The Scrum Guide states: “The Product Owner is one person, not a committee.” Yet, in some environments companies build products that are so complex and big that they need multiple teams to get the job done. For these situations the Scrum Guide states: “If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.” Contradictory to these suggestions, I observe that several companies feel the urgency to have multiple product owners for these situations. (They often argue that they “inspected and adapted” and in their case it is a necessary step to make Scrum work.) Let me share my thoughts on that. 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/⁠

good time scrum product owners contradictory scrum teams scrum guide product backlog product goal

#59: Revising the Scrum Guide with Don McGreal

Play Episode Listen Later Aug 2, 2023 43:08

In this episode of the Agile Mentors Podcast, Brian welcomes Don McGreal to discuss the revision of the Scrum Guide and the delicate balance between staying true to the core principles of Scrum while allowing for necessary flexibility. Overview In this episode of the Agile Mentors Podcast, Brian is joined by Don McGreal, to delve into the topic of revising the Scrum Guide. Don shares some of the behind-the-scenes of the decision-making process, and the rationale behind the crucial revisions that have shaped the latest version of the Scrum Guide. Listen in to gain a deeper understanding of the principles that guide Scrum and how they continue to evolve and the delicate balance between staying true to the core principles while allowing for necessary flexibility. Listen Now to Discover: [01:11] - Brian welcomes us to the show and introduces his guest, Don McGreal, the Founder and Vice President of Learning Solutions for Improving, author of “The Professional Product Owner” and a big name in the Scrum.org community to talk about revising the Scrum Guide. [04:27] - Don shares how he got involved in revising the Scrum Guide. [05:21] - One team, one group focused on the product. [06:57] - What a scrum team consists of now and why they made the change. [08:11]- We don't expect you to have a title on your business card. [08:53] -The switch from role to accountability. [10:51] - Ten people on a team, one Scrum master, one product owner: It's not illegal in Scrum to take on more than one set of accountabilities or have a bigger team but there are risks involved. [12:51] - Three people using Scrum to work through treatments for a child with autism. [13:34] - Why the team decided to stick with the term "developer." [16:22] - Other terms, including "sprint" and 'backlog" that caused debates and why they stuck. [17:39] - Scrum sounds different because it IS. [18:20] - True Leader: the hot-button topic in the scrum guide that people are still debating, and how they landed on their decision. [19:52] - Clarifying the term "serve" and the need for true leaders who empower the team and make things happen beyond just serving. [21:21] - Today’s show is brought to you by Mountain Goat Software's, Advanced Certified Product Owner® Course, which aims to enhance product owners' skills, confidence, and credibility. The course offers lifetime access to materials and interactive software for valuable and enjoyable breakout exercises. Additionally, participants gain access to Mike Cohn's Agile Mentors Community, with 12 months of ongoing coaching and support. [22:00] - The decision to drop the three questions from the Daily and the new approach. [22:47] - A significant addition to the Scrum framework – the concept of a product goal representing the journey towards a vision. [23:40] - The (results-driven) power of the product goal as inspired by “The 4 Disciplines of Execution." and how it’s changed how backlogs are managed and success is measured. [25:00] - Changing the measure of success: measuring success by value rather than checking things off a backlog list. [25:26] - The vision is the big idea-the product goal is the milestone. It's a step towards the vision. [26:21] - In the revised Scrum Guide, the product goal is now part of the product backlog, emphasizing a commitment to achieving objectives with sprint and product goals focusing on the overall goal, not every task, while the Definition of Done ensures the increment's success. [29:28] - Before the new Scrum Guide, teams working on multiple products had debates on having one prioritized backlog or multiple lists. [30:12] - How the introduction of the product goal in the Scrum Guide directed teams towards having one focused direction, (preventing everything from being equally important). [31:06] - How emphasizing one strategic focus helped teams with multiple products alleviate challenges with prioritizing and improved their approach and alignment. [31:43] - Product backlog with mixed products lacks direction. Product goal provides focus without excluding other items. [33:15] - Some of the controversial changes, like making refinement an event and concerns about terminology like "master" in Scrum roles. [34:49] - The term "immutable" in the Scrum Guide means unchanging, which some find bothersome, but it serves to maintain consistency and distinguish genuine Scrum from modified versions. [36:49] - It's immutable, and it isn't suffocating. It's a lightweight framework described in a 13-page document—there's a lot of wiggle room in there—give it a shot and give it its best chance to succeed by following these simple rules. [37:28] - Change it if you must but then stop calling it Scrum. [38:05] - The sacred text about Scrum is meant to be easy to take on, helpful…AND flexible. [39:22] - Learning from the early days: streamlining a 200-300 page document with legal complexities into the current Scrum Guide, while aiming to distill its essence and promote simplicity and accessibility. [40:48] - You can find out more about Don and Improving by visiting their website. Additionally, Don's book, "The Professional Product Owner," can be found on Amazon. [41:07] - If you enjoyed the episode, the best way to support us is to share it with others and subscribe to the Agile Mentors Podcast on Apple Podcasts. Your feedback is valuable, so feel free to email us by clicking here. References and resources mentioned in the show: Scrum Guides Improving The Professional Product Owner: Leveraging Scrum as a Competitive Advantage Scrum.org The 4 Disciplines of Execution Advanced Certified Scrum Product Owner® Join the Agile Mentors Community Mountain Goat Software Certified Scrum and Agile Training Schedule Subscribe to the Agile Mentors Podcast on Apple Podcasts Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is the SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Don McGreal is Vice President of Learning Solutions at Improving, and author of the best-selling book: 'The Professional Product Owner: Leveraging Scrum as a Competitive Advantage', and a Scrum.org Professional Scrum Trainer who has authored and taught classes for thousands of professionals around the globe.

8 Costly Side Effects of Having an Oversized Product Backlog

leads agile costly side effects stakeholders scrum oversized false sense agile manifesto scrum teams scrum guide product backlog

Play Episode Listen Later Jul 27, 2023 5:47

Here are eight critical side effects of this Product Backlog anti-pattern: Encourages Waste: An oversized Product Backlog fosters waste by investing time in items that may never be developed due to the continuous discovery of more valuable tasks. It's a clear violation of Agile Manifesto principles; particularly, simplicity—the art of maximizing the work not done—is essential. Sunk Cost Fallacy Risk: A large Product Backlog can lead to the sunk cost fallacy. Teams may continue to refine and prioritize items because they've already invested time into them rather than because they add significant value. This behavior contradicts the Agile Manifesto's principle of continuous improvement and adaptation. Leads to Analysis Paralysis: A huge Product Backlog can cause what's known as analysis paralysis, where the sheer volume of items becomes overwhelming, leading to indecision and delay. The team might spend excessive time evaluating, prioritizing, and re-prioritizing items, which detracts from their capacity to focus on actual product development. This excess of choices often slows down decision-making processes, making it difficult for the team to determine where to start or what to focus on next. Ultimately, this slows down the entire project, diverting energy away from creating value for the customer and towards managing the Product Backlog itself. Damages Stakeholder Engagement: A bloated Product Backlog presents a significant challenge regarding effective communication. The vast number of items can make it difficult for stakeholders to comprehend the plan, the progress, and the order of priority, leading to potential misalignment of expectations. Stakeholders may struggle to find their specific interests within the large list, confusing them and potentially causing a feeling of detachment. Crowding Out Effect: A comprehensive, oversized Product Backlog may inadvertently discourage stakeholders and team members from contributing their ideas and insights. The backlog's perceived completeness might give the impression that there's no room or need for additional input, potentially missing valuable ideas and insights. Inhibits Innovation: A huge Product Backlog can unintentionally stifle the creative energy within the Scrum Team. The lengthy list of tasks can create a culture of ‘checking off the boxes' where the team focuses more on completing the tasks rather than exploring and innovating. The team may feel constrained, perceiving that there's no room for new ideas, which can limit their creative problem-solving skills and deter them from finding innovative solutions. This mindset contradicts the Scrum value of ‘openness' and the Agile principle of harnessing change for the customer's competitive advantage. False Sense of Security: An exhaustive Product Backlog may provide a false sense of security, an illusion of control. It might seem like the Scrum team identified all the necessary work, reducing the perceived need for discovery and learning. This misalignment with the Scrum Guide, which advocates for iterative learning and discovery, can be harmful. Encourages Early Optimization: A bulging Product Backlog can lead to premature optimization, as the team may feel compelled to design systems or workflows that anticipate the completion of future backlog items, resulting in unnecessary complexity, contributing to waste if these tasks later change or get deprioritized. This approach conflicts with the Agile principle of simplicity—the art of maximizing the amount of work not done—and the Scrum value of focus, as it encourages effort toward uncertain future needs rather than the most valuable present ones. How to connect with AgileDad: - [website] ⁠https://www.agiledad.com/⁠ - [instagram] ⁠https://www.instagram.com/agile_coach/⁠ - [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠ - [Linkedin] ⁠https://www.linkedin.com/in/leehenson/⁠

What foundational documents are helpful for Agile teams? with Buyi Kalala

Play Episode Listen Later Jul 7, 2023 35:10

This week, Dan Neumann is joined by Buyi Kalala to discuss Agile teams and the fundamental agreements that help to build a strong foundation. In this episode, Dan and Buyi talk about teams, how they operate, how they conduct themselves, and how they achieve consensus about the ultimate goal for the team. Listen to this episode and find a discussion on the Team working Agreement and the value of having a definition of ready and a definition of done. Key Takeaways Team Working Agreement: When creating a Team, you have to consider that you are dealing with many personalities. Every member has to agree on how they will relate to one another and how the team intends to operate. The true intent of a Team Working Agreement is to make that team the most remarkable that it can be. It is a working document designed to help the team be the best it can be. Working agreements can be created for any group of people, including between teams and their stakeholders. The Working Agreement should evolve over time. What is the definition of ready? A checklist of characteristics for a refined Product Backlog Item (PBI) can help ensure that the work is defined enough to include in a Sprint. The team must have alignment and a shared understanding before backlog items are included in a Sprint. There needs to be a structure that identifies who they are doing the work for, why they are doing it, and what that work entails. Remember: Who, What, Where, When, and Why. Revise your Team's definition of ready as needed. Definition of Done: The Definition of Done is included in the Scrum Guide. This can be captured as a list of conditions that must be met before the PBI is accepted by the Product Owner. The Acceptance Criteria are entirely different from the Definition of Done. AC is specific to a User Story. Characteristics of a Definition of Done applies broadly What is done and what isn't? New teams sometimes avoid drawing the line. Remember that 80% done isn't done. Move from implicit to explicit understanding. We need to shift to value-based instead of activity-based. 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!

team touch definition ac characteristics helpful sprint agreement agile documents foundational product owners revise user stories pbi agile teams scrum guide remember who agilethought

From High Performers to Demoralization, And How The Product Owner Role Can Destroy A Scrum Team | Gregory (Greg) Miller

Play Episode Listen Later Jul 4, 2023 12:17

Gregory Miller: From High Performers to Demoralization, And How The Product Owner Role Can Destroy A Scrum Team Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Greg reflects on a team that self-destructed, causing him significant pain. The team, previously considered an exemplary high-performing unit, faced external factors and decisions that disrupted their dynamics. Leadership discussions about replacing their product, the removal of their Product Owner (PO), and a lack of support left the team directionless and demoralized. Greg recognizes the detrimental impact of removing the PO, highlighting it as an anti-pattern that ultimately led to the team's disbandment. This episode serves as a powerful reminder of the importance of providing support, direction, and maintaining team cohesion to foster a thriving and motivated workforce. Featured Book of the Week: "The Scrum Pocket Guide" by Gunther Verheyen In this segment, Greg talks about his most influential book for Scrum Masters, which is "The Scrum Pocket Guide" by Gunther Verheyen, a previous guest on the podcast. He highly recommends this book, as it has been invaluable to him in his role. Greg frequently refers to it and even keeps it on his nightstand for easy access. One aspect that stands out to Greg is Gunther's emphasis on the values side of Agile. The book delves into why the Scrum values are significant and explores their importance in the context of Scrum. Greg appreciates this focus on values as a fundamental aspect of Agile practices. For further exploration of the Scrum values, Greg suggests referring to the values section in the Scrum Guide. Overall, "The Scrum Pocket Guide" has had a profound impact on Greg's understanding of Scrum and serves as a go-to resource for him as a Scrum Master. [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome! About Gregory (Greg) Miller Greg is an Agilist and Coach who has been working in Agile software development for more than 10 years. He hosts The Agile Within podcast with Mark Metze (a previous guest), which promotes agile behaviors and mindset. He lives in Ohio with his wife and four children, two of which are twins. You can link with Gregory (Greg) Miller on LinkedIn and connect with Gregory (Greg) Miller on Twitter.

leadership coach coaching tips ohio team destroy agile sm product management scrum gunther high performers team dynamics product owners scrum masters greg miller team success demoralization scrum teams scrum guide product ownership agilist christopher avery mike cohn linda rising scrum master toolbox podcast product owner role

Sprint Goal - Is It Worth It?

speaking goal product businesses sprint user stories scrum guide sprint goals

Play Episode Listen Later May 30, 2023 9:13

What do we know about Sprint Goals? The 2020 Scrum Guide clearly states that a team commits to a Sprint Goal rather than how many User Stories the team can complete. Having a Sprint Goal is a great idea, but I often see it misfiring. The latest Scrum Guide focuses more on Sprint and Product goals, which is good. However, setting goals will only help us if we change our thinking from output to outcome. If we set goals based on delivering features, we risk still ending up in a feature factory When setting goals, we should have a customer-centric perspective. We need to think as if we are in their shoes. Businesses are often tempted to give IT solutions rather than explain their problems. To tell what functionality or features they need. Speaking in a metaphor, the business is unwilling to let us walk in their shoes.

ScrumWOW - Scrum As An Infomercial

scrum infomercials scrum guide

Play Episode Listen Later May 24, 2023 6:58

ScrumWOW - Scrum As An Infomercial Scrum is more than just a framework, it's a way of life. It's a framework that enables teams to work cohesively towards a common goal, and it's not just for software development teams. It can be used for any project that requires teamwork. Scrum was first introduced in 1995 in “The Scrum Guide” and was based on the concept introduced in 1986 in the article “The New New Product Development Game.” At its core, Scrum consists of three main pillars: transparency, inspection, and adaptation. It's also built on five core values: focus, commitment, respect, courage, and openness. Without these values, the project is doomed to fail. 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/⁠

Replay: Agility with Jeff Sutherland

Hardcore Soft Skills Podcast

Play Episode Listen Later May 2, 2023 25:10

This episode originally aired in July 2021. ------------------------------------------- As many organizations are talking today about becoming “agile” it is important to know what it really means. Dr. Jeff Sutherland (https://www.linkedin.com/in/jeffsutherland/) is the ideal person to discuss this. He is the chairman and founder of Scrum Inc., a signatory of the Agile manifesto, coauthor of the Scrum Guide and the creator Scrum@Scale. He is also the coauthor of the best selling book Scrum: The Art of Doing Twice the Work in Half the Time. Today we talk about the misconceptions of Agile, the origins of the Scrum framework, and how his military experience and his work doing scientific computer modeling influenced him. For more resources, sign up for the newsletter at https://www.hardcoresoftskillspodcast.com/ Connect with me via https://www.linkedin.com/in/yadiraycaro/

time work agile agility scrum jeff sutherland scrum guide doing twice scrum the art scrum inc scrum scale

How can we do Continuous Delivery in Scrum? With Eric Landes

Agile for Humans with Ryan Ripley

Play Episode Listen Later Mar 27, 2023 4:11

In this episode, Eric Landes addresses the challenge of doing Continuous Delivery on a Scrum team. Many teams and organizations struggle with Continuous Delivery, and some think that in a Sprint there can be only one release. Or, they struggle with getting their Increment good enough to be “potentially shippable.” What's a Scrum Team to do? Check out our public Scrum training courses if you want to attend Scrum training. Key Takeaways: The 2020 Scrum Guide talks about Scrum teams creating multiple increments within one Sprint. Now the Scrum Guide is encouraging frequent releases. Which makes my DevOps-focused heart sing! What does this mean to your teams? In my opinion, aiming to deliver to production frequently helps your team focus on quality. The Scrum Guide does not specifically say to release to your customer. Potentially shippable is the term, but I encourage teams to aim for customer feedback through frequently releasing to production! If the team makes releasing to Production part of their DoD, they need to figure out what that means in their organization. How do they ensure high quality and safety for the product before it gets to the customer? For software teams, this would include thinking of automated testing and automated deployments. Teams that adopt these practices include that work when decomposing PBIs into your Sprint plan. This thinking helps the team focus on how they can automate other requirements to meet organization standards and remove bottlenecks to production deployments. For instance, if your organization has compliance policies, your team may be able to automate compliance verification. This can be done using third-party tools, or your team can customize the automation necessary for compliance verification. Discuss these options within your team. Help team members think outside the box for solutions. For organizations that have gates in place, like a change advisory board (CAB), talk through options that meet the requirements. For example, your CAB requires a list of new features that are being deployed. Use release automation to automatically create release notes and notify CAB members of the notes. Most of the time, teams object to continuous delivery based on organizational impediments, not technical ones! Keep this in mind as you encourage your Scrum team to self-manage obstacles. Show others in the organization better ways to ensure the quality and safety organizations strive for in production. Use PBIs to experiment with team members' ideas. As the Product Owner orders an experiment in the backlog and brings it into the Sprint, teams measure the experiment's impact toward continuous delivery. Continue to use the framework to your advantage to achieve Continuous Delivery. This is doable, teams, don't be afraid to use Scrum and Experiment toward Continuous Delivery! Related to this Episode: A complete list of the current Scrum Training by AgileThought. 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!

touch production experiments sprint landes dod devops scrum cab product owners continuous delivery pbis increment scrum teams scrum guide agilethought

YDS: What are the Best Agile Books for a New Scrum Master?

Play Episode Listen Later Mar 21, 2023 1:52

Ryan and Todd suggest their own book, "Fixing Your Scrum," which could be suitable for someone who wants to learn about Agile software development and become a Scrum Master. They also recommend checking out the Scrum Guide, "Scrum Mastery" by Geoff Watts, and the Agile for Humans YouTube channel for additional information. They also mention a few other books, including "Mastering Professional Scrum" by Simon Reindl and Stephanie Ockerman, "Scrum: A Pocket Guide" by Gunther Verheyen, and "Scrum Insights for Practitioners" by Hiren Doshi. ⏩ 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.

amazon community books humans practitioners agile scrum kanban scrum masters scrum guide geoff watts

#39: The Art of Writing User Stories with Mike Cohn

ceo writing run invest svp references agile collectively scrum user stories scrum alliance scrum guide agile alliance mike cohn

Play Episode Listen Later Mar 15, 2023 29:09

Mike Cohn joins Brian to share his experience facilitating story-writing workshops and offers insights on creating effective user stories that deliver value to customers and focus to your team. Overview In this episode of the "Agile Mentors" podcast, Brian is joined by Agile coach and trainer Mike Cohn to discuss the art of writing user stories through story-writing workshops. Mike shares his expertise on the importance of creating user stories, including how to write them effectively and their benefits in the development process. Listen in as Mike provides valuable insights on conducting effective story-writing workshops, including the role of a skilled facilitator, keeping the conversation on track, and how using the INVEST criteria can help you create high-quality user stories that meet the needs of your users. Tune in for practical tips and strategies to improve your user story writing workshops to energize your team while giving them a clear focus on what they need to do. Listen Now to discover: [01:09] - Brian is sitting down with Mike Cohn today to discuss story writing workshops. [01:57] - Mike shares team/stakeholder writing sessions during the early 2000s that morphed into "story writing workshops" to help teams understand what they were doing. [03:37] - Mike explains why he prefers to write 20-30 stories at the start of a quarter, only writing a few new stories during the sprint, then doing another story writing workshop every three months. [05:20] - Brian clarifies that teams don't have to wait for a story writing workshop to write stories. He shares his recommendations for holding story-writing workshops once a quarter to replenish the backlog and "refill the gas tank" with new ideas. [06:03] - Mike expands on the gas tank analogy, explaining that, like filling up a gas tank, teams don't need to wait until the backlog is empty to have a story-writing workshop. [06:52] - Mike shares why he prefers a quarterly approach to story writing for its big-picture view of the coming months. [07:17] - Brian references the 2020 Scrum Guide and suggests using the product goal as the bigger idea to zero in on. [07:32] - Mike agrees with Brian's suggestion of using the product goal as a focal point during story-writing workshops sharing his idea of the importance of something to aim for beyond just the single sprint goal. [07:59] - The importance of focusing a story-writing workshop on a single goal, i.e., setting a product goal for three to six months and using it as the workshop's focus to generate necessary stories. [09:29] - Who should attend a story-writing workshop? Mike offers his suggestions to bring creativity and new ideas and build better products. [11:33] - Mike shares why he believes involving team members in story-writing workshops is a time-saving, worthwhile investment that will improve product outcomes. [12:06] -The tools for a successful story-writing workshop for everyone involved. [13:57] - Mike explains why story-writing workshops might work better online than in person. [17:19] - To keep the conversation on track, having a skilled facilitator for your story-telling workshop is crucial. [17:58] - The importance of having a scrum master or agile coach facilitating story mapping sessions for guidance through any issues with sequencing or organization of ideas. [19:16] - Collectively writing the same story simultaneously vs. brainstorming different stories and then coming together—Mike shares which he prefers and why. [21:34] - Mike shares why saving the story refinement for later is best. [24:05] - The importance of striking a balance between the level of detail in the stories and the time spent on the story-writing workshop. [25:21] - Brian shares a story about an organization he worked with recently at Mountain Goat Software that used the INVEST criteria as a definition of Done to check off every story they wrote. [25:58] - Mike explains the six attributes a team should know to create good user stories. [27:20] - Mike shares why story-writing meetings energize teams, leaving them excited about the product and the upcoming period while giving them a clear focus on what they need to do. References and resources mentioned in the show: How to Run a Successful User Story Writing Workshop Better User Stories Video Course by Mike Cohn 2020 Scrum Guide Join the Agile Mentors Community Mountain Goat Software Certified Scrum and Agile Training Schedule Scrum Alliance Subscribe to the Agile Mentors Podcast on Apple Podcasts Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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 the CEO of Mountain Goat Software and the Co-founder of Agile Alliance and Scrum Alliance. He’s passionate about agile and finds it rewarding when a company really understands agile, commits to doing it well, and succeeds dramatically. Mike’s focus is coaching, training, developing new courses, sharing ideas in his blog posts and tips, and participating in the Agile Mentors Community, especially with the live Q & A sessions.

#39: The Art of Writing User Stories with Mike Cohn

ceo writing run invest svp references agile collectively scrum user stories scrum alliance scrum guide agile alliance mike cohn

Play Episode Listen Later Mar 15, 2023 29:09

#37: Servant Leadership, Not Spineless Leadership with Brad Swanson

Play Episode Listen Later Mar 1, 2023 32:14

Brad Swanson joins Brian to explore the concept of servant leadership and share actionable takeaways to help you lead with compassion and empathy. Overview In this episode of the Agile Mentors podcast, Brad Swanson joins Brian to discuss the concept of servant leadership and how it can be applied in an Agile environment. Learn how to create strong personal connections with your team members, the power of asking powerful questions to foster collaboration, and how to be more assertive as a leader while remaining flexible about the process. Listen in as Brad shares three practical ways that listeners can cultivate a servant leadership mindset and build a positive and productive work environment. Listen Now to discover: [01:48] - Brian introduces Brad Swanson, who has the trifecta of certifications with Scrum Alliance: CST, CEC, and CTC. [02:54] - Brad shares his belief that servant leadership involves prioritizing the needs of the team while cultivating a culture of trust and collaboration. [04:43] - Since the 1970s, the servant leadership concept introduced by Robert K. Greenleaf has involved empowering team members rather than seeing them as subordinates. [07:48] - Brian shares his experience playing football and how it relates to management styles, highlighting that a calm and empowering approach can be more impactful than an authoritative one. [09:55] - Brad shares the idea that effective leadership involves the ability to balance and leverage multiple power styles and shares the book "Leadership Agility" by Bill Joiner and Steven Josephs, which emphasizes the importance of situational leadership. [13:30] - Brad shares his perspective on the shift in the last version of the Scrum Guide from using the term "servant leadership" to "true leadership" and why he prefers the term situational leadership. [15:05] - Brian acknowledges that people have a natural predisposition towards being either assertive or accommodating and how stepping outside of one's comfort zone can lead to both personal growth and an expansion of your skill set. [16:05:] - Brad suggests there is a difference between being assertive and directive. [19:38:] - The effectiveness of asking powerful questions to invite collaboration and reach a mutual goal. [20:17] - The key to being more assertive as a leader without attacking the individual (and remaining flexible about the process). [21:55] - Brad shares three ways listeners can implement a servant leadership mentality. [23:35] - Brian shares how to use a notebook to process your thoughts and ideas while giving others a chance to speak up. [24:38] - Brad shares why listening is a skill that requires frequent practice. [25:15] - Why it’s a good idea to keep your team in the loop about the changes you are trying to make in your leadership style. [26:13] - Why being open and transparent about your efforts to improve can help create a learning environment where improvement is both expected and accepted. [27:05] - Why creating strong personal relationships with the people you are leading is crucial to effective leadership and developing the team's skills. [29:05] - Listeners of the Agile Mentor’s Podcast can get a 10% discount on the Certified Agile Leadership class Brad has coming up on March 27th by using promo code friend10. Find out more by visiting Agility 11. [30:34] - Join the Agile Mentors Community to continue the discussion. You can get a free 12-month membership into the community by taking a class with Mountain Goat Software. References and resources mentioned in the show: What is Servant Leadership? "Servant Leadership: A Journey into the Nature of Legitimate Power and Greatness" "Leadership Agility" Agility 11 Certified Agile Leadership - CAL Essentials & Organizations with Brad Beginning March 27, 2023 - Promo Code: friend10 Mountain Goat Software Certified Scrum and Agile Training Schedule Scrum Alliance Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast on Apple Podcasts Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at 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. Brad Swanson, Founder and Principal Coach and Trainer at Agility 11 helps organizations achieve sustainable success through Lean and Agile principles. With extensive experience as a trusted advisor to executives and organizations worldwide, Brad holds certifications as a Leadership Agility 360 Coach, Agile Leadership Educator, Scrum Trainer, Enterprise Coach, Professional in Agile Coaching, and LeSS Practitioner.

founders coach nature professional trainers organizations svp references agile servant leadership agility scrum cec ctc spineless agile coaching scrum guide leadership agility robert k greenleaf brad swanson

#37: Servant Leadership, Not Spineless Leadership with Brad Swanson

Play Episode Listen Later Mar 1, 2023 32:14

Should I have One Definition of Done? With Eric Landes

Play Episode Listen Later Feb 15, 2023 3:10

In this episode, Eric Landes addresses a question he received while training: “Should we have more than one ‘Definition of Done?'” If you are interested in attending Scrum training, check out our public Scrum training courses. Key Takeaways: This week, let's talk about the Definition of Done. In one of our classes, we had a question about the Definition of Done. Specifically, how many Definitions of Done can a Scrum Team have? So, I went to the Scrum Guide, and here is what that says: "The moment a Product Backlog item meets the Definition of Done, an Increment is born." The guide does not say it meets the sprints Definition of Done or the potentially shippable definition of done. Instead, it states, "the Definition of Done," implying, in my mind, that there is one Definition of Done. In class, we discussed whether there should be a definition of done for releases, for instance. When some organizations release the software, users need to be trained. Marketing materials might need updating, etc. And I understand that these things need to happen. Having one DoD would reduce friction for releasing. No waiting for another team to complete work. The Scrum team controls when they can release. High-maturity teams and organizations are designed this way. But not all organizations are in a place where we can have the Scrum team do everything necessary for release. So the team may have to grow into it. That is ok. Remember where you are headed and make improvements every sprint to put everything necessary for done into your definition. Related to this Episode: A complete list of the current Scrum Training by AgileThought. 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!

marketing touch definition landes dod definitions scrum increment scrum teams scrum guide product backlog agilethought

Responsibilities vs Accountabilities - A Better Understanding of Agile Roles

Play Episode Listen Later Feb 9, 2023 9:23

Responsibilities vs Accountabilities - A Better Understanding of Agile Roles Product Owner: Accountabilities Product Vision: Craft a Product Vision that points the team in a meaningful direction. Product Strategy: Define a strategy enabling the team to decide what to do and what not to do. Goals: Set meaningful goals that enable teams to focus and intensively collaborate towards a unique direction. Value Maximization: Prioritize meaningful problems that maximize the outcomes for users and businesses. Communication: Ensure stakeholders are well-informed about results, decisions, progress, etc. In summary, they should never say, “I was unaware of that.” Responsibilities Stakeholder Management: Engage with stakeholders to partner up and create value for products. This includes organizing meetings, workshops, communication, etc. Backlog Management: Curate, sort, and clean up the Product Backlog to ensure it has the most relevant items to create value. Roadmap: Craft product roadmaps to provide perspective and set expectations on where the product is heading. Monitor results: Constantly evaluate KPIs to understand how the product creates value for end-users. Product Discovery: Ensure continuous learning to enable innovation and solve problems users care about. ScrumMaster: Accountabilities Scrum Understanding: Ensure business stakeholders understand how to play the Scrum game. Atmosphere: Develop a collaborative atmosphere with a balance between learning and delivering. Framework: Ensure that all Scrum events occur and that all artifacts are created as defined in the Scrum Guide. Teams' Effectiveness: Enable the team to grow and become as effective as possible. Enable Self-management: Unleashes the team's potential by helping them become self-managing teams. Responsibilities Ensure the Sprint Retrospective takes place: The Scrum Master may facilitate the Sprint Retrospective, but the responsibility is ensuring that it happens. Another team member can run the show. Ensure Retrospectives End Up with Actions: After each Sprint, Scrum teams discuss how to get better as a team. Scrum Masters ensure the result of the session has clear agreed actions. Coach stakeholders: Invest whatever is necessary to coach key business people to enable teams to thrive with Scrum. Scrum Events: Ensure the team respects the Scrum Events frequency and timeboxes them. Development Team: Accountabilities Quality: Ensure the code meets the agreed quality standards. Scalability: Creates solutions that scale to the required business needs. Efficiency: Guarantee solutions are efficient from the users' perspective. Maintainability: Develop an application that can be maintainable by other professionals. Responsibilities Solution: Implement solutions that solve the agreed problems. Test: Perform required tests to meet the quality expectations. Delivery: Define a delivery process and execute it accordingly. Estimate: Only those who work on the solution can estimate it.

coach responsibility invest roles sprint agile kpis monitor scrum unleashes scrum masters scrum guide product backlog scrum events

Estimation Was Replaced by Sizing In The 2020 Scrum Guide!

replaced sizing estimation scrum guide

Play Episode Listen Later Jan 30, 2023 5:04

I am SO VERY happy with the news that the word estimation was replaced by sizing in the 2020 Scrum Guide! This has been a long time coming and it truly does make sense! Estimation forces us into a time-based way of thinking where sizing is more flexible and allow us to have more freedom with regard to relative sizing and forecasting!

Remember the Future Agile Retrospective, prospecting for risks to prepare for | Fred Deichler