If you have access to in-construction software to test, then you can follow agile methodology to test it.
But if the whole team follows a traditional SDLC, then you will not have the software to test before the end of development of a stable version, then ofcourse you cannot take an agile-approach to your testing work.
I think there are lots of ideas that can be borrowed from agile and used on traditional teams. Of course, it is easier if you have a customer on site, short iterations, etc., but don't let that stop you.
We talk about the agile testing quadrants as a way to think about the purpose of testing. I think that alone is worth while.
Mike, at my last job, the development organization said it wanted to "go agile", but never adopted any practices except for one small (and successful!) project. The programmers wouldn't automate unit tests. We released every two weeks, but that didn't make it agile.
While I tried my best (using patterns from Rising and Manns' Fearless Change) to motivate the organization to change, I focused mainly on making my own QA team successful, and working with the developers and customers as best I could. Within our QA team, we used agile practices such as using good design techniques and refactoring on our automated test scripts, pairing, working in small increments, and collaborating closely with other teams. I got more help from programmers on functional test automation when I started writing test scripts in the same language they used for the app. I went to the dev managers to ask them their greatest areas of pain, and borrowed what I could from Agile to address those. For example, they complained most about not getting useful requirements. I suggested writing customer-facing tests ahead of time in place of requirements documents. They agreed to this practice, and it solved the problem.
That's just one example. The agile approach to testing is mainly about applying certain values and principles. You can try to get more involved with other parts of the organization, even when testers are on a separate team. You can also try to work more closely with business experts, learn more about the business so you can help deliver value, and step out of your comfort zone to find more ways to contribute.
Co-author, with Janet Gregory: Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009) http://lisacrispin.com