← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS From Combat Pilot to Scrum Master - How Military Leadership Transforms Agile Teams With Nate Amidon
00:35:01
Loading summary
Transcript43 lines
- [00:04]
A
Hey there, agile adventurer, just a quick question. What if, for the price of 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. Hello everybody. Welcome to a very special bonus episode. For today's bonus episode, we have with us Nate Amidon. Hey Nate, welcome to the show.
- [01:22]
B
Hey Vasco, thanks for having me.
- [01:24]
A
Absolutely. So Nate is the founder of Form 100 Consulting and a former Air Force officer and combat pilot turned servant leader in software development. Nate has taken the high stakes world of military aviation and brought its course core leadership principles, pardon me, clarity, accountability and execution, into his work with Agile teams. So Nate, let's start with your origin story. How did your experience as an Air Force pilot shape your approach, your take on leadership, and of course, eventually your work with agile teams?
- [02:01]
B
Yeah, well, thanks for having me for sure. And you know, I had no, I had no aspirations of working in the software development space. I decided not to be an airline pilot after leaving the Air Force and I sort of just fell into agile. I was a contractor at a large tech company and was working on an agile team and realized really quickly that how, how you build and create and execute in a software development way, in an agile way was it almost exactly how we operated in the military and especially as a pilot. So I flew C17s, which is a large cargo plane and it was, it's a plane with a large crew. So we had a crew of anywhere between five and seven people and we would go on missions that could be anywhere from two to three weeks long. And every day we would mission brief in the morning and make sure everyone was on the same page. And then we problem solved our way through the day and then we debriefed after and then we did it again. And at the end, you know, we, we accomplished the mission. So when I learned about what Agile was, I realized it's the exact same thing. And I'm familiar with time boxes because when you're flying, you have to land at. You only have so much gas. So all of this stuff really just fit well. And I realized that what I learned leading crews and teams and executing missions was the same philosophy that software development teams needed to execute. So, yeah, and so you learn a lot through trial and error as a military officer. And really that's what we do at Form 100. We hire former military officers, bring that leadership skill set into the software development space.
- [04:00]
A
Absolutely. So we had another Air Force pilot a few weeks back, about two weeks back from the time we are recording this, and he talked about something that you also talk about, which and you introduce, which is this brief execute debrief cycle, which the Air Force, at least the pilots have baked into everything. And how do you bring that experience to your work with the teams? Like, because of course you say that when you saw the agile teams and the work you were doing them, it felt familiar. But obviously the teams, they don't necessarily have people from the Air Force that would be aware of the brief execute debrief cycle. So they don't think it's the same.
- [04:48]
B
Right.
- [04:48]
A
So how do you kind of shape that, which is a very disciplined and focused approach from the military into the teams that you work with? Like, how does the conversation go, what reactions do you get and how hard is it to convey those ideas to the teams you work with?
- [05:05]
B
Well, I learned as an instructor pilot that it's really important to make sure everyone understands why you're doing what you're doing. So we don't brief execute debrief just because. Right. We do it because we know that getting everybody on the same page is really important. Right. Everyone needs to know what is going on. So we talk a lot about at our company is driving alignment. And so we have to be super clear strategically and tactically what it is that we're doing. And everyone's on the same page. So that's why the brief part is so important. And I'm gonna go on a quick tangent on briefing because the more high performing your team is, the more high performing your crew is, in my perspective, flying a cargo plane, the shorter and the more succinct those briefings get. Okay. And oftentimes the briefings can be really fast. They can, you know, you still want to keep the cadence, but everyone's on the same page already. And everybody knows now there's times when you just have a brand new crew and those briefings are going to take longer because you have to spend more time. But it's important to have the discipline to make sure you have those, you know, in, in the Agile world, planning daily standups, you have those syncs that drive alignment and communication and that's the real key for why we do it. And then obviously execute, you should execute, get things done. And then the debrief cycle though the reason we debrief is because we want to get better. Okay. And we, when, whenever we would fly a mission, things would always go wrong. Like we would always mess things up and there could be dangerous situations that occurred and we need to talk about those because we need to make sure they don't happen again. And so when you go out like with a crew for a three week mission, by the end of those three weeks, you're really a high performing team because you've gone through all of those debrief, getting the incremental, getting better as a crew and you get in the habit of making sure everyone's aligned and that feedback loop gets tighter, right? In the military, we'll talk about an OODA loop, if you're familiar with that term. But everything gets tighter, we get better. And so that's why we do the debrief. So, so going. You know, I've definitely worked with Agile teams. They're like, we don't debrief, it's a waste of time.
- [07:37]
A
Some they, some don't even brief, right?
- [07:40]
B
Yeah, they just do it. Why do, why do we do planning? Why do we do standups? This is stupid. And sometimes they're right. And they're right because they would do debriefs in a way that weren't actionable. They weren't actually getting stuff done. You know, I guess there's, there's like, you can be a, what I call like a feeling scrum master. We're always talking about, you know, how people are feeling. And after a while engineers like, they want action. And so for me, if I'm gonna spend the time of a full engineering team for at least an hour to dive into how things get better, like it's actionable, right? Like it's gonna make things more efficient and make things better at the end. So I think the way to do it is a change management exercise a lot of times and you have to explain why we're doing what we're doing.
- [08:33]
A
For me, one of the cool things that Christian Bukos is the Previous Air Force pilot guest that we've had also mentioned was this concept of a mission. A mission isn't just a fuzzy term that somehow gets branded about and of refers to a, whatever random collection of actions. Right. Like your mission is also briefed, executed and debriefed. And Christian even talked about what he called the mission bubble, where you need to really focus on the actions that you're going to take and you accept no distractions during that preparation and execution of the mission. And one of the things that you added to that was that idea of having a very tight feedback loop. You talked about, like, we need to get better. Right. Like that's, that's the obvious thing. But before we can get better, we need to have that feedback loop. When you think about the teams that you work with, what are the mistakes that teams are doing that prevent them from first creating the opportunity for that feedback loop and then of course, taking advantage of it?
- [09:44]
B
Yeah, I mean, I like what you said about mission focus. We talk about that a lot in the military. But one of the benefits of being a cargo pilot on a three week mission, you're kind of off on your own is that missions can change. Right. And things can change inside a sprint. And so I, I see teams fall into either a couple of traps where they're not focused on what is it, what's the actual goal of the sprint. Like, what does success look like after sprint planning where we can say, hey, this is, this is, this is a win for us. Like this is our goal for the sprint. I'm a big fan of sprinkles, but if they don't do that, then they, they can kind of flail and not really be tight on the mission. The flip side though is they can be so focused on the sprint planning mission that they don't realize that the mission's changed, that there's higher priority things that have come in and those types of things happen. You have to be able to adapt to those things. And so that's all part of the, I think that's all part of the feedback loop. And that's why, I mean really the product owner position is a lot of times, I think, underappreciated as part of the Agile team because they should be the ones. There should be someone that knows when the mission's changed. Right. And so there needs to be that voice of the business, voice of the customer that actually relates what the priorities are and that person needs to be engaged and needs to be part of the team.
- [11:23]
A
Yeah, absolutely. And you mentioned several Feedbacks there, Right. Like there's of course the very basic idea of doing the Sprint planning and then figuring out when things have changed. That's one feedback loop. And then there's the role of the product owner. Getting feedback from the product owner during the sprint may also lead to getting the mission or the sprint content to change. Having that goal, which is a core enabler of having feedback. Right. Like if you have no goal, everything will fit. There's no feedback opportunity, right?
- [11:55]
B
Yeah, absolutely.
- [11:56]
A
So there's so many things that kind of, I would say, kind of build the opportunity for us to create those feedback loops. What do you think are the major audience obstacles that prevent teams today, the teams that you work with, from realizing that and of course then also from taking advantage of it?
- [12:16]
B
Yeah, well, there's a few things. So you're technology is complicated and hard. Right. It's just getting more. So with AI, there's. You're in a dynamic domain. Right. You know, there's Knufin diagram, which I'm a fan of. Right. To really just understand, are you complicated? Are you complex? A lot of times we're in the complex realm and feedback loops are super important in that realm. Like we, we. Things are changing and we have, we're doing feedback loops to figure out what's going on. Right. Not to just react to what's happened. And that's a different mindset shift. And so that's why alignment's so important.
- [12:57]
A
Right.
- [12:57]
B
Everyone knows really what the goal is, what the mission is. So we can like to your point, if we don't know where we're heading, then we won't be able to identify.
- [13:05]
A
You know what, what you said is actually very important. If we don't know where we're headed, we can't even detect if there are changes. Right. Like if we don't have a goal, there's no feedback on the goal because there's no goal. And one of the things that that kind of this conversation triggered in me is this idea of this constant and recursive or fractal feedback loops. Right. Like the daily stand up is an opportunity for a feedback loop and interaction with a colleague is an opportunity for a feedback loop. The showing something to the product owner is an opportunity for a feedback loop. And one of the things that I really like, and you already referred to the OODA loop, which is something that comes also from the military, this concept that you should always be observing, orienting, deciding and acting and building that into the way the team works can be quite difficult. I mean I don't know how your experience has been with your teams, but I've worked in teams where people are so focused on their tasks that even just the suggestion that the task should be interrupted for the purpose of collecting and responding to feedback becomes a high contention point, to say the least. Right. And people will say, oh, we don't want to have any meetings, we should stop the daily meetings meeting. That's another example. And I think that we are as a community kind of missing the opportunity to create that culture of feedback loops.
- [14:41]
B
Right.
- [14:41]
A
Because that's what makes us better, that's what allows us to adapt.
- [14:46]
B
Yeah. Look, the underlying core of this, what I think about a lot, is high performing teams and communication. And so what you're describing is. So there are times when you absolutely should not interrupt an engineer to tell them something's changed.
- [15:06]
A
Right.
- [15:06]
B
I mean, I'm a big fan of deep work. Every shoulder Tap is a 15 minute reset for them to get back into the game. We should avoid that. Right. I mean, especially as Scrum masters, our job should be to give engineers more time to do engineering. Right. So I can't do it. So. But there are, but there's also times when you absolutely should shoulder tap them. And so knowing when to do that and when not to do that and knowing what other people are working on and what you're working on and the bigger picture of the mission, like all of this comes together, that's really what I mean by alignment and communication. Like, like there are things in the Air Force that we over communicate on. Right. Like we need to make sure the landing gear is down and then we check and then, and then we check again and then everyone confirms it. Because if we don't land without the landing gear, we'll still land, but it's not going to be pretty. And so having that context and that ability to know what everyone's working on, what's important to the team and to the goal or the mission, and then having really the psychological, psychological safety, the ability to build those feedback loops and to communicate with each other. Like you, we're building a team of people who understand what, like, everyone's here to help, everyone's here is aligned to the same mission and we know when to communicate and when not to communicate. And that's not something you can just read about. You have to build that through reps, through retrospectives, through daily standups, through constant interactions. And so that's really how you get to a high performing team. And the difference between a high performing team and one that Isn't is really stark because of those differences, because of the ability for someone on the team to say I just figured this out and Jill over here is struggling with something similar and I know that it's worth my time to tap her shoulder and to say, hey, you should check this out. Right. Because they all know. And so building that team aspect is really important and I think that's the key. That's the game.
- [17:18]
A
So talking about teams, one of the things that you work with is to help veterans transition into tech. In your perspective and your experience, what makes them such a great fit for roles like scrum master and agile coach?
- [17:34]
B
Yeah, absolutely. So we, we hire former military officers and senior NCOs. Sometimes we'll bring them on without any, any experience in the tech world. And they all, almost every one of them performs amazing. And the reason is because they know how to, they know how to work on a team. They, they've had reps leading teams before and they understand the servant leader piece. All right. Now they do some other things too that I think the veteran aspect is really valuable. Showing up on time, doing what you say you're going to do. You know, really understanding how to take care of other people on your team. Right. And understand some people first business. Right. But, but the ability to just integrate, integrate and operate and understand, see the forest through the trees, know the mission and learn, learn how to lead teams is, I mean that's the intangible stuff. These are, these are some of those like foundational skills that are hard to get and that enable you to be really good, you know, at the more technical pieces.
- [18:50]
A
Yeah, absolutely. Many of these skills are incredibly critical for software development. You called it a people business and I totally agree. And I would add to that that it's not just a people business, it's a co creation exercise. Right. Because very often we get blinded by the word execution in the sense that it sounds like if you just do the task. But I imagine in combat, I've never been in combat, but imagine in combat very much as in software, lots of things happen all the time. We need to be checking in with everybody all the time. Things need to adapt and very often even multiple times a day. Right. Like you can't go. A very common example is to wait until the end of the sprint to bring up what might be a potential blocker. Like I deal with this even today. Many teams still do this and it's like that that's not okay. Right? Like anything that, that sounds like a potential blocker should be raised in the next daily standup at the latest, if not before. And I think that, that at least that's my expectation. I'd like to hear your thoughts. That's an expectation I have. That somebody with military experience could bring to the team this ability to check in with each other all the time. To, to have the mission in focus all the time and not get lost in the details of a single task.
- [20:17]
B
Yeah, I, I, you know, I would say the, the ability to know when to check in. Right now there, there are going to be times. Well, let me, let me give a flying example. Okay. So you know, if, if I'm on the ground, I'm flying cargo planes, all right? And so we'll take, we're a huge cargo plane and we'll take tanks and helicopters and load some really complicated cargo. And so there's people in our crew, they're called the load masters that are in the back. They're special specialists at this. And so when their heads down doing that thing, like, I may not want to interrupt them at all. Okay. There's gonna be times when it's a bad idea to interrupt people. Even if there's something that I think is important that could affect the mission. But if it doesn't affect that piece of the mission, that doesn't affect that thing. Like I'm not, I don't want to over check in, but I also don't want to under check in, right. If they're loading on a piece of cargo and I find out that that cargo shouldn't be loaded on our plane, that's a good time to check in. Right? And so the, the key, and one of the reasons I think veterans are fit really well in these agile teams is they know when to do that, right. When to let people do work and when to check in. Now you're not always going to be perfect, but you should be striving to know that like we shouldn't over, like we shouldn't have four stand ups a day on average for a team, right. But we might have to have two if there's a huge bug issue. I mean you have to have the ability to have the, you have to build the context, right. You have to understand what is it our team does, what's the goal of the mission, what is everyone else doing. That's why daily standups are so important. And to your point about the blockers. Yeah, absolutely. Like there's times when people don't want to speak up. Right. And so part of, part of even the retrospectives I think is Building an actual culture of communication, of comfortability with people. Like, there is a lot of value in taking the team out and going out to happy hour or doing events. Right. I mean, because you really, that's why you do it. You want to build it so people are comfortable speaking up if they have an issue. And you know, it takes time and effort to build that type of culture.
- [22:47]
A
Absolutely. Talking about culture, you guys work with veterans. How do you onboard them? Like, how do you prepare somebody with military experience to start working with an agile team or an agile organization?
- [23:01]
B
Yeah, well, so, I mean, one thing I think is important is the veteran community is a cross section of society, Right. And so not everybody that's a veteran is going to be a great Scrum Master. And there's certain jobs out there that we might, we may target over others and, but we really go through a screening process to find the right type of person who's going to be successful in this type of role. And then onboarding, you know, if you're coming directly out of the military, you spent, in my case, when I got out after 10 years of, or 12 years of active duty service, I had no idea what to expect. Like, you just don't know. And you know, you're capable of doing stuff, but you don't know the domain you're, you're moving into. And, and so when we bring on somebody new, you know, we have our own, we have multiple recruiting sessions with people, right? And we make sure that everyone, that everyone's on the same page with what it is we do. We, we have our own internal training program to teach them how we operate in Agile, how we do scrum, how we do program management. You know, we give them, we give them as much information as possible. And then when somebody joins, we have, assign everybody a wingman. And so everyone has a dedicated person that they check in with regularly to bounce ideas off, to ask questions. And so for us, we operate as a team for our clients. Everybody is communicating, everyone's on the kind of on the same page with like, hey, here's what we're doing. And so, you know, that's partly, partly, I think why we've been so successful is because we have this almost military unit culture that helps kind of like transition into the private sector. Now I could talk about some. One of the bigger struggles that I
- [25:08]
A
see,
- [25:10]
B
you know, is, is really around. I think the military culture drives leadership as a core component through the entire, through the entire ranks. We talk about it all the time. If you're an officer, senior nco you've been to leaders dedicated leadership training. You've. It's, it's on your performance report. It's something we just talk about all the time in the private sector. I feel like that's lacking some. And so there's just a baseline expectation from people that people in leadership positions are going to act a certain way because almost everyone in the military has these kind of baseline things you just wouldn't do in the private sector. That doesn't always exist. So that can be a real struggle.
- [25:58]
A
Absolutely. For those tech hiring managers who might be on the face about, on the fence for, pardon me, about hiring someone with a military, military background, what would you say to them?
- [26:10]
B
I, I'd say if, if you're, if you're on the fence, you should, you should lean towards. Yes. I don't, I'm not going to say just go out and hire a veteran. Absolutely. And because you don't know what your context is, you don't know the domain and if you're not set up to support, may not line up. Right. But I do think there are certain roles that are really like the Scrum Master role for me. I don't understand why every, every junior officer getting out of the military doesn't just get automatically hired as a Scrum Master. I mean like if you were to say what's the what, what do we want a Scrum to do? And what does a military officer do? A junior military officer, it's like line for line. And, and so I would say if you're on the fence, lean towards hiring because you're going to get a bunch of these intangible skills that are really value add and they're, they're hard to build outside. Yeah.
- [27:18]
A
And of course people with that kind of training and, and experience already come with many years of experience. Like you did. Right. Like 12 years of active service.
- [27:30]
B
Look, and, and you know, there's, I mean as a passion, a passion topic for me, so I can talk about this for a long time. But you know, there's the ability to stay calm. Right. There's ability to, you know, to not over talk. Right. There's the ability to, to really listen to understand what's going on and. Yeah, and I also just think the integrity aspect, the ability to just the amount of grit that you have from even just going through basic training is something that is just so needed in the private sector, especially in the software development space.
- [28:10]
A
Yeah, I totally agree. So we're close to the end, Nate. But before we go, what's one resource could be a book, a video, a podcast, a blog that you'd recommend for someone who wants to go deeper into understanding this kind of leadership that we discussed today and also the importance of having a mission that is the goal for the Sprint and so on. What's one resource you could recommend?
- [28:38]
B
Yeah, I mean I'll give you two that I'm a fan of. I think Stanley McChrystal's team of teams is a great book and I think just understanding the importance of the team dynamic and as look, everything with this, with AI coming out is a huge change management exercise and teams are really going to have to, the higher performing teams are going to be the ones that are the most successful and organizations are going to be more modular, they're going to be more, less top down hierarchy organization and more of a team bottom up approach. And so understanding, especially if you're a leader in the software development space, understanding how teams and teams of teams is a, is a great approach to understanding team dynamics. And then the other book that I'm a big fan of is the Extreme Ownership by Jocko. Well, once Jacob, let's call him Jacob. And, and that is like, you know, one of the things that I think is so it's, it's one of the things that we do at the core at our company. It's really part of our culture. He's like, we don't just say it's not our problem. So I see this, I see this. A lot of Scrum Masters, Scrum Masters will say I'm the team process person, all right? And my job is to set the meetings, run standups, do retrospectives, right? And for me, I think to be a good Scrum Master, you have to take ownership of the team's execution. Okay? Now that means if the product requirements aren't good, I think it's a Scrum Master's job to go out and try to help. You should take ownership of that. If QA is the problem, take ownership of that if the release pipeline's a problem, if it's a stakeholder communication issue like you should, you should be the vessel and ownership of the entire process of value delivery. And having that mindset of extreme ownership is so refreshing on a software development team because you'll get into a retrospective. We had this goal for the Sprint, we didn't hit it. And then all of a Sudden here's the 10 external reasons that are completely out of our control and we can spend an hour complaining, but when you reframe it as, okay, here are Things, let's say we can own. What can we own about this? Right. Like, hey, the stakeholder made a stupid decision. Well, did we give the stakeholder the right information to not make a stupid decision? Like, did the stakeholder make a great decision off of really bad information we provided? Right. And, and so the I, the idea of being of taking ownership of a team, of your task, of the outcomes is one of the things that I think drives team resilience and a continuous improvement mindset.
- [31:47]
A
Absolutely. And Nate, before we go, where can people find out more about you and the work that you're doing?
- [31:55]
B
Yeah, so LinkedIn is the best way to find me. So you can hit me up, connect with me on LinkedIn for sure. Our website's form100consulting.com. There's a lot of good information there, you know, especially a lot of stuff around like, hey, how do you actually implement AI into your business processes? Those types of things. And yeah, that's probably the best two ways. You won't find me on TikTok.
- [32:22]
A
Absolutely. We'll put the link to those on the show notes and everyone. Why not? If you have follow up questions, just hit up Nathan on LinkedIn and continue the conversation. We learn as a community. Nate, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
- [32:39]
B
Yeah, absolutely. Thanks for having me on. It's been great.
- [32:45]
A
All right, 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. And 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@scrummastertoolbox.org membership because listening is great. It's important. But doing it together, that's next level. I'll see you in the community. 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 their work. Remember that sharing is caring.