Podcasts about certified scrum trainer

Joel Bancroft-Connors: The No-Scroll Bar Rule—Empowering PO's Through Constraints 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. The Great Product Owner: The Collaborative Innovator Joel describes an exceptional Product Owner scenario at a large insurance organization where complementary skills created magic. Working with two different people - a business expert who understood insurance but lacked development knowledge, and a designer with user experience expertise - Joel suggested the designer take on the Product Owner role while collaborating closely with the business person.  This collaboration between complementary skills produced outstanding results. The great Product Owner understood that their role wasn't to control every detail but to unleash developer creativity by providing problems and context rather than prescriptive solutions. Joel's approach of "give the developers a problem and a canvas" allowed the team to innovate while staying focused on customer needs. This Product Owner fostered innovation rather than preventing it, demonstrating how effective collaboration can transform product development. The Bad Product Owner: The Business Analyst That Couldn't Let Go Joel identifies a problematic anti-pattern: the Business Analyst who transitions to Product Owner but can't abandon their documentation-heavy approach. While Business Analysts can make excellent Product Owners with proper support, those who insist on documenting everything create communication bottlenecks and slow down delivery. This creates a "telephone game" effect between the BA/PO and developers. Joel encountered one such individual who would declare "the developers can't do that" without giving them the opportunity to explore solutions. Following his "no-scroll bar rule" for documentation, Joel emphasizes that Product Owners should provide just enough information to enable developer creativity, not overwhelming detail that stifles innovation. When the problematic BA was replaced with someone who understood customers and trusted developers, the team's innovation flourished. In this segment, we refer to the book Liftoff, by Larsen and Nies. Self-reflection Question: Are you enabling developer innovation by providing problems and context, or are you stifling creativity with excessive documentation and control? [Scrum Master Toolbox Podcast Recommends]

Joel Bancroft-Connors: Sustainable Value—Redefining Success Beyond Profit 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. Joel has evolved his definition of Scrum Master success over time, moving beyond traditional metrics to focus on what truly matters: sustainable value delivery. While Agile principles clearly state the goal of delivering value continuously, Joel emphasizes that success isn't just about making profit - it's about creating sustainable profit through sustainable processes and people practices. He challenges Scrum Masters to consider their "people sustainability metric" and asks whether their approach supports long-term team health and organizational resilience. Joel's definition encompasses three pillars: delivering sustainable value, maintaining sustainable processes, and ensuring sustainability for people. This holistic view of success requires Scrum Masters to think beyond immediate outcomes and consider the long-term impact of their practices. In this segment, we refer to the book Turn the ship around! by David Marquet.  Self-reflection Question: What is your people sustainability metric, and how are you measuring whether your Scrum practices support long-term team and organizational health? Featured Retrospective Format for the Week: Back to Basics Joel advocates for returning to the foundational retrospective format outlined in "Agile Retrospectives" by Derby and Larsen. Rather than getting caught up in complex or creative retrospective techniques, he emphasizes the power of following the basic steps: set the stage, gather data, generate insights, decide what to do, and close the retrospective. Joel stresses that there's an important arc to retrospectives that shouldn't be overlooked. By taking time to properly gather data and following the structured approach from the agile retrospectives book, teams can achieve more meaningful and actionable outcomes. Sometimes the most effective approach is simply executing the fundamentals exceptionally well. In this segment, we refer to the book Agile retrospectives, by Derby and Larsen.  [Scrum Master Toolbox Podcast Recommends]

Joel Bancroft-Connors: The 90-Day Rule—Building Trust Before Disrupting the Status Quo 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. Joel shares his first experience as a CSM at a traditional hard drive manufacturing company, where he learned the art of patient change management. Tasked with bridging the gap between a rigid mothership company and their agile startup division, Joel discovered the power of focusing on principles rather than processes. For six months, he concentrated on creating transparency and shifting focus from status reporting to "getting to done" without ever mentioning Scrum or Agile.  His approach followed what he calls the 90-day rule: "In the first 90 days - do no harm, but then have a plan to do something." By listening first and building trust, Joel helped the team deliver a product in just three months. He emphasizes the importance of making people feel valued and using "future perfect thinking" to envision desired outcomes before introducing change. In this episode we refer to Luke Hohmann's Innovation Games, the website and resource Manager-Tools.com, and Daniel Pink's book Drive. Self-reflection Question: Are you rushing to implement changes, or are you taking time to build trust and understand the current state before introducing new practices? [Scrum Master Toolbox Podcast Recommends]

What does it really mean to have a bias toward action and how do you build that into your culture without skipping strategy? Boris Gloger joins Brian Milner for a deep dive on experimentation, leadership, and the difference between tactical work and true strategic thinking. Overview In this conversation, Brian welcomes longtime Scrum pioneer, consultant, and author Boris Gloger to explore the tension between planning and doing in Agile environments. Boris shares how a bias toward action isn’t about skipping steps—it’s about shortening the cycle between idea and feedback, especially when knowledge gaps or fear of mistakes create inertia. They unpack why experimentation is often misunderstood, what leaders get wrong about failure, and how AI, organizational habits, and strategy-as-practice are reshaping the future of Agile work. References and resources mentioned in the show: Boris Gloger LinkedIn Leaders Guide to Agile eBook 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. Boris Gloger is a pioneering agile strategist and Germany’s first Certified Scrum Trainer, known for shaping how organizations across Europe approach transformation, strategy, and sustainable leadership. As founder of borisgloger consulting, he helps teams and executives navigate complexity—blending modern management, ethical innovation, and even AI—to make agility actually work in the real world. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have the one, the only Mr. Boris Glogger with us. Welcome in Boris. Boris Gloger (00:11) Yeah, thank you, Eurobrein, for having me on your show. Brian Milner (00:14) Very excited to have Boris here. For those of you who haven't crossed paths with Boris, Boris has been involved in the Scrum movement, I would say, since the very, very earliest days. He's a CST, he's a coach, he's an author, he's a keynote speaker. He had a book early called The Agile Fixed Price. He runs his own consultancy in Europe. And he has a new book that's been, that's going to be coming out soon called strategy as practice. And that's one of the reasons we wanted to have Boris on is because there's kind of this topic area that's been percolating that I've heard people talk about quite often. And I see some confused looks when the, when the topic comes up, you hear this term about having a bias toward action. And, we just wanted to kind of dive into that a little bit about what that means to have a bias toward action. and really how we can apply that to what we do in our day-to-day lives. So let's start there, Boris. When you hear that term, having a bias toward action, what does that mean to you? Boris Gloger (01:12) The fun thing is I was always in tune with the idea because people said my basic mantra at the beginning of doing agile was doing as a way of thinking. So the basic idea of agile for me was always experimentation, trying things out, breaking rules, not for the sake of breaking rules, but making to create a new kind of order. the basic idea is like we had with test-driven development at the beginning of all these agile approaches and we said, yeah, we need to test first and then we have the end in our mind, but we don't know exactly how to achieve that. So there is this kind of bias towards action. That's absolutely true. On the other hand, what I've always found fascinating was that even the classical project management methodologies said, Yeah, you have to have a plan, but the second step is to revise that plan. And that was always this, do we plan planning and reality together? And actually for me at the beginning, 35 years ago, was exactly that kind of really cool blend of being able to have a great vision and people like Mike and all these guys, they had always said, we need to have that kind of a vision, we need to know. Yeah, if the product owner was exactly that idea, you have to have that vision, but you really need to get the nitty-gritty details of, so to say, of doing this stuff. Brian Milner (02:40) Yeah, that's awesome. And the thing that kind of always pops to my head when I think about this is, we hear this term bias toward action and there's sort of this balance, I think a little bit between planning and action, right? I mean, you wanna plan, you wanna plan well, but you don't wanna over plan. You don't wanna waste too much time trying to come up with a perfect plan. You wanna... you want to do things, but you also don't want to be, you don't want to rush into things. So how do people find that balance between not just, you know, going off, you know, like we say in the U S half cocked a little bit, you know, like just not, not really not ready to really do the thing that you're going to do. Cause you didn't really invest the time upfront, but on the other hand, not spending so much time that you're trying to get the perfect plan before you do anything. Boris Gloger (03:28) You know, the problem, for me, the issue was solved by when I figured out that the teams typically struggle not to achieve, for instance, the sprint goal or the end or whatever they wanted to accomplish when they have not the right know-how. So it's a knowledge problem. So for instance, I don't know if this is still the case, but sometimes developers say, need to... to immerse myself with that I need to figure that out. I need to get the new framework before I can do something about estimates or something. So whenever you hear that, that you know that person that just tries to give you an estimate or the team that would like to come into a sprint goal or whatever it is, they are not really knowing what topic is about. It's a knowledge gap. And then people tend to go into that analysis paralysis problem. They don't know exactly what they need to do. So therefore they need to investigate. But by doing investigation, you start making that big elephant in the corner, larger and larger and larger and larger because you go that ishikara diagram, you have too many options. It's like playing chess with all options at hand and not have enough experience. What kind of gambit you would like to do. So everything's possible and by, because you have not enough experience, you say everything's possible, that creates too much of a planning hassle. And Agile, is the funny thing is, made us very transparent by just saying, okay, let's spend maybe two weeks. And then we figured out two weeks is too much. So let's do a spike, then we call it a spike. The basic idea was always to have a very short time frame, timeline where we try to bring our know-how to a specific problem, try to solve it as fast as possible. And the funny thing was actually was, as if I I confess myself that I don't know everything, or anything, sorry, that I don't know anything, then I could say, I give me a very short timeline, I could say I spend an hour. And today we have chat, CVT and perplexity and all that stuff. And then we could say, okay, let's spend an hour observation, but then we need to come up with a better idea of what we are talking about. So we can shorten the time cycle. So whenever I experienced teams or even organizations, when they start getting that planning in place, we have a knowledge problem. And a typical that is, is, or the classical mindset always says, okay, then we need to plan more. We need to make that upfront work. For instance, we need to have backlogs and we need to know all these features, even if we don't know what kind of features our client really would like to have. And the actual software problem is saying, okay, let's get out with something that we can deliver. And then we get feedback. And if we understand that our kind of the amount of time we spend is as cheap as possible. So like we use the tools that we have. We used to know how that we have. We try to create something that we can achieve with what we can do already, then we can improve on that. And then we can figure out, we don't know exactly what we might need to have to do more research or ask another consultant or bring in friends from another team to help us with that. Brian Milner (06:46) It's, sounds like the there's a, there's a real, kind of focus then from, from what I'm hearing from you, like a real focus on experimentation and, you know, that, that phrase we hear a lot failing fast, that kind of thing. So how, do you cultivate that? How do you, how do you get the organization to buy in and your team to buy into that idea of. Let's experiment, let's fail fast. And, and, we'll learn more from, from doing that than just, you know, endlessly planning. Boris Gloger (07:12) I think the URCHAR community made a huge mistake of embracing this failure culture all the time. We always tell we need to call from failure because we are all ingrained in a culture in the Western society at least, where we learned through school our parents that making failures is not acceptable. Brian Milner (07:18) Ha ha. Boris Gloger (07:32) And I came across Amy Atkinson and she did a great book to make clear we need to talk about failures and mistakes in a very different kind of way. We need to understand that there are at least three kinds of mistakes that are possible. One is the basic mistake, like a spelling error or you have a context problem in a specific program that you write or you... You break something because you don't know exactly how strong your material is. That is basic mistake. You should know that. That's trainable. The other is the kind of error that you create because the problem you try to solve has too many variables. So that's a complicated problem. You can't foresee all aspects that might happen in future. So typical an airplane is crashing. So you have covered everything you know so far. But then there's some specific problem that nobody could foresee. That's a failure. But it's not something that you can foresee. You can't prevent that. You try to prevent as best as possible. And that's even not an accepted mistake because sometimes people die and you really would like to go against it. So that's the second kind of mistakes you don't like to have. We really like to get out of the system. And then there's a third way kind of mistakes. And that is exactly what we need to have. We need to embrace that experimentation and even experimentation. mean, I started physics in school and in university and an experimental physicists. He's not running an experiment like I just throw a ball around and then I figure out what happens. An experiment is a best guess. You have a theory behind it. You believe that what you deliver or that you try to find out is the best you try to do. The Wright brothers missed their first airplane. I mean, they didn't throw their airplane in the balloon. Then it gets destroyed. They tried whatever they believed is possible. But then you need to understand as a team, as an organization, we have never done this before, so it might get broken. We might learn. For instance, we had once a project where we worked with chemists 10 years ago to splice DNA. So we wanted to understand how DNA is written down in the DNA sequence analyzer. And I needed to understand that we had 90 scientists who created these chemicals to be able to that you can use that in that synthesizer to understand how our DNA is mapped out. And we first need to understand one sprint might get results that 99 of our experience will fail. But again, management said we need to be successful. Yeah, but what is the success in science? I mean, that you know this route of action is not working, right? And that is the kind of failure that we would like to have. And I believe our Agile community need to tell that much more to our clients. It's not like, we need to express failure. No, we don't need to embrace failure. We don't want to have mistakes and we don't want to have complicated issues that might lead to the destroying of our products. need on the other hand, the culture, the experimentation to figure out something that nobody knows so far is acceptable, it's necessary. And then, edge our processes help us again by saying, okay, we can shorten the frame, we can shorten the time frame so that we can create very small, tiny experiments so that in case we are mistaken, Not a big deal. That was the basic idea. Brian Milner (11:04) That's a great point. That's really a great point because you're right. It's not failure in general, right? There are certain kinds of failures that we definitely want to avoid, but there's failure as far as I run an experiment. at that point, that's where we start to enter into this dialogue of it's not really a failure at that point. If you run an experiment and it doesn't turn out the way you expected, it's just an experiment that didn't turn out the way you expected. Boris Gloger (11:30) Basically, every feature we create in software or even in hardware, we have never done it before. So the client or our customers can't use it so far because it's not there. So now we ship it to the client and then he or she might not really use it the way that we believe it is. Is it broken? it a mistake? It was not a mistake. It was an experiment and now we need to adapt on it. And if we can create a system, that was all that was agile, I think was a bot. On very first start, if we can create a system that gives us feedback early. then that guessing can't be so much deviation or say in a different way, our investment in time and material and costs and money and is shortened as much as possible. So we have very small investments. Brian Milner (12:13) Yeah, that's awesome. I'm kind of curious too, because, you know, we, we, we've talked a little bit at the beginning about how, you know, this is part of this bias towards action as part of this entrepreneurial kind of mindset. And I'm curious in your, experience and your consultants experience that you've worked with big companies and small companies, have you noticed a difference in sort of that bias toward action? Uh, you know, that, that kind of. is represented in a different way in a big company versus a more small startup company. Boris Gloger (12:48) The funny thing is I don't believe it's a problem of large corporations or small, tiny little startups, even if we would say that tiny little startups are more in tune in making experiments. It's really a kind of what is my mindset, and the mindset is a strange word, but what is my basic habit about how to embrace new things. What is the way I perceive the world? Every entrepreneur who tries to create it or say it different way, even entrepreneurs nowadays need to create business plans. The basic ideas I can show to investors, everything is already mapped out. I have already clients. I have a proven business model. That is completely crazy because If it were a proof business model, someone else would have already done it, right? So obviously you need to come up with the idea that a kind of entrepreneur mindset is a little bit like I try to create something that is much more interesting to phrase it this way. by creating something, it's like art. You can't, can't... Plan art, I mean, it's impossible. I mean, you might have an idea and you might maybe someone who's writing texts or novels might create a huge outline. But on the other hand, within that outline, he needs to be creative again. And someone will say, I just start by getting continuous feedback. It's always the same. You need to create something to be able to observe it. that was for me, for me, that was the epiphany or the idea 25 years ago was, I don't know what your background is, but I wasn't a business analyst. Business analysts always wanted to write documents that the developer can really implement, right? And then we figured out you can't write down what you need to implement. There's no way of writing requirements in the way that someone else can build it. That's impossible. And even philosophers figure that out 100 years ago is written, Shanti said, you can't tell people what is the case. It's impossible. So, but what you can do, you can create something and you can have it in your review. And then you can start discussing about what you just created. And then you create a new result based on your observations and the next investment that you put in that. And then you create the next version of your product, your feature, your service, et cetera. Brian Milner (15:12) Hmm. Boris Gloger (15:25) And when we came back to the entrepreneur mindset and starting companies, Greaves created exactly that. He said, okay, let's use scrum to come up with as much possibilities for experimentation. And then we will see if it works. Then we can go on at that. And large corporations typically, They have on the one hand side, have too much money. And by having too much money, you would like to get an investment and they have a different problem. Typically large corporations typically needs to, they have already a specific margin with their current running products. And if you come up with a new business feature product, you might not get that as that amount of of revenue or profitability at the beginning. And therefore, can't, corporations have the problem that they have already running business and they are not seeing that they need to spend much, much more money on these opportunities. And maybe over time, that opportunity to make money and that's their problem. So this is the issue. It's not about entrepreneurial mindsets, it's about that. problem that you are not willing to spend that much money as long as you make much more money, it's the same amount of time on your current business. It happens even to myself, We are running a consulting company in Germany and Austria, and Austria is much smaller than Germany's tenth of the size. And if you spend one hour of sales in Austria, you don't make that much money in Austria than you make in Germany. this investment of one hour. Where should you focus? You will always focus on Germany, of course. means obvious. Brian Milner (17:08) Yeah. Yeah. Boris Gloger (17:10) Does it make sense? Maybe I'm running so. Brian Milner (17:14) No, that makes sense. That makes sense entirely. And so I'm kind of curious in this conversation about action and having a bias toward action then, what do you think are some of the, in your experience in working with companies, what have you seen as sort of the common obstacles or barriers, whether that be psychological or. organizational, what do you find as the most common barriers that are preventing people from having that bias toward action? Boris Gloger (17:44) the they are they are afraid of the of that of tapping into the new room endeavor. So that was always my blind spot because I'm an entrepreneur. I love to do new things. I just try things out. If I've either reading a book, and there's a cool idea, I try to what can happen. But we are not And most organizations are not built that way that they're really willing to, when most people are not good in just trying things out. And most people would really like to see how it's done. And most people are not good in... in that have not the imagination what might be possible. That's the we always know that product adoption curve, that the early adopters, the fast followers, the early minority, the late minority. And these inventors or early adopters, they are the ones who can imagine there might be a brighter future if I try that out. And the other ones are the ones who need to see that it is successful. And so whenever you try implementing Scrum or design thinking or mob programming or I don't whatever it is, you will always have people who say it's not possible because I don't have, haven't seen it before. And I sometimes I compare that with how to how kids are learning. Some kids are learning because they see how what is happening. They just mirroring what they see. And some kids are start to invent the same image in imagination. And but both that we are all of us are able to do both. It's not like I'm an imaginary guy who's inventing all the time and I don't, people, maybe there's a preference and the organizations have the same preference. But typically that's the problem that I see in organizations is based on our society and our socialization, on our business behaviors and maybe the pressure of large corporations and all that peer pressure is Brian Milner (19:34) Yeah. Yeah. Boris Gloger (19:54) The willingness to give people the room to try something out is the problem. Well, not the problem, it's the hinders us of being more innovative in organizations. Brian Milner (19:59) Yeah. Yeah. Well, that brings to mind a good question then too, because this experimentation mindset is very, very much a cultural kind of aspect of an organization, which speaks to leadership. And I'm kind of curious from your perspective, if you're a leader, what kind of things can you do as a leader to encourage, foster, of really nurture? that experimentation mindset in your organization. Boris Gloger (20:34) Let's have a very simple example. Everybody of us now maybe have played with chat, CPT, Suno, perplexity and so on. So that's the school AI technology around the corner. And what happens now in organizations is exactly what happens 30 years ago when the internet came here. You have leadership or managers who say, that's a technology, I give it to the teams, they can figure out whatever that is. And the funny thing is, if you have a technology that will change the way we behave, so it's a social technology, a kind of shift, then I need to change my behavior, I need to change the way I do I'm doing things. Yeah, everybody of us has now an iPhone or an Android or whatever it is, but but we are using our mobiles in a completely different way than 30 years ago. And to lead us and manage us, we need to train ourselves first before we can help our teams to change. So the problem is that Again, a lot of Agilist talks about we need, first we need to change the culture of organizations to be able to do Agile and so on and so on. That's complete nonsense. But what we really need to is we need to have managers, team leads, it with team leads, to help them to do the things themselves because Agile, even in the beginning, now it's technology change, now it's AI, is something that changes the way we do our stuff. It's kind of habit. And we need to help them to seize themselves. Maybe they can only seize themselves by doing that stuff. And that goes back to my belief that leadership needs to know much more about the content of their teams and the way these teams can perform their tasks and the technology that is around to be able to thrive in organizations. Brian Milner (22:40) Yeah. Yeah. I love this discussion and I love that you brought up, you know, AI and how that's affecting things here as well. how do you think that's having a, do you think that's making it easier, harder? How do you think AI is, is kind of influencing this bias toward action mentality? Boris Gloger (22:59) Yeah, it depends on if you are able to play. mean, because the funny thing is, it's a new kind of technology. really knows what all these tools can do by themselves. And it's new again. It's not like I have done AI for the next last 10 years and I know exactly what's possible. So we need to play. So you need to log in to adjust it. Yesterday, I tried something on Zulu. I created the company song in 10 seconds. I went to ChatGVT, I said I need a song, I need lyrics for a company song. These are the three words I would like to have, future, Beurus Kluger, and it needs to be that kind of mood. ChatGVT created the song for my lyrics, then they put the lyrics into the... And they created a prompt with ChatGVT and then put that prompt in my lyrics into Sono and Sono created that song within 10 seconds. I mean, it's not get the Grammy. Okay. It's not the Grammy. But it was, I mean, it's, it's, it's okay. Yeah. It's a nice party song. And now, and just playing around. And that is what I would like to see in organizations, that we start to play around with these kind of technologies and involve everybody. But most people, the very discussions that I had in the last couple of weeks or months was about these tools shall do the job exactly the same way as it is done today. So it's like... I create that kind of report. Now I give that to Chet Chibati and Chet Chibati shall create that same report again. That is nonsense. It's like doing photography in the old days, black and white. And now I want to have photography exactly done the same way with my digital camera. And what happened was we used the digital cameras changed completely the way we create photography and art. changed completely, right? And that is the same thing we need to do with ChatGV team. And we need to understand that we don't know exactly how to use it. And then we can enlarge and optimize on one hand the way we are working, for instance, creating 20 different versions for different social media over text or something like that, or 20 new pictures. But if I would like to express myself, so, and... and talk about my own behavior or my own team dynamic and what is the innovation in ourselves, then we need to do ourselves. And we can use, that is the other observation that we made. The funny thing that goes back to the knowledge issue, the funny thing is that teams typically say, I don't know if it's in the US, but at least in my experience, that we still have the problem within teams. that people believe this is my know-how and that is your know-how and I'm a specialist in X or Y set. So they can't talk to each other. But if you use maybe chat GPT and all these tools now, they can bridge these know-how gaps using these tools. And suddenly they can talk to each other much faster. So they get more productive. It's crazy. It's not like I'm now a fool with a tool. I can be a fool and the tool might help me to overcome my knowledge gaps. Brian Milner (26:20) Now this is awesome. I know that your book that's coming out, Strategy is Practice, talks about a lot of these things. Tell us a little bit about this book and kind of what the focus is. Boris Gloger (26:30) the basic idea when I started doing working on the on strategies, we be in the the actual community, we talk about strategy as what is a new idea of being OKR. So OKR equals strategy, and that is not true. And I came up with this basic idea, what is the basic problem of of strategic thinking and we are back to the in most organizations, we still believe strategy is the planning part and then we have an implementation part. And years ago, I came across a very basic, completely different idea that said every action is strategy. Very simple example. You have the strategy in a company that you have a high price policy. Everything you do is high price. But then you are maybe in a situation where you really need money, effort, revenue issues, liquidation, liquidation problems. Then you might reduce your price. And that moment, your strategy is gone. just your obviously and you have now a new strategy. So your actions and your strategies always in line. So it's not the tactic for the strategy, but tactic is strategy. And now we are back to Azure. So now we can say, okay, we need kind of a long-term idea. And now we can use for creating the vision. For instance, you list the V2MOM framework for creating your vision. But now I need to have a possibility to communicate my strategic ideas. And in the Azure community, we know how to do this. We have plannings and we have dailies and we have reviews and retrospectives. So now I can use all these tools. I can use from the bookshelf of Azure tools. I can use maybe OKRs to create a continuous cycle of innovation or communication so that I get that everybody knows now what is the right strategy. And I can feed back with the reviews to management. that the strategy approach might not work that way that they believed it's possible experimentation. And then and I added two more ideas from future insight or strategic foresight, some other people call it. So the basic idea is, how can I still think about the future in an not in the way of that I have a crystal ball. But I could say, how can I influence the future, but I can only influence the future if I have an idea what might be in future. It's like a scenario. Now you can create actions, power these kind of scenarios that you like, or what you need to prevent a specific scenario if you don't like that. And we need a third tool, that was borrowed from ABCD risk planning, was the basic idea, how can I get my very clear a very simple tool to get the tactics or the real environmental changes like suddenly my estimates might not be correct anymore or my suggestions or beliefs about the future might not get true in the future. So I need kind of a system to feed back reality in my strategy. it's a little bit like reviewing all the time the environment. And if you put all that together, then you get a very nice frame how to use strategy on a daily practice. It's not like I do strategy and then have a five-year plan. No, you have to do continuously strategy. And I hope that this will help leaders to do strategy. I mean, because most leaders don't do strategy. They do tactic kind of work. and they don't spend They don't spend enough time in the trenches. to enrich their strategies and their thinking and their vision. because they detach strategy and implementation all the time. That's the basic idea. Brian Milner (30:30) That's awesome. That sounds fascinating. And I can't wait to read that. That sounds like it's going to be a really good book. So we'll make sure that we have links in our show notes to that if anyone wants to find out more information about that or learn more from Boris on this topic. Boris, can't thank you enough for making time for coming on. This has been a fascinating discussion. Thank you for coming on the show. Boris Gloger (30:40) Yeah. Yeah, thank you very much for having me on your show and appreciate that your time and your effort here. Make a deal for the, it's very supporting for the agile community. Thank you for that. Brian Milner (30:57) Absolutely. Yeah, yeah, thank you.

Joel Bancroft-Connors: How Performance Reviews Killed a Great Agile Team 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. Joel tells the story of a team caught in the crossfire of a poorly executed large-scale agile transformation. While the CTO championed going agile, they quickly checked out, leaving the organization without clear direction or understanding of why they were adopting agile practices. The company measured success through output metrics like "number of teams trained" rather than meaningful outcomes. Joel worked with an exceptional team that had built their own collaborative workspace and was performing well, but external forces kept pulling them out of flow. Performance reviews created internal conflict, leading team members to focus on individual success rather than collective achievement. The team ultimately fell into their own traps, with everyone "focusing on themselves and throwing others under the bus." Joel recommends balancing performance evaluations with 50% team-based and 50% individual metrics to prevent this destructive pattern. Self-reflection Question: Does your team truly understand why they are using Scrum, or are they just going through the motions of the framework? Featured Book of the Week: Start with Why by Simon Sinek Joel credits Simon Sinek's "Start with Why" as a transformational influence on his coaching approach. The book's central principle that "people don't buy what you do, they buy why you do it" fundamentally changed how Joel teaches Scrum. He realized he had been teaching Scrum incorrectly by focusing on the mechanics rather than the purpose. Now Joel listens to this book annually and has shifted his focus to helping teams and organizations understand why Scrum matters and why it's important. This shift from teaching the "what" to emphasizing the "why" has made his coaching significantly more effective and meaningful. Joel also mentions the book Coaching Agile Teams by Lyssa Adkins. [Scrum Master Toolbox Podcast Recommends]

Joel Bancroft-Connors: When Great Scrum Masters Fail—The Hidden Cost of Poor Value Communication 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. Joel shares a powerful lesson about the critical importance of communicating value beyond team performance. Despite achieving remarkable success with multiple teams as an agile coach, Joel and his colleagues ultimately failed because they couldn't effectively demonstrate their value to leadership. The teams were thriving, but when budget cuts came, the coaching support was eliminated first. Without ongoing support, these successful teams began to deteriorate. Joel emphasizes that as Scrum Masters and agile coaches, we must actively communicate our impact and connect team success to business outcomes. Simply assuming that good team performance speaks for itself is not enough - we need to interact more with stakeholders and clearly articulate the value we create. In this episode, we refer to the TV series Ted Lasso, and the books Start with Why by Simon Sinek, and Coaching Agile Teams by Lyssa Adkins.  Self-reflection Question: How effectively are you communicating the business value of your Scrum Master activities to leadership, and what specific metrics or stories could better demonstrate your impact? [Scrum Master Toolbox Podcast Recommends]

Real Agile forecasting runs on math, not magic. Brian and Lance dive into Monte Carlo methods, DORA metrics, and how AI is shifting the future of project management. All with a human-first approach that builds better teams, not bigger spreadsheets. Overview In this episode of the Agile Mentors Podcast, Brian Milner and Lance Dacy unpack why Agile teams need to rethink how they forecast work—and why math, not magic, is the real secret. From the roots of Taylorism to today's Monte Carlo simulations, they explore how to navigate uncertainty with data-driven tools like DORA metrics, flow metrics, and probability theory, while keeping the heart of Agile leadership focused on trust, transparency, and better decision-making. References and resources mentioned in the show: Lance Dacy Free Chapters of Agile Estimating and Planning by Mike Cohn 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. Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

