← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
When Overconfidence Breaks the Trust You Worked So Hard to Build | Nate Amidon
00:14:35
Loading summary
Transcript23 lines
- [00:02]
A
Hello everyone. Quick heads up before we start today's episode. The Global Agile Summit is happening on May 4th. Yes, May 4th. And even with a big blowout Star wars party, you have to join. It will be online and it's like always free to attend. We have four tracks this year that I'm really excited about and I think you will too. Stick around to the end of the episode to know what they are. If you want to check it out already now you can check it out at bit ly globalagile 26. That's the numerals 2 and 6 at the end. So one more time, that's bit ly globalagile 2, 6, all one word, all lowercase. And 2 and 6 are the numerals 2 and 6. So stick around till the end of the episode and I'll tell you what's in store. But for now, on to today's episode. Hello, everybody. Welcome to one more week of the Scrum Master Toolbox podcast. And this week, joining us from the US is Nate Amidan. Hey Nate, welcome back. In your case,
- [01:16]
B
pleasure to be here.
- [01:18]
A
So for those of you who haven't yet listened to Nate's episode, check it out. The link is in the show notes. He was think about a few weeks back, I don't recall exactly, but a few weeks back he was with us to talk about how he learned to be a Scrum Master by starting as a combat pilot. He's the founder of Form 100 Consulting and a former Air Force officer and combat pilot, pardon me, turned servant leader in software development. Nate has taken the high stakes world of military aviation and brought its core leadership principles, clarity, accountability and execution, into his work with agile teams. And that's what we're going to hear all about it. Today is Monday, so we're also going to hear how he drove straight or flew straight into a mountain. But we'll get to the failure story in a minute. Nate, first tell us, how did you end up becoming a Scrum Master?
- [02:19]
B
Well, first off, I never flew into
- [02:21]
A
a mountain, as proven by the fact that you're actually here talking to us.
- [02:27]
B
Wouldn't say it hadn't been close. Right. But never, you know, but we always say that impact with the ground has 100% kill rate. So yeah, don't go into the ground. Yeah. So how to become a Scrum Master? You know, I started out, my first job out of the Air Force was, was as a vendor at Microsoft and I was doing program management work and they were spinning up a new software team and I became Friends with the senior engineer that was running this, it was an internal software project and he started talking to me about Agile and how they operated, how they did things because I was in a more traditional program project management type position and I was just frustrated with how nothing got done. It was a lot of meetings, a lot of talk, a lot of, you know, we'll work on it and then we'll get this piece. And everything was, it just, was, it just felt, it didn't feel like what I was used to in the Air Force, which was let's just get things done. And so as I learned more about how they were operating in Agile, how they broke things into small chunks and user stories, and I just became fascinated with it and it really felt like it's how we operated in the military. I actually found a way to get the senior engineer to recommend me to be the team Scrum Master. I went and got a certified Scrum Master certification. And then, yeah, and then I just dove right in and I loved it.
- [04:16]
A
And we're going to hear how much you loved it right next. Because of course not all our attempts to be successful yield success. Sometimes we ourselves, we also bump into the proverbial but thankfully metaphorical mountain out there. So tell us that story, Nate. A story of you as a Scrum Master kind of flying against a solid object.
- [04:43]
B
Yeah, I mean my whole career, both in aviation and in the agile space and software and running a company, all of them has just been a series of failures. It's a non stop of you're constantly tripping and. Yeah, and so one of the biggest failures I've had, and I've had a lot of them when I was still pretty junior Scrum Master and I was working on a, on a software team that was building an internal internal application and I'd been working with them for a while and the team was really starting to click. And one of the things we like to do is always build trust first and focus on building trust with the team. Know, hey, we're here to help, we're here to give engineers more time, we're here to make things more efficient and, and if it doesn't make sense, we don't do it. And, and so one of the things that team was doing was, was tracking story points and then reporting it up and velocity. And that was a problem because velocity is not a great metric for how well your team is doing. And so I, I remember I, I'd switched the team metrics to, to, to their leadership, to predictability instead of velocity and so because that was something we could control, we could control how well our user stories were and how well we broke things down and how well we executed on the plan. Now the plan is going to change. And sometimes, you know, you're going to have higher velocity sprints than others. But, but that was a big win. And I, and so I was overconfident. And, and I, and as I sat there, I was like, well, okay, predictability is great, but if we plan 20 story points and we complete 20 story points, we might have swapped out the whole sprint. Right? We might have dropped 20 points out and added 20 points in. And that's going to cause a lot of churn. And so I proactively came up with a metric to help track, you know, churn of a sprint. And I thought, and I thought that was good. And because I had built so much capital, I just kind of rolled it out. Like, I didn't go talk to the engineers and be like, you know, hey, what do you, what do you think about this? And the pushback I got was pretty wild because I didn't want. The pushback was like, hey, if I add more things to a sprint, that shouldn't be bad. Right? Like, we're trying to get more done, it should be good.
- [07:15]
A
And even if you change stuff from a sprint, it should be okay too. Right? Because that's the goal. Adaptation.
- [07:22]
B
Right now it could also not be okay. Right. It could be that you're just having a ton of churn in the product,
- [07:28]
A
totally lost and don't know where we're going. That is also a possibility. Yeah.
- [07:33]
B
Right. But I didn't think about the edge possibilities. And so I got a ton of pushback and I took a trust hit from my team because I didn't come to them first and be like, okay, I was just solving a potential problem without actually identifying a real problem to solve.
- [07:51]
A
Or, okay, so I see what you're saying and I agree on the face of it, it sounds like that as well. But when I think about it, I'm also thinking that you might actually have been solving a real problem. It's just that the team didn't know what problem you were trying to solve and they might not have agreed with it in the first place. Right?
- [08:12]
B
That could have. Yeah, no, absolutely. And so what I learned from that was not necessarily that that metric is a bad metric, but I learned that if you're going to be a servant leader to the team, you have to really identify and get buy in from the team on the problem. You're trying to solve and that your trust quotant with the team is the most important thing as a Scrum Master, if you want to affect, if you want to affect change and make things better, then you have to build that trust with the team.
- [08:45]
A
And I really love that. Build the trust and keep the trust with the team. I'm working with a team where their Scrum Master has probably out of the best of intentions tried to push a bunch of stuff to the team and now when I hear the team's comments in their anonymous and one on one feedback is we're not listen to the stuff we care about. It seems the Scrum Master doesn't care about. It's too many changes at the same time. Is that also a little bit what you felt was happening with that team at the time?
- [09:22]
B
Yeah, in a way. So our approach to being a Scrum Master, when we bring in a contract Scrum Master to a team, our approach is to do nothing for as long as possible. We want to come in and like never pass up an opportunity to not talk in a meeting. Like the first couple of weeks is so important when you come in as a new Scrum Master on the team because you don't have any context, you don't know who's who on the team. You don't know what they've already tried, what they've already dealt with. The most important thing you can do is let them know that you're not going to make it worse. Because so many teams have had had experiences with bad Scrum Masters and so I had gone through that's. That's always been my approach whether it's been military leadership or Scrum Master or product or any, any position. And, and so I had built up the trust quoting but then I didn't think about like continually maintaining it if that makes sense. And, and so I wasn't throwing a ton of things on them. I just, I just missed the step of like hey, I'm helping the team and I'm not the external person directing the team. And so that's. That mindset made me really understand that like look it, this is a collaborative thing. We're all in a Scrum together and we need to act like that. And it also let me know, look, you know, I'm, it makes me super nervous about metrics.
- [11:04]
A
Right.
- [11:04]
B
And I think there's a whole thread we could talk about just on and
- [11:08]
A
we probably will during this week. Right?
- [11:11]
B
Yeah. But I guess, you know, for me though, I think the key to that failure was look, you're there to help the team and so don't try to solve a problem that doesn't exist.
- [11:26]
A
Yeah, absolutely. Even if you feel or believe it exists, the team also needs to. Otherwise they will feel pushed, unheard, and so on and so forth. That was a beautiful story. Thank you for sharing that with us, Nate.
- [11:40]
B
Sure thing.
- [11:44]
A
Hi there friends. Thanks for sticking around till the end of the episode. So let me tell you what's coming on May 4th. We're running the Global Agile Summit. It will be online and I want you there this year. We have four tracks and each one is built around real conversations with practitioners. No slides, no keynote theater, just honest interviews with people doing the work, just like you. The first track is AI in organizations where practitioners show what actually works. No hype, just AI that makes your Monday better. Happy Monday, everybody. And then we have the people track honest conversations about putting humans at the center of how we work and keeping them there. And third is Agile in Construction. And yes, I really mean brick and mortar construction. Lean and Agile. Actual job sites. Field leaders removing waste. Teams transforming how buildings get built. Stay tuned for what I think will be a super track on Agile in construction. And the fourth track is Agile in Gaming. How game studios ship without burning out. Agile Inside the Creative Pressure Cooker. Over the years we've had more than 12,000 participants since 2017, the time of the first summit organized with the podcast. And this year we're making it easier than ever to join. You can register for free and get access to the summit sessions live during the event week. That's May 4th to May 6th. Or you can grab the Practitioner Pass and get immediate access to last year's keynotes from Jurgen Apollo, Gojko Adzic and Mirete Kangas right now, even before the summit starts. So grab your Practitioner Pass and start learning today. Head on over to bitly globalagile 26. That's 2, 6. The numerals 2 and 6 sign up and I'll see you on May 4th. And one more time, here we go. Bit ly global agile 26. All lowercase, all one word and 26, that's the numeral 2 and the numeral 6. I'll see you on the conference floor.