If you've found agile and walk into a workplace that doesn't particularly follow any methodology and they are resistant to change (as most people usually are), how would you introduce an agile methodology like scrum?
NOTE:
By making the case, just like anything else.
You start by asking yourself this: What are the problems that our current methodology has, and how would agile help fix those problems?
It may not be an easy sale. Going Agile completely requires a different mindset, a different way of doing things, and a different corporate culture. Specifically, the Agile Manifesto list these characteristics of Agile development:
Most companies don't have all of these characteristics already; if they did, they'd already be agile. But chances are good that your company already has some. Evaluate each bullet based on your company's relative strengths, and start a conversation how you can begin incorporating some of these principles into the development process.
Truth is that it is hard to be a leader and to get things started, if you don't have the power to do so (you said you were not the supervsior or boss). First you need to have the belief that Agile, Scrum, or whatever may not be the best for you. Maybe cowboy loner coding is best for you.
Second, you have to have a mission, small at first, but a mission. The first mission will be for yourself - follow your agile plan so you understand it, just for a small project.
Third, you have to have a mission, small at first, but a mission. This second mission will involve you and another team member. After that mission is complete have an honest conversation about the methodology and seeing if it works for you. If you do guess what? You need another mission and another person. Talk about it again. Eventually you'll have enough to talk to the boss. But if you have the developers on board, you don't need the boss because everyone will be doing it.
In this latter case, the one where you are successful, I would document from the beginning to the last scenario all that you have done and the results. I would present that to the boss and at least have a good write up for it and maybe a better raise when the time comes.
Don't forget to document this procedure or you won't get your credit - and you deserve it if it honestly helps you and your organization.
edit: this presumes you have the freedom from on high to do this. if you don't you'll need to ask for permission unless you are very sure, in which case you'll have to ask for forgiveness. Creativity needs freedom. Be sure you have it or be very careful.
The best way to introduce agile is to show them that their practice of waterfalling doesn't quite cut it.
Now if they don't have any process then investigate then prove to them that their lack of a process causes problems. Then you introduce agile as something which brings some order into chaos without tying everybody's hands with rigid processes.
First, I'd inquire as to what do those that would be using this methodology think of it, what experiences have they had with it, etc. so that I can know the background of what perspective do these people have.
Second, I'd likely see how much of a shift would something like Scrum be on this team? Is there a way to break this down so that it isn't a big shift all at once? Piece by piece is a good way to describe the methodology here but also contrasting this to how things are currently done is another part to this.
Third, find a good Scrum Master that could help get management buy-in as well as things initially set up to give success a good chance as sometimes it isn't easy trying to get another chance to launch something.
Everyone follows a methodology. Their's probably doesn't have a standard name and may be inconsistent.
If everyone is productive and likes the way things are, change is difficult (as it should be in this case).
Think about the problems 'agile' has solved for you. Present these privately to the leader if they address issues he/she has identified. Getting someone to accept they have a problem is usually the hardest part, so pick on the low-hanging fruit.
Eventually, they like the pieces of a methodology and find that using all aspects of it is usually what it takes to make the whole thing work. It also can save a lot of trial and error.
