Solution Architects In Agile Projects
Each company treats the Solution Architect role with a different set of responsibilities. In all the companies I worked in or clients I worked for, the roles and responsibilities of Solution Architects have differed significantly, except for the core responsibility: Answering the question "How?".
In a consultancy, I was responsible for:
- Understanding the requirements
- Designing the solution
- Preparing the High-Level Design document
- Roughly breaking it down to delivery items
- Roughly estimating the work, the team profile, and quoting the price
- Guiding the delivery teams as an active part of the delivery team
In a bank, I was responsible for:
- Understanding the requirements
- Designing the solution
- Preparing the High-Level Design document
- Explaining the design to the delivery teams answer questions if needed
In an automotive company:
- Understanding the requirements
- Designing the solution
- Preparing the High-Level Design document
- Implementing the proof of concept or the walking skeleton of the solution
- Guiding the delivery teams as an active part of the delivery team
I can give many more examples, even weird ones, but you get the gist. The typical tasks for each role are the same, though:
- Understanding the requirements
- Designing the solution
- Preparing the High-Level Design document
These three items answer the question "How can we solve this particular problem with the requirements and constraints we've been given?".
The core responsibility of the SA role is to come up with the most suitable solution to the problem. Mind you, not the "best" or the "perfect" solution. The "most suitable" solution. We're not crusaders on a quest to find perfection. That path is dangerous; only a Sith deals in absolutes.
However, in some teams, especially agile teams, the boundaries between roles get blurred. Scrum Guide only has three roles: Developers, Scrum Master, and Product Owner. SA falls into the category of Developers, which is defined as below:
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
Because Scrum Guide is deliberate in its vagueness, it creates a question in the minds of the SAs: What the hell am I supposed to do?
You're not alone in thinking this. I also struggle quite a lot with this.
I don't have a straightforward answer for you, but instead of running around to answer any question, keep calm and focus on "How?". That's the most important one.
A typical Scrum Coach would tell you that the following questions are answered by the roles next to them:
- What: Answered by the Product Owner, explaining the requirements in the form of a Product Backlog.
- Why: Answered by the Product Owner.
- When: Answered by the Product Owner and the team during Sprint Planning.
- Who: Answered by the team during Sprint Planning or the Sprint.
- How: Answered by the team during the Sprint Planning.
However, as the SA, you'll notice you can (and unfortunately, will) answer most of these questions if the necessary roles aren't pulling their weight. That's taxing and blurs your responsibilities.
If you don't know your responsibilities, focus on "How?" instead of stretching yourself thin. Understand the problem, find the most suitable solution, and convey that to the team in the best possible way.
Don't worry about who implements it and when it gets implemented. Let the PM and SM decide on those. Ask PM what you should work on and pull that into the Sprint. Then, what you do best: Analyse, design, document, and guide.
Let the chips fall where they may. It's not your responsibility to solve everything.