Montreal Xp Project

Session of January 2003 (21th meeting) : No iteration

The project stopped and we reflected on how it was going.
Too much setup time.
Not enough time for coding.
Lack of Debriefing and feedback session from each session.
When debriefing existed, it was interesting.
Too much practice not enough exchange on process.
Too much people for the time allocated: merge was really hard small session duration.
Programming session was less interesting than presentation / exchange session.
Pattern : on session was going well with less people, next session was going less well with more people.
Less learning that one night code with a predefined project (as the night with small groups on doing work on each laptop from sam user stories).

Session of December 2002 (20th meeting) : Third Iteration

We were 15 people.
The moderator/facilitator left a mid-session -- jmh

Session of November 2002 (19th meeting) : Second Iteration

Active session from 19h30 to 22h50. Feedback session from 22h30 to 22h50.
Two laptops only. Around 12 active peoples.
Different dynamic comparing to October (see notes bottom of the page).
Sense of accompishment ! We did the first user story.
We need a repository outside the laptops because one of the october laptop were absent. (so we lost some data.) jmh to do a followup.
We rewrote the customer test (and simplified them !).
We did the customer test framework.
And the basic calculator.
Customer test ran at the end of the session !
Interestingly, we did speak very only little about the experiment. But people seemed satisfied from their experiment and did not say much...
you can find the sources in the Files section of http://groups.yahoo.com/group/xpmontreal

Session of October 2002 (18th meeting) : First Iteration. Zero value iteration.

Active session from 20h00 to 22h30. Feedback session from 22h10 to 22h30.
Setup takes time ! (and it is not finished).
Need working on pair programming skills. Need a coach ? Reminder of Pair Programming Guidelines/Rules.
Important : Design discussion in pair / trio (CRC session).
Trio programming does not work !
3 laptops not enough for 14 people ! What experiment whould we do to make it work and have fun ?
jmh will bring a power bar and an extra network cable.
Should we do a Standup meeting (e.g. at 19h00 or 20h00) ?
Acceptance Test Framework has begun with a Java app to interpret scripts (will be ran on Linux and Windows2000).
We kind of planned for 4 units of work (3 units: first story, 1 unit second story).
No acceptance passed : Should we consider this as zero iteration. So we can not really say that we know a velocity.
Should we formalize a little bit more the feedback session: e.g. round table, one person at a time (strictly enforced by a named moderator ?).
Sugggestion : 14 people could be split up in mute observers (e.g. observer of pair programming session). Then objectively give feedback on pair-programming session.

Session of September 2002 (17th meeting) : The planning Game: Estimates

2 parts of 45 minutes.
45 minutes divided in 30 minutes (actual work) and 15 minutes (mini feedback session).
Results : Less interruption.
Work done : all estimates.
We began at 20h00 and ended at 22h00.
Next meeting : Prioritization of tasks and machine setup.

Some rules/rights

Les séances de simulation ne doivent pas être interrompues par les discussions sur la manière de faire la simulation donc prenez des notes.
Les conflits sont autorisés voire encouragés mais toujours dans le cadre de la simulation.
Une période post-mortem doit nous permettre de discuter de tout le processus.
Limite dans le temps par soir pour le projet : 19h30 a 21h30 avec une pause de dix a 20 minutes vers 20h20.

During the 16th meeting of MontrealXpUsersGroup, we debated and brainstormed around possible projects and finally voted for a calculator as a project. Not too hard at first. We attempted to define some user stories with some success. During this 3 hours, we begin to learn how to work together. It is not the same thing at all than simply meeting once a month! I believe we are in the stage of storming in the team. We were about 15 people. We voted the way the client will be represented: a pair of people. Two people volunteered for being client. So Youcef and Luc meet the developper to discuss some requirements they have. Next time, we will nail down user stories for this vision and make estimates. -- jmh

Original list of possible projets :

Robot simulation
Ftp server
(Simple) Database Access (need MockObjects) --Jerome
Simple game: Tetris like: the challenge: how to test a highly interactive GUI

While programming in trio, and talking to the acceptance test guys, we forgot one big step I do believe, some design. We came up with an interface too quickly (and I apologize if I was rude then). Before spliting the work like we did, we should have distributed the roles and made some design.

---

October 2002 : Trio programming does not work !

Why do you say that ? I don't think we had any major problems... maybe others could share the problems they felt trio programming caused. I'm not saying we should scrap PairProgramming in our real lives but I think under the circumstances TrioProgramming? was pretty successful.

November 2002 : We were 4 or 5 around each computers (we had only 2 laptops). The dynamic in front of the computers was so different from october. What happened ? We were two people less. We also reflect on what went worng in october and raise that we had to improve the discussion before jumping into the code. We did discuss and apparently it solved problems when in front on the laptops ! Around Pascal's latpop were people that listened a lot to Pascal. Not much pair programming on this side. Around Jerome's we had almost quadro programming: Jerome, Rod, Luc, Vincent. The keyboard was passed from one person to another but interestingly not so often...

---

Interestingly people seemed to gravitate towards certain roles that most seemed comfortable with.