Il commento di Felice introduce un nuovo argomento: Maintainers Groups

image

 

immagino che il “tipo” di manager a cui ti riferisci sia quello che conosciamo nell’accezione tradizionale, in cui il PM si siede dietro la scrivania, crea il Gantt, se ne frega di cosa accade nel delivery e promette la “luna”.

Si esatto, il manager a cui mi riferisco è quello nell’accezione tradizionale, quella negativa per capirci :-)

Secondo me il problema non è “il manager”, poiché esisterà sempre qualcuno che dovrà “gestire” gli aspetti non tecnici legati alla realizzazione di un Prodotto (o, nella sua totalità, di una Soluzione), ma come il “manager” sia coinvolto in tale realizzazione.
Il contesto a me caro dell’Agile (e se scaliamo, di DevOps e poi Lean), enfatizza come il manager sia un “servant manager” (ok, chiamiamolo anche Product Owner ;-) al servizio del team e della “soluzione” in generale. “Mentore” è una definizione che può forviare perché fa pensare a qualcuno che “guida/insegna” quando la relazione deve essere alla pari e di apprendimento reciproco.

Ameno, condivido su tutta la linea. Abbiamo il concetto di mentore, che come dice giustamente Felice ha poco da spartire con manager e/o PO (ne parleremo)

Anche se non etichettato direttamente come “manager”, in realtà, come implicitamente evidenzi, si avrà sempre qualcuno che dovrà coprire tale attività altrimenti sarebbe il caos: basti solo pensare alle relazioni con i clienti o con le altre funzioni non tecniche dell’azienda.

In realtà non ne abbiamo proprio, diciamo che abbiamo una task force che maneggia questi aspetti, anche di questo ne parleremo.

Il PO è coinvolto attivamente nella realizzazione e il suo obiettivo è massimizzare quanto realizzato agli occhi del cliente e non massimizzare il risultato in termini assoluti, lasciando al team la libertà e responsabilità di auto-organizzarsi nel modo migliore per raggiungere il risultato, proprio come da te evidenziato
Il “servant manager” è fondamentale nella definizione degli assoluti che hai citato: “massimizzare”, “ottimo”, “perfetto” tutto questo dovrebbe essere sempre declinato in funzione del Valore creato, che, alla fine, è comunque quello percepito dal cliente finale. Ok, è importante anche quanto “impariamo e miglioriamo” ma questo non è un discorso afferente al business.

Maintainers Groups

Come dice Felice il Product Owner è una figura essenziale, per come siamo organizzati noi un PO è una figura molto difficile da creare, il problema principale è la distribuzione delle persone intorno al globo, se creassimo un PO avremmo l’inghippo che quel PO è disponibile solo 8 al giorno mentre i team lavorano h24 complicando di molto le cose.

Avremmo inoltre il problema di concentrare la conoscenza in una singola risorsa, e sappiamo molto bene che in un sistema distribuito il concetto di “single point of failure” è proprio quello che vogliamo evitare.

Stiamo quindi introducendo il concetto di Maintainers Group (MG), un MG è un gruppo di persone, minimo 3, distribuite nelle macro time zone (America, Europa, Australia) che agisce come se fosse un PO disponibile h24.

In realtà un MG ha un ruolo un po’ più ampio rispetto a quello di un PO nella sua accezione tradizione in SCRUM, un MG ha (per ora) i seguenti compiti:

  • gestione del prodotto/progetto (a seconda del contesto)
  • amministrazione del/dei repository di competenza
  • triage
  • prioritizzazione
  • sincronizzazione con gli altri MG per garantire che si vada tutti nella stessa direzione, o almeno ci si provi
  • weekly housekeeping, che comprende
    • assicurarsi che quello che è in progress sia attivamente lavorato
    • manutenzione delle release
    • manutenzione delle build
    • pianificazione nel breve periodo
    • brainstorming sul lungo periodo

I MG al momento so work in progress e stiamo costruendo questo concetto giorno dopo giorno mano a mano che scopriamo cosa realmente vogliamo ottenere e quali sono i problemi che vogliamo risolvere.