The Double Hat of an Architect in Agile
I said in this post that I lead architecture teams. That is in fact a very non-Agile thing to say when I put it like that, out of context. Agile requires cross-functional teams consisting of every role that is relevant for the product that the team creates: software engineers, platform engineers, product managers and normally a few other roles including that of an architect. The team must be as autonomous as possible. Without a complete skill set to create their product, the team depends on individuals who are external to them and have competing priorities, and that affects their ability to deliver that product in short increments and feedback loops.
You may wonder if the conclusion that follows is that “architecture teams” do not make sense in an Agile context. Well, I defend that this conclusion is actually both true and false.
The conclusion is true in that cross-functional team sense. The architect must not be the individual that, for being external to the team and with competing priorities, affects the team’s ability to work incrementally and create their product through short feedback loops. The team needs to be able to count on the architect being available to them in every iteration. Almost by definition, in Agile the product is not fully defined from the start of implementation or at any other stage. What follows is that there is no such a thing as defining the architecture upfront either [note: future post on this topic].
The architect needs to be available and contributing to the team on how to technically enable the product features in every iteration of that product or, in other words, the architect must be a member of the cross-functional team and wear their hat.
The conclusion that “architecture teams do not make sense in Agile” is however false — very false! — in another sense. The architect plays a key role in providing to their cross-functional teams a wider technology context than that in which the team operates. Unless their product is extremely small, an organisation will not have one cross-functional team only. It is a lot more common that the actual customer facing product is created through the assembly of smaller products developed by multiple individual cross-functional teams. Think of the teams producing services or libraries, as well as teams responsible for an ERP system, for example. Those teams count on their respective architects to provide them with the wider technical context of which their products will be part. Otherwise, their product would be like a piece of a puzzle that is required but does not quite fit in that puzzle. And what is it that enables the architect to play that role for the cross-functional team? He or she needs also be part of an architecture team. To be clear, this does not mean that architects should take a technical problem away from their cross-functional team, solve it with peer architects and then come back to the cross-functional team with a solution. This is to be avoided since it also introduces an external dependency that affects that team’s ability to work in short increments. Moreover, there is nothing cross-functional about that problem solving approach — how does it account for the considerations of the software engineers, or the product managers, or the automated testing engineers, for example? Instead, what being part of an architecture team means is for the architect to be constantly exchanging with their peers how the solutions of their respective cross-functional teams are evolving. The architect does not need to know about the detailed inner workings of the solutions shared by their peers. The architect needs to know just enough [note: future blog post on this topic] so that he or she will be able to bring the wider technology context to the cross-functional team as soon as that is relevant to them. Together with that cross-functional team, the architect then solves the technical problems that apply to the current iteration of their product.
Notice that I am being very faithful to the definition of team when I say architecture team here. To successfully play that role in the wider organisation, the architects must not be simply a group of individuals with the same job title working in the same area of the company. Instead, they are a team because they share a key goal that can only be achieved through collaboration between themselves. That key goal in question here relates to the full technology context for their area of the organisation.
The architect needs to actively work towards a shared goal with their peers of forming and evolving the full technology context and for that they have to wear the architecture team’s hat.
Therefore, as an architect in Agile, do not hesitate. Do wear both hats. Be part of cross-functional teams and wear their hat. Be part of an architecture team and wear their hat, too.
