How to Implement Scrum in Construction Feat. Felipe Engineer

Scrum in Construction: How to Run Agile, Protect Flow, and Adapt Lean Tools Without Breaking People

You’ve probably felt the gap between what the schedule says and what the project is actually doing. The CPM printout looks clean. The three-week lookahead is stapled and distributed. Everyone nods. Then Monday hits, the work isn’t ready, the field improvises, and the plan becomes a story we tell ourselves to feel in control. Jason Schroeder puts it bluntly in this interview: we are not going to fix the industry by only using CPM and three-week lookahead printouts.

The pain on most projects isn’t that people don’t care. It’s that the system doesn’t give them a short feedback loop. It doesn’t make constraints visible early enough. It doesn’t help teams learn fast, especially in complex areas like interiors, energization, and functional upgrades where dependencies pile up. When the system can’t see problems early, people pay for it latewith stress, nights, weekends, and burnout.

The failure pattern is predictable. We take a tool, we treat it like a script, and then we judge teams for not “doing it right,” instead of asking the Lean question: is it working, and are we learning? Jason describes being criticized for modifying Last Planner to fit circumstances, and he pushes back with the right question if the results are there, why are we policing the template instead of improving the process?

The system failed them; they didn’t fail the system. Most teams were never trained to combine planning methods, shorten feedback loops, and adapt without shame. That’s what Scrum can help with when it’s used as a pull system to enable flow, not as another layer of bureaucracy.

Field story time. Felipe shares his own burnout trajectoryworking over 100 hours a week, seven days a week until a leader hit him at exactly the right time with exactly the right question, interrupted his habits, and helped him try a different way. Within two weeks, he gained 40 hours back, stopped working nights and weekends, and learned a lesson he now repeats: you can’t push a “silver bullet” on teams; you have to meet people exactly where they are. Why this matters is simple. If you want quality, safety, schedule reliability, and stable lives for the people doing the work, you need systems that make work visible, limit multitasking, and create learning cycles. Scrum is one way to do that especially when you integrate it with LeanTakt thinking and Takt where it fits.

Why CPM and 3-Week Lookaheads Aren’t Enough Anymore

Jason isn’t anti-schedule. He’s P6 trained and knows CPM deeply; his point is that the industry won’t get where it needs to go if we treat CPM and short lookaheads like the whole system. CPM can be useful for milestones and contractual narratives, but it doesn’t automatically create day-to-day flow in messy, constraint-heavy zones. A printout doesn’t remove roadblocks. A bar chart doesn’t create team pull. And a “critical path” label doesn’t magically focus the organization on solving the constraint. The real issue is feedback. Construction changes daily. In complex areas, you need a system that lets the team see what’s blocked, swarm it, learn quickly, and adjust without waiting for the next weekly meeting. That’s where Scrum thinking becomes practical especially when you use it to attack the most critical portions of the job instead of staring at them on a CPM report.

What Scrum Really Is in Construction Terms

Felipe demystifies Scrum by translating it into Last Planner language. A backlog is all the things you know you need to do to accomplish the project milestones in Last Planner terms. Sprint planning is similar to phase pull planning: prioritize the next phase and pull the best sequence, but with a time box and a focus on one thing at a time instead of multitasking.

Then comes the daily Scrum. Felipe explains it like this: it’s exactly like a daily huddle, except it’s 15 minutes or less and follows a standard set of questions to keep the feedback loop tight. That time box matters because it forces clarity and eliminates the “meeting for meeting’s sake” habit that kills momentum in the field. Scrum also includes a review (what did we actually accomplish with stakeholders) and a retrospective (how do we learn and change the system). Felipe frames it as minimal management bureaucracy meant to enable team workflow and value delivery, not create paperwork. He even summarizes the structure as “three roles, five events, and three artifacts,” emphasizing it’s intentionally lightweight.

Stop Treating Lean Tools Like Religion: PDCA Your Process

