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

User Tools

Site Tools


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

Link to this comparison view

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

SEWiki, © 2019