Immediately after publishing and getting feedback on the article titled “Rethinking Agile: The Need for True Agility in Leadership,” it happened to me that there is an important aspect we frequently overlook or handle in an ad-hoc manner when evolving the technical architecture of product development. This aspect is related to the role of an architect within a complex system, overseeing the entirety of the landscape and providing guidance to multiple teams. This architect holds a bird’s-eye view of the system and plays a major role in steering teams in the right direction.
Scrum defines three key roles: Product Owner, Development Team, and Scrum Master. Individuals not part of the Scrum Team are generally referred to as ‘stakeholders.’
Additionally, the Scrum Guide mentions ‘committee,’ ‘employees,’ and ‘organization,’ but bounded to the term in Scrum is ‘stakeholder.’
Since every Scrum environment is unique and own process, there isn’t a one-size-fits-all answer.
In this article, we’ll deep dive into the role of an architect responsible for designing solutions and services for organizations. Often, architects work outside of the Scrum Team while Tech leads negotiate with the Product Owner when planning.
Let’s go through the Sprint process.
Resource: Scrum Guide 2020
The Sprint
“Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint. All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.” — Scrum Guide 2020
It’s important to understand that after each Sprint, you should have a product increment that could potentially be released. This applies to every Sprint, including the very first one for a product. We normally call it releasable chunks or deliverables for the sprint.
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems. — Scrum Guide 2020
But there is uncertainty,
In complex environments, what will happen is unknown. — Scrum Guide 2020
Only what has already happened may be used for forward-looking decision making. — Scrum Guide 2020
In Scrum, there’s no room for creating a detailed architectural plan beforehand, and the Scrum team shouldn’t wait until a complete or partial architecture is prepared and approved. This also means there’s no Sprint zero or design sprint without delivering something tangible. So, the architect’s role doesn’t involve preparing a solution before the Scrum Team begins its work.
The Sprint Planning (How team organized)
How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value. — Scrum Guide 2020
This suggests that the development teams have the autonomy to organize themselves. But what does this mean for the architect who can’t decide or guide how the development team should build an Increment or specify which architectural solution to adopt? This is a significant consideration because the architect is the one who understands the broader product landscape across various teams. The architect has a view of both the product and the architectural vision for the entire enterprise.
Scrum employs an iterative, incremental approach to optimize predictability and to control risk. Scrum engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed. — Scrum Guide 2020
This means the team should own the necessary skills and knowledge to perform their tasks. However, one of these important and major skills could be solution design and architecture vision, which is typically the architect’s responsibility. This strongly supports the idea of having architectural skills within the Development Team.
Furthermore, when we consider that the primary goal of a Sprint is to produce a potentially releasable product increment, it becomes clear that the initial Sprint cannot focus solely on architecture. While a significant portion of the work may involve architectural considerations, the team should also construct a functional product that can be examined.
This highlights the importance of a design sprint, especially when it comes to aligning architectural aspects such as scalability, platform vision, security, and infrastructure alignments. Achieving alignment on these critical architectural elements cannot be effectively accomplished within the limited time frame of a 1–2 hour sprint planning session primarily focused on feature delivery discussions.
Accountability and Delivery
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master. — Scrum Guide 2020
Therefore, while someone on the team may have specialized as an architect, the entire team collectively takes responsibility for determining how to create an Increment. If an architect is a part of the Development Team, they collaborate closely with the other team members to achieve this goal.
Architects as Stakeholders
In Scrum, architects play an important role in shaping the architectural vision of the organization. They are responsible for proactively assessing the system landscape and planning for the “now,” “next,” and “later” stages of the product. To fulfill this role, architects collaborate closely with their peers and contribute to cross-functional teams within the boundaries of the sprint.
Within the Scrum framework and the sprint’s time constraints, architects take on the role of stakeholders within the Scrum Team.
Additionally, I like to see architects serving as Technical Product Owners (POs). In this capacity, Product Owners must collaborate on managing the backlog. It’s a straightforward matter. Particularly when addressing non-functional requirements (NFRs) and technical components of the system, such as authentication, administrative configuration, and infrastructure, it is often the Architect who assumes responsibility for these deliverables. They possess the vision for the solution and the overseeing of “how” to achieve it.
As stakeholders or technical POs, architects can actively participate in various aspects of the Scrum process, including:
- Sprint Refinement: Architects attend refinement sessions where they engage in discussions about how to approach backlog items. Their input and expertise contribute to making informed decisions about the implementation of features.
- Sprint Review: Architects are an essential part of the Sprint Review, where they provide valuable feedback on the increment and offer insights on the best way to proceed in the upcoming Sprint(s).
- Advising the Team: Architects regularly advise the Development Team as needed and as requested by the team members. Their guidance helps align development efforts with organizational conventions and architectural objectives.
It’s important to note that, although architects have a significant role, they do not control how the Development Team builds the increment. The team still operates within the framework of organizational practice, and the architect’s presence ensures that architectural considerations are integrated into the development process seamlessly.
The architect in the Development Team
Scrum, as a framework, is designed to handle the complexities of product development. It succeeds in environments where the only known aspect is what has already occurred. Consequently, Scrum is not well-suited for situations where a Scrum Team is expected to commence with a fully defined architecture from the outset. Instead, the architectural direction should evolve organically with each Sprint. This leads to intentional architecture and emergent team concepts.
For an architect to effectively contribute within the Scrum framework, their optimal position is to be an important part of the Development Team. This way, the architect becomes an active team member, sharing in the collective responsibility for all aspects of the work, including architectural decisions.
Alternatively, an architect may take on an advisory role as a stakeholder within the Scrum Team. However, in this capacity, the architect’s influence on the team’s architectural choices is somewhat limited. Given that the Development Team is self-organizing, they have the autonomy to determine how they develop and deliver their increment. but that should be aligned with the architectural vision of the organization that needs the guidance of an architect.