The 5 do's of an architect in an agile team
As an architect, you may have the inclination to plan everything in advance. This may seem contradictory to the agile methodology. However, you can indeed work agilely within the context of architecture. The question is, how do you best combine these two worlds (working agilely under architecture)? And how do you operate as an architect in an agile team? In this blog, I'll provide you with 5 do's that will help you perform your role as an architect effectively within or outside an agile team.
Agile is becoming more prevalent in organizations, just like working under architecture. Agile working aims to add value incrementally with short iterations. However, it may seem to lack overview and structure as a drawback. On the other hand, working under architecture tends to evolve into a massive and all-encompassing documentation project, becoming a cumbersome tool that hinders speed. People naturally tend to seek structure and want to plan everything in advance, but this becomes almost impossible as projects grow larger. Agile working and working under architecture don't have to be at odds; in fact, they should complement each other to deliver good and maintainable software. Hence, these tips are designed to help architects navigate this landscape.
1 Look to the future from an agile perspective
The product owner (PO) ensures that the product backlog is well-defined, but as we move further into the future, the items become less detailed. As an architect, you should collaborate with the PO to discuss the backlog items. This will give you insights into the developments and enable you to make choices regarding the deployment of (standard) components or development patterns based on principles, guidelines, and agreements. Additionally, being part of the team gives you an understanding of any technical backlog. The PO may not naturally focus on this aspect, as they typically come from a business background with functional priorities. By working closely with the PO, you can address technical backlogs and incorporate them into the product backlog.
2 Outline (lean) frameworks
As an architect in an agile team, you stand with one foot in the team and the other in Enterprise Architecture. This can sometimes create a challenging balance. To keep the team aligned with the business direction, translate the principles into frameworks for your team(s) that provide concrete guidance. Remember, reading might not be enjoyable for developers, but writing code is. Therefore, keep the architecture as lean and straightforward as possible.
3 Support the team
As an architect, you don't need to micromanage the team; you should encourage them to figure things out on their own to keep their work engaging. However, when they encounter substantive roadblocks, be there as a sparring partner to assist. While process-level impediments are resolved by the team in consultation with the SCRUM master, you, as an architect, play a crucial role in overcoming technical obstacles. Through constructive collaboration with the team, you can guide them back on track. Be flexible about the solution and the established architecture, but maintain adherence to the defined principles. The team's implementation and the knowledge gained may require reevaluating previous choices.
4 Cultivate a culture of quality
As the team's architect, establish agreements at the start that focus on quality control. Developers may not appreciate principles, guidelines, and agreements initially, but they lead to continuous learning and easier management of the developed code. Examples include: "Standard X must be used for authentication and authorization" (principle), "We use the NCSC guidelines for application security" (guideline), or "Code check-in is only allowed when unit tests are linked and executed" (agreement). Additionally, the architecture should consider topics like development patterns, component reuse, and cross-team compatibility.
5 Update the architecture
Before the sprint begins, you would have made agreements with the PO regarding the desired solution. However, during the sprint, the team makes choices and priorities internally. These decisions should be succinctly documented. For many architects, this can be a challenge. Use models that are comprehensible to everyone, not just developers, for documentation (such as simple process diagrams, visual aids, and other suitable methodologies). This will enable you to document the architecture faster and make adjustments more efficiently in the future.
Conclusion
When considering these 5 points, it becomes clear that the architect in an agile team plays a facilitating role for the PO, the team, and across teams. Together, you work towards achieving the Minimum Viable Product (MVP). It remains essential for the architect not to slow down the project but to be proactive in addressing potential challenges before they turn into problems. If issues arise during the project, the architect's challenge is to swiftly find solutions in collaboration with the PO and the team.
Related articles:
