Today, a friend of mine asked me this question. We both know how companies usually make architectural decisions, but how Agile teams (should) make significant architectural decisions is less obvious. A difficulty with this question is that answer has many perspectives: one could talk about business need, technology choices, documentation, who is involved in decision making, how they actually do it, what kind of meetings, etc.

We could make it even more complex by quoting Grady Booch: “The set of design decisions that minimise the cost of change”. Therefore, it seems that architecting is all about making decisions. Agile teams do have very different way of making decisions compared to waterfall teams:

Continuous decision making

Mature Agile teams spend much more time on making decisions than traditional ones. Ironically, this is often unnoticed because the time spent is spread over all iterations, and more integral part of software development. Compared to waterfall projects, that spends a lot of time in the beginning, an Agile team could start delivering with almost no architectural decisions. In some cases, a team might just start experimenting with a goal of getting early feedback. Nothing is decided yet. The only challenge here is to make sure that cost of change is low enough. This kind of product development has after first few iterations a tipping point, after which certain decisions become more expensive to change.

Pull instead of push driven decision making

You have maybe heard of statements like just in time, just enough, KISS (Keep It Simple, Stupid), and YAGNI (you ain’t gonna need it). This is all good and great, but which factors influence the moment we do take certain decisions? The answer is in the need. The first and foremost need is the business need of current or next iteration. “The first thing on product backlog for our big CRM system is a list of customers. How do we solve this?”. The second need is a product vision created in the process of creating a product backlog. An Agile team will compare each decision against this product vision. In this process, it is often ok to deviate from product vision as long as this is a conscious decision. These deviations result in either changing a product vision, or as a temporary solution. The third one is about two dimensions of quality: structural and perceived. Some call it: internal and external quality. The quality as a driver for architecture decisions is tricky. It is susceptible to various interpretations, and it is the most misused argument for introducing overly complex solutions.

Therefore, an Agile team will never make a definitive decision unless it is necessary for instant delivery in the coming days or weeks. One of my often used mantras: “Do we need to know / decide this right now?”.

A product vision does not influence the moment of decision making, it only gives direction of how product might look like at the end. This direction changes with any significant change in product backlog, or maybe new insights based on technology capabilities.

Everybody is involved in decision making

I remember once a project manager (and now another good friend of mine and Agile coach) telling me in my role of an “architect” to make all architectural decisions. He was observing how challenging it can be to let teams, together with stakeholders, make decisions. He suggested that I should definitely listen to all input, but eventually make the final decision myself. I decided not to follow up his advice and kept organising and facilitating sessions where everyone together makes these important decisions. Despite difficulties, it saved me a lot of time, since I never needed to defend or explain a decision. It was not mine after all. Besides, it contradicts with idea of self-organising teams, and at least one of the Agile Manifesto principles.

There is much more to be said about architecture decision making. Btw, the last one is also the most crucial one. A group of well-educated self-organised craftsmen and -women makes better decisions than an architect alone, despite difficulties in effective facilitation of such process.