A (3:34)

I remember having a chat with Ken Schwaber at the time and asking why did they come up with the term Scrum Master? And he said something to the effect of it's a, it's a role nobody would want and nobody would get status from. That's why they chose it.

B (3:53)

Yeah, I heard something very similar, which is no one in their right mind would call this role a Scrum Master. So we'll call it that.

A (4:00)

Exactly. This of course speaks to the fact that as expected, the first Agile people out there were pioneers. They were not really trying to fit into the status quo. And that's why Agile came about. Right, because of that ability to think differently about how to develop software.

B (4:21)

Definitely.

A (4:21)

Now, through all of those years, the first few years or maybe even later, we all go through moments of difficulty as Scrum Masters or as Agile coaches. And today's fail Monday here on the podcast. Rene. So let's dive into one of those moments. Share with us a story of a moment where you tried your best, but at that time, as so often happens, the best just wasn't good enough. Tell us that story.

B (4:46)

Yeah, so it was at least a decade ago. I was working at the time for a superannuation organization and they were doing what if what is in Australia a super stream rollout. So that was a standardization of how we processed our superannuation payments in Australia, both coming in and out and being able to automatically use an API that the government supplied to actually process that information. Now the organization I was working in, because it was a legislative change, it was a clear date that we had to drive for, which is already the start of a bit of an Agile anti pattern. And so I went into this particular team both as a coach and as a Scrum Master and a few other things as well, to be honest. And very early on it was funny actually the first two days I was there, I was sort of checking how much people knew Agile they were talking about and so forth. And it was a very quiet floor. And as you could imagine straight away, that's a bit of an anti pattern as well. And so I actually even had someone who was literally beside me send me an email asking me a question and going, just ask me the question. And so there was obviously a lot of work inside of that team to get them working. Agile, finding out what the backlog was looking at that day, starting to build up a trajectory around can we even do this? And so I took two sprints to try and get an established velocity and we estimated the backlog of everything else that we had to go. And it was very risky. The date was very risky. And I thought, oh, it's going to be tight. I thought we could do it. So we continued down that pathway of developing the work that we needed to do. It was my first time working in an organization that had a separate sales group and they were going out to all these different other clients and going, yeah, we can do this thing for you. And every single client was after something very unique and bespoke and the salespeople kept selling them, yeah, we can do that. And in reality we had a timeline that was unmovable and a scope that we could barely fit in to the time itself. And yet we kept having brand new requirements coming in. And I wasn't in these sales meetings so there was quite a bit of anti patterns around that. So I tried to push back on sales and say, no, you need to have me in these discussions so I can actually say whether this is an easy change or a hard change. At the end of the day it was very obvious. The sales kept doing their own thing. We weren't going to hit the date, it was a legislative date. And I said to the CIO at the time, we're not going to hit this. In fact, we'll be, I can actually tell you we're going to be three weeks late. What do we do? Do we tell the government? Do we do it to tell the group of all the different implementers you know what's going to happen? And he said, just make it work. Didn't give any advice on how to make it work. He wasn't going to throw more. He actually did offer it in fairness to throw more people at it. And I said, I can't throw more people at it. With five weeks to go. That's just not going to happen. Because you and I both know there's like a mythical man month around. Adding extra people that late will actually make you go slower. And so I went through everything that we could possibly do, obviously spoke to the team themselves around what we could do. We couldn't come up with anything innovative at the end of the day. And like, I projected out very early on that we're not going to make it. Gave that feedback and the constant feedback from the CEO at the time was just get it done, just make it done. And then I just realized that nothing was going to make him happy. I couldn't actually change anything. And he said, I need you to demonstrate the confidence that we're going to get there. And so, I mean, back in those days, we generated velocity burn up charts manually using Excel. And so I just made this beautiful Excel chart show us that we were going to hit the date when in reality we weren't. And he goes, great, now I can prove to all our clients that we're going to hit the date. It's sort of like I was, I was like having kittens going, we're not going to hit this date. He goes, but I've got, it's going to happen, I've got the proof now. And so in reality, we played a game of chicken, waiting for another implementer to put up their hand first to say, no, we're just not going to hit the date. And everyone else had to then give leeway to that particular implementer and that time came out. So I sort of feel in retrospect that there was a number of things that I did wrong, but it was also very interesting and challenging environment. As a Scrum master.

A (9:46)

Yeah, that game of chicken that you referred to is actually something that I feel we are always playing when we use schedules or make scheduled promises, right? Like at the end of the day, somebody will be late. It's software. Somebody will be late. So we are actually rewarding, hiding information through this game of chicken, as you called it, Right? Like through this. No, no, no, Just, just act as if you're gonna make it. Somebody else will raise their hand up first and say, hey, we're not going to make it. And then it's their fault, not your fault, that we're late. And this is for me, one of those aspects of software development that even though we adopted Agile, I mean the industry overall started adopting it in the early 2000s, but it's 2025 as we record this. Probably by now a large percentage of companies claim they are using Agile, but we haven't yet understood the very basic IDE idea of Agile, which is to create transparency to progress, not to deliver on unrealistic deadlines. So if you had the opportunity to go back and kind of relive that story again, Rene, what would you do differently?

B (11:06)

Yeah, I mean, I thought about it a few times. I think obviously I wouldn't, I wouldn't fake a burn up chart. I think I'd be a bit more courageous in that conversation and say, look, I've done as much as I possibly can. It's now up to you as a CIO for you to own this problem. And I don't think I did that. Yeah.

A (11:27)

And that allows then, and this is actually a good point for the CIO to own that problem because as development organizations, we can only say, hey, we think we are on time or we think we're late. But ultimately it ends up being a business decision. Right. And when the business says, no, no, no, just, just give me a burn up chart that tells me you're going to be on time, they're kind of reversing the responsibility. It's a business decision to react to being late. It's the development team's responsibility to say if and when we are late. Right. Like, and, and I think it's very important for us to kind of draw that line very clearly and acknowledge that certain responsibilities are not ours. Meaning the development teams, Scrum masters, Agile coach, project managers, they are not our responsibilities, they are somebody else's. Meaning the business's responsibilities.

B (12:19)

Right, Exactly. Yeah.

A (12:22)

It was a great story. Thank you for sharing that, Renee.

B (12:26)

No worries.

A (12:30)

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 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.