Extreme Enthusiasm

I write them here so that I’ll have a place to find them again.

(more…)

The Agile Mini-Project is a workshop that I presented with Vieri del Bianco at the Essap summer school.

The workshop is a miniature XP project in half a day. It starts with a brief introduction where we introduce what the exercise is about, then we split the audience in teams of no more than 6 people. Each team is then mentored by a coach.

The planning phase of the exercise is to extract user stories from the vague handout that the participants were given. The idea is to identify stories that are small enough to be coded in very little time. The coach, acting as a customer, identifies which story or stories he wants built.

After planning comes design, when we ask the participants to identify classes (in the object-oriented sense) and their responsibilities. The point is not to obtain a complete design, but to think about the problem.

After the design comes coding: we split participants in pairs. Each pair works on the same stories. This is sometimes called “swarm programming”: by having more pairs solving the same problem in parallel, we get to choose the best solution. It makes sense in the class environment, where it avoids the overhead of integration; but it makes sense in production as well, expecially when the story is difficult and will lay the foundation for much later work. It pays to choose the best design among a few, rather than sticking with the only one that a lone pair of programmer could come up with.

The last part of the exercise is a retrospective. One pair from each team shows their work to the whole class, and we discuss different solutions.

The materials for the exercise are:

• Presentation
• Handout
• Eclipse project

In retrospective, I think that half a day is too short for this project. Three-quarters of a day would be better. The purpose of the workshop is to tie together many themes, such as user stories, planning, test-driven development, design and acceptance testing. I think it works better with participants who have some knowledge of these topics.

The 3rd edition of the Essap summer school is finished. I’m finally home, feeling exhausted and happy.

It’s been a week full of learning, teaching, talking, heat, sweat and rain. For the first time the organizers of the school (myself, Federico and Vieri) decided to sleep in the same hotel as most of the participants rather than commute from home. Given that I no longer have the stamina it seems I had in 2006, it was a good choice. It was good to have a bit of respite in the evenings. Although most evenings I had some work as well.

Expecially on Wednesday night, me and Vieri still had not all of the material for Thursday morning’s event, the Agile Mini-Project. As soon as we were back from the school, at around 19 in the hotel, I showed Vieri the material I had prepared for the workshop. It was changed a lot from what we had thought before. I was not confident at all that it would work. We were tired, and there was not much we could add to it. I suppose this was for the best; it turned out we had the right amount of material (slides, exercise text, example code) that we could use for a half-day workshop.

We discussed the material for a while, then at 20:30 we set out to go to the restaurant. We had to: this was the restaurant that Vieri chose for the social dinner. We had an important appointment with the owner, to discuss the menu. A most pleasant task, I should say. :o)

Late at night, around midnight, I gave some polish to the material and went to bed.

Genesis of this mini-project

This workshop was organized by Vieri del Bianco and me.

The Agile Mini-Project workshop was tried out in two evenings at the Milano XPUG. The first evening I gave a task of “write a Basic interpreter”. I gave participants a list of user stories, carefully crafted so to be small and incremental, and no code to start with. I was not happy with the results; most participants wrote monolithic code with little design and little functionality. I expected participants to create a Parser class, and Interpreter class and maybe Expression and Statement classes. What I got instead was a bunch of monolithic code. Clearly these developers were not familiar with parsing theory, because they tried to avoid parsing as long as they could.

The participants followed the TDD rules, with poor results. I learned that TDD does not necessarily result in good code nor much functionality. As Simone Genini remarked today at Essap, Agile coding works well when the developers know a lot about analysis and design. You need to be strong in the fundamentals: in addition to analysis and design, you must know about algorithms and data structures.

So I learned that I should ask participants to do a little planning session, and a little design session before starting coding.

The second evening of Agile-miniproject tryout at the Milano XPUG Vieri was present. While I was scared to really try a true Agile miniproject, and I was trying to change it to an “advanced TDD” session, Vieri insisted that we really do a mini-project. I’m so glad that he did.

