I’m a tactile learner. I digest information a lot quicker from playing with things than from reading books. That’s why I like running training workshops and attending things like that at conferences. Working through the proposals for the upcoming Progressive .NET tutorials, we had quite a heated debate on talks and workshops as teaching styles, with some people saying that they know how to prepare a good talk but don’t know how to design a workshop. Converting one into another isn’t that hard at all. Here is what I do normally to design a workshop from a talk:
- Start with a list of things I’d like to talk about (let’s say good practices for acceptance testing); it often helps me to create a powerpoint slide deck for a short talk
- identify solutions I’d like to present (say specification over scripting, cross-functional teams)
- for each solution, identify a good problem example that demonstrates how the solution brings a good benefit compared to alternatives (for example, a script that’s perfectly good for a regression test, but useless as a communication tool)
- add the problem before the solution in the slide deck; make sure to remove anything that actually presumes a solution in the problem description, especially things that would give away what I want to present.
- break down the slides so that I can pause between the problem and the solution
This gives me the basic structure of a mix of exercises and presentations. I start with the presentation as I would normally and stop after presenting each problem. Then I split people into groups and let them try to solve the problem. I time-box this and go around while they are solving it, joining each group for a short while. Depending on the problem, I apply two strategies while doing this:
- If the problem deals with a new technology that people might not know about (eg new specific CLR features), see what they are doing and gently push them in the right direction.
- If the problem is more conceptual than technical, and has a classic bad solution that people fall into, let groups fall into the trap. Answer questions they ask but don’t try to point them into the right direction yet.
In the first case, we expect everyone to end up in more-less the same place because of the help, so presenting one good solution either from a group or the remaining slides (solutions that come after problems) is a nice end for that exercise.
In case of the other group of problems, we expect groups to arrive at different places – one group might directly fall into the classic pitfall, another might be halfway to the right solution, a third might come up with something alternative that you haven’t thought about. Let one person from each group present where they are, and then discuss solutions with everyone as a group. If your preferred solution was reached by anyone, discuss why that’s better than the rest. If not, present your solution after this and discuss that as well, comparing it to the other solutions.
Aim to run each block for 30-45 mins and have 15-20 mins of discussion after. A typical 3 or 4 hour workshop gives us enough time to work through two or three of these blocks, depending on the remaining slides to discuss (intro/retrospective etc).
|
|