Using Architects in Scrum Projects
20 January 2014
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
One of the principles of the Agile Manifesto states, "The best architectures, requirements, and designs emerge from self-organizing teams." The key term in this principle is team. Scrum is big on team mentality.
Most of the activities that are part of Agile software development need the involvement of the team. The team succeeds and fails together, and the whole team strives together toward a common goal in order to deliver better-quality software. I believe that if an architect is part of the team and is responsible for delivering quality software, then he is a good asset to the team. He will have the team's trust.
A scenario where I think architects can be used even as an external resource: when there are guidelines about nonfunctional requirements. For example, if the guideline from an architect says the system must be able to process a million messages per hour, it is good because it specifies the qualities of the software and can be included in a Definition of Done or a product backlog wherever feasible.
It is important to emphasize that we know the whole team is committed toward the success of a given project and that any impediments are being removed. If architects are not part of the team, then they are more likely to cause constraints rather than solving the problem. They tell the team how to solve a problem but are neither committed nor responsible for delivery of the product. This should be avoided.
In summary, architects can tell a team what to do but not how to do it, if they are outsiders. They should be able to tell how to solve a problem and strive toward solving that problem with the team.
Current rating: 3.8 (4 ratings)