Derived from Agile Project Management methodologies, Agile Construction is a new process that's shifting the way teams plan, execute, and deliver work on construction projects.
Introduction
The term agile has recently become popularized across a variety of industries, most notably in software development. Agile offers a framework that differs from traditional waterfall project delivery methods, which typically encompass long-delivery cycles with core outputs only delivered at the end of the project. Agile methods, conversely, require iterative planning, consistent scope refactoring, and regular working-product delivery throughout the execution phase of the project. One of the core goals of agile methods is to produce high-quality, working deliverables (value) more rapidly, which may be consistently improved upon and enhanced over time.
Agile methodologies have not been extensively used or tested in the construction industry. There are publications and materials available on the topic, however, they are sparse. Regardless, due to the positive yields of agile in other industries, construction project teams are beginning to explore the key concepts of agile and test them in construction project environments. This beginner's guide provides on overview of agile principles and explores how they may be adapted and adopted in a construction project workflow. Through iterative planning, self-organization, and short-duration sprints, project safety, quality, cost, and schedule performance improvements may be garnered.
Agile versus Waterfall Models
Most construction teams are familiar with waterfall project delivery processes. In a traditional waterfall project delivery model, the final project handover is the ultimate deliverable. Value, or the final working product, is only delivered to the client at the end of the project upon turnover of care, custody, and control of the building, bridge, or process facility that we're building. Quality verification and testing is asynchronous with task execution; it occurs only after asset construction is complete, or nearly complete.
Waterfall processes are linear. A series of gates must be passed to successfully continue the project journey. Therefore, teams invest significant time and effort in defining and planning the project scope early in the project. Long, complex, and detailed project delivery schedules are established by scheduling experts, which the entire team is committed to execute to as they work their way from gate to gate. This approach yields risk; if you can't see the final product until the end, how can you be sure that you're on schedule, performance is as expected, and that quality is up to client expectations? The answer: we rely on analysts and mountains of reports.
Agile teams take a different approach. In agile programs, instead of one final handover, micro-products are the outcome. Deliverables are produced continuously throughout the project; teams don't wait until the end of the project to test the product and turn it over to the client. Progressive testing and turnover is possible with an agile approach.
Agile teams don't plan at a granular level at the outset of the project. They create higher level plans and empower execution teams to complete the detailed planning efforts for their scope. Agile, contrary to popular belief, doesn't negate the need for planning. It empowers the delivery team in the planning process in an iterative manner.
During execution, short iterations (sprints) drive project activities. Iterations are defined periods of work with a clear scope, goals, timeline and deliverables; teams are expected to complete their planned work scope within the sprint duration, earning points along the way. Quality verification and testing are synchronous with building; therefore, agile methods expedite the completion of project components, enabling the progressive turnover of systems, floors, or buildings.
In traditional waterfall project delivery models, it is extremely difficult to pivot when scope creep occurs or design changes are made. With so much effort invested in front-end planning, scope creep or change results in significant planning rework. In Agile Construction, scope creep or change has significantly less impact. Because planning is iterative, and granular execution planning is only done at the sprint level, teams can rapidly pivot and adjust to project changes while minimizing the impact to project cost and schedule. This upside makes Agile Construction attractive to design-build project teams and to contractors and sub-contractors that are regularly encountering scope modifications.
A construction project can't be completely agile; with complex design and construction specifications and regulations well-established, a full agile model isn't a practical goal. Unlike in software, we can't simply deliver a working room or refinery system every few weeks; design and construction of assets takes longer and is more complex. However, we can leverage agile concepts to augment our waterfall methods, creating a hybrid model that provides the benefits of agile without completely overhauling the way we execute projects. And, that exactly what Agile Construction teams are doing.
Defining the Construction Roadmap
The first step in Agile Construction project planning is defining the Construction Roadmap. The Construction Roadmap outlines the high-level sequence of construction execution activities; teams will develop a preliminary sequence of Construction Zones (CZs). Construction Zones are geographic areas of work with clearly defined boundaries and scope requirements. The sequence of execution of these these Construction Zones outlines a delivery prioritization based on Client turnover priorities, as well as completions and commissioning requirements. This sequencing should be determined in collaboration with the client, so as to ensure that the proposed sequence of deliverables suits their needs.
For example, when building a house there are a number of zones which may be encompassed. The garage may constitute Construction Zone 1, while the patio may constitute Construction Zone 14. Each zone has clear geographic boundaries; completion sequencing should be determined based on what's possible (based on build limitations) and what's needed (the sequence that the client would like the product delivered). The final sequencing of Construction Zones defines the Construction Roadmap. Note that this residential building example provides a simple explanation of boundary definition and zoning. This process may be extrapolated for other industries where work zones may be vertically or horizontally more complex.
It's important to understand that this roadmap isn't 'set in stone'. Construction projects are dynamic; the roadmap may require numerous adjustments due to material delays, site accessibility issues, or a variety of other events that may cause construction priorities to shift. The Construction Roadmap, and the sequencing of all Construction Zones, should be defined in the project level 2 schedule.
Develop Project Sequencing Plans
Once the Construction Roadmap has been defined and agreed to by all requisite stakeholders, project sequencing plans may be created. Sequencing plans are more granular deliverables that outline the priority completion dates of defined scopes of work. These scopes of work differ dependent upon the stage of the project.
Design Sequencing Plan - a design deliverable that prioritizes the sequence of completion of Design/Engineering Work Packages based on construction priorities and the sequence of Construction Work Package execution.
Procurement Sequencing Plan - a procurement deliverable that prioritizes the sequence of fulfillment of procurement activities to support the sequence of construction activities.
Construction Sequencing Plan - a construction deliverable that prioritizes the sequence of completion of Construction Work Packages (CWPs) based upon the completions and commissioning requirements of the project.
When developing sequencing plans and sequencing work scope activities, teams must always focus on the needs of the next task owner in the value chain. The famous Stephen Covey mantra "begin with the end in mind" is highly applicable with agile programs. It is imperative that project teams work together to ensure that prioritization provides value to the project owner; ultimately, the utility of the delivery sequence is where value is created for the client. In this model, sequencing planning is construction driven.
Sequencing plans must be developed collaboratively and synchronously to prove effective. If a change is required in one sequencing plan, all other sequencing plans must be reviewed and updated accordingly. Early stakeholder alignment and collaboration is key to the success of agile programs. The sequencing of work packages within each sequencing plan should be identified in the project level 3 schedule.
Sprint Planning
The next step in the agile workflow is to begin sprint planning. This is a highly engaging and collaborative activity that takes place at the beginning of each sprint; the goal is to break down, list, and sequence work activities in a manner that will create value to for the client.
The key to effective sprint planning is ensuring that the right people are involved. During design, sprint planning should engage the area lead (product owner), the discipline lead (scrum master) and team architects/engineers. During construction, sprint planning should engage the area superintendent or construction manager (product owner), the supervisor (scrum master) and those responsible for ensuring work completion (foremen/lead hands). These individuals will work together to estimate work, prioritize activities, and develop effective and achievable sprint plans.
During sprint planning, higher order work packages are dissected into smaller, more granular deliverables. During design, design/engineering packages will be broken down into a list of requirements, each of which will become their own mini work package. Construction teams will follow the same process, breaking down construction packages into granular tasks. Specific deliverables per construction package will be identified and documented in list form. This list becomes the backlog.
Sprints are time-boxed; they will run for a set period of time. Sprints are typically 2 weeks in duration but may be 3 or 4 weeks at the discretion of the project team. Sprints should not run longer than 4 weeks. Standard time-boxing is important for the team to accurately identify work to be completed during each sprint; the team must make commitments to complete all planned work during these time periods.
Each activity within the backlog is estimated to determine activity hours required. Teams must calculate accurate estimates for each task so as to ensure that all tasks added to a sprint can be completed in the defined duration. Estimates should be produced collaboratively by those that are responsible for completing the work.
At the beginning of each sprint, during the sprint planning session, teams will compile a list of sprint deliverables for the sprint they are currently working on; these deliverables are drawn from the backlog. Teams should focus on the highest priority and most logically executed items first; items shouldn't be added to the sprint simply because they are easy to do. Consideration for bulk work completion and minimizing resource requirements should be made. At the end of the sprint planning session, the team makes a commitment to complete the planned tasks.
The Sprint
Each day the team holds a daily stand up (scrum) meeting. These meetings are designed to explore what was completed yesterday, what is being worked on today, and any roadblocks that individuals are encountering. Each participant has a turn to speak; it is the responsibility of the scrum master (supervisor) to keep the discussions on point. These meetings should last no longer than 15 minutes and should be scheduled just prior to shift start each day.
During these daily scrum meetings, tasks are moved across the task board. All planned tasks for the sprint start out in the 'To Do' column. Once in progress, the responsible task owner moves the task to the 'In Progress' column. When testing or verifying, the task is moved to the 'Testing' column. Once 100% complete, the task card is the moved to the 'Done/Complete' column. Task cards should only be moved by the individual that is responsible for task completion.
What Happens when Tasks Aren't Completed
Sometimes a sprint concludes and all planned tasks haven't been completed. While not ideal, this happens from time to time. In these circumstances, the tasks should be placed back into the backlog so as to be captured and completed in a future sprint. If a task is partially complete, all completed work should be documented on the task card; the previous responsible party should also be listed in case someone else is assigned to the task at a later date. It's important that any knowledge transfer required can be completed efficiently.
Sprint reviews are completed at the end of each sprint. During the sprint review, the product owner 'demonstrates' the completed product to the client and project leadership team. Demonstrations may include model reviews, checklist reviews, a site tour, or a general discussion. The sprint review may be a stand alone meeting or may be integrated with the weekly or bi-weekly progress meeting. Feedback from the end user is a critical facet of the sprint review. By clearly and continuously demonstrating and discussing progress and deliverable completion, teams maintain alignment and eliminate the risk of out-of-sequence deliverables.
Retrospectives
Retrospective meetings are held at the end of each sprint. The goal of the retrospective is to review what went well during the sprint and what may be improved upon. As sprints are iterative in nature, continuous improvement is possible through targeted and tactical reviews, driving improvement strategies which may be rapidly implemented.
It's important that all agile team members understand and participate in the sprint review. If the intent of these meetings is not understood, participation is likely to wane over time. Further, if these meetings are dominated by only a few stakeholders, deficiencies are likely to be missed. The scrum master should educate stakeholders on the reasoning behind the process and encourage all participants to contribute.
The Agile Team
Agile construction teams are self-organizing. This does not mean that the team does whatever they want; it means that teams are responsible and accountable for planning and executing their own work. Contrary to other project delivery models that add additional resources to the team to plan work scope, on agile projects the task owners are responsible to plan and execute their work with support from other stakeholders. If you are familiar with Lean Construction, this approach is very similar to that outlined in the Last Planner® model.
Contrary to some project delivery models, agile teams can be cross-functional and multi-disciplinary. Team members aren't siloed into specific discipline focus areas but rather are placed on tactical high-performance teams to complete tasks. Depending on the nature of the sprint, sometimes these teams will be single discipline (piping, electrical, civil) while at other times these teams will be cross-functional. Team members may switch teams at times, at the end of each sprint, based on their skills and the tasks involved in a particular upcoming sprint.
Why Agile?
Agile Construction is a new approach to project delivery. Use has been limited to date and there is broadly accepted overarching model or best practice specifically defined for construction project implementation. As a result, data and reports on usage and outcomes are scarce. However, the success of agile processes in other industries warrants a keen evaluation and analysis of the concept in construction project delivery. Forward thinking teams are already exploring and implementing agile pilots.
One of the most significant benefits of Agile Construction, as mentioned earlier, is the ability to rapidly pivot and change course when needed. Design and construction teams may differentiate themselves by leveraging agile workflows through the ability to more effectively meet changing client requirements or adjust to changing site conditions. While there are a number of overlaps between agile and lean concepts, the ability to rapidly shift directly to meet client needs is distinctly agile.
Agile is implemented across most industries to reduce project risk. In traditional waterfall project delivery models, value isn't produced for the client until the end of the project when the asset is handed over. In Agile Construction, value may be created at regular intervals. Rather than focusing on one long-term project, teams may create micro-projects (floors, units) that may be turned over and commissioned well ahead of project completion. This approach ultimately allows the project owner to derive value from the teams' efforts far earlier than traditionally occurs.
Further, agile methods enable teams to respond effectively to the dynamic nature of construction operations. Teams may pivot rapidly and effectively without having to recreate project plans for every roadblock or delay that is encountered. When something goes wrong, the team adjusts the sprint or the backlog and carries on with little impact.
By self-organizing, teams are engaged and develop a sense of ownership over the plan. In traditional waterfall models, team members are often provided with a plan; it's not their plan and therefore they often feel no sense of accountability to it. With agile, the plan is developed and owned by the team. By making commitments at the beginning of each sprint, the team will be measured on their performance outcomes.
Lastly, Agile Construction keeps the project owner engaged in the process. This engagement ensures that client needs are routinely worked into the plan throughout the project lifecycle. No more surprise required-by dates or last minute wish list items. With agile, once the sprint is set, the goals aren't readjusted ad hoc. Even the client is accountable to facilitate overall project performance by speaking up, providing input, and ensuring that the project is progressing to their needs at every stage of execution.