eXtreme Programming e dintorni in salsa Team Nimbus

lunedì 25 settembre 2017


Alla nascita, una piccola azienda IT è generalmente costituita da poche persone che, con a disposizione solo il tempo e un pochino di hardware, cercano di trasformare un'idea in un successo commerciale.
In quelle prime fasi i lavoratori-fondatori sono molto affiatati e interagiscono molto, e per questo è comodo che condividano lo spazio. L'ufficio ideale è quindi costituito da una stanza nella quale trovano posto scrivanie e sedie a sufficienza per tutti.

Se davvero l'idea era buona e il successo arriva, il numero di persone generalmente aumenta e con esso aumentano le interferenze, molto spesso di natura acustica.
Quante volte ci capita di vedere che il lavoro di qualcuno (es. elemento del customer care che parla al telefono con un cliente) è disturbato dal lavoro di qualcun altro (es. sviluppatori che discutono ad alta voce di un problema)? In questi casi è importante trovare una soluzione che consenta a tutti di lavorare nel modo più efficiente possibile.

La soluzione "tradizionale", se vogliamo la preferita dal manager vecchio stampo, è quella di separare i lavoratori in spazi singoli (uffici, se sono sufficientemente importanti, altrimenti cubicoli). Esistono addirittura dei comodi "schermi divisori per scrivania" che uniscono il bello dei cubicoli alla semplicità di riconfigurazione delle scrivanie.


Certamente si tratta di un approccio che risolve il problema originale. Si vengono tuttavia a creare nuovi problemi, che generalmente sono sottovalutati dal manager di cui sopra:
  • le persone risultano essere isolate anche dai collaboratori
  • si perde la possibilità di sentirsi "parte di un tutto"
Il primo problema è la madre di tutti i problemi aziendali: se le persone non si parlano, necessariamente si lavorerà male perché:
  • "non sapevo che si fosse deciso di fare così"
  • "non sapevo che per ottenere X si potesse fare Y, io ho sempre fatto Z e ci mettevo una vita"
  • "non avevo capito se ti serviva X o Y e non sapevo come fare per chiedertelo"
eccetera eccetera, ad nauseam.

Il secondo problema è forse anche peggiore. Se le persone non si sentono parte del gruppo ma solo ingranaggi dell'azienda, nessuno si impegnerà per migliorare le cose. Tutto tenderà a mantenersi allo status quo "per inerzia".
Ovviamente il manager, che la sa lunga, non è affatto contento di questo e spingerà affinché le persone lavorino di più. Altrettanto ovviamente questo non farà altro che affossare ulteriormente il morale e aumentare i problemi nelle relazioni interpersonali (perché gli obiettivi dei singoli non saranno mai compatibili tra loro, e si creeranno tensioni perché le priorità di chi ha bisogno delle cose non saranno priorità per chi deve farle), che a loro volta ridurranno la propensione delle persone a parlarsi. Di nuovo, ad nauseam.

Ok, lo ammetto, è facile parlar male dell'ipotetico manager. Però che alternative ci sono?

