Nei post precedenti abbiamo visto che il Manifesto Agile non è e non coincide con una metodologia ma bensì con una filosofia, un pensiero, un insieme di best practices che pongono al centro del prodotto sempre l’User. Spesso si fa confusione e si finisce per confondere e far corrispondere l’Agile con un singolo framework. Sbagliando. Più comunemente e più sinteticamente Agile non è Scrum e Scrum non è Agile. 

Agile Scrum: il Product Owner e il Team Tecnico

Scrum struttura e organizza il lavoro definendo dei ruoli, individuando il Product Owner come responsabile funzionale e il Team Tecnico come responsabile dello sviluppo. Ciò in cui Scrum in parte manca si riscontra proprio in questo punto. La responsabilità della funzionalità è incentrata sul Product Owner allontanando il Team Tecnico dall’obiettivo e dalla soluzione al problema. Il Team tecnico, che si occupa dello sviluppo, eseguirà nel corso del tempo tecnicamente feature richieste da altri, stabilite su decisioni degli altri e basate quindi su una strategia che si allontana dalla esecutiva quotidianità. Per avere una visione di insieme l’intero team dovrebbe essere in grado di spiegare la finalità di ogni feature.

Scrum, tra User Story e Velocity

Il framework Scrum usa la velocità come unità di misura per appunto misurare la produttività del team. Quante più task si portano avanti in uno sprint tanto più il team risulta essere produttivo. Questo comporta da una parte la velocità di azione del team nel rispondere ai task, dall’altra alla realizzazione dei task in modo così immediato e meccanico da agire prima di pensare. A volte quindi si perde il perché, il motivo per cui quel task debba essere eseguito, cosa apporterà quella feauture all’azienda, quale impatto avrà sull’user piuttosto che definire quanto sia stato prodotto, quante task siano state spostate nella casella done.

E qui non si può che ribadire il concetto che abbiamo più volte espresso, ovvero che non esiste un framework miracoloso che possa con la sua sola implementazione risolvere i problemi di un’intera azienda. E nello specifico Scrum, con tutte le sue regole da seguire, risulta peccare di flessibilità. Agile coaches che hanno abbracciato il framework Scrum in tutto e per tutto trovano come loro unica risposta a problemi non risolti o soluzioni non trovate questa, “Scrum funziona nel suo intero, non hai seguito Scrum from the book”.  Ma se è vero che è il framework a doversi adattare alle persone perché dovrei seguire per filo e per segno delle regole poco malleabili?

Scrum, e se cercassimo un’alternativa?

Scrum non è solo un framework ma anche un mindset. Voler trovare da Product Management un’alternativa significa quindi anche guidare il team verso un nuovo approccio, un nuovo modo di vedere e intendere le cose. Come agire? Piuttosto che mantenere costante il focus solo su le task da sviluppare e le feature da costruire uno step potrebbe essere quello di includere il team di sviluppo in discussioni incentrate sul business aziendale, sugli obiettivi e sui problemi che con quelle stesse task a loro assegnate andremmo a risolvere. Cambiando così la visione, includendo così il team in una visione di insieme. Molto più grande. Delegando a loro riflessioni e attività che per cui non riescono a trovare risposta in un codice dalla qualità impeccabile o in un manuale di istruzioni. L’obiettivo prende il posto della soluzione. Tutto questo ha bisogno di tempo, di molto tempo. Costruire un empowered product team, perché di questo si tratta richiede un grandissimo investimento di tempo. Mutare la cultura e l’organizzazione di un team è tutto tranne che un gioco da ragazzi. Ma come si dice... chi la dura la vince!

Le fasi del Cambiamento

Fatte le precedenti premesse, vediamo nel dettaglio come iniziare a muovere questo cambiamento. Costruire una nuova organizzazione richiede un processo lungo: perché non trattarlo e affrontarlo come una product strategy? E quindi come un problema di prodotto? 

Identifichiamo 

- L’obiettivo da raggiungere, quale e in quanto tempo: un empowerment product team autonomo nell’individuazione, sviluppo e implementazione di feauture strettamente connesse agli obiettivi aziendali di business. Tempo 3 anni.

- La sfida da affrontare per raggiungere l’obiettivo: un team che conosca gli obiettivi aziendali di business e che ad un anno e mezzo dalla sfida scriva da solo il 50% delle feauture, considerando gli obiettivi aziendali.

- Le prime cose da fare per affrontare la sfida: individuare un Team Lead che sensibilizzi nel tempo il resto nel team agli obiettivi di business.

- La situazione attuale da cui si parte: il team non conosce obiettivi aziendali di business e costruisce spesso feature disconnesse da ciò.

Preparazione al Cambiamento

Quali potrebbero essere le prime cose da fare per passare da una metodologia “project based” a un “impact team”? 

All’inizio il team non è pronto per vivere senza la sua struttura di riferimento e nello specifico seguendo il processo Scrum. Quindi un buon metodo potrebbe essere trovare un equilibrio lasciando in un primo tempo l’organizzazione basata su attività tipiche di Scrum, come le sprint o la retrospective, iniziando a lasciare maggiore libertà di movimento e decisione al team stesso. 

Altra azione importante potrebbe essere quella di individuare un Team Lead, ovvero un membro del Team. Il suo ruolo sarà cruciale. Il Team Lead rispetto al resto del team è consapevole e sensibile agli obiettivi di business, quelli legati alle funzionalità del team: la sua figura quindi supporterà il Product Manager nell’evangelizzazione di tali obiettivi all’interno del team, parlandone in tutte le possibili discussioni. Tirandoli in causa sempre.