Learn how to apply agile methods in engineering projects, which practices work, their limits, and how to combine Agile, Scrum, Kanban, PMO, FEL and Owner’s Engineering.
Check it out!
Agile methods can significantly improve the management of engineering projects, but they should not be applied as a direct copy of the model used in software development. The benefit appears when principles of adaptation, flow, collaboration, prioritization and feedback are used to reduce waiting, accelerate decisions and organize technical production without weakening standards requirements, responsibilities, baselines or change controls.
In engineering, part of the work is iterative by nature: alternatives are studied, assumptions are validated, interfaces are coordinated, documents go through review cycles and field information can change the understanding of the problem. Another part is strongly constrained by legal requirements, safety, contracts, manufacturing, construction and physical dependencies. For this reason, the most consistent use of agile methods occurs in a hybrid system, in which the organization selects practices according to the type of work.
The correct question, therefore, is not “Scrum or traditional management?”. It is: what level of adaptation is technically appropriate for each component of the project, and how should this flow be integrated into reliable engineering governance?
What are agile methods?
The term agile methods is broadly used for approaches that value adaptation, collaboration, incremental delivery, work transparency and frequent feedback.
Historically, the movement gained major visibility with the Agile Manifesto, published in 2001 in the context of software development. Over time, adaptive principles and practices began to be used in other forms of knowledge work.
It is important to distinguish several concepts:
- Agile is a philosophy or mindset oriented toward adaptation and value delivery;
- Scrum is a framework structured around roles, events and artifacts;
- Kanban is a flow-management approach emphasizing visualization, work-in-progress control and system improvement;
- Lean seeks to reduce waste and improve flow and value;
- Last Planner System is a production-planning and control system strongly associated with Lean Construction;
- Rolling Wave Planning is a progressive-planning technique in which the near future is detailed more intensively than distant horizons.
These concepts are not equivalent and do not need to be implemented as a single package.
Why agile methods matter to engineering
Engineering projects rarely begin with all information available at a definitive level.
Even when contractual scope is known, questions remain, such as:
- actual site conditions;
- unrecorded interferences;
- manufacturer data;
- interface definition;
- operating requirements;
- validation of alternatives;
- client decisions;
- equipment availability;
- regulatory changes;
- multidisciplinary coordination.
Part of the project therefore consists of progressively reducing uncertainty.
The problem with an excessively sequential model is waiting for one discipline to “finish” before exposing its results to the others. Where many interfaces exist, this tends to push conflicts to later stages, when the cost of change is higher.
Agile practices help increase the frequency with which the system produces verifiable information and receives feedback.
Engineering is not software: the limits must be recognized
Mature application of agile methods begins by recognizing what is not easily adaptable.
In software, a feature can often be changed, tested and deployed again at relatively controllable cost. In a physical asset, certain decisions become progressively irreversible.
Once a civil foundation has been built, equipment manufactured, piping installed or a panel assembled, change may require physical rework, remobilization, repurchasing materials and operational shutdown.
Engineering projects must also deal with:
- technical standards;
- safety requirements;
- professional responsibility;
- licensing and external authorities;
- inspection and testing criteria;
- formal documentation;
- traceability;
- contracts and measurements;
- long equipment lead times;
- physical dependencies among disciplines.
These characteristics make it dangerous to interpret “responding to change” as accepting changes without formal assessment.
What can be transferred from agile methods to engineering
Although the context is different, several principles are highly transferable.
Make work visible
Projects frequently have dozens or hundreds of simultaneous items: documents, comments, RFIs, revisions, submittals, decisions, interfaces and open issues.
When this flow is not visible, management relies on meetings and individual perceptions. Visual boards and structured systems help identify bottlenecks and responsibilities.
Work in smaller cycles
Instead of concentrating all validation in one large late review, teams can establish frequent coordination and verification cycles.
Prioritize what unlocks the system
Not every open issue has the same impact. One interface decision may release three disciplines, while another activity may have little influence on the critical path.
Limit work in progress
Opening too many work fronts simultaneously tends to increase queues and completion time. WIP limits help teams finish work before starting new items.
Receive feedback early
Early review of concepts, layouts, criteria and interfaces reduces the likelihood of discovering incompatibilities only during detailed design or in the field.
Learn from the process
Retrospectives and reviews of the work system can be translated into engineering as periodic analyses of bottlenecks, rework, input quality and meeting effectiveness.
What should not be transplanted literally
Some practices need adaptation.
Physical deliverables do not necessarily fit into sprints
The natural duration of an engineering activity may exceed the selected cycle. Forcing a complex analysis into two weeks may create artificial subdivisions with no value.
The client cannot always reprioritize requirements freely
Standards, safety and contractual requirements are not simple backlog items. Changes must respect Requirements Management in Engineering.
The definition of done must include technical quality
Completing a task is not merely moving a card to “Done”. A document may require calculation, independent verification, approval, signature, interface review and version control.
Not every change is cheap
The cost of change tends to increase as the life cycle progresses. Therefore, the degree of adaptive freedom must decrease as decisions are released for procurement or construction.
Main methods and practices that can be used
Scrum
Scrum organizes work into cycles called sprints and establishes defined events and responsibilities.
In engineering, some elements can be useful:
- cycle planning;
- frequent review with stakeholders;
- definition of the cycle objective;
- prioritized backlog;
- retrospective;
- short synchronization meetings.
Use should be selective, however. Not every organization needs to reproduce the Product Owner, Scrum Master and Developers roles in full.
The Scrum Guide itself defines Scrum as a specific framework. Therefore, calling any visual board or daily meeting “Scrum” is technically incorrect.
Kanban
Kanban is particularly well suited to engineering flow because it does not require all work to fit into fixed-duration cycles.
It can be used to control:
- documents;
- RFIs;
- interfaces;
- comments;
- submittals;
- approvals;
- survey open items;
- commissioning actions.
The focus is to see the flow, limit WIP and improve predictability.
Lean
Lean broadens the discussion to value, flow, waste reduction, reliability and continuous improvement.
In engineering environments, waste may appear as:
- waiting for information;
- rework;
- excessive handoffs;
- documents produced before inputs are mature;
- redundant approvals;
- late decisions;
- meetings without outcomes;
- multiple versions in circulation.
Last Planner System
The Last Planner System has a strong relationship with construction and collaborative planning. It works with commitments, constraint removal and reliability of short-term planning.
Its application deserves dedicated treatment because it should not be reduced to “a construction Kanban”. Within a hybrid-management cluster, it serves as an important bridge among project management, planning and Lean Construction.
Rolling Wave Planning
Rolling Wave Planning details work progressively.
In engineering, this means maintaining visibility of the entire project without pretending there is enough information to detail distant activities with the same precision as the next few weeks.
It is a natural bridge between predictive management and adaptive practices.
Is the question which practice to use — Scrum, Kanban, Rolling Wave or a combination — without creating an artificial methodological transformation?
Engineering Project Management structures the management model around the project’s actual problem, integrating governance, planning, workflow, interfaces, changes and deliverables.
Suitability matrix for agile methods in engineering
The decision can consider five main dimensions.
| Dimension | Lower need for adaptation | Higher need for adaptation |
| technical uncertainty | known solution | alternatives still under evaluation |
| requirements stability | consolidated requirements | evolving requirements |
| cost of change | low-cost change | expensive physical/contractual change |
| need for feedback | low | high |
| physical irreversibility | low | high |
The greater the uncertainty and the lower the cost of change, the more room there tends to be for adaptive cycles.
The greater the irreversibility, regulatory dependency and cost of change, the greater the discipline required for baseline and Change Control.
Does the organization need to adopt adaptive practices without losing common governance criteria across projects?
Engineering PMO Implementation and Structuring defines minimum standards, tailoring criteria, indicators, gates and decision processes so different methods can coexist without fragmenting governance.
Where agile methods work well in engineering projects
Development of alternatives
In studies and early stages, it is common to develop alternatives, compare criteria and progressively eliminate options.
Short analysis cycles avoid spending significant effort on solutions that could have been discarded early.
Multidisciplinary coordination
Interface Management is one of the best application areas.
Interfaces should be identified, assigned and closed. A flow board can make explicit where a given decision is blocked.
Design Management
Design Management coordinates the process through which different disciplines produce an integrated solution.
Frequent reviews, prioritized packages and clear definition of inputs increase reliability.
Handling RFIs and comments
RFI queues can be managed by criticality, aging and schedule impact.
Document production
Documents can move through states such as preparation, development, verification, approval and issue.
The objective is not merely to know how many documents are “in progress”, but to understand cycle time and where the flow is accumulating queues.
Owner’s Engineering
In Owner’s Engineering, the volume of interactions among designers, contractors, suppliers, inspection, field teams and the client makes visual management especially useful.
OE can maintain formal controls for submittals and decisions while using adaptive practices to prioritize analyses and open issues.
Brownfield and existing-condition surveys
Existing environments contain high uncertainty. Field information changes assumptions and may require replanning.
Adaptive management allows discoveries to be incorporated without losing change traceability.
Where application requires more caution
Safety requirements
Electrical protection, functional safety, structural stability or fire-protection criteria cannot be relativized to “gain speed”.
Documents released for construction
After a certain approval level, changes must be formally controlled.
Long-lead procurement
Equipment with long lead times requires early decisions and sufficient stability for contracting.
External regulatory interfaces
Approvals with utilities and authorities have their own processes and do not follow the project’s internal cadence.
Physically sequential activities
Certain field services have rigid predecessors. Visual management can help, but it does not eliminate the physical logic of execution.
Agile methods and FEL
Front-End Loading may at first appear to be a completely predictive approach because it works with maturity gates.
In reality, there is strong complementarity.
FEL establishes the maturity level required to progress. Adaptive practices can improve how the team produces the information required to reach that maturity.
A FEL cycle can contain several rounds of:
1. gap identification; 2. data collection; 3. alternative development; 4. technical/economic evaluation; 5. stakeholder review; 6. risk update; 7. decision on further development.
The gate remains formal, but development between gates can be iterative.
Agile methods and the PMO
A PMO does not need to choose a single methodology for the entire organization.
A mature PMO can establish a tailoring framework.
For example:
- repetitive and stable projects use a predominantly predictive approach;
- projects with high solution uncertainty use adaptive practices during development;
- implementation retains baseline and Change Control but uses Kanban for RFIs and open issues;
- complex programs combine executive gates with progressive planning.
The PMO’s role becomes ensuring governance, comparability and organizational learning without imposing unnecessary processes.
Agile methods and Engineering Consulting
Engineering Consulting produces knowledge and technical decisions.
This work is particularly sensitive to input quality.
If a team starts a specification without knowing operating requirements, rework is likely. If it waits months to gather every possible piece of information, it may delay the project unnecessarily.
Agile and hybrid management of engineering projects seeks a balance: identify what information is required to start safely and what can mature progressively.
Backlog applied to engineering
A backlog can be a powerful tool when structured.
Where applicable, an item should answer:
- what must be produced or decided;
- why it is required;
- which requirement or milestone it supports;
- which discipline is responsible;
- which inputs are needed;
- who must review it;
- what the completion criterion is;
- what its priority is;
- what the impact is if delayed.
This brings the backlog closer to the real project-management system.
How to define priority
Priority should not be defined only by the person who speaks loudest in the meeting.
Useful criteria include:
- impact on the critical path;
- number of dependent activities;
- technical risk;
- regulatory deadline;
- procurement need;
- operational criticality;
- information value;
- cost of delay.
Items that unblock several work fronts normally deserve higher priority.
Visual management: transparency without oversimplification
A board should show enough to support decisions without trying to replace every project system.
One possible structure is:
Waiting for input → Ready to start → In development → In verification → In approval → Complete.
Intermediate queues can reveal important bottlenecks.
If fifty items remain “In approval”, the problem is probably not production capacity; it is decision or review capacity.
WIP: why starting less can finish more
Excess simultaneous work creates multitasking, handoffs and queues.
When each specialist has ten documents open, individual progress may appear high, but few items reach completion.
Limiting WIP forces the system to finish and exposes bottlenecks.
This logic is especially relevant in project offices and Engineering Consulting teams.
Useful agile metrics for engineering
Throughput
Number of items completed per period.
It can be measured for documents, RFIs, revisions or interfaces.
Cycle time
Time from the start of work to completion.
Lead time
Total time from request to delivery.
WIP
Number of items in progress.
Aging WIP
Age of items that are still open.
Rework rate
Percentage of items that return to earlier stages because of quality problems or missing information.
These metrics complement, rather than replace, indicators from Project Management and Project Controls.
How to integrate agile metrics with schedule and cost
A project can track CPI and SPI at the executive level while simultaneously tracking cycle time at the operational level.
This combination is powerful because the indicators answer different questions.
- SPI helps understand aggregate schedule performance;
- CPI helps understand cost performance;
- throughput shows completion capacity;
- cycle time shows flow speed;
- WIP shows work accumulation;
- aging highlights items that are getting old before becoming consolidated delays.
In other words, flow metrics can work as leading indicators, while some traditional indicators describe performance that has already materialized.
How to implement agile methods without losing governance
1. Start with the problem, not the framework
Determine whether the problem is decision delay, excessive WIP, low visibility, rework, interfaces or short-term planning.
2. Map the real flow
How does a demand enter? Who produces? Who verifies? Who approves? Where does it stop?
3. Separate governance from operational flow
Baseline, requirements and gates remain formal. Production flow can be adaptive.
4. Choose only a few practices
It may be enough to begin with a visual board, WIP limits and a weekly priority-replenishment meeting.
5. Define done criteria
An item is complete only when it meets the corresponding technical criterion.
6. Measure the system
Observe cycle time, throughput, queues and rework.
7. Adjust
The methodology must serve the project. If a ritual does not generate information or decisions, it needs to be redesigned.
Example: multidisciplinary upgrade design for an existing installation
Consider a project involving Electrical, LPS, Telecommunications and Electronic Security disciplines in a brownfield installation.
Governance can establish:
- contracted scope;
- standards criteria;
- milestones;
- budget;
- approval process;
- Change Control.
The technical team can work in cycles:
Cycle 1: validate existing documentation and survey gaps.
Cycle 2: close design criteria and main interfaces.
Cycle 3: develop alternatives and critical decisions.
Cycle 4: issue prioritized basic-design packages.
Cycle 5: incorporate comments and consolidate interfaces for detailed design.
At the same time, a board can control RFIs, documents and impediments.
The schedule still exists. What changes is how the team organizes the work required to meet it.
Example: Owner’s Engineering during implementation
On a construction project, OE may simultaneously receive:
- submittals;
- RFIs;
- deviation requests;
- inspection reports;
- execution open issues;
- design revisions;
- commissioning documents.
A single queue makes prioritization difficult.
The system can classify items by criticality and create classes of service. An RFI blocking a critical work front is handled differently from a document correction with no immediate impact.
This is agility applied to technical governance: respond faster to what actually threatens the project.
Main adoption mistakes
Implementing a tool before a process
Buying Kanban or agile-management software does not fix a poorly defined flow.
Renaming meetings while keeping the same behavior
A daily that becomes a one-hour status meeting is not an improvement.
Confusing autonomy with absence of authority
Teams need to know how far they can decide and when they need to escalate.
Ignoring documentation
Engineering requires evidence. Important decisions should not exist only in conversation or on a card.
Creating a backlog without real priority
If everything is a priority, nothing is a priority.
Failing to integrate procurement and field work
Engineering planning must consider the dates required for procurement and construction.
How to choose among Scrum, Kanban, Rolling Wave and other practices
There is no universal answer.
| Need | Well-suited practice |
| organize work in cycles with a clear objective | Scrum or adapted cycles |
| control continuous flow of documents and open issues | Kanban |
| reduce excessive simultaneous items | WIP limits |
| plan with progressively available information | Rolling Wave Planning |
| improve short-term reliability in construction | Last Planner System |
| maintain formal decisions between maturity levels | Stage-Gates |
| combine everything under corporate governance | hybrid management / PMO |
The organization can use more than one of these practices in the same project.
Are agile methods suitable for every project?
No.
Highly repetitive projects with stable scope and low uncertainty may gain little from a sophisticated adaptive structure.
On the other hand, highly complex projects are not automatically candidates for “more Agile”. If complexity is associated with strong physical interdependence and high cost of change, the answer may require more upfront planning, not less.
Maturity lies in distinguishing uncertainty that should be explored from dependency that should be planned.
The role of tailoring
The current PMBOK emphasizes adapting practices to the project context. The second edition of the Agile Practice Guide also takes a framework-neutral approach and explicitly addresses selecting appropriate life cycles and practices.
This view avoids methodological dogmatism.
For engineering, tailoring can define:
- which gates are mandatory;
- which horizon will be detailed in the schedule;
- which flows will use Kanban;
- which meetings will have a short cadence;
- which decisions require Change Control;
- which metrics will be tracked;
- how documents and evidence will be preserved.
Agile methods as part of a broader management system
The greatest value does not appear when a company “implements Agile”. It appears when flow practices are connected to a broader governance system.
This system may bring together:
- Engineering PMO;
- Project Controls;
- FEL;
- Design Management;
- requirements management;
- interface management;
- Owner’s Engineering;
- BIM and coordination;
- document management;
- commissioning.
It is this integration that turns isolated methods into organizational capability.
Is there rework, review queues, aging RFIs or decisions without a clear owner among disciplines and contractors?
The Project, Program and Portfolio Governance solution structures authorities, decision flows, escalations and control mechanisms to reduce latency without replacing technical responsibility with ceremonies or tools.
When the company should consider this approach
Some symptoms justify evaluating agile or hybrid practices:
- documents remain under review for weeks;
- decisions have no clear owner;
- too much work is started and too little is completed;
- meetings produce lists but no closure;
- RFIs age until they affect field work;
- disciplines discover conflicts only near issue;
- a schedule exists but does not guide weekly work;
- changes happen informally;
- the PMO is perceived only as a reporting area.
In these cases, the response does not need to be a complete methodological transformation. Often, redesigning the flow, establishing cadences and integrating short-term planning with governance already produces significant gains.
A3A Engenharia uses management, planning and governance good practices as applied to Engineering Consulting, Owner’s Engineering and project management, selecting tools according to the maturity, risk and technical nature of each project.
Technical references
[1] PROJECT MANAGEMENT INSTITUTE. Agile Practice Guide — Second Edition. PMI, 2026. Available at: PMI.
[2] BECK, K. et al. Manifesto for Agile Software Development. 2001. Available at: Agile Manifesto.
[3] SCHWABER, K.; SUTHERLAND, J. The Scrum Guide — The Definitive Guide to Scrum. November 2020. Available at: Scrum Guides.
Frequently asked questions
They are approaches emphasizing adaptation, collaboration, transparency, feedback cycles and value delivery. Agile is a broad concept; Scrum, Kanban and other practices are specific ways to operationalize some of these principles.
Practices from Scrum, Kanban, Lean, Last Planner System, visual management and Rolling Wave Planning can be useful depending on the type of work. Application is normally hybrid and must respect technical requirements, contracts, standards and physical dependencies.
Some elements work very well in knowledge production and coordination, but literal adoption is not suitable for every activity. Physical work, procurement and long-duration analyses must respect their technical nature.
Agile is a broad set of principles and adaptive ways of working. Kanban is a flow-management approach based on work visualization, WIP control and continuous improvement.
No. Contemporary PMBOK guidance allows different ways of working and tailoring. In engineering, agile practices can be combined with scope, schedule, cost, risk, governance and documentation management.
Yes. They are especially useful for organizing RFIs, submittals, open issues, revisions, interfaces and decision cycles, provided technical approvals and formal records remain traceable.
Complementary technical materials
Related solutions
- Engineering PMO Implementation and Structuring
- Project, Program and Portfolio Governance
- Requirements, Evidence and Acceptance Criteria Management
Related engineering services
Related technical content
- Agile and Hybrid Management of Engineering Projects
- Project Planning with Rolling Wave Planning
- PMO: what it is, types and functions
- Design Management in Engineering
- Interface Management in Engineering Projects
- Requirements Management in Engineering