Applying Agile methods to building design

When it comes to how teams are managed and work is delivered, it might be time for building design professionals to follow the lead of software developers and get Agile, writes Andrew Corney of Trimble Sketchup

Believe it or not, building design and software engineering have a lot in common. In both cases, you’ll see diverse technical teams, made up of individuals working independently on tasks that together add up to an integrated product.

Sometimes, these individuals will work on multiple projects simultaneously, each project with its own managers and clients. Balancing the competing demands of multiple projects makes careful time management essential – but it’s probably fair to say that, while doubtless highly skilled, individuals working on building design teams aren’t always as good at time management as software engineers.

Building design, after all, tends to take a macrolevel focus, bringing together large teams from disparate firms. Software project management, by contrast, takes a micro-level focus, enabling small teams of engineers to be highly productive.

Which leads me to a question I’ve often wondered about: Could a more micro-level focus, as seen in software development, help to improve the effectiveness of building design teams? Waterfall problems To answer that question, it’s helpful to understand how modern software is developed. At one time, this was a ‘waterfall’ process, in which all decisions were made before development work could begin.

But with the introduction of Agile processes, that has changed. Now, the delivery of work is structured so that progress is constantly checked and design direction can be altered accordingly, with very little wasted effort. Building construction, by contrast, is almost by necessity a ‘waterfall’ process. A design must be completed before its creation can begin. While agile execution may be possible in large-scale building projects, it still feels a long way off in most cases. However, when we directly compare the creation of a working piece of software to the creation of a documented building design, some important parallels emerge. Both have: • A loose conceptual vision, which needs to be developed and refined over time into a working solution • A need for flexibility and adaptability, as more information becomes avail-

able or project requirements evolve • A high level of interrelated dependencies, which need to be developed individually, but can easily trigger change requirements in each other Arguably, many building design teams seek to minimise cost by operating with a waterfall mindset. That essentially means waiting for a perfect set of design ‘‘ When design requirements before starting so that change can be avoided. The notion that we need to know everything before we professionals are can begin is somewhat ingrained in engiassigned multiple tasks, they may neering, but it may not be the most costeffective way to operate. In other words, the way that software end up pulled in development teams are structured different around agility could potentially lead directions and confused about building design teams to big productivity gains, too. To illustrate how this might work, let’s compare three approaches to the prioritisation organising technical tasks and work.

of work ’’

The ‘business-as-usual’ approach

This is the familiar approach most commonly seen in building design, especially at consulting firms. Here, each company involved in a project is unique and has different management styles and organisational processes.

Projects are run by project managers, who may also lead the technical design of a project, or who may simply be project managers. They plan out the resources

required, based on the available fee. Resource requirements are mapped out against timeframes and deadlines for the project as a whole, and project managers meet periodically as a group, in order to agree on how resources should be allocated, based on remaining effort and, to some degree, work left to be done.

At the beginning of the week, team resources are allocated to projects, with each team assigned one or more tasks to perform as part of each project. Design professionals can often be assigned to more than one project and usually, are not asked to estimate the time it will take to complete the task. Tasks assigned are often things that take longer than a week, and once each team member knows what they are working on, they are left to their own devices, although managers and other staff may check in and make sure everything is okay.

But this process can lead to a number of problems that result in reduced productivity. If someone gets blocked in the process of performing a task, it may be unclear to them what they should work on while they wait to get unblocked. They may end up performing lessimportant or less well-defined tasks, just to stay busy. This is particularly true when a task is being reviewed by others, who may take a long time over it before handing it back for corrections, leading to frequent context switches.

Or, when design professionals are assigned multiple tasks, they may end up pulled in different directions and confused about the prioritisation of work. Again, this creates frequent contextswitching, which can lead to mistakes and longer completion times.

On top of this, the system is not designed to reward the early completion of tasks. Over time, this leads to a culture of spending the time available to complete a job, rather than completing a job as efficiently as possible, which means the business loses the chance to book time savings. This system also punishes tasks that take longer than the fee allows, even if estimations for the work were not carried out. This can lead to work being rushed and incorrect, as well as reduced morale. The Kanban method Kanban is a structured, open framework, in which work is divided into tasks that are visually represented on a Kanban board. This enables everyone on the team to see what team members are working on and the state of each piece of work.

