Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools

Reflection of the first preparation meeting

Anonymous Feedback

Overall Satisfaction

[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.]

Technology learned

[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.

Collective Review


  • 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


Discussed during the meeting

  • 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.

Value (stream) analysis

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.

Suggested solutions

  • 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).
teaching/labs/xp/2009a/preparation_first_meeting_reflection.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2024