Scrum and Architecture

| |

I am currently trying to find my way as an architect on a Scrum team, and I am finding it pretty difficult. I feel that, Scrum by itself largely focusses on 'what' needs to be build, expecting the 'how' to somehow magically happen by itself. Worse, software customers tend to focus on concrete, visible functionality, often expecting quality (performance, robustness, modifiability, etc.) to be implicitly handled by a ‘good’ development team. If these quality aspects are not part of the process somehow, it becomes a challenge giving them sufficient attention. Unfortunately, there are always lots of ways some functionality can be realised, but only a few that all stakeholders will be happy with in the long run. 


The Scrum police where I work insists that I am part of the core team, and therefore, I need to work on tasks from the Scrum board like everyone else. However, as an architect, I am accustomed to be working on different things than the developers, i.e. the broad lines, vision, coordination, quality aspects, consistency, technical option evaluation, frameworks.  If I, without a separate role, start to work on different tasks than those on the Scrum board, I create some form of elitism which is obviously undesirable and goes against the team effort. I do believe a single prioritised backlog thing is a very good way of making sure the right things get developed in the right order. The challenge then is to make sure architecture aspects do become part of the tasks on the backlog, and the other elements of the Scrum process. 


So suppose you are lobbed into a Scrum project/team and are expected to provide some (technical) guidance and help create quality applications. How can you perform the role of architect in a Scrum team. Below I list a number of strategies I found thus far, for which I consulted with peers. 


Separate need for design from doing design 

When recognising a need for investigation (i.e. the need for an new technology, a library, an algorithm or a structure), split recognising the need from actually investigating it. Submit the need to the product owner as a backlog item. Some Scrum purists might argue that this is wrong because the item does not deliver functionality to the stakeholders. This is true, However, you should be able to argue which backlog items benefit from the investigation, stories which typically will have no or a very high point estimate. That estimate might need to be revised once the investigation is complete. An advantage of this approach is that, compared to having an appointed architect, any team member can work on the story, giving them an opportunity to learn and bolstering the team effort. In your informal role as architect, you should verify that the outcome is sound, documented, and communicated to the team.


Planning is design

The planning meeting is in fact also a design meeting, where the solution is designed by the team as the story is split into tasks. As architect, you ought to prepare and think about this prior. Again the advantage is that the design is thought of, discussed and agreed upon by the team, very efficient. The design should be recorded as part of the session notes, and documented. 


Liaison tasks a backlog items

Reserve time for meetings outside the team as backlog items. I often get dragged away for meetings with vendors, stakeholders, customers. This might be considered part of the 10% of the time the Scrum team uses to support the product owner, but at least for my setting, the amount of time this consumes is considerable.  


Separate dependencies on external factors.

Our project, focusses on integration with external parties. As such, many backlog items require the involvement of other teams, partners and customers. Those involvements often mean delays, unexpected problems, agreeing on test times and other things, make it very hard to complete the story in one sprint. There is a very high risk of not competing the story due to some unforeseen circumstance. We have found it advantageous to split those stories into:

  1. A backlog item for any agreements that need to be made before actual work can start on the story.
  2. A backlog item for the work to done by the team that does not involve any external parties. 
  3. A backlog item for connecting and testing with external parties/other teams. 

This way, we prevent stories from falling out of sprints. While the value to the stakeholders might not actually realised until the final story is delivered, the chance of not completing a story is greatly reduced. The first and third also often require management attention.  


Architecture and training sprints

Some Scrum guidelines say one should begin a project with a ‘sprint 0’ in which the architecture of the system is determined. Or more likely refined, as some work typically was done in a pre-study. In our case, since we upgraded our technology, we spend an entire sprint in training the team, also providing some room for free-format investigation.


Scrum master as architect

It is possible to combine architecture work with the Scrum master role. As a Scrum master, you naturally attend many meetings etc. where architecture plays a role, and design work can be done when assisting the product owner. Of course you have to want to / be able to perform the role of Scrum master.


IT operations is a stakeholder

IT operations will often be the first to suffer if a software system is performing poorly in production. They may also object if it is built using non-standard (for the organisation) technology and require the system is supplied with adequate operational consoles, error notification and fault-tolerance. Therefore, making sure they are a stakeholder makes sure the backlog also gets supplied with items that focus more on operational (I prefer this term over ‘non-functional’) requirements. Also, by requiring IT operations to participate prioritisation it both raises awareness by business stakeholders that IT systems don’t run by themselves, and it forces IT operations to take an active role in creating a maintainable system.  


Cross-team architecture guidance

Scrum teams are by definition ‘selfish’, i.e. they try to realise their own goals. To make sure things remain are aligned, any architectural choices should be in line with corporate policy (which therefore should exist and be maintained), or be validated with an enterprise architecture group. Product owners and Scrum masters should maintain an eye out for backlog items that affect the technical environment (i.e. new technologies, new connections) and coordinate the choices outside the team. ‘changes to the technical environment are decided and coordinated’ must be part of the definition of ‘ready’ for backlog items. 


Innovation team 

Separate from the Scrum teams, some people should be tasked with directed research of new technologies and developments, so the Scrum teams can counsel the team and use their input. People should move in and out of those positions from the Scrum teams. 


Quality team

In a larger organisations you will have multiple teams. The Scrum way is multi-disciplinary teams, where each team is able to perform any required task, possibly modifying many different applications/components. This might mean two teams concurrently modify a certain component, thus interfering with each other. 


Source code control will help in this of course, but version dependencies might interfere with releases. For instance: Team 1 modified a component and wants to release, but team 2 also uses the same component, has adapted to the modification, but does not want to release now.   


For larger settings, ‘version management in the large’ might be an option. Shared components are owned by a quality team. Other teams check in/check out components from this team. The team is also responsible for QA-ing the modified component (on architectural aspects). This team is also a natural spot for innovation work, longer term architecture, and refactoring. 



For a software development process framework, Scrum says very little about when/how design and architecture needs to happen. Given its by itself commendable focus on customer value, finding a place for quality is a challenge. In this article, I have outlined a number of things that can be done to make sure architecture, and therefore quality becomes part of the process. Those are:



  1. Separate need for design from doing design 
  2. Planning is design
  3. Liaison tasks a backlog items
  4. Separate dependencies on external factors.
  5. Architecture and training sprints
  6. Scrum master as architect
  7. IT operations is a stakeholder
  8. Cross-team architecture guidance.
  9. Innovation team
  10. Quality team



I hope this helps in finding a place for architecture/quality within the (short term) stakeholder value driven process that is Scrum. 


Any comments/additions, drop me a line at