Agile construction?

Agile construction?

Hi Friends,
I had a peer asking about agile in construction and I started to answer but I thought I would put the answer here so everyone can benefit. I worked in construction for 7 years while at the Fred Hutchinson Cancer Research Center. I was responsible for the Project Management of the IT Systems, spaces and

Let’s start off by takeing a close look at our definition of “agile” I tend to avoid the word as much as I can. I use other words like Nimble, Flexible and the like. For construction you will use a combination of agile practices and lean.  In my mind, most if not all agile practices are actually a subset of Lean that works for New Product Development.  The Lean elements that are outside of what is commonly known as agile are optimized for situations where you are dealing with repeated production of the same thing over and over.

My definition of agile is “being able to adapt as fast or faster than the changes are coming at you.” With this definition you can be agile if your delivery cycle is 9 months as long as your change cycle is 10 months. you are still able to adapt faster than the changes coming at you.

Now with this more open definition of agile you can look at something like construction and see that there are multiple agile scales there. Shell and core have a change cycle of  years, while the plumbing system may have a nine month change cycle.

Lets examine: You have the overall scale of the building. Which you might maximize your agility by using modeling to begin with and doing some kind of Virtual Reality. But after you make the decision about shell and core you aren’t going to add floors to a building after the foundation is poured, the foundation cant’ take it.

But you have flexibility in other areas.

Lets take a second and look at the rest of the building. We could use VR to deal with the Shell and core, but what about the MEP (Mechanical, Electrical, Plumbing) systems? Really there is no need to go into excruciating detail of the systems within the building in the early stages (although most often they do).   As a matter of fact it is actually poor planning to do so.  Although you want to know essentially that you will have an HVAC system, you don’t need to specify the model number.  Think about it for a minute. if we have a 3 year planning cycle from first drafts to turnover of the building. If I specified the MEP systems all up front you would be getting a building with 3 year old technology. Personally I would be pissed off if you gave me a building with a 3 year old electrical system, and there is no way you would qualify for LEED certification.

unfortunately most construction does not follow an approach that allows them to be nimble like this.  They tend to specify the detail of what is best at the current moment and then execute change orders later.  This approach allows them to make changes but the CR/CD (Change request/Change directive) process tends to be cumbersome.

How I would approach the construction teams would entirely depend upon their change tolerance.  If  both the contractor and the client are willing to give a nimble approach a try then I would go deep and go fast.   Identify the different agile cycle times and coordinate them.  Minimize the documentation in favor of frequent conversations.  Flatten the organization and get more time from the building sponsors.

Most of the time you won’t get this perfect storm of a amiable customer and construction company. What I would do in that case is take the process I am outlining in my book:

  1. Build great teams
  2. Start having retrospectives
  3. Map the value stream and optimize it
  4. optimize for multiple releases (can you complete a floor at a time? or a wing at a time?)
  5. Get the leaders to meet more frequently with the folks in the field, daily
  6. Make changes to testing. Have systems testers sit with the designers. Nothing is designed with out input from a tester.
  7. Pair people: pair workers on the building, pair managers with managers, pair executives. pairing is awesome but sometimes a hard sell.

ok so there are some random thoughts to start a discussion. I would love to hear what others think.


shout out to Wael Khalil for the question!

By | 2016-10-25T16:20:16+00:00 April 24th, 2014|agile, agile fundamentals, Basics, culture, Design, lean, management, Retrospective, waterfall|0 Comments

About the Author:

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.