B (4:51)

So tell me a little bit more before we go into the new process and how you introduce those. What are some of the typical things that you find, find free up that access capacity. Like a couple of examples just to make it concrete for the audience.

C (5:06)

Yeah. One is big batch processing. People like to wait to do things. So like, and we laugh about this all the time, like, well, even something as simple as making a commitment on an action item in a meeting, the default answer in construction, and anyone who's listening to this that has any type of experience in construction, this will immediately trigger them. If somebody's asked to make a commitment, the default answer is within two weeks. Everybody always answers within two weeks. And so when you hear that and like, we'll look at like, what does it actually take? And you deconstruct that. And so the waste associated with the in two weeks answer is waiting. Waiting is the waste that's in play. But the subtle thing that's happening is big batch processing and multitasking. People are doing a lot of things and they're finishing nothing. And so when they make these commitments, they're hedging their bet because they know that they have these other things distracting them that they have to get done. But they, they don't want to not please another human being, so they want to be polite and they'll say two weeks. Now, nothing in the world that I know of, no natural human process actually takes 14 calendar days to do. But it is the number one answer that people make. And so when you, when you pick apart what it actually is, then you can, you can reduce the batch size of something more appropriate and get a much better answer. It's never 14 days. Maybe it's 13, but it's not 14. And so like that waiting is terrible. That, and that's, that's a huge thing. I want to teach people the downtime. Maybe I play like a short little video that comes from software development. And the, it's hilarious because all the examples of the video, it's a video from a software company called Orbus and it's the eight wastes of Lean. And it's an amazing video that shows the downtime in like, it's like a three minute video. But once people see the eight wastes and all on like, I feel like every example is a construction example in their software video. It's hilarious. You can't not see it. And that's what you're going to use to implement. You're going to use that to, you decrease the waste and then you create the capacity to do the changes. And so I, so I survey people. The number one answer when I say what's what waste is affecting you. Waiting is number one. It doesn't matter if I'm talking to a design engineers, architects, or if I'm talking to Foreman or anybody in any trade. Waiting is the number one thing.

B (7:35)

That's what the system produces. Right? Waiting.

C (7:37)

Exactly. Waiting. Because the whip is too high. The whip is the work in process is too high. The higher the work in process, the less throughput your system will give you. So the waiting becomes exponentially longer and unnecessary.

B (7:50)

So you've freed up the capacity. What do you do next?

C (7:52)

Yeah. Then that's the first thing I do is I make things transparent, make things visible, increase transparency. Step one. So like I worked with, there was a team I work with that was working on a job. This is the classic every day you work, they lose a day. This job already had lawyers engaged. They're going to claim, they're going to litigate and they're going to litigate against the city. This was the city project. They're making an ambulatory emergency response center. You call 911 in the city and this building answers the call and deploys emergency resources and other things. And, and it was. They'd worked two years and they still had another. It was like a, supposed to be a one year project. It was two years later, not done. And, and I go to the team and this is a class like all the classic patterns are in place. And the, the team was convinced that the people they hired to do the project were incompetent. And so the biggest challenge there was.

B (8:46)

That's an easy one to believe, right? Given that it was a two year, a one year project that had lasted already two years and I had one.

C (8:53)

More year to finish. So it was like it needed, it needed from the time they realized that they were getting lawyers involved, it was going to take two years to finish. And so we implemented a simple thing. We made visible the next milestone goal that the team was going to achieve, which if the case was like, it was like some, some putting up some priority walls in the building. And these were like drywall walls, like drywall paint. And so we just made that visible. We spent five, five minutes in the meeting describing what it means for these walls to be finished on a whiteboard. And I hand wrote the date and I put it on the wall. And I told the superintendent, like in, in Europe they have. These are site managers. Superintendent. Same in the United States, Superintendent. And I said, just put this on the wall and if people ask you, just answer the questions, leave the answers there. We answered it as a group with the other lead foreman from the meeting and five minute meeting. What happened was two weeks later they met their schedule and improved the schedule by four days. And the superintendent said, never in the entire time I worked here have we ever met a schedule commitment or did better. So it was the first time ever. And the only thing we did was we spent five minutes. Now what that thing I was actually doing with them was planning. We were planning and we were defining where a future condition where we wanted to be.

B (10:20)

But it was like real time planning always Adjusting to the reality of that moment.

C (10:25)

Yeah. And to make that change happen, to even get to the point where I can stand with this team and have this five minute conversation, I had to bribe them with pizza. I bought the team pizza. And it wasn't like I didn't pay amount of money like the company let me reimburse, but we fed people. And in the time that they were eating, that's when we did the five minute conversation, defining what it was. And they made the time up.

B (10:49)

Yeah. And I really like that approach of, okay, first free up capacity. Because otherwise you're always going to increase the pressure and it's only going to make things worse and then make things visible. Trust that people know what to do, and they usually do. If you make the things visible. And that five minute meeting that you just discussed, I don't know if that's what you thought when you did that, but did you introduce that as kind of an analog to the daily scrum?

C (11:18)

Yeah, that team was. They weren't doing a daily. They weren't doing a daily huddle. Like, in construction, it's very common for teams to do these daily huddles usually for safety reasons. There's like a lot of like, legal reasons why they have to review these things that they're going to do. And a lot of projects hijack that safety meeting and make it a production meeting where they're pushing dates on people. So that. That was happening on that project, but they were not actually planning. They were just pushing. They're. They're using those meetings to push. And I had. I was observing the team and I realized, like, I don't think people are clear on what needs to be done. So we didn't get to the point where we had to do the daily. Just making the. The dates visible and letting them input that pattern first. I told them, like, in a future state, like, there's a couple more things we're going to do. In reality, it's like 25 more things I wanted them to do, but I was like, I just keep it simple. Like it's going to be a couple more changes. And what ends up happening, Vasco, is that we make these changes, we stabilize, and then we introduce the next change because the capacity changes again. And we're using. We're back to theory constraints. I think we talked about like on Tuesday, where your system, as it stabilizes and you make a change to a bottleneck, the whole system changes again. You have to find a different bottleneck will emerge.

B (12:33)

Exactly, exactly. That's so. Well expressed like, don't try to do all of the things at the same time, because when you do one thing, the system changes.

C (12:43)

Yeah. And once it stabilized and we saw that that was an issue, the next thing to change was to put a focus on getting people paid. The change orders were a problem. That was the next big thing to change that that released so the team could actually get paid for work that they had done because the design was ever evolving.

B (13:02)

Yeah, absolutely. I really like that change approach and I'm sure we can learn a lot from that also in the software side. So thank you very much for sharing that with us, Felipe.

C (13:11)

Yeah, you're welcome.

A (13:16)

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.

B (15:09)

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.