In an Agile Environment, who is responsible for software architecture

Question

In an agile team, who is responsible for making high-level architecture and design decisions that affect the entire system, not just the work being done in the current sprint?

Maybe product owner, scrum master, the scrum team or someone else?

Answer 1

"The software architecture is performed by the entire team. This practice does not remove the need for a software architect, it just means that the architect contributes to the discussion with a broader and probably more experienced perspective, nevertheless all members of the team contribute towards the architecture of the software."

• Source: http://www.executivebrief.com/blogs/software-architecture-agile-environment-sashimi-approach/

Answer 2

Architects, of course, but perhaps not the traditional kinds of architects.

I don't mean the lead-surgeon kind of architect who does all the thinking and then leaves the monkeys to do all the typing. I mean an experienced lead programmer who understands the cost/benefit tradeoffs of difficult-to-reverse decisions and who advises teams on what to do.

Effective architects are hard to find, but it can be a fantastic position, and so you probably have at least one experienced, thoughtful programmer who could do it well. Such a person needs to

• Make good architecture decisions, of course, but also
• Know how to give advice effectively, so that others feel comfortable taking it, and also
• Slowly delegate architecture decisions to the teams

This last point trips a lot of people up. When well-meaning agilists say things like "The team owns the architecture", they have that "right", but I find the advice almost completely meaningless in its application. If you trusted teams to take responsibility for their own architecture, then you wouldn't be asking the question in the first place, now would you?! I therefore assume that you ask the question because there is some concern either that

• Nobody will take responsibility and we'll have a poor architecture, or
• The wrong people will take responsibility and we'll have a poor architecture, or
• Whoever takes responsibility will become a scapegoat and you're hoping to avoid that

If you need someone to take responsibility, then give it to whoever wants to accept it. Seriously. That person at least cares. Give that person the resources they need to do the job and help them when they need it. It probably doesn't matter how competent the person is, because if they care, then they'll try to learn what they need to learn. Naturally, such a person needs support in the form of good books to read and a community of peers and mentors whom they can ask for help and advice.

If you worry that the wrong person is about the take responsibility, then I hope you know who "the right person" is, and will fight to install them as an architect. A book like The New Strategic Selling will help you learn the sales techniques to make that happen.

If you just need a scapegoat, then quietly nudge others to give the responsibility to whomever's career you'd most like to destroy or impair. At least be honest about it.

Getting back to an effective architect's work, they can think of their job as a management position, rather than merely a decision-making position. If they don't delegate at least the most routine decisions to the teams, then they will become a bottleneck and slow down the entire organisation. Adding more architects at the top does not make that go faster. Cultivating better architecture decisions from the ground up will. The delegation board technique will help your architect become more comfortable over time delegating more and more decisions to the teams as those teams earn trust by showing competence.

I think of a great architect as someone who helps me understand how to design my systems better, who will advise me patiently when I ask for it, and who will occasionally stop me from making a very poor decision. Such an architect acts like a leader in the truest sense of the word: someone that others voluntarily follow.

I know that was a lot.

References

Miller, The New Strategic Selling. This book includes a model for understanding why you failed to close a specific sale. I find this invaluable in understanding why coworkers won't do the obviously wonderful thing I'm suggesting.

Weinberg, Becoming a Technical Leader. This book helped me learn how to do the non-architect part of the effective architect's job.

Appelo, Delegation Boards and Delegation Poker. Don't underestimate how hard delegation is and how much we suck at it. Learn do it more effectively and more comfortably.

Answer 3

The best architectures, requirements, and designs emerge from self-organizing teams

-- Agile Manifesto

So the team self-organizes to make architectural decisions in whatever way it sees fit. There's no hard and fast rule, it can range from consensus to a "council" of the most senior members, to designating one particular member as the architecture authority, to letting the architect choose if there is a member with such a job title...

Answer 4

I feel that the answer to ""who is responsible for making high-level architecture and design decisions?" depends on the size and number of teams.

