|
|
Day 3
TDD
Matteo presented a “Bowling Game” Kata, to show how TDD works, in very small steps. After the Kata, we ran a Randori, where we tried to write a roman-to-decimal converter. At first, the team made some progress, but then got bogged down by the combination of unfamiliarity with java, TDD and the difficulties of the problem. I’ve now participated in a few Randori’s and I’ve seen this pattern a lot: people get into trouble and try to program themselves out of trouble, thereby making the situation more difficult. What can we do when things bog down? Step away from the keyboard. Revert back to the last working situation, erasing all code that was written since then. Take a break. Draw something on the whiteboard…
Meanwhile, Jacopo and I sketched out different approaches on a (paper) notepad. We tried simplifying the problem by breaking it in two parts; we tried a data-driven approach with very little logic; we tried a more algorithmic solution; we went through the data backwards, then we tried to go through it in the other direction. Programming problems have lots of solutions, each with their advantages and drawbacks. We explored several alternatives on paper and in our heads. We were the final pair in the Randori and finally implemented the algortihmic solution the team had embarked upon, despite the weird Italian keyboard, which seems to hide the { and } keys 🙂
During the lunch break, I wanted to see if we could do a simple Ruby implementation, without any loops or ifs. Of course we could! I haven’t been programming lately: getting people to follow a waterfall methodology takes up too much of my time. I realized that I still like to program. TDD (or should I say BDD?) is the fastest and most fun way I know to write working software. These little Katas are great exercises to explore different ways to solve problems. On the train from Milan to Geneva (read more in the next entry), I worked some more on the Roman numerals and on a Sudoku solving program.
Oops
During the Randori, we noticed that few participants had experience with java, the programming language chosen for the course. This could pose a problem during implementation. Pairing with people who know java helped, but we still lost a lot of time with the complexities of the java libraries (who invented java.util.Calendar and what were they smoking?) and infrastructure (web server, database) that we didn’t really need. Time to adapt again: we focused on the domain code only.
XP in Milan
Matteo, Luca, Allesandro and I went to Milan to meet with the local XP User Group. We talked about the activities of both groups, how we’re organized and the state of agility in Belgium vs Italy. We continued the talk at a nearby Chinese Pizza restaurant, were we had a mix of pizza and Chinese food.
Some members of the user group volunteered to pair program at ESSAP, to add a bit more java experience. On Thursday and Friday, there were lectures on acceptance tests, continuous integration and retrospectives. Of course, ESSAP ended with a retrospective and a party.
Read more about ESSAP.
Ciao! 
Ciao Jacopo, Luca, Alberto, Francesco, Alessandro, Davide, Andrea, Piero, Matteo, Sergio, Federico, Alessandro, Alejandro, Uberto and the members of the Milano XP UG. Hope to see you again. In Italy, Belgium or at one of the fine agile events around the world. Hint: if you like beer with your agility, don’t miss XP Day Benelux in Mechelen.
I couldn’t stay for the whole course. On thursday morning I was off to Geneva, to meet with Freddy Mallet of Hortis.
Day 1
Professor Lanzarone gave the kick-off of the course. Francesco Cirillo of XP Labs then gave a presentation about what agility means. His message was clear (even though my Italian isn’t very good): agility is about the values and principles, more than the tools and techniques. XP is no silver bullet, but it can look like magic… when done well.
In the afternoon, Frederico Gobbo presented different tools and techniques for drawing ideas and thoughts like free idea maps and mindmapping. He then described how exam scheduling works at the university and described his wishes. This was the start for our first user-story writing session for the exam-scheduling project.
Matteo started the session with a simple exercise: everybody scribbled something on a card, to check that the paper and pens work; everybody tore up their card, to check that cards are cheap and easily discarded. The session didn’t go very smoothly at the start: few people had experience with story writing, we were a large group (15 people) and each story led to lots of discussion. Due to my poor understanding of Italian, I had some trouble understanding the discussion.
We made some changes to the way we worked:
- don’t over-analyze each card. First, write some cards in brainstorming fashion. Afterwards we can analyze and reject or rewrite the cards as needed
- let the customer write the stories, not the whole team, otherwise we get a lot of duplication
- don’t write stories which say “The User does this…”, but write them as “The administrative assistant does this…”, “The professor does that…”, “The student…”. This gives a face to “Il utente”. You can invent “personas” (even whacky ones). Even better is to use actual users. You can do little role-plays: “John does this. Then Mary does that. Then George does this…”
Day 2
Stand up, speak up
At the standup meeting we decided to split the group in two. Half of the team worked with Frederico as their customer and me as coach; the other half worked with Matteo as their customer and Luca as their coach. That worked a lot better. Agile is also about reflecting on your work (“Hansei”) and improving all the time (“Kaizen”).
Let’s Play!
To learn more about stories, the roles of customer and developer, estimating effort, planning releases and velocity, we played the XP Game. Fun was had by all. I wonder what the other people at the Villa thought about all those bursting balloons…
All the teams very quickly went through the first release, mostly because they didn’t ask me (their real customer, as opposed to the proxy customers in each team) any questions. As a result, many of them implemented stories incorrectly. After the release, we reflected on what happened and the teams adjusted their way of working. The next two releases, they asked a lot of questions before starting the implementation and they had fewer problems implementing stories correctly. The players noticed that they could predict the amount of work they could deliver in a release, by using their velocity. In the last release, the teams were able to accomodate a change in plan (a high value story was introduced during implementation), with very little overhead. Estimating the new story and replanning by taking out another story to make room for the new story went very quickly, with very little overhead.
Tell me a story
In the afternoon, Frederico wrote some 15 stories, the team estimated the effort and Frederico assigned priorities (not value).
We evaluated the stories according to the INVEST criteria. Each story should be (as much as possible):
- Independent from the other stories, for easier planning, implementation and testing
- Negotiated and negotiable
- Valuable to the customer and users
- Estimated (and clear end detailed enough to be estimable) by the people who will implement
- Small enough
- Testable
Go read Bill Wake’s excellent article on the subject.
Coaching in a language you barely understand is not easy, but you can go a long way with just a few words, observing body language and tone of voice and observing the interactions between the people. Things went quite well, I didn’t have a lot to do, just some small adjustments and tips now and then. At the end, Frederico verified that the stories covered all the topics from his “Free Idea Map” of the exam application.
Then we hit another snag: the computers at the Villa were hopelessly underpowered to run Eclipse. Again, we adapted: several people volunteered to bring their laptops, hubs, network cables… Tomorrow we can start programming!
Forza Italia!
And then we came to the most important part of the week: the semi finals of the World Cup. Italy vs Germany. Italy won with two last-minute goals. The sleepy, little town of Varese exploded into sound: fireworks, cars racing round and people cheering. The party lasted the whole night. Italy plays the final of the World Cup!
Matteo Vaccari invited me to participate in the “European Summer School on Agile Programming” (ESSAP) in Varese. The school ran for 5 days. Each morning, there were one or two tutorials; each afternoon we applied what we learned on a small project. Frederico Gobbo and Matteo acted as our customers for an application to set appointments for exams at the Università dell’Insubria. Many of the participants are students, so they had lots of ideas for features for the application.
The course was set in the stunning “Villa Toeplitz”, with a fantastic park (see the pictures).
   
|
|
