Thurday at Agile - No lunch

Thursday morning started just like the other mornings: breakfast in the Grand Ballroom but with most people late. I guess Wednesday evening was quite exhaustive to many people.
I went straight to the Learning & Education stage where I could enjoy an amazing double session (went all the way through morning) of Game Design. This was NOT software game design. It was "hardware" game development. The idea was how to create games that could be used to teach concepts to people. Hubert Smits from Railly introduced shortly the work of Sivasailam Thiagarajan (aka Thiagi at www.thiagi.com).
After a short introduction, Hubert explained that we were going to build a game to teach Sprint (or Iteration, depending on your flavor of agile) planning.

We started by playing a game ourselves. Each os uf wrote down 4 cards with strong opinions he had about iteration planning. Hubert collected all of those and shuffled them redistributing 3 cards to each person. He asked us to sort the cards according to the importance we attributed to the sentence on the card. Meanwhile, he was laying down the rest of the cards on an empty table. Once we were done, he asked us to come to the table, now full of cards, and exchange the cards one by one on our hands with the ones on the table if we considered them more important. When he realised we were all happy with the cards we had, he asked us to trade cards among ourselves following the same idea to increase the value of the cards on our hands (according to our personal opinions). Finally, he ordered us to join with two or three other people and form a group. The group would have all the cards from its members and was to chose three cards that they would hold as theirs. The wrapping up was to have each group present their cards explaning why those cards were important to them.
I found this activity very interesting to align people's expectations about something. I could understand that it was a very good way to have people accepting other people's ideas. Hubert suggested it could also help building a team since the involved people would go from an individual perspective to a group perspective. To me, it looked like a very good ice breaker to get people thinking together.

The next part was the most important one and the goal of the session: to develop our very own game about iteration planning. It was a pretty simple board game. Each player had a character that was in a path leaving from start and aiming to reach the end. The initial rules that Hubert gave us were simple. All players receive about 10 cards at start and those are given back after shuffled when they are over. A player can only go forward if he presents a card that fits the stage in which he is. A player can challenge the presented card if he believes it does not fit that stage. Upon a challenge, all the players in the game should discuss the matter and reach a concensus. If they decide the challenger was right, the challenged player cannot go forward. On the other hand, if the challenged player was right, the challenger goes back one move and the challenged goes forward regularly. The first player to reach the end wins.
Based on those simple rules, we were supposed to define the stages of our game and then write the cards that the players would hold. That was a very interesting activity. It made us think a lot about what were the steps we considered essential in the planning and generated lots of discussion. We then had to gather all the cards we wrote individually and have them classified into the stages we defined. After that, we could change a few rules that we believed would improve the game. Finally, we played our own game to make a few changes with the game experience. We discovered the whole stage stuff was very boring since it took a long time to change stages. The idea that solved it was to have the game being iterative itself. Meaning each move would bring you to another stage and once you were done with the iteration, you would start another until you reach the end.
I loved that experience. It was a great way to have people think about their working system and how to teach it to others. Keeping a coach around as a game driver can be very useful to correct mistakes that the team can make. Finally, playing the game sounded a bit exhaustive but creating it is very revealing. The best part is that such game can be created to teach almost any process or complex non deterministic flow.

During the game session, Danilo, Mariana, Arnaud, Dan and Liz were working on the Block Problem with a Haskell solution. The most innovative idea was to set up a mercurial server (version control) and commit each step so that people could work on their environment and keyboard (Dan had a dvorak keyboard while Arnaud has an azerty one). Once I managed to take them off the, Mariana and me went have lunch with Danilo, Kiko and Bonnie Aumann (which we met at Kiko's presentation on Tuesday) at the CN Tower (CN stands for Canada National). It was a really good lunch with a great view and the chat was very pleasant. Kiko insisting that I was the french one so I should choose the wine and saying that being old (around 35) was way better than being young (around 25).

We came back from lunch about 30 minutes late and I went to my work on the Mezzanine floor. I used the half first slot I had left to relax a bit and review the things I want to ask for reruns. The second slot of sessions in the afternoon was filled with a Panel about open source and agile. The session was organized by Dennis Byrne and had Dirk Riehle, Mary Poppendieck, Naresh Jain and Christian Reis (Kiko). The discussion turned around what are the advantages of open source development that agility disregards or lost. Mary was very sharp as always which made the audience defended itself and attack a few points. I would not be capable of summarizing all we discussed there. The two main points that open source have were setting the user's expectation low and having volunteer work (and therefore committed workers).

After that, we all went to the Banquet where we could enjoy Uncle Bob's talk about Clean Code. Many blogs have already reported what happend but I would like to focus a bit more about his (re-phrased) point: "Craftmanship over Execution". I understand this as a consequence of all the refactoring value we have today. Nobody can sistematically say that refactoring is done. It can always improve. I have to admit I face frequently the question about when should I refactor some piece of code. Should I do it after I've written it and I master it? If I do so, I might be waisting time on something that will never be used (this code won't be extended). On the other hand, if I wait to refactor only when I need to, my code can look really crappy and it might take me some time until I remember how the code was supposed to work. Most of the time, I find myself refactoring things until I just have the feeling that it is enough. I don't know what makes me feel good enough with the code but, at some point, I accept it can be left the way it is even if more refactoring can be done. This sounds obviously as a support to the craftmanship theory since this "intuition" can only come from learning and experience. But shouldn't such motivations be triggered by some regular facts that could be documented? How do we create our craftmanship book? I have no idea but would surely like some tips.

Finally to close the night, Kenji Hiratabe presented himself with 10 other Japanese people by singing the well-know "Dear ecuspi (XP)". For those of you who lost that moment, check it here.
Believe me, around 800 people stood up and sang and danced hearing that. It was really fun!

Well, I am almost over for my reports. I hope I will post Friday by the start of next week. Then I should get back to my regular activities (Archimedes and Squeakasts). Bye bye everyone.