Jason’s stance is refreshing and necessary: we should PDCA our Lean tools. He openly admits to modifying Last Planner without shame, shifting huddles to focus more on roadblocks than PPC, because the goal is flow and results, not ritual compliance. He calls out the criticism he gets, “you have to do it the standard way”  and answers with a Lean principle: aren’t we supposed to iterate? Felipe backs this up from another angle. He describes how teams debate whether something is “textbook,” and he returns to the purpose: why are we doing it in the first place? Not for awards. Not for purity. For outcomes, learning, and stability. When the tool becomes the goal, the project suffers, and people burn out trying to “perform the process” instead of improving the work.

Signals You’re Using Lean Tools in “Template Mode”

• The team can recite the steps, but roadblocks still sit unresolved week after week.
• Meetings produce notes, not decisions or experiments.
• People are criticized for “not doing it standard” instead of being coached toward results and learning.
• The system is treated as a script, so teams often fake compliance instead of being honest.
• Interiors or complex zones feel impossible to manage because the tool can’t keep up with the volume of dependencies.

When Last Planner Breaks Down in Interiors and Complex Work

Jason describes a real field condition: in big hospitals, laboratories, and mega projects, Last Planner “in its designed detail can start to break down in building interiors because there are so many activities and so much interdependence. That’s not a knock on Last Planner. That’s a signal about complexity and feedback speed. In those environments, you need tighter loops, smaller batches, and a visual system that helps the team focus on the next best work while actively clearing constraints. That’s why Scrum boards, simple to-do, doing, done can be powerful in functional areas, shutdown work, upgrades, and other zones where “the plan” must be updated constantly.

Use Flow for the Standard Areas and Scrum for the Troublesome Areas

Jason outlines a practical hybrid mindset. Start with a Takt plan to get realistic about the end date and avoid the gap between what we sell and what we can actually build, then avoid letting CPM logic thrash flow back and forth. Where areas run nicely on Takt, keep them there; then focus Last Planner or Scrum energy on the most critical, constraint-heavy portions of the job elevators, MRI installs, power upgrades where dedicated teams can meet daily and push constraints out of the way. That’s the right posture: flow where flow is possible, and an agile swarm where complexity demands it. Scrum becomes a way to “attack” the most critical items instead of simply labeling them as critical and hoping the schedule survives.

“Done Means Done”: The Quality Standard That Protects Handoffs

One of the most valuable moments in the interview is Felipe’s definition of “done.” In construction terms, “done” is not “mostly done.” It’s installed right, coordinated, ready for use, and the next person in line can pick it up without rework, punch lists, or “takesies backsies.” That definition protects flow because handoffs are where projects hemorrhage time. When “done” is vague, teams push half-finished work forward, stacking defects and creating downstream chaos. When “done” is clear, teams finish as they go, stabilize quality, and maintain a rhythm the field can trust.

The Daily Scrum and the Power of Short Feedback Loops

The daily Scrum is a 15-minute-or-less check-in designed to keep the team aligned and focused on removing constraints quickly. The power here isn’t the meeting; it’s the frequency and the discipline. It keeps the team from waiting a week to discover what’s blocked. It forces prioritization. It reduces multitasking, because the work is pulled one item at a time instead of scattered across ten “in progress” tasks.That’s how you protect people from burnout: fewer open loops, fewer late surprises, and less thrashing. Short loops turn stress into action, and action into learning.

Retrospectives: Turn Complaints Into Experiments

Felipe describes running a retrospective with an IPD team and making one requirement explicit: if it’s only talk, it’s not helping. The retro must produce experiments specific changes the team will test to improve what isn’t working. He shares that the team identified issues, created experiments, and even followed up quickly with a list of what they would try next. This is the habit construction needs. Not just “lessons learned” after the job is over, but learning while it still matters.

Adoption Rule: You Can’t Force It Meet People Where They Are

