I'd like to start with a question: You said - "If a very successful Agile team is seconded to working on a project which thinks it is Agile but truly is" I presume that last word should be isn't. Is this correct? If not, please reword your question so it could be answered correctly.

If the W is for waterfall, then there are some things perhaps you could do that would make folks happier, but not necessarily solve the issue entirely. I'll start with an assumption that no matter what you do, you can not remove the ability of being forced to do waterfall.

Let's presume your folks were using Scrum, then run each waterfall phase in a Scrum fashion. You get the visibility and daily communication/collaboration, just not the coding until you get to the development phase (thanks to Mike Cottmeyer for bringing this up in Agile Coach Camp 2008).

Another option perhaps (which would be really good if you are at least allowed to overlap some of phases of the waterfall) is to use a Kanban process to manage the individual requirements to a "ready for development" state (thanks to David Bulkin for this suggestion at Agile Coach Camp 2010 in NC). Allowing you to overlap would at least get developers into coding on ready requirements without having to wait for a full requirements document to be done (you'll probably still have to do one). If you are using a phase-gate though and the entire set of requirements must be done before moving onto design/development, then you'll not gain the true advantage of Kanban speeding the process; you WOULD get the benefit of seeing where your bottlenecks/constraints are.

Within your development phase, using either process, you could run it in Scrum -like fashion if you wanted to... (BTW, if you are also forced to use EVM to measure progress, look below for a few links on Agile EVM.)

A few other random comments:

In most waterfall environments you produce tons of useless documents; just ensure you also produce truly useful stuff (example tests, user stories, etc.). It might be more work on the team (factor it into your estimations!), but it will make the development and ultimate end-user satisfaction higher.

Perhaps make some of the tasks a pair exercise; there is no reason you can't pair analyze (and document) requirements.

Still don't be afraid to bring in users or stakeholders for periodic (every week even) to see what has been built so far... if they need to make a change, allow it. Just factor in that you will be updating the documentation as well.

And lastly, don't forget that you can still have regular retrospectives for improvement regardless of what phase you are in. In fact, you could use these to justify my closing comment (below).

Those would be my gut feelings on how to handle a Wagile process - they are really more geared towards team happiness and somewhat towards ensuring the team delivers value.

My closing comment, if this is because the Wagile SDLC is incorrect, volunteer to refine the SDLC and make it more Agile! Use your retrospectives to serve as feedback on what needs to change.

Hope that helps! Paul

Agile EVM links: http://www.infoq.com/articles/agile-evm http://www.agilejournal.com/content/view/210/33/ http://www.pmforum.org/library/studentpapers/2007/PDFs/Kane-5-07.pdf

The first two are from the same author and the content is more or less the same.