When Leadership Says "Just Make It Work" in Agile | Renee Troughton

Summary

---

Podcast Summary: "When Leadership Says 'Just Make It Work' in Agile"

Podcast: Scrum Master Toolbox Podcast
Host: Vasco Duarte
Guest: Renee Troughton, Agile Coach
Date: October 13, 2025

---

Main Theme & Purpose

In this episode, Vasco Duarte interviews Renee Troughton, a veteran Agile coach from Australia, about real-world challenges Scrum Masters encounter when organizational leadership pushes for unrealistic delivery ("just make it work") despite evident risks, anti-patterns, and cultural barriers. Renee reflects on her own failure in such a scenario, exploring the consequences, lessons learned, and the crucial importance of courage, transparency, and role clarity in Agile teams.

---

Episode Highlights and Key Discussion Points

Renee’s Early Agile Journey and the “Iteration Manager” Origin (02:07–04:00)

• Renee fell into Agile almost by accident in the early 2000s, during a period when Agile was still in its infancy and only two books existed on the topic.
• The bank she worked for needed someone to experiment with "this Agile thing,” and she willingly dove in.
• Naming of the Scrum Master role:
  • Due to cultural fit, “Scrum Master” was rejected by leadership in Australia. Renee coined the alternative, “Iteration Manager”—a title still used throughout Australian Agile circles.
• Notable Quote:

  “For those of you who've heard, Australia keeps calling Scrum Masters Iteration Managers. It actually came from me back in 2003 because we just couldn't let the term fly.”
  – Renee Troughton, (03:15)

Fail Monday: The “Just Make It Work” Story (04:21–09:46)

• Setting: ~10 years ago, Renee worked with a superannuation company managing a legislative-mandated tech rollout.
• Challenges:
  • Unchangeable deadline due to legislation.
  • Sales teams kept introducing bespoke client requirements, unaware or unconcerned with the project’s true capacity—and without consulting delivery teams.
  • Quiet, disengaged team culture with communication dysfunctions (e.g., emailing questions to people sitting beside each other).
• Delivery Reality vs. Leadership Expectation:
  • Renee, after two sprints of establishing velocity, recognized hitting the deadline would be impossible, even projecting a three-week delay.
  • When she raised the risk, the CIO responded, “Just make it work,” offering no practical solutions but expecting certainty and confidence.
• Mythical Man-Month Realization:
  • CIO offered more people, but Renee pushed back, citing the classic software adage that extra people so late would slow things down, not speed them up.
• Key Moment:

  “He said, just make it work. Didn't give any advice on how to make it work. ... 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.”
  – Renee Troughton, (07:12)

• Burnup Chart Fiasco:
  • Under pressure, Renee made a “pretty” but misleading burnup chart in Excel to show projected on-time delivery, despite knowing they would miss the deadline.
  • The CIO used this as “proof” for clients, and the team ended up in a waiting game—hoping another company would be first to admit missing the date so they wouldn't take the blame.

  “I just made this beautiful Excel chart to show us that we were going to hit the date when in reality we weren’t.”
  – Renee Troughton, (08:13)

Consequences: The Cost of Hiding Reality (09:46–11:27)

• Game of Chicken:
  • Vasco notes this is a recurring problem in software—schedules become a game of “who admits failure first,” thereby rewarding opacity instead of transparency.
  • Leadership’s insistence on visible confidence pushes teams to hide the truth, undermining Agile’s core value of transparency.

  “We are actually rewarding hiding information through this game of chicken, as you called it, right?”
  – Vasco Duarte, (09:58)

• Agile’s Unlearned Lesson:
  • Despite modern Agile adoption, many companies still prioritize appearance over honest progress reporting, missing the point of iterative, transparent delivery.

Lessons Learned: Courage and Role Clarity (11:06–12:22)

