Accueil / How to reach 90% and make it stick: Lessons from Acquia's DrupalCon training

How to reach 90% and make it stick: Lessons from Acquia's DrupalCon training

This DrupalCon Chicago, I delivered a full day training with a cross functional team of Acquians on "Upgrading your site from Drupal 6 to Drupal 7". By account of evaluation results and my own perception we were successful in delivering an experience which provided real practiced knowledge while engaging a diverse group. There were also a couple themes for improvement which I'll be touching on, the process of preparation and perhaps a bad joke or two.


Heather James - our training manager, assembled a team from the three technical branches of Acquia: Erik Webb (Professional Services), Joshua Brauer (Client Advisory) and myself (Engineering).

  • Erik helps enterprises adopt Drupal by doing site audits, architecture consulting and training for Drupal developers.
  • Joshua does the same, but also responds to emergency situations, troubleshoots difficult performance issues and advises our clients on their technology choices.
  • I am a Scrum Master for which means I help build the product and occasionally remind cats to herd themselves.

Having multiple instructors from different viewpoints helps to answer the greatest diversity in questions. Also, people have a very low attention span listening to one person talk, so a group really helps mix up the tone.

Pre-conference survey

A couple weeks prior to the training, Heather sent out a survey to participants to feel out the mix of roles, knowledge they wanted to acquire and the industries they worked in. A few of the questions we asked where:

  • Job title, company name, website, etc
  • Upgraded Drupal before?
  • Drupal experience?
  • What are your general goals for the training?
  • Do you have a specific case you want to look at?

The survey was interesting and exposed some flaws in our plan, but ultimately, only 1/2 the participants responded. The 22 person group turned out to be approximately 70% academic, 10% SMB, 10% enterprise and 10% non-profit. All participants were developers / designers of some sort, some very technical, others mostly project managers. We knew we were going to have a diverse crowd, so we prepared for it.

Make friends and ask directions

Far more important than the survey though was getting to know the participants. I can't stress this enough. I came to the training center early before the crowds. As people came in, I introduced myself and got to know a little about each person and specific goals. Obviously it is too late to alter the curriculum at this point, but it produces three important benefits:

  • Sets the tone that this is an interactive session and they are all individually important to me.
  • Identifies the appropriate tone and vocabulary to use with them depending on their technical expertise.
  • Allows me to tailor my individual interactions around their goals, not mine.

On the importance of doing

David Kolb's well known Experiential Learning Model specifies four elements of learning.

As a facilitator of this process, I feel a traininer should:

  • Ensure all four elements are covered.
  • Help the learners move through each step at a pace which doesn't frustrate them.
  • Create an atmosphere where people become more confident in their new super powers.
  • Entertain enough to maintain high energy

The exercises were all fake sites which had "real" looking content and structure. It's really nice working for a company like Acquia, because when we were in a time pinch, our client advisory team stepped in to build the sample sites. The CA team (hiring!) have probably touched more Drupal sites than anyone else in the industry and as such are experts at finding the problem. And because of this, they are perfect at creating scenarios where there are the right kind of problems. They developed three sample sites for us in increasing difficulty which I felt really touched on the areas we needed to cover in an introductory class.

All of the exercises for the day were in pairs or groups. Some were done on everyones' individual computers, some just on a single computer. The instructors floated between groups, answered questions, sometimes off-topic questions, and generally debugged whatever issues people were facing.

One participant, Tanya Plonka, a photographer and designer from Lethbridge, Alberta said to me later that "I found the process of making backups, and going through the steps to get ready a little tedious, but by the end of the day, I realized that it actually made it stick in my head and now I can see the process from start to finish."

See Tanya's excellent pictures of the day and of all of DrupalCon on her blog

Tedium is not the goal but for me; success is the feeling of integrating a new skill as opposed to mereley learning a new fact. To get there, sometimes you have to walk there on your own. I want to feel not like someone learned something from me, but that they can do something now which they couldn't do before.

Fast lane / breakdown lane

90/10 Rule

