Applying agile to building design

Sample Kanban board with design work broken into tasks.

Over the past year, as someone who switched careers from one domain (building design) to another (software), I’ve been contemplating how these industries can learn from each other. 

This year we have spent a lot of time thinking about how to be more agile in our software development process. Agile is a philosophy and way of working that seeks to improve how teams function through improved task management. Unlike the building industry, where loads of energy has been put into macro considerations like integrated project delivery, the software industry has poured intellectual effort into optimizing efficiency at the micro-scale. 

Building design teams that learn from these efforts could potentially realize big productivity benefits to their business. To understand how we’ll explore the problems the software industry has been trying to solve with agile. 

Software design projects are often large, long-term efforts powered by cross-disciplinary teams. Big ideas are established early on but as detail is added, teams need to be adaptable to change and be prepared to redo work or change direction without much notice. Dependencies on other team members are common. Sound familiar?

Agile at its heart: Break big tasks into smaller, manageable pieces.

Agile grew out of a desire to improve the control and predictability of this process. It was important to realize that projects managed as a small collection of large tasks tended to utilize resources inefficiently and end up with outcomes that were not what the client really wanted. 

The key to agile is breaking down these large tasks into smaller, clearer jobs that are big enough to represent meaningful progress, but small enough to be understood and therefore estimated accurately. Tasks are prioritized (and reprioritized) on a Kanban board which improves project visibility and clarifies who is working on what. Once a task is pulled in by a team member, it’s small enough (say 3-5 days of work) that they can be left alone while they complete that job (and that job only). 

How different approaches might address productivity challenges.

This fairly simple concept can lead to remarkable outcomes. Firstly, the project manager is obliged to describe and prioritize the upcoming small actionable tasks their team should work on. Although this sounds like a lot of work, it pales in comparison to the pitfalls of assigning tasks without the necessary context. 

Secondly, by always providing an actionable, prioritized task list, technical staff become free to do new work without risk of confusion. The work that is next to do is clear.

Thirdly, by providing visibility into what everyone is working on, the value of each person's work is clearer. The consequences of pulling that person away from that task are clearer. When a task runs long, it’s also easier to see why and get it under control quickly. 

Finally, the completion of tasks is readily celebrated, offering a regular sense of progress for those at the coalface. 

Few building design firms operate this way. Tasks assigned to staff are often huge, weakly defined - with titles like “schematic energy model” or “concept drawing package” and hard to keep track of. The smaller tasks within these are often prioritized incorrectly. 

Often, staff bounce between projects based on utilization targets (the need to log time to tasks that can be billed for as much of a project’s duration as possible) and long term delivery goals. Progress is rarely celebrated. 

The attached paper explores some of these ideas in more detail. I was excited to present these thoughts at two conferences this year and see how well the ideas resonated with mechanical engineers and energy modelers. We think applying agile to building design could potentially lead to great benefits for any discipline. 

If you are interested in talking more, reach out or join our SketchUp forum on the topic. Thanks for reading!