Ripensiamo al problema originale. Il rumore che disturba è fortemente legato al fatto che persone che fanno lavori "incompatibili" lavorano le une vicino alle altre.
Ottimo. Allora allontaniamole. Prendiamo un ufficio bello grande (anche se magari un po' più in periferia), mettiamo le persone che parlano al telefono (customer care) da una parte e quelle che parlano tanto tra di loro (sviluppatori) dall'altra. Nel mezzo mettiamo le persone che non parlano al telefono né passano troppo tempo discutendo tra loro. Niente pareti, niente divisori.


Non basta? Chi parla al telefono può mettere le cuffiette col microfono, così mentre parla gode dell'isolamento necessario per la conversazione.
Certo, dal punto di vista dell'inquinamento acustico le stanze separate sono difficili da battere. Però la possibilità di parlare facilmente, senza barriere fisiche, con i colleghi crea condizioni di collaborazione migliori, che portano immancabilmente a risultati migliori.
Per i meeting è comunque bene avere a disposizione sale riunioni, tanto per non disturbare eccessivamente gli altri. Magari con porte a vetri, che lasciano passare tanta luce e ci consentono di scoprire in quale riunione è stato imprigionato quel collega del quale avevamo bisogno (e, di rimbalzo, consentono a lui di scoprire che lo stiamo cercando).

E se poi la gente si distrae e inizia a sparare ca**ate invece di lavorare?

La necessità di mantenere i dipendenti concentrati sembra essere uno dei grandi crucci del management. Mai come in questi casi tanto sforzo è stato impiegato con effetti tanto negativi.
Le persone non riescono a rimanere concentrate full time. Questo è un fatto e vale per tutti. Alcune pratiche dello sviluppo agile (tipo la tecnica del pomodoro) ne prendono atto al punto di introdurre momenti di pausa pianificati nel processo.
Una certa quantità di svago è assolutamente positiva, consente alle persone di riprendere il lavoro con rinnovate energie invece di costringerle a trascinarsi in stato catatonico fino all'ora di uscita. Inoltre la possibilità di parlare serenamente con persone che non lavorano direttamente con noi crea ottime opportunità di scoprire cosa stanno facendo gli altri e, in cascata, opportunità per creare sinergie e/o sfruttare meglio le risorse a disposizione (ad esempio evitando di rifare un lavoro che altri hanno già fatto in un altro contesto).

Non sappiamo quante aziende abbiano capito che le persone lavorano meglio se possono farlo da coese invece che da separate. Qui in 7Pixel l'apertura è da sempre parte dell'azienda, anche negli spazi: l'unico periodo nel quale ci sono state stanze separate (per interi reparti, non per singole persone) è stato quello in cui il numero di persone era salito al punto da eccedere la capienza della singola stanza, e la nuova sede non era ancora pronta. Quello è anche stato l'unico periodo nel quale si è sofferta la presenza di barriere nell'interazione con i colleghi.
Ora che la nuova sede è una realtà consolidata, i principi dell'open space sono stati incorporati persino nell'architettura: in entrambe le ali dell'edificio il piano superiore è più stretto di quello sottostante ed appare un po' come un balcone, consentendo alle persone su piani diversi di parlarsi direttamente a mo' di Romeo e Giulietta. Nei miei 8 anni di collaborazione con 7Pixel, l'open space è indubbiamente stato un fattore determinante nel successo dei progetti.

E voi, lavorate in un ambiente aperto e collaborativo o siete costretti a portare metaforici paraocchi come foste metaforici cavalli da tiro?




La nascita di un'idea

Ho già scritto un articolo riguardo a come i Nimbus hanno affrontato nel tempo il tema del continuous improvement e in generale della formazione/studio.
Oggi vi vorrei parlare di come 7Pixel ha pensato ad un modo alternativo per organizzare un evento formativo per tutti i suoi devs e di come io l'ho vissuto nel mio ruolo di organizzatore.
Il 7 Settembre 2017 si è svolta infatti la prima edizione dello Spartan Hackathon: una maratona di programmazione lunga 24 ore che ha visto sfidarsi 5 team di sviluppo.
In 7Pixel, grazie anche al nostro reparto "Qualità del lavoro" ci siamo fatti alcune domande:
  • come invogliare tutti gli sviluppatori a fare formazione?
  • come promuovere forme alternative di formazione che non siano "solo" corsi o conferenze?
  • come rendere il miglioramento continuo più stimolante, divertente?
  • come rompere la routine delle giornate lavorative con qualcosa di utile e spassoso?
Lo Spartan Hackathon è stata la risposta a queste domande.

Di che cosa si tratta

#spartanhackathon
Lo Spartan Hackathon altro non è che una epica sfida di programmazione: viene dato un problema e ogni team ha come obiettivo quello di realizzare il miglior software che risolva la sfida assegnata.
Tutti gli elaborati sono valutati da una giuria di esperti (gli Efori) che ne assegna i voti in base ai risultati ottenuti, alla creatività della soluzione trovata e alla presentazione del software stesso.

Le regole d'ingaggio

Ogni partecipante deve avere il proprio device su cui sviluppare. E' ammesso l'uso di librerie esterne e di un dataset che viene fornito dai saggi.
La battaglia dura 24 ore consecutive, ci si può riposare e rifocillare a piacimento.
Il software prodotto deve rispettare l'output richiesto ed ogni battaglione al termine dell'avventura deve fare una breve presentazione di quanto fatto.

I plotoni

Ogni plotone è composto da 4 soldati scelti in modo da separare gli elementi dei normali team di sviluppo aziendali e di avere seniority diverse all'interno del gruppo.
La scelta dei gruppi è stata una parte sicuramente divertente ma complessa in quanto abbiamo cercato il più possibile di fare squadre "equilibrate".

La  battaglia

Leonida e gli Efori
Il giorno dell'Hackathon è partito con note di folclore e ironia che scimmiottavano il tema spartano dell'evento.
Non sono mancate personalità in costume come l'annunciatore (io) e gli efori (i Product Owner dei vari prodotti aziendali).
Dopo la formazione dei plotoni (e la distribuzione di bellissime t-shirt e braccialetti con colori diversi per ogni team) e l'annuncio del tema della sfida, la battaglia ha avuto inizio.
Ogni team era in un'isola di scrivanie separata, dopo una prima fase d'analisi nella quale non sono mancate domande chiarificatrici del problema dato, si è passati al concept delle soluzioni e alla realizzazione vera e propria.
Lo stack tecnologico era libero per cui ogni battaglione ha, dopo aver trovato un accordo, incominciato a vomitare codice per raggiungere l'ambita meta. Si sono visti software in Java, C#, PHP e Ruby.

La notte

Il giorno è trascorso velocemente e nella notte si sono incominciati a vedere i primi segni di ironico squilibrio.
L'atmosfera era molto rilassata e giocosa anche se l'impegno nel realizzare il progetto era sempre presente. 
Fra un pisolo e l'altro non sono mancati divertenti siparietti e atti di pura follia :)

Il responso degli Efori

I plotoni presentano agli Efori
Le ultime ore della sfida si sono consumate nell'impacchettare qualcosa che fosse giudicabile dagli efori, i quali al termine della gara hanno assistito alle varie presentazioni dei team proponendo alcuni input particolari per poter giudicare gli output del software.
Con la consueta ilarità si è quindi arrivati alla proclamazione del team vincitore che ha ricevuto come premio, oltre alla gloria, anche delle bellissime medagliette a forma di elmo spartano :)
Dopo aver osannato i vincitori e deriso gli sconfitti abbiamo anche fatto una breve retrospettiva della giornata, a botte di post-it abbiamo trovato cos'è andato bene, cosa male e cosa si può migliorare.
I vincitori

