Architecture: A broken industry

[Alyson Reinholdt, MS]

The current issue with Architecture

Architecture is a broken industry. For clarity, we use the term “Architecture” to refer to the combination of cross-functional teams that are involved in the designing of buildings. The reason we use the term “Architecture,” rather than AEC (Architecture, Engineering, Construction), or Architectural Design, or some other term to define all of the parties from the client to the contractor, is that there currently isn’t one word that is accessible to people outside the industry that paints a broad enough picture of what it takes to design a building. We say “Architecture,” as an architecture for communication.

Missing also from the discussion is a name for the design process itself. There is no name or identifiable technique in Architecture for the design process. There are several tools, namely Building Information Modeling (BIM) - the most high-tech tool-based approach - but it does not contemplate humans talking to humans. Rather, its own process documentation skirts the issue of what people should do when they meet, and it maintains that having design teams communicate through the discovery of clashes is enough interactivity. It is a tool designed by a software firm, so it follows that their solution to every problem is the tool itself.

There are phases in the American Institute of Architects (AIA) design process called Schematic Design and Design Development. There are a lot of words spent describing what gets done in these phases. The process as written, or the blocks and concepts of what is contained in those phases, is not expanded on enough to speak to the highly collaborative drawing production portion of the process - the part where teams combine ideas in the form of drawings through ideation and iteration. The assumptions are that everyone knows of what the blocks are composed. There is no agreement. It’s as if one is making a meal and the instructions say to make a marinara, bread, and pasta, but no instructions are given on what those complex items are.

Another challenge in Architecture is the reliance on legacy thinking and the belief that projects can be planned through prediction. The IT world makes distinctions in processes such as Waterfall and Agile, and it makes further distinctions between complicated and complex problems. Architecture makes no distinctions. Because of this lack of intellectual rigor or epistemology, Architecture has no answer for why people in the industry work abusive hours, or why women and minorities are so massively under-represented in STEM and Architecture.

The focus of The Hickories is to bring Agile approaches, and frequently the Scrum framework, into the Schematic and Design Development phases in the AIA design process – at last iteration, a sixty-two-page document that does not outline the structure of meetings, how people should participate in meetings, how participants should interact, or what tools should be used for managing data.

“We are being ruined by the best efforts of 
people who are doing the wrong thing.”
~ W. Edwards Deming

Without going on too long here, the result of lack of clarity in the existing methods reinforces a pyramidic hierarchy, does not suit a modern egalitarian or humanitarian workforce, and leads to the loudest members of the group running every meeting. This leads to work environments that reinforce male dominance and other biases that The Hickories feels are an echo from the roots of the creation of Management, which have not changed since the days when there were no women in the workplace and minorities were treated very, very badly. We have many stories of women leaving the Architecture and Engineering professions due to gender-related biases in the way offices operate. It is important to point out that the #metoo movement is now making its way through Architecture and Engineering.

The Hickories believes all of these issues can be resolved using methods that other creative industries have been perfecting since the 1960s. As a consultant, and later COO, Michael Combest brought Agile and Scrum into an architectural engineering firm in Kansas City, early in 2014. It was a difficult process, but there was very good and measurable success converting projects and clients to visual management by using Trello. Trello bridged the gap between teams that were always distributed across the nation, on large and small-scale building projects of all commercial types.

Scrum vs. Trello

To start with, it is standard practice for a project to be in a city that is different from where the architect is based, and also different from where the engineering team is based. Because it is cloud-based, Trello solved all of the problems above by allowing teams to see what was on the mind of the Project Managers in both the architecture firm and in the engineering firm.

When The Hickories showed a modified version of Scrum to Arrowstreet Architecture in Boston, we produced a ringing success by accelerating a project that was proving difficult, with the traditional mix of very tight deadlines and evolving criteria. After the project closed, Trello and organic Agile approaches started popping up throughout the office, later converting many internal practices to Trello.

 In short, the best way to break the hegemony of consolidated or cloistered knowledge is to democratize it through visual management. Trello is the best, first tool to put firms and teams on a path that takes advantage of the vision and creativity of the individual players by democratizing project knowledge and by fostering professional debate.

