This post contains a series of questions all relating to helping people adopt agile.
I'll start by answering a general question that covers part of all these questions, and then address any specific instances separately.
Question: How do you get people to convert from a waterfall to an agile approach?
Understand why you want to use an agile approach. I do not recommend adopting agile for the sake of adopting agile. There should be some problem or set of problems that you are trying to solve that agile does a particularly good job of fixing. There is nothing worse that introducing agile in a "program of the month" form without a compelling reason as to why. For example, agile is particularly well suited for projects with a great deal of uncertainty.
Let them know what is in it for them. The WIIFM (What's in it for me) is different for different people. For members of the team, it can mean a predictable rhythm of development, control over scope in the short term, and the ability to deliver something quickly (small wins), among other things. For stakeholders, it means an opportunity to provide meaningful feedback based on a concrete running product. It also means the option of having part of the product available to start using while the remainder is being developed, and it means increased flexibility to change course when new opportunities arise partway through the development cycle.
Give them an opportunity to talk to someone who has done it before, but is not a religious zealot. If available, provide them with examples of other agile projects that have delivered inside your organization. Failing that, find some success stories in similar organizations. But again, keep it real and avoid hype.
Provide training to the team that is trying agile out for the first time, but make sure the team goes through the training together, and make sure that the training is provided by a good trainer. Again this is someone who has actually done it, not just talked about it. Certifications are not a sufficient means for determining a good trainer. Get some references. Did the coach provide guidance on an appropriate agile approach, but also provide guidance on why the approach is structured the way it is and provide helpful suggestions for teams to determine what practices and techniques will work in their environment, or where they may need to make some adjustments.
Another helpful resource on ways to encourage change of many kinds, whether it is switching to agile, or some other changes, read the book Fearless Change by Linda Rising and Mary Lynn Manns.
Question: How do you get BA's to convert from a waterfall methodology to an agile approach?
The above suggestions are helpful, but BA's have some specific concerns, ok fears, about converting to an agile approach. Primary among these is the perception, well founded, that there is not room for BA's on agile projects. After, none of the agile approaches mention the BA role (never mind that most of them don't explicitly mention testers, project managers, or in some cases developers) and agile also encourages developers to talk directly to the users. *gasp* Actually, any confident and competent business analyst would welcome all of the members of the team wanting to talk to the users, customers, and stakeholders. It gives them a chance to focus more on making that the team has a complete understanding of the problem and solution. They get the opportunity to move from being stenographers and order takers to really crafting solutions and ensuring that description of the problem is complete. It in effect forces business analysts to move up the value chain in the project world.
It also gives business analysts a great opportunity to learn new skills that normally resided with testers, project managers, and developers. Agile teams have no real role delineations except where necessary to identify that the team consists of all the needed skill sets. Team members collaborate with each other to determine how to deliver on their commitments, which means that developers help understand the requirements, business analysts help test, and project managers focus on removing obstacles.
So the biggest argument for BA's to convert to agile is that they become a more well-rounded project practitioner, which makes them more valuable to their employer, and more marketable to future employers.
Question: When introducing agile, do you suggest business unit training first?
No. I suggest that everyone on the team, developers, testers, BA's, business folk all talk training together as a team. Effective training is very experiential, and uses the teams own project for its examples.
Question: What is the best way to get PM's and executive stakeholders that are accustomed to waterfall on board with agile?
For executive stakeholders, explain to them the business benefits that can be seen with agile. This includes some value quicker, and the ability to see progress and provide feedback on a regular basis.
For Project Managers, position it as an opportunity to build their leading from influence skill set and point out that depending on the nature of the project, that the agile approach may be the best approach to succeed with their project.
Question: How do you overcome the hurdle of "that's the way we've always done it" mentality with project participants? PM, IT, Stakeholders?
Say "you're right." Then ask if the way we've always done it has worked for the organization. If the old approach has in fact worked, and by worked I mean delivered the value expected and needed to help the organization meet its objectives, then perhaps you shouldn't be changing. I suspect however that there is probably some room for improvement in how the organization tackles its projects.
Then provide them information of how agile has worked at other places in your organization or other similar organizations. Make sure that the examples you provide show how agile addressed problems similar to the ones you face in your teams.
Question: How do you get your leads (with only waterfall experience) on board with attending daily standup meetings?
Make it worth their while. The idea behind the standup meetings is that it provides an opportunity for the team to quickly coordinate their activities on a daily business and to identify (but not resolve in that meeting) obstacles that are getting in the way. These 15 minutes a day (an hour and 15 minutes in a week) can replace several hours that they would otherwise spend in meetings. The frequent checkpoints help the team keep in sync and avoid miscommunication and false starts that occur when the team does not keep in touch. Identifying problems that the team is facing and leaving the discussion and resolution of those problems to people that are most impacted leave the rest of the team time to return to the work relevant to them.