My approach to Drupal training

I have been doing Drupal training for about 2 years now; I have also taught two semester long classes in Drupal. All in all, that's about 200 people. As I am sitting here looking for new ways to teach and train (moving to a Linode VPS, changing assignments, developing new materials); and I think I need to explicitly state my position on how Drupal training should be done.

Make it hands-on
Human beings learn better by doing than by listening. If you are teaching databases and ask your students to imagine a database, you are doing it wrong. They have to have access to a real database - and not some lame local MS Access stuff, but the real web-server-based deal like MySQL. Encourage experimentation. (corollary idea: to do hands-on training well, you need at least 2 hours - and that's if you plan everything very well and have no glitches. Don't attempt short zipline tours - there is not enough time to get people to repeat common tasks to develop habits).

Give as much access as possible
If you are teaching Drupal, at the very least give each user admin level access to his or her own Drupal install. Ideally, also give them FTP access to the codebase. The more advanced the training, the more access is needed - all the way to database access and maybe even command line access to be able to try Drush. Yes, the more people can tweak the more things they will break; counter that with clearly defined access (give them access to their stuff, not other people's stuff or the server) and have daily and ideally hourly backup ready to be able to restore their sites if they really screw them up. Another good thing about lots of access is that it makes your users feel empowered and trusted.

Use the latest code
Use the latest code for the core and contributed modules. That means occasionally working with beta and even alpha code. Things are more likely to break; but your users need that experience to learn what level of risk is appropriate. Current unstable code will likely be stable by the time the people you train use it on real life projects; and the current stable code will be obsolete.

Explain "why" not "how"
Don't teach people where to click in the GUI; teach them why they should be clicking there. Show them the underlying principles of the system.

Ask for feedback and ideas
Ideally build some basic questions into your registration form to get initial ideas about user needs (level / expectations / projects they will work on); set up a web form to collect feedback after training to help you improve. Most importantly, solicit ideas during training. If you are planning to teach them how to create custom content types, ask your audience to come up with some ideas on what content types they will need in their projects; decide together what fields you will need and built the content type. Just remember that this type of improvisation requires a lot more from you; teach with a canned content type idea first to work out the bugs and then introduce ad lib elements.

Drupal Literacy is for monkeys; teach the big picture
Don't teach basic things without the global context. You don't teach people "basic" driving skills by showing them the steering wheel - you teach them to relate to other participants in traffic, and you teach them that the car runs on gasoline and needs regular oil changes. This goes hand-in-hand with the "why"-not-"how" approach - to be able to teach the causes and principles, you need to put things in context. In Drupal terms, that often means teaching about HTML, CSS, PHP, MySQL, LAMP, and FTP, among other things - and about conceptual ideas like information architecture and content strategy.

Document 100% of your training
Public speaking theory teaches us how to deliver good speeches - very carefully planned speech outline combined with extemporaneous delivery. You should be doing the same in training - the step-by-step documentation (ideally integrated into your training sites with local links to admin resources and functions) provides the scaffolding for your training without stifling your ability to follow up on user questions, adjust content, pace, and the level of explanation.

Teach only as much as you can cover well
If you have planned to teach 10 topics and realize that your audience is less prepared than you thought and you can cover only 3, focus on those three. There is more value in teaching less well than teaching a lot poorly. If you have proper documentation built into your site, adventurous uses will be able to teach themselves the remaining 7 topics after the training.

Training doesn't end with training
Most of your users won't leave the room and start working with Drupal 24/7. They will probably return to Drupal a day, a week, or even a month later - when they have forgotten a lot. What do you have in your training to aid their recall? I like having built-in documentation, a customized Dashboard to help them find common tasks, and a list of useful links (including my contact information).

Create a habit of looking for answers
In the beginning, you want to hold your user's hand very firmly; but towards the end of the training it is a good idea to present them with a problem that they can resolve themselves by looking up answers on google, durpal.org, stackexchange, and so on. Without the habit and the knowledge that they can find answers to common problems online, they will be helpless once they leave the training.

Don't police content
The trainer is a mediator, and as such he or she has no ethical right to get involved in content appropriateness decisions. You should be able to help create Sarah Palin's supporters site without a single negative comment about the Tea Party. You are only allowed to criticize and correct badly designed content types, not the content itself.

Don't expect a bureaucracy to have startup mentality
Most of the time you don't teach pure Drupal; you teach it on the clients' custom configuration with featured disabled for security reasons, features unavailable because the hardware is not compatible, or features not enabled because the system admins are lazy. Make sure you learn as much as possible about the local flavor of Drupal, and share that knowledge with the people you are training.