[The following interpretation of the scale was given before the poll: 5 represents a rather neutral feeling. Below 5 there is dissatisfaction and above 5 satisfaction.]

[No interpretation of the scale was given, but it seems to be natural to interpret 0 as “nothing learned” and 10 as “learned as much as possible in the given time”.]

[In alphabetical order.]

• “Unified” infrastructure to avoid presentation problems.
• A more planned time schedule would be nice!
• All basic technology was already known. The presentations were nice to refresh the knowledge.
• Missed some practice!
• More time to prepare for the topics.
• More time to prepare the presentation and a clearer time schedule about the presentations would have been nice.
• Overall environment was very nice.
• So little time for practical stuff on Prolog.
• Way too low time for good introduction to huge topics as TDD/Test-First.
• Would make sense to do some hands-in exercise, so each could try the problems.

• Games
• [dsp: There were a lot of good things in the presentations.]
• [dsp: The meeting times were respected!]
• [dsp: Open mind to game experiments.]

• [No idea]
• [dsp: Cookies are only provided close to Christmas. ]

• Strict schedule
• More small breaks
• More time for exercises
• More time for discussion
• Include the extra time [for games etc.] in the schedule

• Although the need to have more time for the topics was felt by almost everybody, a quick poll showed that extending our next meeting is not an option (4 of 10 votes against this suggestion are striking).
• We will continue to use games. [The team didn't get the time to improve his stick-lowering strategy. So it needs another chance next time.]
• Daniel will prepare and publish a clear and precise schedule before the next meeting. The schedule will contain time for the extra elements (games, talking, reflection) and breaks.
• The presenters will condense their presentations to the essentials. If tutorials are included a realistic share of the time needs to be allocated for that.

When did we waste time, i.e. spent time in a way that wasn't contributing to the overall value of the preparation? How can we reduce the waste? The following is just the result of a little thinking by dsp. (The focus is not on what went wrong but on how can we improve the meeting.)

• Deep understanding of the topics by the presenters/experts.
• Good overview of the technology as background for further learning during the lab.
• Basic knowledge how to use technology.
• Hands-on experience of tools (to overcome the inhibition threshold to use the tools).
• Motivation to use beneficial agile practices.

• Time for switching from one laptop to another.
• Partially understood tutorials. (See comment above.)
• [We can probably come up with more “waste”, if we start from the list of typical waste in software development elaborated by Poppendieck & Poppendieck: Partially done work - Extra processes - Extra features - Task switching - Waiting - Motion - Defects]

Breaks are no waste as they contribute to the ability to understand the presentations and tutorials.

• Presentations
  • Name the five essential points that everybody should remember after the talk. (Create a summary slide listing them. Illustrations make it easier to remember them.)
  • Remove everything from your presentation that doesn't contribute to the understanding of these essential points.
  • Review the values and remove/add elements to provide more value with smaller effort if possible.
• Tutorials
  • Double check tutorials. (Try variations. If you rely on certain names, write them down.)
  • The second partner (=: assistant) should walk around to assist the other participants in case of problems.
  • There might be other experienced participants. Find them before the meeting and let them assist the others.
  • Before proceeding with the next step, make sure that everybody got the current step. (Don't ask. Let the assistants tell you!)
  • Working in pairs is sometimes useful.
• Organization
  • Suggested schedule will be published by dsp already this year.
  • Send your five essential points latest one week before the presentation to the contact teachers for your topic.
  • Presentations are submitted [to the repository or to dsp] two days before the next meeting.
  • The same holds true for the tutorials and the required tools.
  • On the morning of the Thursday before the meeting we create an IDE and a workspace that contains everything for each tutorial.
  • This setup will be distributed via SVN and USB-Stick.
  • We will use only one computer for the presentations and the tutorial (Two, if somebody needs a Mac).