Finalmente, Laureato!!!

Dopo 5 lunghi anni di studi, di tempi ritagliati fra famiglia e lavoro, sono finalmente riuscito a concludere il Triennio di Canto al Conservatorio Cherubini di Firenze e mi sono laureato, il 20 giugno 2014, con un bel concerto presso Villa Favard a Firenze.

Programma del Concerto

  • G. F. Händel (1685 – 1759) “Comfort ye… Every valley…” (da “The Messiah”, 1741)
  • R. Schumann (1810 – 1856) (da “Dichterliebe” op. 48, 1840) “Im wunderschönen Monat Mai”, “Aus meinen Tränen sprießen”, “Die Rose, die Lilie, die Taube, die Sonne”, “Wenn ich in deine Augen seh”, “Ich will meine Seele tauchen”, “Im Rhein, im heiligen Strome”, “Ich grolle nicht”
  • G. Verdi (1813 – 1901) “Lunge da lei… De’ miei bollenti spiriti” (da “La traviata”, 1853)
  • H. Duparc (1848 – 1933) “Phidylé” (1872), “Chanson Triste” (1868)
  • I. Stravinskij (1882 – 1971) “Here I stand” (da “The Rake’s Progress”, 1951)
  • P. I. Tchaikovsky (1840 – 1893) “Kuda, kuda” (da “Eugene Onegin”, 1879)
  • G. Puccini (1858 – 1924) “In un coupé?… O, Mimì tu più non torni…” (da “La bohème”, 1896)

Costruisci, misura, impara

Sto leggendo il libro “The Lean Startup” di Eric Ries. E’ un libro incredibilmente interessante da moltissimi punti di vista ma quello che preferisco è il concetto guida, che può esser fatto proprio sia da una Startup, sia da un’azienda che comunque vuol condurre il proprio business applicando i principi Lean del Product Developement.

In poche parole il concetto è: tutti falliamo, soprattutto le Startup. Il fattore discriminante non è banalmente quello fra le aziende di successo e quelle che falliscono (troppo facile), bensì fra quelle che imparano dai propri errori e quelle che non lo fanno. E per raffinare ancora di più il concetto, dividiamo ulteriormente chi impara in quelli che imparano rapidamente e quelli che imparano lentamente. In pratica un principio base è che l’azienda deve imparare il prima possibile la lezione per evitare di sprecare risorse di sviluppo su qualcosa che non avrà successo. La lezione può arrivare da un fallimento, ma anche da un parziale successo.

Come si fa? Le tre parole Costruisci, Misura, Impara aiutano a memorizzare il concetto. Abbiamo detto che lo scopo principale è imparare la lezione, al fine di avere conferma se il lavoro che si sta facendo è sulla strada giusta o sbagliata. Ed abbiamo anche detto che dobbiamo imparare al più presto. Quindi che fare?

Alcuni step schematizzati:

  • Costruisci un prototipo funzionante e distribuibile della feature che vuoi rilasciare ai clienti. Deve essere il famoso MVP (minimum viable product) che sta sul mercato, che ha una dignita, ma che contiene tutte quelle feature non strettamente necessarie ad “imparare” quello che si vuol verificare. L’MVP deve essere funzionale a confermale le “assunzioni” che l’imprenditore si fa quando lancia un nuovo prodotto.
  • Misura: prima di rilasciarlo ai clienti assicurati di poter “misurare” l’impatto sui clienti e di poter verificare numericamente le assunzioni che ti hanno portato alla costruzione dell’MVP. Questo passo è il più difficile perché normalmente non si è abituati a considerarlo. Non si parla di guardare se il mese prossimo avremo più nuovi clienti, bensì di capire se quella feature è stata utilizzata, se quei clienti che l’hanno usata l’hanno trovata utile e la promuoverebbero, se le assunzioni fatte sono o meno confermate.
  • Impara: analizza i dati e controlla se il prodotto sta avendo successo, se la feature è quella che i clienti aspettavano o meno, se le idee di impatto che ti eri fatto sono confermate, superate o non avverate.
  • Ripeti i punti precedenti per ogni feature

La cosa che mi ha sbalordito è che ad esempio un team di sviluppo che applicava questa tecnica aveva iniziato a lavorare soltanto su attività che potevano essere verificate e il cui ritorno poteva essere misurato. Tutte le altre attività non misurabili erano troppo rischiose e quindi, a meno che non fossero strategiche, non venivano sviluppate. Avevano addirittura messo una colonna “Verified” dopo la colonna DONE della Kanban Board (con tanto di WIP limit), che stava a significare che un’attività era fatta, consegnata ai clienti e testata.

