Since I got addicted to unit tests more than 10 years ago, in the majority of my workplaces I was the first who has ever heard about these. Nevertheless I kept writing my little unit tests whenever I could, and estimating the cost of unit testing into my tasks. Whenever someone asked about my coding habits, I told what I was doing and why it worked for me. Usually at least some of the people were interested, and eventually I got to give presentations on the topic and mentored people to write their first unit tests.
You don't need to start convincing people about the agile way the first day at your new workplace. Just follow the principles in your own work as much as you can. If you do it well, you will deliver better code. If your coworkers and/or management notice it, they will ask how you do it. Then you can tell them.
Update
Most of the seasoned developers (and managers) have seen trends and fads come and go, so they do not get excited by the latest buzzwords. However, if you can demonstrate that a certain approach (tool, way of thinking) really works in practice, in the actual project, the ones who care about their craft will almost surely sit up and listen. But if you have no such people in your team, maybe it is time to look for a better place...
I think (and I may be going out on a limb here) that ALL projects should have a bit of classic waterfall: The initial analysis and specification phase is essential. You must know what you are doing, and you must have it in writing. Getting the requirements in writing is difficult and time consuming, and easy to do badly. That's why so many skip it - any excuse will do: "Oh we do agile so we don't need to do that." Once upon a time, before agile, it was "oh I'm really clever and know how to solve this, so we don't need to do that." The words have changed a bit but the song is essentially the same.
This is of course all bull: You have to know what you are to do - and a specification is the means by which developer and client can communicate what is intended.
Once you know what you have to do - sketch out an architecture. This is the "get the big picture right" part. There is no magic solution here, no one right way, and no methodology that will help you. Architectures are the SYNTHESIS of a solution, and they come from partly inspired genius, and partly hard-won knowledge.
At each of these steps there will be iteration: you find things wrong or missing, and go fix 'em. That's debugging. It's just done before any code got written.
Some see these steps as boring, or not needed. In fact, these two steps are the most important of all in solving any problem - get these wrong and everything that follows will be wrong. These steps are like the foundations of a building: Get them wrong and you have a Leaning Tower of Pisa.
Once you have the WHAT (that's your spec) and the HOW (that's the architecture - which is a high-level design) then you have tasks. Usually lots of them.
Bust the tasks up however you want, allocate them however you want. Use whatever methodology-of-the-week that you like, or that works for you. And get those tasks done, knowing where you are heading and what you need to accomplish.
Along the way there will be false trails, mistakes, problems found with the spec and the architecture. This prompts things like: "Well all that planning was a waste of time then." Which is also bull. It just meant you have LESS foul-ups to deal with later. As you find problems with the high-level early days stuff, FIX THEM.
(And on a side issue here: There is a big temptation I've seen over and over to try to meet a spec which is expensive, difficult, or even impossible. The correct response is to ask: "Is my implementation broken, or is the spec broken?" Because if an issue can be sorted out quickly and cheaply by changing the spec, then that is what you should do. Sometimes this works with a client, sometimes it does not. But you won't know if you don't ask.)
Finally - you must test. You can use TDD or anything else you like but this is no guarantee that at the end, you did what you said you would do. It helps, but it does not guarantee. So you need to do final test. Thats why things like Verification and Validation are still big items in most approaches to project management - be that development of software or making bulldozers.
Summary: You need all the up-front boring stuff. Use things like Agile as a means of delivery, but you can't eliminate old-fashioned thinking, specifying, and architectural design.
[Would you seriously expect to build a 25-story building by putting 1000 laborers on site and telling them to form teams to do a few jobs? Without plans. Without structural calculations. Without a design or vision of how the building should look. And with only knowing that it is a hotel. No - didn't think so.]
Best Answer
As other answers have stated, Management has every right to get a high level estimate upfront of a project. They are not unreasonable for trying to determine ROI.
One of the approaches that I like about Agile however is that the scope of a project is not fixed. It can be initially sized out at the Feature and Epic level, then business can determine ROI based on what are the most important features. Maybe the fancy UI with bells and whistles has low business value, but the workflow engine for handling claims has a high ROI.
When you lump the whole project together then it harder to meet ROI than if you focus on the critical business functionality that is desired.
Here is a way that I have done this:
Take your WBS milestones and turn each of these into a deliverable feature
This allows you to categorize your project into mini subprojects that have varying business value. Each of these should stand on their own in terms of business value.
T-Shirt Size the Effort on Features
This is a very easy way to get a rough idea about how big or involved a particular feature might be. Perhaps low value features still have a great ROI if they look like easy wins.
Break Down a Feature into Stories
Go through the exercise to find a small feature that is well understood and break it down into stories initially. Estimate these stories by points. Now you have a basis where
This will be a basis of comparison to other features
Associate story point effort to all Features
Compare your Small Feature to other features. For example,
Medium Feature Y is probably 80 story points. Continue this until you have story points estimated at a high level for all features.
Estimate your Team Velocity
Looking at your development team, try to determine how many story points could this team effectively deliver in a given sprint. If you have previous Agile projects as an example with this team that is a great place to start. If you do not have such history behind the team then go through a mock Sprint Planning with your team where you start looking at your Small feature that you have detailed out. What kinds of hourly estimates are people giving for their tasks on these stories?
Based on how much work the team thinks they can deliver in 2 weeks, use that total story point number as the average potential velocity of your team!
Find your Projected Completion Date
If your team in mock sprint planning feels comfortable delivering 25 story points in a sprint, and your total backlog looks like 300 story points for the gold Cadillac version of your project, then it looks like your team would ideally take 12 sprints or 24 weeks to complete everything.
Now it is trivial to turn cost of resources on your team into dollars per week to arrive at a cost for ROI vs. Business Value. The negotiation can continue on what the most important features are and then your project management becomes basically a Knapsack Problem.