🏗 Building planning with agile iteration

You are probably used to building planning as a process to do in details ahead of the design stage. We will see in this article why it is not always the best way to achieve a productive design and why Agile iteration can be a really good framework for Architecture & construction.

Indeed with agile iteration you split the project design in small objective, that you can achieve quickly and that will be presented to all stakeholders. This way of doing allow a better collaboration with all the team, the architect, the engineers, BIM manager, project owner and even construction company.

• It is less costly as you only work on what is really needed
• It allow to have results early and eventually adapt the earlier choices
• It takes profits of the collective intelligence of  the whole team

Agile iterations : from phase to sprint

Iterations, the division of projects into phases, you will tell me, you already practice it! Certainly, there is nothing new in this concept, we are all used to dividing a complex task into several simple sequences. Besides, the project owner does it for us, by segmenting the project in phases, which follow one another: Sketch, Preliminary design, Technical design. We are paid as architects and engineers in relation to the delivery of a phase.

But in agile and scrum, the most popular agile approach. We go further in this division. And specifically at the end of each cycle we take profit to collect the ideas and viewpoint of stakeholders and to guide the design.

The agile iterations must be shorter, ideally around 1 to 3 weeks instead of 2 to 3 months for a classic phase. Also, we introduce the fact that the program at the beginning is not necessarily the one we will do at the end, at least not exactly!

"What do you mean! But contractually, my design team must do everything that is in the program, I pay them for that!" So we say that the program, the demand, is negotiable. What counts more is the delivered value, not the initial contracts / demands.

From one iteration to the next : the feedback loop

We also introduce the fact that there is a feedback loop at the end of each iteration. Indeed at the end of each sprint, stakeholders or members of the design team can propose modifications of the initial request and repriorize the tasks to be done. And it is mainly for this reason that slicing the project into shorter iterations makes sense.

Indeed, it is not possible to know everything from the beginning, the customer's needs, the knowledge of what needs to be done, develops progressively. And in particular by regularly showing the project in the process of being made. You can show for example a demo of the BIM model, or even of any document, perspective, plan which allows all the team members to understand the project in it's current state.

If we recap a bit,

👉 Agile iterations are work cycles shorter than phases

👉 They are called sprint in scrum, but why not milestone, deadline, cycle. The important is that you use a terminology that make sense for you.

👉 Iterations repeat and feed each other.  For example, at the end of the first iteration, you can reorient the priorities of the second one

👉 At the end of each iteration, we show the project to as many stakeholders as possible, to get feedback and orient the next work

But all this is fine, but how is it better to work like this?

Working in agile iterations, why is a better building planning strategy?

Agile approaches were created in opposition to the traditional method. This method, that you all know without knowing its name, is called the waterfall method.

In the waterfall method, the requests come from the top to the bottom where the team just execute what has been planned.

And yes,  waterfall is a nice image. But in fact it reflects more a Taylorism organization of a project, like a factory that would cut a complex assembly into a series of simple operations:

1- Define the program
2- Choose the architectural team
3- Define the project by going into more and more details
4- Choose a construction company
5- Build

Taking only step 1, how can a client know for sure what is important to plan? The people who are most likely to advise him: the architect, the contractors, the engineers, are not even known!

On the contrary, in Agile, only the minimum is defined upstream, the decisions are taken, iteration after iteration between all the stakeholders.

So, working in short agile iterations, allows several advantages:

👉 Limit the assumptions we need to make to adapt to the situation and the current knowledge of the subject in connection with the customer or end users.

👉 Always have a shareable result at the end of the iteration, to be able to ask all stakeholders about their opinions. We call that shorten the feedback loop.

👉 Prioritize at a given moment what is more important for customers, users and give the value right away, instead of making them wait 3 months! Thus avoid the tunnel effect, where you work for 3 months without releasing.

But how to apply this in practice in my projects?

Yes, that's good, but you know the business as well as I do, it will never work in construction! Engineers only start their work when the project is "frozen". The client is picky and sticks to the letter of his specifications.

Yes, I agree, and we have identified and commented on these brakes to agile many times with the agile BIM community during our meetups. But I think that there are nevertheless many possibilities internally or within the design team to change the way of working.

So I propose you to test this iteration work based on what already exists, the design meetings.

📅 In practice, re-schedule with agile iterations you design meetings

So basically here's what I suggest you do:

✅ Decide at what level of collaboration you want/can work, indeed it can be difficult to involve the whole team. But no need to stop there, might as well start at a smaller level, but with a more motivated team. So for example it can be "With the project management", "Just in-house" as an architect or engineer. Or even alone, why not!

✅ Identify design cycles on which to base your sprint practice. For example, scheduled design meetings with the client. If the meetings are too far apart, why not propose more regular meetings! Your client will certainly be happy to hear about the project more frequently!

✅ Try to list the important points for this meeting and judge the priority level with the other stakeholders. Important items are, for example, those that "unblock" another stakeholder, such as determining some structural grid to give the engineer some starting assumptions. We'll talk about prioritization soon to help determine what's most valuable, but for now go with your gut.

✅ Force yourself to prepare a deliverable, even if the project isn't finished. The sooner stakeholders, regardless of their technical level, can get into it and give their input, the better.

So I wish you a great week agilizing your schedule. 👋

And hopefully it allows your team to do better decision and limit the scope of the building planning to the more essentials topics that are delivered progressively and discussed with the all team..

Learn how to use Agile methods for construction projects thanks to our free training by email. You will receive emails like this to move forward with agile.