Cosa ci ha lasciato

Ci vediamo alla prossima edizione
Sicuramente è stata un'esperienza nuova, diversa dagli altri Hackathon ai quali avevo partecipato.
Una vera sfida nella sfida in cui oltre a dover produrre un buon risultato, ci si deve anche scontrare con la stanchezza della notte, con un team con il quale non si è abituati a lavorare, con delle scelte che non sempre sono condivise e con un tema che non si conosce.
Personalmente credo che siano state 24 ore ben riuscite, in cui ogni partecipante e organizzatore si è portato a casa qualcosa,
Io come organizzatore ho compreso la difficoltà di trovare un tema adatto a partecipanti con competenze e skill diverse, ho capito che per organizzare un evento come questo l'ingrediente principale è l'entusiasmo, ho compreso che non è possibile accontentare tutti ma che è possibile comunque farli divertire e che per far in modo di avere un buon numero di partecipanti bisogna essere molto pazienti ed insistenti.

Il futuro

Speriamo che quella che si è consumata sia solo la prima di tante edizioni della Spartan Hackathon, ci auguriamo anche che questo evento possa essere, con i dovuti aggiustamenti, aperto anche all'esterno di 7Pixel coinvolgendo diverse community e aziende.
Vi terremo informati :)




Cerca nel blog

Blog Archive

Popular Posts