Participants: Jason Little, Mike Berberich, Nimat Haque, Par Boos
Role of an architect on an Agile project:
1. As a solution architect. Dedicated to a team or teams. It is ideal if the architect also participate in implementing stories.
2. As a technical mentor. Facilitate architectural discussions and guide the team to make sound architecture decisions. The goal is to help the team to become self-sufficient in making architecture decisions.
3. CTO/Chief Architect/Enterprise Architect interacts with teams at the beginning of a project to set the architectural vision and keep a tab on the direction from time to time.
Emergent Architecture:
1) Grass-root architecture. The team from time to time captures the solution architecture as it evolves organically and identifies any inconsistencies and addresses them as necessary.
2) Spikes. Uses spikes to test new components/technology or approach on a real story (not as a throw-away). If the spike is successful, nothing needs to changes. Otherwise spike an alternative approach. Not everything needs a spike. Avoid spikes when there are plenty of examples and best practices available. Use training where available to reduce the risk of wrong adoption of a new technology or tool or components.
3. Architecture refactoring. Team retrospective, external inputs (issues with "illities," and new customer requirements), and bug density may trigger the need for architecture refactoring initiatives. Instead of premature optimization for "illities," wait for specific needs to come up and address them just-in-time.
4. Use a small effort (one story) in every sprint to address "illities" on an on-going basis. For example, story might be that improve the response time of a customer search from 2 seconds to sub-second.
Role of an architect on an Agile project:
1. As a solution architect. Dedicated to a team or teams. It is ideal if the architect also participate in implementing stories.
2. As a technical mentor. Facilitate architectural discussions and guide the team to make sound architecture decisions. The goal is to help the team to become self-sufficient in making architecture decisions.
3. CTO/Chief Architect/Enterprise Architect interacts with teams at the beginning of a project to set the architectural vision and keep a tab on the direction from time to time.
Emergent Architecture:
1) Grass-root architecture. The team from time to time captures the solution architecture as it evolves organically and identifies any inconsistencies and addresses them as necessary.
2) Spikes. Uses spikes to test new components/technology or approach on a real story (not as a throw-away). If the spike is successful, nothing needs to changes. Otherwise spike an alternative approach. Not everything needs a spike. Avoid spikes when there are plenty of examples and best practices available. Use training where available to reduce the risk of wrong adoption of a new technology or tool or components.
3. Architecture refactoring. Team retrospective, external inputs (issues with "illities," and new customer requirements), and bug density may trigger the need for architecture refactoring initiatives. Instead of premature optimization for "illities," wait for specific needs to come up and address them just-in-time.
4. Use a small effort (one story) in every sprint to address "illities" on an on-going basis. For example, story might be that improve the response time of a customer search from 2 seconds to sub-second.