Dr. Strangework

Ovvero: come ho imparato a non preoccuparmi e ad amare il lavoro remoto

In questi tempi difficili dovuti alla recente crisi causata dal COVID-19 (o coronavirus), come team di sviluppo software siamo stati costretti a modificare radicalmente nostre pratiche di lavoro.

In questo articolo cercherò di raccontare come ci siamo trovati da un giorno all’altro a lavorare in remoto al 100% dalle proprie abitazioni, sperando di poter essere di ispirazione sia per realtà simili alla nostra, sia per capire se alcune di queste pratiche potranno essere estese in tempi di ritrovata normalità.

Il nostro è un team “Agile” che da 6 anni lavora in “Scrum”, composto da 8 persone tra Scrum Master e sviluppatori, che lavorano assieme a Sprint, i tipici cicli di lavoro di 2 settimane.
Come quasi tutte le altre realtà, in conseguenza ai provvedimenti emanati dal governo italiano, non ci siamo più potuti recare nel nostro studio dove solitamente lavoriamo a stretto contatto.

Il team in questione è formato dall’unione di due realtà, Chialab e Channelweb, che lavorano in sinergia già da anni, con sedi differenti anche se non molto distanti, per cui alcune pratiche di lavoro remoto erano già state implementate nelle routine quotidiane.

Come Chialab non abbiamo mai praticato molto il lavoro a distanza. Crediamo che ci siano delle componenti molto importanti nella quotidianità del lavoro in presenza, come scambi di opinioni tra colleghi che lavorano spalla a spalla sullo stesso progetto o idee espresse ad alta voce durante lo sviluppo software, che fanno dell’immediatezza della comunicazione (anche non verbale) un punto centrale del processo lavorativo.
Tutto questo, come detto, è venuto a mancare di colpo.

In questi giorni si sente molto parlare di “smart work”, termine che spesso viene utilizzato per descrivere il lavoro a distanza, quando in realtà esso non è che una delle pratiche che costituiscono lo smart work: un sistema di lavoro flessibile più ampio.
Smart work viene anche tradotto come “lavoro agile”, da non confondere con “Agile” pronunciato all’inglese, ovvero una serie di pratiche ben definite che come Chialab adottiamo da tempo.
Sarebbe più corretto quindi parlare di lavoro remoto o “remote work” per riferirsi unicamente alla possibilità di lavorare a distanza.
Nel caso specifico trattato in questo testo, illustrerò alcune pratiche di remote work, combinate con metodologie Agile.

Cosa è cambiato

Essendo il nostro un team Agile, la cui caratteristica principale è quella di rispondere al cambiamento prontamente, ci siamo trovati avvantaggiati nell’affrontare questa situazione straordinaria.

Il team nella fattispecie ha realizzato e gestisce delle piattaforme per l’editoria scolastica (scuole medie e superiori) per l’editore Zanichelli, piattaforme che nel periodo di chiusura forzata delle scuole, dovuto all’ordinanza per contrastare la diffusione del coronavirus, sono state messe sotto particolare stress, in quanto sono rimaste l’unico strumento per proseguire con l’insegnamento a distanza. In media la piattaforma principale contava circa 800 accessi al giorno che nel giro di pochi giorni sono balzati fino ad oltre 40.000 per poi stabilizzarsi sui 20.000 visitatori giornalieri.

Dal punto di vista tecnologico, i nostri prodotti si sono trovati a dover sostenere molti più accessi, scalando le risorse dell’infrastruttura server. Anche l’aspetto di comunicazione si è rivelato di strategica importanza, in quanto si è reso necessario evidenziare feature e contenuti fondamentali per una didattica a distanza.

La situazione, inoltre, era di difficile prevedibilità, in quanto le priorità dal punto di vista del business erano in continuo mutamento a causa della natura eccezionale della situazione in cui ci eravamo trovati.

Come ci siamo adattati

La prima cosa che abbiamo cercato di affrontare è stata le gestione della quantità di lavoro.

Il team era abituato a lavorare con carichi costanti e a realizzare nuove funzionalità per le piattaforme ma, in questo caso, era necessario lasciare tempo per imprevedibilità o emergenze da gestire in corso d’opera. Per questo motivo gli sprint sono iniziati con degli effort più bassi del solito.

Contemporaneamente, la realizzazione di nuove feature non poteva essere totalmente bloccata, sia per rispettare la roadmap del cliente, ma anche per mantenere alto il morale del team di sviluppo: uno sprint di soli bugfix o gestione di emergenze non sarebbe stato salutare per lo spirito del team.

