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.