What does soccer, soda, and software have in common? According to Jim York—everything. In this episode, he and Brian Milner break down what great teamwork really means, why shared goals matter more than job titles, and how understanding your team’s unique contribution can unlock better flow and results. Overview In this episode of the Agile Mentors Podcast, Brian Milner sits down with veteran Agile coach and trainer Jim York for a deep dive into what makes real teamwork tick. They unpack what separates a group of coworkers from a high-functioning team, explore the role of shared goals in driving motivation, and walk through value stream thinking using vivid analogies from sports and soda cans alike. Whether you're part of a Scrum team or leading cross-functional initiatives, this episode will help you think differently about collaboration, flow, and how teams can work better together. References and resources mentioned in the show: Jim York Jim's Blog Jim's Video Library Lean Thinking: Banish Waste and Create Wealth in Your Corporation by James Womack & Daniel Jones Liftoff Vision: Launching Agile Teams and Projects by Diana Larsen & Ainsley Nies GoatBot 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. Jim York is a business owner helping teams discover how to delight their customers. He uses systems thinking, agile and lean to co-create resilient, learning teams. As a coach, he works with his clients to help them grow in directions that matter to them to achieve their goals. Jim is a Certified Agile Coach®️, holding both the Certified Enterprise Coach and Certified Team Coach credentials; Certified Scrum Trainer®️; Agile Fluency®️ facilitator; LeSS Practitioner. In 2007, Jim co-foundered FoxHedge Ltd with his wife, Melissa York. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We're back here for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have the very distinguished gentleman, Mr. Jim York with us. Welcome in, Jim. Jim York (00:12) Well, thank you, Brian. Glad to be here. Brian Milner (00:15) Very excited to have Jim with us. We were just chatting before and Jim and I met years ago at a conference. We got introduced by a mutual friend, Mr. Kurt Peterson, who has been on the show. He came on a little bit earlier to talk about Kanban. And just for those people who aren't familiar with Jim, Jim is a co-founder of a company called Fox Hedge. And he has been an Agile coach, a Scrum trainer for quite a while now and I give him the title Luminary, kind of scrum luminary, thought leader, been around doing this for a while. I hope that doesn't sound insulting in any way, Jim, to call you that. Jim York (00:55) Nope, nope, just trying to shine my light and help others shine theirs. So that's what a coach does. So. Brian Milner (01:00) Awesome, Cool, well, we wanted to have Jim on because we had this topic that it's kind of a broad topic, but it's, I think, actually crucial to today's world. And that's just the broad topic of teamwork itself. So I'll start this way, Jim. I want to get your opinion. In today's world, with the changing kind of landscape with AI and everything else that we see that's kind of influencing how we work, has teamwork had its day? Is it time now for something new or is teamwork still the best way to build things? Jim York (01:34) Yeah, well, teams are universal. I think once you get more than one single individual and you get some task that requires more than what one person can do, it's inevitable. We've to work together. And so I don't see that going away. It might change a bit. But in many ways, think the things that we face today are, in many ways, things that we faced before. They might be showing up in a different way, but I think there's some universality. universality to teamwork. Brian Milner (02:03) Yeah, I agree. And so what do we mean by teamwork? Why don't we define that a little bit for everyone? Jim York (02:09) Yeah, I guess we have to step back and start looking at what's a team. If we talk about teamwork, there's this whole expression, teamwork makes the teamwork. So what's a team? And the classic definition of a team is it's a group of individuals working on a shared goal. And so it's kind of like built into the definition, we're working on a shared goal. So teamwork is that combined action. Brian Milner (02:13) Yeah. Yeah. Jim York (02:32) And so that's kind of the general concept. It's, you know, some of the parts, you know, is greater than the whole. And so it's taking that mix of experiences, knowledge, skills, and bringing them together and having that dynamic, that energy, and kind of focusing it in the same direction. You know, that's really what teamwork is about. Brian Milner (02:55) Yeah, it's good to clarify it, because I think the word team gets quite widely used in today's world. you'll hear people describe that, hey, that's my sales team. When you look at it and how they actually work together, there's not really a lot of teaming actually happening. It's just a group of individuals who have the same job and that. that format. I do think you're right. It's important to understand the difference between that kind of a team and what we're talking about here as a team. Jim York (03:25) Yeah, there are different kinds of teams and people in a sales team, even if they're not working with each other, the fact that they have a shared goal does create some sense of team. And there's different teamwork where everybody's providing kind of their unique thing. And then you have, I think like a team in a rowing, when you have like four people in a rowboat. they might have somebody who's steering the boat, you know, but they have the four people holding onto the oars and, you know, they're working at a similar cadence. You can say to a certain degree they're individuals. I don't know if they're fungible. I don't think they're necessarily fungible, but they're working together to accomplish that shared goal. know, the people in rowing, that's different from people on like a soccer team. You know, on a soccer team, you're... You got the whole pitch, you know, you're all over the place and the ball's moving around and there's this kind of coming together and going apart of various team members interacting at different places and at different times throughout the game. You're kind of acting dynamically to where the ball is and where the opponents are and where they are on the field. And so there's this creativity that occurs there that's kind of a different kind of creativity than you might see in a rowing type of competition. Brian Milner (04:18) Yeah. Jim York (04:42) But yeah, I think there are different kinds of teams, but I think that universal theme of being a group of individuals that are having that shared goal, I think that's the thing that's in common. It's not the nature of the work that some people might call agile versus predictive or planned work. mean, the concept of a team is more universal thing. Brian Milner (04:43) Yeah. Yeah. I like the example of kind of the crew, right? Of rowing and stuff. I think that's a good picture because you're right. I mean, it's very subtle, but there's a lot of combined movement. And if one person is off a little bit, it really affects how others are working. I've used the example sometimes in my classes as a contrast to think about like a golf team. You know, like the idea that you have the group of people who, again, I say this in classes. So anyone listening to this who's a golf expert, it really loves golf. Please, email in and tell me if I'm wrong about this. But this is what I say in my classes. You know, if you're on a golf team, it's a group of individuals who are each shooting their own 18 holes. But then at the end of the round, you just total up the score. And if you have the lowest lower score than another team, then you win, right? But it's, When I'm shooting my 18 holes, I'm not necessarily aware of what everyone else on my team has done or what they're doing at the same time. We don't play off each other, right? I don't take the first shot and then they take the second shot. It's all on me to do my best. And then hopefully everyone else has done their best and we just kind of see how it works out at the very last second. Yeah. Jim York (06:17) Yeah, so teams are different. know, teams are definitely different. And I think it's that idea of the shared goal that is the thing that kind of the glue that holds the team together and that shared goal that can be at various levels. I mean, it can be at this grand big picture level. You know, sometimes what's referred to as a product vision, it can be at a more discrete team level. Sometimes that's referred to as, you know, our our unique contribution to the product division. So that would be like our team mission. And then there's maybe, you know, a specific task. And so, you know, we might be working on a specific, very small, discrete task. And, you know, there's a potentially a group of people working on that thing. And, and, and those people have that shared goal of moving that task, you know, through a process to a completion state. And so there's, there's some variability here in the different kind of levels and Hopefully, there's some alignment between those different levels when you're talking about a team. Brian Milner (07:14) All right, so there's some different kinds of teams and it kind of is wide ranging in how we would describe it. There's different configurations, but we have a single purpose. We're working together towards a single purpose. That's kind of our unifying factor there. So then what makes teams work? What's the glue other than our purpose? How do we actually... Combine efforts, how do we play off each other's strengths? How does that happen? Jim York (07:47) Yeah, well, it depends, right? I mean, that's the classic consultant's answer. It depends. How do we play off of each other? If you're in an environment where you've got a known solution to a known problem and you're just executing steps in a plan, those dynamics are pretty well understood. People in that process can be trained to do different types of activities. They can gain experience in that. Brian Milner (07:50) Yeah. Jim York (08:08) That's a fairly predictable kind of process, but then there are others where it's emergent. And so we have to kind of figure it out on the fly as we go. And even those environments where it seems that we've got a pre-existing solution, there is a very clear variable there, and that's people. People show up different every day. I might have had a poor night's sleep, and people might think, well, Jim's normally fairly easy to work with, but wow, today he's... got a short temper or whatever it might be. And so we have to of figure out on the fly how we adapt to those variables. anything that has to do with people, you're going to have some variability. think stepping back, Brian, I think one of the things that is important to kind of understand or get a sense of what part of the system that we want to understand when we're talking about a team and they are dynamics, they actually are fitting within some sort of product ecosystem. And so where are the boundaries of what we mean by our shared purpose, our shared vision within that ecosystem? There's a classic book called Lean Thinking by James and Womack. And there's a really interesting example, simple diagram in the book of a value stream. And it's a value stream of a cola can. And it's kind of fascinating. You kind of see this very simple value stream in there and it starts with aluminum being, well, not the aluminum, but the bauxite actually being mined. And it goes through a reduction mill and then to a smelter. And then it goes through some hot rolling and cold rolling process. And so finally you get basically rolls of sheet aluminum that go to a can maker and the can maker is cutting the cans that are then formed into the cola can. You know, and that can maker is actually the middle of the value stream because all the things I've described so far are upstream. Downstream of the can maker, once they've made the cans, the cans go to a can warehouse somewhere and they sit there until a bottler says, hey, we need some cans because somebody's ordered some cola. And so, you know, the cans make their journey to the bottler and they get filled and then they get... Brian Milner (10:01) Hmm. Jim York (10:17) go to a bottling warehouse and of course there's transportation, there's trucks carrying these empty cans from the can maker to the bottler and then the filled cans from the bottler to the bottler warehouse and then ultimately they go to some wholesale operation and then to a retail store and then you and I perhaps will go into the store and buy a six pack of cola and we go home and we drink the cola. And so you see this very simple kind of journey, this little value stream. from the perspective of the can maker. And so, first time I encountered that value stream, I'm sitting there looking at the can maker and I'm asking myself the classic question that I ask my clients. One of the first questions I ask is, who's your customer? And so for the can maker, it can be very easy to look at that and go, well, it's the bottler because the bottler is the one who places the orders for the cans. So clearly the customer for the can maker is the bottler. Of course from a lean perspective we look further down the stream We were looking at the end of the stream to see you know, what's what's it all for? What's it all for? And if you look at the diagram you get to you know finally to the end of the stream and there's the home where the person's potentially sitting on their couch and enjoying you know that that cola and so you know if you think about all the different steps along the value stream from the mining to the to the smelting to the bottler and Brian Milner (11:17) Ha Yeah. Jim York (11:38) the can maker themselves, the retail store that's selling the cola. The thing that you would ask them that would be the glue that would hold them together for this would be what Diana Larsson and Ainsley Nees call in their lift off book, the product vision. And so the product vision is really kind of what's it all for? And the cool thing about a product vision is it's very concise, it's very succinct and everybody can hold it in their heads very easily because of that. It's typically one sentence. And so I'm going to speculate this because I'm not a, I'm not part of this value stream where Cola makes its journey to people in their homes. But I'm guessing the product vision for all of these various people along the value stream boils down to something along the lines of our customers enjoy a convenient, refreshing beverage. And so the cool thing about that simple statement is that Brian Milner (12:23) Mm-hmm. Jim York (12:28) If you were to go to the mine and ask a miner and say, some of this bauxite that you're mining, in the context of this soda, what's it all for? Now, they're probably mining bauxite for a variety of different customers and a variety of different products. But in the context of this particular value stream, they could look down to the end of the stream and say, it's all about that person sitting on their couch at the end of a long day who simply wants to have a convenient, refreshing beverage. And so that's what you know, this particular product vision is. And so that kind of calls into view a couple of things. One is context is important. So when we're talking about the product, we have to be very specific about what it is that we mean, who is that customer at the end of the stream, and what is the experience that we want them to have. And so this product vision is, as I said, very simple. our customers experience a convenient, refreshing beverage. Now, that makes it simple in terms of this particular value stream, but it also makes us aware that it's very complex for the miners because they've got to deal with competing interests from a whole lot of different customers. And so if they've got limited capacity, they may be trying to figure out, which customer do we satisfy? And so the usefulness of the product vision is being able to go to that mining company and say, do you find value in, do you want to support this activity of creating this experience for this customer with convenient refreshing beverage? And if they buy into that, if they agree with that, that's your leverage, that's your argument. why you should deliver against this value stream versus some other value stream. Now, you don't always win that argument, which is really what life is about, is we're always dealing with trade-offs and we're dealing with different options or opportunities. And so I think that's one aspect of this. But when we talk about the team in the context of a product vision, The team is huge. The team is absolutely huge because it's not just a can maker and the can maker team. It's also the bottler and the bottler team. It's maybe the truckers union that's providing transportation between these different things. the retail store. It's the retail warehouse. All of them potentially have their own concept of team. And in order to create value, it's not just what you do and provide to your next partner on the value stream. You have to really pay attention to the entire value stream because ultimately anything that doesn't come together in the right way at the right in the right place right time It puts it all at risk It puts it all at risk. So I think it's important that we kind of understand the product vision this highest level glue that holds us together and then at a more discrete level look at your team, for example the can maker and What is their unique contribution? In Liftoff, Diana Larsson and Ainsley Niece call this the team mission. And so what is the team's unique contribution to the product vision? And so for the can maker, it's also fairly simple. It's like, we make the cans. And they could flavor that a bit with, they use the latest technology and they use environment. sensitive manufacturing processes, know, they source things using sustainable, you know, approaches and the like. at the team mission level, we're getting a little bit more discreet in terms of what it is that that team is contributing to the greater whole. So think part of this is just kind of stepping back and thinking about what it means to be a team. Brian Milner (16:12) Hmm. Jim York (16:24) You know, are we talking about we're a team that's the collection of all of these things? At times that might be a useful way of thinking about it. At other times we need to kind put our heads down and focus on what our unique contribution is and make sure that we're doing the appropriate job there. Brian Milner (16:24) Hmm. Yeah, this is fascinating because so what I'm hearing is that really we have to expand our thinking a little bit about teams because teaming teams are, know, in one sense, the small group that you're working with on a on a regular basis, but it's there's a larger team concept as well of the entire value stream from end to end. All the people who are contributing, they all are are working towards that ultimate goal of, in your example, someone having a refreshing beverage at the end of their long, day at work? And how often do we actually realize that or look at that? Are the miners really even aware of the fact that they're contributing to that sort of a larger team goal? I think that's a great question. Jim York (17:21) Yeah, that's an excellent point. And what are the implications of either that awareness or lack of awareness? And I think this kind of comes to play when we think about what motivates teams. If all I know is that I'm mining bauxite, that might work for some folks. That's enough motivation. Sometimes people say my paycheck is enough motivation. Brian Milner (17:44) Ha ha. Jim York (17:45) But if you really understand what it's all about, that maybe ties into a bit of self-worth, that I'm a contributing member of society. It could also help you make the right decisions and perform the right actions if you know ultimately what this is gonna lead to. And sometimes that's a calculation that's done in terms of the quality. of the work that you're doing or the output that you're creating. For certain applications, the quality might have certain characteristics where the quality has turned up very, very high in some areas or maybe it's lower in other areas because it's good enough. And if you overbuild quality, you might be introducing some waste because it's not. It's not necessary for the job at hand. In other places, if you deliver below quality, you introduce some risk that the product is not going to be, or the ultimate customer experience is not going to be what it is. I don't know about you, but I've occasionally gotten one of these plastic soda bottles where they've made the plastic so thin for the soda bottle that the liquid is actually needed inside the bottle to maintain the structural integrity of the bottle. Brian Milner (18:54) Yeah. Jim York (18:54) And if I were that customer sitting on the couch at the end of a long hot day, let's imagine it's a white cloth couch and I'm drinking orange soda and I reach over to pick up the soda and my hand, you know, grasping around the soda bottle, all of sudden the soda bottle just collapses in my hand and orange soda goes all over me and the couch and everything else. mean, that's, you know, there's some quality characteristics, some specifications around that. Brian Milner (19:02) Ha ha ha. Jim York (19:18) container that that plastic container that has to integrate well into the rest of the process. It has to work with the bottler and it has to work with the consumer when they're actually using it. So it's understanding the whole can certainly help teams feel a sense of purpose and also can guide that decision making in those actions around it. Brian Milner (19:30) Yeah. Yeah, I think that's an important thing to keep in mind and remember because, you you mentioned, you know, some people would say paycheck is a motivator. And I, you know, I, I kind of subscribe to the Dan Pink kind of motivation philosophy that, know, that, can only do it so far that it is a motivator, but it is a motivator only to a certain point. Beyond that point, we need more. We need more to motivate what we're going to do. Cause you know, there's a million things out there that can give me a paycheck. I could work in a lot of different places, but I've chosen to do what I do for a reason. There's something that fulfills me from doing that, or I prefer it in some way to what my other options might be. I know I've heard people say this in classes before, the idea of how do you have a vision for somebody who builds clothes hangers? We have this talk about vision, this grand design. Big purpose. Well, how do you do that for someone who has clothes hangers? You know, like I get that, you know, there's not everything, every product in the world has, you know, a save the world kind of vision, right? But I think you can, in your example of kind of the mining thing, I think is a good example of this because you can connect it to that ultimate value. And when you connect to that ultimate value, it doesn't that motivate people more to think, hey, I'm helping someone who's had a hard day. I know what that's like. Have a hard day, sit down on your couch and you just want to relax a little bit. Yeah, I want to help that person. Like that, is something that that'll gets me out of bed, you know? Jim York (21:06) Mm-hmm. Yeah, and I think that does require you to think beyond what we often think of as being the team. Because to make it all come together and result in that ultimate product vision, that, you know, the person having the convenient refreshing beverage, in my example, you know, all of those different parts have to come together. And any one of them, if it doesn't happen, you know, that we don't have that value that's realized at the end of the value stream. And so having that connection to what it's really ultimately about is critically important. And understanding where you fit into that and what your value add work is, I think is critically important. And so we talked about like at high level product vision, we talked about this unique contribution of your team like the can maker, and so our team mission, we make the cans. And then we get to the practicalities of the task that's in flight, the work that we're doing right now. And I think that's a critical piece of this puzzle. What is it that's the thing that's being acted upon right now? The work in process or the work in flight. And depending on what the nature of that is, I think that drives a lot of... decisions and one of them is around, you know, who do we need? So who are the actual people, you know, that have the right skills, knowledge, experience in order to do that work? And also it informs our process and so, know, again, that process could be something where it's a known process and we're just, you know, turning the crank or it might be something where we're having to figure it out on the fly. Regardless of the nature of the work, there's going to be a workflow. When we're trying to get something done, the work is going to be flowing through some sort of process. And it's that flow that really intrigues me. we want to look at the flow, especially if speed matters. And why would speed matter? Sometimes speed matters because customers want what we are building yesterday. So they want it as soon as possible. So time to value is often what's considered there. If we're something new that hasn't existed before, sometimes we're also building quickly so we can get it in front of someone to get their reaction to see whether it's fit for purpose. So we might think of that as being time to feedback. But the flow itself is there's the workflow. And so work, the nature of it is a piece of work is something that maybe an individual can go work on. Other times there's a piece of work that requires more than one person to work on. So there's an element of collaboration with that. Even when it's an individual that can work on a piece of work, usually they've received something from somebody that allows them to start that piece of work. And when they're done with that piece of work, they're passing what they've done along to somebody else and that other person is picking up. So even if... there's an ability to work on a discrete task by yourself, there's still an interaction often on the front end of that and the back end of that. So work is still flowing and we have to figure out how to collaborate in such a way that the work that is not being held up in some queue somewhere where we're getting some bottlenecks and that they're constraints. so figuring out how do you enable the work to flow and how do you enable the people to flow? Years ago, I had an opportunity to coach soccer and on my team, I taught them, in addition to like skills, I taught them three concepts. And so the first one was, everybody on the team should know where the ball is. And so it seems pretty obvious, you should know where the ball is. But if you look at this from a team building software perspective, does everybody know where the ball is? You know, what is the work that's in flight and what's the current state of that? I mean, we use information radiators to try to help people understand where the ball is, but often I don't think we use them as effectively as we might. So I'm always challenging teams to figure out, you know, how do you use your communication systems, your information radiators to enable everyone in your ecosystem to understand, you know, what's the work in flight and what is its current state? And why do you need to know that? Brian Milner (24:55) Hmm. Yeah. Jim York (25:24) Well, if you know where the ball is, you can get a sense of what are the things that are in the way of that ball moving forward. So my second rule for the team was know where your obstacles are. And so in a soccer game, you're seeing your opponents. And so you might have a great plan on how you're going to advance the ball from where it is currently down the field towards the goal. But little problem with that. You've got people on the other team trying to keep you from getting there. So you're having to react real time in the moment to those obstacles. And so in addition to everybody on the team knowing where the ball is, everyone on the team needs to know where the obstacles are. And so when you have that information, and again, for a team building software, this is the kind of thing that should be readily available in some sort of information radiator, real time ability to see where the ball is and to see what's in the way. Why is that important? Well, if you know where the ball is and you know where the obstacles are, you can position yourself as a team member to be what I called the help. And so by the help, that's the one or two people on your soccer team that if you're the one with the ball, you know you can pass to them easily. You know, that they are constantly moving around and positioning themselves to be in the place where it's possible for you to get the ball to them. So who are those two people? Well, it changes depending on where the ball is. And so what the team has to do is kind of get a mental mob. Brian Milner (26:41) Ha ha. Jim York (26:47) in their heads of the actual position of people on the field and get a sense of if the ball's here and the obstacles are here, then I should put myself here. Now, it isn't for all the team members to position themselves to be the help because that would be crazy. Just as we see on Agile teams, when somebody picks up a task, the whole team typically doesn't swarm on that task. It would be too many people on the task. Brian Milner (27:06) haha Jim York (27:16) So who shows up to work the task? The right number of people with the right skills and knowledge. So how do they know to come? It's because the work is made visible. And so they come because they see that they're needed. How fast do they come? Ideally, they're there instantly. Now, why might they not be there instantly? Because they might be working on some other tasks. And so if this were to happen in soccer game, you would see the other opponent, you know, they would be... basically scoring goals against you right and left because when you try to pass the ball, you wouldn't have somebody there to receive the ball. So knowing where your help is, if you've got the ball and passing it to that person helps you continue the flow down towards the goal. So if you're not the person who has the ball and you're not one of those two people that are the help currently, What you're doing as another team member is you are. orienting yourself on the field so that you will be the help when it's needed. And so there's this constant movement of people down the field. And where this really brings it home, I'll use this example, and I'm coaching agile teams, is they'll talk about how all their work and stuff, and I'll use the example of the soccer game and the one ball, and they say, now let's imagine you put two balls in flight. Brian Milner (28:16) Hmm, that makes sense, yeah. Jim York (28:36) Can you optimally move those balls down the field towards your opponent's goal? And typically, there is a limit, right? How many balls can you put on the field? Two, three, 15? It's like, yeah, it really drives home the point of limiting the work in process. the teamwork is made more effective and efficient if we have some sense of where the work is, what is the nature of it so that people can come and go, I call this people flow. so we're looking at things like the, well, out of... Brian Milner (29:05) Yeah. Jim York (29:09) out of the concept of open space, the law of mobility. It's like within our organizations, within our teams, can we have people flow to where the work is needed and also have people flow away from the work when they're not needed? And so enabling that autonomy of the individual to be able to go where they need to go in order to optimize the flow is a... Brian Milner (29:13) Yeah, yeah. Jim York (29:34) is a key organizational design problem. Brian Milner (29:37) Yeah, yeah, this is fascinating stuff. mean, I love the analogy with the soccer teams and that I mean, I, that makes sense to me. I love kind of where you're going with this. If people are hearing this and thinking, well, I like to hear more about this stuff. We're going to put links in our show notes back to Jim's site on this because he's got a lot of blog posts. They're kind of around the same theme on this. And we'll link to those specific blog posts for you so that you can find them. But Jim, I want to be respectful of your time and our listeners' time. So thank you so much for taking your time out to share this with us. Jim York (30:08) Well, I've been very pleased to join you, Brian. Thank you for the opportunity. Brian Milner (30:13) Absolutely.

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

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

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

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

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

