What Building Teams Can Learn from Scrum

“The more you overthink the plumbing, the easier it is to stop up the drain.” – Mr. Scott, Chief Engineer of the Starship Enterprise

rugby-scrum

Much of my professional upbringing can be characterized as falling within the boundaries of traditional architectural practice.  I started out working in a small design-build practice which required hands-on construction.  I then moved on to working on large international projects at NBBJ.  Early on, I became enamored by the latest and greatest trends in BIM and computational design.  I was driven to make my own tools, software, and algorithms to solve real-world building problems.  I wanted to be faster…. better.  Yet, while I found much success in applying these concepts to my design work, I was never quite satisfied with the foundation upon which these new capabilities rested.  I speak, of course, of project management.

Even with the great speed, flexibility, and insight that new tools give us, the management-style of a building project has fundamentally remained unchanged.  Linear, sequential planning that is resistant to change continues to be the order of the day… even while our tools allow for iterative design and our clients are demanding a more collaborative process.

Project managers, in many ways, have the most to lose when executing a design.  They are accountable for, among other things, project budgets, resources, and schedule. Traditional project management offers a seemingly structured and predictable methodology with fixed scopes and schedules.

I have now had the fortune of spending a portion of my most recent career as a consultant with CASE.  In my tenure with that team, I directed and contributed to numerous software development projects.  Current trends in software project management offer a much different methodology to building:  agile project management.  Agile represents a different management paradigm focused on high iteration, collaboration, continuous improvement, and evolving customer criteria.

Agile grew out of process deficiencies in the software development world that continue to persist in the world of building.  In 2004, the Standish Group found that the average IT cost overrun was 43% with an estimated cost of $55 billion per year in the US.  One answer to this was the introduction of agile project management which resulted in faster development, faster bug resolution, avoidance of scope creep, and a focus on user needs.  In a recent article in ARCHITECT Magazine, Daniel Davis observes that “While we may marvel at a software engineer’s skill in programming, we should really admire their ability to execute a complicated product on time and on budget.”

One particular flavor of agile is a more prescriptive methodology called ‘Scrum’.  Scrum proceeds from the notion that requirements of a project can sometimes be ambiguous and will emerge over time.  For example, clients will change their mind… and those changes can be unpredictable.  This should sound familiar to anyone who has worked on a building project.

Much of the literature and success stories for agile and scrum exist in the IT world which can make for a difficult conceptual leap for building professionals.  After all, our product is space and hardware… not features and software.  Yet there is much that can be learned in the world of construction.

So what can building teams learn from Scrum?  Here are my top 5 takeaways…

1.  Sprints – Plan for a Unit of Iteration

ScrumIteration

Iteration is the order of the day.  Embrace it.  Plan for it. 

Scrum’s basic unit of measurement is the “Sprint”.  Sprints are short-term efforts focused on achieving a clear goal with a working ‘product’ that can be evaluated to inform subsequent sprints.  For an architecture team, a sprint might be planned with a focus on designing the building facade.  A BIM team might plan a sprint with a backlog of coordination issues to resolve among the project models.  Sprints should be planned in short term periods such as 1 to 4 weeks to keep the team focused on achieving specific goals.  It is also important to note that sprints are fueled by the individual accountability of team members as opposed to overarching process plans to complete tasks.  In this sense, a sprint should require less planning… not more.

2.  Backlogs – Focus on Value, Consider the Effort

We need to be critical of the value of what we’re doing day-to-day.

Each sprint starts with a backlog.  That is, a list of tasks that need to be completed in order to achieve the goal of the sprint.   The emphasis of the backlog should be on the value gained from completing the task with consideration to the amount of effort involved.  As a team executes a sprint, they might find that one task will take a long time to complete, but deliver very little value to the overall goal.  Meanwhile, other tasks may require less time, but deliver a lot of value.  The constrained time frames for executing a sprint causes a team to be critical of what they are doing and its overall value to the project.  This backlog might be refined, grow, or shrink over the course of the sprint.

3.  Retrospectives – Learn from the Past

Reflect on what was successful… and how we can continuously improve. 

Sprint Retrospectives are an important part of improving the process in the next iteration (or project).  In my experience, building teams often suffer from repeating the past without learning from their mistakes.  Project after project, we see the same coordination errors, lapses in communication, and design challenges.  Frequent retrospectives after a sprint allow teams to reflect on what they can do better in the next stage of the project.

4.  Stand-ups – Communicate Fast and Often

The best thing a team can do is talk to each other.

 I really enjoy stand-ups.  They are short, sweet, and they give me a chance to talk to my teammates as a group.  Stand-ups are a chance for the entire team to understand what everyone is doing on a daily basis with 3 minutes or less allocated per person.  Everyone should provide a verbal update on 3 things:  1.  What I did yesterday, 2. What I will do today, 3.  What are my barriers for doing the work.  If there are any barriers, the stand-up organizer (‘Scrum master’) will take note and set follow up actions to resolve the barriers AFTER the meeting.

(Pro-tip:  The biggest mistake I see when Scrum is implemented is turning a stand-up into a detailed hour-long meeting each day.  Stand-ups are meant to be an activity that is respectful of everyone’s time… avoid long-winded discussions. We need to get back to work!)

5.  Team Activities – Establish Transparency

SprintBoard

We need to be more transparent with our activities. 

Developing a building can sometimes feel like a black box and it is hard to see where all the moving parts are.  This can result in team members duplicating efforts, stepping on toes, or ignoring certain tasks.  One tool of Scrum is to establish a ‘board’ which defines the status of different tasks in the backlog.  Each task should have a checklist, a due date, and, most importantly, someone assigned to be responsible for the task.  A Scrum board provides transparency to the entire team as to the status of different activities as the project progresses.  It also holds team members accountable for what they are assigned.  If you have a co-located team, a physical Scrum Board could be made up of sticky notes and a whiteboard.  Remote teams might use a collaboration tool to update each other on progress over long distances.  (Trello is my favorite).

Some other thoughts…

There are many obvious differences between creating software and creating a building.  Buildings carry much more liability, are far more expensive, and take longer to make.  However, the process of creating a building shares many similarities to making software.  Developing a building is a highly complex process with high iteration and subject to changing requirements.  Personally, I have always felt that designing a building with BIM was more akin to developing a piece of software than it is to drawing.  Beyond a building project, Scrum can also be a useful tool for managing the development of internal resources such as standards, execution plans, or training material.

As the IT and software industry discovered, the amount of waste due to inadequate project management was unsustainable.  Agile methodologies, like Scrum, were part of the solution and is finding success in many technology companies around the world.  Will agile project management techniques solve similar problems in the delivery of buildings…?  

It couldn’t hurt to try…


Are you Interested in using scrum on your next project?

Contact Us