The 5 Dos Of An Architect In An Agile Team

In an agile architecture environment, you may have the tendency to think everything through in advance, while this actually seems to be odd with the agile method.

How do you act as an architect in an agile team?

In this blog, the inventors of the enterprise architecture tool BlueDolphin will give you 5 do’s that will help you to fulfill your role as an architect within or outside an agile team.

Agile architecture is starting to find its way into more and more organizations. Elegant work tries to add more and more value with short steps.

People want to work in a structured way, so they think everything out in advance. But this is virtually impossible if the project is more significant.

5 Do’s of An Architect in An Agile Team

In this article, we present the following 5 Do’s of an architect, starting with looking forward.

Look at the future from the agile practice.

The product owner (PO) ensures that his product backlog is elaborated, but the further into the future, the fewer items are embroidered.

As an architect, you must spar with the PO about the backlog items. This gives you insight into developments, and you can choose to use (standard) components or development patterns based on principles, guidelines, and agreements.

Besides, as part of the team, you have insight into the technical backlog. It is not self-evident that the PO pays attention to this. Usually, he comes from the business and will have a functional focus. By working closely with the PO, you can discuss the technical backlog and have it included in the product backlog.

Sketch (lean) frameworks

As an architect in an agile team, you have one leg in the team and the other in the Enterprise Architecture. Sometimes, this creates an impossible split.

Translating the principles into frameworks for your team for concrete control makes it possible to keep the team in step with the business course. But remember, as a developer, reading is not fun; writing code is, so keep the architecture as lean and mean as possible.

Support the team

As an architect, you don’t have to be on top of the team; you have to let them figure things out so that their work never gets boring. But when they get stuck, you must be there for them as a sparring partner.

The team resolves obstacles at the process level in consultation with the Scrum master, but you play an essential role as an architect in determining substantive obstacles.

You try to put the team back on track by sparring constructively with the team. Do not be too stuck to the solution and the setup architecture, but to the established principles. The development of the team and the knowledge you acquire may require a reassessment of the choices made.

4 Build a quality culture

As the team’s architect, you have to make agreements at the start that pay attention to quality control.

Principles, guidelines, agreements

Developers will not like principles, guidelines, and agreements. However, they ensure a continuous learning process and easier management of the developed code.
Examples include:

• “if authentication and authorization are used, we use standard X” (principle)
• “We use the guidelines of the NCSC for the security of the application” (guideline)
• “checking in code is only possible when unit tests are paired and performed ”(convention)

Architecture should also consider topics such as development patterns, reuse of components, and compatibility across teams.

Update the architecture

Before the sprint, you have agreed with the PO about the desired solution.

Choices and priorities are also made within the team during the sprint. These choices must be recorded briefly and concisely. This is a challenge for many architects.

When recording, use models everyone can understand, not just the developers (think of simple process models, talking boards, and other methodologies that lend themselves to this). This allows you to capture the architecture faster and make adjustments more quickly in the future.

Conclusion

When you consider the 5 points, you notice that the architect in an agile team works as a facilitator for the PO, the team, and across teams.

Together, you work on creating the Minimum Viable Product (MVP).

As an architect, it remains essential not to delay the project but to be keen to see and tackle challenges before they lead to problems.

Should problems arise during the project, it is the architect’s challenge to find a solution quickly and in consultation with the PO and the team.