Non è stato il mio caso ma qualcuno mi ha detto che il messaggio che è arrivato è che Kanban è un sottoinsieme delle regole di Scrum che a sua volta è un sottoinsieme di quelle di XP. Mentre il messaggio credo volesse essere un altro. Personalmente l'ho ritenuto valido, anche se forse di parte (xp)?
A molti il talk può essere sembrato di parte verso XP e riduttivo verso Scrum/Kanban, se non una polemica vera e propria nei confronti delle metodologie agili.
In realtà il vero filo conduttore tra le problematiche nelle tre metodologie esaminate era quello della disciplina/integrità (illustrato come "uscire dalla zona di comfort"): forse lo spartiacque più importante tra team performanti e non.
Ho infine apprezzato la conclusione: con una frase ha sintetizzato bene un'intera filosofia che può essere presa come spunto pratico.
In generale un bel talk, con buon mix di osservazioni e provocazioni su cui riflettere.
Mi sarebbe piaciuto riuscire a chiedere a Matteo come far coesistere alcuni dei punti emersi nel talk, come:
- I team non hanno bisogno di una leadership tecnica
- I membri del team devono essere liberi di seguire le proprie idee
- I membri del team devono remare tutti nella stessa direzione
In risposta all'anonimo che mi attribuisce questo messaggio:
"- I team non hanno bisogno di una leadership tecnica
- I membri del team devono essere liberi di seguire le proprie idee
- I membri del team devono remare tutti nella stessa direzione"
Attento! Queste cose non sono vere in generale! Quello che volevo far capire e' piu' questo:
"In un team che funziona bene, il ruolo di tech leader non serve, anzi spesso e' dannoso. Questo NON SIGNIFICA che non ci sia leadership tecnica! Anzi deve esserci, ma non e' responsabilita' di un singolo individuo. Diventa responsabilita' di tutti."
"In un team che funziona bene, devo accettare che le cose possano essere fatte in maniera un po' diversa da come le avrei fatte io, PURCHE' LA QUALITA' SIA BUONA"
Il discorso sulla leadership e' molto interessante e c'e' un mondo di studio e ragionamenti per chi lo vuole approfondire. Se vuoi rivolgermi domande, perche' non le posti sulla mailing list extremeprogramming-it?
Ringrazio l'intervento chiarificatore di Matteo, che ha messo in evidenza proprio i punti che mi aspettavo sarebbero emersi, e di cui sono personalmente convinto.
La mia domanda/provocazione era legata ad'una interpretazione emersa nelle chiacchiere post keynote, e che speravo Matteo avrebbe aiutato a chiarire, come ha puntualmente fatto.
Mah, insomma... Non mi ha emozionato troppo. Chi conosceva già gli argomenti non ha ricevuto messaggi così nuovi, e chi era a digiuno di agile ha ricevuto una infarinata troppo diluita su troppi temi. Alla fine dello speech mi è rimasto il dubbio: quale voleva essere il succo messaggio?
Talk chiaro e autorevole.
Personalmente ho apprezzato molto l'invito alla riflessione a tutto tondo, penso che un key note debba prima di tutto far riflettere.
Mi sarebbe piaciuto avere anche qualche insight o qualche dato per evidenziare la traiettoria che ha XP o altre pratiche agili, qualcosa per dire "e' difficile ma keep calm and stay Agile"
Sono stato un po' deluso da questo key note.
Nonostante il titolo fosse promettente, ciò che ne è uscito è molta teoria e belle intenzioni, ma lontane dalla pratica e, a volte, anche dal realismo.
Ho avuto l'impressione di essere ad una di quelle lezioni in cui si parla di condensatori "con piatti paralleli ed infiniti". Che va bene come modello per capire i principi, ma poi non si applica nella realtà. Che sia questo uno dei problemi di quel 1% di adozione? Che approcciare con frasi come "il resto non funziona, le metodologie Agili sì" sia esattamente ciò che NON si deve dire ad una conferenza di questo tipo? Che l'approccio migliore sia dire: "ok, vediamo come convincere gente che ha fatto business (con successo) per anni con altre metodologie che questo metodo è più efficace"?
Davvero vogliamo ancora parlare di "alveare" (i.e. di team omogenei) quando nella stragrande maggioranza dei casi i team sono estremamente eterogenei? Non conviene suggerire, ad esempio, come inserire con efficacia un neolaureato in un team di persone ben più esperte?
In altri talk ho sentito diverse volte la frase "nani sulle spalle dei giganti". Credo sia quello che è mancato in questo key note. Peccato.
Con l'alveare non volevo suggerire che i team siano o debbano essere omogenei (d'altronde neanche le api fanno tutte lo stesso mestiere). Volevo suggerire che in un alveare le api costruiscono un sistema complesso senza bisogno di un coordinamento centrale. In un team XP i novizi si inseriscono bene, ma non e' questo il problema piu' grosso che io vedo e di cui io volevo parlare.
Per il resto quello che ho raccontato e' in (gran) parte frutto di quello che ho imparato da altri, in parte frutto della mia esperienza. E' vero, ci sono organizzazioni che hanno successo anche senza usare metodi agili. In molti casi pero' si tratta di organizzazioni che vivono di semi-monopolio (vedi il famoso sito di Trenitalia).
Comunque, fino a che hai successo, non sono certo io a venirti a dire che devi cambiare. Io parlo per quelli che non riescono a portare a termine i progetti con successo, o a quelli che non riescono a fare sufficiente margine per tirare avanti, quelli che non sono piu' in grado di fare evolvere il loro codice legacy.
I metodi di cui racconto funzionano si' in pratica, e lo so dall'esperienza. Ma il punto del mio discorso e' che per farli funzionare in pratica bisogna fare fatica! Non si tratta di un proiettile d'argento che si possa facilmente adottare o comprare. Si' c'e' molta distanza fra teoria e pratica, e la maniera di migliorare, secondo me, e' di modificare la pratica per farla aderire il piu' possibile alla teoria.
Spettacolare presentazione! Complimenti! Mi hanno fatto molto piacere anche le parole del Rettore della facoltà di Economia prima dello speech... Molto lusinghiere!
Comments
Comments are closed.
Ottimo argomento e slide efficace.
bello, forse un po' troppo polemico. Non ha reso giustizia alle metodologie non xp
Ottimo recap della situazione, fonte di collegamento per molti dei talk successivi.
Bravo Matteo, giusto partire dall'xp per iniziare a parlare di agile.
Non è stato il mio caso ma qualcuno mi ha detto che il messaggio che è arrivato è che Kanban è un sottoinsieme delle regole di Scrum che a sua volta è un sottoinsieme di quelle di XP. Mentre il messaggio credo volesse essere un altro. Personalmente l'ho ritenuto valido, anche se forse di parte (xp)?
utile per riflettere su dove si vuole andare e dove si sta andando
A molti il talk può essere sembrato di parte verso XP e riduttivo verso Scrum/Kanban, se non una polemica vera e propria nei confronti delle metodologie agili.
In realtà il vero filo conduttore tra le problematiche nelle tre metodologie esaminate era quello della disciplina/integrità (illustrato come "uscire dalla zona di comfort"): forse lo spartiacque più importante tra team performanti e non.
Ho infine apprezzato la conclusione: con una frase ha sintetizzato bene un'intera filosofia che può essere presa come spunto pratico.
Chiaro e condivisibile. E' vero: scrivere software bene è complesso e faticoso.
Ottimo talk, mi ha dato vari spunti di riflessione e approfondimento.
In generale un bel talk, con buon mix di osservazioni e provocazioni su cui riflettere.
Mi sarebbe piaciuto riuscire a chiedere a Matteo come far coesistere alcuni dei punti emersi nel talk, come:
- I team non hanno bisogno di una leadership tecnica
- I membri del team devono essere liberi di seguire le proprie idee
- I membri del team devono remare tutti nella stessa direzione
A.
Ottimo talk di una persona intelligente che ammette anche di essersi sbagliata, come su Rails.
Um grande impulso al miglioramento di noi tutti.
Keynote spettacolare. Mi è piaciuto molto il collegamento tra l'uscire della comfort zone e l'applicazione dell'agile.
Molto diretto ed efficace
Provocatorio e stimolante!
In risposta all'anonimo che mi attribuisce questo messaggio:
"- I team non hanno bisogno di una leadership tecnica
- I membri del team devono essere liberi di seguire le proprie idee
- I membri del team devono remare tutti nella stessa direzione"
Attento! Queste cose non sono vere in generale! Quello che volevo far capire e' piu' questo:
"In un team che funziona bene, il ruolo di tech leader non serve, anzi spesso e' dannoso. Questo NON SIGNIFICA che non ci sia leadership tecnica! Anzi deve esserci, ma non e' responsabilita' di un singolo individuo. Diventa responsabilita' di tutti."
"In un team che funziona bene, devo accettare che le cose possano essere fatte in maniera un po' diversa da come le avrei fatte io, PURCHE' LA QUALITA' SIA BUONA"
E' chiara la differenza?
Il discorso sulla leadership e' molto interessante e c'e' un mondo di studio e ragionamenti per chi lo vuole approfondire. Se vuoi rivolgermi domande, perche' non le posti sulla mailing list extremeprogramming-it?
https://it.groups.yahoo.com/neo/groups/extremeprogramming-it/info
Ti rispondero' volentieri e vedrai che coinvolgerai nella discussione tanti altri che la sanno piu' lunga di me.
Ottima presentazione.
Forse sarebbe utile però aggiungere qualche testimonianza/esempio reale di chi alla fine ci è riuscito e di chi invece no.
Ottima presentazione.
Forse sarebbe utile però aggiungere qualche testimonianza/esempio reale di chi alla fine ci è riuscito e di chi invece no.
Indubbiamente ci si aspetta che il keynote di apertura sia grandioso: e così è stato. Bravissimo Matteo (e non poteva essere altrimenti)
Ringrazio l'intervento chiarificatore di Matteo, che ha messo in evidenza proprio i punti che mi aspettavo sarebbero emersi, e di cui sono personalmente convinto.
La mia domanda/provocazione era legata ad'una interpretazione emersa nelle chiacchiere post keynote, e che speravo Matteo avrebbe aiutato a chiarire, come ha puntualmente fatto.
A.
Mah, insomma... Non mi ha emozionato troppo. Chi conosceva già gli argomenti non ha ricevuto messaggi così nuovi, e chi era a digiuno di agile ha ricevuto una infarinata troppo diluita su troppi temi. Alla fine dello speech mi è rimasto il dubbio: quale voleva essere il succo messaggio?
Molto bello, chiaro e stimolante.
Niente di particolarmente stimolante.
Un buon keynote.
Keynote assolutamente centrato e che descrive bene, secondo me, la realtà.
Mi è piaciuto proprio il fatto ricordare\non dimenticare XP
Talk chiaro e autorevole.
Personalmente ho apprezzato molto l'invito alla riflessione a tutto tondo, penso che un key note debba prima di tutto far riflettere.
Mi sarebbe piaciuto avere anche qualche insight o qualche dato per evidenziare la traiettoria che ha XP o altre pratiche agili, qualcosa per dire "e' difficile ma keep calm and stay Agile"
Sono stato un po' deluso da questo key note.
Nonostante il titolo fosse promettente, ciò che ne è uscito è molta teoria e belle intenzioni, ma lontane dalla pratica e, a volte, anche dal realismo.
Ho avuto l'impressione di essere ad una di quelle lezioni in cui si parla di condensatori "con piatti paralleli ed infiniti". Che va bene come modello per capire i principi, ma poi non si applica nella realtà. Che sia questo uno dei problemi di quel 1% di adozione? Che approcciare con frasi come "il resto non funziona, le metodologie Agili sì" sia esattamente ciò che NON si deve dire ad una conferenza di questo tipo? Che l'approccio migliore sia dire: "ok, vediamo come convincere gente che ha fatto business (con successo) per anni con altre metodologie che questo metodo è più efficace"?
Davvero vogliamo ancora parlare di "alveare" (i.e. di team omogenei) quando nella stragrande maggioranza dei casi i team sono estremamente eterogenei? Non conviene suggerire, ad esempio, come inserire con efficacia un neolaureato in un team di persone ben più esperte?
In altri talk ho sentito diverse volte la frase "nani sulle spalle dei giganti". Credo sia quello che è mancato in questo key note. Peccato.
Andrea
Andrea, grazie del feedback.
Con l'alveare non volevo suggerire che i team siano o debbano essere omogenei (d'altronde neanche le api fanno tutte lo stesso mestiere). Volevo suggerire che in un alveare le api costruiscono un sistema complesso senza bisogno di un coordinamento centrale. In un team XP i novizi si inseriscono bene, ma non e' questo il problema piu' grosso che io vedo e di cui io volevo parlare.
Per il resto quello che ho raccontato e' in (gran) parte frutto di quello che ho imparato da altri, in parte frutto della mia esperienza. E' vero, ci sono organizzazioni che hanno successo anche senza usare metodi agili. In molti casi pero' si tratta di organizzazioni che vivono di semi-monopolio (vedi il famoso sito di Trenitalia).
Comunque, fino a che hai successo, non sono certo io a venirti a dire che devi cambiare. Io parlo per quelli che non riescono a portare a termine i progetti con successo, o a quelli che non riescono a fare sufficiente margine per tirare avanti, quelli che non sono piu' in grado di fare evolvere il loro codice legacy.
I metodi di cui racconto funzionano si' in pratica, e lo so dall'esperienza. Ma il punto del mio discorso e' che per farli funzionare in pratica bisogna fare fatica! Non si tratta di un proiettile d'argento che si possa facilmente adottare o comprare. Si' c'e' molta distanza fra teoria e pratica, e la maniera di migliorare, secondo me, e' di modificare la pratica per farla aderire il piu' possibile alla teoria.
Diretto e interessante!
Bel talk, argomenti esposti con efficacia.
A tratti provocatorio ma ci sta per essere un keynote, non e' una lezione.
Spettacolare presentazione! Complimenti! Mi hanno fatto molto piacere anche le parole del Rettore della facoltà di Economia prima dello speech... Molto lusinghiere!
Begli spunti, ben legati, bel ritmo. Bravo!