Chiaramente tutto questo che vi scrivo è molto abbreviato e conciso. Vi consiglio vivamente di andare a visitare il sito relativo al movimento http://theleanstartup.com/ e a leggere il libro “The Lean Startup” (c’è anche in italiano con un’improbabile traduzione del titolo “Partire Leggeri”).

Kanban nel week-end

E’ da diverso tempo che cerco di organizzare le mille attività che si concentrano nel fine settimana con Kanban. Chiaramente non si parla di Kanban nel vero senso della parola: non ho attività di grandezza identica e non mi metto a confrantare il cycle time, altrimenti rischierei il divorzio 🙂 Ma i principi base del DONE e del WIP limit sono drammaticamente utili ed efficaci.

Gli step sono semplici:

  • fai una bella lista delle attività che devi fare
  • dai loro un ordine ideale di priorità
  • metti il wip limit a 1
  • inizia a lavorare la prima…
  • …e così via fin dove arrivi

Alcuni punti di attenzione/suggerimenti:

  • WIP limit: ad un certo punto sentirai un’irrefrenabile voglia di iniziare un’altra attività anche se la prima non è finita; e tutto questo per mille scuse che darai a te stesso. Non lo fare.
  • per facilitare il punto sopra, cerca di cambiare le priorità in funzione del tempo che hai per farle (es.: non iniziare alle 12 un’attività da 3 ore perché il pranzo te la interromperà)
  • TEST: assicurati che quello che hai fatto funzioni (es.: prova ad innaffiare le piante se hai montato l’impianto di irrigazione automatica, o prova a riavviare il PC se hai fatto degli aggiornamenti importanti)
  • DONE: non smettere di fare l’attività finché non è davvero DONE. E questo concetto a casa (come ovunque) include che tutto sia a posto, che il cacciavite sia di nuovo fra gli attrezzi e che il gesso in terra dopo il buco che hai fatto con il trapano sia pulito
  • Un po’ di pianificazione: questa non è tanto Kanban-oriented, ma l’ho trovata utile. Avere un’idea generica di quali attività staranno nel sabato mattina, nel pomeriggio, nella mattina di domenica e nel pomeriggio di domenica, può aiutare.

Chiaramente fare Kanban nel weekend è il primo passo verso la pazzia.

Scrum e supporto

E’ normale che un team che sviluppa abbia mediamente 2 esigenze da conciliare:

  • quella di sviluppare un prodotto con nuove funzionalità
  • quella di supportare i clienti

Come si può conciliare lo Scrum (che prevede iterazioni time-boxed di 2-4 settimane, con Sprint intoccabili e protetti) con il supporto che solitamente è composta da flussi di attività destrutturati e la cui priorità e dimensione può cambiare?

Condivido la mia esperienza.

In alcuni team mi è capitato di adottare la soluzione “fixed time” per citare “The Scrum Field Guide” di M. Lacey e funziona piuttosto bene. Questa soluzione è praticabile soltanto se il supporto si configura come un rumore di fondo (passatemi il termine) più o meno costante e che non ha particolari sbalzi di impatto sul lavoro del team. In questo modo il team, durante il planning, ha già la coscienza di quanto più o meno sarà il “rumore di fondo” del supporto e può prevedere di lavorare una certa quantità di cose per lo Sprint con un buon livello di sicurezza.

In altri contesti dove invece il supporto è molto variabile, ho trovato utilissimo dividere il team in 2 sottogruppi, un gruppo che fa Scrum (e quindi sviluppa con tutti i sacri crismi di Scrum) e un gruppo che fa supporto utilizzando Kanban, in modalità “fate pure Scrum che vi difendiamo noi”, ovviamente con una rotazione periodica fra le persone che fanno scrum e quelle che fanno Kanban per evitare che i “fire-fighters” si suicidino. Una nota per il gruppo che fa Kanban: al netto di emergenze catastrofiche o altro, il gruppo deve forzarsi a lavorare con un wip limit molto basso, al fine di avere tempi più bassi sulla singola richiesta di supporto ed avere alla lunga (nemmeno troppo) un’idea del cycle time.

In entrambi i casi comunque non si deve contravvenire ai dettami di Scrum e Kanban, per essere sicuri di massimizzare il risultato.

Lo Scrum “a modo mio”

