Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.So not just fast (early), but continuous too! And that's the whole point of the position of architecture in Scrum/XP/Agile. In order to be able to continue to go fast, we have to make sure we mind our architecture, since architecture is:
The set of design decisions that minimize the cost of development, maintenance and use (my definition, close enough to Grady Booch's)So the whole point is that architects make sure that teams can go fast now and ever after, and that the cost of use and maintenance is proportional to the development investment. So architecture is not a stable deliverable or document, much better to speak about architecting; the process of keeping the architecture aligned with the product development and agile process. Architecting is about identifying stakeholders that might be overlooked by the team and Product Owner, such as Support, Legal and 3rd party vendors. Architecting is about challenging the Product Owner and team to go slow, in order to be able to go fast by high quality standards, such as readability, 95%+ test coverage, early integration and performance testing, refactoring and the boy scout rule. So architects, make sure you identify and represent stakeholders, and get their points on the Product Backlog (yes, it may contain non-functionals) by working closely with the Product Owner. You are a major stakeholder! Assist the team by making them go slow for a good reason, namely to serve previously overlooked stakeholders. There is a subtle balance here, if in doubt go fast with the Product Owner, and only address the issue when velocity drops because of technical debt.