In this episode, Brian Milner and Lance Dacy dive into the evolving world of software development, exploring how AI and automation are reshaping the landscape. They discuss the essential skills developers need in this new era, from embracing AI as a tool to mastering emotional intelligence and continuous learning. Overview Brian and Lance discuss the transformative impact AI and automation are having on the software industry. They explore the importance of adaptability, continuous learning, and cross-functional expertise, emphasizing how developers can thrive by embracing AI as a tool rather than a threat. The conversation highlights the growing need for soft skills like emotional intelligence, curiosity, and collaborative leadership, and encourages developers to be open to new technologies and ways of working to stay competitive in the ever-evolving tech landscape. References and resources mentioned in the show: Lance Dacy Big Agile “Be curious, not judgemental” – Walt Whitman #54: Unlocking Agile’s Power in the World of Data Science with Lance Dacy #63: The Interplay Between Data Science and Agile with Lance Dacy #82: The Intersection of AI and Agile with Emilia Breton #99: AI & Agile Learning with Hunter Hillegas Accurate Agile Planning Mountain Goat Software Certified Scrum and Agile Training Schedule Certified ScrumMaster® Training and Scrum Certification Certified Scrum Product Owner® Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® 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. Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. How's your week going? I hope everyone's week is going well. Yeah, I'm switching things up. I'm not saying things exactly as I did the past 100 episodes. But welcome in. I hope you guys are having a great week. We are back with you here at the Agile Mentors Podcast. And I have one of our favorites back with us. I have one of our repeat visitors, Lance Dacys with us. Welcome back, Lance. Lance Dacy (00:28) Thank you, Brian. Great to be here. Brian (00:30) Always excited to have Lance with us because we always have such great conversations. And I wanted to have Lance back because we were talking about something recently that I think might be a good topic for us, might be on a lot of people's minds. And that is really kind of getting into this, what we've loosely termed the new age of development. With the new tools and new kind of the way that AI has worked its way into things and automation. How is this going to change and affect our teams? How is it going to change and affect how we develop? How is it going to change and affect the software industry? Lance, I know you had some thoughts on this. I'm going to just open the floor for you and let you take it from there. Lance Dacy (01:15) That's great, Brian. My heart is always with organizations and developers, just trying to help people get better. You and I shared that vision that I remember a long time ago, even at DFW Scrum, one of our vision statements was just trying to help you to do better today than you did yesterday. It's like, what are the things that we can help teams and organizations? And something's real heavy on my mind lately as I work with these teams. You know, we have these notions out there like Agile is dead and, you know, where is Agile headed? And that's not really what this is about here because I think what's happening, as a lot of people have already said, it's just become more of the mainstream. Let's quit labeling it. You know, like Mike always tells us, object -oriented programming won. We don't really call it that anymore. Objects won and off we went. So I'm not really focused so much on the agile type scenario, but we do work in Scrum and agile teams and I see plenty of organizations that need help with that. And I still encounter to this day, developers who are lagging behind on their skills, right? We get so focused in the day -to -day feature development of our roadmap and things like that. that I just fear that developers aren't setting enough time aside or not challenging the organization to help them do that, to learn new skills. And I started compiling this list of like, if I go in and start teaching teams how to do scrum and how to manage your backlog and how to do that, it doesn't matter if they don't have the skills because everything we talk about in Agile is based on reducing waste and the more of these skills gaps that we have. then I find the more handoffs and the more bottlenecks and you know that's one of the eight waste, you know, of lean. And so that's what I wanted to talk about today. And I love the topic like the new age of development. I'm not going to sit here in a spouse to claim to say, here's all the skills you're going to need. But as you and I work, I think we can find plenty of examples to help guide some of these people, even Scrum Masters that are coaching teams or agile coaches, you know, just kind of put some thoughts in their mind about. know, these skills and I have about a short list of five that I've seen growing and then thought we'd go from there. Brian (03:30) That sounds great. I want to dive into one that I know is on your list and it's one we kind of talked about here beforehand, but that is kind of how AI is affecting teams and the skills needed to be relevant with that. Now, I want to preface this by just saying my own personal opinion here on this. I'm not a doom and gloom person when it comes to AI. don't really see it much different than... Lance Dacy (03:34) Thank So, I'll see you. Brian (03:59) how automation really changed things like testing. When automation entered the testing realm, we didn't lose all our testers. We still needed testing. It just was a tool that enhanced the way we did testing. And I think AI is sort of going to be that for how we program. don't think we're at a place where, or I don't know, things could change quickly, obviously, but I don't feel like we're within 10 years. of it completely replacing developers. I think we're still going to need to have expertise. We're still going to need to have that guidance. Maybe 10 years is too big of a window. don't know. Maybe five years? I don't know. Lance Dacy (04:42) These days you don't know. I just thought yesterday something changed. No, I'm just kidding. Brian (04:46) Right, right. But I don't see that happening in the near term window for sure, just because it does a lot of things well, but it doesn't create. It can do things based on what's already been done, but it can't really then go through and create something entirely new itself. So I think you still need human beings for that component of it. Lance Dacy (05:04) Done. Brian (05:15) And I think for developers, learning how to integrate that kind of tool set to help you reduce your errors, define bugs, AI is great at looking over a huge chunk of your code and finding potential issues that you can go back and look at. That can save you enormous amounts of time. So I think there's skill involved there for for the developers segment that I think is embracing it rather than kind of holding it at arm's length and saying, that's the enemy, that's gonna somehow replace me. No, think of it like automation. It's not to replace you, it's just another tool to enhance and give you time to do other things. Lance Dacy (06:02) I think, you know, you mentioned, don't think you and I either would be convicted of being doom and gloom people. think we're pretty well optimistic, right? It is scary. mean, obviously these things that are changing, you're like, my gosh, I have to, the main word I keep thinking about is adaptability. You know, I've got four kids. I keep telling them the best skill they can do is learn how to learn, you know, and I think you just used a perfect example in development about test automation. Brian (06:10) Yeah. Lance Dacy (06:30) We weren't scared of that. The testers might have been because they're like, well, what do I do now? Well, you got to go learn a new skill, right? But it freed us up. Can you imagine still doing, there's companies out there that still do manual testing, and they have to wait until all the changes are in until they do testing, and you will never compete. in a good hyper competitive marketplace doing things like this. So the test automation freed us up and actually what I used to tell my teams is it gives you more confidence, right? So developers can make more radical changes in the code without feeling like, know, you. You blow on something and then it breaks. know, y 'all ever seen code like that before? And it's like, I think it builds their confidence that test automation helped them to be more efficient and more productive because they can experiment more. think that's the goal is I write this code and I can quickly test to see what happens. And I start building my confidence and I can make more radical changes to the system instead of tiptoeing or walking on eggshells. So I'll date myself a little bit. Your example is probably much better than mine. But can you believe I don't use a Maps Go anymore? Y 'all remember the days of trying to navigate a street address with a Maps Go or a real map? I mean, I'm kind of at that bridge where we started having online maps, but you still had to know where you're going and print it out before you left and then take it in your car. You're still trying to read it as you're driving. I mean, who does that anymore, right? So I get in my car these days and now I don't even have to plug CarPlay or Android or whatever you have. It's wireless. You just get in and I'm now a co -pilot in my car. And we kind of laughed about that. think the last episode we're on and I can just drive around in it. I just do what it tells me to do. But it'll never replace my experience, my opinions, and my knowledge of the world. So I can. Brian (08:05) Right. Lance Dacy (08:20) you know, sidestep any suggestions it has, but it helps me be more productive. It knows where traffic is. I don't know that. You know, I know the city I live in and I know five different ways to get somewhere, but I don't know if there's a road closed or anything like that. So I feel like with developers, we need to start embracing some of these tools to help you be more confident, help you. mean, goal of agility, right, is to go faster, go faster than our competitors. So I feel like that's the premise of what we're trying to accomplish here is optimism with these tools. AI is just one of them. But we all have that in our day -to -day lives. test automation is good. I've got the driving. What's another one you got, Brian, that's made you more efficient with AI? Brian (09:01) Well, just before we move on, one thing I wanted to kind of throw out there because I heard this example recently for AI and I thought this was a kind of a really good practical example. If you've been a developer for any amount of time or if you've ever developed in the past, you've unlikely encountered a situation where you've had to go into somebody else's code. And when you do that and you have to enter, especially if it's like a rat's nest of code that you can't really make it out, it's been there for a long time. and it's fragile, no one wants to delve into it. Well, I read this article from a guy who basically had used this legacy code base and entered into AI and had AI go through and comment and help them learn what the different sections of the code did and how it was structured and organized. And it just saved them an enormous amount of time in trying to understand what had come before. Because you know, Like I said, we've all entered those places where we've had to come in behind someone else that is no longer there and try to figure out where we get started, even if it's not code, right? Even if it's something else, but we've all had to come behind someone else. And if we can take a folder full of documents, feed it into AI and then say, help me understand blah, blah, blah. Yeah, summarize this. Help me understand where would I go for this? That's just an enormous time saver. And that's what I think is really great about it is Lance Dacy (10:17) you summarize this. Brian (10:27) So as far as skills are concerned, think prompt engineering is a good one. think coding, interacting with code with an AI agent so that you can create your own AI agents so that you can programmatically call that information. If you're a coder and you can do that, man, to me it's like it just exploded. And now the possibilities are endless of what you can do with that kind of stuff. Lance Dacy (10:57) just dated myself with Cliff Notes too, right? Just think of it like on the fly Cliff Notes. And I heard Alastair Coburn, one of the thought leaders in our industry, been around for a very long time trying to help humans and machines interact better. And he kind of summarized really well about what it's doing in his life is saving him keystrokes. Brian (11:03) Right! Lance Dacy (11:19) And that's kind of like what I wanted to focus on with developers. Can you imagine if you got to spend more time being creative and less time writing on a keyboard to the computer, like you just talk to it. I'm getting to the point now, I used to text all the time and I used to laugh at people that hold the phone up to their voice and they talk into it. I fat finger things and misspelled things so much, all I do is just talk into it anymore. So I feel like coding, that's what it's, you're not even going to tell it the code to write. You're going to have to be... more problem solving design engineer, you less code writing, more problem solving and understanding the domain in which you're trying to automate and algorithm design and ethical considerations that go along with that. But the computer won't be able to do that, but it'll save you keystrokes. It'll save you time. And I think Alistair summed that up pretty good that way. Brian (12:07) Yeah, it's architecture, right? We have to be better architects at what it is we're trying to develop. that way we can give the rough architecture and let AI do the dirty work of the small details to fill in. Lance Dacy (12:21) Well, you mentioned something too about boundaries, right? So AI has to operate within boundaries of what you feed it to learn off of. It's very, I'm not going to say never always really, that's a hard thing to say these days, but it's going to be very surprising if AI can just generate new ideas. It'll probably generate new ideas, but from what? I was working with a client yesterday that comes from more of the manufacturing world and he's really struggling with leadership agility. Like how do I lead and build a culture in a world for people who do the kind of work that we normally focus on with software engineering and development? He said he's a mechanical engineer and I kept using the word knowledge work, right? So the people who do our kind of work, the reason it's so complex, risky, uncertain, unpredictable and all those things is because it's kind of like knowledge and critical thinking and creative work. And he goes, but how is that different? I'm a mechanical engineer. How does that differ from software engineer? And I said, you know, it's a really good point. It's nothing about who's smarter than who, right? So I'm not trying to put anybody down on that. But in the world of mechanical engineering, you are bound by physics. are like you work in the space industry. Yeah, you're doing some cool things and you got to come up with new ways of doing things, but you still have to operate with. physics and astrophysics within those boundaries that we know about with space. But in software, and I sit down and start writing something, there's no boundaries. Like I can use any technology I want, can come up with any, I'm limited by my own skills and abilities. So why not let AI go help me get ideas? I'm not saying you got to write it all for you, because hey, I told one of the AI tools to write me an e -commerce site in Ruby on Rails. and it gave me all the scaffolding and if I would have taken that and start putting it in, then I can start elaborate. But how much time does that save me? How am gonna construct the file? So it kind of handles that architecture, but then I gotta put my critical thinking on it. I just feel like it's gonna make us, if we embrace it correctly, it's just gonna make us more efficient in that way. Brian (14:22) I agree. So what was one of the other skills that you had down that you thought of as being a new era kind of skill? Lance Dacy (14:29) So I'll just go through the four left real quick. I was thinking about cross -functional expertise and we can dive into some of those a little bit. Most Scrum teams we say, hey, you got to have cross -functional teams. And that doesn't mean everybody knows everything. It just means we have all the skills on the team to bring something usable by the end of the iteration. But I feel like cross -functional these days is no longer about coding. Like I know a front -end developer, back -end developer, database person, tester, UI, UX, architecture. These are more like understanding what we call now DevOps, cloud infrastructure, hardware, software integration, particularly in fields like, I work with some defense people, some aerospace engineering, writing code is like bare minimum anymore. So if you can do that, celebrate that, but you've got to move beyond that and start understanding these machines hardware, which leads me to my next one, which is continuous learning and adaptability. because the rate of change in software frameworks and tools we just talked about has accelerated. And if we're not keeping up with that and learning from that, you're gonna be left behind. So be agile in that regard. The last two I had on my list, one I'm just gonna brand it as cybersecurity. Brian (15:47) Yeah. Lance Dacy (15:47) cryptography, like I got a, went to school and for data science, you know, got my master's degree when just after COVID started, I had no idea what I was thinking, but it actually was pretty good because it was all online anyway. But I had to take a lot of cryptography classes way over my head, but at least I understand the terminology and the nomenclature, but that's going to be the key. is, and I've read somewhere, I can't remember the article, but there's like a shortage of 79 ,000 jobs in cryptography. So if you're looking and you're scared for the future, go start learning cryptography and security because these, you know, specifically zero trust architecture, these things that a lot of blockchains have been pioneering in the last couple of years, we're going to have to start locking these things down because every time we find a better way to do security, a hacker undoes that. And this was the cat and mouse game forever and ever. I don't think that will go away. So cybersecurity and more like risk management, you need to understand coding practices for that, as well as how the hardware, the protocols, how do these things talk to one another? And then the last one I just branded is more like... collaborative leadership and communication. need a stronger, you know, used to we would think of software coders sitting in a dark basement, just leave them alone and let them code. And I think we're getting to the direct opposite of that. They need to be leaders out talking to the people who need these systems, going back to that cross -functional expertise. you need to do better communication to the non -technical people so you understand what you're trying to accomplish and automate for those people in the world of cybersecurity and how software tools are changing. People get tired of the buzzwords, right? The technology jargon. So you're going to have to learn how to do that. And I think data scientists are going to be, they're kind of the first group that I've seen this happen. Like when we talk about data science and analytics and AI and Scrum, We've done a couple of podcasts on that. The issue is not just, I'm going to demonstrate what I've shown you, but now I'm going to partner with you and say what I think we should do next. Like I can model a data system ad infinitum, but my theory is I think I've done the best we can do. You can spend two more million dollars and we'll get this much or spend a thousand dollars. do this. And you have to partner with them on that. So those are kind of the five here. You mentioned the first one. So AI and automation, integration, things like that, cross -functional expertise. continuous learning and adaptability, the cryptography, cybersecurity realm, whatever you want to call it, and then collaborative, more collaborative leadership and communication. So those were the five gaps that I think if developers are scared and want to shore up their skills, those are kind of the five that I'm telling my teams to go look for. Brian (18:38) That's a great list. I throw a couple, I don't have a full list like you brought, but there's a couple of things that just popped in my head that I would throw into that list as well. One is what I'm just going to call teaming. Because I think there's a need, there's a real need in the marketplace today of people understanding how to do work in a team. Because regardless of what the work is, regardless of what the industry is or the Lance Dacy (18:51) Yeah. Brian (19:07) backdrop is, you know, most, most jobs, you work together with a group of people to accomplish something in some way, shape or form. That's part of the reasons why shows like The Office or movies like Office Space are so funny is because it's so bad in so many places that people don't really, we laugh at it because we all painfully are aware of how bad it is. Right? Right. Lance Dacy (19:35) It's real. We get it the mark. Brian (19:38) So being able to understand how a group of people actually do work together well to accomplish something. And I'm not talking about hokey kind of motivational, hey everybody, let's make sure we put on our happy faces today. Right, I'm not talking about that. I'm talking about just, we all go, know, the way I explained it in classes, do we think of teaming as sort of the way you would do golf on a team? where everybody goes and shoots their own 18 holes and then we total up the score? Or do you think of teaming more like it would be in football or basketball or soccer or something like that where everyone's on the field at the same time, we all have the same goal, we're all moving towards the same goal and we do whatever is needed to accomplish that goal. We have to work together. If you go to any youth sport in the world that's a team, what's the one thing that you'll hear people say, from a sideline over and over the coaches say to the team, you got to talk to each other. Right, communicate, talk to each other, call for the ball, right? And that's such an essential teaming kind of component of that, that I think that's one of the big things there is just being able to understand how to team. Lance Dacy (20:37) Communicate, yeah. Well, and if you don't know what you're supposed to do, ask somebody. So that's the, you know, I'm not going into psychological safety, but how many people feel safe in an organization going, I don't know how to do this because then you're like, my gosh, if I don't know how to do it, I'll get fired. I lose my job. do this. so cultures have to change as well. I don't have that on my list because this was more specific to contributing it as a team. But I think that's a really important call out. know, professional sports get a bad rap when we use analogies. I love them. because I love sports and I know some people don't play sports and I get that, but you at least have seen them. But that's a great example of five people, 11 people, eight people, whoever it is on the field together with one goal. How important is that? And how often do organizations do a good job at centering people around a one goal? Terrible. We do a terrible job at that. But that's out of the, developers, when I say collaborative leadership, they need to start pushing on those things. So that's, I guess we could call those soft skills. What would you call those, Brian? Brian (21:53) Well, actually that was gonna be my next thing was kind of more of these soft skills that I know a lot of people really hate that term and you can use whatever term you wanna. Right, I mean, that's one of them, right? But I mean, just being able to navigate conflict on a team. Lance Dacy (22:01) emotional intelligence. I've heard that. Yeah, fill in gaps when you don't have a skill. Go learn it. Solve, work the problem. You know, remember Apollo 13 is like one of my favorite movies. It was a really well done one. And Ed Harris is a great example in that, as he plays Gene Crantz, know, as Apollo 13 was having its issues. Brian (22:17) Yeah. Lance Dacy (22:27) and work the problem people, they don't know what they're doing. They're all smart people getting together, but they need something. They have to talk and collaborate. So I think that's a huge one. how do you learn to do that? You gotta go do it. You can't read a book and say, how do I get more collaborative? You gotta have, I call it attitude, aptitude, and drive. If you don't have the right attitude or tone when you work with people, They're going to shy away from you and not tell you everything you think. So you want to be approachable. You want to be, hey, bring me any problem you have. Let's talk about it. Like you want to be, that's what I call the right attitude to succeed. Aptitude obviously is your ability to learn something new and get up to speed. And then the drive to succeed. How many people have you worked with where they just do the bare minimum getting by just collecting their paycheck, you know? developers face that, right? So if you're one of those people, if you really want to shore up your skill, go figure out how to change your attitude or maybe you're in the wrong business. But how would you, you know, that's a good one to think about. How would you help fine tune those as a person? What could you go do to shore up your attitude, aptitude and drive? I'll put you on the spot, Brian. I'm sorry. you've done a lot of good talks recently on the neurodivergent and I know you've Brian (23:38) What? Lance Dacy (23:44) you know, the research that you've done on that, that's more of what I'm talking about here is finding your place in the world of every, you know, bring your gift and talent in whatever state it is, but how could you train yourself to be more approachable and have a better drive? What do you think? Brian (23:59) Yeah, well, so my biggest advice there is, I'll quote Ted Lasso who's quoting someone else, but right, be curious, not judgmental, right? That old phrase, which is not his, I forget where it comes from, I think it was, I don't wanna get it wrong. Right, right. Lance Dacy (24:10) We all knew something from Ted Lasso, right? You'll put it in the notes, I guess, later. Brian (24:27) But that phrase I think should be kind of a hallmark for how we approach things is with curiosity. Like why is it this way? Why is it working this way? And what's behind that rather than that's wrong or that's bad or that's whatever. Right, right. You know, someone does things a different way. Well, that's curious. I wonder why they do that that way. Is that the best way to do things? Let's discuss it. Let's analyze it. Lance Dacy (24:42) Or what are you making? Brian (24:56) I just want to briefly say too, when you mentioned the sports analogies things and how we get in trouble sometimes for using sports analogies, I say this in my classes, at its core, I can't really completely get away from sports analogies because Scrum is a sports analogy. Lance Dacy (25:17) In 1986, they used a professional example, team example, of how products were succeeding in 86. Sony, know, Honda, Canon, all of them, and that's what spawned that article for it, right? Brian (25:23) Right. And that article says, you know, the relay race approach to doing things is not the right way. That's a sports analogy, right? It's talking about relay races and handing the baton off between one runner and the other runner. And, you know, that's a sports analogy. And think in teaming, there's an inherent kind of, all right, we don't have to get into all the rules and regulations of the different sports. You don't have to follow them. But I think we can, like you said, I think we can all understand. that when you have a team on the field at the same time, there's a big difference between that and, like I said, golf, where I'm just gonna go shoot my 18 holes, right? But what somebody else is doing doesn't affect me, right? I mean, it affects me at the end of the day with the score, but it doesn't affect, if I'm on the fifth hole, I don't really need to even know what anybody else is doing because I'm just, I'm shooting the best 18 holes I can shoot, right? Lance Dacy (26:08) Do the best I can in my one skill. Yeah. And you do have a shared goal, right? We're trying to get the best score, but you're more limited. You can't help other people. Like what is the, it's the attitude I really think, I wish I had a better word for it, but when you walk out on the field, you either are there to do whatever you can to succeed within your capacity and have an attitude of, let's pick each other up. Everybody's going to have good and bad days. We know that. So somebody's going to show up on the team and be like, man, I'm sick or. I'm moving and I'm scattered all over the place and I'm going to be a little flighty this week. People pick each other up. Like, how do we learn to do that, Brian? How do we, how do we, how can we teach people, especially developers to contribute on their teams in that way? It's not about your skills. It's about your attitude, your aptitude and drive. Brian (27:12) Yeah, and I think what's at the core of that for a lot of teams and I had several conversations with the different agile conferences I went to this year with people about this. There's this cultural aspect that is so much more important than any of the details that we get into as far as meeting length and who attends and all that. It's just at its core, do you inspect and adapt? Right? Do you actually take time when you... Lance Dacy (27:21) Yep. Brian (27:42) And it sounds so simple, right? But how many times have you been involved with something at work where everyone knows it's the wrong way to do it, right? Everyone knows that's a terrible thing that's happening in our work. And we all can just kind of shrug our shoulders and say, well, I guess that's the way it has to be. Why? Why don't we inspect and say, why are we doing it that way? Is there another way we could do things? And then we try something different. Lance Dacy (28:07) Well, and pull it up because the other problem is the hierarchy of a traditional management driven organization is do I have the courage, you know, one of the scrum values courage to raise that flag and stand up for what's right or our fear of losing my job. And I'm going to encourage you developers out there. If you really want to do a great job, you're a great developer and you're not just trying to get by. I would challenge you like I had to learn a long time ago and say, if I do those things and I get fired, I don't want to work at that organization anyway. But that takes a lot more courage because you got a family and you got all this stuff. But you might have your answer if you start raising the flag. don't be an ass about it. Be an attitude, aptitude, and drive. But that's why I said number three on my list here was continuous learning and adaptability. You have to learn that. Brian (28:54) Yeah. Yeah. And I'll give you kind of a practical example here. So if you're working on a team and let's say that you need to get approval to do something, okay? If you have to get that approval and you know that approval is going to cause a delay because I've got to go get approval to do this. Well, be curious, ask the question, why do I need to have this approval? What's the purpose behind getting this approval? And if the answer, if there is a good answer, right? Well, we have to do that because compliance is really important with us and our safety or whatever. And if we don't do that, then we can have a catastrophic event. All right, there's a good reason to get approval. But if the reason comes back, well, because that's the way it always has been, we've always had to ask four layers of approval to get something done. Maybe then question it and say, hey, is there a... Can you help me understand the purpose of getting these four layers of approval? Is there really a need to get four layers of approval for this? What's the downside if I don't get approval for this? Is it catastrophic if I make a decision that maybe one of those four layers of approval disagrees with? Can it still be changed later? What I try to tell people is the speed you get from not having to go through those four layers of approval is far outweighing any kind of small mistake that that person might make. So that's kind of a practical example to say, be curious about it. Try to inspect and adapt. Why is it this way? Does it need to be this way? Is there a reason why we're doing it this way? And if there's not a good answer as to why, then I think it's not bad to question it. Lance Dacy (30:39) Yeah. And they're never going to say, well, we like ossified and calcified processes. Every time we have a problem, we add more checks and balances to them. We never remove them. And that's one of the bane of the team's existences these days is, yeah, we got to mitigate risk and we can't be haphazard, but that's why you got to shore up your skills on this automation and get better at problem solving, less coding and more problem solving. And I tell you what, Brian, we were going to wrap up at the end of the podcast with what I wanted to talk about is don't be scared about AI because I don't think, like I said, I don't want to use the word never or always, but I really think it's going to be hard for AI to learn and take our place in number one, emotional intelligence and empathy. you know, AI can certainly analyze patterns of what it's been for, but truly understanding emotions, nuance, and the complexities of human relationships, which is what we're talking about here. Tone AI don't, I don't think it'll ever really learn how to do that or well. All right. on top of that, be the ethical side of it, right? The cultural things and ethical, know, you could put boundaries on it. can give it rules. But I think humans have a really good, well, most humans have a good sense of that. So I think emotional intelligence and empathy, I creative problem solving and artistry. I kind of use the word artistry for developers as well, like writing code and architecting code and the hardware infrastructure and all that that goes into that. AI can generate the beginning, like AI can generate art. It can generate music if you heard some of these things. I mean, they're good. I see the art, I see the music, but it's all based on patterns. It lacks the ability to produce truly original works that stem from like live experiences and personal insights. So celebrate that and bring that to your job. And I think alongside that is complex thinking, know, strategic thinking, leadership, critical thinking, things like that. know, AI is effective at optimizing and analyzing data and helps us, you know, like COBOL used to read and write data faster than any other system. Humans can't keep up with that. Our processor is the bottleneck. So use that, offload that to something else. But your leadership requires abstract thinking and foresight and the ability to motivate people is something that AI really is not going to be able to do. So start shifting your focus from, you know, the things of data and analyzing. let the computer summarize that and then you put your critical thinking on it. And I think that's where you're going to find a better place for yourself as developers. You're going to be and need to be technologists, but that blurring of the line between DevOps and coding is coming and coming and coming. So you have to start learning the hardware that's running all this stuff and make higher level decisions and less of the lower level. So celebrate your emotional intelligence. your empathy, build those skills up, never lose sight of critical problem solving and artistry that you bring to the table and complex thinking and adaptability. Those are the things that you need to focus on, I think, as developers and embrace this AI to make you more efficient. That's my opinion. Brian (33:59) Yeah. And I'd say, you know, I just tag one last thing on that and it's to say, you know, with the new tools, with the new kind of AI stuff and things that come along, be curious, not judgmental. Ask about how I could use that to my advantage. You you mentioned the music kind of software. I think I know musicians who are using that kind of software to help them, but they see it more as a tool, not as, and now it'll do the job for me. just like I wouldn't go and put in into chat GBT, write me a whole book on something, right? Right, right. I'm not gonna go, if I'm a musician, I'm not gonna go say write a whole song and I'm gonna just take that lock, second barrel, here's everything that that put out and I'm not gonna alter their change. No, but I can get an idea, I can get a melody or a hook or something that I could use and then I can build upon that. So. Lance Dacy (34:34) And then just spin that over. Yeah. And those are always patterns, like every music you hear somebody, it could sound like another song. So you're not really violating ethics there. Like I used AI one time, you my son's learning how to do guitar and I play piano, but I was like, give me eight chord structures that are sad. I mean, there's a certain number of combinations and you listen to them and you're like, okay, now I can add a song under that. But I didn't have to sit around and pick forever and ever like they did, you know, in the old days, which I celebrate that. I think that's great. But why not have eight of them there? And I say, I like that one or don't give me eight more, you know, give me eight more. Brian (35:13) Sure. Right, right, right. So think of it more as a tool, right? Well, this has been great. think this is, hopefully we've given everyone a lot to think about here. And if there's one thing I kind of sum up, I hope that people look at it, maybe we're a little too Pollyanna about this, if that's a dated reference too, but naive. But I would say, Lance Dacy (35:32) Yeah. Brian (35:57) try to be more hopeful about these tools and say, can I use them to my advantage rather than how can I, how is it going to destroy it? Lance Dacy (36:04) Attitude, aptitude and drive. Have a great attitude, right? Say, hey, I'm going to embrace this stuff and not so much doom and gloom. Go figure out how you can use it to your advantage and you're going to separate yourself from everybody else. Totally agree with that. Brian (36:07) There we go. Love it. Well, Lance, thanks for coming on again. I appreciate you taking time. Lance Dacy (36:21) My pleasure. As always, I look forward to our next one, Brian. Y 'all have a great week.

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

