XP Days BE 2008: program out!

This year my PhD dissertation takes my strenght... I won't be there at XP Days BE. But if you are interested in the agile thing, it is a good place to be. Check it out!

The ideal world of software mind mapping

Given that pen-and-paper mind mapping is a useful and effective idea in most cases, I want to share with you the vision of Eric Blue about the ideal world of software mind maps:

# There exists a standard mindmap format (Simple MindMap Notation?) that isn't tied to one particular product.

# This new format can be easily authored on multiple platforms (web, windows, linux, mac, and handheld devices), and can also be quickly created by average humans.

# Users can easily share their mindmaps with others, collaborate in real-time, and not be tied to a particular product (desktop or web-based).

# Users can host mindmaps themselves, and choose from a number of innovative mindmap presentation libraries that will allow them to embed their map in their website, blog, or intranet portal.

# Users can easily link their mindmaps together in a distributed fashion (no need for a central hosting provider). World-wide mind maps can grow organically, benefit from advances in the social and semantic web, and allow users to visually link, search, and share.

"Innovation is key: competition is a *good thing*, and users reap the creative benefits"

Agile Loops at ESSAP

I forgot to publish... sorry guys, here there is our contribution!

A lovely ESSAP this year...

ESSAP just finished, and I'm proud of the results, being a local co-organizer, with Matteo, Vieri and the guys of Agilmente. This year we hadn't the facilities of 2007, as XP2007 occurred in Como, and I was in trouble of having participants from Europe. Well, this year we had more than in 2007! And the atmosphere creted was lovely, also because me and Matteo decided not to come back home every night but to sleep at De Filippi, where most participants were (so, I could finally have the occasion to play Lupus In Tabula, finally). A lot of interesting persons came to bring their agile eXperiences, and everyone was happy with it: both PhD and graduate students and professionals, whatever high their knowledge in Agile was.

And, for the guys who love Enterprise 2.0 success stories, we organized all with two wikis: the first is private, and shared among the organizers, and the other is public, being the school web site. no more wasting time in mailing lists! Wikis rock, and they are an agile tool too!

Mapping and agile

A lot of people here at ESSAP asks me about mapping and agile; I've opened a small review in the wiki of my favourite books that I republish here:

Tony Buzan is the inventor of mind mapping, the most powerful brainstorming technique for individuals I've ever seen. He has published a lot of books, and this is my favourite: simple and easy, you will start mind mapping after 10 minutes. After some practicing, you can turn yourself to dialogue mapping, a technique invented by Jeff Conklin. Dialogue mapping is more focused on team brainstorming. If I'm allowed to use it, redudancy in discussion is drastically reduced and meetings lasts less time with more achieved results.

Another Pomodoro expert in Sweden

The Pomodoro Technique was invented by Francesco Cirillo, who is one of the first XPer in Italy, if not the first one in absolute, but since then the PT is spreading around the world. A clever guy has just written to me, and he has a very interesting post about the PT and pair programming. He has interesting observations about breaks. Check it out!

P.S.
OT: Download Firefox 3.0 today to achieve the Guiness Record!

Pomodori at Limerick

| View | Upload your own

Learning agile techniques playing

I've just taken part to a very informative workshop lead by David Parson about choosing the right technique at the right time in your team. The main goal is to build a Human Powered Machine on A4 trasparent paper sheet, on which you draw upon as slices with colored pens as the technology. In the team, there is the stakeholder, who prioritizes user stories (already written, as in the XP game, with their own business values), the developers, and a tracker/scribe (of course, it's me). Moreover, a QA person who decides if the stories pass, i.e. he performs acceptance tests, will act for every team involved. There were two teams, with 4 developers and 1 stakeholder. The game lasts three iterations, 20 minutes each (more or less a pomodoro...): 5 minutes planning, 10 developing, 5 testing on the integration table. The interesting part is that you have a plateau of techniques you are (not) allowed to use. For example, if you do not choose continuous integration, you can't use the previous slices.

In my team, Peter Bell took the role of the leader at once, so that the other developers initially were shy to propose their ideas, and also pushed our stakeholder, Noura. But it was Thomas that posed the key question: "what kind of vehicle?" and the common decision was: a kind of a bike. On the contrary, Philippe was the first to start actually developing, with a lot of details, unlike the others (each should develop alone in the first iteration). The integration phase on the table was quite good, and Peter had the idea to write on the stories what each should develop. Great idea: Philippe and Peter refactored their own work, Karl choosed another user story why Thomas started again and designed an improved version 2 of his slice. Now the QA person should evaluate the demo, and everything got ok, save two stories about a luggage feature and a mirror.

