Brenda Michelson wrote an interesting piece on whether SOA and Agile development techniques are compatible or not. My answer is that it depends on a number of factors, such as:
1. Are we looking at building a SOA using Agile techniques, or are we building it with another methodology with the view of enabling agility once there are enough services built and available to make a difference?
2. What is the current state of Agile methods in the organization? Are the techniques relatively new to the business, or is there substantial experience with the methods already in-house?
3. If Agile is already being practiced, how well is it practiced in the organization? Is there a successful track record with previous Agile projects?
4. Agile methods are tightly coupled. You're in for a dime, in for a dollar with Agile. A basic theme in SOAs in loose coupling to enable services to satisfy a wide variety of application needs. Architecture becomes important here because if the proper amount of coupling isn't maintained and controlled, the SOA degrades into just another application specific API that uses a different transport mechanism. Along with tossing future Agile enablement out with the bath water.
Every organization goes through a learning curve with a new development methodology, and Agile is no exception. Certain businesses have problems adopting any development methodology if the culture has specific bad habits, such as continuously looking for silver bullet solutions and discarding all that don't give a quick results fix; or picking elements of a methodology that appeal to them and discarding (to their detriment) those that don't fit their worldview. Some outfits just can't execute projects well no matter what they try to do for various reasons, and Agile techniques won't save any organization with poor execution capabilities.
A well-designed and built-out SOA will definitely enable agility in the future with respect to applications development. The issue on whether the SOA itself should be built-out with Agile methodologies begs a number of the questions above. My take is that organizations attempting to design/build a SOA might want to initially use more traditional project management methods if Agile is new to the business. This will allow for Agile project execution experience to build up sufficiently while the SOA gets into a form that will enable Agile applications development in the future.
I'll share a story here that references Brenda's question regarding reconciling architecture elements with Agile techniques. A colleague recently decided to implement the beginnings of a SOA - a data abstraction layer that shields myriad databases from applications. The apps invoke web services to get and put their data without having to do row-column engineering on tens of different and confusing schemas. He sold IT management on going Agile with the project because they could 'have it faster' and leverage it into an enterprise SOA that would promote further applications development agility. Unfortunately, the current status of his project is late, and getting later every passing day. Among the key problems and issues: lack of experience with Agile methods; continuously having to educate developers (and their management) that they no longer need to access databases directly; and continuous refactoring of web services to meet changing development requests, which further degrades the web services because the coupling to this specific application becomes tighter and tighter as time goes on and the change requests pour in.
My friend is guilty of underestimating what it takes to execute an Agile SOA project and may wind up building a 'shantytown' of web services that will have to be replaced or significantly refactored multiple times. But that's what learning curves are for and as experience in this area grows, I'm confident that the outcomes will be more satisfactory.
In the meantime however, I would take a long look at decisions to use Agile on a SOA build-out if a number of the criteria I've outlined above apply to your particular situation.