Felipe learned the lesson the hard way. He tried pushing what he thought teams wanted, wasn’t invited back, and it took years to repair the relationship. Then he says the line that should be posted in every Lean implementation room: “You have to meet people exactly where they are.”

This is respect for people as a production strategy. You can’t shame teams into flow. You create an environment where they can experiment safely, get repetitions, then iterate and make it their own. That’s how you get real adoption without breaking people.

How to Start Simple: Visual Boards, Backlogs, and One Conversation at a Time

Felipe is clear: you don’t have to start with full formal Scrum on day one. Start where you are. If you’re not doing a daily huddle, start with a daily huddle. Then make a simple visual board and a backlog: to do, doing, done. Keep it visible. Keep it honest. Make the work pull-based and reduce multitasking.

Jason shares his own “ignorant” early version of Scrum big boards, stickies, meeting around the work in complex areas and the point is not the label. The point is the behavior: visualize work, focus, learn fast, and adjust with the team.

A Simple Scrum Starter Set for Construction Teams

• Create a visible board with to do / doing / done and keep it current.
• Build a backlog of real work and real constraints, not wish lists or vague promises.
• Time-box the daily huddle to 15 minutes and use it to clear blockers fast.
• Define “done” so handoffs are clean and the next crew can flow without rework.
• Run a retrospective that produces experiments, not just opinions.

Where Takt Fits: Rhythm for the Work, Scrum for the Constraints

Jason’s hybrid approach is a practical way to keep the system stable. Takt provides rhythm and predictable flow where the work is repeatable and can be balanced. Scrum provides an agile attack system for the messy, constraint-heavy zones that require daily coordination and rapid learning especially the places where “critical path” labels aren’t enough to generate action. That combination is exactly what LeanTakt is about: flow over busyness, and systems over heroics. Not more meetings. Better feedback loops. If your project needs superintendent coaching, project support, or leadership development, Elevate Construction can help your field teams stabilize, schedule, and flow.

The Challenge: Build a Team That Learns Fast Without Burning Out

The real win in this interview isn’t Scrum vocabulary. It’s the leadership posture behind it: shorten feedback loops, learn quickly, and adapt tools to the project while protecting people. Felipe’s story about gaining 40 hours back in two weeks is proof that better systems don’t just save schedules they save lives at home, too.

If you’re leading in the field, take this as your challenge. Don’t force tools on people. Don’t worship templates. Don’t settle for meetings that produce talk. Build a learning system. Make work visible. Define “done.” Create experiments. And lead with respect. Because the quote is true, and it’s the heart of implementation: “You have to meet people exactly where they are.”

FAQ

What is Scrum in construction, in plain language?
Scrum is a pull-based workflow system that makes work visible, limits multitasking, and creates short feedback loops through daily check-ins, reviews, and retrospectives. Felipe describes it as lightweight by design, meant to enable team workflow and learning rather than add bureaucracy.

How is Scrum different from Last Planner System?
In the interview, Felipe maps Scrum elements to Last Planner concepts backlog to milestones, sprint planning to phase pull planning, and daily Scrum to a short daily huddle while emphasizing Scrum’s time-boxed loops and visibility as a way to deliver value quickly.

Where does “done means done” fit on a jobsite?
It’s the quality standard that protects handoffs. Felipe defines “done” as fully coordinated, installed right, ready for use, and usable by the next person in line no partial completion that creates downstream rework and delays.

How do I introduce Scrum without forcing it on the team?
Start simple where the team is: daily huddle, visible board, and a basic backlog. Felipe is clear you don’t have to start with full formal Scrum on day one, and he emphasizes the adoption principle: meet people exactly where they are.

How can Scrum and Takt work together?
Jason describes using a Takt plan to establish realistic flow and end dates, then applying Scrum to focus daily energy on the most critical, constraint-heavy portions of the job like complex functional areas or specialty upgrades