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 exper