Scrum and the role "Architect"

The basic idea of Scrum is easy to convey. The most important rituals can be learned quickly. The implementation is notoriously difficult and requires a lot of practice. The first stumbling blocks that, in my experience, occur in practice with software products can be condensed into a few contradictions related to the role of the architect or his tasks:

1. the iterative and incremental development on the one hand and the desire for a sustainable software architecture, which is only possible if the possibly necessary major conversions are tackled first and thus no quick added value for the customer is created

2. the self-responsible and self-organizing approach of Scrum Teams on the one hand and the joint work on a single large product, which is to be developed uniformly with several teams (toolchain, compiler, version control system, CI/CD, etc.) and thus the self-determination of the team is undermined

The task of an architect is usually interpreted in such a way that it specifies what the overall design must look like and often on top of that,  according to which paradigms and with which tools must be worked. So it is precisely this role that should take the side of the "non-agilists" at points 1 and 2, one should think.

Regardless of whether the team members are more for or against agility, either way the obvious questions will be whether there should be an architect in Scrum at all and if so, shouldn't he or she at least be part of the team and act more as a coach and not as a decision-maker?

When I was confronted with these questions, it was very often possible to quickly show the teams based on their own history that it is not possible to plan a complex product completely on the drawing board. Seamlessly afterwards, there are always memories in the collective memory of a development department of large-scale fundamental reconstruction work of architecture and design, which in retrospect turned out to be much more time-consuming than expected, which could not be completely implemented to the end and which, moreover, did not reach the actual planned goal. This then always unfolds a more or less loud criticism of the previous architect, who is said not to have done a good job, or the idea of an obviously necessary fundamental departure from this Rolle.

More or less two opinions remain as a result of such discussions:

1. Essentially, an architect is superfluous, because it simply does not work to work out large conversions on the drawing board and therefore we simply do not open such "major construction sites" anymore.

2. An architect is still necessary, because otherwise nobody keeps track of the design and the code base and this leads to a poor quality product that is difficult to maintain and extend.

In fact, these two positions are not only not far apart, but hardly contradict each other: People who tend to opinion 1 usually very quickly admit that the quality of the product must of course not suffer and therefore "of course" a coordination between developers of all teams must be passed on. Persons of the second group, on the other hand, have no problem with the fact that there does not have to be "one" architect, but that this task can of course be taken over by members from all teams.

At this point, the architects involved usually realize that it is a great advantage for them that they no longer have to be solely responsible for the overall design, but that it is much more practical and reassuring to be able to work with developers from all teams. Then it's usually done: the team members agree on a regular vote on planned projects that will have an impact on the entire code base or approach, and the architects are present and act more as coaches and mentors than as decision-makers. Whether architects then formally retain this title, whether they are formally part of a team or not, or whether they are even merged with the title "developer", can be agreed on a case-by-case basis with the participants and thus take personal sensitivities into account.

More than a side note but not directly to the matter:

Such discussions should not be left to themselves and should be very well prepared and moderated, because personal sensitivities between participants can of course come to light on this occasion and passionately led also easily poison the mood. Such conflicts, which have nothing to do with the actual matter, should be channeled and addressed and clarified in a separate conversation.