For one or two teams with 3-7 on each team then the self-organized team can do with lead from the senior members.

For 3 or more teams the increased complexity leads to the need for an architecture team that can see if the various sub-teams are doing work that will interface with the other teams. In my experience that point is reached when there are approximately 8 teams or at about 50 people.

Answer 5

There are some great resources from the Scaled Agile Framework (SAFe) team on their site.

It essentially helps you scale out agile across your organization, going above a single release and into portfolio and program planning. Their documentation shows suggestions on how to involve your Enterprise and System Architects in the process to introduce architectural epics into the release train.

Edit for clarity to address the question more directly:

In a scaled agile environment there are multiple tiers of ownership over the architecture. The agile implementation team will own the low-level emerging architecture by refactoring as needed to continue their implementation of their backlogs. Higher-level architectural decisions (supported operating systems, browsers, platforms, libraries) are under the responsibility of your system and enterprise architects. They will make the business cases for when these changes need to occur and will recommend for these architectural changes be added to the release train for the implementation teams.

So, in regards to the high-level architecture decisions that go beyond the sprint, you will usually have these made at a level above the team. These professionals traditionally have an 'architect' role within the enterprise already.

Answer 6

I think most of the other answers are thinking about this from the perspective of being inside a project.

If that is the only level of architecture in an organisation the result will frankly be chaos. I have witnessed this chaos first hand, sadly it happens.

According to TOGAF, the Enterprise Architecture Department makes high level plans for and with the business to create and replace the IT environment. The Enterprise Architect will have defined architectural principles and got them signed off at the highest levels of the organisation and will help create the high level architecture and requirements for each project. Each project is initiated to provide an architectural building block in that high level architecture.

So, at the project level, the Solution Architect will create the project architecture (possibly iteratively) and will get sign-off from the Enterprise Architect.

Now, to focus on an agile project. An agile project has requirements. They aren't in the form of a massive "Requirements Document" but instead are epic and stories. These Epics still require planning. You don't send a team of developers off on a few sprints into the unknown. You know at a high level what the system needs to do, what other systems it needs to interact with and what hardware / Operating System / Language constraints the organisation has and this guides and constrains the architectural choices open to the Solution Architect. For example, if you are committed to .NET and SQL server, you would have to make an extremely compelling case to implement an e-commerce site based on Magento using PHP and MySQL because of the costs involved in supporting two DBs, two languages, two webservers etc. Alternatively, one project could choose to use a completely different library or a different look and feel and this could have implications to all other in-flight projects. It is essential to have the oversight of an Enterprise Architect to prevent this sort of "Architectural Debt" from happening.

Answer 7

Depends on the organizational design of the organization and if the product is in a portfolio. Larger, role-oriented organizations are may appoint senior architects to lead these type of activities.

Generally an senior architect will facilitate and guide design decisions as they don't just affect a product backlog, they may affect several products in a portfolio of products.

Smaller, agile companies may rely on developers that are system experts to lead the development team to align on architectural design.

Ultimately, architectural decisions need to be agreed upon by the delivery team that works on the product. Experienced Architects and tech leads will be more focused on facilitating the discussion around what the design should look like, rather than dictating the design.

Answer 8

I think most answers already highlight that the team not a single person should take these decisions.

What they do not touch is another Agile principle:

Simplicity--the art of maximizing the amount of work not done--is essential.

Thinking about high-level architectures & design decisions are often not taken with simplicity in mind, possibly leading to wasting a lot of effort and adding unnecessary complexity that could make things harder to extend.

Think ‘gardening’ over ‘architecting’—Create a culture of living, growing design

During your current iteration you should make architecture & design decisions for your current needs. Instead of looking ahead to a future that might never become, focus just on what you need now. Probably YAGNI a well thought-out architecture now, let the team handle it bit by bit.

Other reads:

• https://less.works/less/technical-excellence/architecture-design.html