Managing The Network of Promises in Lean Construction | Luca Cotta Ramusino

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches Episode: Managing The Network of Promises in Lean Construction | Luca Cotta Ramusino
Host: Vasco Duarte
Release Date: June 19, 2025

---

Introduction

In this episode of the Scrum Master Toolbox Podcast, host Vasco Duarte engages in a profound conversation with Luca Cotta Ramusino, an expert in applying Lean and Agile methodologies within the construction industry. The discussion delves into the innovative integration of Agile retrospectives in construction projects, exploring how principles traditionally associated with software development can revolutionize construction management.

Agile Retrospectives in Construction Projects

Luca begins by addressing the unconventional application of Agile retrospectives in the construction sector. Drawing parallels from Scrum and the Toyota Production System (TPS), specifically the concept of Hansei (reflection or introspection), Luca emphasizes the necessity of regular reflection to foster continuous improvement.

Luca Cotta Ramusino [01:55]: "Basically, how can you improve what you're doing if you keep doing the same thing you've been doing?"

He highlights the challenges introduced by the COVID-19 pandemic, which necessitated remote collaboration and increased the importance of reflection without traditional face-to-face interactions. This led to the adoption of informal, daily reflections integrated into routine activities.

Reflect and Disinfect: An Innovative Retrospective Technique

One of the standout practices discussed is the Reflect and Disinfect method, coined by colleague Colin Milburgh. This technique seamlessly blends daily health protocols with reflective practice, ensuring that teams take a moment to introspect at the end of each working day.

Luca Cotta Ramusino [02:20]: "While you were disinfecting, you also had a chance to speak freely. And this was very, very, very informal."

The Reflect and Disinfect session is designed to be brief, lasting only about 15 minutes, and occurs naturally as workers conclude their day by putting away tools and sanitizing their hands. This informal setting encourages open communication without the pressure of formal meeting notes, enabling teams to discuss:

1. What to Continue: Celebrating successful practices.
2. What to Stop: Identifying ineffective methods detrimental to the project.
3. What to Start: Experimenting with new approaches to enhance productivity.

Daily Reflection: A Value-Rich Practice

Luca underscores the value of integrating daily reflections, a practice seldom emphasized in software circles where the pace often hinders the allocation of time for improvement.

Luca Cotta Ramusino [06:35]: "The ability of creating that daily reflection is really valuable."

He compares it to the software industry's tendency to postpone reflection, leading to inefficiencies that become ingrained until they require significant correction.

Key Metrics in Lean Construction: PPC and RNC

Transitioning to measurement, Luca introduces two pivotal metrics from the Last Planner Method, a collaborative planning approach in construction:

1. Percentage of Plan Complete (PPC):
   Measures the reliability of commitments by evaluating the percentage of planned tasks that are completed within the expected timeframe.

2. Reasons for Not Complete (RNC):
   Identifies the root causes behind incomplete tasks, allowing teams to address recurring issues systematically.

Luca Cotta Ramusino [08:17]: "It's on Tuesday. If you have completed that on Monday night. Okay. This is like a promise that two different teams make to one another."

He likens construction projects to a network of promises, where each commitment must be honored to ensure smooth progress. High PPC indicates reliable promises, while RNC provides insights into areas needing improvement.

Reliable Promises and Their Qualities

A central theme is the concept of reliable promises, foundational to effective collaboration in construction projects. Luca outlines the essential qualities that constitute a reliable promise:

1. Autonomy to Decline:
   Teams must have the ability to say no to unrealistic commitments.

2. Knowledgeable Parties:
   All involved parties should have a clear understanding of their responsibilities and the tasks at hand.

3. Capability to Deliver:
   Ensuring that teams have the necessary resources and means to fulfill their promises.

4. Shared Understanding of "Done":
   Establishing a mutual agreement on what constitutes task completion, preventing misunderstandings and ensuring quality.

Luca Cotta Ramusino [13:37]: "A reliable promise has a number of identifiable qualities... Both parties have to agree on what done means to the point that we have two different statuses for work. One is done and we also have done done."

This dual-status system differentiates between mere completion and a consensus that the task meets all required standards, akin to Scrum's "Definition of Done."

Definition of Done vs. Done Done

Luca elaborates on the importance of distinguishing between "done" and "done done":

