How do you make architectural decisions on an Agile project when you have no architect?

During the webinar that I delivered last week Lean architecture - Architecting in an Agile world one of the participants Craig asked the question "what advice do you have for environments where there are no architects but key decisions need to be made?" Unfortunately, there was insufficient time during the webinar to answer that question, so I am giving my answer in this article.

Agile architecture does not necessarily need a specialist 'architect'

When we talk about agile architecture people may assume that we need someone with a job title of 'architect'. During my Lean architecture - Architecting in an Agile world webinar I spoke about the idea of looking for a person or people with the necessary skills, knowledge, experience and know-how to make good architectural decisions on an Agile project.

Agile and Scrum projects place a strong emphasis on cross functional teams and so it is quite possible that the architectural skills you need for the project exist in the senior members of the project team, even though they may not have the word 'architect' in their job title.

So irrespective of title, if there was no architect, who is in a good position to make good architectural decisions, or collectively contribute to those decisions, and are they comfortable to make those decisions?

Make Agile architecture decisions transparent

Whether working with a specialist architect or whether using the cross functional architecture skills of the Agile team it is important that architecture decisions are quite open. On an Agile project these decisions should not be made behind closed doors - many eyes and brains result in a better decisions.

One way to do this is to be very clear about the rationale behind why an architecture decision was made. This may include documenting each decision, its rationale, the architectural principle(s) behind the decision, and why the decision was made, or why a principle applies. You also want to identify the implications of the decision and any counter arguments.

This approach may avoid new people joining a project and re-litigating decisions unnecessarily. Noting that you should reconsider decisions if circumstances change or if new information or learning occurs that may require revisiting a previous decision, which we should embrace on an Agile or Scrum project where change is expected and accommodated in the approach.

For example, often on Agile projects you can make decisions with the best information you have, move forward, and then after a few sprints the decision can be questioned and revisited and it may be appropriate to do so. In this situation it can be very useful to look back at the decision rationale. It may be that the decision was made based on what was known then, and the understood implications. However, now a few months later, you have more information, things may have changed, and the team may have discovered something they didn't know. Therefore the decision could potentially be revisited.

When these decisions are captured and available to everyone then people see these and the rationale is understood. Team members can contribute their input, ensure the various angles have been considered, and they feel like they are listened too and on board.

Capturing architecture decisions in an Agile way

When capturing architectural decisions and the rationale this doesn't necessarily imply comprehensive documentation. The Agile Manifesto values 'working software over comprehensive documentation'. You can still value documentation, you just need to value working software more.

Capturing architecture decisions on a wiki

Architectural decisions can be captured in many ways that may be suitable for an Agile project. For example, recording the decisions in a project wiki is a very useful approach. You can have pages dedicated on the wiki to architectural decisions, they're available and transparent for everybody to see and new people joining the project can be referred to them. A wiki is a good tool because people can often add comments, or commentary, to the decisions.

Capturing architecture decisions as a backlog item

An architectural decision can also be captured as a backlog item or a user story and this can be a smart way to work on Agile projects. It just comes down to the way that the user story is expressed. For example, in a user story you could say "as a security architect, I want to ensure that information in transit cannot be viewed by those who aren't supposed to see it, therefore all traffic has to be encrypted with HTTPS."

Working with external architecture advisers

In my article Agile architecture - Where does an architect fit in a Scrum sprint? I explained four ways that architects and architecture skills might fit into an Agile project. This current article has focused primarily on using cross functional skills from within the Agile team to make architecture decisions when there is no specialist architect available. At times however, you may wish to use a specialist 'consulting architect' from outside of the Agile project team and potentially even outside of the company. 

The Agile team could work with a consulting architect who may look at what's going on, see the outcomes, become aware of problems, and then effectively offer advice or ideas to help the team work through a particular architectural consideration.

A good example could be for the consulting architect to get involved in sprint retrospectives, which is a standard meeting at the end of a Scrum sprint cycle, to help review how the sprint went and identify any issues. They may be able to offer good ways or options to move forward.

The team should feel free to contact the consulting architect when they want help working through a problem with architectural considerations. This is a good collaborative approach in keeping with Agile and Scrum values.

Using a part-time architect on the team

While it is not normal in Scrum to have part-time members of the team (ideally they have full-time team members who are co-located), part-time architect involvement may be an option in some circumstances and teams. Potentially items are allocated to them on a part-time basis on the sprint backlog. They pick up those tasks, and they attend the daily stand-up meetings to report on how those tasks are going. The tasks could be such things as making recommendations to ensure the team meets the security requirements or ideas and designs to ensure the product meets non-functional or system quality requirements such as scalability, performance, and compliance.

Bringing this all together...

Architectural decisions do need to be made on Agile projects. Where an agile delivery team does not have a dedicated person with 'architect' in their job title, the cross functional skills of senior members of the team may still allow the team to make pragmatic architecture decisions. In this instance, it is a good idea to capture the architecture decisions made with supporting rationale. Using consulting architects from outside of the team or the organisation for advice can also be a option or using a part-time architect as part of the team, acknowledging for the latter that you are 'pragmatically' bending the purest view of how Scrum works.

At the end of the day, a continuous improvement approach where you experiment, do more of what works when it comes to making architecture decisions, and less of what does not work, is most likely going to be the best path to take.

Bill Ross is Principal Consultant specialising in architecture and is based in Equinox IT's Wellington office.