The presentation took place Teusday march 5th, 2002 at l'ETS.  
Approximately 25 students attended.

The good :

	1. dicussion was lively and interesting ;
	2. the class did not strictly come from a university / research background ;
	3. we got most of our stuff across in a very short amount of time ;
	4. jerome was more radical, JP was more of a moderate, which made for an interesting mix ;
	5. the class as not freaked out by PairProgramming.

The bad :

	1. we came across like evangelists (might be a consequence of clashing of mindsets during a magistral presentation) ;
	2. the students were not helped (by us) to come to "realisation by consequence" ;
	3. we didn't establish that the students had failed with other processes.  this would have helped targeting where  weaknesses are with regards to writing docs a priori.

The ugly :

	1. the class couldn't get over the fact that we don't design ahead of time  ;
	2. jerome kept slamming RUP :).

----

A couple of things came out that where interesting in presenting this. The first one is that people write docs in time consuming software (UML editors, for example) as throw away docs. They do class diagrams, for example, code the diagram, and never maintain the docs again (a couple of people said this much in conversation).

The second one, from private conversation, is that Xp works with above average skill programmers. There's a wiki page on this. Gotta find this. We've had discussion on this.

----

Things learned :
	1. Don't slam RUP : it polarizes discussion. It's best left to the students to bring it up.
	2. Let the students figure it out for themselves : in ths presentation, the only thing we let the students figure out is the workspace organization. We could have presented this in such a way that they could have figured out much more. So shoot me, I'm a constructivist.
	3. There is no "no docs" practice : concentrate more on what we do than what we don't do.
	4. Let the students figure out the problems : if they have implemented RUP and it works for them (they meet dates (without multiplying man hours by 10), and have no bugs), you'll have a hardtime convincing them about the values of other methodologies.
	5. Insist on TravelLight rather than KeepItSimple (positive versus negative again).

----
MontrealXpUsersGroup