• Renee’s Reflections:
  • If she could do it again, she’d refuse to fake evidence and push for the business to own the true risk.

  “I think obviously 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 CIO for you to own this problem. And I don’t think I did that.”
  – Renee Troughton, (11:08)

• Ownership of Business Risk:
  • Vasco clarifies: Engineering can signal delivery risk, but it’s the business' role—not delivery—to manage impacts or negotiate external realities.

  “It ends up being a business decision ... certain responsibilities are not ours—meaning the development team’s, Scrum Masters, Agile coach, project managers—they are somebody else’s; meaning, the business’ responsibilities.”
  – Vasco Duarte, (11:46)

---

Notable Quotes

• On role naming and cultural fit:

  “Australia keeps calling Scrum Masters Iteration Managers. It actually came from me back in 2003.”
  – Renee Troughton, (03:15)

• On leadership’s unhelpful directive:

  “He said, just make it work. Didn’t give any advice on how to make it work.”
  – Renee Troughton, (07:16)

• On transparency vs. gaming the system:

  “We are actually rewarding hiding information through this game of chicken... 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.”
  – Vasco Duarte, (09:58)

• Personal takeaway:

  “I wouldn’t fake a burn-up chart. I think I’d be a bit more courageous.”
  – Renee Troughton, (11:08)

---

Important Timestamps

• [02:07] Renee’s entry into Agile and the origin of “Iteration Manager”
• [04:46] Introduction of the “fail Monday” story
• [07:12] Mythical man-month and leadership pressure
• [08:13] The burnup chart ethical quandary
• [09:46] Vasco’s reflections on schedule-driven dysfunction
• [11:06] Renee’s hindsight and lessons learned

---

Summary Takeaway

This episode provides a candid, insightful look into the organizational dysfunctions that persist even within “Agile” companies—especially when delivery teams are pushed to “just make it work” against insurmountable odds. Renee’s personal story underscores the pitfalls of succumbing to leadership pressure at the expense of truth, and the critical need for courage, honesty, and insistence on proper role boundaries in the Agile journey.

---

Transcript

[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 war free 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 this 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 one more week of the Scrum Master Toolbox Podcast. And this week, joining us from beautiful Sydney in Australia is Rene Throtten. Hey Rene, welcome to the show.

[B]

Hey Vesco, thank you for having me.

[A]

Absolutely. So Rene is one of the most experienced agile coaches in the Southern hemisphere with over two decades of transformation experience across banking, banking, insurance, pharma, real estate, and probably a bit more by now. Since 2002, she's helped organizations to go digital, tackle systemic issues and deliver value faster. She's passionate about cutting bureaucracy. And Renee champions a return to humanity at work, which I'm sure will shine through in our conversation during this week. So to get us started, Renee, tell us a little bit more about yourself and how did you end up becoming a Scrum Master?

[B]

Sure. So, you know, I sort of fell into the job, which was interesting. So back in 2002 or 2003, I was working for a smallish bank at the time and I had been doing some project management work for them. I was a little bit bored and they said, hey, we're going to try this agile thing. So if you recall, that was only Agile, was only like a year or two old at that stage. And I said, look, I don't know what this agile thing is, but I'm happy to give it a go. There were two books on agile at the time and that was it. I read those two books and then I became effectively a Scrum Master straight away for a number of effectively digital spaces. At that particular point in time it was interesting because I thought very early on would the term Scrum Master here, work inside of Australia because at the time it was first organization that was going really hard at Agile back then. And I sort of sense checked with leadership, can we have this role called Scrum Master? And the feedback was no, that's a terrible name. And so I ended up calling it Iteration Manager. So for those of you who've heard, Australia keeps calling Scrum Masters Iteration Managers. It actually came from me back in 2003 because we just couldn't let the term fly.

[A]

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]

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]

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]

Definitely.

[A]

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]

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]

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]

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]

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]

Right, Exactly. Yeah.

[A]

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

[B]

No worries.

[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 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 [e-mail] 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.