In the two retrospectives produced during the Arrowstreet/Hickories engagement, it is clear, from the voiced opinions of the individual members of the workgroup, that project constraints were causing considerable stress. The final retrospective told the success story: it was the combined opinion that success was a function of the impact of visual management via Post-its at first, followed quickly by a conversion to Trello. Michael Combest played the role of Scrum Master and did this from his office in Kansas (now San Francisco). Trello made all of this possible. The success of the project, the internal water-cooler talk about the success of the project, and the use of Trello caused visual management to take hold, without a directive from top management.

 Visual management via Trello has a side benefit of reducing the reliance on managers to assign tasks – Scrum calls this remedy "Self Organization." During daily stand-up meetings, it was a frequent occurrence that members of the design team would self-select to work on specific segments of the design. This increased design velocity while increasing productivity in subtle and profound ways.

Project Managers are a common constraint on information flow. This is a feature of very old thinking about power and accountability and is not a reflection on the people who are placed into these roles. PMing is a terrible job, because it exists, but somebody has got to do it, again, because the role exists.

Without seeing what needs to be done, teams over-rely on Project Managers to assign duties. This dependency requires the PM to know the capabilities and constraints inherent in the knowledge of every player on the design team, every hour of every day. This absurdist constraint is an Expertism echo from the original pyramidic corporate structure, and it forces very capable contributors to make judgments that result in overproduction and rework. Trello allows teams to not only know what others are doing, but also what others on the team are capable of, and what their level of understanding of the project requirements are, in an impromptu manner rather than in an ad hoc way. Trello makes this free-flowing and open sharing of information possible for distributed teams.

Using traditional methods, teams meet infrequently – sometimes at intervals of weeks or months. The documents and data produced during that iteration time-interval are filled with misunderstandings that have to be reworked (refactoring, in IT terms). This infrequency and lack of transparency ruins the work-life balance of most of the participants: a great deal of overtime has to be worked just to make up for the lack of communication early in Schematic Design and Design Development phases. The Hickories has frequently seen abusive behavior from managers toward staff during these stressful reveals. Top-down responsibility obfuscation is the norm in Architecture because of the lack of available data. Managers are in a position to blame staff when things go wrong. Visual management using Trello breaks this cycle.

Trello normalizes what is known; Scrum gives the team a frequency of interaction; Agile gives the team a known, and measurable, philosophical way to approach problem-solving.

Saying it again, Trello makes all of this possible.

Hickories + Trello

The Hickories uses Trello for everything. We use it to manage the book we are writing, which we intend to leverage for change in the way Big Education teaches Architects and Engineers. We use it for idea-sharing and development of written articles. We are huge collaborators and believe ideas are always made better with more perspectives, which Trello puts up in lights for all to see. Michael Combest even used it to plan the updating of his San Francisco apartment.

As quickly as possible, The Hickories works to move clients to Trello, not merely to make use of the Scrum architecture, but to introduce visual management into the working environment. Most Project Managers work off of tightly-kept paper notes, which are visible only to the PM. Visual management profoundly changes the availability of data. By democratizing the data in this way, idea velocity and self-alignment can happen. Without visual management, teams are run as extensions of the PM, for better or for worse. Even for the better, The Hickories believes teams that over-rely on the PM for directives are 20-30% inefficient. This means that clients are overpaying for the product because of built-in, industry-cultural norms.

Decisions in an Agile environment can’t be made effectively unless the data is available for every member to see. In Architecture, since teams are distributed across the globe, democratizing the data is critical to understanding the trajectory of a given project (product, in IT terms).

We believe – because we have seen it – that Trello and visual management is the key to curing the gender disparity problem in Architecture. The Hickories works to bring organic and radical change to the organization of the Architecture workplace. “Radical” implies “from the root,” or bottom-up architecture. We believe Trello is key to organically evolving Architecture into a modern, humanist state by allowing all parties to see the vision, have a voice, and add to the value in the design process for buildings. All of this will improve the quality of life for the people in the Architecture and Engineering industry by improving the quality of the interaction architecture, or work environment, for the players. The Hickories believes Architecture has an architecture problem. We also believe Trello is the best tool to fix it.