
Loading summary
A
Hey there, agile adventurer, just a quick question.
B
What if, for the price of a
A
fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame warfree and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's the Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership, that's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.
B
Hello everybody. Welcome to one more week of the Scrum Master Toolbox podcast. And this week, joining us from beautiful Denmark is Christian Tordal. Hey Christian, welcome to the show.
C
Hey Vasco, thank you for having me.
B
Absolutely. So let me tell you a bit about Christian. He's a former Danish army officer turned Agile coach. It's interesting, we've interviewed a lot of army officers that have turned Scrum Masters or agile coaches. So one more. And he works with leaders and teams to create clarity, accountability and momentum in complex organizations. His approach blends military leadership principles with modern product development and helps organizations move from discussion and strategy to real execution and measurable results, which is the big gap in many organizations today. So, Christian, that was a short intro. Tell us a little bit more about yourself and how did you end up becoming a Scrum Master?
C
Yeah, so my journey didn't start in tech as many might have been doing. Mine started in the military where I served as a served and trained as a first lieutenant within the artillery in Denmark. And when I started the family, what is it, ten years ago now, the first one and a half year I was commuting back and forth towards Jotland and Copenhagen. And then my wife gave me the ultimatum of you want to be a dad or you want to be a soldier? So I applied for a job and I ended up at Copenhagen Airport as an operations manager within security. Was kind of good, but something was missing. So I reached out to a good friend of mine who was a software architect, used to work at a large logistics company and we kind of looked into what is it that an officer, what are the capabilities that this character has. So we kind of looked into product management and he said, if you want to do product management, you need to know about Agile. And I was like, what's agile? So what I basically did was I started reading about Agile, read the book Scrum about, from, from Jeff Sutherland, and I started connecting on LinkedIn with scrum masters. So I contacted real practitioners to know about the craft and what kind of fell in place was a lot of the things that you do as a Scrum Master is almost one to one with how leadership was done within the military and how my mindset worked. So it kind of clicked that way. And then I actually met up with a former classmate from the Officers Academy who just happened to be a lead Scrum Master with direct reports. And he said, I'm actually looking for one, so would you please send an application? And I think a couple of months later I was the lucky one to get that job. So that's how I became a Scrum Master.
B
It's interesting how you talk about the kind of military leadership style kind of similar to what a Scrum Master is, because out here in the civil world, the civilian world, I should say, we believe that military is all about top down command and control. But what I hear you say is that that's not how you guys on the inside saw it. Why do you think we have that view from the outside looking towards the military?
C
I think it's a remnant from old times, to be honest. Also maybe what you catch in the, in the movies and so on. For me, the military has been the institution or company that I've been in that had had the most modern and pragmatic approach to leadership. So for me there's a lot of structure, but structure creates freedom because it sets the frame from which you can operate. And then you basically left to come up with your own suggestions for how you want to build a solution.
B
Yeah, absolutely. That's a great way to introduce it and I'll put some links in the show notes. We've interviewed quite a lot of military personnel that has started their career as Scrum Masters and Agile Coaches later on. So, interesting stories, but of course, today's Monday, Christian and Mondays. Here on the podcast we talk about failure, not because we like failure, but because we like the lessons learned from failure. So tell us that story first. We'll dive into the details later.
C
Yeah, I have a lot of them because I have a lot of experience. But the one that comes to mind is from, from during the. The pandemic, the corona And I was working for a bank at this, this point, I think the third largest bank in Denmark. And I was kind of wondering, because I was told when I got the job that, that we were working with the rpa, Robotic Process Automation. Automation. And we were a small department. I had three teams. And the teams wanted not, you know, the classic scrum teams. They were a business analyst and then two developers, preferably seniors. But I was kind of curious to the approach that those kind of left for me to inherit. We were doing six week sprints and I was curious about that. And there was a lot of Angie patterns in general, planning sessions were like a half an hour where you would take one item, backlog item, and then just put it in a calendar, say, okay, this week to do this, next week you're going to do that. So I started looking into what is it that the symptoms are here. And I kind of advocated for shorter feedback loops in order for us to kind of bring more value to the business. And it took me some time to convince the po, which was also the kind of director of the small department that we had were 18 people in total. And the first planning session we had, everything crashed. And I couldn't figure out why until I kind of said, okay, then we have to go back to the. Well, there was a lot of yelling and a lot of scolding on my behalf, but let's go back to what we know. And what I found out was that we weren't having a backlog. So by having six week sprints, we were able to go outside to the business bringing assignments or add items, and then actually develop and release them within those six weeks frames. And the failure is that I failed to see this pattern. I only focused on the sprint length, which was weird to me because you usually do two weeks or four weeks. So I found out that I had to do more relationship building. I had to be in the meetings where the business analyst and the PO actually was discussing how things came into the backlog. So the real issue was not the length of the sprint, but the root cause was actually having problems with defining a backlog.
B
That's a great story. And it kind of reminds us that we should be humble enough to accept that how we see things may not actually be the real thing that is happening. Right, because the length of the sprint as you defined it in that story was just a symptom, Right? Like it wasn't the problem. It wasn't even the problem. In fact, it was a solution to the circumstance that they were in. And when we start digging into it or kind of trying to understand what's the reality beyond what I can observe directly. Then we start saying, oh, but maybe there's this other opportunity. If I would just be in the meetings with the business analyst and the product owner, I would learn a lot more. Right, and what did you do in that context, though, when you started to understand that what you thought was the problem was just merely a symptom? Did you try something else different? Did you share that insight with the people around you? How did it go?
C
I think my original approach was the military way. So you have. I kind of saw Scrum as we were doing Scrum. So I kind of saw Scrum as an sop, Standard Operating Procedure. So it was kind of by the book, but I failed to see the pragmatic side of it. So the context was really what was the tipping point for me. So what I did was I started going to these meetings and actually listening into what are the symptoms that the BAS and the PO is experiencing. And then from that going into, okay, I think I got it now. I think it's the backlog that's missing. So how about we start building a backlog? So we sat down and started figuring out how could we get more items in on a shorter time than the period that we already had?
B
Yeah, absolutely. And that just shows that once you start looking at the problem from a different perspective, you find other things to try out. And as long as you have that mentality of allowing the experiment to go right, like trying something out, learning and then improving, you can actually find something that works. So, great story. Thank you for sharing that. Christian, welcome.
A
Alright, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you. The members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing Agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep dive interviews, books. And if you're into no estimates, we got the pioneers of no estimates in those Deep Dive interviews as well. Agile business intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course, without the flame wars, it's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you. So check out all the details at Scrum Master Toolbox because listening is great, it's important. But doing it together, that's next level. I'll see you in the community.
B
Slack we really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum Masters know about this valuable resource for the work. Remember that sharing is caring.
Podcast: Scrum Master Toolbox Podcast
Episode Title: When Applying Scrum By The Book Fails, Understanding Context Before Changing The System
Guest: Christian Thordal (Former Danish Army Officer, Agile Coach)
Host: Vasco Duarte
Date: May 18, 2026
This episode explores the pitfalls of applying Scrum "by the book" without understanding the team's context, highlighting how seeing symptoms rather than root causes can lead to misguided interventions. Christian Thordal, with his unique military-to-Agile journey, shares a candid failure story and lessons learned about context, humility, and effective change in complex organizations.
"A lot of the things that you do as a Scrum Master is almost one to one with how leadership was done within the military and how my mindset worked."
— Christian Thordal [03:47]
"Structure creates freedom... you’re basically left to come up with your own suggestions for how you want to build a solution."
— Christian Thordal [05:12]
"The real issue was not the length of the sprint, but the root cause was actually having problems with defining a backlog."
— Christian Thordal [08:22]
"The context was really what was the tipping point for me."
— Christian Thordal [09:55]
"We should be humble enough to accept that how we see things may not actually be the real thing that is happening."
— Vasco Duarte [08:54]
This episode delivers a candid, practical reminder: Scrum and Agile are means to an end, not ends in themselves. Effective change starts with understanding the system’s context—and that requires curiosity, humility, and connection.