Embracing Action in Agile Methodologies

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.