Differences

This shows you the differences between two versions of the page.

--- teaching:labs:xp:2009a:preparation_first_meeting_reflection [2009/01/12 22:30]
Daniel Speicher
+++ teaching:labs:xp:2009a:preparation_first_meeting_reflection [2018/05/09 01:59] (current)
@@ Line 1: / Line 1: @@
+====== Reflection of the first preparation meeting ======
+===== Anonymous Feedback =====
+==== Overall Satisfaction ====
+{{:teaching:labs:xp:2009a:firstmeetingoverallsatisfaction.png  |}}
+[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 ====
+{{:teaching:labs:xp:2009a:firstmeetingtechnologylearned.png  |}}
+[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".]
+==== Comments ====
+[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 =====
+==== Keep ====
+  * Games
+  * [dsp: There were a lot of good things in the presentations.]
+  * [dsp: The meeting times were respected!]
+  * [dsp: Open mind to game experiments.]
+==== Drop ====
+  * [No idea]
+  * [dsp: Cookies are only provided close to Christmas. ;-)]
+==== Try ====
+  * Strict schedule
+  * More small breaks
+  * More time for exercises
+  * More time for discussion
+  * Include the extra time [for games etc.] in the schedule
+===== Consequences =====
+==== 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.)
+=== Values ===
+  * 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.
+=== Waste ===
+  * 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).

SDA SE Wiki

User Tools

Site Tools

Differences

Page Tools