As an architect, what is my place in Scrum?
By: Willem-Jan Ageling
Tags: Scrum, Agile, Serious Scrum, Software Development, Work

As an architect, what is my place in Scrum?

Scrum and the stakeholders, episode 3

The ‘Scrum and the stakeholders’ series discusses the place of several stakeholders in Scrum. All its articles have this theme and can be read on their own.

By stux-12364 at Pixabay

Introduction

Scrum knows 3 roles: Product Owner, Development Team and Scrum Master. People outside the Scrum Team are addressed as ‘stakeholders’. On top of that the Scrum Guide mentions ‘committee’, ‘employees’ and ‘organization’, but the umbrella term in Scrum is ‘stakeholder’.

Often stakeholders have no insight in what kind of role they can play. The series ‘Scrum and the stakeholders’ aims to clarify the place of the different stakeholders within Scrum.

Every Scrum environment is different, so there is no clear-cut answer that applies to all situations. Therefore we will discuss the different options to help you decide what is the best solution for you.

This article will discuss the architect who architects solutions and services for organizations. Often the architect is acting outside of the Scrum Team, but this doesn’t have to be like this.

The purpose of a Sprint

“The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.” — Scrum Guide 2017

It is important to note that the outcome of every Sprint should be a potentially releasable product Increment. This is true for EVERY Sprint, so also for the first Sprint of a product.

Scrum knows no Sprint zero where an architectural runway is created. Scrum Teams also shouldn’t start only when a complete architecture is ready and signed-off. This is NOT what Scrum is about. Instead:

“Scrum is a framework for developing, delivering, and sustaining complex products.” — Scrum Gide 2017

And:

“In complex environments, what will happen is unknown.” — Scrum Guide 2017

This rules out having a complete architecture in place before starting with Scrum Teams. It also rules out having a Sprint zero without delivering an Increment. This means that an architect’s role is NOT to prepare a solution before the Scrum Team steps in.

But there’s more, involving the characteristics of a Development Team.

Characteristics of a Development Team

A Development Team is self-organizing:

“No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality; — Scrum Guide 2017

Where does this leave the architect if she/he can’t tell the development team how to create an Increment, which architectural solution to use?

Development Teams are also cross-functional:

“with all the skills as a team necessary to create a product Increment;” — Scrum Guide 2017

One of the skills required can be to design a solution, the work done by an architect. This is a strong argument for having the skills of the architect within the Development Team.

If we then also take into account that the purpose of the Sprint is to create a potentially releasable product increment, we can conclude that the initial Sprint can’t involve architecture only. A big chunk of the work done can involve architecture, but the team should also build a working product, which can be inspected.

Accountability in a Development Team

Development Teams have two other characteristics too:

“Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis;” — Scrum Guide 2017

And:

“Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.” — Scrum Guide 2017

Hence someone can be specialized as an architect, but the team as a whole takes responsibility of how to create an Increment. An architect who is part of the Development Team works together with the other Development Team members.

Architect outside of a Development Team/Scrum Team

Scrum clearly brings forward that a logical place for an architect is within the Development Team. Now suppose that this isn’t the case, how can an architect best approach a Development Team then?

The architect will be a stakeholder of the Scrum Team. As a stakeholder the architect can give advice to the Development Team on how to best create the architecture. Within Scrum she or he can:

attend refinements, discussing the options of how to approach one or more backlog items;

participate in the Sprint Review, giving feedback on the increment and giving input on how to best proceed for the next Sprint(s);

regularly advise the team as needed/requested by the team.

The architect should be aware that by being outside of the team that she or he doesn’t get to tell how the Development Team eventually builds the increment. Surely the team may need to follow the organizational conventions, but this is also true without the architect bringing it up.

Have the architect in the Development Team!

Scrum is a framework that addresses complex products. In a complex environment “only what has happened is known”. This means that Scrum is ineffective when a Scrum Team has to start with a fully ironed out architecture. Instead the architecture should emerge every Sprint.

The best way for an architect to play a role in Scrum is to be part of the Development Team. She or he will be part of a team that has mutual responsibility for all the work, including architecture.

An architect could also have an advisory role as a stakeholder of the Scrum Team, but this means that the architect has less influence on how the team chooses to create the architecture. Because the Development Team is self-organizing, who determine how to build their increment. They have final say in the architecture of the increment.