Whether you are a Product Owner or a Solution Architect, understanding how these two roles interact is critical to working effectively in—and with—your Scrum Team.
The challenge is that there’s not much information on this topic out there, and the Scrum Guide doesn’t prescribe a specific role for the Solution Architect. From its perspective, they are a Developer on the team.
The Product Owner is responsible for maximizing the value of the product resulting from the Scrum Team’s work. The Solution Architect, on the other hand, is there to continuously improve the product’s ability to deliver value in working with the Scrum Team.
Some liken their relationship to that between a Chief Executive and a Chief Technology Officer in a company, with one growing the company and the other ensuring that the company has the technical backbone required for it to grow.
Others say it goes deeper, and that the Solution Architect contributes as much to the operability of a product as he or she does to its development, especially in Scrum Teams where DevOps is more than “just another agile term.”
The Product Owner does this by formulating and communicating the product goal and the themes, epics, and/or user stories on the product backlog, making sure the backlog itself is visible and transparent to the organization, and the items on it are clear to the Developers on the Scrum Team.
Though Scrum doesn’t prescribe what the Solution Architect does, nor how they do it, a useful definition comes from the Solution Architect role as defined by version 5 of the Scaled Agile Framework (SAFe).
The Solution Architect, SAFe says, is responsible for defining and communicating a shared technical and architectural vision. That vision is there to help ensure the product is fit for purpose (it meets the user’s needs) and fit for use (it’s there when the user needs it).
Typically, the Solution Architect does this by formulating enablers and tasks that improve the Scrum Team’s DevOps capabilities and shape the technical backbone of the product, and that ultimately contribute to the product’s quality attributes, which many know as a product’s “-ilities.”
These enablers can be anything from Technical Spikes that help the Developers on the team evaluate options to reduce the risk of selecting a technical approach to Enablers to build features and capabilities into the product, or refactor existing ones to pay off technical debt.
Just like some Product Owners keep a roadmap, which helps to visualize the mid- to long-term direction of the product, some Solution Architects have a runway, which consists of the non-negotiable enabler work that must be done along the way.
Product Owner vs. Solution Architect
|Product Owner||Solution Architect|
|Focus||Business value||Ability to deliver value|
|Visualization||UX Mockups||Solution Designs|
|Planning||Product Roadmap||Architecture Runway|
|Scoping||Epics, Stories||Enablers, Tasks|
|Measuring||Customer satisfaction||Fitness functions|
Driving the Scrum Team’s Culture
The two are also the drivers of culture in the team. From the one side, a culture of understanding and valuing the customer. From the other, one of understanding the solution-design patterns, making the most of technology, and striving for continuous improvement.
When the Product Owner and the Solution Architect work in harmony, the Scrum Team balances delivering value and improving its ability to deliver value with every Sprint.
When they don’t—or a person who can act as the Solution Architect is missing—the Scrum Team becomes the victim of not being able to see the overarching architectural patterns and of having cut corners where they should have been laying foundations.
Driving the Outcomes of the Scrum Team’s Work
The outcomes of a Product Owner’s work are the product’s face, the understanding of value among the Developers, the relationship with the users, customers and/or sponsors, and the product’s usefulness in their hands.
Is the product helping the customer get the job done?
The outcomes of a Solution Architect’s work are the product’s backbone, the understanding of solution design among the Developers, and the product’s ability to be built, tested, deployed, operated, and monitored.
How evolvable and resilient is the product?
Measuring the Value of the Product
Whereas the Product Owner works with a vision and backlog items equivalent to functional requirements in an agile way of work, the Solution Architect works with a solution design and backlog items very much resembling non-functional requirements.
The Product Owner measures the outcomes of their prioritization calls and trade-offs using Net Promoter Score (NPS) or another methodology for eliciting customer satisfaction; the Solution Architect measures fitness functions to determine just how close the product architecture is to achieving its architectural goals.