Iteration two: regression testing was chosen by our team, while the other choosed continous integration. New stories A pair in each table was now allowed. Thomas and Karl exchanged a lot of ideas, while Peter and Philippe talked with the stakeholder, Noura. The QA got well! Fantastic! The team was excited and, during iteration three, they never losed the focus, i.e. to design a human-powered vehicle, unlike the other team. So they discarded absurd stories like flying. What stucked me is Philippe, who made a spike who proved to be effective, even if developers were allowed to work together for the final integration. We won the game! In any case, it was funny and informative. David told us that the materials will be available on his web page.

My eXperience with the Poppendiecks: eliminating waste

I took part in a workshop lead by Mary and Tom Poppendieck and it was quite an eXperience. I realised that in my activity of agile facilitator I never focused on the goal of eliminating waste. What's waste? Everything that it's not value from the point of view of the customer. Ask yourself, how much of your code base is useful, i.e. actually used by your customer? What is not used is junk, and its complexity is an exponential cost. This is the first source of waste in software development.

The second source is handsoffs, and it is a big one. Every time you separate:
- responsability (what to do);
- knowledge (how to do);
- action (doing it!);
- feedback (learning from results)
...you are in a handsoff state. I think in that sense the Pomodoro Technique is really a marvellous tool to reveal handsoffs.

The third source of waste is task switching: some people pass more time in juggling eggs in switching than in actually doing their task!