Si sente spesso dire “sì, noi facciamo Scrum, ma abbiamo fatto qualche aggiustamento, per adattarlo alle nostre esigenze”. E’ quello che in letteratura è chiamato “Scrum-But“. E’ bene o male?

La risposta è chiaramente: “dipende”, ma tende al male.

Team molto navigati, che hanno praticato Scrum per diverso tempo (1-2 anni) hanno sicuramente la percezione del valore di ogni singola prescrizione e sono in grado di “aggiustare” Scrum senza snaturarlo. Conoscono le ragioni che stanno dietro il Daily Scrum, dietro una Retrospective e possono ricercarle in molti modi diversi, non necessariamente legati alla cerimonia specifica e un po’ prescrittiva che qualsiasi libro di Scrum suggerisce.

Ma un team alle prime armi, che vuol iniziare ad usare Scrum, non deve per nessun motivo cambiare una virgola del framework. Scrum è stato studiato per funzionare e per avere relativamente pochi vincoli. Toglierne alcuni significa smontare la struttura portante del framework, con un risultato insoddisfacente o comunque minore di quello che si otterrebbe applicandolo in pieno. Non solo: i ruoli di Scrum (Product Owner, Scrum Master, Development Team) hanno alcune responsabilità specifiche e ben circoscritte: seguirle alla lettera significa risparmiare moltissimo tempo in discussioni inutili su chi deve prendere alcune decisioni.

Vi faccio alcuni esempi

Scrum senza il Daily Scrum

Probabilmente il team lavorerà scoordinato per tutto lo sprint, proprio perché non ha occasione di fare Just-in-time planning o di far emergere in maniera collettiva gli impedimenti. Lo Scrum Master non sarà a conoscenza di tutti i problemi e tutto il team rischia di arrivare alla review con pochissime cose fatte semplicemente per mancanza di coordinamento. Portare una user story in Done in maniera coordinata richiede un grande lavoro di focalizzazione da parte di tutto il team, specialmente all’inizio quando il concetto di cross-funzionalità è ancora sconosciuto.

Scrum senza Product Owner

Il team perderà ore a decidere cosa sia meglio per il prodotto, perché chiaramente non è facile mettersi d’accordo sulla strategia in 8 persone. Alla fine sarà più il tempo speso in chiacchiere che quello nello sviluppo. Non solo: quando arriverà il CEO a dire “perché avete scelto questa strategia” nessuno sarà responsabile in maniera diretta.

Scrum senza Scrum Master

Beh, è un po’ come avere una palestra di arti marziali senza l’insegnante 🙂 Il team inizia a fare Scrum by-the-book, trainato da qualcuno più motivato di altri. Se tutto va bene, i primi 2 sprint saranno divertenti, ma poi il team tenderà a tornare a lavorare come prima. La transizione verso Scrum è scomoda e faticosa, perché va a rompere molte abitudini: lo Scrum Master, con la sua capacità di servant leader e di facilitatore, ha il compito, ogni giorno, ogni meeting, di riportare il team sulla giusta strada

Scrum senza Review

Il team tenderà a fare cose “non-done” perché tanto non c’è bisogno di mostrarle a nessuno. Conseguentemente, quando il Product Owner chiederà di fare una Release, il team avrà ancora moltissimo lavoro da fare per portare a Done le cose lasciate a mezzo. Preparare una review “forza” il team ad assicurarsi della bontà del lavoro fatto. Qualcuno addirittura, all’interno dello Sprint, fa una pre-review il giorno prima, intorno ad un tavolo con tutto il team.

Scrum con Sprint di 2 mesi

Questa è una delle cose che succede più spesso. Si crede che Sprint più lunghi riescano ad ammortizzare meglio il tempo “sprecato” nelle cerimonie di Planning e di Review, oppure che ci sia bisogno di 2 mesi per portare un lavoro tangibile in Review. Niente di più sbagliato. Il team deve sforzarsi di riuscire a costruire qualcosa di “shippable”, di consegnabile e tangibile in 15 giorni, eliminando le cose che non servono. Quante righe di codice sono davvero importanti per user story che stiamo lavorando? Potrei rimandare lo sviluppo di qualcosa al prossimo sprint? Fare bene Scrum significa anche imparare a dividere il lavoro in piccole parti di valore. E questa è una delle cose più difficili di Scrum. Aggiungo anche: Sprint lunghi riducono molto la possibilità di fare “inspect and adapt”. Alla fine di uno sprint ci si può rendere conto di dover dare una sterzata significativa al Release Plan, grazie ai feedback degli stakeholders: più lungo è lo sprint, più tardi daremo questa sterzata, più soldi avremo sprecato.

 

