Agile Adoption
You can do it yourself: http://www.targetprocess.com/blog/2010/04/going-agile-from-within.html


The problem is that this process is so slooow. It is inevitably slow, because all the mindset changes are slow, and you can’t speed them up greatly. My estimate is about 1 year as a minimum (no proof, sorry, just personal experience). You can’t absorb all the agile spirit in a shorter period of time (maybe some geniuses can, but they don’t need coaches anyway). I do believe that a good agile coach can speed up agile adoption, but not as greatly as often advertised.
OK, so changes are slow. It is absolutely required to manage the change over a long period of time. You can’t setup something, run it for a couple of iterations and leave. There is a high chance that development team will degrade and slip back to old-and-oh-so-known practices quite fast. It leads to several possible conclusions:

1. If you hire agile coach, it is better to have about 1 year contract.
2. If you hire agile coach for just 3-6 months, setup internal learning/change process as fast as possible.

The main idea of agile adoption is a paradigm shift. People should change their habits, rituals, working patterns and activities. It is SO hard! Some people just can’t accept it and leave the company. The goal of agile adoption is to change mindset of as many people as possible and let rock-hard minority go.
So why I personally don’t like the idea to hire someone who will teach us agile? It immediately puts our intelligence to question. Are we really not able to learn ourselves? Can’t we read some books, discuss them and try, for example, Scrum in a single dev. team? If we want to hire someone, to me it looks like we’ve already given up and can’t do anything cool without external help. It looks like we got exhausted and now need a power recharge. It is similar to an external CEO hired in a desperate attempt to save company.



http://www.sarahmei.com/blog/2009/10/06/is-agile-too-slow/

10 Mistakes in Transitioning to Agile

http://www.drdobbs.com/architecture-and-design/193402902;jsessionid=TXIPPZDDXINUXQE1GHPSKH4ATMY32JVN

What not to do

Mistake 2: Go Fast to Go Fast

Do not take the time to get your group and other groups within your organization to understand agile development. Especially if you're also growing fast and creating new departments, do not slow down and throw them into the mix. For example, say you just established a new User Experience group. Before you even have time to define the new group's roles, throw them into the agile initiative.

Make sure you don't clearly define the terminology, such as the similarities and differences between use cases and user stories. This way, everybody will have a different idea of what is being created and that will contribute to the overall confusion.