(How) do architects fit into Scrum teams?

Currently many companies have an architecture department or board. Nevertheless, architecture is mostly kept outside of the Scrum teams. So, I wonder: how do they fit in? Do they still have a reason to exist?

Who chooses the “how”? The architect or the team?

Keeping architects out of the Scrum teams is not the way to go. Architects do tend to want to change the “how” of the teams. The how should solely be chosen by the teams themselves. Even architects outside of the team should not interfere with that rule, because it causes teams to slow down and can lead to sprint cancellations or scope creep.

The basics of Scrum say that the team should be experienced and trusted to choose the how of implementing any features. So in principle architecture choices should be made by the team.

So what is the role of the architect then?

According to the Scrum principles, the architecture will grow and develop as needed to always satisfy the needs of the organisation, or better put: the customers of the organisation. And at the same time allow the implementation of improvements and new features. (Retrieved December 15, 2016, from: https://www.cloudtp.com/doppler/devops-organizational-change-agent/)

This is easier said than done. Especially in companies with several technologies used by several teams. All having some form of interaction with each other and all in need of solutions from at least one other team in the organisation.

Bring in the agile architect

The best way is to bring the architecture knowledge into the teams. Make sure that one of the team members is capable enough to act as a solution architect and make sure that that person has the authority to make certain choices. Also make sure that the architects do interact and share knowledge with all the solution architects and also regularly with the teams. Or in other words: architecture needs to slim down and be more agile. Keeping everyone in line all the time is a very difficult task and makes the organisation rigid. Giving leeway to some form of freedom and possibility of deviation might even grow the company knowledge and strength.

So now we have architecture in the teams. Is that sufficient to get IT implementations done properly?

I don’t think so. The focus for domain, technology or enterprise architects outside the teams should be on stipulating key focus points of interaction, and making sure that interactions are facilitated with a few rules and guidelines (not with a stone set way of working).

Architectural decisions

Implementation is the domain of the team. But making sure automation is there and monitoring, security and audit trails are not forgotten and implemented properly, is an architectural decision. This decision affects all teams and should be governed, checked and improved whenever necessary. Hence the architects should facilitate the teams in improving those non-functional requirements and making sure this is not overruled, because the team only is only asked to deliver business value. In the end the customer experience is created by the entire company, not just in one team.

“You can’t directly change culture. But you can change behaviour, and behaviour becomes culture” – Lloyd Taylor VP Infrastructure, Ngmoco

Scrum gives architects focus

In other words: Scrum should give the architects back their focus. Something that was lost, due to whim of the day issues popping up and demand for clarification of IT architect rules. The only very important additional qualities needed in architects are: allowing for bottom-up improvements, and learning how to facilitate the implementation of non-functional requirements in such a way that the entire company profits from it.