Intent

Guide the team to reduce technical debt before it becomes a problem.

Motivation

The nature of agile development is to deliver working software continuously. This means that the focus for all actors (Product Owner, Scrum Master and Team) is on the functionality delivered in each iteration. As a consequence, technical debt is considered okay and is likely to increase for each iteration completed. Often, this is allowed to go on until the debt has reached a level where the velocity of the team is starting to decline. After a while something has to be done, and the term Refactoring Sprint is introduced. A refactoring sprint is in this context an iteration totally devoted to paying off technical debt, thus no functionality is delivered for an entire iteration.

How it works

The Agile Architect Pattern prevents the scenario from the motivating example from happening by introducing an Agile Architect role. The Agile Architect can be seen both as a member of the team and as well as a stakeholder. This makes him/her able to both work with the team members, guiding them while trying to identify architectural issues as well as discussing requirements for future iterations with the technical resources from the client. While the team has a iteration-by-iteration time frame, the agile architect can see a few iterations ahead making sure the architectures evolves in a way that (hopefully) will not cause major problems ahead.

When to use it

The Agile Architect Pattern should be used in any project spanning over enough iterations likely to cause the technical debt large enough to slow the team down. It is important that the Agile Architect is comfortable both in the code domain acting as a guide for the team as well as on a higher level of abstraction to be able to interact with the client technical resources.