Join Brian and Bernie Maloney as they explore the transformative power of mental models, emphasizing the shift from a mechanistic to an organic mindset in Agile organizations. Overview In this episode, Brian and Bernie Maloney discuss the profound impact of mental models on organizational culture. Bernie delves into how our beliefs and assumptions shape our thinking and behavior, particularly within Agile environments. He discusses the importance of transitioning from a mechanistic to an organic mindset, focusing on problem-solving rather than merely delivering solutions. The conversation also highlights the role of psychological safety in fostering a culture of experimentation and learning. Bernie shares valuable resources, including Amy Edmondson's 'The Right Kind of Wrong,' to further explore these concepts. Tune in for insightful strategies for enhancing your organization's agility and effectiveness. Listen Now to Discover: [1:03] - Brian welcomes Certified Scrum Trainer® and Principal at Power By Teams, Bernie Maloney, to the show. [2:15] - Bernie delves into the concept of mental models, sharing the origins of his philosophy of "making new mistakes" developed during his time at Hewlett Packard. [5:55] - Bernie illustrates the power of mental models and belief by sharing a compelling example that brings these concepts to life. [13:46] - Join us for a Certified Scrum Product Owner® Training, where a year of coaching and development with Mike Cohn, Brian, and the Agile Mentors Community of Agile leaders is included with your training. [14:39] - Bernie discusses how applying mental models can enhance the effectiveness of Agile transformations, creating a naturally adaptive and innovative climate. [18:12] - Bernie offers language as a powerful tool to support the shift to a new Mental Model. [23:30] - Bernie demonstrates the use of mental models for product owners through the Mobius Loop, providing actionable guidance and examples [26:27] - Brian shares a big thank you to Bernie for joining him on the show. [26:59] - If you enjoyed this episode, share it with a friend, and like and subscribe to the Agile Mentors Podcast so you never miss a new episode. [27:27] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership to that site by taking any class with Mountain Goat Software, such as CSM, CSPO, or Mike Cohn’s Better User Stories Course. 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: Bernie Maloney Power By Teams Mobius Loop The Right Kind of Wrong: The Science of Failing Well by Amy Edmondson Agile Teams Learn From Spikes: Time Boxed Research Activities by Mike Cohn Certified Scrum Product Owner® Training Certified ScrumMaster® Training and Scrum Certification Mike Cohn’s Better User Stories Course Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Bernie Maloney is an Agile leadership coach and international speaker, leverages his 25 years of engineering and leadership experience to help teams and organizations unlock their full potential. Known for his engaging workshops and impactful coaching, Bernie believes in making performance breakthroughs both achievable and enjoyable. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We are back for another episode of the Agile Mentors Podcast. I am with you as always, Brian Milner. And today I have a very special guest with me. I have Mr. Bernie Maloney with me. Welcome in, Bernie. I am. Bernie Maloney (00:14) Thanks, Brian. Happy to be here. Brian (00:16) Great. I'm so excited to have Bernie here. Bernie and I have touched base for years over conferences. We've run into each other and had chats and shared our shared passion for Hawaii and other things. But Bernie was speaking at the recent conference and we've gotten into some conversations. I wanted him to come on because I wanted him to, first of all, if you're not familiar with Bernie, sorry, I see, I just want to jump right into it. If you're not familiar with Bernie, Bernie is a CST. He works at a company called Powered by Teams. He teaches classes, Scrum Master product owner classes and leadership classes and other things as well. But he is a principal at Powered by Teams. So just wanted to give you the basics there before we dive into anything. But the topic that we started to talk about that just as a jumping off place for us is a topic. the topic of mental models. So Bernie, why don't you explain to everyone how you define that, mental models. Bernie Maloney (01:23) So, Brian, this is a great topic. I find myself talking about it all the time. And y 'all, I warned Brian, like, he can press play on this, and it might be 15 minutes before he gets a word in edgewise here. It touches on mindset. It touches on a lot of topics. My talk that Brian was referencing at the recent Scrum gathering in New Orleans was make new mistakes, leadership lessons from an Agile success. which goes back to where I really kind of cut my teeth in Agile at Hewlett Packard. See, I'm a mechanical engineer by training. And I cut my teeth in Agile in the consumer PC division at HP about, this is scary to say y 'all, okay, about 27 years ago starting at this point. And some of the fun stuff, it was a bang up enterprise. It was the fastest business in HP's history to hit a billion dollars. And it was just... Brian (02:05) Yeah. Bernie Maloney (02:18) a great proving ground. We had hardware, we had software, we had distributed teams where volume manufacturing was in Asia, engineering was here where I am in Silicon Valley. Go -to -market for Europe was in Grenoble, France. We had high volume. Some of our products had 100 ,000 units in a single model run, with like 200 models in Europe on a quarterly basis at times. So high volume, high mix, tight margins from a business perspective. A lot of technology products want to have 20 % to 30 % gross margins. That's before you start taking off deductions like expenses and salaries and things like that. On a good day, we had 8 % gross margins for Christmas products, maybe 2 % gross margins. We used to refer to it as we were shipping rotting bananas. And like I said, I was there. When I started, we were shipping six products a quarter. We grew to 20. By the time I left after eight years, we were doing 200 products a quarter in Europe alone. Brian (03:04) Ha ha. Bernie Maloney (03:16) hardware, software, distributed teams, high volume, high mix. And we did all that with weekly iterations of a plan. At one point in my career, I was tactically responsible for the delivery of 2 % of HP's top line revenue with zero direct reports. And part of the secret sauce of success in that organization was really that mental model of make new mistakes. So that's where the talk title comes from. And in fact, makenewmistakes .com will point to poweredbyteams .com because I own that domain too. But that mental model really helped the organization thrive and not just survive. We went from like a number one to a number five share. Sorry, from a number five to a number one the other way around. Because the founding executives recognized that in that tide of a market, mistakes were probably going to happen. And so what they did is they established the psychological safety. Wow, look, there's another great topic. Make new mistakes. You knew that if it was an honest mistake, it would be forgiven. Just don't make it again. Get the lesson is one of the things that they said. I can even tell you the story about the weekend I blew a million dollars of HP's money and I was forgiven, but you'll have to come to a conference talk for that. So that was just like a great experience. And... Brian (04:32) Wow. Bernie Maloney (04:39) After that experience, I went on to TVs. Another part of my background is I shipped the very first internet connected TVs. Look it up, the Media Smart 3760 from HP. It shipped even before Apple TV. It bombed. Okay, it was way ahead of its time. But I recognized that that had been such a joyride. And then I recognized some other stuff that really gets into the psychological, the mental aspects of leadership, high performing teams. And I could, Brian, I could talk about that too, but okay. But that kind of got me to recognize that with those skills, the success that I had experienced at HP could probably be replicated. That's kind of been the path that I've been on for the past 15 years is really helping organizations go along that path. So mental models can be really big. Let me give everybody here an example. And so Brian, I'm going to speak to you as a way of illustrating mental models. So imagine you are physically where you are right now. Brian (05:24) Yeah. Bernie Maloney (05:37) but it is 150 years ago, okay? Imagine you're physically where you are right now, but it's 150 years ago. Now, Brian, let me ask you, can man fly? Brian (05:47) boy, you're testing my history knowledge. Bernie Maloney (05:52) Okay, make it 200 years ago, okay? That makes it easier. Okay, cool. Great, now fast forward to the present. Brian, let me ask you, can man fly? Brian (05:54) No, yeah, no. Yes. Bernie Maloney (06:02) What changed? Nothing about the laws of physical reality. It was just your mental model of what for man to fly means. That's the power of belief, okay? And belief limits a whole bunch of stuff in the way that people behave. So you'll hear Agilent talk all the time about, this is all about changing mindset. I'm probably, Brian, gonna give your listeners some ways of. Brian (06:06) invention. Bernie Maloney (06:30) changing mindset as we go through this, but that's going to illustrate the power of mental models. Now, a big one that I like to use that's specific to Agile comes from Gabby Benefield. She's an Agilist out of the UK, and it's called the Mobius Loop. And I think she's got the domain mobiusloop .com. So everybody can imagine a Mobius Loop. Okay. And what I really like about this model for her... Brian (06:32) Sure, yeah, please. Yeah. Bernie Maloney (06:56) i s the right -hand half is what a lot of organizations think Agile is. Build, measure, learn, build, measure, learn. The whole idea of the build trap that we talk about in Agile. It's all about the delivery of a solution. Okay? But the left -hand half is all about the discovery of the problem. Okay? And the discovery of the customer. And that's a part of Agile too that most organizations overlook. So you got to ask why. And it comes down to kind of mental models. So when I was at Persistent, if you go look me up on LinkedIn, you'll find some of my employment history. I was at Persistent for a while. They had a really good mental model. And it's something I still use when I go into a client. And they would talk about there's kind of three eras of a company culture. And so culture is really the environment that an organization lives within. And there's an era. where cultures were formed before the internet. So things like finance and government and mining and manufacturing and oil and gas field developed. I mean, I've had clients in all of these areas. And in that sort of an environment, okay, it was, well, an era. One of the things I'll ask, and Brian, I'll kind of like let you represent the audience. Would you say in general, the people that you work with, the markets that they serve, Are they moving faster and all up into a thumbs up, slower, thumbs down, or about the same, thumbs sideways? Are the markets moving faster, slower, or about the same as they were, say, five or 10 years ago? Brian (08:32) I think everything's moving faster, yeah. Bernie Maloney (08:34) Cool. Okay. Now, how about the technology that your clients use to solve problems for that market? You know, moving faster, thumbs up, slower, thumbs down, or about the same as it was, say, five or 10 years ago. Faster. Yeah, cool. Okay. Now, when things are moving faster, thumbs up for yes, thumbs down for no. Do they always move in a straight line? Brian (08:46) No, faster. No, not always. Bernie Maloney (08:56) Okay, cool. So now things are moving faster, but they're not moving in a straight line. So let me ask you, do most organizations try and plan and predict? Is it possible for you to plan and predict when things are moving faster and they're not moving in a straight line? Is it easier or harder to plan and predict? Brian (09:19) I think it's definitely harder. Bernie Maloney (09:21) Yeah, but organizations are trying to do that, aren't they? And it's because their mental model is as a machine. So organizations born before the internet have a mental model of the entire organizational system being a machine, the industrial age, which you can plan and predict. They treat people like cogs in a machine. In fact, the thing that us Agilists will say is, when you say resources, did you mean people? See, that's... Brian (09:35) Yeah. Bernie Maloney (09:50) That's kind of now we're starting to get into some of the culture aspects of this because language actually forms culture. And so you'll hear Angela say, did you mean people? Like when that whole word of resources comes up. But organizations born before the internet, they've got one culture. Okay, they were born in an era of plan and predict. They've got a mental model of the system being a machine. And your listeners would probably agree most of them struggle with Agile. Okay, now there's another era born in the internet but not the cloud. So some examples like here in Silicon Valley, Cisco, PayPal, okay, lots of us have had exposure to them and lots of us recognize they still struggle with agile because agile wasn't really fully formed and articulated. Then there are organizations that were born in the cloud and so places like Striper Square and I use payments because I've had... clients in finance across all three of these eras. So Stripe or Square, they were born in the cloud where things were almost natively agile because the Agile Manifesto had been published by that point. They just inherently get agile. So these mental models of your organizational system being a machine get reflected in the language. So things like people or resources, it turns them into objects. It enables something I've heard called pencil management. Wear them down to a nub, go get a new one. In fact, if you do the research on where the word resources was first applied to human beings, it might shock some people. So I don't talk about that openly. They'll have to find me privately. I'll be happy to point you out the reference. And once I do, it's like, ooh. But one of the jokes I'll crack. And this is one of the ways that you can start to shift the language. If people call you resources, because you know that turns you into an object, start calling them overhead. Brian (11:23) Yeah. Ha ha ha. Bernie Maloney (11:48) Okay, it can kind of make the difference there. Okay, so, but you know, if things are moving faster and they're harder to plan and predict, that mental model needs to shift. In fact, in agile, we talk about you need to move to sense and respond. When things are moving faster, it's kind of like Gretzky, skate to where the puck is going. You need to sense and respond to the situation. So a better mental model instead of a mechanism is an organism. Because think about organisms, like cut yourself, it heals, okay? It senses and responds. Or like a forest fire comes in, wipes things out, and nature always kind of fills things back in. Sense and respond. This gets reflected in the language. So Brian, do your clients talk about metrics? Brian (12:37) Of course, yes. Bernie Maloney (12:38) Okay, cool. So do they talk about efficiency? Brian (12:41) I would say a lot of businesses will talk about that. Yeah, sure. Bernie Maloney (12:44) Yeah, cool. That's the language of machines. Probably better language is diagnostics instead of metrics. That invokes some of the curiosity. And probably instead of efficiency is effectiveness. One of the things I'll say is scrum is not efficient. It's not about utilization of capacity. It's about the production of value, which is all about effectiveness. See, efficiency or effective. Do you go to your doctor for an efficient treatment? or ineffective treatment, Brian. Brian (13:16) Effective, hopefully. Bernie Maloney (13:17) Awesome. Do you go for blood metrics or blood diagnostics? Brian (13:21) Yeah, diagnostics for sure. Bernie Maloney (13:23) Yeah, so now you're starting to get some hints about how you can start to shift the mental model. What you're really doing with Agile, y 'all, is you're shifting the culture, and culture is hard because it's not visible. The tools, the processes, the practices that folks like Brian and I will teach and coach, they're super visible, they're super valuable, but they're often not enough to start to change things. So, Brian, would you say most of your listeners are familiar? familiar with the language of Tuchman of forming, storming, norming, and performing. Brian (13:56) I'd say there's probably a good percentage, yeah. Bernie Maloney (13:58) Cool. I actually like to draw a Satir curve. So Bruce Tuckman, Virginia Satir, they were contemporaries. They were both just researching human systems. So Virginia did a performance axis on the vertical and a time axis on the horizontal. And the way Virginia described it is you're kind of going along in a certain status quo. And so you're kind of along that baseline. And then a foreign element enters and some change. And then you descend into chaos. And you can't see it. like your performance goes down until you have a transformative idea and then through some practice and integration, you rise to a new status quo. This happens to people all the time when they introduce changes in their life like New Year's resolutions. I'm going to get fit and healthy this year. You know, it's a beach body time. And you start doing it and it's like, this is so hard. You're in chaos. And what human beings want to do is they want to go back to the way things were instead of moving through. OK, this happens when you introduce agile into your organization. You'll hear Agilist talk about this as the Agile antibodies. You introduce it, this is so hard, and people want to go back to the way things were instead of kind of moving through. So the tools, the processes, the practices, they're really good, but they're not powerful enough. You got to start changing the culture. Culture is like what we all swim in, but climate is something that you can start to affect. So climate is a little bit closer in to your team, and you can start talking about these mental models. Like when I was at TiVo, I was hired into TiVo to bring Agile in because I had shipped TVs, I knew about Agile. And I was hired in on, I think I can say this now because we're more than a decade past. Have you all ever streamed anything? Yeah, okay. So TiVo was working on that in like 2009, 2010. I got to see that stuff and I was like, really wish I had taken off for them. But that program... Brian (15:42) yeah. Bernie Maloney (15:54) disbanded, okay, and the culture kind of spread in the organization. And I knew that this was a possibility, so when I brought it in, I made sure I didn't just work with my team that was doing a Skunk Works project, where we were just kind of doing some internal development that we weren't, you know, or stealth is probably a better word these days. So a stealth program inside of TiVo that you couldn't talk about. I knew that... when Agile would spread, it would hit some of this resistance, these antibodies. And so I made a case for bringing in people from outside my team so that it was familiar. And when that program disbanded, it organically spread on the cloud side of TiVo because of some of this stuff. So within your own team, you can kind of create a climate. And then when you start to see results like that, that's going to start attracting kind of the rest of the culture that's there. But these mental models, like shifting from mechanism to organism can really help an organization recognize where their limiting beliefs are about how things go. And it's going to be reflected in language. So if you like dive into anthropology a little bit, you're going to recognize that it's really well established. You can change a culture by starting to change the language. And all of us, okay, if you're observing what's going on in Eastern Ukraine here in 2024, that's what's going on. with the Russian occupation, they're changing the language because that's going to change the culture. That's why they're doing stuff like that. So, and even language starts to shape the mental models that you've got. A good example of something like that was when European, you know, when European explorers is the language I'll use, came to the Americas, the natives didn't really have a language for ship. And so they saw these people coming in floating on the water. And that was the way that they could describe it. So even language kind of gets into a cultural sort of a thing. So these are techniques that you can put into your toolkit. Start shifting the language to start shifting the culture, which can kind of help with the mental models. When you got the mental models, that's where the language starts to come from. If you don't have the mental models, you're probably not going to have the language. And I encourage all the folks I work with, start shifting from the whole idea of mechanism to organism. Okay, Brian, was that 15 minutes? Did I go on for as long as I predicted I would? Brian (18:27) About 15 minutes. Yeah. No, but I think that's a good point. There's a thing that I'll talk about a lot of times in my classes where I would all say, you know, the waterfall paradigm is one that's based on manufacturing. And there's a false understanding of what we're doing as manufacturing and it's not. It's more research and development. So you have to kind of shift the process to be one that's more conducive. to research and development. So that's very much in line with what you're talking about here. I love that. Bernie Maloney (19:01) Yeah. Do you think people would appreciate some book references that can kind of like help you? Okay. So specifically on that whole ethos of experimentalism that you just touched on, Brian, I'm currently going through Amy Edmondson's The Right Kind of Wrong. Really good book. Now, Amy is well known because she helped establish psychological safety as a super important topic in organizations. Brian (19:07) absolutely. Absolutely. Bernie Maloney (19:30) So she was coupled, I think, with Project Aristotle at Google. And in this book, she unpacked some really interesting stuff. She talks about failure, and there's types of failures. There's basic, there's complex, and there's intelligent failures. OK, intelligent failures, they're just native to science. You know things are going to go wrong. You're going to have Thomas Edison, the I Found 1 ,000 Ways. to do a light bulb wrong, sort of. That's like intelligent failure. Basic failure, she breaks down into, let's see, neglect and inattention. And those are the things that you really want to start to squeeze out of a system. With that mental model of a mechanism, I would say a lot of, call it management, tends to think of a lot of failures as basic failures. And that's where blame starts to come into a system. Okay, so now we're back into psychological safety. Okay, where you want to establish, you know, that was an honest mistake. Hence the talk title of make new mistakes. Okay, so you can have processes and procedures that can kind of squeeze out some of those basic failures. Complex in the middle is really interesting to talk about. As I'm getting into the material, she unpacks... Now, complex failures are those chain of events, you know, Brian (20:30) Yeah. Yeah. Bernie Maloney (20:54) This thing and this thing and this thing all had to line up and go wrong at the same time for this catastrophic failure to go on. And in medicine, which is where her original research was, they talk about it as Swiss cheese. And she says, if you go into a lot of medical administrators' offices, you're going to find some model of Swiss cheese there. Because they talk about it's like all the holes have to line up for something to go sideways on you. So complex failures. It's a chain of events, a bunch of little things. And she points out that in the research, these often happen when you have an over -constrained system where there's no slack, where you're trying to operate with, get this, Brian, 100 % efficiency. You're trying to load everybody up. So that is just like, it's not just juice on psychological safety, but like, looking at the whole idea of intelligent failures that we want to encourage versus constraining out basic failures versus working to reduce those complex failures and not just thinking complex failures are basic failures, but they're systemic failures that then might be part of the system, might be part of the mental model that's going on that's there. So super juicy stuff. Brian (22:11) Yeah, yeah, that's really good stuff. I've always loved Amy's work and I feel, you know, silly calling her Amy. But Amy Edmondson's work has always been great. Yeah, Professor Edmondson. She, the work on psychological safety, I think was just amazing. And the examples she used in her research are amazing. And, you know, all the stuff with Project Aristotle. Bernie Maloney (22:20) Okay, Professor Edmondson, yeah. Brian (22:36) I love the concept of psychological. I mean, again, not to make this the topic of our podcast, but, you know, I love the idea that they, they, they found that psychological safety was, so foundational that nothing else mattered. That if you didn't have that, that not no matter what else you layered on top of it, it would not fix the problem that you didn't have psychological safety. Bernie Maloney (22:58) Yep. And that's one of the reasons why I say Agile is actually a social technology more than anything else. I mean, that's why it's people and people over processes and tools. This is really a social technology that we deal in. Brian (23:10) That's a great way to put it. I love that social technology. Awesome. I love that. Bernie Maloney (23:14) So kind of talking about Amy and psychological safety and kind of all these systems that we're talking about, another mental model that I like to give particularly my product owners, going back to that Mobius loop. and like on the right hand side is all about delivery, okay, that's where you give team solutions to build. That's what a lot of organizations do. Versus on the left hand side with discovery, it's all about problems to solve. So I like to encourage my clients to instead of just giving people solutions to build, give them problems to solve. Now, for product owners, if you imagine like an onion that's kind of stretched out left to right, so kind of an odd long little onion. Brian (23:41) Yeah. Bernie Maloney (23:58) and on the far right is your sprint. And then as you go to the left, you're at a release, and further out to the left, you're in roadmap, and way further out into the left, you're into these vague things like vision. So product owners kind of deal with this whole span of things. And in between, product and sprint goals start to make things a little bit more concrete. Okay, and... One of the things I'll do for my product owners is I'll take that Mobius loop and I'll overlay it on a planning onion like that and go, do you get to see how, like what we're talking about here, you're starting out way vague in discovery and you're getting way more concrete as you get into delivery and into the sprint. And really the job of Agile and Scrum is both. It's not just about turn the crank on the machine. In fact, I think it's unfortunate that there's a book title out there of twice. the work in half the time. I actually like to pitch this as more it's about twice the value with half the stress. Okay, now as you imagine that Mobius loop kind of overlaid, one of the things I'll unpack for folks is when you're way out in that vision area, there's a lot of uncertainty that's there, okay? And you're actually going to have to do discovery. You may have to run some experiments. Brian (24:58) Yeah. Bernie Maloney (25:24) Okay, and it's only as you get closer into delivery that you want to get closer to certainty. And really, that's kind of the job of a product owner is squeezing uncertainty out of the system. Initially through discovery of the problem to solve, who to solve it for, what the market is, but it's the job of the whole team in Agile to squeeze that uncertainty out of the system. Brian, I'm sure you've had folks like talk about spikes. You ever have people get wrapped around the axle about like including spikes in their product backlog? Brian (25:48) Yeah, for sure. yeah, for sure. Bernie Maloney (25:54) Cool, the way that I frame that up, okay, so here's a mental model. That's just technical uncertainty that you've uncovered. Great, okay, so now we've got to go squeeze that uncertainty out of the system. So stop getting wrapped around the axle on stuff like this. Just like stop trying to plan and predict things. Instead, kind of get into sense and respond on all of them. And there, I've kind of brought it around full circle for you, Brian, for where we started. Brian (26:09) Yeah, no. No, that's great. That's great stuff. And I love the fact that we can bring it back full circle. Well, this is fascinating. And like you said, we could press play and go on this for another half hour very easily. But we'll be respectful of people's time here and keep it to our normal time length. Bernie, I can't thank you enough for coming on. I really appreciate you sharing your experience with us. And... what you've learned over your years of working in this profession. Bernie Maloney (26:50) Thank you so much for asking me, Brian

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

