
Loading summary
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 our success. Thursday, the big question of the week. This week it's all about agile in construction with Felipe Engineer Manriquez. Hey Felipe, welcome back.
B
Hey Vasco, good to be back?
A
Absolutely. So we'll talk about success in a second. But first, of course, retrospectives are a huge aspect of what agile is about. Building that learning feedback loop that eventually leads to, we hope, Kaizen. So that's lean and agile right there in that one ceremony. So talk us through. How do you introduce the whole idea and the practice of retrospectives in construction and what's your favorite format?
B
Yeah, I actually start with something that people know. So I relate it to what people already recognize and that is this concept of a postmortem. Most construction project teams and design teams have experience with at the end of a project when it's done doing a postmortem review. Lessons learned, it's famously called nowadays. Lessons learned. I was actually with the team this morning and we were, we were saying that we need to do a lessons learned because this is important for us and the team is just now transitioning from design phase to the construction phase. Like they're only maybe three months into construction and they have another, call it 15 more months to go. But I've been heavily influencing the team and they say we need to do a retrospective and they actually use that word retrospective and lessons learned because we're changing the vocabulary in the industry and we're starting to pick this up. So my favorite way to do it is to take what they already know about post mortem. And I tell people like where post mortem comes from is a surgical team has killed the patient and they're dead. And the patient is literally on the table and they've gathered the nurses and the doctors and they're standing all around the dead body and they're talking out loud the mistakes that they made that led to this person being killed. And people think like, this is. I don't want to get all morbid on you, but this practice, this is the third leading cause of death in the United States is medical mistakes. Third leading cause of death. And it's not a trivial number. And you could do your own Googling and research and see the numbers. It's. But this is what these things happen and hurt people. And in construction projects, the mistakes we make also hurt people and cause massive frustrations and sometimes bodily injuries. So this is like a very serious thing, this retrospective and this concept that I bring in. The easiest one is this postmortem concept. When I often ask people, have you been through a postmortem? 99% of the people raise their hands and say yes. I say, okay, let's do an easy one. I call it. We'll do a start, stop, keep exercise. And because we're going to do this post mortem on a cycle, we're going to do it regularly. And so, like the team I was talking about this morning, they committed to doing it monthly. So it's like the biggest sprint possible for them. It's the one month, four week sprint. And so every month we're going to come together and we're going to look at a start, stop, keep. It's very simple, very effective start. What things do we need to start that we're not doing now? That's going to make things better so that we don't have those errors that we've experienced on past projects? Stop. What things should we no longer do that? Don't serve us, do not add value and continue. What are the good things that we're doing that we want to not stop doing and maintain? Because they're helping us have a good, stable output that we like. And we do those things one at a time. You don't answer them all at the same time. You do them one at a time. We use silent brainstorming technique so that people can have time to think and answer these questions. And then we put them visually in front of them, either on a digital display or an analog, a big whiteboard. The team I'm working with now wants to do it analog. So we're going to do sticky notes. On a whiteboard which I'll then digitize and use AI to help categorize. And I did this recently on a huge project that was. The team had recognized they were failing. And we did this with 60 people, 60 leaders of companies, from project executives to directors and PMs and we did it. It took us eight hours. But this was like they had worked for four years on a 10 year project and hadn't done this before. So it took a day. Now for the other team, it's a, it's an only, it's only $95 million project and it's going to take us an hour to go through the exercise because they're switching from a year of design to now they've got a year plus of construction. And so for in the retro, I love like in the scrum best practices. It's always said that if your sprint cycle is about a week long, want to allocate like 45 minutes for this and you just use algebra. If it's two week sprint, almost two hours. If it's a month, almost half a day. And like even the team I'm working with this morning because they're thinking about this and they're actually pre writing the start stock keep activity, I feel totally confident that an hour is plenty of time plus I'm facilitating it. So I want to make sure I hit my time box.
A
Absolutely. And time boxes are very important because we don't want the discussion to fall into this cycles of finding a problem, blaming someone, finding a problem, blaming someone and never actually getting to action. Because the goal of course is to get into a concrete action that we can take home and improve our future work. Of course we do this retros because we want the teams to succeed and of course we want ourselves to succeed as well. When you think about yourself as a scrum master for this kind of projects in construction, specifically, what does success look like? What metrics or sign do you use to know that your work is having a positive impact?
B
Yeah, I use the hardest one to measure team happiness. I go right, right away, I go to the subjective type of response and I tell people. I just talked about this on my own podcast like a couple weeks ago, I said I'm like a human thermometer where I can sense emotion. Like because of all the trauma I've had working in the construction industry and it's been traumatic. I've had days Vasco where as I was driving home in the early days of trying to apply these concepts that my frustration level was so high that I had to call my spouse and just tell them how bad my day was. And I would pound the steering wheel with my hand as I'm driving to almost break the steering wheel off my car. That's how high my frustration was. I've never had a day like that since. I've adopted all these things and made these changes, but that's how bad it is. And I was experiencing that as a young project engineer on a job. And so I'm very sensitive to people's emotional states. And so I use this, this idea of the how happy is the team? As a proxy for success. And, and it's actually we, we measure this now systematically using this concept of team health. We do periodic surveys with some of the larger projects and we, we use a series of questions to determine like, where are people frustrated? Where are people happy? And so I always focus on those really subjective measures where people have to say how they feel now. And this is something that I've trained myself to recognize within five minutes of being with the team. And so I tried never to make observations from databases alone or from power BI reports or any type of digital dashboards, which I know a lot of executives love. And they put way too much confidence in. I put way more effort on physically being with a team. And so when I'm physically with the team, I can tell, is this a stressed out team? Is this a team having fun? That's and all that. And I'll tell you, like the teams that are having fun and are lighthearted, making jokes, these are high performing teams almost 99% of the time. But the teams that are overly sarcastic or too quiet, they're burning out. And then you can, you can discern that quickly. So now, I mean, now that I'm saying it, people are thinking about how's my team right now? If you had to think about your team like in the last, if you were with your team for an hour, in that hour you can observe are we stressed or no. Stressed, light hearted, having a good time. And like just do it subjectively, like a Likert scale. On a scale of 1 to 5, how happy are you? Like, I used to tell this to one of these estimators I was working with. I was like a scale of 1 to 5 or 5 is you, you wish you were working at Google, you're getting massage at work while you're coding. And he was not a coder, he was an estimator. Or one is like, you want to jump out of the window, where's your stress level now? He's like. And he's like, it's a two when we first started. So. But he was very quiet. If I didn't ask him, I wouldn't never know that he was stressed out. Because a lot of people just internalize it in construction. That's what most people do is they push it down and internalize it. So I use the subjective measures of how happy they are as a proxy and I just do a simple likert scale of one to mentally. And I just see like five is extremely happy and one is like very unhappy. Like they're going to quit, they're going to walk away from this project and try to see where they are in that spectrum. And from there then I can tell what kind of impact I'm going to have. And then the metrics always show like the schedule improvements happen as they move closer to a five. Whereas is it like extreme happiness? It's almost like what is that? That extreme happiness? I. It was like a Nirvana album. Nirvana. Yeah, it's Nirvana. When you reach Nirvana, that's like a five.
A
Yeah, that's never gonna happen. At least not while you're working.
B
Not while you're working. Yeah. Like people don't laugh at work. I was on a project where the stress was so high I went to. I had not seen this person for a long time. I work on a lot of projects at the same time, so I'm working a portfolio. And one of the individuals I hadn't seen forever, you know, gave me a hug. And then another person commented to me, like, we don't give hugs in construction. And I found out that person's stress was they were like at a one, like they were ready to walk away. And so like I intervened of course, you know, because that's what I meddle. I'm a metal meddling person. A successful Scrum Master medals appropriately. That's my mark of success as a Scrum Master is like, you get involved, we run to things, we don't run away from things and we deal with problems head on. Like I see a problem, I'm just like, oh yeah, this is another thing to work on. Like I addicted to problem solving. And so I think that's, that's a good counter measure. Like first, first thing I do is just understand like what's their current state? And when you do that and let people talk. I was even. I was teaching my son. I taught my son to be a Scrum Master and he's working even more now with in teams. He's now he's 16 so when, when you're a little kid, most of the stuff you do is individual. And he's in high school now there, he's in that period where they're switching to team focused things, where things are done in groups. And I was telling him like, the most important thing that people want, and we know this from our Scrum training, it's actually not love like people. People do not have an overt need to be loved. They have an overt need to be understood. And I told my son, like, the faster you can understand your teammates, the faster you can shift into these hyper productive patterns of product of like getting things done. But if you don't understand your teammates, you can never cross that line and get to the next thing where you're going to.
A
Otherwise you're just fighting, even though you might not feel like you're fighting. Because people are very skilled at hiding how they feel, of course.
B
Exactly. So, like, understanding people is super important and you must, as a Scrum Master, do that to be ultimately successful and impact on positive changes.
A
That's a great way to finalize this episode. Thank you very much, Felipe.
B
You're welcome.
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. 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 at Scrum Master Toolbox, 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.
Title: Team Happiness as the True Measure of Scrum Master Success in Construction
Guest: Felipe Engineer-Manriquez
Host: Vasco Duarte
Date: January 29, 2026
In this Success Thursday episode, Vasco Duarte sits down with Felipe Engineer-Manriquez to dive into the application of Agile, specifically Scrum, within the construction industry. The discussion centers around translating retrospective practices into this domain, measuring the true impact of a Scrum Master, and why team happiness is the ultimate metric for success. Felipe brings in relatable analogies, personal stories, and actionable insights directly from the field.
Introducing Retrospectives as ‘Lessons Learned’:
Felipe emphasizes approaching retrospectives in a way that feels familiar to construction teams, linking them to the post-mortem or "lessons learned" sessions already recognized in the industry.
Post-mortem Analogy:
Connecting the concept back to the original roots in medicine, Felipe explains how post-mortems involve honest discussion of mistakes to prevent future harm—drawing parallels to reducing errors in construction.
Start, Stop, Keep Format:
Felipe shares his preferred structure for these sessions:
Cadence and Practical Implementation:
Timeboxing:
Both Felipe and Vasco agree on the critical importance of timeboxing to prevent retros from becoming blame sessions.
Team Happiness as Core Metric:
Felipe states that the “hardest one to measure” is actually the most important: team happiness.
Self as ‘Human Thermometer’:
Felipe reflects on his emotional sensitivity developed through challenging experiences in the industry, which now allows him to quickly gauge a team’s morale.
Subjective Measures Over Data Dashboards:
Unlike reliance on digital dashboards or management reports, Felipe places priority on in-person observations and periodic surveys to understand real moods within teams.
Identifying Burnout and High Performance:
Teams making jokes, being lighthearted, and engaging are nearly always high-performing, while sarcasm or silence suggests burnout.
Practical Happiness Scale:
Felipe uses a Likert scale (1–5) for a simple happiness check-in.
Direct Connection to Performance:
He observes that as team happiness trends upwards, so do schedule improvements and delivery success.
The Importance of Understanding (Not ‘Love’):
Teaching his son about teamwork, Felipe stresses the need to understand teammates—not necessarily to love them—which accelerates productivity.
On Adapting Agile to Construction:
“We're changing the vocabulary in the industry and we're starting to pick this up.” – Felipe [02:27]
On High-Stress Environments:
“I’ve had days... my frustration level was so high that I had to call my spouse and just tell them how bad my day was. And I would pound the steering wheel with my hand as I’m driving to almost break the steering wheel off my car. That’s how high my frustration was.” – Felipe [07:05]
On Intervention and Scrum Master Mindset:
“A successful Scrum Master medals appropriately. That’s my mark of success as a Scrum Master—get involved. We run to things, we don’t run away from things and we deal with problems head-on.” – Felipe [11:00]
Felipe is candid and relatable, drawing on vivid personal stories and analogies. He adopts a coaching tone, offering practical wisdom along with humility and humor. Vasco steers the conversation with curiosity, connecting Felipe’s construction-specific insights with Agile principles familiar to the audience.
This episode is particularly useful for Scrum Masters, Agile Coaches, or industry professionals striving to foster happier, more effective teams in non-traditional agile environments like construction.