In Kanban, the work on a project is divided into a structure of ‘epics’ and ‘tasks’. An epic is a complete piece of scope; a good example might be ‘Deliver HVAC systems description report.’ A task, meanwhile, is a contained, definable piece of work that contributes to the completion of an epic. A task for the above epic, for example, might be ‘Run load calculations’.

In a Kanban framework, work that needs to be done for the medium-term future is divided into tasks. Although task size doesn’t technically matter, a good-sized task is something that leads to the completion of something meaningful after three to five days of independent effort from a single engineer.

In a building project run along Kanban lines, the project manager takes time at the beginning of the project to divide the known scope into tasks. Once the project starts, the project manager prioritises and assigns deadlines to the first 10-20 tasks. At this stage, tasks include a description, note dependencies and provide the documentation required to start the task. Tasks that are ‘ready to do’ appear on the left column of a Kanban board. Only once preliminary work is complete will team resources become available for the project.

As new team members become available, they assign the highest priority task to themselves, ensure they have everything needed to start, provide an estimate of time needed to complete the work and move the task to ‘in progress’.

While a task is ‘in progress’, a designer might get blocked. At that point, the task is assigned to the person from whom the designer needs information, in the form of a ‘to do’. The person blocking the task is notified and the designer moves to the next highest priority task while they wait. Once a task is complete, it is moved to ‘QA’, reviewed for satisfactory completion, and then moved to ‘done’. Time spent on each task is tracked and free team members move to the next highest priority task when work is complete. Every day, a 15-minute stand-up involving the whole team gives everyone the opportunity to highlight where they are blocked and need help, or where tasks need QA checking. It also allows the team to celebrate work that has been completed. What makes Kanban so effective is that no one can have more than one task ‘in progress’ at any one time, and the priority order of tasks is always clear, guiding which tasks should be worked on by the team at any given moment in time. The Scrum approach Scrum is a more structured version of Agile development, which seeks to create certainty around completion dates for groups of tasks and increase focus for the team working on those tasks. The work is still divided into epics and tasks, but the delivery of the tasks is different.

Unlike Kanban, in which the project

manager has full control over each task, Scrum seeks to allocate tasks into uninterrupted ‘sprints’ that typically last one to two weeks. During this time, tasks cannot be changed or re-prioritised and designers are simply left to complete all of the work in the sprint. A one-week sprint might work as follows. The Friday before the sprint, the engineering team holds a planning meeting to estimate the effort involved in completing tasks and agree on which tasks will form part of the sprint. During the week, the designers have a clear goal – to complete all tasks in the sprint. As designers finish tasks, they are encouraged to look at what is left and focus on how that work can be completed with the time ‘‘ The notion that we need to know remaining in the sprint. This may include helping others with tasks. After all, the goal is for the team to complete all tasks. At the end of the week, the team briefly everything before shares the work that has been completed. we can begin is If deadlines were missed, they discuss somewhat ingrained in where estimates for time to complete work went wrong and why (or work extra-hard to complete the work). engineering, but it In Scrum, a Kanban board is typically may not be the most cost-effective used to help organise the state of each task in a sprint. But the main difference between Scrum and Kanban is that way to operate. In Scrum provides more focus (in the form other words, the of an uninterruptible scope of work for a way that software development week). The trade-off, meanwhile, is less flexibility.

teams are structured around agility could potentially lead building design teams to big productivity gains, too ’’

Agile building design – are you ready?

Scrum and Kanban could both substantially change the way a building design firm organises the delivery of work.

But leadership is essential, because both processes put a stronger onus on the project manager to orchestrate the preparation of tasks and respond to the needs of the team. In many ways, these processes turn project managers into ‘servant leaders’, who strive to clear the way for design work to get completed with minimum disruption, at the highest level of efficiency.

Either way, the tech industry has put huge effort into optimising the process of software delivery and continues to do so. Although the building industry frequently evaluates delivery mechanisms, too, it doesn’t tend to do so at the microlevel of how individual teams are managed and run – but perhaps it’s time to make the change.