The fourth source is delays. Where you find queues you will have delays, and the only answer you can give is stop accepting more than you can handle (put it differently: reduce input flow to the level of output flow or increase output flow; if you can't eliminate at all, put in a "never list").
Other situations. When you should turn again to your supervisor it is delay. Another example is merging time: please, do continuous integration instead! To discover delays, ask yourself this kind of questions: how long do you go alive? how much time from decision to release (this reminds me of the kanban practice, where you have to be start, on progress, completed, delivered area so to organize your product backlog).

When asked what about testing and waste, Mary answered that the structure you should test any continous integration cycle (3 min.), your content should be test every day, and the layout/UI every release candidate (RC) -- this is on the delivered software at the end of each sprint. It is interesting the distinction between RC, i.e. after each 2-week sprint, while a full release is in the mind of the customer, typically every 3 months, when you've got the money (at least outside Italy; bt this is another - sad - story). The only tests not to be performed (only) automatically are in the layout layer. But this topic is out of the Poppendieck's workshop. I will coever UCD (User Centered Design) and interactive design and agile in another post later. Stay tuned!

eXtreme Limericks at Limerick...

Open space sessions are one of the best tradition I find in XP and Agile conferences, and I've just catched one of them really worth blogging.

The problem: how can non-programmers have an experience of pairing? Martin Heider, a German agilist here at XP2008, had a clever idea about this: eXtreme Poetry. And of course, we are at Limerick, so we will write... limericks. A limerick is a typical English poetry form, easy enough to learn in minutes and well structured. The metaphor is that coding is much like writing poetry. For instance, limericks should "compile", i.e. the rhyming structure should be respected, and also the rhythm, and after compiling you can perform refactoring as well.

The idea is to write limericks in pairs about agile themes. There is a 5 min. long time-box for the pair as a "coding" iteration, with a third person acting as an observer. After the iteration is finished, a small retrospective begins, about what occurred. It happens that at first time we were the only two people in the open space, so me and Martin tried to write a limerick about pair programming:

I know a programmer searching for pair
running through all rooms looking everywhere
   nearly giving up
   after his stand up
doesn't understand why they don't care.

The interesting part is that me and Martin constantly switch our roles of driver and navigator: I put the scenario (someone looking for a pair), Martin wrote down the word 'pair' and the first and second lines arrived fluently. The fourth line was proposed by Martin and I completed with the fifth one, then Martin posed the word 'care' and I completed the limerick. Five minutes done. We didn't retain our ideas in our mind, we directly put on the whiteboard, so that your pair should not wonder what eggs are you juggling in your head. Our small retrospective put the problem of exerpertise in the exercise: what if an English speaker comes (like a senior programmer in a programming pair)? And lucky we, Charlie Poole came in. After a small explanation of the eXtreme Poetry mechanisms and goals, Charlie paired with me and he started thinking alone. After a minute, he produced what follows in seconds:

I do not want to write a test
'cause coding is what I do best
   and if it's wrong
   it won't be long

..and I had only the time to write it down! In any case, I found the last line, that rhymed with 'pest' (a synonym of bug) as uneasy to understand, and Charlie agreed. Then Martin said something like: "you need to fill the rest" and the last line came directly thereafter:

I do not want to write a test
'cause coding is what I do best
   and if it's wrong
   it won't be long
'til someone else completes the rest

The retrospective showed that Charlie is not used to work in pairs for creative tasks, and also write an essay with an other person is not easy for him. The reflection is that people who don't like programming in pair conseder coding as a creative activity, essantialy an art, as poetry, and consequently they want to be recognized as the unique authors of their creations. Charlie explained to us the differences between syllabic languages like Italian or German and English in regards of the rythm (wow!). Then Martin underlined the fact that an English native is really a senior in limericking compared with a non-native! So pairing is difficult in such a question. The third pair was made by Martin and Charlie. They started from the word 'agile' and spend 3 minutes to find how to have rhymes: 'fragile '(ok), 'for long while' (more or less)... After my pomodoro ringed, this was written on the whiteboard:

A company wants to be agile
but they did it their very own style

As an observer, I noticed that they got blocked by a too difficult word, they should at once find another start point so to complete the iteration in time. Did you ever had such an experience in pair programming?!? In any case, Martin completed it in extra time:

A company wants to be agile
but they did it their very own style
   commanding from the top
   it was really a great flop
I have think about that for a while

I proposed to have 5 minutes for refactoring, at at the end there became 25 minutes (a full pomodoro!). This was the second version:

A word coming down from the top
is that agile must not be a flop
   always commanding the peers
   that will lead to many cheers
writing tests that won't pass without any stop

This version was unsatisfactory for everybody (note the shift of the lines on top, as you are used to do in code refactoring!). And the test was red bar: it doesn't rhyme, i.e. it doesn't "compile". I entered the arena so all together we refactored the limerick obtaining what follows:

The rod coming down from the top
is that agile must not be a flop
   so we work every day
   in the "agilist" way
writing tests that won't pass without stop

This was the end of the session, really, really informative. Some questions arised: what happens with a pair of two English natives? Waht if we use a rhyming dictionary, i.e. having a supporting "IDE" for poetry? The answers in the next eXtreme Poetry sessions!

ESSAP 2008 da Varese con furore

Anche quest'anno abbiamo fatto partire la ESSAP, la scuola estiva di agilità del mio Dipartimento. Qualcuno mi scrive che il fatto di non scorporare nella quota di iscrizione il vitto e alloggio dalla scuola stessa penalizza i varesotti che volessero partecipare. Be', è vero solo in parte. Intanto, chi è di Varese è comunque avvantaggiato perché non ha il costo del viaggio. Inoltre, c'è da considerare che, per come è strutturata Varese topograficamente, non essere tutti nello stesso posto anche di sera è un grave handicap: si perdono quelle opportunità di socializzazione tra i partecipanti che a volte insegnano più che il programma ufficiale... Per questo motivo abbiamo voluto che tutti quanti, organizzatori compresi, alloggiassero insieme. Alla fine, ci si guadagna tutti. Veramente.

Quasi quasi vorrei essere all'estero per votare...

Il mio amico Dario Taraborelli, ricercatore italiano all'estero, mi segnala con un certo divertimento la diversità di prospettive di un paio di candidati per le prossime elezioni. Da un lato troviamo Andrea Verde, cristianissimo e italianissimo ex-pornoimprenditore (indovinate per quale partito/polo?), dall'altro Beatrice Biagini, laica, giovane, mobile, che parla di lotta alla mafia come di rilancio della ricerca scientifica in Italia.

Mi trovo alle pendici del Monte Bianco, domani sarò nella Francia più profonda (Autun, nel Morvan). Dalla mia prospettiva le cose non sembrano così nette... Non so chi votare. O meglio, so che non posso votare evidenti vassalli del Vaticano e buffoni di corte, e per me alcuni sono chiaramente tali, non cercano nemmeno di nasconderlo (probabilmente non hanno neuroni a sufficienza per cogitare cotanti pensieri). Però anche nel Partito Democratico non c'è chiarezza. Dove sono i fondamentali fondamenti laici? Qualcuno me li deve dimostrare! No, per tenere su tutti si è accarrozzati anime filoclericali innominabili... E vedi anche i difficili rapporti del PD con i radicali, adesso (forse) risolti.

Certo che, da dottorando italiano in informatica, approvo quanto dice la Bea Biagini su ricerca e università, come non potrei?.

Comunque qualcosa qui qualcuno si cerca di farla. Io, per esempio, grazie alla fiducia datami dal mio direttore di Dipartimento, ho lanciato, con un collega più esperto di me, una scuola estiva d'eccellenza, europea, in inglese, con docenti invitati riconosciuti dalla comunità internazionale. Voglio dire, qualcosa si riesce ancora a fare. Se ci credi.

Il modello collaborativo dell'open source per lo sviluppo software

Nell'ambito del programma di eventi del Cantiere dei Mestieri ICT, si è tenuto martedì 26 Febbraio in via Santa Marta 18 a Milano un convegno inerente il tema “Iniziative e prospettive per l’Open Source nelle Aziende e nella Pubblica Amministrazione". Trasmetto qui il mio contributo come relatore.

Per i tech-manica: la mia prima volta di lucidi fatti interamente con Google Docs. Per un certo tipo di informazioni, ricche di foto, può esser più agile della coppia LaTeX/Beamer...

Un pied a terre a Torino...

Lunedì scorso sono stato a Torino e ho scoperto, grazie al mio amico Fabrizio, un bellissimo Bed & Breakfast dall'atmosfera famigliare. Il signor Gino Nicosia vi accoglierà benissimo, e se siete fortunati avrete anche la vista sulla Mole...

Writing user stories... a retrospective of the workshop in Bologna

Caveat: this post is a spoiler of the writing user stories role game I've played in Bologna. Credits: it is mainly based on the Agile Requirement Exploration session in XP Days BE 2007 by Dave & Brett, but it was modified by me in structure. So, enough for the introduction.

Let's say you have 25 people sitting 5 per table. Each one is a team. The goal of the game is to practice user stories in a controlled context, so to highlight improvements for participants, and in particolar to understand: who is responsible, who feels responsible; how much our presumtions on the domain influence our design. I started with a brief pantomime about the risk of silver bullets, then I collocate with the poster user stories for people who aren't used to write them. Each team has people who don't know each other at best, or at least don't work each day one with the others. It is important that at each table there is at least one person who actually wrote user stories -- or he or she think so.
I didn't explain the standard "syntax" of user stories (the mantra as-a-role-I-want) and I soon realized that it would be better to do it. Next time.

Then, the first pomodoro starts: each team is given a paper sheet with a 5-line specifications, sufficiently unclear, from the customer. "This is what I want. Do it." The topic is a web site that seems to be an iTunes clone, but it isn't. Each team can call me or Fabio (playing the the customer's role) for explanation, but we can't be in different tables at the same time. Ergo: customer time is precious, don't waste it. In the second pomodoro I lead a small retrospective in form of a dialogue mapping (see my PhD minor dissertation about this particular technique) with the following key questions: which difficulties? how much the customer (not) on site influence? Fact: requirements should always be elicited from the customer in any case.

