An Agile Construction Project

Can an Agile approach be taken to construction Management?  Maybe, but what would it look like?

As a quick background, I spent 3 years in the commercial construction industry on the project management side.  I am currently a product owner in the software development industry.

Scrum in Software Development

This article looks at how a costruction project might take and Agile approach using the Scrum Framework.  Scrum is an iterative incremental framework for managing complex work commonly used with agile software development.  Although Scrum was intended for management of software development projects, it can be used as a general project/program management approach (http://en.wikipedia.org/wiki/Scrum_(development)).   The goal is to identify the highest priority requirements on a regular basis and specify which tasks are needed to fulfill those requirements in a Sprint Planning meeting.  Once the sprint has been planned, the team works on and finishes the tasks, and updates the team on task progress during a daily stand-up meeting, called the Daily Scrum.  At the end of each sprint, the team has a releasable product that can be presented to stakeholders during a Sprint Review.

The main roles in Scrum are; the “ScrumMaster”, who maintains the processes (typically in lieu of a project manager); the “Product Owner”, who represents the stakeholders; the “Team”, a cross-functional group of people who do the actual analysis, design, implementation, testing, etc. (http://en.wikipedia.org/wiki/Scrum_(development).  Let’s look at these roles in more depth and see how they might be applied to construction management

The “Team” needs to be able to work undisturbed by external distraction throughout the sprint.  They are a self organizing group who pick what tasks, scheduled within the sprint, they will work on daily.  They are responsible for understanding dependences between tasks, and planning appropriately throughout the sprint.  Team members are welcome to engage stakeholders about details on requirements.  But outsiders should not themselves confront and disturb individual team members with question and input.  Instead, the ScrumMaster fields all outsider questions.

The “Scrum Master manages the process and protects the team from distractions. He removes all impediment so the team can keep moving forward.  The Scrum master inspires the team to do the right job, and may even have input on tasks.  He or she should have good communication skills, communicating with both the team and stakeholders.  The Scrum master must be able to gauge the status of the sprint.    The Scrum master takes responsibility for product delivery and inspires the team to deliver the expected product.

The Product Owner needs to understand the requirements and relay them to the team and answer and questions around the details.  The product owner needs to be able to make decisions on the fly as necessary, and take responsibility for those decisions.  He or she should time box everything from meetings to sprints.  The product owner should deliver general processes.  He or she should have an open and maintained backlog (contract documents in construction), allowing team members to review the backlog and begin to prioritize upcoming tasks.  There should be an input system in place that enables team members to give input on the backlog.  This allows the team to post real change requests and give input for areas of concern.

Both the Product Owner and the Scrum master work for the same objective: to enable the team to deliver a valuable product (in the case of construction, on time and within budget).  Both must have great trust in each other.  The Scrum master shouldn’t have to worry about not having the proper requirements and the product owner shouldn’t have to worry about daily work being competed.  In the construction industry, the Scrum master informs the product owner of requirements that cannot be implemented as first detailed

So, how could these roles be applied in the construction management process?

Scrum in Construction Management

Because we would want the team to remain somewhat small, we would probably want to limit team members to the foreman level.  The foreman for each trade would serve as a proxy for the subcontractor as a whole (that is, the implementation side).  I would think that for this process to really work, there would probably need to be some hierarchy of teams.  Each trade or subcontractor may also want to have it’s own Scrum master, Product Owner, and definition of a Team, as they are in a sense running their own mini projects, and have their own need to manage resources across other general projects.  But, for now we’ll just focus on the foreman level.

It seems to me that a Superintendent would be best suited for the Scrum master role.  He would be in charge of running the various Scrum meetings and working with the foremen on daily task and implementation details. He would identify obstacles that affect work progress and remove them.  Obstacles due to unclear or unimplementable requirements would be communicated to the product owner.

Optimally, I would see the Product Owner being an experienced Project Engineer.  It could also be the Project Manger, depending on the size of the overall project.  However, on a larger project, the Project Manager should really take on role similar to that of a Product Manager within the Scrum framework, understanding and dictating the vision for the overall project, aligning the project with internal corporate goals and external owner needs.  I’ll follow up on how the Agile process could be used in project selection and successful bidding.  This would also have implications on the Project Manager role.  For now, I’ll focus on the Project Engineer.  Playing the role of a product owner, the PE would need to fully understand all drawings, specifications, and contracts.  He or she would need to have all of this documentation readily accessible to the team for any planning and conflict resolutions needs.  All documents must be kept up to date, enabling all team members to have access to most current requirements.  As the team reviews the most current documents for sprint planning purposes, needs for change requests or RFIs may become present.  It becomes optimal to resolve these before the building process begins for the specific requirements in question. The PE must have tight feedback loop systems in place with all parties contributing to detailed requirements.  This means, at the minimum, the PE must be able to communicate with all architects and engineers involved in the design quickly and efficiently.  He will need these systems so that he can make decisions on the fly that can help the superintendent remove obstacles to building progress.  In many cases this may mean the team needs further clarification on some design detail, most likely resulting in an RFI of sorts.  The PE would ultimately be responsible for time boxing everything from various meetings, outside of sprint meetings, to sprint durations.  He would be in charge of maintaining and often creating general processes around the above listed interactions.

Meetings

Each day during a sprint there is a daily status meeting that takes place called a daily stand-up meeting.  During this meeting, all team members state what they did yesterday, what they are going to do today, and discuss any obstacles in their way, keeping them from accomplishing their goals or tasks.  Any larger issues that may or may not involve other team members are reserved as a parking lot issue that will be addressed directly following the meeting.  The meeting starts on time at the same time everyday.  The reason it’s called a stand-up meeting is because it’s supposed to be short enough that there’s really no need to sit down.  Ideally, the meetings should last all of 15 minutes a day.  It’s the job of the Scrum master to run these meetings.  So, in the construction industry, the superintendent would run this meeting, I would think, first thing in the morning, and would call on the foreman for each subcontractor on site.  If any obstacle were identified by the foremen, it would be on the superintendent to remove those obstacles.  This may involve the Product Owner, in our case the PE.  The PE would also be expected to attend these meetings and give his or her daily status update.  The daily stand-up meeting forces accountability on the GC and all trades and provides insight on the progress of the project on a day-by-day basis.  It also serves as an opportunity for coordination between all trades.  They will all know what each other are doing on a daily basis and will be able to further coordinate after the meeting.  By conducting the daily stand-up meeting religiously, the team will start to work as a well oiled machine and therefore increase efficiency and reduce rework.

I have talked a lot about sprints up to this point, and people reading this, not familiar with Agile Scrum, may be wondering what a sprint is.  In the software development world a sprint is a time-boxed period focused on completing a decided upon set of goals, activities, and tasks.  For the most part there are multiple sprints within a release.  A release represents a complete and sell-able product.  On the project I’m currently working on our sprints have a set duration of 4 weeks.  During these four weeks we work on a set of activities that we have planned to complete within the sprint.  The team gets together during the two day lag between each sprint and fleshes out the details of activities that they are planning to put into the next sprint.  Adding the activities to the sprint and planning resources takes place during the sprint planning meeting.

This is where I’m on the fence with how this would work in construction management.  If the team were to decide to work within regular (same duration), specific time frames for each sprint, the work might be a little bit difficult to split up. This also works best, when a schedule has not been decided upon up front in as much detail as a construction project schedule has.  Construction management does much of the design and planning up front, before the shovel ever hits the dirt.  This works well in the industry and it’s most likely not going to change anytime soon.  However, even with good planning up front, many unknowns present themselves throughout the project.  On my last construction project I believe we ended up with over 500 RFIs and several other forms of change to the contract documents, and I don’t believe this is all that uncommon.  With that many changes, there’s always opportunity to increase efficiency in the change process, as well as, reducing the amount of changes through process improvement!  Not all changes are due to incomplete design documents.  Many are a direct result of poor communication and coordination.  This is where I see opportunity to work more efficiently within specified time boxes that focus on specific chunks of work.  I see a lot of opportunity for efficient resource loading, as each trade can focus on the goals of the sprint and move resources as necessary from project to project.   So, instead of sprints all being the same duration, I would suggest starting with schedule milestones, as these often represent completed, even some times occupy-able, portions of the overall project. Milestones can very from the completion of a wing of a building to closing in the exterior.   For this reason, Project Engineers, most often with the help of Project Managers, will need to decide how best to split up the work and form these time boxes that can be used for sprint planning.

Once the milestones/sprint time frames have been chosen, the team can begin the sprint planning process.  This is where the goals, activities and tasks are detailed and resources are accounted for.  I really see great opportunity here.  Because the schedule is already in place, and the high level activities such as “frame in room A”, along with estimates, have been already worked into the schedule, the key here will be to accurately plan for resources.  As a side note, this is kind of the opposite way it happens with Agile projects in software development.  Usually the team has a set amount of resources and plans for what activities those resources can feasibly complete in a specific time box.  In the construction industry, resources are often moved from project to project on an as-needed basis.  During sprint planning, the team would sit down for a day and go through all of the upcoming activities and start to flesh out the task and resources needed to compete those activities.  The PE would lead the meeting, and I picture planning going something like this:


PE: ABC framers, I see we have an activity coming up in this sprint for framing and finishing room A.  We need to get this done by xyz day in the sprint in order to allow for the painters to get in behind you.  So, given this time frame and all other goals of this sprint, what tasks do you need to perform to complete this activity?  What are your estimates on these tasks?  What resources do you have and/or need to complete these tasks?

Framer: Well, we’ll need to complete 1,2, and 3 tasks, and with this short schedule, that will require us to have x amount of guys out here from this date to that date.


These types of conversations will provide valuable, in-depth insight into project tasks, and validate or invalidate current resource planning.  For instance, the framer may say “I can’t get the guys necessary to complete these tasks, within the given time frame.”  The issue is now in the open, and can be planned around by a talented team.  And because all trades that will be working within the sprint are represented, these work-arounds can be planned immediately and affectively!  After the meeting, all team members will have agreed upon and know what is expected to be completed within the sprint.  They will know what guys to get on site and when.  The reason this provides so much value, is because it keeps the entire team fresh and focused only on the work at hand.  Often times construction projects can run for many months and on into years.  It can be very difficult for the team to digest huge schedules and constantly be on top of resource planning.  It creates a very definable level of accountability and facilitates collaboration across trades!

In a perfect world, it would be highly beneficial to involve architects and engineers in sprint planning.  If it were my project, I’d force it.  In software development, the people who write the requirements and test them are always involved in these meetings.  That’s because all software must be testable and accepted.  In the same sense, this holds true in the construction industry.  I believe a good portion of the punch list can be knocked out incrementally.  Imagine this continuation of the above scenario and the value it would bring to the project:


Electrician: Before you guys dry-in, I’ve got to get my electrical stubbed out.  I’ve got the guys to do it quickly, so I don’t see it being much of an issue.  I just want you to be aware of it.  Also, I noticed that the hanging light fixtures don’t have a spec.  We need to get a submittal in on these, but aren’t sure what is wanted.  We can hang them in the next sprint, but there may be a substantial lead time for getting them here depending on the vendor.

Electrical Engineer: Oh, I’ve been meaning to send out an addendum on that.  We want to use vendor abc.  I’ll get the change out to you as soon as I get back to the office.  Also, I can come out that week and complete my punch list in this region if you like.

Superintendent:  I can also schedule the inspector.  Because we’re always prepared for him and make his life easy, he’s willing to come out multiple times throughout the project.

Framer: Yeah, this works for us.  Also, sense we’re on this subject, we noticed that the texture for the drywall wasn’t called out in the drawings for this room.  We’ve been using orange peel throughout most of the project.  Is this what we want here?

Architect: Yes, that works here.  I’ll put out an addendum for the finish drawings specifically calling this out.  Also, when I come walk the punch list, I’m going to be specifically looking for xyz.


This back and forth has gotten a lot of the key players on the team in sync and has already reduced time in RFI composition and possible rework for making incorrect assumptions.  The engineer and architect have specifically stated what they will be looking at on a punch list walk and the building inspectors are getting involved early in the project.  To me, this is what Agile is all about!  If the various items hadn’t been specified yet due to missing owner requirements, the A/Es could go get these now, or it could be brought up in the owners meeting.  The owner would then know the current stakes and would need to make a decision accordingly.  I see great opportunity in using some sort of this Scrum-like framework in the construction industry, and I hope this post intrigues industry professionals to consider adopting some flavor of this framework.  I believe it could provide a huge competitive advantage!


Upcoming follow-on concepts I hope to write about soon:

  • The role of Project Manager within the scrum framework
  • Agile effects on radically reducing task dependencies
  • Paired programming: could this concept be applied to paired trade coordination?
  • Modular, independent units: stagging
  • Refactoring: change orders
  • Flexible architecture that allows for decisions at the last possible moment
  • Resource Allocation:  know how many guys you have, how many hours they work, and how much work can be done in those hours
About these ads