Here are our Top 10 thoughts on the subject of dealing with architecture on Agile projects:
- On any complex project that is delivered using an Agile methodology, special effort should be allocated for designing the right architecture, because the textbook understanding of Agile does not provide for it automatically. The actual implementation of this approach will depend on the project at hand.
- At minimum, architectural decisions for the upcoming sprint should be discussed and made during the sprint planning session, because without them a sprint cannot be estimated correctly. If necessary, the appropriate ‘technical’ stories should be discussed and estimated. (However, it is advisable to define user stories so that newly implemented architectural features are, indirectly, a part of normal user stories with visible GUI and testable functionality.)
- Architectural decisions that involve specific user stories should be estimated and documented as child tasks related to those stories.
- An experienced architect (who, as a rule, is shared between several projects) should ideally be present at the sprint planning meeting.
- If the architect’s presence at the sprint planning meeting is not possible, he or she should review the architectural decisions made by the team promptly, ideally within one day, and approve or reject them. If the changes requested by the architect impact the estimates significantly, sprint cancellation should be invoked.
- On large projects with a complex architecture, it is advisable to maintain a team of architects to be shared between several agile teams. This team will generate and submit specific architectural decisions to teams before each sprint planning session, and the teams will take those decisions into account as they estimate their sprints.
- Architecture documentation, if required, should be updated by the architect at the end of every sprint, because too many changes can occur during a sprint, and any attempt to keep the documentation up to date “in real time” becomes too time consuming.
- Unlike developers and testers, a dedicated architect should not estimate and track his/her time, because the architect’s activities are carried out in a continuous fashion, often in part-time mode, and can be hardly estimated correctly.
- On small and medium size Agile projects, architecture can be defined during the Planning Game by brainstorming with the entire team. In more complex projects with a lot of specific requirements and restrictions regarding customer production environment, the team can still generate good architecture solutions, but in this case a dedicated architect (probably shared between several Agile projects for the same customer) can be useful, e.g. for quick review and approval of solutions generated by the team during the Planning Game.
- Otherwise what could happen, for example, is that the team may come up with a great architecture solution for the implementation of a particular User Story that would be nice in an ideal world, but the deployment of the whole project could fail, because customer security will not allow it due to very specific limitations.