As a trainer, the best you can hope for is that 90% of the class find the experience fulfilling. It shouldn't be a waste of money for anyone, but trying to target everyone is a fool's errand. The class was advertised as an introductory class to upgrading. Since every upgrade is a completely specific case, and within that each component presents unique challenges, we agreed early on that the goal was to teach people the correct process; to know what questions to ask, since we could not provide all the answers even if we tried.

However, there are people who came to the class knowing 80% of what we were showing them. They came because they are facing technology decisions now which have a long lasting impact and they need to know if the Commerce module has a clean upgrade path or the API for migrating custom CCK field types, etc. These are important questions, but naturally, we can't prepare for all of them, and we couldn't possibly cover all of these and produce a cohesive experience for the group.

The audible

Since the survey suggested some people were "in the fast lane", I had a backup plan for the case that we had a room full of pros who attended with specific questions (despite the general advertised curriculum). It became apparent early on that a breakout session would be appropriate, giving them expert guidance in a roundtable format.

Erik Webb took this group on in the afternoon and it was really well received. About 50% of the class opted to go out and have a free form discussion of D7 APIs and the other half went through our advanced exercise and workshopped some of the tougher issues there. The feedback was universally positive from both groups on this approach. It felt good to not be dogmatic about our schedule and just flow with the needs of the people there.

Bring extras

The main complaint we got was that there weren't adequate advanced exercises for more experienced people to move on to if they finished early. Even the advanced people felt that the material lived up to the billing and agreed that we needed the baseline, but it would have been better to provide activities the advanced students could move on to independently even if most of the groups were still working on the introduced exercises. In the future, maybe this means more preparation or perhaps having tiered groups for the entire day, not just the ad hoc discussion in the afternoon.

In addition, there were a couple people who were relatively novice. Working in groups and having ample instructors to help them took care of this issue for the most part, but I could imagine in a more niche or challenging class, this would be a bigger problem that I don't really have a good solution to.

Room for improvement

While this training was a success, I think there are some things that we could have done better in order to make the day even more successful and less stressful for us as trainers. It really doesn't take much to turn the day upside down when you have 22 students. If the infrastructure fails or if the exercises don't function as expected it can be very hard to recover. We had a couple gotchas here, but nothing major. Below is what I'd like to do differently next time.

  • This was the first run of the class, and so some kinks inevitably have to be worked out. Next time, I think we would have done a dress rehearsal, ideally in the space with a couple of peers to see how it all fit together. We had never given this specific presentation publicly before, and rehearsing internally is never quite the same. While the exercises had been tested, we hadn't run them against all the possible operating system setups we faced the day of. Thankfully, we didn't have anyone who totally fell behind, but there were a couple gotchas for Windows users we hadn't counted upon. Lesson learned? Practice, practice, practice, and then practice some more.
  • The instructors all have "day jobs". This is great because we bring a lot of credibility to the table, but it also means less time to prep and practice. That's always a tricky balance, you want people who practice the material in the "real world", but you also need people who are capable trainers and have time to hone the experience. We had a good mix of both experts and trainers, and that allowed us to react quickly when we wanted to make changes during the day.

The Drupal training industry is not very well equipped to handle the demand it is facing. Quality is variant, availability is scant and curriculum is expensive and hard to maintain as the space changes frequently. Acquia is trying to address each of these, and this is something I intend to work on personally. Hopefully you'll be hearing a lot more about Acquia training initiatives in the months to come and my involvement in them.

P.S. I would like to float a class on "Understanding the Drupal community - how to recruit, manage, partner, contribute or perish: A guide for project managers and technology decision makers". What do people think of this? Would you be interested?

Images: | |
Sign up for our blog newsletter!


Ajouter un commentaire

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • Pour publier des morceaux de code, entourez-les avec les balises <code>...</code>. Pour du PHP, utilisez. <?php ... ?>, ce qui va colorier le code en fonction de sa syntaxe.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Les lignes et les paragraphes vont à la ligne automatiquement.
By submitting this form, you accept the Mollom privacy policy.