Many companies are in the process of changing their software development life cycle from Waterfall to Agile methodology. Volunteer youth coaches in the United States had to make a similar transition when beginning to coach soccer after years of playing and coaching baseball.   
    As a soccer referee, I can always spot the baseball dad who was asked last-minute to coach soccer. He is the coach yelling to the kids, "Stay in your position!  Get back! Get back!  NEVER to the MIDDLE! No, pass the ball FORWARD! SEND IT!" Why? Because the converted baseball dad has not grasped the difference between the games.
Specialists vs All Arounds
    In baseball, each player on the field has a position assignment with very well-defined boundaries of where we would expect that person to be. One would never expect to see a pitcher in the outfield. [Except, perhaps Kent Tekulve in the 1979 World Series... but I digress.] Players become experts at their very specific positions,  and stay where they belong.
    In Waterfall development, there are very well-defined roles:  business analyst, front end developer, middle tier developer, back end developer, tester, etc.. Team members do work specific to their particular skill set.
    In soccer, although players have positions that they play, the nature of the game is much more dynamic, and one often sees players move significantly from their "home positioning" to cover and support others on the team.
    In Agile, the team's goal is to deliver the sprint stories as quickly as possible. It is not surprising to hear in standup that a person whose job title is "developer" has picked up QA tasks in order to help the team finish the sprint.The best Agile teams have multi-talented members, who can pitch in wherever needed to solve a pile up.  
Individual Efforts vs Team Accomplishment
    When he steps up to the plate, the baseball player has his chance to shine and make us cheer by getting a hit.  On a double play, each player demonstrates his skill, then conveys the ball to the next person. (Tinkers to Evers to Chance!). Baseball is essentially a series of individual efforts, always in a particular direction, tied into a team result.  
    Likewise in Waterfall, each phase of the project focuses on a particular member: the business analyst, the developer, the tester, the deployment expert,  with heavily documented and staged handoffs between each team member and the next, progressing down a very well-defined path.
    On the other hand, continuous ball movement is what wins soccer games. The best teams think in multiple dimensions:  passing backwards creates space, and sets the team up for a successful attack. This requires an incredible amount of teamwork and communication to pull off well.
    Communication and collaboration are the keystones of Agile. Teams swarm to get a story done, and heavy documentation as well as handoffs are discouraged. "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."  [Agile Manifesto]
Up Front vs In Process
    Winning baseball teams take their scouting reports and analytics, come up with a plan for field positioning and pitching, and implement this plan during the game.
    In Waterfall, requirements are gathered in the initial phase of the project, and these requirements form the basis of all subsequent work. Next, the architecture is determined and set down and recorded in a document for teams to reference.
    In soccer, on the field decision making is essential. Pregame preparation should concentrate on teaching the team to recognize patterns, and make good decisions on their own based on those patterns. During the game, I hear the best coaches remark, "That's a 3v1 - you know what to do."
    In Agile, the preparation phase gets just enough of an outline of a project to get a feeling for what is needed to be done. Drilling down into the requirements happens as each story is worked in the sprint. As the requirements are better known, architectural decision points are reached:  the team needs to be equipped to quickly make the best choice.
Static vs Dynamic
    Baseball is a slow-moving, predictable game - you always know who is on offense and who is on defense.
    In Waterfall, the project outcomes and requirements locked in after the initiation phase. If any new requirements are discovered, their incorporation is tightly controlled and most often held to end of the project. The project never strays from original vision.
    Soccer is characterized by quick transitions - possession changes instantly, and a single event can dramatically alter the tone of the game.  
    In Agile, new requirements are uncovered as team works with the business, and incorporated quickly into the cycles. Hence, the project can easily change direction and evolve - this is by design.
Preparing your teams to do Agile
    To develop a winning soccer team, former baseball coaches needed to learn that the two games are very different from each other. When transitioning to Agile, make sure your teams understand that it's a whole new way of working.  

• Provide the teams with adequate training.  Have the teams discover the differences by comparing and contrasting to the methodology they are already using.

• A very difficult concept to grasp is the "minimum viable product": the focus of Agile of delivering a tiny slice of what is requested that still has business value.  Hire some people who have successfully implemented Agile in the past to consult on what minimum viable products look like in your domain.

• The team needs to come into the project with a "we're all in this together" mindset. Spend some of your preparation phase on team building exercises.  

• Do a skills assessment of your team, and note where each member needs to grow from specialist to generalist, as well as any gaps that could cause a pile-up in work.  Decide on a strategy for increasing the team's skill sets.  Pair programming, where two members work on the same code together, is an excellent chance to pair a less experienced member with a more experienced one - the concept can be extended to any of the tasks in the project.

• Because the team will need to make many architectural choices, be sure to furnish them with access to your patterns library.  Incorporate reviewing patterns with the team as part of the normal sprint work. 
• As new requirements are discovered, the solution architect needs to be involved, so that she can help teams to plan out what architecture is best for meeting the requirements in a robust way. "The best architectures, requirements, and designs emerge from self-organizing teams. " [Agile Manifesto] - but only if the teams are properly educated and experienced [ Kristin's corollary]

Transition is often challenging:  whether it be transitioning from baseball to soccer coach, or changing software development methodologies. Preparation, research, and a new mindset will be the keys to your success.  

Let the match begin!

References
http://www.agilemanifesto.org/principles.html