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 in more and more organizations. Agile working tries to add more and more value with short steps. People want to work in a structured way, with the result that they think everything out in advance. But this is virtually impossible if the project is larger.

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 less the items are elaborated. As an architect, you have to spar with the PO about the backlog items. This gives you insight into developments, and you can make choices about the use of (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. By translating the principles into frameworks for your team, for concrete control, it is 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 have to be there for them as a sparring partner. Obstacles at the process level are resolved by the team in consultation with the SCRUM master, but as an architect, you play an important role in substantive obstacles.

By sparring constructively with the team, you try to put the team back on track. 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 architect of the team, you have to make agreements at the start that pay attention to quality control. Developers will not like principles, guidelines and agreements. But they do 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) or “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 made agreements 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 that can be understood by everyone, 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 faster 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 the creation of the Minimum Viable Product (MVP). As an architect, it remains important not to delay the project, but to be keen to see challenges ahead and tackle them 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.