Start Architecture Thinking

You and your team might be accustomed to defining the architecture at the beginning of a project. In fact, there’s an acronym for that: BDUF, Big Design Up Front.

In agile approaches, we expect to evolve the architecture as the product proceeds. The team will add features, iterating over the feature set. The team builds, increments, and refactors the code and tests as it proceeds. Those activities help the team evolve the architecture. However, your team—and any architects your team might want to consult—can and should start thinking about the architecture.

There are several reasons to avoid having an architect hand down architecture for a project:

• Architects need to be part of the collaborative team. Just as we still need project management for agile projects, we still need architectural thinking. Agile projects do not need an architect who is not part of the team.

• If the architect is not part of the team, the project will evolve and the architect will not understand the changes should the team require architectural assistance in the future.

• I have yet to see a project where the architecture didn’t change as the team finished features.

Having architectural expertise on your team helps a team finish work faster. Architects can be servant leaders, coaching people to think about the effects of decisions. Architects can pair or mob with a team to show how to think about architectural qualities such as performance and reliability. (See ​Work as a Whole Team to Create the Product​, for details on pairing and mobbing.) I particularly like architectural spikes (not longer than one day) to experiment, scout, or wayfind in the problem domain.

When I work with people who are accustomed to starting with architecture, I ask them to draw a low-fidelity picture of the architecture they think will work. I ask them to update the image of the architecture as the team progresses.

If I work with an architect who needs to define the architecture at the beginning, I ask that person to explain three things that might go wrong with the architecture. I have found that architects who cannot think of three (or more) things that can go wrong don’t understand the entire problem well enough. They are not sufficient for my team.

I have been able to remove those insufficient architects from my teams. If you have a manager who wants to impose an architect on your team, remind that manager that ​Teams Manage Their Own Membership​.