How do you control architecture in an agile project? [closed]

Question

How do you ensure that the project will be build with "good" design decisions enabling a flexible software architecture?

How do you balance between completely leaving the architecture to the teams on one side, and let all architecture control to a few individuals on the other side?

Do you have an "architecture group", "architecture label" or things like that?

Answer 1

A prerequisite for Agile approaches is an architecture you already know how to use.

If the architecture is not well-defined and completely understood, you can't really take an Agile approach.

You need to have some technical spikes that show how the architecture works, and how the various pieces will fit together. You can do these are preliminary sprints, but they won't lead directly to a release to users. They're a special case, required to get to an architecture you can use.

Once you're past this "understand the architecture" effort, you can then start to execute sprints that lead directly to releases for the users.

Answer 2

I could explain how I would do it, but this says it better than I could.

Answer 3

I would also recomend reading fowlers document Is Design Dead, as far as I understand his arguments if you consider all the agile practices as a whole then you gain the freedom to make large changes and so can evolve an architecture.

Refactoring works most effectivly with continuous interation, testing is enhanced with TDD and continuous integration ... I could go on. Evolving 'architectures' are only limited if you are unable to make the large changes requied to correct 'mistakes'.

Additionally, I think you have an architect as a stakeholder in the project, they contribute user stories which are in turn delivered back to the architect.

This is also a good way to utilise pair programming with the architect working as part of the pair. In this context the architect is not so much a dedicated person more a hat that a member of the development team wears while pair programming.

I think XP does not diminish the role of the architect (and architecture) it just places the resonsibility on all team members to deliver and spreads the cost over the lifetime of the project.

[edit]

Per other comments dont be afraid of some upfront planning, itteration zero is a good time to try and chart a bit of a plan, just dont get to strict about delivering it to a specific time scale.