# Teams
Come transition team (lista nomi) in questo periodo abbiamo ragionato sulle attività future relative all'organizzazione di Claranet Italia. Con questo post vogliamo condividere il lavoro fatto.
## Dove siamo diretti
Come ricorderete, in sede di definizione del Business Plan, è stata presa la decisione strategica di andare verso una delivery unica e non più segmentata in due aree distinte.
Per implementare questa visione strategica, ovviamente bisogna introdurre dei **cambiamenti** che riguardono **tutti**.
Nel Transition Team ci siamo interrogati su quale sia una struttura a tendere, ma sopratutto quali siano gli elementi fondanti che ci permettano di evolvere valorizzando le nostre conoscenze e mantenendo la nostra cultura.
Quello che descriviamo oggi è quello che riteniamo l'elemento fondante: **il Team**.
Parleremo di come cambia rispetto a come lo abbiamo inteso fino ad oggi, e daremo l'idea della direzione verso cui muoversi nei prossimi mesi.
## Una nuova idea di team
La proposta di un modo diverso di comporre i team prende spunto da una serie di osservazioni sulla situazione attuale e tiene in considerazione l'obiettivo finale, ovvero quello di arrivare ad avere un'organizzazione in grado di scalare, basata su team che siano self-sufficient e cross tra le vecchie aree funzionali.
Con il termine *self-sufficient* indichiamo dei team che hanno tre caratteristiche:
- auto organizzazione
- deleghe, capacity, competenze
- guard rails
I team quindi sono unità che si **auto-organizzano** nello svolgimento del lavoro di delivery, che hanno le **deleghe**, la **capacity** e le **competenze** necessarie ad attuare azioni che vanno oltre la sfera tecnica, quali attività interne (recruitment, mentoring, teaching, ...) ed esterne (rapporto con il cliente, monitoraggio del budget, prioritizzazione del lavoro, ...).
Intraprendono il percorso verso la consegna di valore ai clienti stando all'interno di **guard-rails** definiti dalla governance, quali budget, marginalità, priorità, ...
In questo percorso di trasformazione riteniamo necessari alcuni cambiamenti.
In primo luogo vogliamo disaccoppiare il ciclo di vita del team da quello dei progetti del **cliente**
Il team sarà un'unità stabile con un **tempo di vita** diverso da quello attuale, e non più legato dal carico di lavoro che arriva da un singolo cliente, e una persona farà parte di **uno e un solo team**.
Questa struttura potrà garantire la crescita delle persone e limitare il rischio di stagnare per troppo tempo negli stessi ambiti e tecnologie.
Il team potrà lavorare su diversi progetti per diversi clienti in contemporanea (tendenzialmente non più di due/tre), decidendo in maniera autonoma l'allocazione interna.
All'arrivo di un nuovo prospect, invece di comporre un team ad hoc, saranno i team esistenti a proporsi in funzione della propria capacity, competenze ed interessi.
Si modificherà la **dimensione** attuale dei team: ad oggi abbiamo team molto piccoli che sentono forte l'impatto dell'ingresso di nuovi progetti ed attività. L'idea è quella di portarli ad essere composti da un numero sufficiente di persone per avere abbastanza massa per gestire più progetti e clienti, garantendo una buona comunicazione interna. Indicativamente, prendendo spunto da Scrum, 5 - 9 persone.
Per arrivare a questi numeri non è sufficiente unire i team attuali ma è necessario l'inserimento di **nuove persone**. Già alcune stanno arrivando, frutto dello sforzo fatto in questi mesi da chi si è dedicato al recruitment.
L'ingresso di questi nuovi assunti dovrebbe essere inoltre semplificato dal fatto che entrati in Claranet andranno subito a bordo di un team. Il team stesso si occuperà delle attività di mentoring e on-boarding facendo leva sulla presenza di più persone che possono in momenti diversi affiancare chi comincia a lavorare con noi.
Andrà inoltre aumentata la **diversity** facendo in modo di avere un mix funzionante ed equilibrato di esperienze, approcci e competenze, favorendo la diffusione di conoscenza all'interno del team. In direzione strategica, venendo meno la differenza tra le aree Agile e Cloud, i team saranno composti da persone che storicamente arrivano dai due diversi ambiti.
Bisognerà garantire ai team lo **slack** necessario per avere il tempo a disposizione per favorire l'auto-organizzazione e per essere in grado di gestire imprevisti e variazioni nel carico di lavoro: un sistema impegnato al 100% è fragile e inefficente.
## Il Percorso
Quello che ci si prospetta è un **cammino graduale** di trasformazione fatto di esperimenti che condivideremo. Assieme valuteremo il riscontro e nuove idee ed intuizioni che emergeranno oltre a quanto fin qui descritto.
L'obiettivo a tendere è quello di strutturare la one delivery nel modo indicato. Quello che non si può definire a priori sono i dettagli delle configurazioni dei team (quante persone, quale mix di competenze, quanta diversity...): *emergeranno strada facendo e terranno conto della specificità dei diversi contesti*.
Ci rendiamo conto che questo cambiamento mette sotto pressione il sistema e chiede un forte **coinvolgimento di tutti**, dato che dobbiamo contemporanemente consegnare valore e modificare il modo in cui lo facciamo. Non abbiamo alternativa; non possiamo fermarci riorganizzarci e ripartire, perché nel frattempo il mercato e i nostri clienti continuano a muoversi e non ci aspettano.
Come direbbe il saggio *Yoda*
> NO! Try not!
> DO or DO not,
> There is no try
Con il passare del tempo **ulteriori tematiche** andranno affrontare quali:
- gestione del context-switch,
- rotazione dei membri fra i team,
- bilanciamento del carico di lavoro,
- figura del mentor che fa crescere altri team su conoscenze verticali (microservizi, ML, serverless, ..)
In un approccio incrementale vogliamo crescere gradualmente, sapendo che i team stessi porteranno idee e contenuti su come smarcare questi punti.
## I primi esperimenti
La prima azione nella direzione di questa nuova idea di team è stata portare Angelo Gelmini a bordo del team Gaiago. Angelo con il suo background ha permesso di **avere un team cross** in cui si sono verificati i primi **scambi di competenze e conoscenze**.
Sono anche emerse delle difficoltà sulla gestione di progetti su cui Angelo era già impegnato (Cerved). È normale che succedano queste cose, vanno affrontate in maniera aperta, e il loro superamento contribuisce alla definizione del modello.
Notizia di queste settimane è la **nascita di un team** nato dall'accorpamento tra le persone che si sono occupate in questi anni di Mercury e Banca Mediolanum, l'inserimento in questo team del neo-assunto Walter, la presenza di colleghi dell'ex area Cloud e la presa in carico di un nuovo cliente, ConTe.
In questo team, visto il focus di Conte sui microservizi, sperimenteremo anche ll lavoro di Paolo D'Incau come mentor su quelle tematiche.