Maintaining architectural alignment

- I work with technical architects in organizations all the time. They consistently share with me their concern that agile teams are empowered to define the best possible solution for their product. The architects' goals are to make sure every product is aligned to the overall technical strategy for the whole organization. Needing architectural alignment on a scrum team seems a little counterintuitive at first. In fact, one of the agile principles says that the best architectures, requirements, and designs emerge from self organizing teams. That statement was true when it was written and it's still true today. But as you know, each scrum team doesn't live in a vacuum. In fact, in most organizations, there are many scrum teams. What might work best for one team may break what another team is doing. Also, what might be the easiest solution for your team may run counter to the overall technical architecture of the company. So how does a scrum team make sure they stay in alignment with the bigger picture? Well, there are several approaches you can take to help your team handle this. Most of the time, when a new product is being built, an enterprise architect will be assigned. They'll work with the team and share the architectural constraints. These come in the form of nonfunctional requirements or NFRs. They are added to the backlog. These NFRs are things like response times, coding languages, and server specifications. They don't define how the team codes the work, only the guardrails needed by the enterprise to ensure the health of the technical ecosystem. Enterprise architecture, then, is simply another product stakeholder. It's wise to continue to engage the architects at different times throughout your efforts. For example, make sure this group is represented in your sprint reviews. You can also include them in design sessions. In fact, the release boundaries are a great time to hold informal reviews with them. In these conversations, it's really just a touchpoint to make sure direction and guardrails haven't changed in the last few months. These will assure both the team and the architects that everything is moving in the right direction. All of this could seem like it's undercutting the agile principle we talked about earlier, but it really doesn't. Agile architecture is emergent, meaning that teams are defining the design locally. At the same time, they are intentional, meaning that all stakeholders, including architects, are consulted. Their requirements are also solicited to ensure that teams' intentions match the enterprise intention. Once intentional alignment is established, your team is free to go about designing the best possible solution. You just need to make sure you're treating architects as you would any other stakeholder.