Many professionals working in construction think of the Agile approach as something that other sectors do. As the person tasked with leading Staticus’ agile transformation, you can probably guess that I have a different opinion.
But to implement the Agile methodology effectively, leaders need to understand which tasks and operations within their construction company are well suited to Agile, and which are not.
So, in this short article I want to share my experience regarding when Agile is right for construction and engineering companies, and when it isn’t. My argument is that there is definitely going to be some use for Agile in your company, it just might not apply to every team and every task.
But before we get into when to use Agile ways of working, I want to briefly address some of the fears companies in construction have around this project management tool.
Why construction companies fear Agile (and why they really shouldn’t)
The perception of Agile is that it is mainly for tech companies. So it’s natural that companies in construction initially look at it with some doubts.
After all, why would a methodology built for a completely different type of company, developing a completely different type of product, be right for us? Can the approach used to develop and build an app really be applied to designing and installing façades?
Another doubt is around employees. Will team members who are used to working in one way really be ready and willing to adapt to new methods of working?
These are fair questions. And my answer is that, as modern construction companies, we have much more in common with other sectors than you might think.
For example, many of the processes are the same:
- We have to figure out a concept,
- We have to identify the materials that we’ll need,
- We have to find a way to assemble these materials in one piece.
Ultimately, we’re all still trying to answer the same basic question: How do you build a valuable product for your customer?
So, even if the products and customers are different, the ideas and the processes can be similar.
When is Agile suitable in construction?
As I mentioned in the introduction, it is really important not to introduce Agile for all your processes and teams. Some teams and some tasks are simply not a good match for this way of working.
So, I want to take you through my experience of which teams and people are a good fit for Agile, and which are not. Let’s start with which are not.
Avoid Agile if the tasks are standardised and have strict requirements
Basically, if you’re working with tasks that are standardised, repetitive and where the regulations and requirements are very strict, Agile isn’t a very good fit.
As Head of the Quality and Process Division at Staticus, I oversee quality control for lots of tasks like this – and I know Agile is not the right process to use. Here’s why. Agile is a methodology aimed at maximising flexibility, speed, creativity and (the clue’s in the name) agility. And none of these attributes are particularly important with repetitive, standardised tasks.
Think about the assembly process for a façade unit. For this we use very detailed, step-by-step technologies to put together façades consistently and at exactly the same quality level. For this process, Lean is a more useful methodology (and one we use at Staticus too), because it can make the process more efficient. By contrast, Agile is not very suitable in this case.
Avoid Agile with team members who aren’t ready for it yet
Another point to consider is not just a team’s function, but who you have working in those teams. As I have already mentioned, one of the reasons construction companies are reluctant to embrace Agile is because they think their team won’t go along with it.
I agree that in construction there are probably more people who are used to working in their particular ways. And of course it’s always hard to ask people to change their approach and start working in a different way.
The key lesson I have learned is that you can’t force people to change. If you try to force it you may get people using Agile on the surface, but they won’t really have changed their approach. For example, they might change their weekly meeting to every Monday morning and call it a standup, but in reality, it’s just the same meeting format as before. Furthermore, even if they do change for some time, if they’re not invested in Agile then over time they will just go back to their old ways.
If some of your team aren’t ready for Agile, don’t push them. Instead, create a buzz around it by showcasing the success of team members who have successfully used Agile ways of working. Which leads me on to my first point of when you should use an Agile approach.
Use Agile with open-minded team members who are ready to learn
To implement Agile at Staticus, we started with small steps. We worked project by project, beginning with a pilot project in Oslo – the Økern Portal office complex. We built an Agile team for this project with members from each value chain (Sales, Project Management, Design, Procurement, Supply, Production, Installation). The results from this project were very impressive:
- We achieved project budget implementation above 100%,
- Non-conformities management was improved,
- And we achieved higher client satisfaction levels.
What’s more, the engagement of team members was really good. So we used it as a showcase and gradually started rolling out this approach to more and more projects.
What was the key to the success of that first pilot project? It was the team members. They were all open-minded and motivated to try something new. We have quite a young team here at Staticus, so that helped us find suitable people who were ready to embrace a different way of working.
The success of the pilot project helped us in two ways. First of all, we now had solid evidence that an Agile approach worked. We could share those people in the company who were initially doubtful. Secondly, the team members of that pilot project were really keen to tell others about how the project had gone. We encouraged them to share their experiences, including the negatives – we didn’t want them to sugarcoat anything. After all, the project definitely wasn’t all unicorns and rainbows. This honesty was very useful in persuading others, because they could see it was a balanced assessment. When they said that, overall, their experience with Agile had been positive, people believed them.
Use Agile with your design teams
The biggest benefit Agile will bring is greater adaptability. For us, this is a huge benefit, especially at the design stage. We work on large projects, with an average value of $11 million. And each project is unique, which means they require tailored technical solutions to meet the sustainability requirements of the client and the vision of the architect.
Applying the same approach to design with every project just wouldn’t make sense. Instead, an Agile approach is ideal. We can be proactive, quickly adapt our plans, and respond to any changes efficiently and without sacrificing quality.
In the end, Agile comes down to focusing on the customer, and this is what we have to do with every project. Even if the customer gives us specific requirements, it’s our job to be proactive – to make suggestions and offer better options.
Customers have higher expectations today. They expect fast responses and for us to work as part of their team, as partners and not just subcontractors. The short feedback loops and iterative way of working used in Agile is perfect for this type of relationship. That’s because it requires good communication and the ability to adapt quickly, both of which Agile enables.
A more Agile future for the construction sector
As I mentioned in the introduction, I don’t want to present Agile as a solution for every part of your construction business’ work. But our experience at Staticus shows the Agile is a very valuable methodology to have at your disposal. This is especially true if you regularly do any of the following:
- Collaborate with clients as proactive partners, not merely as subcontractors;
- Work on projects with high levels of complexity;
- Change designs or plans to meet new demands or tackle unforeseen issues;
- Develop and incorporate new technologies into your projects.
I’d be very surprised if your company is not doing at least one of these on a regular basis. Which means there is definitely scope for integrating Agile into your processes.
And regarding that final point on new technologies, I would also highlight the fact that construction is rapidly becoming more tech-oriented (in fact, pretty much every industry is moving in this direction in my opinion). And when you understand that, it becomes clearer that processes designed for the tech sector can work in our sector too.
In the end, the work we do is all about designing a valuable product for our customers. And, in my experience, Agile is an excellent way to help us achieve this.
