Agile architecture is largely defined by a subset of the 12 agile principles and hence this heavily influences the remit of a software architect:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
The agile architect fosters an environment through coaching and mentoring that allows the development team to create software that can be easily modified to support changing requirements.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
An architectural ecosystem that supports frequent releases of software, and encourages teams to work across the full vertical slice of the system, should be promoted by the agile architect.
Working software is the primary measure of progress.
There are no large upfront design phases in Scrum or other agile frameworks and every sprint must deliver value. The agile architect supports the team in the creation of an evolutionary architecture.
Continuous attention to technical excellence and good design enhances agility.
Clean, well-written software that has good test coverage is much easier to change than poorly written software with no tests. The ability to change software easily promotes the ability to respond to changing business needs. The agile architect should help the team develop good technical practices through pair programming, coaching and mentoring. The agile architect should use their influence to protect the codebase from the pressure to cut corners on quality.
The best architectures, requirements, and designs emerge from self-organizing teams.
Rather than being the font of all knowledge, the agile architect pushes decision making to the development teams. This removes the architect from being an approver and cause of delay and allows the teams to move quickly. This requires the agile architect to describe principles of good design and overall objectives to the teams. The agile architect may also define constraints that can be added to product backlogs to guide teams as they implement solutions.
Agile architects remain hands on and are often the best or most respected developer in the team which is why they can lead by influence rather than diktat. Agile architects may be a member of a single team or multiple teams and this varies from one organisation to another. As a team member they would contribute to the definition of done and continuous improvement activities of the team. Only architects that code are allowed to play planning poker.