Right tool for the job - what about the architecture

How does the architecture relate to 'project management' discussion. Well, part of the tool selection you need to identify and understand the task at hand - what are the key areas. Why discussing agile architecture here? Because I'd like to understand how a typical heavy upfront activity could be managed in lean & agile way as I am pretty convinced of the benefits of those compared to waterfall.

First of all you can use 'architectural significance' as one priorization criteria, which would put those requirements on the top of the backlog.

Another topics is the right team, meaning that in case you have an identified architectural challenge on your hands the team must be able to cope with 'agile architecture' - ok, this is nothing different from any project/development activity the right people do make the difference in any case.


Quote from Nick Malik at http://blogs.msdn.com/b/nickmalik/archive/2009/04/27/why-agile-development-requires-agile-architecture.aspx

Agile architecture is the act of producing enough architecture to meet the needs of the project, and nothing more, and producing it in a timely fashion, with a minimum of effort.  Agile architecture RARELY produces a detailed class model in advance.

Agile architecture often produces a high-level component model and context model to establish the existence of components, their names, and perhaps even the division of responsibilities in the dev team itself.  (think: Scrum of Scrums).  Agile Architecture nearly never produces diagrams of technical things, like the structure of a message.  Dev tools do that, from the code itself.

Agile architects will produce models using a dev environment tool, like Visual Studio or Sparx Enterprise Architect, not a diagramming tool like Visio that cannot easily be connected with the code.

Agile architects will use diagrams to communicate between people and to express artifacts into code where developers have real freedom to make the magic happen.