• Done:
  Indicates that a task has been completed from the perspective of the team executing the work.

• Done Done:
  Represents a collective agreement that the task meets all criteria and standards required by the receiving party.

Luca Cotta Ramusino [14:55]: "It's not done until it's done done."

This approach ensures that quality is not compromised and that all stakeholders share a unified understanding of task completion.

Insights and Conclusions

The episode provides valuable insights into how Agile practices, particularly retrospectives, can be effectively adapted beyond their traditional domains. By implementing daily reflections and robust metrics like PPC and RNC, construction teams can enhance their reliability and continuous improvement efforts. The emphasis on reliable promises and a clear definition of done fosters a culture of accountability and quality, essential for the successful execution of complex construction projects.

Luca’s experiences underscore the universality of Agile principles and their adaptability to various industries, demonstrating that the core values of reflection, collaboration, and continuous improvement are instrumental in driving project success.

Notable Quotes

• Luca Cotta Ramusino [01:55]:
  "Basically, how can you improve what you're doing if you keep doing the same thing you've been doing?"

• Luca Cotta Ramusino [06:35]:
  "The ability of creating that daily reflection is really valuable."

• Luca Cotta Ramusino [13:37]:
  "A reliable promise has a number of identifiable qualities... Both parties have to agree on what done means to the point that we have two different statuses for work. One is done and we also have done done."

• Luca Cotta Ramusino [14:55]:
  "It's not done until it's done done."

Conclusion

This episode of the Scrum Master Toolbox Podcast offers a compelling exploration of integrating Agile practices within the construction industry. Luca Cotta Ramusino's insights highlight the transformative potential of Agile retrospectives and metrics in enhancing project reliability and fostering a culture of continuous improvement. For Scrum Masters and Agile Coaches, this discussion provides actionable strategies to adapt and implement Agile methodologies beyond software development, achieving success in diverse project environments.

---

Note: This summary focuses solely on the main content of the episode, excluding promotional segments and non-essential sections, to provide a comprehensive and informative overview for listeners and those interested in Agile practices within construction.

Transcript

[Vasko]

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.

[Luca Cotta Ramosino]

Welcome to our Thursday success. Thursday, of course, the most important question of the week this week with Luca Cotta Ramosino. Hey Luca, welcome back.

Let's do this.

Let's do this. A pleasure to have you here to talk about something that many perhaps don't assign to a typical construction work. And that is of course, the use of agile retrospectives in a construction project. So you've been applying this? Of course. So what have you learned about facilitating reflection and retrospectives in construction projects?

Retrospective is something I also got from Scrum. Okay. I am also a Scrum product owner and I found a nice parallel when studying the Toyota way in Hansei, which is reflection. Okay, Introspection. Well, basically, how can you improve what you're doing if you keep doing the same thing you've been doing? Okay, this is the big question. You need a moment to stop and think back on what you have done and can you do this better? Okay. That is the reason why you should stop and think during COVID If you recall, maybe it might have been a little different in different nations because the health organizations differ. But general rule was, all right, you know, don't, don't be in a room with other people unless absolutely necessary. Okay. And one other thing that you had to do was to use hand sanitizer frequently to wear masks. Anyway, long story short, there's this term that came up to describe a moment of retrospective at the end of a working day. The definition is not mine. It's by calling Milburgh. But I love the definition and I have been applying the technique. So he called this reflect and Disinfect. So at the end of the working day, people were maybe, you know, putting away their tools or getting ready to close the working day and go home. You also had a number of health procedures he had to perform. And this is the reflect and disinfect. While you were disinfecting, you also had a chance to speak freely. And this was very, very, very informal. Okay. So no meeting notes, just people sharing what they thought was interesting about their work day. And in a retrospective, if you think about it, you need to answer three basic questions. First of all, what should we continue doing? We know it's working. Okay, so let's celebrate that we got something right. Okay. What should we stop doing? We have ascertained that it's not good for the project. Okay. And third, what should we start doing? As in experimenting a way of doing what we are doing, only better. Okay. And this is how you go about your reflect and disinfect. And it takes all of 15 minutes. You know, by the time you taken off your safety boots and put away your tool and use the hand sanitizer. You have discussed all three questions.

