Condividere i valori e pair programming

Ho sentito parlare più volte dell’importanza delle condivisione dei valori all’interno di un team. Fino a qualche giorno fa non ne avevo avuto esperienza diretta all’interno del team di sviluppo, e soprattutto non l’avevo vissuta sulla mia pelle. Negli ultimi due giorni ho invece avuto la fortuna di sperimentarlo, grazie ad una pratica che mi ha permesso di confrontarmi in modo molto stretto con il mio collega sviluppatore: il pair programming.

Come già accennato nel post precedente, attualmente lavoro su un piccolo progetto nel quale gli sviluppatori sono due: me medesimo ed un mio collega. Personalmente il pair programming (pp) è una delle pratiche che più mi piacciono di XP, per vari motivi.

Ritengo il pair programming la pratica più psicologica e human-intensive dell’extreme programming, perché esemplifica molti dei valori dell’agilità nel rapporto gomito a gomito che si viene a creare tra i due pairer, nonchè il principio dell’umanità. E’ proprio grazie a questo stretto rapporto tra due persone che ci si accorge se i valori sono allineati.

Dando per scontato questo allineamento dei valori (comunicazione, semplicità, feedback, coraggio, rispetto) tra me ed il mio collega ed i principi per mezzo dei quali scegliere quali pratiche applicare, ho pensato che il mio collega apprezzasse il pp, o meglio che fosse possibile applicare questa pratica. Ho pensato di poter convincere il mio collega ad applicarla, sottovalutando l’importanza dei valori e del sapere ascoltare.

Presto sono emerse una serie di resistenze (assolutamente rispettabili) a questa pratica, che penso siano comuni a molti: un certo orgoglio, l’intrepretare la navigazione come perdita di tempo, il desiderio di incappare personalmente negli errori per imparare. Ogni mio tentativo di “convincere” il mio collega della grande bontà del pairing falliva. Mi sono accorto che i motivi erano sostanzialmente i seguenti:

• il mio collega dà una grande importanza al valore della velocità a breve termine
• il mio collega antepone il valore della velocità a quello della comunicazione
• il mio collega ritiene che massimizzare il feedback per mezzo dell’interazione non sia sempre da ricercare

Personalmente ho commesso l’errore di voler convincere all’applicazione di una pratica invece che voler adattare la pratica stessa alle esigenze del team. L’uomo sempre al centro! Ad esempio se la navigazione può sembrare una perdita di tempo (“…capirai a che serve che ti trovo il punto e virgola!”), renderla più brain-intensive facendo tenere al navigatore l’elenco dei task, o comunque ricoprendo un ruolo più attivo. Il “problema” è che anche ogni contromossa di questo tipo è stata percepita come un’imposizione: i valori alla base del pair programming non erano condivisi!

Paradossalmente questa esperienza ha aumentato la mia stima nei confronti del PP, scoprendo un suo ruolo come grande risorsa nel far emergere vincoli e disallineamenti di prospettiva all’interno del team.
E’ emersa inoltre la richiesta di schiettezza e di apertura nel rapporto tra i pairer per rendere la pratica sostenibile. Proprio come in tutte le altre “intime” relazioni umane! Data la natura molto intima della pratica, si è rivelata anche faticosa a livello umano, perché da plasmare coppia su coppia!

Da un lato quindi l’adattare le pratiche facendosi guidare dal Rispetto, dall’altro la consapevolezza che se i valori di base non sono condivisi ogni tentativo di adattamento fallirà.