The architect doesn't talk, he acts.
When this is done,
the team says, "Amazing:
we did it, all by ourselves!" (17) (The Tao of software architect - Philippe Kruchten)

On the surface - When it comes to agile development the role of the software architect is a little more blurred.

The most obvious aspect where architects is for the technical architecture. An experienced technical architect, can greatly enhance any project by steering the designs into the "best" directions (under the chosen platform constraints). The technical architect can also promote reuse etc.

Additionally while the requirements change a lot and not fully defined, the quality attributes of a system are more stable - if you need performance, then you need performance!. More so,  there are some qualities that are inherent to agile process - for example you want to put an emphasis on flexibility and maintainability - if your developed solution does not have these it is going to do refactorings. Thus, depending on the size of the project you may want to use an architect to help set the ground rules in the first couple of iterations.

Another area where architect involvement can be very beneficial is when you try to scale an agile project a good choice is to try to break the project to smaller loosely coupled projects (see this paper  for example)  - well, this is just  what we (architects) live for...

By the way, few agile processes, define the architect role up-front, one such process is MSF 4 Agile. Note that MSF (Microsoft Solutions Framework) version 4 comes in two "flavors" one that is aligned with CMMI  and the other a (much) more light version, the afford mentioned MSF 4.

How does the SPAMMED process fare with an Agile project - (surprisingly enough) I would say pretty well

First of the architect should be hands-on i.e.  part of the development team (most likely the technical lead)

• Stakeholders, you would probably want stakeholders on-site for any architecture related  meeting (just as much as you would want the customer on site for other activities)
• Principles would include things like TDD, Simple Implementations, Refactoring
• Quality attributes would hold Flexibility and maintainability and a couple or so of the important project qualities (performance, availability..)
• For the modeling you would chose very few views and would try to focus on ones that have manifestation in deliverables
  A good example for this is the Application designer  in Whidbey (see screen shot below) - the result of which is the projects structure for the solution

• Mapping doesn't really change
• Evaluation would be focused on proof of concepts and/or skeletal architecture.
• Deployment - well,  being part of the team... you would notice if your decisions were wrong or circumvented

To sum up - yes Agile projects can and many times should use an architect to help it stay on track - hey, even XP has an architectural spike...