Software Architecture in Scrum

Scrum is increasingly being adopted in many industries outside of software development, but within this original realm, there are still plenty of things to improve.

As one of the principles of the Manifesto for Agile Software Development states, “Continuous attention to technical excellence and good design enhances agility,” and thus mature scrum teams are always aware of this need, and they usually complement scrum with extreme programming ideas and practices, and extensions from continuous delivery and devops.

Among the challenges in this space, software architecture is an area in which I've worked with many agile teams over two decades, and I want to share with you some of the guidance and experiments I found most successful.

Architecture, not Architects

One of the recurring challenges many organizations face is that they tend to create architecture teams or areas, typically as a centralized service. This is obviously against the scrum principle about self-managed and cross-functional teams, as it is usually a decrease in scrum teams autonomy.

As with other specialists, like user experience or testing, architecture should be a team capability, probably stronger in some of the team members, but not limited to them.

One common concern about that is that the organization “doesn't have an architect for each team.” As always, the best solution might not be keeping a centralized service, but spreading the knowledge.

The most successful approach so far is to foster collaboration instead of delegation. This means guiding the few current “architects” work with the teams on their architecture challenges, but not for them. The idea here is challenging that “special” role to collaborate and add architectural knowledge to the team, instead of providing a closed solution.

A common misconception is that software architecture is something that requires higher seniority than most developers have, and can't be trusted to anyone. As happens with anything else, it is not needed that an architect transfers all their knowledge to the team. Good Certified ScrumMasters® can help establish a healthy mentorship process in which some team members learn by working with the architect, but solving their real-world problems, and get concepts, patterns, and practices applied to their product, not “universal wisdom.”

For this to work, architects should be willing to provide mentoring, teams need to be willing to learn, and leadership have to understand why it is important. In many cases, this is something scrum masters can help with, even if they have no technical background.

This approach has to be seen as an investment: It will take longer for the current architects at first, but over time they will stop being a bottleneck for the teams, and at some point they become part of one of the teams, hopefully based on their own choosing.

But how can architecture be consistent if it's spread among teams, with no centralized intelligence? As usual, cross-team concerns are better suited for communities of practices (CoPs) than centralized services. That doesn't always mean an architecture CoP. Architecture thinking can be an active part of product design, technical excellence, or any other CoPs.

Out of the Architecture Blueprint

An issue which is usually associated with centralized architecture teams is that as they are in high demand; they are usually tasked with providing a Blueprint early in the application design process. As you go away from this approach, you can start weaving architectural concerns in the early stages of product design involving anyone from stakeholders to team members, and safely defer architectural decisions for later, as scrum encourages you to do with product design details.

One approach I found useful to start an incremental architecture is to run some simple activities during your Inception or product discovery phase. 

If you are running an agile inception, you might have a short activity like sketching the solution in 10 feet, where stakeholders and team members generate a rough sketch of the technical solution, not with detailed components or technologies, but usually identifying different data sources, intensive processing, client access (web, mobile, APIs, others). This activity tends to generate interesting issues to keep in mind later in Backlog Refinement and Plannings.

Additionally, some of the initial concerns about quality attributes can be taken into account as part of the initial definition of done.

To help discuss quality attributes with stakeholders without scaring or boring them, you might want to use my Architectural Tarot Deck (which is a free resource, of course).

Sashimi Architecture

When you use an incremental approach to product design, like user story mapping, your developers can use these thin releases to start designing and implementing the minimal architecture they need to support them.

This approach, called sashimi (as it thinly cuts through several layers of the application at a time) allows the team to focus on functional needs, and grow the architecture as it grows.

An example of this for the client layer can be starting with the simplest web application, leaving the door open to choose later whether to wrap parts in an API to be called from a mobile app, or just building a progressive web application (which is a huge cost difference).

An example applied to complex logic is to build a simple facade for the first instance of processes, which can hide growing complexity, eventually replacing the implementation with the most appropriate workflow or rules engine. Many times in the past I had projects starting with prescribed workflow engines that were not really needed and added lots of accidental complexity.

Continuous Architecture Validation

High-quality software requires the team to integrate continuously. The more frequent the build server checks the entire solution, the easier it is to fix problems or inconsistencies.

Of course, the finer grain of your changes, the more frequent you can commit, and the faster the build server can provide feedback. One of the practices that allows you to move in many little steps and ensure good coverage is test-driven development (TDD).

Assuming your team is doing TDD, or at least is writing lots of automated tests, it can quite easily start automating some quality attribute automated validation.

Common examples of quality attribute automated validation in test-driven development:

• Load tests to check performance, capacity or availability issues

• Resource metrics to check efficiency, capacity or availability

• Multiple environments in acceptance tests to check internationalization, supportability, or interoperability

What's interesting about doing this is that over time, step by step, they can automate many things concerning their definition of done.

Architecture during the Sprint

For me, the things we usually associate with architecture shouldn't be a separate part of the overall product design, so I just add some ideas about how to integrate this discipline into the regular scrum events:

• You can keep an eye on quality attributes during sprint planning/refinement activities. You might use the tarot deck, quick sketching or other techniques while discussing each PBI. The team can have in mind testing and validation effort at the planning III part, when they figure out their implementation strategy, maybe as additional tasks.

• When implementing each PBI during the sprint, they can have extended acceptance criteria to their tests, and have feedback from their build.

• At the sprint review, some quality attributes test or metrics can be shared and discussed 

• At sprint retrospectives, architectural improvements (either in implementation or validation details) will appear if the team is engaged in architectural thinking

I hope this gives you some ideas to improve how your teams tackle this area. As always, this is a long process, but the meat teams I worked with always spend time improving at these, and as a result, much less having to solve runtime problems and system failures.

If you are interested, you might check out my 2010 paper, “Software Architecture in the Agile Life Cycle,” and my book (in progress) “Agile Architecture.”

Ready to take your scrum skills to the next level and strengthen your technical skills in agile product development.? Become a Certified Scrum Developer®.

About the Author 

Martin Salias has been a professional software developer and architect for almost 40 years,  involved in projects throughout the Americas, Australia, and Europe, for organizations as diverse as United Nations or Microsoft Corp. He is a Certified Scrum Trainer®, a CSD Educator and one of the initial members of the Latin American agile community.