In the third pomodoro some new rules come. Ok, you need customer on site. We take randomly one person per table being the customer proxy and Fabio conducted them out of the room. In the room, I told each team that inside trading comes: swich your cards between the tables! This is an innovation I thought, so people can (a) rewrite stories by heart (usually the result is better than before) and (b) see how others work. In the meantime, Fabio give an extra paper sheet to the proxy with the detailed list of features based on the 5-lined requirements. Furthermore, each customer proxy must choose a cognitive style (other innovation), as NPL defined: V for Visual, A for Auditive and K for Kinestesic. That means that the proxy plays a role and he or she understands "only" the questions put in the correct cognitive style by the team. For example, a Visual proxy wants to have sketch of the GUI, while a Kinestesic one wants pantomimes.

After a while, proxies come in again, but they sit in a different table... Additional rule: only the proxies can ask for help to me or Fabio as the customers.

The final pomodoro is a general retrospective starting from the counting of features found by each team. It is worth noticing that there is no correlation between teamresults and the cognitive styles... A constructive critique was to add an other pomodoro for teams, so that cards can be prioritized. That sould be fine: even if the workshop lasted more than 2 hours, people was so enthusiastic they missed the coffee break as they chosed so. Incredible, isn't it?

Retrospettivando Bologna: l'importanza delle card...

