Agile architecture - Where does an architect fit in a Scrum sprint?

On Wednesday of this week I presented the webinar Lean architecture - Architecting in an Agile world and as part of the Q&A one of the attendees Stephen asked the question "Where does an architect fit in a Scrum sprint?" Unfortunately, there was insufficient time during the webinar to answer that question, so I am going to give my answer in this article.

Agile architecture is an increasingly important subject, as Scrum and Agile approaches become mainstream and as the expectations increase for software when it comes to non-functional considerations, such as security, reliability, performance and so on.

We covered the topic of where an architect fits in a Scrum sprint to some degree in the Lean architecture - Architecting in an Agile world webinar. I discussed three areas where an architect or architecture skills may get involved in a Scrum based Agile project, as shown by the red circles in the above image. I'll elaborate on each of these in the article and also add some additional suggestions.

Architect as part of the Scrum team

In this option the architect is part of the Scrum team, and this is the most embedded way that an architect would fit into a Scrum project.

It may not even be an individual who has the title of 'architect', because the big idea behind Scrum teams is that team members have different skills and their roles may change to deliver what is required for a particular sprint.

So it could be that certain senior developers or other people within the team have got some architecture skills, or are in the best position, or have the best knowledge, to make those architectural decisions.

Those team members with architectural skills or responsibilities by the nature of being in the Scrum team will be involved in the sprint on a day-to-day basis. They'll attend the stand-up meetings, take items off the backlog, and work on them. When working with items on the sprint backlog the first thing they'll do is break those items into tasks. This could involve specific architectural tasks or coming up with a design or an architecture to deal with appropriate security or performance for example.

Architect as Scrum stakeholder

Often architects are expected to work across multiple projects and having a dedicated architect full-time in a Scrum team may not be viable. In this situation the architecture skills may be outside of the Scrum team, potentially as a stakeholder for what the Scrum team is delivering, as shown in the red circle at the left hand side of the above image.

Examples of this may be enterprise, infrastructure and systems architects. They may have concerns or feature requirements relating to what is being developed that they want to address. For example, they may want to ensure that whatever system is being developed complies with the architectural strategy and standards of the organisation. In this instance they may be laying down the high level direction, putting in some constraints, and trying to influence scope.

In this situation the external architect, acting as a stakeholder will be looking to influence the Product Owner's decisions about what goes on the product backlog and what is prioritised, to help achieve their architectural objectives.

Architect as Scrum Product Owner

The other option that I covered in the webinar was the architect being the Product Owner. An architect would normally be used in this role when the Scrum team deliverable is not so much an end user or business functional product. More likely it is going to be a reusable technical or architectural product like a common library or a common service that'll be used by other Scrum teams or projects.

In this case the architect is wanting something created and is making the decisions around priorities and the 'definitions of done' for the product or component.

The Scaling Agile Framework (SAFe) describes this situation where a systems architect acts as the Product Owner and explains how this role is used to create architectural features that are added to the architectural runway.

Architect as independent quality assurance of a Scrum team

During the webinar I covered the above three ways that an architect may get involved in an Agile or Scrum project, but there is also likely a fourth.

Sometimes you see an architect get involved in a Scrum team periodically to undertake quality assurance or to perform reviews. This can be quite a hard role, because the architect in this scenario can be seen as a hinderance to the Scrum team.

The team may be working well, producing, doing the work, and evolving the solution quickly. They have likely made a lot of pragmatic decisions in rapid succession. If the architect only comes in on a part-time basis, just periodically, maybe every couple of weeks, there will be a lot of catching up to do. If the team is waiting for approval from the architect, or the architect is not available to give the okay or to agree designs and approaches then the team may be left waiting.

Furthermore, if the architect requires items to be changed then this introduces rework, and in this instance the architect could be slowing down the Scrum sprint and could even be considered an impediment to the sprint. These scenarios are not in keeping with culture and intent of Agile and Scrum and so are probably not the best way to proceed.

A better way of working is for the architect to say "I've got certain knowledge or skills that may be of use to the Scrum team. Come to me when you want help with something." So the Scrum team sees the architect more as a resource they can bring in to help them work through a problem, or come up with an idea, and to collaborate with.

What is the best Scrum architect option?

The answer as always in these situations is "it depends on the nature of the project".

For example, an architect within the scrum team will probably need to be a 'software architect' (or for an infrastructure product potentially a network or infrastructure architect). They will tend to be dealing with specific software development technologies such as .Net or Java and they will need good expertise in these technologies. Where these skills are available within the Scrum team this option could be the best approach, making good architectural decisioans that are informed from being embedded as part of the team.

The architect operating as a stakeholder, quality assurance reviewer or adviser outside of the Scrum team may still be a very important approach where there is insufficient agile architecture capability within the team, or specific architectural considerations such as enterprise architecture need to influence the team's activities.

Having the architect as the Product Owner will be the best approach when the product the team is delivering is a technical or architectural product, and the architect is the best person to make decisions on the priorities for that product.

But irrespective of the details of how an architect is engaged with an Agile project, the key point (as per the webinar) is that the culture of an Agile approach requires architects to be supporting and enabling the delivery of business value - not as dictators enforcing standards.