Dunque, argomento tosto che non so se riesco (e voglio) esaurire in un singolo post. In Particular la struttura è fluida, molto fluida, con tutte le conseguenze del caso. Ho già introdotto il concetto di Maintainer Group ma ovviamente è una delle tante strutture/processi che in un modello molto fluido sono necessarie, perché l’anarchia non funziona.
Le strutture principali che abbiamo sono in questo momento 4:
- Squad
- Task force
- Guild
- Maintainer Group
Lasciamo da parte per un secondo i Maintainer, di cui ho già accennato.
Guild
Una Guild non è ancora ben definita, diciamo che l’intenzione è quella di identificare un gruppo di persone molto lasco accumunate da un interesse comune, ad esempio RabbitMQ, quindi una Guild-RabbitMQ serve per discutere tutto ciò che è inerente a RabbitMQ e che va oltre il dettaglio che abbiamo un trasporto basato su RabbitMQ.
Task Force
Una task force è un gruppo di persone, diciamo almeno 3, che si forma al fine di portare a termine un compito. Potremmo, semplificando, che una task force ha lo scopo di gestire il ciclo di vita di una issue su GitHub e quindi il suo ciclo di vita è legato a quello della issue stessa. Per certi versi una task force si comporta in maniera molto simile ad un team scrum, e in linea con alcune pratiche scrum la task force ha bisogno di uno scrum master. Data la fluidità della cosa il concetto di scrum master come persona da noi non funziona, abbiamo quindi da poco introdotto il concetto di facilitator che all’interno della task force agisce come scrum master. Il facilitator viene nominato dalla task force quando quest’ultima si forma, quindi apre ad un interessante scenario che è in linea con la nostra necessità di condividere conoscenze e skill, chiunque può fare il facilitator e chiunque può quindi imparare a fare il facilitator.
Squad
Se una task force si occupa dell’operatività quotidiana, una squad si occupa di processo. Abbiamo tanti processi interni (tanti) e ogni processo ha una squad che ha lo scopo di definire prima e manutenere poi quel processo. Ad oggi la squad è anche coinvolta nel processo di prioritizzazione, ma sappiamo che è una cosa che vogliamo cambiare e a cui stiamo lavorando. Una cosa importante quando dico che si occupa di processo è che una squad non è responsabile di modificare un processo, è responsabile di realizzare che una modifica è necessaria (internamente chiamata process improvement), a fronte di questa necessità la squad apre una issue, una task force si forma (senza necessariamente includere persone della squad) e il processo/problema viene discusso e modificato di conseguenza, se necessario.
Il ciclo di vita di una squad è virtualmente infinito, ma i membri che la compongono no, c’è un modello di rotazione che fa si che chiunque possa partecipare per un periodo al lavoro di una squad. Aprendo quindi ad una delle cose che adoro: chiunque può avere un impatto, se lo vuole, su qualsiasi aspetto dell’azienda che sta aiutando a costruire.
Due note importanti:
- il modello è inclusivo per definizione, sta al singolo decidere se ne vuole stare fuori perché by design è coinvolto
- l’azienda a questo punto diventa un modello fluido, in continua evoluzione e mai finito o con contorni netti e ben definiti, il che ovviamente può essere frustrante
Abbiamo scalfito la superficie, o forse neanche :-)
Approfondiremo, mi sa che ci potrei scrivere un libro su quello che ho imparato negli ultimi 18 mesi.