Essap 2007, second part
Here is the second part of my comments about Essap 2007.
Friday. Last day.
The day started as usual with the standup meeting. We’re getting better and better at this; it only took 10 minutes today. We had a good feeling for what people appreciated yesterday (Fabrizio’s presentation expecially.) Noone reported any particular problems, perhaps because any problems they have they got used to it or there’s no more time to do much about it.
Simone suggested an excursion for the late afternoon, when the school closes. We’re going to “Paradise Peak,” a suggestive vista point on the “Sacro Monte” near Varese.
Then Luca Grulla started his session on “Retrospective Techniques.” It’s amazing how much Luca has improved in self-confidence, compared to last year. In fact last year I had to insist that he lead the final retrospective, and took me some time to convince to do it (he was much better qualified than me, since he led a few already.) This year Luca answers with confidence many questions from the audience about agile in general. His presenting skill is very good: clear slides with little text and plenty of examples. It’s clear he knows his stuff from experience. He explains the basics of retrospectives: the goals of a retrospective, the Prime Directive (everyone did the best they could, there will be no talking of blame), the phases and exercises. Luca confirms what Gabriele told me already, that the “Agile Retrospectives” book is full of excellent advice on how to do retrospectives in an Agile setting (that is, not “at the end of a project”, but “at the end of an iteration”, or even “whenever you need one.”)
I did not know that the facilitator should preferably not be a member of the team. When you can, you have a member of another team in your company lead; otherwise, you can have someone in the team facilitate, but he should clearly mark the “change of hat” from when he is contributing as a team member to when he is facilitating.
After the presentation, Luca divided the audience in six four-people teams, and assigned a role-playing exercise to each. For instance:
You are the support development team of an important online bet agency. Customers call a 24/7 call center reporting problems and the call center talks to you to fix and close defects. The team is struggling due the high volume of requests that daily receives from the call center(and some of these are not actual defects).
2 Tester, 1 Developer, 1 Project Manager
We had some pizza in the park for lunch. Then in the afternoon Luca facilitated the retrospective on the Essap itself. Last year he had us place post-its on a timeline of the week. This year he had us do the “starfish” exercise, where we break the whitboard in six spaces: “stop doing”, “do less”, “keep doing”, “do more”, “start doing.” Then everyone writes no more than two post-its for each of the categories. There was a lot of people, so the whiteboard was very crowded. It was exciting to see the whiteboard covered thick with post-its!
My mind is full of thoughts of what I did wrong, what we can improve for next year. This retrospective was a very positive experience. The mood of the people was clearly positive; everyone looked happy and the there were much more stickies in the “keep doing” and “do more” sections.
I had many good suggestions from the “start doing” section, some really insightful. The main complaint was that we had not enough time to spend on the hands-on project. I will certainly agree to this. There was too much time allocated to sessions, and not enough time allocated to the project. Jacek suggested that we optimize session time so that exercitations in a session can be directly related to the hands-on project. Mikael suggested that we limit session topics to the most important things, so that we keep focus on the most fundamental things that are needed to start working in an agile way (with an eye towards the hands-on project.)
There were many stickies with “Ruby on Rails”, in the “keep doing section”, but quite a few with the same in the “stop doing” section. I understand this. Rails is fun and attractive. Yet it can be an obstacle to learning Agile techniques. Learning TDD and simple design is difficult enough, without the added difficulty of learning a new framework. It seems to me it will be a good idea to drop Rails and web applications in general for the next edition. It would be a good idea to keep technology to a minimum: no database, no GUI; focus on the domain objects. Luca suggested a command-line application.
It’s a bit of a pity for the JooB lab application. The idea was very good, and the people of the Varese XP UG did an excellent job of developing the skeleton application (and creating the lab infrastructure, and setting up the participants laptops!) But you must focus. On an Agile school you should stick to simple OO programming. In a Rails school JooB would be a great project. In fact I’d like to use it to teach Rails, if the authors will agree to publish it as an open-source project with a liberal license.
There were some post-its about better coaching during the labs. I agree with that, as well. There should also be an experienced coach for each team. This was not possible this year, for my two coaches were not available; Gabriele sick in bed, Federico away for a conference. Next year we should have at least a coach for team, and a spare one to cover for the unexpected. This means that we should have at least three coaches if we want to have three teams. And, the teams were too big. I would say 5 to 6 people is the maximum for a new team; this will limit the number of participants to, say, 16 if we have three coaches, or 12 participants if we only have 2 coaches…
There was an awkward moment for me, for many participants suggested that we give badges with the names on the first day; Luca noticed that the same item came up last year at the retrospective, and I did not act on it. The retrospective is a waste of time if you don’t implement the actions! My fault.
So what were the other actions that were suggested? Luca had us vote; the highest votes went to “more hands-on work” and “have printed material ready before the conference.” Point taken; I will implement these two. I asked Luca to be the appointed sponsor for the name badges :)
One thing that participants were enthusiastic about was the use of the pomodoro; they found a lot easier to follow a long session, when the organizer pauses for 5 minutes every 25. Some organizers didn’t follow the pomodoro rule strictly, and the audience found this annoying!
After the retrospective we closed the school. Most people left for their trains. A few stayed for the excursion on Paradise Peak. And it was worth it! I didn’t know there was such a nice wood just outside Varese. The view from the Peak was breathtaking, the weather was perfect. The smell from pines in the crisp air, the bright sunlight: Summer at its best.