È stato pubblicato il materiale presentato all'Agile Day a Bologna, tra cui anche il mio poster mostrato al workshop condotto con l'aiuto del prode Fabio Beta. Vorrei focalizzarmi sulle carte per scrivere le storie.

Tim Mackinnon, l'invited speaker, ha descritto in poche slide (video)la teconologia delle carte come segnaposto di conversazioni più ampie, non una raccolta di specifiche! Ho trovato infatti, nel corso del laboratorio -- o workshop che dir si voglia -- che ho lanciato che questo concetto, che sembra molto chiaro, è difficile da mettere in pratica. Inoltre, la struttura standard delle storie:

[chi] Come (ruolo) [cosa] voglio (requisito) cosicché [perché]] (valore di business con le lenti del ruolo)

non è così semplice da padroneggiare come pensavo, anche da chi è uso a scrivere le carte.

Un altro aspetto importante che ha mostrato Tim è come tradurre i bachi, cioè i test d'accettazione non passati, in storie a sé, con il procedimento del ribaltamento del contrario in qualcosa di positivo. Anche l'aggiunta del pezzo "piuttosto che..." che evidenzia cosa evitare credo che lo adotterò, mi sembra molto chiaro e utile.

Totalmente nuovo, per me, inoltre, il concetto di gold cards. L'idea di motivare i singoli membri del team di sviluppatori, abituati a lavorare a coppie, su un processo di innovazione lungo l'iterazione mensile, mi sembra veramente molto, molto buona.

Anche per gestire le retrospettive il team di Tim ha un'innovazione interessante: per aiutare tutti a sentirsi sicuri ci si passa un gettone costituito da quattro carte con le domande fondamentali. Ovviamente, per non aumentare lo stress, uno può sempre dire 'passo'.

Insomma, con le carte si possono fare molte cose interessanti, non solo l'XP game... E the Next Big Thing?!?

Secondo Tim si chiama kanban di David J. Anderson. Si trattadi un modo per gestire i cambi di requisiti (interessante, eh?). Ve ne parlerò se e quando avrò una seppur piccola esperienza pratica in merito.

Shemflection from Belgium: games work!

A bit later shemflection about my XP Day BE experience. In the open space tables for the participants, where people let there their own books in vision for others (this is shared knowledge, guys!) there was a space for games, where I added my own copy of Lupus In Tabula, already mentioned in this blog.

But the best thing I discovered is Fluxx, thanks to Bernard Van Der Beken, who offered me an instant game. It is very funny, andit is very agile: in fact it is a simulation of what does requirement changing mean. Other games I want to check out are Game of 33, Chrononauts and Zendo.

Hoping they will also come in Italian and Esperanto as well...

This is not agile...

...even if some people believe so.

Raccontare storie (d'uso) non è mica facile

Sono tornato da Bologna dove ho partecipato all'Italian Agile Day, su invito di Marco Abis, l'organizzazione, e di altri agilisti italiani. Ho riproposto, un po' modificato, il workshop/laboratorio seguito all'XP DAys Belgium 2007, con il graditissimo supporto all'ultimo minuti del mio amico (agilista) Fabio.

I posti previsti erano 25, e circa una decina si sono presentate sperando che qualche sedia si liberasse. Così non è stato. Anzi, dopo 4 pomodori belli intensi, due di ritrospettive, due di simulazione, e davanti alla prospettiva di una pausa caffè, i partecipanti erano ancora cosiì coinvolti che non si sono alzati dalle sedie per altri dieci minuti!

Detto tutto questo, credo sia stato un grande successo: nella comunità agile italiana si vede che c'è voglia di avere sessioni più interattive. Ottimo segno.

The Pomodoro Technique: Commercial #1

Performers: Bernard Vander Beken & Yves Hanoulle at the XP Days Benelux 2007, Mechelen (BE).