Change is never easy.  So the question is, how do you change things when you know they're broken?  There are two approaches: Revolution or Evolution.  Usually revolutions are bloody, messy and can sometimes end up causing more damage in the end.  Evolution seems to be a much more appropriate choice for the corporate American status quo.   Just keep in mind that no matter which path you choose, there will always be the obstinate section of the office who insists that beige is the only color. 

I.  Find Critical Points

Consider the following questions:

• What are the most important components of the existing process? Why? 
• What are the biggest weaknesses in the existing process?
• What are the things that stakeholders complain about most? Bugs? Deadlines?  Visibility?

The answers to these questions are important.  If you want to introduce change, you have to have a reason.  But you can't just throw the baby out with the bath water.  You have to know what's important to the company, the department and your team.  Use this information as the basis for your battle strategy.

II.  Start Small

Make sure the first thing you introduce is the most valuable to the situation.  If bugs are a big concern, start with TDD.  If Deadlines are the issue, go with short iterations.  The evolutionary approach is exactly that, an evolution.  Once you have a basis, you can start to add (or remove) pieces to the process.  TDD is often a good starting point.  The tangible evidence of its benefit is something a customer, a boss, and fellow developers can appreciate right away.  Continuous Integration or Pair programming are both a good second step.  Next comes the daily Scrum, then the iteration planning meeting, then the release planning.  Pretty soon you're using User Stories and metrics.  This sounds much easier on paper (or a blog in this case) than it really is in real-life. But patience is a virtue.  Don't be upset when you're the only one writing unit tests.  Do a couple demo's for people and soon enough they'll see how confident you are while you refactor without hesitation.

III.  The resistance

Whether you do it all at once, or a little at a time; you will undoubtedly run into those who are opposed to these new methodologies in one form or another.  Don't get bogged down in arguments with this person.  You must pick your battles wisely.  Find the people who are the most open minded.  They are the ones who will join with you in your journey uphill.  Once you have another person sold, the fever will start to spread on its own.  If you're lucky, you work in an office that is at least somewhat democratic.  When it comes time to take a vote on the next standard or practice, the resistance will be forced to jump off the waterfall.

IV.  Have fun

Life is way too serious to be serious all the time.  If you can't stop for a minute and enjoy the fact that you're getting paid to write code, then perhaps you should consider a career in library sciense or the like.  If people see that you are an energetic and fun-loving person while you're working, they might start to think there's a reason for that. 

V.  Lead by Example

Self discipline is very important if you are going to successfully implement an agile methodology.  When you have a code review (or better yet pair program), you're code has to be stellar.  You can't convince programmers of anything, if they think your code stinks.  Demand nothing less than the best.  That's not to say that you should over-engineer, but rather that your code be readable, maintainable, and well (but not over) designed.

VI.  No COBOL

You can write COBOL and you can sit near me, but you can't do both at the same time.  So help me if I look over at your screen and see this:

PROCEDURE DIVISION.
Begin.
   OPEN INPUT SalesFile.
   OPEN OUTPUT PrintFile.
   READ SalesFile
      AT END SET EndOfFile TO TRUE
   END-READ.
   INITIATE SalesReport.
   PERFORM PrintSalaryReport
   UNTIL EndOfFile.
   TERMINATE SalesReport.
   CLOSE SalesFile, PrintFile.
   STOP RUN.

DISPLAY "I will punch you"