Join Brian for the 100th episode of the Agile Mentors Podcast as he dives into the future of Agile with fan favorites Scott Dunn and Lance Dacy. Listen in as they explore the evolving role of AI, the continuous need for leadership innovation, and the Agile community's journey towards greater accountability and effectiveness. Overview In the 100th episode, our expert panel celebrates by examining the latest trends and enduring challenges in the Agile industry. They discuss the critical need for organizations to adapt and innovate, particularly through leadership and management strategies that foster high-performing teams. This episode is a deep dive into how embracing change and technological advancement can propel the Agile industry forward, ensuring that organizations not only survive but thrive in an ever-evolving business landscape. Listen Now to Discover: [1:10] - Join Brian in a special celebration of the 100th episode of the Agile Mentors Podcast, featuring a look forward to future innovations in Agile! [1:43] - Brian kicks off the landmark 100th episode with a forward-looking panel on Agile and Scrum's future, featuring experts Scott Dunn and Lance Dacy. [4:01] - Listen in as Brian asks the panel to share their insights on emerging trends within Agile and Scrum, setting the stage for a thought-provoking conversation. [4:15] - Lance highlights key trends including solutions for scaling challenges, the integration of AI in Scrum, and innovations in leadership and management. [6:54] - Scott emphasizes the enduring impact of Agile and Scrum in driving organizational enhancements. [11:36] - Lance underscores the critical need for leadership and management to adopt innovative approaches and acknowledge generational changes to effectively engage and support their teams. [13:30] - Addressing the provocative statement that 'Agile is dead,' Brian explores its implications on the real-world demand for Agile compared to its perceived necessity. [14:50] - Brian, along with Scott and Lance, urges the Agile community to recognize its shortcomings and learning experiences, which they believe may be contributing to negative perceptions of Agile, and how the community could approach it differently. [24:10] - Brian encourages you to try out Goat Bot, Mountain Goat software’s Scrum & Agile AI tool. This free tool is trained to handle all your Agile and Scrum queries—start asking your questions today! [25:58] - The panel explores the impact of AI on enhancing agility in organizational practices in estimating, development, and so much more. [32:20] - Brian stresses the importance of using AI as a tool to support, not supplant, discussing ways it can improve rather than replace human efforts. [43:23] - Brian shares a big thank you to Scott and Lance for joining him on the 100th episode of the show. [43:44] - Brian thanks you, the listeners, for your support and shares his excitement for the future of the show, inviting you to send us your feedback or share your great ideas for episodes of the show. Just send us an email. [44:57] - We invite you to like and subscribe to the Agile Mentors Podcast. [45: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, such as CSM, or CSPO, or Better User Stories Course. We also have Advanced Certified ScrumMaster® and Advanced Certified Scrum Product Owner®, where we get right into the good stuff and have some deep discussions. 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: Scott Dunn Lance Dacy Goat Bot Certified ScrumMaster® Training and Scrum Certification Certified Scrum Product Owner® Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® Mike Cohn’s Better User Stories Course Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum. Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away. Auto-generated Transcript: Brian (00:00) Agile Mentors, welcome. This is our 100th episode. Can you believe it? We've been doing this for 100 episodes now. So first, before we even get into today's episode, I just wanna say huge, huge thank you to you. Thank you for listening. Thank you for giving us feedback. Thank you for giving us suggestions. We would not have made it to 100 without you, so. Huge thanks to you. And to celebrate, we're trying to do something different here for the 100th and not just let it go by and not mark this occasion. So what I wanted to do was to have some of our regulars, our favorites on together so that we could really kind of look ahead. So let me introduce our panel for today. First of all, I've got Mr. Scott done with us. So Scott, welcome. Scott Dunn (01:00) Thank you, Brian. Glad to be here. This is awesome. Congratulations. That's so cool. Brian (01:04) That, thank you, thank you, thank you very much. And then another favorite that we have on quite frequently is Lance Dacey is with us as well. Lance Dacy (01:13) Hey Brian, congratulations once again. I remember us just talking about this when you were starting out with podcasts and you look at 100. You do this every week, right? Is it a, has it been a hundred weeks? Wow. Brian (01:22) Yeah. Yeah, we do this every week. We missed a couple. Our listeners probably know there's been a couple of times in there we've taken some small breaks around holidays and other things. But yeah, this is going on just about every week since then. Lance Dacy (01:38) Well, congratulations. That's amazing. Brian (01:40) Thank you, thank you. Yeah, I'm amazed and as I said, very, very grateful. And it really hit home to me when I went to my first conference after doing this and people would come up and say, hey, I listen. That was really a cool moment. And I always tell people, hey, I'm speaking to other conferences, come and say hi. Come and say hi to me this year. So as I said, I wanted to have a panel so that we could talk about, we've been... Scott Dunn (01:40) Amazing. Brian (02:10) doing this for 100 episodes and lots has changed, lots have changed over the past year and a half, almost two years now that we've been doing this. We kicked off on, I think it was May 18th, 2022. So we're coming up on two years of doing this. And my thought was, what's gonna happen over the next 100 episodes? Like, where are we gonna be in the next two years? Where are we gonna be in the next five years? What kind of things are changing? What are we going to think about stuff over that time period? So I wanted to have a panel to kind of comment and discuss this with us and Where I wanted to start is maybe not where I think most people are going to think I'm going to go But I want to start with kind of the agile industry kind of the way things are going now for Coaches consultants scrum masters product owners So I'm gonna throw this as an open question and whichever of you wants to go first, go first. But what do you think we're seeing right now? What kind of trends are you seeing in that realm? And where do you think it's gonna, where do you think it's going? Scott Dunn (03:26) I nominate Lance to go first. Lance Dacy (03:28) Okay, here, obviously they're thinking about Scott. It looks like he's got something to say. Okay, well, that's a tough question because I think it still depends on the industry and the organization. It's all made up of people still. So there's still a lot of variables, I think, that affect the way that we do our jobs as transition coaches or business agility coaches or agile coaches, whatever you wanna call us. I think... Brian (03:29) Hahaha Lance Dacy (03:59) You know, I think there's still plenty of organizations out there that are struggling to bring their people together to deliver great products. And it's not because they don't want to, it's just lacking the skills and the frameworks and things to do that. So I still think that there's some organizations out there that benefit from saying, hey, let's just start from what we know and start doing this and then adapt to it as it changes. But I think a lot of times organizations, I think scaling is one of those big. problem child out there that people have kind of learned how to do this with smaller teams and smaller parts of the organization, but getting the whole organization to collaborate together. And of course, they look to another framework for that. And I'm kind of framework agnostic, especially when it comes to scaling, because I think at the end of the day, if you can't do it well in the small environment, it's going to be very difficult to do it well in the large environment. So the best thing you can do is kind of analyze your own situation. with like value stream mappings and cross-functional teams and things like that, and try to make sure that you're organizing yourselves and preventing waste as much as possible, I think is one of the big things. But I've also seen a kind of an uptick in, of course, these practices in agile being distributed over non-software domains. We've seen that for a long time, that's not necessarily a new thing, but I think it's gravitating more. to that. But I think the biggest one is really what we're talking about today is how is this AI stuff or what we have been talking about, how is that affecting this? And I think it's here quicker than we really think, or already here. And so trying to figure out how to handle, you know, data driven decision making based on that and, you know, using these tools to integrate. And then I think the last one that I would talk about is leadership and management. I think There's a specific type of environment and culture required for these people to thrive and collaborate and leadership and management has not seen a lot of innovation in the last 150 years. So, I find myself spending a lot of time coaching executives and mid-level managers on how to foster an environment that we can know how we practice psychological safety, empowering people and making it a great place to work, especially in this remote distributed environment. So I don't know if it's... All that's fairly new, but I think it's more prevalent than it was in the past. So I don't know, Scott, go ahead. Scott Dunn (06:28) No, that's good stuff. And I've only got 35 points I want to walk through. So one, I think we had all agreed that this idea of agile seems to be the common experience we're seeing as we're still coaching out there in organizations. They think that they've already done that. That's in the past. What's next? Or they settled in like, we're just hybrid. And it's not a. So help us move forward. It's like, no, we weren't done that. Here's this other thing. But the other things they're needing. And I like it, Lance. You kind of mentioned a couple of other words that people use, like organizational improvement, organizational chiasm, these ideas, like, hey, we're trying to get better. And I almost rather use those words because if I use a word they think they know, then we've kind of lost the fact that, you know, we're there. It strikes me, it's a little bit like marketing. They're just like, nope, marketing's done. And now we're doing this. And like, no, marketing's always learning, moving forward, growing. And I think we're gonna see this idea they realize, like, oh. Agile wasn't like a destination we check the boxes now they're on Scrum team. So that's one thing we're continuing to see. And the reason I'm saying that is the problems are still the same problems. We're talking earlier about capacity management, visibility, clear, you know, can execs see where we are in these larger initiatives? And the answer is like, no, they're still not doing those well. That speaks to whole org. And two quick stories on that is one, we're working with a company that decided like, yes, we're going to take this whole org approach. Lance Dacy (07:27) Yeah. Scott Dunn (07:45) And once they, within a few months, they'd gone from cycle time of 100 days down to 10. They had tripled their productivity. They went from one release every two weeks to seven in a day, right? But that's because the whole org is represented as they're rolling out, actually holistically. Let's contract that with a company we're just talking to this week. I was trying to describe getting a group together, it's representatives across other departments who have people who have authority, who have influence, finances, et cetera. they could not grasp the idea that there'd be a team working on improvement items across the org. It took several explanations, like I'm not talking at the team level. I'm talking about the team that's working across the org level. And what part of this comes back to is I think of the idea of I'm a manager. This is my own like awakening recently. If I'm a manager, let's say I'm the software engineering manager, I'm the director, my concern, this is my mistake earlier, my concern is not, are we doing ads all right? My concern is, is my boss getting what they want? If my boss wants clear reporting on where we're at the features, I don't care if it's Agile, waterfall hybrid doesn't matter. Did you show me a nice pretty report that gives them what they need? That's what I, that's what I do not wanna be called into her office on Friday about, right? So I keep mistaken, like they wanna do Agile, right? No, they wanna check the box and what they're accountable for and meet those expectations. And I know the higher up the or we go, the less they probably understand about Agile. At least that's the surveys that I'm running is like a... a 20, 30, 50% gap between what these people say their managers think they understand about Agile and what the people actually do in the work know that they understand Agile or not, which is always a large gap. A good example of that is remote. I'm not trying to kick a dead horse when it's down or whatever the saying is, but we've talked about remote a lot, but here's what we're seeing is, I think the basis of a lot of this return to office is simply, I don't know my people are working or not, I just need to see them. Brian (09:30) Hahaha. Scott Dunn (09:41) I can't tell, and I can't see them, I can't tell, and I get nervous, which really means I don't really have an understanding of fundamental aspects of how work is done using transparency, inspect and adapt, all that, right? And because I can't really, I don't really have mastery over that, I'm gonna need you in the office at least three times a week. Because I don't, I'm not really watching the work anyways, but at least I know you're showing up, and I'm accountable to make sure people are busy and working. That's, you know, I draw it down to its most rudimentary level. To me, it's a reflection of the capability of management. You mentioned that, Lance, about leadership. I think we're starting to see Lance Dacy (09:41) Right. Brian (09:52) Yeah. Scott Dunn (10:11) What we probably will see is this real cutting line of those who get it and trust their people and they work. And we've seen, you know, 10X, 100X on, on experts really let loose to do their best work and those who are simply like, you know, managed in that traditional sense and all the drawbacks and your loss of talent, all that. I think the companies will have to pay the price eventually. Thinking back to the time when people didn't really want to go ad drug because they thought it was a fad. And it didn't take but a few years, like, um, I could be wrong. Brian (10:35) Yep. Scott Dunn (10:38) maybe that is a thing we need to do, right? And then everyone gets on board, but there was a lot of kicking and screaming and doubting the early years. I think we're gonna see that with remote work is made like the proving ground of do you really work this way or not as a manager? Do you get this or not? So those are some of the trends I see. I still see a lot of people still in the very fundamentals because they think these things are already understood and known and we're moving on to something next. There is no next. I think the pace of change out there is if you're not working this way as an organization, you're losing ground already. Like... while they're listening to the podcast. Lance Dacy (11:08) It's like the remote, you know, what you were just saying is like the remote is the automated test for your operating system at work is like, if it works like that, then we're likely doing some really good things. But you know, I remember, um, I'm going to show my age here though, but prior to my technology career, I worked at FedEx and I was in leadership and management, managing their third largest hub here in Fort Worth, Texas, uh, the air hub, you know, and FedEx did a great job teaching leadership and management and all that kind of stuff. Brian (11:08) Yeah. Scott Dunn (11:14) Thank you. Lance Dacy (11:36) And I remember them focusing on the idea that you cannot lead and manage people currently how you are going to in the future because they were talking about how the new generation is coming on board and they just won't tolerate certain things. And I think you hit it on the head with that, Scott, that if these managers don't learn how to lead and manage with this newer generation, two or three removed from what I'm talking about. you're not going to have any employees because they will not tolerate it. They do not work that way. They work radically different. You know, I'm going to categorize money as a gen X person. And I'm going to say we were taught to be very individualistic, climb the corporate ladder, you know, keep your pain to yourself, just grin and bear it, fight through it, do the best you can and be autonomous and don't rely on a lot of people. And, you know, don't trust anybody. You know, the latchkey kids, we just were independent. We learned how to do it all. And that's not necessarily bad. We needed to be managed a different way than these people now. I, and I've got four kids, so I see it. It's like, they're not going to tolerate this stuff. So you hit it on the head with that leadership. I mean, coverage, a broad spectrum, but, um, Mike gave a talk in Oh nine. I'll never forget this. When I first went to the scrum gathering in Orlando and Oh nine, and he was on a panel and he said it really succinctly. He said, I hope we don't call it agile or scrum anymore. It's just the way that we work. Brian (12:36) Yeah. Lance Dacy (12:54) And he was referencing object oriented programming. You know, he said, we don't call it object oriented programming anymore, it's just programming, you know, object one. And so it's like, yeah, we're not going to, let's not have this debate. We want to build the highest business value things as early as possible with the least amount of costs who can argue that that's not the right way to run an organization. So let's not debate it. Let's not use the buzzwords. Let's just do it. Brian (13:01) Right. Scott Dunn (13:12) Yes. Brian (13:18) Yeah, I agree. And it's, you know, kind of back to what Scott said, too, there is a marketing issue here, right? There is this kind of idea of people are so saturated with the terms that they've experienced them and they feel like, hey, I know that I know what that is, I don't need to be I don't need to learn any more about that. And now I'm just kind of moving forward when they don't really. And that's what drives all the people out there that are saying Agile is dead and all the Agile is dead speakers and all that stuff. It's not dead. And if you listen to them, they don't say it's dead. They just say, people don't understand what it is. And so they're doing it wrong. I think there's kind of this interesting dynamic going on. Right, because on one hand, I think we're at a time when Scott Dunn (13:54) Mm-hmm. Brian (14:03) businesses could benefit the most from doing things like Agile because they're gonna get the most with less by doing these kinds of approaches. However, at the same time, we're hearing stories of entire Agile departments being let go in different organizations. And we're seeing people who struggle after coming through classes and stuff finding work as a scrum master, even though there's a demand. There's high demand still for these kinds of things. So there's sort of this dichotomy that's going on of, I think there's a slump going on in the agile demand when the need for it is high. And maybe that's a marketing, right. Maybe that's a marketing thing that we haven't done a good job, but I wanna propose one other thing here and I wanna get your guys take on this. Lance Dacy (14:51) than ever. Brian (15:02) The people who say Agile is dead and they say that, we shouldn't be doing this because we should call it something else. Because no one understands what it is anymore. And that's why they say it's dead. I have generally thought of those, and I think many of us sometimes fault the leadership a little bit in this to say, they didn't invest enough to understand it. They didn't really support it, right? Kind of that mentality. But I think that as an Agile community, that we need to own up. Like, I think we just need to step forward and say, you know what, we have not always done it right. And there's been plenty, you know, I talked about this in the Scrum Master class. There's plenty of Scrum Masters out there who think that the job of being a Scrum Master is to schedule meetings. And that is it. And... Scott Dunn (15:55) Oh. Brian (15:58) You know, those people, you can understand why a company would say, I don't need that person. I don't need a person to do that. And then all of a sudden they're letting go all of their Scrum Masters because they think that's what a Scrum Master is. So I think we have to own up a little bit to say, we're partly responsible for this, right? We're partly responsible for the bad impression that Agile has and we just gotta own it and say, yes, that's true, but that's because we've made mistakes as well and we're learning. Lance Dacy (16:17) Thank you. Brian (16:28) And now we know better, right? Now we know what we're supposed to do. But the pretense that we maybe came into it with, saying, hey, we know everything and we know how to do this stuff, was what caused the downfall, I think. What do you think? Scott Dunn (16:32) Hmm. Lance Dacy (16:44) It's like the overlay though of saying here, here's how you do it, right? I think what we got wrong or not necessarily wrong, just we didn't know any better at the time is, I've worked with 20 companies and this way work, let's try it. And then if it doesn't work, we'll adapt it. Cause I think it's always been about that. But you know, just like any approach, you know, the effectiveness of that approach depends a lot on how it's implemented, supported, adapted, taught. And I feel like what we should just start focusing on, you know, it's hard to put this in one term, Maybe it's just like helping and facilitating the creation of high performing teams. Like that's an unarguable thing that you would want to have. What's happening is the organizations either whether they misunderstand the role or have a bad experience in the past with it because you can't say their experience is invalid, right? Everybody has their different experience and opinion and what they went through. And I acknowledge that. But if you think of any professional sports teams, what's happening in the organizations in this world? Brian (17:20) Yeah. Lance Dacy (17:43) is they're getting rid of the coach of the team. And what we have to do is start recognizing what does the coach really do is trying to make the team high performing. You know, in professional sports, it's to score points and win the game, right? Well, kind of trying to do the same thing here, you would never get rid of the coaching position saying, well, all they do is watch film and tell the team what they're doing wrong. No, I mean, Andy Reid, you know, the Kansas City Chiefs, they won the Super Bowl, arguably the best football team in the world, if that's what you're using as a bar. And... Scott Dunn (17:46) Thank you. Brian (17:55) No. Scott Dunn (18:03) Thank you. Lance Dacy (18:12) And so they've arrived, they're the best. Do we get rid of Andy Reid? No, they need him even more because they get complacent and they get this idea that we don't need to change anything. And I see plenty of teams like that. It's like, no, the coach has one of the hardest jobs in the world is to tell the best performing team in the world they can get better. And the organization sometimes is the wet blanket and suffocating the environment for which that team can perform. Scott Dunn (18:16) Thank you. Lance Dacy (18:37) And I feel like, you know, instead of whether you want to call it a scrum master and agile codes or whatever, it's almost hard to use those terms. Some of these people anymore, because they'll just sit there and argue with you about it, but let's just say I'm trying to coach a high performing team and how can you argue with that, you know? Brian (18:50) Yeah. Yeah, I don't think you can. Scott, what do you think? Scott Dunn (18:53) If I was to ask you, well, if I was to ask both of you, do traditional management, whoever's making hiring decisions, do they know what an agile coach is and what's in telling them that they're doing well or not? And I would argue the most don't. And I think that's why we see a lot of people, I mean, in the end, people follow the money. I don't call people for work and their own self-interest. So if I can just update my LinkedIn profile and change it to agile coach. and whoever interviews me can't tell a difference. And that means I get a salary bump and of course, or let's just tell it like it is. And I think your listeners, I know you to be good with this. If I can just take a two day class and I'm gonna get a 25% salary increase, whether or not I get it or not, let's not even go there. Like I passed the test, I've got the certification. And unfortunately, I think that's more the dynamics of any given market is like, oh, it jumps to the solution, right? I just, you know. hire these scrum masters and I've done the agile thing. And even though any of us would say like, that's much bigger than that, this agile coaching involved is much more than the two day class that you need, et cetera. But think about that. I'd look at the people that I've trained, which, you know, is thousands. How many companies actually came back and said, we need help as an agile coach? 20, 22 dozen, right? That we actually went in and did real transformation work. So that's them not asking. That's them like, no, we got it. I think that simplicity of understanding Do I take a solution or do I go through a mindset change? Well, taking the solutions is going to be easier. So I'm going to jump to that rather than like reflect, like, I think we need to change. Change is hard, we agree. So back to the point of like, are we to blame? I see some of that market dynamics, but we do that with diets. We do that with the career. Also Greg, we wouldn't just grab something easier than actually go through the change. So I do agree with you, but I think it's a good point. How we try to re-message that when the world already thinks I understand it. I think we're watching this happen. When I look at companies in that space, Brian (20:30) Yep. Scott Dunn (20:42) They are using different terms and phrases. I think that moves us away from, maybe that's an aspect of like, where to blame. The other interesting thing, Lance, you mentioned about the coach and we don't fire the coach. And I think that's the best example I go to is, look, I'm a business owner of a professional sports team. I'm watching the dollars and I don't wanna have to pay Andy Reid millions, but I know it gets results. And I don't wanna coach for the offensive line. I don't wanna coach for defensive, but the results are clear whether that works or not. Brian (21:03) Yeah. Scott Dunn (21:08) The other thing that's interesting is you watch some of these coaches, like when it changed in college football with name engine, name engine and likeness in terms of attracting students for different reasons. Like I can make money during college. I don't have to hope I make the pros. And how that changed the game significantly to where some coaches like, forget it. I don't want to play this game where they're now empowered to make their own decisions on where they want to go and not just sit on the bench. If I want to sit on the bench, the transfer portal. So you're watching dynamics play out on what does that mean to bring that change in? I do think in the end, there's probably a simple split on, there's an organization that needs to continuously improve and look for ways to do that. Not as one-off projects of, hey, let's do an improvement project here. But as a feeder backlog, but simply there's always ways to improve and stuff's always coming in and we're always working that as a layer of the way the organization runs. When I see a chief agility officer, some of these other roles, I think they get it. I think manufacturing systems get that with like lean thinking and like, That's just what we do. We're always looking for that. I don't think software engineering. And this organization get it. And to be honest, my friends, you can tell me if I'm off. I don't know if they got sold that truth of this is always going. It is not put all your engineers on the teams, hire a scrum master, change someone's title of product owner and you're good, right? But I think that's what they kind of thought it was. And then they're done, but that's a team level. It's not organization level and it just sits there. So I guess there is someone with the blame because maybe that's what they were taught and not the bigger picture as well. Brian (22:25) Yeah. Yeah. Scott Dunn (22:35) Perhaps. Lance Dacy (22:36) The rebranding is interesting the way you said that. I don't, you know, let's call it something other than Agilent or Scrum, whatever you were talking about. And that's what organizations do when things are broken, is they reorg. We're gonna just change the name of it. It's like following a diet plan and going, well, I don't like that it doesn't let me have sugar, so I'm just gonna call it something different. The constraint. Brian (22:48) Hmm. Yep, you're right. Scott Dunn (22:50) Yes, yes Lance Dacy (23:02) You know, the constraint is there to make you better. And I think that's what a lot of people don't get about, let's say the Scrum framework has a lot of constraints built in not to make it harder to do your work. And I will argue it's harder. Like I tell people all the time, this is a harder way to work. It's not an easier way because it requires all of us to come together. But you just said it so eloquently, Scott, I just thought about that, that they just, who cares what we call it. Brian (23:03) Yeah. Scott Dunn (23:16) Yes, for sure. Lance Dacy (23:26) the organization and the leadership is stuck by saying that at their level, all they gotta do is call it something different and now it's solved. All I gotta do is change the org chart on a spreadsheet. And I can't tell you how many organizations I work with where I'll get a note and say, well, we're going through a reorg right now, so we gotta hold off on this training or do this or do that. It's like, well, you just went through one, I've worked with companies that have been their coach for a very long time. It's like, how many of these are we gonna go through? What's the purpose? When are we going to start realizing that it's not who reports to who, it's who's doing the work and what's the environment and culture we've created for them. And I feel like leadership and management, I don't even care if it's software. Like Scott, you're saying software, we really don't get it. I'm not sure any company really, there's a few out there that I would say their leadership and management's working really well, but the operating system for the culture is broken. And, you know, we know that for a long time as agile coaches, but it's like, there's some benefits to be gained even while that's happening. Brian (23:54) Yeah. Lance Dacy (24:24) that we can get some efficiencies going here and they're still better off. But we've hit that next level, the problems are more complex now. People and it's leadership and it's hard to change those because they've been doing it for 150 years this way. You know? Scott Dunn (24:34) Yes. Brian (24:34) Yeah. Scott Dunn (24:40) Yes. Yeah. Brian (24:41) Yeah. Well, we can't leave the episode without talking about AI, at least a little bit, because I know you brought that up already. But yeah, we definitely need to think about AI in the future. And yeah, yeah. Because I know we talked about that a little bit when we were meeting here before we started to record. But just curious. Scott Dunn (24:46) Hahaha! Lance Dacy (24:52) leaders and managers. Scott Dunn (24:54) Yes. Brian (25:06) Where do you think that whole thing is going? What I should say is, how do you think it's going to affect agility? That's the big question. Lance Dacy (25:17) You want me to go again first, Scott, or is he going to flip flop? Scott Dunn (25:20) No, no, we're not flip-flopping. It's you, man. You got it. I'm not changing. Brian (25:23) Hahaha Lance Dacy (25:23) Okay. He has some reason to do this. You know, I feel like I'm walking into a trap here. Um, the way he's going to trap me. Um, well, and you know, we were kind of talking before we even, you know, started the podcast, but I was mentioning, you know, project management wise, you know, that I believe AI can bring a lot to just helping teams become more efficient and productive just at a superficial level by simply Scott Dunn (25:28) With pretty... Brian (25:29) No, that's a wrong answer, Lance. Lance Dacy (25:50) if we're talking about Scrum, let's say, because a lot of us practice Scrum and we teach it, you think about a sprint planning exercise and how often it's very difficult to just simply explain how to come up with your capacity for the next two weeks, and based on your skillset and the work needing to be done, are we sure and confident that the work we've committed in this next one, two, three, or four week period that we can actually get it done? as a cross-functional team within the constraint of getting something usable to the end user. I think a lot of people forget that as well. So I feel like automating things like sprint planning where you can feed in a profile of all of your different skill sets and their capacity. We no longer languish over this big spreadsheet that I used to use back 10, 12 years ago. There's a lot of better ways to do it nowadays, but I think eventually you just say, based on this team and what they've given me, here's how much work we can do. feed in the work and say here's the best sequence of the work. You know, the harder part is fitting, you know, utilization is not really a topic I want to get into because I think it's always misunderstood. But once you account for all of the slack time that you need to, you want to be as utilized as possible. I think using AI to help figure out what's the best path. Like I do an exercise in my class where I give them 10 backlog items and based on the different skills, capacity, and things that need to be done, what's the best fit? Right, so in data science, we talk about fitting the model. Why not use AI to help us be the best sequencing of the work with the highest value and the best way to use our capacity? So automatic task assignment, just like we do with calendars now, where people can feed in the work they need to do and it'll create the best calendar fit to maximize your workload. Automated code is coming, you know, we're already here. You know, automated. backlog creation, chat bots, AI driven testing. I think all of that is, if not here already around the corner, that's gonna affect, hopefully in a good way, the way that teams do that. Now, we can have a whole nother topic of how that affects product and marketing, because I think the biggest issue we have is getting closer to the user, and understanding and having empathy for them, because too often we get caught up in our own world that we're just... Brian (28:03) Yep. Lance Dacy (28:10) languishing through trying to get the work out. Well, why are we doing the work is the real reason and what's the best way we can get that work to the user that solves their problem. So I'll pause there. There's a hundred things I could go in. I had 35 bullet points. I have about 110, because I love this stuff, AI and data science and all that stuff. But Scott, I'd like to hear you had some good ideas in our pre-talk as well. Scott Dunn (28:14) Thank you. Thank you. Well, I appreciate you inviting me out to the Lance Dacey podcast. I just want to say thank you for that. Right when he drank his water too. Brian (28:37) Hahaha! Weird. Lance Dacy (28:44) Right. I can't respond. Let me take a scotch now that I can respond. Brian (28:46) Yeah. Scott Dunn (28:49) Yeah, he just needs to take a drink. He's ready to go. I know I love it. I love all the ideas in the Thoughtsland. So on my particular view, when we look at the companies we're helping, so we're Atlassian partners, so I'm watching what they're doing. And I mentioned about the fact that it can automatically do like acceptance criteria, you can ask. Anything about, take all the, what we used to call it, the tribal knowledge. It's gonna do that for you. I don't need to track down who's Lucy whomever. I'm just gonna ask it and it knows. I can say, give me a spreadsheet of the people involved with this. What's the background of this project? Any of that tribal knowledge is like, it's already there now. All that data sitting in Confluence, and Jira, et cetera, ability to create tickets. I'm not going and manually creating tickets anymore. I just say, create a ticket for this thing. So all those add up to lots of saving, time savings, all the manual stuff, anything that you just already know. And everyone hates making the tickets and doing so. it's going to take care of that stuff for you automatically. On the dev and engineering side, I'm seeing a lot around what seems to be promising, impossible, certainly code reviews, like there's a template of things that you know you're checking for in code reviews, readiness to go to production. Can it create these models and things? I think we'll wait to see. We're talking about the case tools, but I believe it will because it's not limitless on when we're creating basic applications. If you take your simplest thing like hello world, you know. or a basic screen that's only got five things or a login screen, there's only so many permutations what's gonna happen with that. And it can learn those things and do those things. Software engineering is your biggest cost for software companies, these engineers, and they're hard to find, and you got time zone issues and all these other things. Everyone's looking for ways to reduce cost right now. We've got issues of just getting the talent and the source, and you got parts of these engineers' work that they do not wanna be doing anyways. So I think you're gonna see a lot of those things put pressure on figuring that stuff out. But between the computing power that we're talking about, how much can be handled by those graphics chips and how much information is out there, I think you're gonna see real wins of measurable significance that's gonna be proven out and certainly driven by the business leaders themselves trying to find where can we reduce the cost with the promise of some of these things. But those are some that I've already seen. We're definitely watching, as I mentioned, Brian (30:43) Yeah. Scott Dunn (31:12) on the Scrum developer side, just saying like, what's happening out there? And just take a look and see what we can do. But you're gonna start finding the simpler solutions that are gonna be chipped away at first. I think about the self-driving cars. I remember thinking there's no way the car can handle all these, you know, what felt like limitless situations. It really isn't. There's only so many things happening on the roads and they have slowly learned to do that. I think it's gonna be the same on the engineering side as well. Brian (31:31) Yeah. Yeah, I mean, I agree with both of you. I kind of think that I've taken a stance on it, like in the past, I just see it as a tool. It's a more advanced tool and it can do some things better than we can right now. There's some things that does really well and there's some things that right now it's not very good at. And I think it's important to try to understand that, right? I'm not gonna, you know. I think I've come to a place where I would never say, I don't think it could do X, Y, Z, because I think that eventually it can. I think that there's gonna be things it can do. And it's just a matter of time before it can do pretty much anything that we could be doing right now. Even right now, one of the things it's really, really bad at is having ideas. It doesn't really... Scott Dunn (32:10) Right. Brian (32:30) brainstorm or it can give you ways of, it can give you some little tidbits and things that you can build upon. But having used it to help try to write a blog post or anything like that, well, here's an experiment, right? Go to any, your favorite AI and ask it for 10 business ideas based on whatever, just, Uh... Lance Dacy (33:01) Of course it's not going to be good at that. Brian (33:03) Well, no, it'll give you, it'll give you 10. Scott Dunn (33:03) There's a creativity problem right there. We have a problem with creativity. I see it. Lance Dacy (33:07) I'm just kidding, bro. Brian (33:08) Yeah, it'll give you 10, but then go back and ask it and do a new chat, ask it again. Do a new chat, ask it a third time. Compare the answers you got across all three. And what you'll see is it's a lot of reused stuff, right? And the reason that it's recycling it, the reason it's reusing it is because this is a large language model. This is pulling from what it's been trained on, right? It doesn't invent a new thing itself. Lance Dacy (33:33) Mm-hmm. Create new you Brian (33:38) Right, now again, I'm not saying that it can't do that in the future, but what we have today is not a creative source in that way. It has to have the training data, even image, kind of AI image generators, that's built on what it's trained on. So you can't train it to a point to say, give me a picture of something that you haven't been trained on, right? weird picture that you have nothing in your database to go back to and use as a reference. It can't do that because it can't imagine, right? Yeah. Scott Dunn (34:18) Yes, that's the key. Lance Dacy (34:22) I was working with a company, they do ads, helping people come up with ads. So a lot of marketing spend money out there, right? You can tell it what kind of market you want to go into, what your competitors are doing, and very quickly feed it some images, feed it a few websites, and it'll give you 100 different ads with the words and everything you want to take on it, and already give it a conversion score. Like... Brian (34:44) Yeah. Lance Dacy (34:45) this ad should get this amount. And it was amazing to me, because I kind of struggle with that anyway, as a business owner, creatively coming up with content and ads and things like that. Like we were talking about earlier, I don't think on this podcast, but like being a co-pilot, having the AI stuff be a co-pilot where we kind of use it as a tool. I think eventually it'll be vice versa, ironically, where we'll be the co-pilots. I think... You like personalized user experience, creativity type things like, you know, how we do AB testing and stuff. Why not let AI do a lot of that user research and spin up the code very easily and figure out click patterns and things like that. Like I could say, I need nine different designs for this one screen. I mean, that used to take weeks, if not months for a designer to sit and attend, I'm not trying to bash their field. I love working with them. And. They're very creative people, but I feel like that's going to be the next step with this AI is, hey, give me nine options. And then that designer spends less time creatively. They get better ideas sometimes. Maybe some of them don't like that. I don't know. I'm not a creative person like that. But I can see that helping me in saying, hey, I don't have to hire these nine marketing people or five marketing people. I can just say, hey, let's look at those things. So I think that user, that creativity, Brian, is what you were hitting on imagining things. Brian (36:02) Yeah. Lance Dacy (36:03) Yeah, give it a lot of data can give you options and then you can take that and come up with the ideas as a human, but yeah, eventually that'll all be taken over too, I think it's all taken over the world. T1000, here we come. Brian (36:15) I think you've got to have one of the concepts that's out there is referring to these as agents and having multiple agents that will carry out a different task for you. And I really think that's when I think about the future of this kind of stuff and how this would affect a typical software development team, that's what I see. We have hierarchies in our organizations that exist. And those are essentially different layers of agents, right? Lance Dacy (36:23) Yeah. Brian (36:43) And I think that that's what we're going to see with software development teams and other things is we'll have a deployed network of agents and these, these AI agents will speak to each other and they'll, they'll refine what each other do. Uh, right. And it makes it easier for us, but again, we've got to have the idea to generate it, to start it, right? It just, it can't do that on its own right now. Lance Dacy (36:57) make it easier for us. Scott Dunn (37:03) Cheers. There's definitely a few things where I've just been popping in, where I had to do some legal docs and I just went there and had it write them. They were great. Just fill in the blanks. I was waiting to get content back from someone about a speaker, maybe somebody to go about Mark Kilby on remote and waiting and waiting. I'm like, dog gone. I just wouldn't ask, you know, chat GPT tell me about Mark Kilby, what he does and grab that. And it did a great job. Put that out there. I didn't need, I didn't need someone else to do it. I didn't need to wait for that. Brian (37:31) Yeah. Scott Dunn (37:34) And I don't even look for creative art anymore. I simply say, give me this art. I do it in Creative Cloud. Give me that, and then you know, good enough's good enough. I move, because it's like you're touching on the delays on some of the things that can be the killer of that. I think in the same way back in the day, Sudhnyalanshi said that you're dating yourself. And I remember when I was younger, we just had electricity for the first, I'm just kidding. But think about the first time when you're telling people like, no, the computer could do that for you. Lance Dacy (37:35) I'll see you later. Scott Dunn (38:02) I feel like we're becoming a lot of companies now like, no, AI could do that for you because they just don't know. If they're working a certain way and they've been in that company for 20 years, they think, no, my job is to create the new insurance for them and then send that, no, you don't have to do all that. So I think it'll be a redistribution because for all of us to see here right now and say, I've let go of thinking there's limits to this and that's where I've come to last few weeks. And we're, and we're. Lance Dacy (38:23) Yeah. Scott Dunn (38:26) Well, I'm going to, I feel, I feel we're cutting edge. Your audience may say differently, Brian, but I feel like we're cutting. I feel like we're cutting edge. And if we're just coming to realization, there's not limits. Think about your traditional worker who's not necessarily a knowledge worker, they're just in the office. They have a certain role. It's been not too different over the last 10, 20 years. They have no idea. I probably could cut that. You mentioned Lance about the ads and I was seeing something recently that said that those AI ads can cut, can cut the design time by 90%. Brian (38:31) Yeah Lance Dacy (38:46) Yeah. I would totally agree. I mean, I tried it and you just like you were saying, waiting on delays to me is my biggest thing. Like the best thing we can do for an organization is a value stream mapping of some sort and say, where does the cycle times killing us? There's so much low hanging fruit there that you could turn that into millions of dollars. And if we were just quit articulating words for that, let's just go do it. I feel like that's what AI is gonna do for us. We were talking about the, Mike's Brian (38:55) now. Lance Dacy (39:22) written a book on user stories and all that. So I'm going to use that as an example, as a product backlog entry point to getting work done. And I think we were talking about this before the podcast. And I feel like eventually we're just going to have a user say, as a user, I need to be able to pay by MasterCard on this screen and make sure the error message says this. And if it is successful, do that. And we won't need programmers. The computer will take that. And it'll write the code for that. It'll deploy the code and it'll say, what do you think about that? And so when you talk about this with agile, but I don't know what we're gonna have these, we're just gonna have users that can now have software created for them. Just like I can an ad, you know, it's like, I'm gonna have this design created, but I speak to it in natural language. Who cares if it's C++, COBOL or JavaScript or Python or whatever, it doesn't matter anymore. The computer will decide. and write it, deploy it, and manage it, and take all the complexity out of it. That's eventually where I think we're headed. Brian (40:23) OK, I just want to state this out there for all the listeners. Make sure you at the right person on this. It's Lance Dacey who said that all the programmers are losing their jobs. All right, just make sure you get it right. That's who said it. Uh. Lance Dacy (40:36) Oh my gosh. Scott Dunn (40:40) Here's to seeing you all again. Lance Dacy (40:41) Did I really say all? I just said it's going to be a disruptor. I thought, but you know, I'm sorry. So just like I think you like your next designers, I think software programmers are just highly creative and great people. So I mean, no, uh, you know, no, just be on the lookout, find a way to contribute to the fact that your job. Scott Dunn (40:45) I heard everyone within the year. I think that's what I heard. Brian (41:03) Yeah. No, I mean, all teasing aside, I think that the developers who are using it now within their IDEs and locked into some of these tools that are available to have AI help them with code, they're ahead of the game. And people who are afraid of that stuff and saying, no, I'm not going to keep that at arm's length, we've seen this movie a million times. Right. Scott Dunn (41:03) Yeah. Yep. Yeah. Lance Dacy (41:19) Yeah. Yeah, played out over and over. It's like, you know what, Brian, two weeks ago, I don't know what the time is, I'm just being facetious right now, but a while ago, I would say that not true about programs because I say you will always need somebody programming the computer, but I've since now changed my mind thinking because I'm highly agile and I learned in that space and I drink my own champagne. That's not really true because I can go into chat, you know, I took, I'm a programmer myself, so I mean, no disdain about that, I remember in school, the first program I had to write was C++ about calculating the Easter Sunday date for a given year. And I had to write code to do that. And I tested that with my son over my shoulder, saying, I'm going to show you what ChatGPT can do. I said, write me a C++ program that calculates Easter Sunday for a given year. And I swear to you, in under a minute, all the code was there. Now, it didn't run. I had to take it and put it into an IDE and compile it and do all that stuff. But it worked. And it took me months to do that. So all I'm trying to say is it can help us be better. The creative side will always be there, but can you imagine not having to worry about code anymore? And you do more of prompting the computer instead of coding. That's really what I mean. I don't want to say their jobs are going away. I just think their jobs are going to be changed. They're going to be the next disruptor, just like I was talking about real estate agents and banking and all of us have been disrupted. But we gotta welcome it. Take it. Brian (42:37) Yeah. Scott Dunn (42:40) Yes. Brian (42:49) Yep. Yeah, right. Welcome to the party, pal. Yeah, no, I agree. Lance Dacy (42:57) Right! Scott Dunn (42:59) I feel like saying at this point, we should let all the listeners know that actually this podcast is AI generated and these are not actual people here. Lance Dacy (43:07) I'm not really sure. Brian (43:10) Yeah, this was done with the approval of these three people, but written by written by AI agents. No, no, it's absolutely not. These are real human beings. Well, guys, this has been a really interesting discussion. And I know we've gone a little bit long. But hey, it's the hundredth episode. Come on, cut us some slack, right? We got three of us here. We obviously are going to kind of diverge a little bit. So Lance Dacy (43:15) Good. Brian (43:35) Thank you guys so much for coming on and helping us to celebrate this 100th episode. I really appreciate it. So just want, you know, Scott, thank you. Scott Dunn (43:45) Thank you. Brian (43:46) And Lance, thank you as well. Lance Dacy (43:48) I'm about to say Lance, no thanks. Thank you, Greg and Brian. I always love being on here and Scott, great to see you. It's been too long. Scott Dunn (43:49) Yeah. Hahaha. Good job. Brian (43:52) Right. Scott Dunn (43:56) These two, yes, really enjoyed it. Brian (43:57) Awesome.

Join Brian as he and Arlen Bankston unveil the secrets of Liquid Agility in this episode of the Agile Mentors Podcast. Dive into how this innovative framework revolutionizes product management and fills the gaps in traditional Agile methodologies Overview In this episode Brian and Arlen Bankston delve into the intricacies of Liquid Agility, a comprehensive framework designed to enhance agile practices with its unique focus on prioritization, preparation, and outcome evaluation. Arlen walks us through the JUICE framework, which categorizes work into distinct streams—innovation, iteration, and operation—and discusses strategies for refining projects and maximizing the impact of released features. Whether you're a product owner, Scrum practitioner, or Agile enthusiast, this episode offers valuable insights into making agile methodologies more effective and adaptable to your needs. Tune in to transform your approach to product management and Agile practices with cutting-edge insights from Liquid Agility. Listen Now to Discover: [1:15] - Brian welcomes Scrum veteran, Certified Scrum Trainer®, partner at Grow-Lean LLC, author of HR and the Agile Organization, and creator of Liquid Agility. [2:53] - Explore the concept of Liquid Agility with Arlen as he reveals how it enriches traditional Agile practices, adding layers of depth and adaptability to methodologies [4:59] - Arlen discusses how Liquid Agility transforms prioritization, making it simpler to categorize tasks and put user needs first for more effective project management. [7:45] - Brian sheds light on the elegant simplicity and balance that Liquid Agility brings to the table, streamlining processes without sacrificing depth. [10:05] - Arlen delves into the nuances of his prioritization framework, giving a detailed walkthrough of the JUICE framework and its strategic benefits. [14:30] - Deepen your understanding and work hands-on to practice and understand the craft of being a great product owner by taking a Certified Scrum Product Owner® (CSPO) or Advanced Certified Scrum Product Owner® with Mountain Goat Software. Plus, you’ll be automatically enrolled in Mike Cohn’s Agile Mentors Community, including twelve months of ongoing coaching and support. Find a complete list of our upcoming classes on the Mountain Goat Software's Certified Scrum and Agile Training Schedule. [24:55] - Arlen outlines effective strategies for teams to evaluate and select the tools that best align with their specific needs and goals. [27:59] - Arlen explains the essentials of readiness within the dynamic Liquid Agility framework, highlighting what true preparedness looks like in an Agile context. [31:30] - Brian shares a big thank you to Arlen for joining him on the show. [33:39] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, such as CSM or CSPO. We also have Advanced Certified ScrumMaster® and Advanced Certified Scrum Product Owner®, where we get right into the good stuff and have some deep discussions. We'd love to see you in one of Mountain Goat Software's classes. You can find the schedule here. [34:12] - If you liked the episode, share with any product owner you think might benefit from the discussion today, too! [34:30] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback or a great idea for an episode of the show? Great! Send us an email. [34:46] - Catch Brian live and in person, and hear him speak at the upcoming 2024 Global Scrum Gathering in New Orleans and the Agile 2024 Conference in Dallas. References and resources mentioned in the show: Arlen Bankston Grow-Lean, LLC HR and the Agile Organization by Arlen Bankston Liquid Agility #3: What Makes a Great Product Owner? With Lance Dacy #14: What does it mean to be Product-Centric? With Scott Dunn #50: Exploring the Roles of Scrum Master and Product Owner with Lance Dacy Certified Scrum Product Owner® Advanced Certified Scrum Product Owner® Mountain Goat Software Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast 2024 Global Scrum Gathering Agile2024 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. Arlen Bankston is one of the very first Certified Scrum Trainers®, a Scrum veteran, partner at Grow-Lean LLC, author of HR and the Agile Organization, and creator of Liquid Agility. Known for his thought leadership and dynamic, entertaining, and practical training style, Arlen has trained and mentored thousands of ScrumMasters, Product Owners, team members and executives.

Join Brian as he explores the Change Initiative Canvas with Dr. Steve Martin, a groundbreaking tool designed to streamline and succeed in organizational change efforts. Learn how to tackle change with clarity and strategic foresight. Overview In this insightful episode, Brian Milner and Dr. Steve Martin dive deep into the mechanics of the Change Initiative Canvas, a strategic framework developed to guide organizations through successful transformations. They discuss critical aspects such as setting clear objectives, measuring impact, handling objections, and the importance of cultural alignment within the organization. Whether you're initiating small adjustments or major shifts, this discussion provides the essential tools and tactics to navigate change effectively and achieve meaningful, sustainable results. Listen Now to Discover: [1:10] - Brian welcomes Dr. Steve Martin, PhD, Certified Scrum Trainer®, CEO of Agility Guides, and professor at Franklin University and creator of the Change Initiative Canvas. [2:38] - Steve unveils the intriguing origins of the Change Initiative Canvas, sharing the inspiration and journey behind its creation. [4:38] - Steve breaks down the concept of failure, offering insightful strategies on how to interpret and learn from setbacks. [7:00] - Steve delves into the essentials of recognizing when change is necessary by questioning the underlying reasons and observing the problem's impact. [11:29] - Brian emphasizes how understanding the customer's immediate need for change is vital for navigating towards the right solutions. [14:34] - Steve explains the delicate balance between thoroughly understanding a problem and avoiding the trap of analysis paralysis. [15:24] - Explore your Agile potential with the custom Elements of Agile assessment, crafted by Mike and Brian to help you gauge your team’s current agility and identify opportunities for growth. [17:17] - Steve emphasizes the significance of clearly outlining what success entails to align efforts and expectations across the board. [20:29] - Explore effective strategies for navigating resistance and overcoming constraints during a change initiative, ensuring smoother transitions and successful outcomes. [26:48] - Steve highlights the critical need to understand an organization's culture and outlines methods for accurately assessing it to ensure alignment with strategic initiatives. [30:46] - Steve encourages listeners to connect with him on LinkedIn and explore the practical tools and resources available on the Agility Guides Resources page, designed to enhance real-world Agile practices. [31:56] - Brian expresses his heartfelt gratitude to Steve for sharing his insights on the show, enriching the conversation with his expertise. [32:34] - Continue the conversation and deepen your Agile knowledge by joining the Agile Mentors Community. Enjoy a complimentary year-long membership by enrolling in any Mountain Goat Software, such as the Certified ScrumMaster (CSM) or Certified Scrum Product Owner (CSPO). [33:24] - Subscribe to the Agile Mentors Podcast and spread the word to anyone who might appreciate our discussions. Have feedback or an idea for a future episode? We'd love to hear from you—drop us an email! References and resources mentioned in the show: Steve Martin Agility Guides Change Initiative Canvas Agility Guides Resources Elements of Agile Subscribe to the Agile Mentors Podcast 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 Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Dr. Steve Martin is driven by a passion to help leaders excel, by leveraging extensive experience in orchestrating large-scale transformations and academic insights to empower leaders at all levels to navigate today’s volatile business landscape. From failed beginnings to leading successful agile transformations and teaching leadership principles, he guides executives and managers to lead with authenticity, humility, and a coaching mindset, ensuring both organizational success and personal fulfillment.

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

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

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

Join Brian Milner and Anton Skornyakov as they tackle the often overlooked art of slicing work on this episode of the Agile Mentors Podcast. Discover how this pivotal strategy can revolutionize feedback loops and drive impactful results across industries. Overview Join us on a riveting journey with Agile expert Anton Skornyakov to unearth the transformative power of slicing work in Agile environments. In a world where most projects miss the mark on effective breakdown, Anton sheds light on the critical need for well-sliced work to secure valuable customer feedback and accelerate delivery of results. From the nuanced art of vertical slicing to innovative strategies for tackling complex story breakdowns, this episode is packed with insights and practical examples that span beyond the confines of software development. Whether you're grappling with how to split your next project into manageable increments or seeking to refine your Agile practice, Anton's expert advice and favorite splitting techniques offer a roadmap to success. Listen Now to Discover: [01:20] - Brian introduces an Agile Mentors Podcast listener-requested guest, Anton Skornyakov, Certified Scrum Trainer® and author of The Art of Slicing Work. [02:20] - Hear Anton recount the real-world struggles of translating the fundamental principle of defining effective increments into actionable insights for teams beyond software development. [04:39] - Anton delves into the art of work slicing by expertly applying the rules for splitting user stories, revealing insights for seamless practice. [06:41] - Anton brings vertical slicing to life with a relatable dinner party analogy, illustrating its transformative impact on teamwork. [11:12] - Anton uncovers the magic of vertical slicing, revealing its pivotal role in enhancing team responsibility—an esteemed Agile virtue. [13:01] - Facing challenges in cultivating a unified understanding of Agile principles across your team? Let Mountain Goat Software elevate your team's agility—from non-software teams to the executive suite. [13:58] - Brian expands the conversation to explore the far-reaching implications of vertical slicing on project management and team dynamics. [16:36] - Confronting a familiar hurdle, Anton dissects the notion that the complexity of work stands in the way of effective slicing. [17:57] - Anton explores strategies for navigating resistance when team members push back against the practice of slicing work. [19:20] - Anton reveals his insights into teams' struggles with splitting tasks they deem too large and how to overcome this perception. [24:43] - Anton shares his favorite ways of breaking down work. [28:47] - Brian expresses heartfelt gratitude to Anton for his invaluable insights on today's show and extends a warm thank you to the listeners for their brilliant guest recommendations. If you have a guest or topic suggestion for an upcoming episode, send us an email at podcast@mountaingoatsoftware.com [39:56] - We invite you to subscribe to the Agile Mentors Podcast. Please like, subscribe, and share with your friends. [30:30] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, such as CSM or CSPO. We also have Advanced Certified ScrumMaster® and Advanced Certified Scrum Product Owner®, where we get right into the good stuff and have some deep discussions. 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: The Art of Slicing Work by Anton Skornyakov Agile.Coach Introduction to Agile Working on a Scrum Team Agile for Leaders Mountain Goat Software’s Courses Subscribe to the Agile Mentors Podcast Certified ScrumMaster® Training and Scrum Certification Certified Scrum Product Owner® Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Anton Skornyakov is a Certified Scrum Trainer® and author of The Art of Slicing Work. He is passionate about educating and supporting organizations, reliably delivering results on unpredictable projects.

Would there be any value if everyone in an organization and team were all bringing out the best in each other while working for a common goal? Join the Master at assisting people and organizations in getting things done. Angela Johnson. In other words, she gets people from where they are now to where they want to be. Angela is a Certified Scrum Trainer, Agile Guide, and founder of Collaborative Leadership Team. In this episode we are going to find out what SCRUM is, why it matters, and how it can influence your personal as well as professional lives.

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

Ever wondered how visuals can transform your role as a product owner? Join Brian as he sits down with visual storyteller Stuart Young to unravel the power of visualization in product ownership. Join them on a journey to discover the art and science behind being a successful product owner. Overview Ever wondered how to elevate your product ownership game? In this episode, we delve into the world of visual storytelling with Stuart Young. Join Brian and Stuart as they discuss the diverse tools, such as story mapping and the product disposition canvas, that can bring your product visions to life. From storytelling techniques to the neurodiversity lens, we explore the art and science of communication that transcends traditional boundaries. Listen in to uncover the impactful ways visuals can shape your product strategy. Learn how being more visual can sharpen your skills, foster collaboration, and create a more inclusive and successful product development journey. Listen Now to Discover: [00:23] - Today welcomes Stuart Young, a Certified Scrum Trainer and visual storyteller to discuss storytelling through the product lens and more. [03:32] - Stuart discusses drawing large-scale pictures at conferences and recommends Visual Meetings and Visual Leaders by David Sibbit. [06:54] - Stuart emphasizes the impact of visual storytelling on individuals, highlighting the universal language and information retention through visuals. [08:46] - The benefits of visual representation in capturing the flow of ideas and aiding memory. [10:26] - The importance of varied methods for engaging different learning styles. [11:41] - Stuart discusses the value of visualization tools such as roadmaps, post-it notes, and story mapping to provide clarity and a clear narrative. [12:14] - The importance of blending Stuart references Pixar and Ed Catmull's book Creativity, Inc., discussing the importance of blending exciting elements, like storyboarding, in motivating teams and creating a compelling narrative. [15:13] - Stuart emphasizes the importance of authentic storytelling, even if it doesn't always have a happy ending, he references TEDxHogeschoolUtrecht - Steve Denning - “Leadership Storytelling" for further inspiration. [15:25] - Brian recommends Simon Sinek's TED talk on "Start With Why" as an example of effective storytelling despite not being visually polished. [16:09] - Stuart praises Henrik Kniberg's impactful video on product ownership, acknowledging the simplicity of the drawings but highlighting the potency of storytelling. He recommends the Sketchnote Handbook by Mike Rhodes for those interested in delving further into storytelling. [17:08] - The Agile Mentors Podcast is brought to you by Mountain Goat Software and their Certified Scrum Training Classes. For more information, click on the Mountain Goat Software Certified Scrum and Agile Training Schedule. [18:38] - Stuart highlights the significance of visual elements in crafting compelling visions and underscores the value of utilizing available templates, from sources like the Gamestorming book. [20:06] - Stuart discusses the role of visualization in making the intangible tangible, particularly in the tech space. [21:50] - Brian emphasizes the imprecision of words. He also discusses the value of showing rather than just telling, especially in product requirements, to enhance understanding and avoid delays caused by miscommunications. [23:34] - Stuart reflects on how visual communication can enhance inclusivity. He shares, “For people with reading and writing difficulties, pictures and symbols are better. The worst, the most abstract form, of course, is the word.” [25:22] - The role of a visual storyteller as a "human cursor" connecting diverse conceptual thinkers. Stuart recounts an illustration experience, emphasizing the challenge of visualizing details without clear specifications and underscoring the mantra of "process over art" in product ownership. [28:06] - Stuart underscores the product owner's role in leveraging the unique skills of team members to converge on a shared understanding of what "good" looks like. [29:19] - Brian references the episode of the show they did on Navigating Neurodiversity and the importance of understanding and accommodating different communication styles within a team. He highlights the need for product owners to be aware of the preferences of their team members and adjust communication methods accordingly. [30:54] - Stuart introduces the product disposition canvas and shares a personal revelation. [32:54] - Brian acknowledges the potential superpowers that come with neurodiversity, sharing his own experience of a late-in-life ADHD diagnosis and the benefits of leveraging the unique qualities each team member brings to a team. [33:36] - Stuart reflects on the importance of recognizing individual strengths and blind spots, emphasizing that everyone has a valuable contribution. [34:20] - Stuart encourages recognizing individual strengths for collective success. [35:23] - Listeners can connect with Stuart on LinkedIn and at Agile Nuggets | Agile Tips [37:38] - Please share this episode with others if you found it useful. Send feedback and suggestions for future episodes to podcast@mountaingoatsoftware.com. And don’t forget to subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode. [38:21] - If this topic was impactful to you and you want to continue the discussion, join the Agile Mentors Community where we have a topic discussion for each podcast episode. You can get a free year-long membership in the community just by taking any class with Mountain Goat Software. References and resources mentioned in the show: Stuart Young on LinkedIn Agile Nuggets | Agile Tips | Cprime Learning Scrum in Under 10 Minutes #76: Navigating Neurodiversity for High-Performing Teams with Susan Fitzell David Sibbet Visual Meetings by David Sibbet Visual Leaders by David Sibbet Creativity, Inc. Sketchnote Handbook by Mike Rohde TEDxHogeschoolUtrecht - Steve Denning - “Leadership Storytelling" Simon Sinek: How Great Leaders Inspire Action | TED Talk Agile Product Ownership in a Nutshell by Henrik Kniberg Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers Subscribe to the Agile Mentors Podcast on Apple Podcasts Certified ScrumMaster Training and Scrum Certification Certified Scrum Product Owner Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Stuart Young, a Certified Scrum Trainer and Visual Storyteller, merges Agile methodologies and design thinking to empower individuals and teams. As a thought leader, he champions Visual Storytelling for engaging stakeholders, addressing customer needs, and expediting learning. Through workshops, Stuart encourages teams to embrace visual methodologies to achieve business success.

Join Brian and his guest Lance Dacy as they dive into the trends and challenges awaiting the Agile community in 2024 and the importance of adapting Agile principles to the hyper-competitive world of product development. Overview In this episode of the Agile Mentors Podcast, Brian sits down with Lance Dacy to take a deep dive into the anticipated trends and challenges awaiting the Agile community in 2024. The duo explores the ongoing debate between remote and in-person work, the imperative need for innovation in leadership and management, and the intricacies of forward-thinking strategies as we work toward building organizations tailored for the future. Join Brian and Lance as they navigate the complex intersection of Agile principles, organizational leadership, and the ever-evolving landscape of the business world in 2024. Listen Now to Discover: [01:17] - Brian Milner has Lance Dacy on the show today for the traditional discussion of looking ahead at trends and upcoming developments in the Agile and Scrum space for 2024. [02:10] - Remote vs. in-person work—opening the discussion with this hot-button topic and the evolving debate. [03:31] - Lance offers his insights on organizations' adaptive strategies, what we learned during the pandemic, and the potential benefits and drawbacks of remote work. [05:58] - The loss of collaboration and learning when in a remote environment. [07:22] - The hybrid work solution. [07:36] - Brian shares a study favoring in-office productivity. [09:50] - Lance shares his personal work-at-home challenges and the importance of aligning work environments with individual personalities and preferences. [11:32] - The importance of accommodating individual preferences and working styles, and the need for organizations to match their environments to employees rather than requiring employees to adapt. [12:58] - The challenges faced by managers and leaders in making decisions about remote work, and the importance of flexibility in work hours. [15:20] - Brian raises concern about layoffs in the Agile area during tough economic times, questioning if it's the right strategy for long-term success. [16:23] - Lance emphasizes the need for understanding Agile rather than blindly applying it, suggesting the Agile industry may be bloated and encouraging a focus on culture and effective coaching. [17:23] - Mountain Goat Software, is the sponsor for this podcast. Whether you’re looking to get Certified ScrumMaster (CSM) or Certified Scrum Product Owner (CSPO) training or want to take an Advanced Certified ScrumMaster (ACSM) class, click here to see what we have to offer. [19:33] - Leadership and management innovation—Brian and Lance discuss the need for organizations to prioritize human-centric management AND leadership innovation, citing Gary Hamel's concept of building organizations fit for the future. [23:25] - Lance discusses the devaluation of the human element in organizations. [24:31] - Brian and Lance share their insight into the devaluation of developers, and the need for discussion on the trajectory of Agile in the face of such challenges. [25:55] - Lance highlights the need to educate leaders and managers on the criticality of Agile budgeting alongside project management to align expectations. [27:40] - Lance addresses the challenge in achieving true Agility, and why coaches offer such a long-term ROI. [28:10] - The importance of educating leaders on the value of coaching, psychological safety, and the need for a neutral perspective in fostering organizational improvement. [29:15] - Brian predicts a continued emphasis on cost-cutting in 2024 due to economic uncertainty. [29:57] - Brian expresses his concern about the long-term negative impact of eliminating coaching roles. [31:34] - Lance anticipates a cultural shift that might make it difficult for companies to attract talent if they don’t embrace more human-focused values that empower individuals. [32:59] - Lance urges Agile coaches to adapt to a changing paradigm and discusses the challenge for leaders and managers to shed bureaucratic structures and implement an effective strategy for embracing these principles. [34:17] - Brian urges a reevaluation of Agile's focus, emphasizing transparency and adaptability over rigid structures and roles. [34:48] - Brian stresses Agile's strength in handling unexpected challenges and calls on Agilists to emphasize the fundamental principles to demonstrate Agile's value effectively. [35:40] - The need for new thought leaders in leadership, management, and organizational design to guide Agile practitioners in effectively leveraging data and scaling Agile practices. [36:30] - The importance of evolving beyond rigid practices to embrace Agile's adaptability. Lance uses the analogy of professional sports to illustrate the importance of adaptability, discipline, and rigor in responding to dynamic situations. [38:03] - Not doom and gloom but a chance for growth and adaptation—Brian expresses optimism and excitement for the upcoming year, seeing it as an opportunity for renewed focus and bringing value to organizations in the evolving world of product development. [40:20] - Brian extends his thanks to Lance Dacy for being on the show. And don’t forget to share your thoughts and ideas on upcoming trends in the Agile Mentors Community. [41:09] - Please send feedback and ideas for upcoming shows to podcast@mountaingoatsoftware.com. And don’t forget to share and subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode. [41:14] - Happy New Year to everyone, Brian expresses excitement for the journey ahead in 2024, meeting more listeners at in-person events, and sharing more insights on future episodes of the Agile Mentors Podcast. References and resources mentioned in the show: #63: The Interplay Between Data Science and Agile with Lance Dacy #30: How to Get the Best Out of the New Year with Lance Dacy #76: Navigating Neurodiversity for High-Performing Teams with Susan Fitzell Humanocracy Certified ScrumMaster Training and Scrum Certification Certified Scrum Product Owner Training Advanced Certified ScrumMaster® Advanced Certified Scrum Product Owner® #4: The Developer Role in Scrum with Sherman Gomberg DFW Scrum (Dallas, TX) | Meetup 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. Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

In this episode, Brian Milner and Lucy O'Keefe share their journeys to becoming Certified Scrum Trainers® (CSTs). Join them as they discuss the challenges, unexpected moments, and valuable lessons learned along the way, offering insights for those considering the CST path. Overview Explore the transformative journey to becoming a Certified Scrum Trainer® (CST) with Brian Milner and Lucy O'Keefe. From the submission process to mentorship, co-training, and the rigorous Trainer Approval Committee (TAC) interviews, they unravel the intricacies of achieving CST status. Listen in for valuable tips, reflections, and inspiration for navigating the rewarding but challenging road to becoming an elite Agile trainer. Listen Now to Discover: [01:26] - Brian introduces his guest, Lucy O'Keefe, who recently achieved her Certified Scrum Trainer® (CST). [02:53] - Today’s discussion will explore the experience of becoming a Certified Scrum Trainer® with Brian and Lucy sharing their personal experiences and insights into the process of becoming a CST. [03:44] - Lucy shares what fueled her passion for becoming a CST and how her mentor—Anu Smalley—inspired her. [05:00] - Brian discusses his decision-making process for becoming a CST and why it's important to make a decision that aligns with your instincts and career goals. [06:07] - Brian and Lucy each share their journey to becoming a CST and the steps required before being eligible to pursue the trainer certification. [08:24] - Insight into the two phases of the submission process for becoming a Certified Scrum Trainer®: the materials phase and the Trainer Approval Committee (TAC) phase and the challenges along the way. [09:38] - Brian reflects on the significance of mentorship in the journey to becoming a CST and David Hawks's crucial role in opening doors and making connections with other trainers. [09:48] - Lucy acknowledges Anu's pivotal role and emphasizes the importance of these relationships, (especially considering the challenges posed by the pandemic. [12:00] - Lucy and Brian discuss the relationship-building phase involved in co-training and mentorship. [13:22] - Lucy explains the (time-intensive) nature of co-training. [14:26] - Brian shares his approach to initiating co-trainings. [15:11] - The importance of feedback and obtaining recommendation letters—a crucial element in the submission process. [16:28] - Brian and Lucy discuss the impact of mentorship on their journey, expressing gratitude for the individuals who opened doors and provided mentorship. Brian mentions David Hawks, Kert Peterson, and Lance Dacy, emphasizing the diverse perspectives and valuable insights gained from them. [17:20] - Lucy shares about the recent special episode of her podcast where she featured her mentors. [17:55] - The value of in-person training (and some of the expenses involved). [20:09] - The challenges of training in a virtual environment. [22:18] - The limitations of virtual classes and the added value of personal interactions and shared experiences during breaks. [23:38] -The Agile Mentors Podcast is brought to you by Mountain Goat Software and their Advanced Certified Scrum Product Owner® class. This is the only ACSPO that uses our interactive software so that breakout exercises are valuable and FUN! Plus, you will automatically receive 12 free months in the Agile Mentors Community. For more information, click on the Mountain Goat Software Certified Scrum and Agile Training Schedule. [25:17] - The lengthy process of submitting materials for Certified Scrum Trainer® approval. Brian shares his personal experience. [25:35] - Lucy explains the current two-phase process for CST approval and her experience (highlighting the changes since Brian's initial submission). [26:33] - The rigorous examination process and the scrutiny applied to every aspect of the application during the fine-tooth comb review during the TAC phase of becoming a CST. [27:00] - Lucy describes the final stages of the approval process. [27:19] - Brian reflects on the changes in the CST qualification process and emphasizes the importance of following the TAC's feedback for those who reach this stage. (Advice from Chris Li) [28:49] - Resilience and persistence in the face of potential setbacks during the CST approval process. [30:42] - An in-depth explanation of the challenging TAC (Trainer Approval Community) interview process for becoming a Certified Scrum Trainer®. [32:23] - Brian shares his personal preparation strategies and reflects on the unpredictability of TAC interviews, recounting an unexpected request during his own experience. [33:32] - Lucy shares her preparation methods and also stresses the unpredictability of TAC interviews and the importance of adaptability during the process. [34:29] - Be prepared to think on your feet. Brian shares the emergency situation he faced and a mistake during his live presentation. Plus the surprising comments he received from the committee. [37:27] - Lucy shares her unexpected experience after the committee's vote. And a valuable piece of advice for listeners. [38:33] - Embarking on the CST journey involves challenges and moments of doubt, but perseverance is crucial, as success may require multiple attempts—not everyone passes on the first try. [39:43] - Becoming a CST is a subjective process and often involves multiple attempts—it doesn’t diminish your capabilities as a trainer. Brian shares the crucial aspects of the journey. [40:13] - Lucy shares why it's important not to take rejection personally, instead viewing it as a chance to identify areas for growth and become a better trainer in the end. [41:23] - Brian emphasizes the importance of viewing the CST process as a journey—being prepared for potential setbacks, highlighting the mindset of growth and continuous learning. [42:30] - Lucy adds that the rigorous Certified Scrum Trainer® requirements aim to ensure that CSTs are among the elite trainers, making the achievement more meaningful. [43:38] - The importance of embracing each chance to enhance oneself as an Agilist and a trainer. [44:09] - Brian's words of wisdom: "Hard things that are hard to do, that just makes it all the better when you achieve them.” [44:45] - Lucy’s advice: “It's not just becoming a CST. It's what you learn on your journey that really matters." [45:25] - Congratulations to Lucy for getting her CST! Brian extends his thanks to her for being on the show. For listeners interested in continuing the discussion, you can join the conversation in the Agile Mentors Community, where they also have monthly Q&A calls. [46:58] - If you found this episode useful, please share it. Send feedback and suggestions for future episodes to podcast@mountaingoodsoftware.com. And don’t forget to subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode. References and resources mentioned in the show: #53: Agile Coaching: Debunking Myths and Unlocking Excellence with Lucy O'Keefe #44: Transformations Take People with Anu Smalley #17: Getting There From Here: Agile Transformations with David Hawks #12: Kanban with Kert Peterson #54: Unlocking Agile's Power in the World of Data Science with Lance Dacy #40: Is it Time to Go Out on Your Own? Tips and Insights with Chris Li Subscribe to the Agile Mentors Podcast on Apple Podcasts Certified Scrum Master Training and Scrum Certification Certified Scrum Product Owner Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Lucy O'Keefe has over 28 years of IT experience and has worn multiple hats in the Agile world - developer, Product Owner, Scrum Master, and now, Certified Scrum Trainer® (CST) where she uses her experience to ensure each student has a great training experience.

In the episode 165 of IDEAS+LEADERS podcast I am speaking with Angela Johnson about servant leadership and lessons from scrum masters. Angela is a Certified Scrum Trainer, Agile Guide and founder of Collaborative Leadership Team. In 2010 she founded the company to provide education and consulting services to clients adopting Scrum and Agile.  You can contact Angela here: https://www.linkedin.com/in/angelajohnsonscrumtrainer/ Thank you for joining me on this episode of IDEAS+LEADERS. If you enjoyed this episode, please share, subscribe and review so that more people can enjoy the podcast on Apple https://apple.co/3fKv9IH or Spotify https://sptfy.com/Nrtq. __________ I'd love to connect with you! You can find me, Elena Paweta, the host of IDEAS+LEADERS podcast on: Instagram: ⁠https://www.instagram.com/elena.paweta/⁠ LinkedIn: ⁠https://www.linkedin.com/in/elena-paweta/

Jose Angel Pereira Ruimwyk: Overcoming Adversity and Remaining Unbroken - Join Jose Angel Pereira, former CEO of Citgo Petroleum and a member of the CITGO6, on the "Building Great Sales Teams" podcast as he shares his extraordinary journey of resilience and advocacy. After being wrongfully detained in Venezuela for nearly five years, Jose has dedicated his efforts to advocate for other Americans who are wrongfully detained abroad and to change US policy on hostages. Discover his inspiring story and unique insights on resilience, international experiences, and making positive changes in the world.Angela Johnson: Lessons From The Scrum Master - In this episode of Building Great Sales Teams we are joined by Angela Johnson, CEO, Certified Scrum Trainer, and Author of "The Scrum Master Files. Angela shares her entrepreneurial journey and insights into professional education for adult learners. Celebrating her small business's 13th anniversary, Angela highlights the challenges she overcame, including navigating the COVID-19 pandemic while successfully opening a bricks-and-mortar training and event center. Enjoy!

Join Brian and his guest Lance Dacy as they address the interplay (and the skepticism) of combining Agile and data science. Tune in as they explore the art of crafting Minimum Viable Products (MVPs) to create impactful and efficient solutions. Overview In this episode of the Agile Mentors Podcast, Brian sits down with Lance Dacy to delve into the nuances of aligning data science with the software development mold while dispelling the myths along the way. Listen in as Lance shares his wealth of experience and insights guiding listeners through the step-by-step process of building MVPs in data science projects and sharing how Agile principles seamlessly apply to both worlds. Listen Now to Discover: [01:13] - Brian introduces Lance Dacy on the Agile Mentors Podcast. Since listeners appreciated the previous data science and agile episode, Lance is here for Part Two, this time discussing how data science fits into the software development mold. [02:00] - Addressing the skepticism of combining agile and data science; Lance has both expertise and practical experience. [02:43] - Lance emphasizes that he understands the “naysayers” concerns but aims to help others comprehend the synergy. [03:05] - Waterfall might be better: sorting out the different perspectives on Agile development and data science. [04:45] - The importance of scoping and architecture in software development projects. [05:15] - Challenging the notion of perfectly defined objectives. [05:46] - Most software projects lack a completely predefined understanding. [06:39] - How Agile's empirical process and mindset of experimentation align with data science. [07:30] - Presenting a real-world MVP example combining business drivers and data science techniques. [08:04] - Clarifying what Agile is—a philosophy based on values, not a step-by-step process. [09:03] - The importance of sustainable pace and productivity in Agile. [10:10] - Introducing the concept of MVP and acknowledging the evolution of data science techniques. [11:00] - Discussing MVP in the context of data science, and aligning it with empirical approach. [11:38] - Highlighting the role of MVP in testing assumptions, mitigating risks, and user feedback. [12:00] - Exploring data science's practical relevance for consumers to forge a relatable discussion. [12:47] -Acknowledging familiarity with technology, uncertain about tactics. [13:00] - Highlighting how AI and data science are pervasive in everyday technology use. [13:29] - Examples of AI data science integration: search engines, online shopping recommendations, social media content, smart homes, and more. [14:42] - Introducing common uses of data science: customer segmentation and marketing techniques. [15:19] - Applying clustering techniques like K means for automated segmentation. [15:34] - Lance shares his paper on supply chain optimization, using an ant colony algorithm. [15:56] - The techniques and purpose of supply chain optimization. [16:23] - Exploring data science applications: collaborative filtering, matrix factorization, neural networks. [16:42] - Clarifying data scientists' approach: not a random process but based on problem-solving with models. [17:18] - Iterative development as a primary reason for MVP in data science. [17:57] - Using real-world performance data for model improvement. [18:21] - Risk mitigation as a critical aspect of MVP: linking risk mitigation to surviving challenges and learning from them. [19:51] - Starting with an MVP reduces risk by avoiding overly complex models without sufficient feedback. [20:19] - Setting stakeholder expectations with an MVP: providing tangible insight into data science trade-offs and early deliverables. [20:39] - Highlighting operational considerations of deploying and maintaining data models, addressing challenges in data pipelines, infrastructure, and monitoring. [22:17] - An MVP approach aligns with Agile principles for data science. [22:35] - Brian clarifies the misconception that MVP means sacrificing quality for speed. [23:30] - Lance agrees, addressing the misconception, and emphasizes MVP's importance in learning and improvement. [23:32] - Have you thought about training with Mountain Goat Software? With classes such as Mountain Goat Software, Certified Scrum Product Owner (CSPO) developed by Mike Cohn, and team home software for better interactivity during classes you can’t go wrong. [24:00] - Brian suggests transitioning to walking through a model or example of creating an MVP. [24:07] -A tangible framework for mapping data science work to MVP steps, acknowledging the contextual nature of the process. [24:50] - Lance acknowledges the complexity of the steps, so they’ve been posted below under resources. [25:11] - The importance of problem definition and defining the scope of the MVP. [26:34] - The challenge of gathering and preprocessing data. [27:20] - Selecting a simple model that is easy to interpret and implement for faster training times, easier troubleshooting, and adherence to the principle of parsimony. [29:12] - Using feature engineering to select the most relevant features for the model. [29:33] - Choosing a manageable number of features for the model, rather than attempting to incorporate all available data and avoid overcomplicating or overfitting the model. [30:11] - Lance emphasizes the importance of selecting a simple model and conducting feature engineering based on the insights gained from that model. [30:36] - Training the chosen machine learning model using pre-processed data, typically by splitting the data into training and validation sets. [31:15] - The challenge of evaluating the model's performance and the importance of using the appropriate metrics. [31:34] - The goal: create a model that is good enough for gathering feedback that aligns with the concept of MVP. [31:53] - Lance describes the last step of building an MVP: deploying the MVP by integrating the model into a suitable platform or application. [32:26] - The importance of making the MVP accessible to end users. [33:00] - The crucial feedback loop for making improvements to the model and features, and refining, scaling, or reconsidering the approach. [34:09] - Why you might want to initially deploy a slightly higher-level model. [34:57] - The parallel between the steps of creating an MVP in data science and the principles of Agile. [35:18] - Brian adds that in data science, feedback not only comes from customers and users but also involves analyzing results and outcomes as a form of feedback to refine the model. [35:53] - The importance of relying on scientific expertise to analyze the results of the model and evaluate its accuracy and validity. [36:10] - In data science, the feedback loop also involves analyzing the outcomes and results, similar to the iterative process of receiving user feedback in software development. [37:00] - Lance draws parallels between software development and data science by comparing the process of building software features with the steps involved in creating an MVP for data science. [39:21] - Lance offers some practical examples, beginning with a recommendation system. [41:06] - The decision tree approach and its benefits for stakeholders. [43:00] - Lance talks about churn prediction to gradually incorporate more nuanced data. [43:55] - MVPs for chatbots and the benefits of starting with simple scripted responses in a chatbot MVP. [45:59] - Managing multiple projects. [46:24] - The effectiveness of using logistic regression and decision trees for MVPs. [47:00] - Lance emphasizes the importance of managing stakeholders' expectations. [47:53] - Lance discusses the need to consider the context when interpreting model performance metrics and involving stakeholders in these discussions. [49:16] - The importance of collaboration between data scientists and stakeholders for delivering valuable solutions. [50:11] - Lance draws a comparison between data science and software development in terms of the challenge of coordinating work across different specialized areas. [51:00] - Lance highlights the importance of feedback and iterative adjustments for success. [53:24] - Again, you can find Episode #54: Unlocking Agile's Power in the World of Data Science with Lance Dacy, here. [53:48] - We’d love to hear your thoughts on this topic and your suggestions for future topics. Just email podcast@mountaingoatsoftware.com. 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. [55:00] - Don’t forget to check out the Mountain Goat Software Certified Scrum and Agile Training Schedule, including, Certified Scrum Master (CSM) or a Certified Scrum Product Owner (CSPO) and Advanced Certified Scrum Master (ACSM) and Advanced Certified Scrum Product Owner (ACSPO) classes. I'd really love to see you in class! References and resources mentioned in the show: 6 Reasons Why I Think Agile Data Science Does Not Work | by Ilro Lee Why Data Science Doesn't Respond Well to Agile Methodologies Lance’s SMU Paper (Ant Colony Algorithm and Traveling Salesman Problem) #54: Unlocking Agile's Power in the World of Data Science with Lance Dacy 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 Reasons for Quick MVP in Data Science are to support: Iterative Development Feedback Loop Risk Mitigation Setting Expectations Operational Considerations Steps of the MVP: Problem Definition Gather and Preprocess the Data Select a simple model Feature engineering Train the model Evaluate the model Deploy the MVP Collect Feedback Iterate Decision Time Examples of MVP in Data Science (Logistic regression and decision trees are often used as initial models due to their simplicity, interpretability, and relatively quick development time.) Recommendation Systems: Instead of building a complex recommendation engine, a company might start with a simple rule-based system (e.g., recommending the most popular items) to gauge user interest and system engagement. Churn Prediction: An MVP might involve creating a basic model based on a few key features (like usage frequency and customer complaints) to predict which customers might churn. Later versions can incorporate more nuanced data and sophisticated algorithms. Natural Language Processing (NLP): For a chatbot, the MVP might involve scripted responses or basic keyword matching. Once deployed, user interactions can inform the development of more advanced NLP capabilities Conclusion With Rapid MVP, context is crucial with regard to our general benchmarks (F1-Score, ROC-AUC, MAE, RMSE). You should strive to always consider the context of those benchmarks with the problem being solved. In some medical diagnostic tests, even an F1-score of 0.95 might not be good enough due to the severe consequences of false negatives or false positives. We also likely need to compare the model's performance metrics with a simple baseline (e.g., random classifier, mean prediction) to determine how much value the model is adding. Always align the model's performance with business objectives. Even a model with a high ROC-AUC might not be suitable if it doesn't meet the specific precision or recall targets set by the business. Isn’t it better to find ways to know that earlier than later? Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

An opportunity to connect with John Miller of the Agile Classroom, a next-generation learning framework, with a student-centered approach, emphasizing collaboration, communication, self-organization, and social skills . We look at the Agile classrooms approach focusing on real-world approaches that the most innovative companies in the world use brought to a classroom setting. What the structures, workflows and pedagogic strategies for educators to consider when working with this framework.  About John Miller I had worked for years as an Education Technology Director for a school district, which as a whole, wanted to move towards integrating 21st century skills within the curriculum. But what we found was that we could not change the way students learn, without first changing and modeling these 21st-century skills in the staff and teaching methods themselves. Using Agile, I spearheaded an innovative and engaging way to organize workflows with self-managed teams and quick feedback, creating a healthy and productive workplace culture that allowed for growth and prosperity. John is a Certified Scrum Trainer, Certified Enterprise Coach®, Certified Professional Co-Active Coach, ICF Associate Certified Coach, Spiral Dynamics Integral Level 2, and a Project Management Professional. When not focused on work, John loves to surf (well, wiping out more than actually surfing), spend time with his family and 2 daughters, volunteer as a life coach for students, and make insanely delicious drinking chocolates.   John Miller on Social Media Twitter: @agileschools   Website: https://agileclassrooms.com/    John Mikton on Social Media LinkedIn: https://www.linkedin.com/in/jmikton/ Twitter: https://twitter.com/jmikton Web: beyonddigital.org   Dan Taylor on social media: LinkedIn: https://www.linkedin.com/in/dantcz/ Twitter: https://twitter.com/DanTaylorAE Web: www.appsevents.com   Listen on: iTunes / Podbean / Stitcher / Spotify / YouTube Would you like to have a free 1 month trial of the new Google Workspace Plus (formerly G Suite Enterprise for Education)? Just fill out this form and we'll get you set up bit.ly/GSEFE-Trial

On today's episode, we discuss how organizations need to adapt or die.Angela Johnson is a “professional people geek” with over 25+ years of experience working with teams and leaders in both project management and Agile environments. As a Scrum Master, she found her passion in helping teams and leaders work together more effectively. In 2010, she founded Collaborative Leadership Team, offering Agile education and coaching services to start-ups, Fortune 100 and 500 companies. Angela's expertise extends beyond Scrum to include Kanban, eXtreme Programming, Facilitation, and Organizational Change. She is a Certified Scrum Trainer® and Certified LeSS Practitioner with a background in Communication and Management. Based in Minneapolis, Minnesota, Angela is a proud mom, wife, and teammate. Key Takeaways:Agile and Scrum methodologies were developed to address challenges in delivering value faster and reducing rework. They have become popular in the technology world for their ability to adapt to changing needs.Agile frameworks like Scrum promote transparency, making work visible and breaking down silos. This enhances communication, avoids misunderstandings, and minimizes wasted time and rework.Agile emphasizes breaking work into smaller, manageable chunks, allowing for faster feedback loops and early issue identification. This enables quicker value delivery and eliminates the need for lengthy development cycles.Agile and Scrum enable organizations to adapt quickly to market changes. By pivoting based on real-time feedback, organizations reduce the risk of delivering products or services that no longer meet market demands.Agile and Scrum value effective communication and collaboration, while still emphasizing the importance of documenting shared understanding and agreements.Agile is not a one-size-fits-all solution. It's important to assess whether Agile methodologies align with the specific business problem and context. Instead of blindly following Agile methods, organizations should identify their actual problem and goals, ensuring the chosen approach serves their purpose.Agile principles, such as transparency, iteration, and daily check-ins, can benefit various organizational contexts beyond software development, improving communication and efficiency.Limiting work in progress and prioritizing tasks effectively enhances productivity and value delivery, avoiding the scenario where everything is a priority, but nothing gets done effectively.Empowering teams and fostering shared knowledge leads to higher engagement and productivity. Cross-training and trust reduce dependency on individual expertise and prevent bottlenecks.Transparency and adaptability are crucial in times of change and challenge. By being transparent, exploring options, and adapting together, organizations can successfully navigate obstacles and ensure their survival and successTop 3 Takeaways:1. If everything is “priority”, nothing is. Pick one thing that's going to get you focused and you're going to see more productivity.2. Schedule more frequent check-ins. Be more transparent. 3. Team = we, not me. If you deem yourself an expert in something you should be able to teach. How to connect with Angela:Website: https://thescrummasterfiles.com/LinkedIn: https://www.linkedin.com/in/angelajohnsonscrumtrainer/

In this episode of Agile Mentors, Brian sits down with Lance Dacy to discuss integrating Agile and Scrum practices into the world of data science. Overview In this episode of the "Agile Mentors" podcast, Brian sits down with Lance Dacy to discuss integrating Agile and Scrum practices in the world of data science. Tune in to gain insight into the importance of feedback, the stages of the SAS Enterprise Miner initiative, and how frameworks like OSEMN can enhance the data science process. Listen in to learn how to strike the right balance between technical knowledge and product ownership and why culture is crucial in successful Agile implementation within the data science domain. Listen Now to Discover: [01:16] - Brian introduces his guest Lance Dacy, referring to him as "our San Diego Zoo guy" and the topic of today's show using Agile or Scrum practices in a data science world. [02:27] - Lance shares his background in data science and how it fits into the world of Agile. [05:06] - The big reason so many people are against using Agile for data science and where the big rub is. [09:02] - Who cares if it’s Agile or not? Lance shares Jeff Salts's poll about data science and introduces CRISP-DM. [11:05] - The six steps of the cross-industry standard process for data mining. [14:18] - Adopting a Scrum-like approach and treating data science work as smaller phases makes it possible to classify and organize tasks effectively. [15:59] - Does anyone remember the Rational Unified Process? [17:57] - It’s up to you to come up with ideas—once you have them, here's how we get it done. [18:18] - In the world of data science, implementing frameworks like Scrum can lead to misconceptions and failures—the key lies in understanding the layers of data science, navigating the complexities of the work effectively, and making informed decisions. [23:06] - The vital importance of feedback. [23:45] - The stages of the SAS Enterprise Miner initiative. [27:25] Brian introduces the sponsor for the podcast, Mountain Goat Software, and their two-day Certified ScrumMaster Course that’s perfect for anyone who wants to understand Scrum and add value to any team. [28:23] - How the product owner fits in when discussing working with big data. [29:50] Lance introduces the OSEMN process and explains how to solve a problem like a data scientist. [30:47] - When it comes to the role of a product owner, the technical knowledge required depends on the nature of the product. [31:42] - While Scrum lacks explicit guidance on backlog construction, the OSEMN framework themes (obtain, scrub, explore, model, interpret) can be incorporated to align sprint goals with specific aspects of the data science process. [33:47] - The framework or the structure of how you carry it out is less important than the kind of agreement. [35:07] - It's a cultural rather than a process problem. Lance delves into the debate on applying Agile Scrum to research. [36:37] - A fundamental misunderstanding about daily scrums. [37:18] - None of us are smarter than all of us together. Agile and Scrum work well when you know how to solve the problem, and there's a relatively clear path to victory. [38:49] - Brian shares his biggest piece of advice to people considering this in the data science [39:28] - “Data science is just the work that we're trying to do, tailor your process for your team and your culture and always inspect and adapt to try to make it better.” [41:08] - If you have feedback for the show or topics for future episodes, email us by clicking here (if you have yet to get a response, send another one as something has gone wrong in the process). And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode. And if you are a data scientist or work in big data and found the information in this valuable, let one of your co-workers know about it. References and resources mentioned in the show: Data Science Process Alliance CRISP-DM OSEMN Scrum and Data Science Agile Mentors Blog Topic: Decision Science - What methodology fits best? Certified ScrumMaster Training and Scrum Certification 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 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. Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

Angela Johnson is a seasoned entrepreneur, CEO, Certified Scrum Trainer, and author of the acclaimed book "The Scrum Master Files." With expertise in entrepreneurship and professional education for adult learners, Angela has made a significant impact in these fields.Angela's small business celebrates a remarkable milestone, turning 13 on June 1, 2023. In 2019, the business achieved vertical integration by opening its own bricks and mortar training and event center. Despite the challenges posed by the COVID-19 pandemic, Angela successfully navigated the situation, including managing a newly signed lease.In her work, Angela covers various aspects of small business management, emphasizing the unique "everyone is in sales" approach. Unlike most service organizations, Angela's business operates without a designated salesperson, fostering a collaborative and customer-centric environment.To connect with Angela Johnson or learn more about her work, visit her website at scrumfiles.com. Visitors can sign up for a free download and access valuable resources. Angela is also available on LinkedIn at https://www.linkedin.com/in/angelajohnsonscrumtrainer/ for professional networking and updates.

LifeBlood: We talked about the power of self management, the philosophy and practice behind agile and scrum, the benefits of mutual commitment to principles and values, and how to get more done by empowering others, with Angela Johnson, Certified Scrum Trainer, Agile Guide, author, and Founder of Collaborative Leadership Team.      Listen to learn how to help others become better self managers! You can learn more about Angela at ScrumFiles.com CollaborativeLeadershipTeam.com, Twitter and LinkedIn. Get your copy of The Scrum Master Files HERE Thanks, as always for listening! If you got some value and enjoyed the show, please leave us a review here: ​​https://ratethispodcast.com/lifebloodpodcast You can learn more about us at LifeBlood.Live, Twitter, LinkedIn, Instagram, YouTube and Facebook or you'd like to be a guest on the show, contact us at contact@LifeBlood.Live.  Stay up to date by getting our monthly updates. Want to say “Thanks!” You can buy us a cup of coffee. https://www.buymeacoffee.com/lifeblood

About Angela Johnson: Angela Johnson calls herself “professional people geek.” She is a Certified Scrum Trainer, Agile Guide and author of The Scrum Master Files, Secrets Every Coach should know.    She has 25+ years of experience working with teams and leaders in both project management and Agile environments. Angela started her career in technical support, quickly advancing to programming, database administration and project management. She realized that her passion was not in Gantt charts and status reports but in helping people work together more effectively within organizations. Becoming a Scrum Master enabled her to serve teams.    In 2010, she founded her company to bring Agile education and coaching services to a diverse group of start-ups, Fortune 100 and 500 companies. Angela identified that the best way to learn more about the highs and lows of Scrum adoptions was to immerse her own company into this way of working. In 2014 she renamed the company to Collaborative Leadership Team and began the same journey her clients were undertaking.   Collaborative Leadership Team uses Agile to manage the company and has the privilege of serving others in a variety of industries including: software, hardware, services, marketing and more. The breadth and depth of CoLeadTeam's experience extends beyond Scrum and includes Kanban, eXtreme Programming, Facilitation and Organizational Change for Business Agility.   Angela is a Certified Scrum Trainer®, and a Certified LeSS Practitioner. She holds a Masters of Business Communication from the University of St. Thomas. She believes her greatest roles are mom, wife and teammate.   In this episode, Jordan and Angela Johnson discuss: Problems that are universal to organizations  The relationship between autonomy and psychological safety  The four values of the Agile Manifesto  Practicing radical daily transparency   Key Takeaways: Scrum is all about not having somebody hierarchical above you telling you what to do and when to do it. It's a self-organizing self-managing team. A leader's job is to create alignment and make sure that everyone across the board is able to implement new strategies like scrum and agility.  In order to introduce autonomy and personal responsibility in an organization, the environment has to become psychologically safe and people are able to openly bring up problems that come to light.  Being agile is all about your organization's ability to pivot or adapt. Here are the four values of the Agile Manifesto: Individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.  The key to cultivating an agile team is to practice daily radical transparency. For you to be agile, and be able to pivot in time to prevent a disaster or seize an opportunity, you've got to know where your organization is.  “The leader has to set the tone and be very clear - because people will make things up in the absence of clear direction. ” —  Angela Johnson   Connect with Angela Johnson:   Website: https://thescrummasterfiles.com/  LinkedIn: https://www.linkedin.com/in/angelajohnsonscrumtrainer/    Connect with Jordan:  For executives wanting a complimentary executive coaching conversation: jordan@jordangoldrich.com  Website: www.workplacewarriorinc.com Twitter: https://twitter.com/jordangoldrich1 Facebook: https://www.facebook.com/jordan.goldrich Instagram: https://www.instagram.com/jordangoldrich/ LinkedIn: https://www.linkedin.com/in/jgoldrich/

Just when Angela Johnson thought her career was set in stone, an unexpected twist taught her the importance of agility in business. This realization not only revolutionized her approach but also opened doors to a whole new world of opportunities. What was this twist? Keep reading to find out! About Angela Johnson:Angela Johnson is a Certified Scrum Trainer and a Business Agility Coach with Collaborative Leadership Team. In 2010, she founded the company to provide education and coaching services to clients adopting Scrum and Agile. In 2014, Angela renamed the company and began assembling the dream team. CoLeadTeam uses the Agile values and principles it teaches. Their experiences help their clients apply these practices more readily and enable them to pivot in the face of change.A graduate of Hamline University (B.A.) and the University of St. Thomas (M.B.C.), Angela focuses her work on the upper Midwestern areas of the United States to best serve in her most important roles: wife and mom. In this episode, Dean Newlund and Angela Johnson discuss how to:Decode the critical role of agility in building adaptive business structures.Get acquainted with transformative agile frameworks, such as Scrum and Lean, to enhance your business efficiency.Expose the challenges in embracing agile methodologies within complicated organizations.Understand the power of trust and empowerment in ensuring success within agile settings.Construct small, self-reliant, and strategic teams to strengthen your business agility. "Flatter is better. The more hierarchy and red tape we have, the less nimble we are.” —  Angela Johnson  Connect with Angela:  Twitter: @AgileAngelaLinkedIn: https://www.linkedin.com/in/angelajohnsonscrumtrainer/Website URL: https://collaborativeleadershipteam.com/Workshops: https://collaborativeleadershipteam.com/upcoming-courses Connect with Dean:YouTube: https://www.youtube.com/channel/UCgqRK8GC8jBIFYPmECUCMkwWebsite: https://www.mfileadership.com/The Mission Statement E-Newsletter: https://www.mfileadership.com/blog/LinkedIn: https://www.linkedin.com/in/deannewlund/Twitter: https://twitter.com/deannewlundFacebook: https://www.facebook.com/MissionFacilitators/Email: dean.newlund@mfileadership.comPhone: 1-800-926-7370  Show notes by Podcastologist: Hanz Jimuel Alvarez Audio production by Turnkey Podcast Productions. You're the expert. Your podcast will prove it. 

Join Brian and his guest Lance Dacy as they explore the key differences, skill sets required, and the exciting opportunities in the roles of Scrum Master and Product Owner. Overview In this episode of the "Agile Mentors" podcast, Brian sits down with Lance Dacy to explore the dynamic roles of Scrum Master and Product Owner. They delve into the fundamental differences between these roles, highlighting the unique skill sets required for each. Lance shares his valuable insights and personal experiences, shedding light on the challenges and opportunities that arise in these pivotal positions. Whether you're considering a career in Agile or seeking to enhance your understanding of Scrum, listen in to this episode for practical advice and guidance for aspiring Scrum Masters and Product Owners and a deeper understanding of the crucial roles they play in driving successful projects and maximizing team productivity. Listen Now to Discover: [01:17] - Brian Milner has Lance Dacy on the show today to talk about a question emailed to the listener email address about the two different approaches to Scrum and which class would be a good fit for you, a Certified Scrum Master (CSM) or a Certified Scrum Product Owner (CSPO). [02:28] - Lance shares how he looks at the two different designations and what he looks at as the centerpiece of the process of Scrum. [03:24] - Things to consider when deciding whether the CSM or the CSPO is right for you. [04:34] - Where to start your Scrum journey as a beginner and when taking both the CSM and the Certified Scrum Product Owner (CSPO) classes might be beneficial. [05:28] - You don't have to be a Scrum Master to benefit from the CSM class. [05:54] - The dual focus of the Product Owner roles and the diminishment of Scrum roles. [06:45] - The challenge of combining these roles effectively. [07:54] - The goal is to be agile rather than just doing Scrum-Lance shares the importance of delivering value efficiently and early. Relegating the Scrum Master to facilitation and metrics tasks yields minimal ROI. [08:28] - Do you ever see the coach playing the game? [09:10] - Scrum is a tool - you have to know the tools, how to apply them, and, more importantly, how to use them for the appropriate case. [10:16] - The distinction between programmers (those who code) and developers (anyone working to produce the product) and a look back at the developer role in Scrum. [11:34] - What confuses most people about the different classes and roles. [12:28] - The importance (and top challenges teams face) of capacity planning, Sprint planning, and daily work management in Scrum teams. Lance shares why addressing these aspects is valuable for software and product teams, including marketing and infrastructure teams. [13:44] - The value of certifications as a standard and an advantage in certain situations, but it's like learning to drive - experience is crucial. [15:42] - The importance of learning the values, principles, and tools associated with Agile methodologies to engage in experimentation and gain practical experience, whether a CSM, CSPO, or CSV. [16:25] - How active involvement in user groups and communities (such as the DFW Scrum user group) provides valuable insights and career benefits, fostering collective knowledge sharing and continuous learning in Scrum (and beyond). [17:23] - Mountain Goat Software, the sponsor for this podcast, offers certified LIVE online Scrum classes, including Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), Advanced Certified Scrum Master (ACSM) and Advanced Certified Scrum Product Owner (ACSPO) classes. Book more than three weeks in advance for an early bird discount of $100. [18:38] - Lance shares the three characteristics of a great product owner. [19:28] - Advice for what you should do if you’re starting from scratch and aiming to become a product owner to gain exposure and valuable experience in the field. [21:28] - The likelihood of moving from Scrum Master to product owner rather than vice versa. [22:47] - The four requirements of becoming a Scrum Master requires strong facilitation, teaching, mentoring, and coaching skills, and the demands of being a product owner that makes it a higher barrier for entry. [23:52] - The focus of a Scrum Master vs. a product owner. [24:48] - It's like being the Zamboni for a hockey team—as a Scrum Master, you have the opportunity to work in diverse industries, ranging from space science and astrophysics to finance and software development, without being an expert in those domains. [26:34] - A safer environment for experimentation and growth without the high stakes of individual accountability. [26:58] - Brian shares the primary determining factor in deciding between product owner or Scrum master. [27:51] - In the movie-making industry, like in software teams, there are distinct roles and responsibilities. You can choose to define the problem, manage the process, or contribute to building the product—pick your door and start running (and if you don't like it, you can always switch). [29:06] Real knowledge comes from doing, BUT a class can get you started on the right foot to understanding how to do things and getting your hands dirty to cement further what you want to do. [30:26] - Lance shares how obtaining a CSM or CSPO certification is like earning a black belt in karate—it's a pathway that empowers you to explore. [33:24] - Still on the fence? Send us a note, and we'll gladly help you find your path. [33:40] - Check out the Mountain Goat's training schedule to attend a class with Lance or Brian. [34:01] - Exciting news! We have introduced an Agile Professional Directory to our Agile Mentors community. As a member, you can now sign up and claim your certifications, allowing you to showcase your expertise when interacting with others on the site. [34:35] - Don’t forget, Mountain Goat Software offers a range of classes, including Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), Advanced Certified Scrum Master (ACSM), and Advanced Certified Scrum Product Owner (ACSPO). We love having podcast listeners join our classes to explore further the topics discussed on the show (click here to subscribe). References and resources mentioned in the show: Certified Scrum Master Training and Scrum Certification Certified Scrum Product Owner Training Advanced Certified ScrumMaster® Advanced Certified Scrum Product Owner® #4: The Developer Role in Scrum with Sherman Gomberg DFW Scrum (Dallas, TX) | Meetup 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. Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

Angela Johnson is a Certified Scrum Trainer, Agile Guide and founder of Collaborative Leadership Team. In 2010 she founded the company to provide education and consulting services to clients adopting Scrum and Agile. She was successful at helping others begin their agile journey but wanted a better way to share the highs and lows any Scrum Team faces in their journey. She needed a Scrum Team of her own.     CONNECT WITH Angela Johnson Website: https://collaborativeleadershipteam.com/ Twitter: https://twitter.com/coleadteam LinkedIn: https://www.linkedin.com/company/collaborative-leadership-team/   CONNECT WITH Cedric Francis Website: https://www.lead2greatness.com/ Facebook: https://www.facebook.com/cedricbfrancis Twitter: https://twitter.com/cedricbfrancis Instagram: https://www.instagram.com/leadtogreatness/ LinkedIn: https://www.linkedin.com/in/cedric-b-francis-a0544037/   DONATE TO Fight Hungry Website: https://www.mtsoutreach.org   Disclosure: Links contain affiliates. When you buy through one of our links we will receive a commission. This is at no cost to you. Thank you for supporting Lead to Greatness and allowing us to continue to bring you valuable content.   Promo:   Try Audible Premium Plus and Get up to two free audiobooks: https://amzn.to/3as87Aw   Recording Equipment   Mic - https://amzn.to/3dHeSAi   Road Castor Pro - https://amzn.to/3aujvvS   Headset - https://amzn.to/2QM2O8a   Mic Cable - https://amzn.to/3dJ9Wec   USB Cable (Mac Book Only) - https://amzn.to/2PbAPy2   USB Cable (Windows Only) - https://amzn.to/3sK5K2h   Cable Compatible with Bose Brands - https://amzn.to/32BpN8j   Camera - https://amzn.to/3ncI7Oz   Mini Switcher - https://amzn.to/3dJGiWy   Micro HDMI Cable - https://amzn.to/3tISvQK   High Speed HDMI to HDMI Cable - https://amzn.to/3v3NfaG 

In this episode of the “Agile Mentors” podcast, Brian and Anu Smalley share their perspectives on the relationship between culture and Agile transformation and why people are key. Overview Coaching an Agile transformation requires more than just knowing how to run a daily Scrum. Finding the right people for the job is critical to success. In this episode of the "Agile Mentors" podcast, Brian and Anu Smalley chat about the importance of diversity in Agile teams. Listen in as Brian and Anu explore how culture impacts an organization's ability to adopt Agile practices, the role of leaders in creating an inclusive culture, and the power of sharing stories in building a strong community. Listen Now to Discover: [01:17] - Brian introduces us to the guest, Anu Smalley, who has a lot of experience in Agile coaching and consulting. She’s also been instrumental in increasing diversity in the Agile community. She has a CST mentoring group for people who don't have the same background as the majority of people in the Scrum Alliance. Her company is Capala Consulting Group. [03:34] - Metrics and methodologies are important in organizational transformation, but people are at the heart of it. Organizations cannot successfully transform without the right people. [04:02] - Anu talks about how the Agile Manifesto emphasizes individuals and interactions as the key to success in transformation. She emphasizes the importance of having the right people in an organization to ensure a successful transformation. [05:07] - Coaching an Agile transformation requires more than just knowing how to run a daily Scrum. Finding the right people for the job is critical to success. [05:55] - Brian notes that some businesses see their employees as replaceable parts in a machine. A diversity of perspectives is essential; having only one perspective limits the team's potential. [06:52] - Each person is unique and cannot be replaced like a part in a machine. Anu stresses the importance of recognizing the human aspect of transformation to succeed and that metrics alone will not suffice. [07:48] - Brian discusses the comparison between Agile software development and research and development. Having the right people for the job is critical. [08:30] - Agile transformation requires a focus on people and coaching, and the framework will fall into place once that focus is in place. [09:14] - Anu highlights the importance of understanding what being Agile truly means rather than just knowing the techniques. [09:59] - Brian notes that while many attendees may attend Agile training classes solely for certification, trainers can use this opportunity to teach attendees a deeper understanding of Agile and transform their approach to work. [10:46] - Anu notes that there is a significant difference between implementing Scrum and transforming an organization—one can be learned in a two-day class, while the other requires a deeper understanding of what being Agile truly means. [12:02] - Focusing on people is the key to success in Agile transformation; without it, organizations will not get very far. [14:17] - Brian emphasizes the uniqueness of organizations and how Scrum is designed to be adjusted and custom fit for each group that uses it. [14:49] - Anu highlights the importance of role clarity for individuals and teams to minimize conflicts. [15:53] - The virtual world has made role clarity even more important. Anu shares an example of a client whose main focus for 2023 is to achieve role clarity amongst their teams, explaining what is essential to achieving this goal. [16:19] - Clarity is achieved by bringing people together, resolving conflicts, and working towards common goals. [16:19] - Anu emphasizes that coaching and resolving conflicts are key to achieving role clarity and smooth functioning among teams in an organization. [16:37] - Brian compares learning the basics of baseball to attending a class on Scrum—a class can teach you the basics—a coach is necessary to grow and improve. [17:50] - Anu shares that a coach is essential, even for the best sports people on the planet. [16:19] - Anu emphasizes the importance of role clarity and resolving conflicts in an organization to ensure everyone understands their role and works together effectively. [18:39] - Anu explains that the best players in any sport have personal coaches to keep them in the "being mode," focusing on the individual's growth to impact the company's growth. [19:33] - Brian highlights that even the best athletes in the world have coaches, and we should always keep growing and never stand still. [19:51] - Agile transformations are about the people we have—Anu reiterates the importance of focusing on individuals' growth to impact the company's growth. [20:12] - Leaders need to ensure they have the right people and are continuously teaching, coaching, and helping them move forward. [20:35] - Brian introduces the sponsor of the podcast, Mountain Goat Software's Certified ScrumMaster Class, and highlights its benefits for those interested in understanding Scrum. [23:34] - Anu shares examples of clients who have decided to combine roles or accountabilities due to budget cuts and how it impacts the Agile journey. [24:40] - Anu advises against continuing the Agile journey until it can be done properly. [25:43] - Leaders often make the mistake of not understanding the importance of ScrumMasters, but ScrumMasters do, in fact, provide value (a little sarcasm here). [26:00] - Without capable ScrumMasters, the transformation will stall or fail. [26:39] - Brian notes that even with capable ScrumMasters, leaders must trust and empower them to drive the transformation forward. [27:02] - Culture is all about people; if you don't have a culture supporting Agile transformation, it won't go anywhere. [27:55] - Talking about trust issues between leadership and teams. [28:55] - Anu explains that some leaders may have talented staff, but they are too scared to trust them with an Agile transformation because they are worried about the culture and power structure changes. [29:35] - Brian suggests an innovation initiative, to which Anu sarcastically proposes an innovation sprint as a solution. [29:47] - Brian encourages listeners to contact Anu through LinkedIn or through the website of her company, Capala Consulting Group. [30:52] - Anu invites listeners to share their Agile transformation stories with her and promotes the importance of building a community through shared experiences. [32:58] - The value of learning from different cultural perspectives. [33:17] - Brian invites you to share your ideas for the show or feedback. Email Brian. References and resources mentioned in the show: Capala Consulting Group Mountain Goat Software's Certified ScrumMaster Class Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Agile Manifesto​​ 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. Anu Smalley is the President and Founder of Capala Consulting Group, where she specializes in Executive Coaching and Agile Transformations. She is a Certified Enterprise Coach and Certified Scrum Trainer®. She’s an active member of the larger Scrum and Agile community and enjoys giving back via volunteering at various conferences.

In this episode of the “Agile Mentors” podcast, Brian and Anu Smalley share their perspectives on the relationship between culture and Agile transformation and why people are key. Overview Coaching an Agile transformation requires more than just knowing how to run a daily Scrum. Finding the right people for the job is critical to success. In this episode of the "Agile Mentors" podcast, Brian and Anu Smalley chat about the importance of diversity in Agile teams. Listen in as Brian and Anu explore how culture impacts an organization's ability to adopt Agile practices, the role of leaders in creating an inclusive culture, and the power of sharing stories in building a strong community. Listen Now to Discover: [01:17] - Brian introduces us to the guest, Anu Smalley, who has a lot of experience in Agile coaching and consulting. She’s also been instrumental in increasing diversity in the Agile community. She has a CST mentoring group for people who don't have the same background as the majority of people in the Scrum Alliance. Her company is Capala Consulting Group. [03:34] - Metrics and methodologies are important in organizational transformation, but people are at the heart of it. Organizations cannot successfully transform without the right people. [04:02] - Anu talks about how the Agile Manifesto emphasizes individuals and interactions as the key to success in transformation. She emphasizes the importance of having the right people in an organization to ensure a successful transformation. [05:07] - Coaching an Agile transformation requires more than just knowing how to run a daily Scrum. Finding the right people for the job is critical to success. [05:55] - Brian notes that some businesses see their employees as replaceable parts in a machine. A diversity of perspectives is essential; having only one perspective limits the team's potential. [06:52] - Each person is unique and cannot be replaced like a part in a machine. Anu stresses the importance of recognizing the human aspect of transformation to succeed and that metrics alone will not suffice. [07:48] - Brian discusses the comparison between Agile software development and research and development. Having the right people for the job is critical. [08:30] - Agile transformation requires a focus on people and coaching, and the framework will fall into place once that focus is in place. [09:14] - Anu highlights the importance of understanding what being Agile truly means rather than just knowing the techniques. [09:59] - Brian notes that while many attendees may attend Agile training classes solely for certification, trainers can use this opportunity to teach attendees a deeper understanding of Agile and transform their approach to work. [10:46] - Anu notes that there is a significant difference between implementing Scrum and transforming an organization—one can be learned in a two-day class, while the other requires a deeper understanding of what being Agile truly means. [12:02] - Focusing on people is the key to success in Agile transformation; without it, organizations will not get very far. [14:17] - Brian emphasizes the uniqueness of organizations and how Scrum is designed to be adjusted and custom fit for each group that uses it. [14:49] - Anu highlights the importance of role clarity for individuals and teams to minimize conflicts. [15:53] - The virtual world has made role clarity even more important. Anu shares an example of a client whose main focus for 2023 is to achieve role clarity amongst their teams, explaining what is essential to achieving this goal. [16:19] - Clarity is achieved by bringing people together, resolving conflicts, and working towards common goals. [16:19] - Anu emphasizes that coaching and resolving conflicts are key to achieving role clarity and smooth functioning among teams in an organization. [16:37] - Brian compares learning the basics of baseball to attending a class on Scrum—a class can teach you the basics—a coach is necessary to grow and improve. [17:50] - Anu shares that a coach is essential, even for the best sports people on the planet. [16:19] - Anu emphasizes the importance of role clarity and resolving conflicts in an organization to ensure everyone understands their role and works together effectively. [18:39] - Anu explains that the best players in any sport have personal coaches to keep them in the "being mode," focusing on the individual's growth to impact the company's growth. [19:33] - Brian highlights that even the best athletes in the world have coaches, and we should always keep growing and never stand still. [19:51] - Agile transformations are about the people we have—Anu reiterates the importance of focusing on individuals' growth to impact the company's growth. [20:12] - Leaders need to ensure they have the right people and are continuously teaching, coaching, and helping them move forward. [20:35] - Brian introduces the sponsor of the podcast, Mountain Goat Software's Certified ScrumMaster Class, and highlights its benefits for those interested in understanding Scrum. [23:34] - Anu shares examples of clients who have decided to combine roles or accountabilities due to budget cuts and how it impacts the Agile journey. [24:40] - Anu advises against continuing the Agile journey until it can be done properly. [25:43] - Leaders often make the mistake of not understanding the importance of ScrumMasters, but ScrumMasters do, in fact, provide value (a little sarcasm here). [26:00] - Without capable ScrumMasters, the transformation will stall or fail. [26:39] - Brian notes that even with capable ScrumMasters, leaders must trust and empower them to drive the transformation forward. [27:02] - Culture is all about people; if you don't have a culture supporting Agile transformation, it won't go anywhere. [27:55] - Talking about trust issues between leadership and teams. [28:55] - Anu explains that some leaders may have talented staff, but they are too scared to trust them with an Agile transformation because they are worried about the culture and power structure changes. [29:35] - Brian suggests an innovation initiative, to which Anu sarcastically proposes an innovation sprint as a solution. [29:47] - Brian encourages listeners to contact Anu through LinkedIn or through the website of her company, Capala Consulting Group. [30:52] - Anu invites listeners to share their Agile transformation stories with her and promotes the importance of building a community through shared experiences. [32:58] - The value of learning from different cultural perspectives. [33:17] - Brian invites you to share your ideas for the show or feedback. Email Brian. References and resources mentioned in the show: Capala Consulting Group Mountain Goat Software's Certified ScrumMaster Class Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Agile Manifesto​​ 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. Anu Smalley is the President and Founder of Capala Consulting Group, where she specializes in Executive Coaching and Agile Transformations. She is a Certified Enterprise Coach and Certified Scrum Trainer®. She’s an active member of the larger Scrum and Agile community and enjoys giving back via volunteering at various conferences.

Karim Harbott joins Brian to talk about the 5 levers of crafting a strong culture in an organization and the critical role of leaders in establishing it. Overview On this episode of the "Agile Mentors" podcast, Karim Harbott joins Brian to discuss the importance of crafting a strong culture in an organization through his 5 Levers for Changing Organizational Culture. Listen in as they discuss the importance of aligning behaviors with the organization's strategy and the often-overlooked but critical role that leaders play in the cultural transformation of organizations. Listen Now to Discover: [01:34] - Brian introduces Karim Harbott, an Agile coach and CST, and highlights his book, “The 6 Enablers of Business Agility” He’s joining Brian to discuss culture change and the challenges associated with it. [02:25] - Karim discusses where to begin to make cultural change. [04:14] - Brian and Karim discuss the challenges of teaching culture and the importance of modeling desired behaviors. [04:47] - Karim explains that behaviors are a key factor in shaping culture and shares that there are five levers for changing the culture of an organization. The first lever is the organization's structure, which can encourage collaboration or silos and is the first thing within your control to influence behavior and how people collaborate. [07:15] - Karim emphasizes the importance of examining the system in place using the analogy of a gardener to explain that leaders need to create an environment that fosters the growth of the desired culture and behaviors. [07:51] - Brian references a quote by Craig Larman highlighting that whatever you're seeing at the moment, your system is designed to output that—for a different output, you gotta change the system. [08:21] - Karim explains that Craig Larman's and Deming's quote that "every system is perfectly designed for the results it's getting" both emphasize the importance of the structure in determining culture. [08:47] - Karin shares the second lever for changing culture, which is that the policies and rules that leaders create can be used to control or influence behaviors. [10:37] - Brian references the "Don't be evil" structure at Google and what it entailed. [11:37] - Karin discusses the importance of weaving high-level values into every part of how the organization operates, even the low-level aspects of the organization, to truly influence behaviors. [12:15] - Karin talks about the third lever of culture change, which is metrics and targets, and notes that what you measure and set as targets speaks volumes about what leadership values in the organization. [14:18] - Measuring intangible things like respect and integrity can be difficult, but it is important to find a way to measure them even though they don’t fit neatly into a dashboard. [15:51] - Brian shares an interesting paradigm they use at Mountain Goat Software, where they set goals with both a visual and emotional aspect to help them determine when they’ve reached their goal. [16:56] - Karim discusses the importance of HR processes as a lever (Lever #4) for influencing and reinforcing behaviors in an organization. [18:27] - Brian shares the sponsor for the podcast, Better User Stories, a one-day live online training course with Mike Cohn to improve your user story writing, so your team can do its best work, faster. [19:12] Brian emphasizes the concept that the company is a team effort, not an individual sport. [20:21] Karim highlights the difference between Henry Ford's production line and a team-based environment using the analogy of chopping onions in the kitchen but being asked to make a tiramisu. [21:30] - If the culture incentivizes individuals to prioritize their own interests over the interests of the team, then there is a problem, and conflicting incentives will lead to failure. [22:21] - Incentivizing individualism over teamwork will lead to failure (and unhappiness among 70% of employees). [23:39] - Karim discusses the fifth lever, which he considers to be the most powerful: leadership behaviors. [26:20] - Actions speak louder than words: Brian speaks about the importance of leadership behavior in promoting a healthy work culture with the example of unlimited vacation policies. [28:23] - Karim talks about the importance of behavioral norms in an organization, citing descriptive and injunctive norms as examples. By using the example of a library, he illustrates how people tend to conform to social norms. [30:39] - Karim shares the two things that are necessary to strengthen a culture; without these, a culture cannot be strong (it's important for leaders to be hypersensitive to this). [31:47] - The disapproval of others can be a powerful tool to make sure people behave the way we want them to behave. [32:47] - Brian shares how the TV show Brain Games demonstrated social norms and people conforming to the crowd. [33:43] - Karim emphasizes the importance of crafting a strong culture as one of the most important things a leader can do and calls for it to be a core leadership capability. [35:46] - Do you have an idea for the show or feedback you'd like to share? We'd love to hear from you. Email Brian. References and resources mentioned in the show: Mountain Goat Software's Better User Stories The 6 Enablers of Business Agility: How to Thrive in an Uncertain World The 6 Enablers of Business Agility 5 Levers for Changing Organisational Culture Lead and Disrupt Larman's Laws of Organizational Behavior 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. Karim Harbott is a leadership and business agility expert, entrepreneur, author, and international keynote speaker with over a decade of experience helping organizations with business agility. Karim is one of only a few people globally to hold the Certified Agile Leadership (CAL) Educator, Certified Scrum Trainer® (CST), and Certified Enterprise Coach® (CEC) status.

Karim Harbott joins Brian to talk about the 5 levers of crafting a strong culture in an organization and the critical role of leaders in establishing it. Overview On this episode of the "Agile Mentors" podcast, Karim Harbott joins Brian to discuss the importance of crafting a strong culture in an organization through his 5 Levers for Changing Organizational Culture. Listen in as they discuss the importance of aligning behaviors with the organization's strategy and the often-overlooked but critical role that leaders play in the cultural transformation of organizations. Listen Now to Discover: [01:34] - Brian introduces Karim Harbott, an Agile coach and CST, and highlights his book, “The 6 Enablers of Business Agility” He’s joining Brian to discuss culture change and the challenges associated with it. [02:25] - Karim discusses where to begin to make cultural change. [04:14] - Brian and Karim discuss the challenges of teaching culture and the importance of modeling desired behaviors. [04:47] - Karim explains that behaviors are a key factor in shaping culture and shares that there are five levers for changing the culture of an organization. The first lever is the organization's structure, which can encourage collaboration or silos and is the first thing within your control to influence behavior and how people collaborate. [07:15] - Karim emphasizes the importance of examining the system in place using the analogy of a gardener to explain that leaders need to create an environment that fosters the growth of the desired culture and behaviors. [07:51] - Brian references a quote by Craig Larman highlighting that whatever you're seeing at the moment, your system is designed to output that—for a different output, you gotta change the system. [08:21] - Karim explains that Craig Larman's and Deming's quote that "every system is perfectly designed for the results it's getting" both emphasize the importance of the structure in determining culture. [08:47] - Karin shares the second lever for changing culture, which is that the policies and rules that leaders create can be used to control or influence behaviors. [10:37] - Brian references the "Don't be evil" structure at Google and what it entailed. [11:37] - Karin discusses the importance of weaving high-level values into every part of how the organization operates, even the low-level aspects of the organization, to truly influence behaviors. [12:15] - Karin talks about the third lever of culture change, which is metrics and targets, and notes that what you measure and set as targets speaks volumes about what leadership values in the organization. [14:18] - Measuring intangible things like respect and integrity can be difficult, but it is important to find a way to measure them even though they don’t fit neatly into a dashboard. [15:51] - Brian shares an interesting paradigm they use at Mountain Goat Software, where they set goals with both a visual and emotional aspect to help them determine when they’ve reached their goal. [16:56] - Karim discusses the importance of HR processes as a lever (Lever #4) for influencing and reinforcing behaviors in an organization. [18:27] - Brian shares the sponsor for the podcast, Better User Stories, a one-day live online training course with Mike Cohn to improve your user story writing, so your team can do its best work, faster. [19:12] Brian emphasizes the concept that the company is a team effort, not an individual sport. [20:21] Karim highlights the difference between Henry Ford's production line and a team-based environment using the analogy of chopping onions in the kitchen but being asked to make a tiramisu. [21:30] - If the culture incentivizes individuals to prioritize their own interests over the interests of the team, then there is a problem, and conflicting incentives will lead to failure. [22:21] - Incentivizing individualism over teamwork will lead to failure (and unhappiness among 70% of employees). [23:39] - Karim discusses the fifth lever, which he considers to be the most powerful: leadership behaviors. [26:20] - Actions speak louder than words: Brian speaks about the importance of leadership behavior in promoting a healthy work culture with the example of unlimited vacation policies. [28:23] - Karim talks about the importance of behavioral norms in an organization, citing descriptive and injunctive norms as examples. By using the example of a library, he illustrates how people tend to conform to social norms. [30:39] - Karim shares the two things that are necessary to strengthen a culture; without these, a culture cannot be strong (it's important for leaders to be hypersensitive to this). [31:47] - The disapproval of others can be a powerful tool to make sure people behave the way we want them to behave. [32:47] - Brian shares how the TV show Brain Games demonstrated social norms and people conforming to the crowd. [33:43] - Karim emphasizes the importance of crafting a strong culture as one of the most important things a leader can do and calls for it to be a core leadership capability. [35:46] - Do you have an idea for the show or feedback you'd like to share? We'd love to hear from you. Email Brian. References and resources mentioned in the show: Mountain Goat Software's Better User Stories The 6 Enablers of Business Agility: How to Thrive in an Uncertain World The 6 Enablers of Business Agility 5 Levers for Changing Organisational Culture Lead and Disrupt Larman's Laws of Organizational Behavior 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. Karim Harbott is a leadership and business agility expert, entrepreneur, author, and international keynote speaker with over a decade of experience helping organizations with business agility. Karim is one of only a few people globally to hold the Certified Agile Leadership (CAL) Educator, Certified Scrum Trainer® (CST), and Certified Enterprise Coach® (CEC) status.

Join Lance Dacy and Brian Milner as they discuss the use of metrics in an Agile environment to ensure optimal performance without taking things in the wrong direction. Overview In this episode of the Agile Mentors podcast, Lance Dacy joins Brian to delve into the intricacies of utilizing metrics in software development to ensure optimal performance while avoiding incentivizing adverse behaviors. Listen in as he walks us through the three tiers of metrics that are crucial for Agile teams to consider in order to stay on course. He’ll share the tools required to gain a holistic understanding of an individual's performance and how leadership styles and stakeholders influence team-level metrics. Plus, a look at the common challenges that teams may encounter during their Agile adoption journey and how to overcome them. Listen now to discover: [01:18] - Lance Dacy is on the show to discuss metrics. [02:09] - Brian asks, are there ‘good’ ways to track performance? [02:32] - Lance shares why Agile doesn’t really lend itself to tracking performance. [03:57] - How to handle performance reviews. [04:32] - Lance shares the best way to measure individual performance. [06:40] - Measuring team contribution vs. standalone rockstar. [07:48] - What Ken Schwaber and Jeff Sutherland say about the completeness of the Scrum Framework and why having a superhero on your team is bad. [09:45] - Lance shares the 3 tiers of metrics to measure when working as an Agile team to be sure their team is going in the right direction. [11:09] - Using tangible business-level metrics such as time to market for products, NPS, and support call volume to evaluate performance. [12:20] - How metrics, such as the number of work items completed per month, and cycle time, can be used to evaluate performance at a product level in an Agile environment. [14:10] - Lance shares standard metrics such as velocity, backlog churn, and work-in-process that can be used to evaluate things at the team level. [14:45] - Brian shares the importance of having a broader perspective to avoid having a distorted view of performance. [16:53] - How using tools such as Ishikawa (fishbone) diagrams can help you identify the root cause of the problem instead of the apparent cause. [17:22] - Individual velocity and other big metrics to avoid. [19:02] - How the balanced scorecard can help managers use ALL the information available to develop a comprehensive understanding of an individual's performance. [19:25] - The detrimental effects of using the wrong metrics to evaluate an individual's contribution. [21:29] - Brian shares the story of how a manager's bug squashing endeavor led to incentivizing the wrong behavior [22:31] - Lance references Stephen Denning's statement and reminds us that assumption testing is what developers do every day. [24:00] - Referencing the State of Agile Report statistics on what's stalling your transformation to Agile. [25:15] - Lance shares a behind-the-scenes look at how team-level metrics are affected by leadership styles and stakeholders. [27:05] - Lance shares the spreadsheet he's been using to track data for a Scrum team for over 5 years to understand why the team is not predictable and what they can do to improve. [31:38] - Got metrics management questions? Reach out to Lance. [31:46] - Why it’s imperative that you think of software development as R&D rather than manufacturing to arrive at the right metrics measurements. [33:26] Continue the conversation in The Agile Mentors Community. References and resources mentioned in the show: Join the More than 24k People Who've Trained to Succeed With Mountain Goat Software Mountain Goat Software Certified Scrum and Agile Training Schedule #30: How to Get the Best Out of the New Year with Lance Dacy #31: Starting Strong: Tips for Successfully Starting with a New Organization with Julie Chickering State of Agile Report HBR's Embrace Of Agile The Agile Mentors Community Additional metrics resources mentioned by Lance Agile Metrics Business outcomes, product group metrics, unit metrics) KPI/OKR (Business Outcomes) Time to market, NPS, Support Call Volume, Revenue, Active Account, New Customer Onboarding Time, Regulatory Violations) Product Group Metrics Work items completed per unit of time (quarterly) % of work in active state vs. wait state Cycle time of work times (idea to done) Predictability (% of work items that reach ready when planned) Unit metrics Velocity, backlog churn, work in process, team stability Metrics Spreadsheet Team Size Tracking the size of our cross-functional team (typically Dev and QA), allows us to pair that number with velocity to play “what-if” scenarios in the future. Whether you count half of a person if shared, or whole, keeping it consistent throughout your tracking is what is important. Most teams simply count the number of developers and testers. Team Days Tracking the iteration length is also helpful in understanding a team’s performance. If the team has a 2 week sprint, then usually that is 9 development days of actual work. The 10th day is set aside for sprint review, retrospective, and planning. Committed Tracking what the team committed to completing within a sprint is crucial to understanding their predictability. The are the most uneducated at the beginning of the sprint and tracking what they think they can complete helps us in long term planning. Completed Tracking what the team completed is actually just tracking velocity above, but comparing it what they committed helps us understand their predictability index. Predictability Index (Pi) Software development is complex, risky, and uncertain. A skill that is sought after in this type of environment is predictability. The better we are at understanding what we can accomplish, then finishing what we said we would accomplish builds trust with our management team and customers. If we aren’t very good, tracking this metric often helps us get back to good by committing to less or more depending on our index. Example: Completed Items / Committed Items = Predictability Index (Pi) 25 Story Points / 20 Story Points = 125% 20 Story Points / 25 Story Points = 80% Just because a team has a high Pi, does not mean they are good at predictability. Don’t let high and low numbers fool you, focus on the variance from 100% instead of the actual number. An arbitrary number to shoot for is +/- 15% Pi (85% or 115%). Story Points / Per Day (SPD) Story points per day is just that, tracking how many story points per day of the sprint did we complete (Completed / Team Days). Story Points / Per Day / Per Person (SP/PD/PP) This perhaps is the most useful metric to capture throughout the process. Most of our teams do not have the luxury of maintaining a consistent size or make-up. Inevitably over the course of a few months, the team make-up will change. Once the teams change, velocity has to be reset. In addition, we may actually change our sprint duration over a long period of time (don’t change it each sprint). Once we change sprint lengths, it can jeopardize our pure metrics, velocity has to be reset. However, over all of our teams in a product, if we can capture the SP/PD/PP that our teams complete on average, we can begin to play “what-if” scenarios in long- term planning. Example: Completed / (Team Size * Sprint Days) 24 / (4 * 9) = 0.67 You can then average that number over 4-6 sprints or even the year. Defects While we understand that we won’t ever likely have a zero defect product, it is useful to track how many defects our teams are creating over time. There are usually 2 types of defects, internal and external. Internal Our definition of done should at minimum include that testing is taking place during the sprint with the idea that we would not allow a story to be called DONE if it had remaining defects. As such, an internal defect are the ones that were created while working on a backlog item in the sprint, that we have fixed before calling the item DONE. External External defects are those that have “escaped” our development process and were not discovered during our testing. In a sense, our customer discovered the defect and the work item will become a new backlog item for a sprint. Warranty We should strive to have the warranty concept built into our process. If you bought a car yesterday and the radio fell out, you could take it back and they would fix it fairly quickly. Our customers deserve the same service. Don’t manage a defect backlog, get used to fixing escaped defects immediately, while they are fresh on your mind (right after a sprint). It doesn’t take a long time to fix defects, it takes a long time to find them once identified by a customer. Defects per Story Point Tracking defects per story point help to understand velocity a little better. If you have a team that has drastically increased its velocity, have the defects have increased along with it? Defects per story point help us understand the relationship between a velocity and defects created. Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? It would be great if you left a rating and a review. It really helps, and we read every single one. Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He’s passionate about making a difference in people’s day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Lance Dacy, known as Big Agile, is a dynamic, experienced management and technical professional with the proven ability to energize teams, plan with vision, and establish results in a fast-paced, customer-focused environment. He is a Certified Scrum Trainer® with the Scrum Alliance and has trained and coached many successful Scrum implementations from Fortune 20 companies to small start-ups since 2011. You can find out how to attend one of Lance’s classes with Mountain Goat Software here.

Join Lance Dacy and Brian Milner as they discuss the use of metrics in an Agile environment to ensure optimal performance without taking things in the wrong direction. Overview In this episode of the Agile Mentors podcast, Lance Dacy joins Brian to delve into the intricacies of utilizing metrics in software development to ensure optimal performance while avoiding incentivizing adverse behaviors. Listen in as he walks us through the three tiers of metrics that are crucial for Agile teams to consider in order to stay on course. He’ll share the tools required to gain a holistic understanding of an individual's performance and how leadership styles and stakeholders influence team-level metrics. Plus, a look at the common challenges that teams may encounter during their Agile adoption journey and how to overcome them. Listen now to discover: [01:18] - Lance Dacy is on the show to discuss metrics. [02:09] - Brian asks, are there ‘good’ ways to track performance? [02:32] - Lance shares why Agile doesn’t really lend itself to tracking performance. [03:57] - How to handle performance reviews. [04:32] - Lance shares the best way to measure individual performance. [06:40] - Measuring team contribution vs. standalone rockstar. [07:48] - What Ken Schwaber and Jeff Sutherland say about the completeness of the Scrum Framework and why having a superhero on your team is bad. [09:45] - Lance shares the 3 tiers of metrics to measure when working as an Agile team to be sure their team is going in the right direction. [11:09] - Using tangible business-level metrics such as time to market for products, NPS, and support call volume to evaluate performance. [12:20] - How metrics, such as the number of work items completed per month, and cycle time, can be used to evaluate performance at a product level in an Agile environment. [14:10] - Lance shares standard metrics such as velocity, backlog churn, and work-in-process that can be used to evaluate things at the team level. [14:45] - Brian shares the importance of having a broader perspective to avoid having a distorted view of performance. [16:53] - How using tools such as Ishikawa (fishbone) diagrams can help you identify the root cause of the problem instead of the apparent cause. [17:22] - Individual velocity and other big metrics to avoid. [19:02] - How the balanced scorecard can help managers use ALL the information available to develop a comprehensive understanding of an individual's performance. [19:25] - The detrimental effects of using the wrong metrics to evaluate an individual's contribution. [21:29] - Brian shares the story of how a manager's bug squashing endeavor led to incentivizing the wrong behavior [22:31] - Lance references Stephen Denning's statement and reminds us that assumption testing is what developers do every day. [24:00] - Referencing the State of Agile Report statistics on what's stalling your transformation to Agile. [25:15] - Lance shares a behind-the-scenes look at how team-level metrics are affected by leadership styles and stakeholders. [27:05] - Lance shares the spreadsheet he's been using to track data for a Scrum team for over 5 years to understand why the team is not predictable and what they can do to improve. [31:38] - Got metrics management questions? Reach out to Lance. [31:46] - Why it’s imperative that you think of software development as R&D rather than manufacturing to arrive at the right metrics measurements. [33:26] Continue the conversation in The Agile Mentors Community. References and resources mentioned in the show: Join the More than 24k People Who've Trained to Succeed With Mountain Goat Software Mountain Goat Software Certified Scrum and Agile Training Schedule #30: How to Get the Best Out of the New Year with Lance Dacy #31: Starting Strong: Tips for Successfully Starting with a New Organization with Julie Chickering State of Agile Report HBR's Embrace Of Agile The Agile Mentors Community Additional metrics resources mentioned by Lance Agile Metrics Business outcomes, product group metrics, unit metrics) KPI/OKR (Business Outcomes) Time to market, NPS, Support Call Volume, Revenue, Active Account, New Customer Onboarding Time, Regulatory Violations) Product Group Metrics Work items completed per unit of time (quarterly) % of work in active state vs. wait state Cycle time of work times (idea to done) Predictability (% of work items that reach ready when planned) Unit metrics Velocity, backlog churn, work in process, team stability Metrics Spreadsheet Team Size Tracking the size of our cross-functional team (typically Dev and QA), allows us to pair that number with velocity to play “what-if” scenarios in the future. Whether you count half of a person if shared, or whole, keeping it consistent throughout your tracking is what is important. Most teams simply count the number of developers and testers. Team Days Tracking the iteration length is also helpful in understanding a team’s performance. If the team has a 2 week sprint, then usually that is 9 development days of actual work. The 10th day is set aside for sprint review, retrospective, and planning. Committed Tracking what the team committed to completing within a sprint is crucial to understanding their predictability. The are the most uneducated at the beginning of the sprint and tracking what they think they can complete helps us in long term planning. Completed Tracking what the team completed is actually just tracking velocity above, but comparing it what they committed helps us understand their predictability index. Predictability Index (Pi) Software development is complex, risky, and uncertain. A skill that is sought after in this type of environment is predictability. The better we are at understanding what we can accomplish, then finishing what we said we would accomplish builds trust with our management team and customers. If we aren’t very good, tracking this metric often helps us get back to good by committing to less or more depending on our index. Example: Completed Items / Committed Items = Predictability Index (Pi) 25 Story Points / 20 Story Points = 125% 20 Story Points / 25 Story Points = 80% Just because a team has a high Pi, does not mean they are good at predictability. Don’t let high and low numbers fool you, focus on the variance from 100% instead of the actual number. An arbitrary number to shoot for is +/- 15% Pi (85% or 115%). Story Points / Per Day (SPD) Story points per day is just that, tracking how many story points per day of the sprint did we complete (Completed / Team Days). Story Points / Per Day / Per Person (SP/PD/PP) This perhaps is the most useful metric to capture throughout the process. Most of our teams do not have the luxury of maintaining a consistent size or make-up. Inevitably over the course of a few months, the team make-up will change. Once the teams change, velocity has to be reset. In addition, we may actually change our sprint duration over a long period of time (don’t change it each sprint). Once we change sprint lengths, it can jeopardize our pure metrics, velocity has to be reset. However, over all of our teams in a product, if we can capture the SP/PD/PP that our teams complete on average, we can begin to play “what-if” scenarios in long- term planning. Example: Completed / (Team Size * Sprint Days) 24 / (4 * 9) = 0.67 You can then average that number over 4-6 sprints or even the year. Defects While we understand that we won’t ever likely have a zero defect product, it is useful to track how many defects our teams are creating over time. There are usually 2 types of defects, internal and external. Internal Our definition of done should at minimum include that testing is taking place during the sprint with the idea that we would not allow a story to be called DONE if it had remaining defects. As such, an internal defect are the ones that were created while working on a backlog item in the sprint, that we have fixed before calling the item DONE. External External defects are those that have “escaped” our development process and were not discovered during our testing. In a sense, our customer discovered the defect and the work item will become a new backlog item for a sprint. Warranty We should strive to have the warranty concept built into our process. If you bought a car yesterday and the radio fell out, you could take it back and they would fix it fairly quickly. Our customers deserve the same service. Don’t manage a defect backlog, get used to fixing escaped defects immediately, while they are fresh on your mind (right after a sprint). It doesn’t take a long time to fix defects, it takes a long time to find them once identified by a customer. Defects per Story Point Tracking defects per story point help to understand velocity a little better. If you have a team that has drastically increased its velocity, have the defects have increased along with it? Defects per story point help us understand the relationship between a velocity and defects created. Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? It would be great if you left a rating and a review. It really helps, and we read every single one. Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He’s passionate about making a difference in people’s day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Lance Dacy, known as Big Agile, is a dynamic, experienced management and technical professional with the proven ability to energize teams, plan with vision, and establish results in a fast-paced, customer-focused environment. He is a Certified Scrum Trainer® with the Scrum Alliance and has trained and coached many successful Scrum implementations from Fortune 20 companies to small start-ups since 2011. You can find out how to attend one of Lance’s classes with Mountain Goat Software here.

Join Lance Dacy and Brian Milner as they discuss how to get the best out of the new year. Overview Something about that turn of the calendar from December to January makes us want to dig into planning, goal setting, and change. In this episode of the Agile Mentors podcast, Brian Milner and Lance Dacy discuss how to get the best out of the new year. They’ll walk through why personal retrospectives are the key to determining where to look for change. From 30-day challenges to building relationships with others in the Agile community, to fostering a fertile learning culture, listen in for insight into what might work for you to accomplish the change you seek to make this year your best. Listen now to discover: [01:15] - Welcome to our first podcast of 2023. [01:55] - How opening up our calendars to a new year sets us up for planning new things. [03:17] - Lance walks us through the two types of leaders, the visionary and the executor. [04:13] - Brian shares the benefit of personal retrospectives. [07:15] - How 30-day challenges catapult us to success by breaking things down into smaller chunks. [10:56] - Lance shares why New Year’s resolutions set us up for failure. [12:35] - How to plan goals using backlogs and the cyclical nature of organizations. [13:09] - How to use cross-training to challenge team members to broaden their horizons in the new year. [13:09] - Why you need to think about your intentions when trying to influence up. [14:03] - Why do 30-day challenges work well to engage in a new task, project, or skill with an experimental mindset. [15:29] - Lance shares why it’s critical for Scrum Masters to help leadership and management formulate career plans to help grow the people in the organization. [16:33] - If you’re doing the same thing you did last year, you’re not Agile. [17:16] - How plugging into a community can help you maintain your focus for growth. [19:48] - Why being a Scrum Master and a lone wolf don’t mix. [22:36] - How networking can help you take your career to the next level. [24:10] - Why it pays to keep an open mind (even to that which you don’t agree with), so you don’t miss out on vital information that can change your trajectory. [26:07] - Growing as a Scrum Master and as a person. References and resources mentioned in the show Agile Mentors Community Meetup #13: What Does Cross-Functional Really Mean? with Lance Dacy Mountain Goat Software 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? Please share your thoughts with us at podcast@mountaingoatsoftware.com This episode's presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.