Data la situazione di estrema dinamicità, potevano essere sottoposte al team di sviluppo problematiche in corso d’opera da parte del Product Owner e dei vari stakeholder; questo a lungo andare sarebbe potuto diventare problematico per il team, che già era alle prese con emergenze di vario tipo e si sarebbe dovuto fermare per valutare le nuove richieste.
Per ovviare a questo caso particolare lo Scrum Master, ha svolto una funzione di maggiore mediazione, supportando il Product Owner (del cliente) nell’identificazione delle priorità.
Come chi lavora in Agile sa, non è buona prassi fare da filtro per il team, ma in questo caso particolare ci è sembrato necessario procedere in questa maniera, lasciando più libertà al team di concentrarsi sul proprio lavoro.

Gli strumenti e le pratiche

Come già accadeva in situazione normale, tra team e cliente (che comprende il Product Owner) c’è una comunicazione tramite un canale di messaggistica immediata, Slack nel nostro caso, per eventuali problematiche o esigenze di progetto. Nel canale della chat condivisa avviene maggiormente la mediazione dello Scrum Master descritta precedentemente.

Esistono ovviamente anche dei canali di messaggistica riservati al team di sviluppo per discussioni più tecniche ed un canale riservato allo stand-up meeting (Daily Scrum). Questo canale, già utilizzato da tempo dal team, funziona con un bot che ogni giorno posta le classiche domande del Daily Scrum, ovvero:

• cosa hai fatto ieri?
• cosa farai oggi?
• hai qualche blocco e hai bisogno di aiuto?

a turno ogni membro del team scrive le sue risposte e lo Scrum Master le osserva per poter facilitare in seguito eventuali problematiche.

Oltre agli stand-up, il team ogni settimana fa quello che viene chiamato “weekly scrum”, ovvero una videoconferenza con il Product Owner (del cliente), per aggiornarlo sugli stati delle lavorazioni.

Sempre ogni settimana era regola degli sviluppatori ritrovarsi nello stesso posto per un momento di allineamento, dove uno o più membri del team mostravano una lavorazione particolare dello sprint in corso oppure qualche novità tecnologica realizzata o studiata.

Questo momento è stato mantenuto e modificato per dare spazio ad ogni membro di poter mostrare un aspetto del lavoro della settimana, in modo da mantenere tutti allineati anche senza stare nella stessa stanza.

Tutto il lavoro da quando è iniziato 6 anni fa è regolarmente tracciato in board su Jira, consultabile in ogni momento da remoto.

Per gestire la priorità e le specifiche delle attività da completare (Product backlog refinement) il team ha sempre fatto dei meeting in presenza una volta per sprint, due giorni prima del termine dello stesso, che per questa contingenza si sono trasformate in videoconferenze, senza particolari problemi.

Allo stesso modo lo Sprint Planning Meeting e Sprint Review sono diventate naturalmente delle videoconferenze.

Più difficile è stato adattare la retrospettiva del team, durante la quale si cerca di migliorare il lavoro del team stesso.

Cercando della documentazione online mi sono imbattuto in un articolo del team di Hotjar, che spiegava come utilizzare un template di Trello e un meeting a step via videoconferenza per trasformare la classica retrospettiva a post-it su un muro, in una retrospettiva su una board condivisa, dove visualizzare punti di forza e debolezze del team nello sprint appena terminato.

I risultati

Il primo sprint come prevedibile è stato molto difficoltoso, in quanto il cambiamento generale è stato repentino e non graduale.

I meeting, come detto, non sono cambiati molto rispetto al solito, a parte la retrospettiva che è comunque servita ad individuare le problematiche e mantenere valide le discussioni anche da remoto.

La maggiore mediazione tra team e Product Owner e stakeholder da parte dello Scrum Master ha aiutato gli sviluppatori a rimanere concentrati senza fermare il lavoro.

Nonostante le urgenze ben tamponate, le feature hanno progredito con un ritmo abbastanza regolare, anche se con degli ovvi, per quanto minimi slittamenti della timeline generale di progetto.

Seppur mancando componenti importanti di comunicazione dal vivo, possiamo dire che il lavoro remoto ha funzionato nel mantenimento delle performance e della qualità del lavoro e non escluderei che possa diventare parte integrante, ma non esclusiva del lavoro in un prossimo futuro.

Piccoli consigli personali

Vorrei concludere condividendo qualche piccolo comportamento che mi ha aiutato a gestire personalmente questo periodo di isolamento e lavoro remoto.

• create uno spazio di lavoro personale in casa: aiuta a mantenere la mente in modalità di lavoro evitando distrazioni
• pensate molto bene prima di scrivere in chat con colleghi e clienti: la comunicazione scritta è più complicata e va ponderata
• ricreatevi delle routine, simili a quelle che avete di solito in ufficio
• cercate di darvi degli orari fissi e non lavorare ad oltranza; aiuta ad avere del vero tempo libero per curare quello che non è lavoro

Manuel Zanettin