Potrebbero esserci molti altri esempi, ma mi fermo qui.

Chi è lo Scrum Master?

Il ruolo dello Scrum Master (SM) è piuttosto nuovo, soprattutto in Italia. Infatti non è facile trovare persone che nel proprio curriculum abbiamo lavorato in questo ruolo.

Sicuramente non è chiaro, per le aziende che vogliono iniziare ad usare Scrum, chi possa fare lo Scrum Master. Mike Cohn in “Succeeding with Agile” fa alcuni ragionamenti su come alcune figure pre-esistenti, tipo Project Manager, Tech Lead, etc… possano “riciclarsi” come Scrum Master, ma alla fine il risultato è sempre lo stesso: nessuna delle figure attuali ha tutte le caratteristiche necessarie.

Buone descrizioni dello SM sono presente pressoché ovunque in letteratura (ad esempio la “Scrum Guide” di K. Schwaber), ed ognuno ne evidenzia alcune sfaccettature. Scriviamo alcune caratteristiche (davvero solo alcune) e proviamo a descriverle:

  • è colui che si assicura che Scrum sia fatto bene (“Master” dello Scrum)
  • è un “servant” leader
  • facilita la self-organisation
  • stimola il team affinché aumenti la sua produttività

Lo Scrum Master come Coach di Scrum

Sembra scontato, ma non sempre lo è, soprattutto quando, al momento della transizione verso Scrum ci si chiede “Chi può fare lo Scrum Master?”. La prima risposta solitamente è: “Prendo il capo e lo faccio diventare SM”. Errore! Lo SM deve essere una persona appassionata di metodologia e che almeno abbiamo manifestato il desiderio di crescere in quella direzione. Deve essere una persona capace di facilitare l’adozione delle pratiche Scrum, non di imporle. E deve trasmetterne al Team l’importanza e il significato.

Lo Scrum Master come servant leader

Un’altra cosa importante da considerare quando si sceglie uno SM è il tipo di leadership che è solito trasmettere alle persone. Persone autoritarie sono di solito inadatte a questo ruolo. Il concetto di “servant leadership” è allo stesso tempo semplice ma difficile da trovare. Lo SM è facilitatore del team, agevola il lavoro, rimuove gli impedimenti che il team trova durante lo Sprint, parla con le persone e le consiglia sulle scelte difficili. Non impone le sue idee (comprese quelle sullo Scrum) ma fa sì che il team le capisca e le assimili. Sicuramente è una persona autorevole, non autoritaria.

Lo Scrum Master come facilitatore della self-organisation

Questo è uno dei compiti più difficili dello SM. I team sono spesso abituati a ricevere lavori e richieste in modalità “push”, ovvero: “tu mi dici cosa devo fare e io lo faccio”. Tendono spesso a sedersi sul fatto che c’è un capo che prende le decisioni e sono smarriti quando ad un certo punto (ad esempio con l’adozione di Scrum) qualcuno dice loro che le loro responsabilità sono aumentate, che alcuni problemi devono risolverli da soli. Sono spesso abituati ad un rapporto 1 -a-1 con il capo.

Lo Scrum Master deve insegnare al team come vivere come un’unità sociale autonoma. Deve istruirli e guidarli su come si lavora insieme, come organizzarsi per sviluppare le feature che il Product Owner richiede, come affrontare il concetto di cross-funzionalità; e deve far passare il concetto che non c’è qualcuno che risolverà i loro problemi, i loro conflitti: i primi responsabili di come il team lavora saranno loro.

Lo Scrum Master come spinta alla produttività

E’ lo SM che in Scrum spinge il team ad aumentare la sua produttività. Detto così suona strano, soprattutto sapendo che lo stesso SM è anche quello che deve assicurarsi che il team lavori ad un passo sostenibile, senza straordinari, senza pressioni dall’esterno. Il problema è che normalmente si pensa che la produttività di un team dipenda da quante persone ci sono o da quanto lavorano o da quanto “non sono” lavativi.