It's one of the things that really strikes me with that. First of all, I love the name of the practice. Right. Reflect and disinfect. I'm sure we can come up with a different name for software, but the practice name is. Is absolutely brilliant. And then the second thing that is not often discussed in software circles is that you did this every single day and you try to make it as informal as possible. And this is so cool. And of course, we know that quality circles from Total Quality Management and TPS or Toyota Production System have been there for many years. But in software, we kind of tend to resist the idea of reflecting because we're, as you say, so busy doing what we need to do that we have no time to do it better. But then we eventually need to have time to do it twice, as it usually goes. And this ability of creating that daily reflection is really valuable.

Yeah, we're so busy mopping the floor that nobody turns the faucet off.

Exactly, exactly. But of course, as we do these retrospectives, we are doing them with the intention of helping the teams that we support, helping the organizations we are part of. So when you think about your work, applying lean and agile construction. Lean and agile to construction, what metrics, what signs, what are you looking for to ensure that you are contributing to the success of the project? And of course, the teams and the organization that you work with.

There are two very important metrics that are used on construction sites. And they come from a collaborative method, collaborative planning method called the last planner method. It's called last planner because planning is done by the people who are closest to to the work. Last as in I'm actually at the, at the edge of the work. You know, there's not another layer of management under me. And they are called ppc. Percentage of plan complete and rnc. So reasons for not complete, completing something. And to me they, they are both invaluable ppc. So meaning how much? What percentage did we get completed this week out of everything that we said we would complete? So you can think of a construction project as a network of promises. Okay. It's on Tuesday. If you have completed that on Monday night. Okay. This is like a promise that two different teams make to one another. Now if the promise is maintained, then you get to the end. If the promise is broken, so to speak, then you are stuck. You cannot progress in your work. So the whole point of planning together is to establish a reliable promise. Okay. I can rely on you saying that you are going to take five people on the roof to do this, this and that and you will be done by Thursday, end of work day. Okay. Measuring the percentage of plan complete allows you to see how reliable your promises are. Okay. I mean if you get 100% PPC, then you're, you're cheating. Come on, you're just, you're just. Ah, come on. No, you just, you want your PPC to look good and impress the boss.

Which would be no surprise, especially if bonuses.

But it's not going to help complete that hospital or car park or whatever it is you're building. Okay? Reasons for not completion. Okay. The RNC to me is just as important because it shows where you should concentrate. What is going different in this project, what is behaving differently from your expectations. And that is why you measure reasons for non completion. And I have found that after a few weeks into a project, the problems that the missed deadlines tend to concentrate aggregate in two or three problem areas. You know, it could be we have a material delivery problem, okay. Or we have a crew handover problem. It's important that you focus on these reasons so that you can improve your throughput going forward.

So when you think about ppc, this kind of highlights the importance of knowing what complete means. Because as we illustrated in a couple of episodes ago, if you have a wall complete, but actually the pipes behind the wall are all the wrong pipes, then you can't count that wall as complete. So we need to somehow get to an understanding of what complete means. And in Scrum we have this concept of the definition of done. So what does it mean to be done with something? And I imagine that when you're talking about percentage complete, you're also talking about having a clear shared understanding of what complete means. Is that correct?

That is correct. So a reliable promise has a number of identifiable qualities. You know, first of all, you can, you can say no. If you can't say no, then it's not a promise. It's like, you know, somebody twisting your arm behind your back. Both parties are knowledgeable, meaning they, they know what they're talking about. Both parties have the means to deliver the promise. Okay? And then most both parties have to agree on what done means to the point that we have two different statuses for work. One is done and we also have done done. Okay? Done done means that the guy receiving the work also agrees that it's done and it's done. No, it's not done until it's done done. And an Irish colleague of mine, you know, said, in Ireland, we also have done done expletive that I can't. Done. Done. Done. F Done. Okay, that's just for Ireland.

Absolutely. And this highlights the importance of having that agreement between all the parties involved, which in your case, I imagine means that the different specialties involved in one of those promises all agree what don means. Yes, absolutely. Well, thank you for sharing that. It's been very enlightening. Thank you, Luca.

A pleasure.

[Vasko]

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

[Luca Cotta Ramosino]

Slack.

[Vasko]

We really hope you liked our show.

[Luca Cotta Ramosino]

And if you did, why not rate.

[Vasko]

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.