We had agreed to split the 18 participants in three six-people teams. We discussed a bit about the difficulty of introducing a Subversion server for each team. In my experience, small mishaps with these tools can result in an hour wasted. That would be a disaster for a half-day workshop. Besides, having three pairs work on the same codebase would introduce a bunch of additional problems, such as resolving conflicts, organizing work among pairs, and so on. The real risk would be that all the time were spent on the these activities, that are really not much fun compared to coding.

So we decided to avoid Subversion, and have all pairs work in parallel on the same story, starting from a copy of the same project. No integration problems. It was a good decision, because it turned out that many Essap participants had difficulty enough following the TDD rules; learning how to integrate at the same time would have been too much.

That evening we tried a different format; we didn’t give many rules to follow besides TDD. I gave them a small user story in the Basic Interpreter domain, and gave them a simple version of the interpreter, with a couple of stories’ worth of functionality in it.

It didn’t work very well that way either. My Basic Interpreter starting code was nice and clean enough, but it was a bit complex. It could interpret programs such as

10 INPUT A
20 INPUT B
30 PRINT A * B

The code was reasonably nice, with small classes each with a simple responsibilty. Some XPUG participants said that they liked reading through the code, although they added very little functionality! Still, no parsing knowledge is still no parsing knowledge. The domain would lead to complex problems, such as how to parse a recursive structure like “A * (B + C)”.

I still liked the idea of having a simple “text in, text out” user interface, that interacts with a rich domain model. I wanted to get down to the heart of this example, and I found inspiration in the example that Dave Nicolette uses in his TDD sessions; a simple “fighting game” with characters that have weapons and can receive damage.

I liked a lot that example, because there are very little algorithmic complexities, but you can reason a lot about how to assign responsibilities to classes; in this, it’s similar to most programming problems. I didn’t like the “fighting game” setting, which sounds a bit too violent. I do like fighting games and I played a lot of them, but the feeling I have when I think of Agility is not like fighting; it sounded the wrong tone. So I turned to one of my other favorite things, text adventures; I changed the domain to an extremely simplified text adventure, kind of like the games by Scott Adams or Brian Moriarty of the ’80s. i wrote a simple transcript of the interaction with this imagined game. Implementing this would have been more than enough work for a half a day. “Work for 12 days”, said Marc Evers when he read it. I’ll post the details of the exercise some other day.

I provided the very minimum skeleton code for this exercise. I’m very pleased with how the exercise turned out. In todays’ retrospective, many Essap participants said that they appreciated a lot that the mini-project tied together some threads that were discussed all along in the previous three days: user stories, planning and TDD. Although I did most of the work of writing the exercise materials, it was Vieri that made us stay on the right track of doing a true mini-project (rather than just more TDD). It wouldn’t have been nearly as good without him. Also Vieri and Fabio did a very good job of coaching their teams.

Thanks

What else to say? It’s been an incredible week, and it was the generosity of many contributors that made it possible. Elio Lanzarone, who first had faith in our ability to pull off something like Essap (Elio is a great coach. We have lots to learn from him.) The guest workshop organizers: Yves Hanoulle, Els Ryssen, Marc Evers, Willem van den Ende, Fabio Bertone, Jacopo Franzoi, Tommaso Torti, Stefano Fornari, Simone Genini, Luca Grulla. Many of them came from abroad, all of them posponed important other business to be with us. A first-edition Essap-friend who came to visit us: Alejandro Barrionuevo. My friend Carlo Bellettini, who came to help us today and is a software engineering professor who “gets” Agility. My employer SourceSense who let me steal Jacopo and Tommaso for one day, and our customer Eugenio S. for the same reason. The Ninja technical staff, so called because of their ability to have everything perfectly sorted out while you were not looking for a second: Andrea Gervasini, Domenico Marini and Massimiliano Pepe. I’m so pleased that this year the ninjas prepared workshops in addition to fixing the infrastructure. The many Milano XPUG members who helped playtest the mini-project. And the other school organizers, Vieri del Bianco and Federico Gobbo. Thank you all!

Update: and of course thanks to Simone Gentilini as well for participating to the “Agile loops” presentation and being with us in the first days of the school.