Cosa fa quindi lo SM per stimolare la produttività, per aumentare la velocity di un team? Moltissime cose. Ne elenchiamo alcune:

  • facilita l’adozione di pratiche tecniche (TDD, pairing, etc…) che aumentano la qualità del codice, riducono il numero di bug e quindi il tempo perso a mettere toppe al codice
  • lavora con il team per ridurre al minimo gli sprechi come lavori lasciati a mezzo o fatti male
  • istruisce il team sul concetto di debito tecnologico e su come vada evitato in qualsiasi modo
  • pone l’attenzione sulla Definition of Done e si assicura che ogni feature la rispetti, facilitando fra l’altro l’adozione delle pratiche di testing
  • spinge il team all’aggiornamento continuo, in modo che si utilizzino soluzioni software “moderne”

 

E’ evidente quindi come lo Scrum Master sia una figura molto diversa dal solito, lontana dal concetto di Capo o Boss, ma anche lontana dal Tech Lead che decide come si fanno le cose, o anche dal semplice Project Manager che in maniera “asettica” tira le fila di un progetto.

Un Daily Stand-up Meeting fatto bene

Il Daily Stand-up Meeting è un incontro rapido di 15 minuti che i team Scrum fanno ogni giorno, solitamente di mattina. L’incontro “da manuale” richiede che ci si incontri davanti alla Scrum Board (tutto il Development team, preferibilmente con Scrum Master e PO) per rispondere personalmente alle 3 domande:

  • cosa ho fatto ieri?
  • cosa faccio oggi?
  • che impedimenti rallentano o bloccano il mio lavoro?

Ultimamente qualcuno aggiunge anche una quarta domanda, suggerita da Mitch Lacey nel libro “The Scrum Field Guide”, ovvero:

  • qual è il mio livello di confidenza sul raggiungimento dello Sprint Goal?

Questa domanda ha lo scopo di far emergere eventuali problemi che le persone tendono a non dire se non forzati. Serve soprattutto a fare esercizio sulla trasparenza e sul team building.

In generale uno Stand-up meeting fatto bene fa la differenza sulla riuscita o meno di uno Sprint. Per questo penso convenga chiarire i ruoli di ognuno dei partecipanti.

Cosa fa il Team Member durante lo Stand-up

Durante il meeting ogni team member risponde alle 3-4 domande, cercando di inserire quello che dice in un contesto di team: non parla dei “suoi” task o delle “sue” storie, bensì dei task sui quali sta lavorando. Oltre a chiarire su cosa sta lavorando e su cosa lavorerà, evidenzia prontamente i problemi che ha incontrato, i suoi impedimenti, i suoi dubbi e le sue perplessità. Se ha bisogno, chiede immediatamente aiuto ad un altro team member: cercare di risolvere da solo un problema è soltanto tempo perso. In Scrum non ci sono sfide personali, bensì sfide del team.

I team member tendono a fare alcuni errori durante lo Stand-up. Vediamone alcuni:

  • usano il meeting per fare discussioni tecniche: il team si deve parlare durante tutta la giornata. Lo Stand-up serve per pianificare la giornata: ogni discussione deve essere annotata dallo Scrum Master e rimandata a dopo.
  • ognuno fa il lavoro che preferisce: le persone tendono a selezionare un lavoro che torna a loro congeniale, a dispetto della priorità richiesta dal PO. Lo Scrum Master deve lavorare perché si termini prima le storie più in alto, poi via via quelle a seguire, facendo appello al concetto di cross-funzionalità, fondamentale in Scrum
  • non arrivano preparati allo Stand-up. Perché il meeting riesca ad essere rapido ed efficace, c’è bisogno che ogni persona si prepari in anticipo sul lavoro che dovrà fare nella giornata, discutendone in anticipo con gli altri team member
  • parlano in maniera superficiale. Ogni team member deve essere chiaro e trasparente per far emergere dubbi e impediment il prima possibile. I dubbi che emergono alla fine dello sprint mettono a serio rischio l’esito dello sprint stesso

 

Cosa fa lo Scrum Master durante lo Stand-up

Lo Scrum Master ha il ruolo fondamentale di assicurarsi che lo Stand-up abbia luogo e che segua le regole dello Scrum. Deve quindi guidare le persone, far percepire loro l’importanza di questo meeting, della sua cerimonia, della puntualità e del timebox, ovvero del rispetto rigido della durata di 15 minuti, e deve lavorare tantissimo per evitare gli errori di cui abbiamo parlato sopra.

