agile solution architect

There are only three roles in Scrum, the Developers, the PO and the SM! 

As per the Scrum Guide: 

The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.

The specific skills needed by the Developers are often broad and will vary with the domain of work.

I need to know what is the optimal way to apply the role of solution architects in Scrum

Why? Where does this so-called "role" come from? I'd suggest that there is no optimal way of succumbing to organizational gravity.

Instead, perhaps you should explain that this confection presents a constraint, that the challenge is more one of solution architecture, and that the Developers are held jointly accountable for any decisions made about how to build a quality product.

Thanks for replies

I think the word ROLE made some confusion

In fact, I didn't mean a role in scrum; instead, I meant a (Role in Development team, like developer, SA, BA, ... etc)

I read some articles that explain how does Agile deal with the JOB of architects in Agile (Or scrum) by giving different ideas!

Some suggest that the architect should be ONE person the has ONLY ONE JOB in development team as an architect!, and other suggest that each developer can act as architect

What I understood from  Ian Mitchell reply is that he suggest to let the development team to decide how to apply the architect JOB; and I think that this is the best way

if I didn't get the idea of Ian Mitchell, please tell me

Thanks

Mostly solution architecture are not agile as far as I have seen it is done in the same way as in traditional model. There will be dedicated Architects(external consultants) who give solution walkthroughs to relevant stakeholders and once it is finalised, the development will start in sprints. This happens in large programs to build a product. During development sprints, I have seen them helping PO to understand the flow and participate in backlog item creation. 

When dedicated person doing this job, the work is not distributed among all in the team. Because during sprints they may not involve in coding or testing. So my perspective is to have the team accountable for the solution decision as Ian mentioned. But at the start it may bring some challenges to the team to operate this way and many developers may hesitate if they have experience egos. 

As a Tech Lead, I frequently collaborated with Solution Architects, who were often considered external to the Scrum team. My experiences in this regard were mixed, largely due to the nature of the product being developed.

For instance, when working on a legacy product with limited new technical challenges or opportunities for refactoring, the need for active architectural oversight is minimal. In such cases, it may not be necessary for the architect to be a full-time member of the team.

However, when building a new product or a significant version update, it’s crucial for the Solution Architect to be an integral part of the Scrum team. This ensures they have a deep understanding of both the functional and technical requirements, as well as the team's capabilities. By being embedded in the team, the architect can collaborate more effectively with developers on tasks, ensuring the architecture aligns closely with the evolving product. In this scenario, having an "outsider" architect is less effective and can hinder the team's progress

Hi, I have participated in several agile projects as a solution architect, but not as a part of the team. I have participated in large-scale solutions where the system has to be integrated with others. In this sense, the system that the team delivered was integrated with others and it was necessary to make decisions and definitions that went beyond the system. As a solution architect, I defined the high-level architecture, integrations, what each system should do, aligned with high-level requirements, process mapping, identification of capabilities, etc etc etc. This blueprint was communicated to the team to ensure direction. Then, the SCRUM team created their story backlogs and sprints and worked within an established direction. I only participated in the sprints where I had to detail decisions, mappings, definitions of attributes that are used in other systems, etc. In my personal opinion, the decisions about construction are made by the team, but when they need to extend beyond their scope, in an end-to-end solution, that is where they need help, maybe...

Architecture should be a **team responsibility**, not assigned to just one individual. Here's why and how it works in practice:

1. Most teams inherit existing patterns and will often have to work within architectural constraints from legacy systems or enterprise design patterns. I would suggest Scrum teams can identify those patterns in their Definition of Done or documents like "Architectural Design Records" ADRs.

2. But don't stop there. A self-managing team would debate and agree on the future-state architecture. Remember: The best architectures, designs, and requirements emerge from self-organizing teams.

3. I consider architectural decisions to be working agreements. A good team will discuss, debate, and make architectural choices that fit both technical and business needs. And, like all robust working agreements, I expect (and help) teams to adhere to their own agreements.

4. Many aspects of architecture are fuzzy, and can left as such. But over time, architecture starts to crystalize - some patterns will prove to be more robust than others. As those aspects of architecture crystalize, I advise they can be clearly documented. This can be in the Definition of Done or ADRs (as I said earlier), or any form that ensures visibility and accountability.

5. And incrementalism is important. Instead of trying to design the perfect architecture upfront, teams must learn to work incrementally — they can use each Sprint to move incrementally from their current condition to their desired future state.

And I understand that some people are called "Architect" and feel ownership of certain aspects of product or system design. In rare cases, when the technical domain is extremely unique or challenging - I appreciate those people and the knowledge they can share with teams. But in most cases, most teams that I meet, they're building systems with architecture that is quite standard - there needn't be a specialist. In the latter case, I recommend those architects ought to relinquish control and expand their skills in other ways - perhaps toward team leadership. I describe a learning path for those types here: https://scrum.works/articles/2019/09/Learning-Path-Solutions-Architects/