Architectural design with autonomous teams

According to the agile manifesto, the best architectures emerge from self-organizing teams. The word emerge here has received some criticism, since it seems to imply that this happens automagically (it doesn’t), and that it doesn’t require significant effort (it does). I prefer the verb design here (in stead of emerge), as it indicates an intentional activity. The key message of that (in)famous emergence principle is not to discourage intentional design, but to clarify that agile teams work best if they are autonomous. In other words, no outsider should dictate the architecture – the teams design it.

As a consequence of this, agile teams need architectural design compentencies. Last year Transavia, one of our airline clients, acted on this need. They set out to hone their agile teams’ skills in this area, and asked us to develop an architectural design training curriculum for non-architects. Each of their 20 teams was invited to send a representative to the course, to become a guide to the architectural emergence process in their self-organizing team. Some teams sent product owners, others tech-leads, we saw the occasional information analyst. We got to spend 10 full days with them spread across three months in a kind of Architecture Boot Camp, and learnt a lot.

Autonomous architectural thinking

The learning for us started right away with the selection of the course topics. Apart from the necessary technical content, such as introductions to modern software technologies, application integration and security tactics, we had to get the concept of architectural thinking across. What is architectural thinking in an agile team?

Based on our previous experiences doing architectural design with teams, we decided to focus on two key aspects:

• Seeing architecture in terms of stakeholder value
• Making trade-offs in design decisions?

Architecture in terms of stakeholder value

One of the problems agile teams have with architecture is that it is sometimes perceived as something that inhibits, rather than enables, business value. There can be several reasons for this. For example, under-the-hood improvements such as refactoring or laying architecture runway are seen as leaching capacity from the teams – capacity that could otherwise be used to create new features. Another example are architectural compliance rules, which can cause delays and make the teams feel constrained in their design choices.

In our curriculum we turn this perception around to make the teams and their business counterparts see architecture as a positive thing. A key skill is translating the impact of this architecture work (the enablers) into business terms, facilitating the explanation of their value to stakeholders. This also gives teams confidence to approach business stakeholders to participate in the design of ‘their’ enablers. Course attendees complete a number of exercises focused on speaking the language of the business, such as a business case for technical debt reduction. They also practice techniques such as architecture roadmapping to prioritize enablers based on current and future business needs.

Trade-offs in design decisions

Focus on stakeholder value also informs better design decisions. Knowledge of good design principles by itself is not enough at the architectural level: architecture is context, so for high-impact decisions the teams should be able to trace the decision criteria all the way to stakeholder value. And that often requires a much closer involvement of business stakeholders than teams are used to. But how do we get the attention of ‘the business’ for topics that, at first sight, seem purely technical?

Interesting business stakeholders in design decisions may sometimes look like a hefty challenge, but this is where the ‘architecture in terms of stakeholder value’ skill pays off. Their involvement in the decision process is actually quite essential, because without it the team cannot ask the all-important why questions that reveal the real stories and drivers behind stakeholder requirements. Such background stories often lead to new, previously unknown decision criteria, which in turn can completely turn around the team’s design – leading to solutions that are a significantly better fit to the business needs.

One technique that proved very popular (and easy to apply in practice) is decision stories. A decision story captures the essence of a design decision in one sentence, just like a user story does for a business need: “In the context of <context>, facing <concerns>, we decided for <choice>, and not <rejected alternatives>, to achieve <criteria>, accepting <drawbacks>.” The power of the decision story is that it is concise enough to quickly get your head around the essence of a decision, but still encourages a reasonable level of justification. Including rejected alternatives and drawbacks has proved to be especially valuable, since it reflects the work that has gone into the decision, and shows the team’s awareness of alternatives and drawbacks. The decision story assures the reader that the team has not just followed their first hunch. Teams using this technique find it easier to convince stakeholders that their design is well justified. We use decision stories as a valuable addition to more comprehensive techniques like trade-off tables and ADRs (Architectural Decision Records).

Experiences

That’s it, the skills that we found to be essential to architectural thinking. “Don’t you teach them about modeling and documentation”, you may ask? Sure, we spend some time on that too – but always in the light of stakeholder value, as seen in our value-driven architecture documentation approach.

It is now three months after the first batch of team members attended Architeture Boot Camp, and a first evaluation shows effects of the training coming to fruition. Teams are starting to document design decisions, and to involve their stakeholders in the process. During the evaluation it also became clear that the biggest challenge for some teams is indeed to get business stakeholders’ attention. Teams that were not well aligned with their business stakeholders beforehand found it much harder to apply what they learned. There is also a role here for the organization’s architects outside of the teams – they can coach the trained team members and help deal with concerns that cross team boundaries, riding the Architect Elevator (also part of the boot camp training).

Our discusssions about architecture across the board show that it is not just Transavia that feels the need for architectural design skills in teams. In order to facilitate the development of these skills in other organizations, we recently made the Architecture Boot Camp available as an open registration curriculum. If you’re interested, the first open architecture boot camp will be run in The Netherlands from March to May 2023.