Lo SM ha anche il ruolo chiave di “risolutore” di impediment. E’ di solito durante lo Stand-up che le persone tendono a far emergere problemi di ogni tipo che bloccano o rallentano il loro lavoro: lo SM deve prontamente cercare di risolverli, magari non in prima persona, ma deve attivarsi perché siano risolti il prima possibile. Nel caso (non improbabile) che le persone non facciano emergere gli impediment in maniera chiara, è compito dello SM “stanare” il problema, “annusare” l’inghippo e farlo emergere.

Ken Schwaber scrive nella sua “Scrum Guide” che lo SM può anche non partecipare, a patto che si assicuri che lo Stand-up abbia luogo. Questo è vero, ma soltanto con team maturi che sanno portare avanti uno Stand-up meeting in maniera efficace autonomamente.

 

Cosa fa il Product Owner durante lo Stand-up meeting

Molti pensano che il Product Owner non possa/deva partecipare allo Stand-up, quasi fosse un “nemico” o un “infliltrato del business”. Quando il PO è disponibile, ha tutto l’interesse a essere presente, sia per avere informazioni sull’andamento dello Sprint, ma soprattutto per dare supporto al team in caso di dubbi sui lavori in corso. Ovviamente non risponde alle domande cerimoniali, ma è a disposizione del team per eventuali chiarimenti.

Disclaimer

Anche Lean e Agile

Perché no?? Recentemente (da circa un anno e mezzo) sono entrato nel mondo Lean e Agile. Non sto a dire tante cose, dato che c’è un’infinità di materiale su internet.

Lean nasce dall’esperienza di Toyota ed è un processo il cui scopo principale è quello di eliminare gli sprechi. Lo si applica chiaramente ai processi produttivi, ma si può arrivare (se si è particolarmente folli) anche alla vita personale. Personalmente ne ho sperimentata l’efficacia nell’applicazione di Kanban.

Agile condivide i principi Lean e li applica principalmente allo sviluppo software. Nella maggior parte dei casi i grandi progetti software iniziano con delle specifiche e finiscono con tutt’altre, proprio perché le esigenze del cliente cambiano, soprattutto quando il progetto si protrae per molto tempo. Non si sa perché ma magicamente tutti i progetti di sviluppo software finiscono per essere in ritardo e non consegnare mai quello che il cliente si aspetta. Agile si ripropone di risolvere questo problema lavorando a stretto contatto con il cliente, dichiarando apertamente più importante il dialogo e il feedback continuo rispetto alla negoziazione di un contratto vincolante. Ovviamente, per riuscire ad avere feedback continui dal cliente, Agile propone di rilasciare molto spesso parti di software realmente funzionanti, invece che alla fine del progetto (come succede normalmente con Waterfall): se si rilascia software funzionante ogni 2, 3 o 4 settimane, il cliente può usarlo, toccarlo e magari anche già venderlo. Inoltre può decidere di cambiare percorso e modificare anche pesantemente le altre features. Le mie esperienze lavorative mi hanno portato a conosce ed usare “Scrum” come metodologia Agile applicata allo sviluppo software. Come definizione non è esaustiva: mi riprometto di chiacchierarne meglio in alti post futuri.

Concerto per il Congresso Eucaristico Nazionale 2011 ad Ancona

Domenica 11 Settembre 2011 la Compagnia di Aquero è andata ad animare la conclusione del Congresso Eucaristico Nazionale ad Ancora alla presenza del Papa Benedetto XVI (era a 10 metri da me 🙂 )

Abbiamo fatto un bello spettacolo davanti a 3.000 persone, che ripercorreva il percorso del fidanzamento, dall’inizio della conoscenza fino al matrimonio, con momenti attoriali e canzoni. Il pomeriggio è andato veramente benissimo e posso dire che siamo stati veramente bravi!!

Per adesso non abbiamo nessun video ufficiale, ma appena arriva, lo postiamo.

Concerto “Mistral” a Malaga per la GMG

Dal 10 al 13 agosto siamo stati a Malaga per preparare e fare un concerto per i giovani del gruppo degli OMI che si preparava alla GMG di Madrid. Il concerto aveva nel primo tempo vari brani di Mite Balduzzi, dei quali io ho cantato “Prenditi cura di me”, “Madre dolcissima” e “Non finirà”. Il secondo tempo invece aveva tutti i brani del disco “Mistral” e io ho interpretato “Arlecchino Amore” e “Mistral”.

Ringrazio tutto il gruppo di amici musici e cantanti che, malgrado il caldo, hanno preparato ed eseguito lo spettacolo alla perfezione davanti ai 1,200 giovani accorsi.