Troppo spesso le aziende si lanciano nella missione di "diventare Agile" prima ancora di capire cosa significhi veramente. Nel momento in cui si manifestano le prime crepe e le aspettative vengono disattese, iniziano a sorgere dubbi e si perde ogni possibilità di raggiungere l'obiettivo.
La verità è che diventare Agile significa creare team più produttivi e consegnare i progetti più rapidamente, ma questo può avvenire solo se tutti sono d'accordo sulle regole del gioco. Ascolta l'intervento di Heather Fleming e Justin Riservato, del gigante dell'e-commerce Gilt, che spiegano il motivo per cui ottenere il consenso sui principi Agile è più importante di implementare un processo.
In particolare, Heather e Justin esaminano le risposte a tre domande fondamentali a cui ogni team deve prepararsi a rispondere prima di intraprendere il percorso Agile:
- "Ma quando avrai finito?" Perché sbarazzarsi del concetto di scadenze è la conversazione più importante (e più difficile) quando si decide di diventare Agile.
- "Questa è la mia priorità assoluta, ma non posso incontrarti fino alla prossima settimana." Cosa fare quando il tuo partner commerciale non può (o non vuole) diventare un membro effettivo del team.
- "Tutto quello che voglio fare è programmare. Perché devo partecipare a tutte queste riunioni?" Perché implementare Scrum non è il primo passo per diventare Agile.
Guarda e impara
Domande e risposte
Qui, Heather e Justin hanno selezionato alcune delle domande principali poste durante la sessione di domande e risposte di questa presentazione. Continua a leggere per approfondire le tattiche su come applicare metodologie Agile.
D1: Meglio una board Agile digitale o una fisica? Qual è la vostra opinione a riguardo?
R1: Dipende molto dalla configurazione del tuo team. Lavorate tutti nello stesso posto? Da quanti membri è composto il team? Hai spazio sufficiente per una board fisica di grandi dimensioni? In Gilt utilizziamo entrambe ma abbiamo notato che, man mano che cresciamo e coinvolgiamo dozzine di team, le board Agile in Jira Software si rivelano più pratiche di quelle fisiche: sono molto più semplici da configurare, modificare e condividere con i membri dei team remoti. Il vantaggio delle board fisiche, invece, è che non puoi ignorarle perché ce le hai sempre sotto gli occhi. Inoltre, sono un ottimo posto per discussioni estemporanee sul lavoro in corso o per le riunioni stand-up, se ti capita di organizzarne.
D2: Come si può lavorare con un manager o un cliente che non segue o non comprende il processo Agile? A volte sento che i miei sforzi per spiegare come gestire efficacemente il flusso di lavoro non danno frutti.
R2: Devi innanzitutto riflettere sull'ordine delle operazioni. Se stai cercando di lavorare in un processo Agile con persone che non ci credono, sicuramente stai correndo troppo. Affinché tutto vada come deve andare, devi ottenere il consenso sulla filosofia prima di eseguire un processo. In passato lo abbiamo fatto esaminando i problemi specifici che un team stava riscontrando con il processo corrente e risolvendoli in modo Agile. Puoi illustrare al tuo manager o cliente i problemi reali che sta cercando di risolvere e spiegare come li affronteresti in un framework Agile? Puoi portare questa persona a diventare Agile gradualmente, piuttosto che sottoporre l'intero processo a un cambiamento radicale? Successivamente, man mano che il team inizia a lavorare in modo più efficiente, potrai mostrare risultati reali. In breve, il nostro consiglio è di adottare un approccio Agile per diventare Agile. ;)
D3: Come si può implementare un processo Agile quando il progetto ha un'offerta fissa e/o una programmazione fissa con una lista prestabilita di requisiti da implementare?
R3: Innanzitutto, è impossibile completare con successo un progetto con una programmazione fissa E una lista fissa di requisiti da implementare. La vera domanda è: esiste un modo per convincere tutti di questa verità? La maggior parte delle scadenze e dei requisiti non costituisce veri e propri vincoli: si tratta di desideri. Innanzitutto, interrogati sul motivo per cui vi state occupando di un determinato lavoro e sul problema che state cercando di risolvere. Se comprendi veramente gli obiettivi del progetto e i motivi alla base dei vincoli, puoi assicurarti che il team stia facendo il lavoro giusto al momento giusto. Prendere nota di tutti i requisiti con le relative date di scadenza non costituisce una garanzia di puntualità.
D4: La maggior parte dei progetti ha una data di rilascio che di solito viene comunicata a partner e clienti. In questi casi, l'unico aspetto negoziabile è l'insieme di funzioni (scendendo talvolta a compromessi sulla qualità). Come si può rispettare una scadenza fissa?
R4: Ti sei già dato una risposta: la soluzione è negoziare l'ambito. Se non lo fai, hai ragione quando dici che la qualità ne risentirà. Pensare di poterti concentrare nell'ambito a prescindere da tutto è un'utopia: anche se non è ciò che la gente vuole sentire, devi assicurarti che i tuoi team facciano i conti con la realtà. Heather ha scritto un breve post del blog su questo argomento che puoi leggere qui.
D5: Secondo voi, quali modifiche bisognerebbe apportare al modo in cui viene implementato Scrum?
R5: Il nostro problema più grande è la rigidità di Scrum. Pensare che un singolo processo altamente prescrittivo possa funzionare per tutti i team, indipendentemente da chi sono e a cosa lavorano, è presuntuoso. Sappiamo bene che è uno strumento efficace per i team, ma Scrum non è l'unico modo per essere Agile e molti team falliscono nel diventare Agile perché pensano di dover implementare Scrum in un modo specifico con tutti i ruoli lavorativi, le storie utente, i criteri di accettazione, le riunioni e gli artefatti previsti. Heather ha anche un problema con il titolo "Scrum Master". ;)
D6: Come si può impedire agli stakeholder di influenzare direttamente i membri del team?
R6: Beh, un buon stakeholder È un membro del team. Pertanto, idealmente, dovresti portare gli stakeholder principali nel tuo team affinché possiate lavorare tutti insieme! Se hai a che fare con stakeholder che si limitano a dare istruzioni al tuo team o intervengono durante il progetto cercando di modificare ogni cosa, è importante che l'intero team capisca cosa sta facendo e perché. Indipendentemente dalle persone con cui parlano gli stakeholder, la risposta deve essere sempre la stessa. È questo a fare la differenza tra un team e un insieme di persone. Devi comunicare molto e assicurarti che tutti siano sulla stessa lunghezza d'onda e si muovano nella stessa direzione.
D7: Valutate le story sulla base di stime approssimative dell'ordine di grandezza (in ore) o sulla base di punti?
R7: Facciamo l'una e l'altra cosa e alcuni team non utilizzano alcuna stima. I punti sono ottimi in quanto più astratti e scollegati da un calendario specifico. Le ore possono essere utili come transizione se il tuo team rifiuta la stima poiché è più tangibile. Lo scopo della stima è stabilire se uno sprint sia troppo pesante o troppo leggero e apportare le dovute modifiche. Una volta che lo sprint è iniziato, la stima non ha più alcuna utilità. Riteniamo che, una volta che hai lavorato con un team per un po' di tempo, il processo di stima non sia più necessario. Siamo tutti in grado di guardare il lavoro e stabilire piuttosto facilmente se la quantità sia giusta per lo sprint.
D8: Quanta importanza attribuite ai leader/responsabili del progetto con ottime capacità di analisi e conoscenza dei prodotti rispetto a quelli che si limitano a coordinare le riunioni tra gli stakeholder a livello tecnico e commerciale per raccogliere i requisiti?
R8: Sono importantissimi :) Coordinare le riunioni, prendere appunti e così via non sono competenze specialistiche: chiunque può occuparsene. Pur nella loro utilità, esistono mansioni ben più preziose per il team. Se vi state occupando di un lavoro puramente amministrativo, allora il team ha ragione a chiedersi perché tu ne faccia parte. Tutti i membri del PMO di Gilt conoscono perfettamente l'argomento in questione e gli strumenti e le tecniche per completare il lavoro e portano le proprie competenze in ogni team in cui lavorano. In precedenza, molti di noi erano ingegneri o hanno lavorato con altri reparti di Gilt e portano con sé competenze uniche in materia.
D9: Solitamente da quanti membri sono composti i team e che tipo di esperienza hanno le persone che lavorano in Gilt?
R9: Preferiamo che i nostri team siano snelli ma sufficientemente grandi da essere autonomi, così che possano portare avanti i progetti senza dipendenze da altri team. Seguiamo la "regola delle due pizze": i team dovrebbero poter essere nutriti con due pizze. Inoltre, siamo fermamente convinti che ogni individuo del team porti con sé una serie di talenti unici e dovrebbe essere in grado di utilizzare questi talenti nel team a prescindere da quale sia il proprio titolo professionale. Pertanto, se l'owner di prodotto è generalmente responsabile di tutte le presentazioni ma non possiede le competenze necessarie e c'è un ingegnere che sa come comunicare e conquistare un pubblico, lasceremo che sia l'ingegnere a occuparsi di questa mansione. Il titolo professionale non è tutto!
D10: Come gestite un team addetto al controllo di qualità separato, soprattutto nei casi in cui i test potrebbero essere eseguiti in uno sprint diverso da quello di sviluppo?
R10: Questa è una delle nostre posizioni più controverse, ma non abbiamo un team addetto al controllo di qualità separato in Gilt. Ci affidiamo ai test di automazione durante tutto il processo di sviluppo e distribuzione e ciascun team è responsabile della qualità del proprio codice. Se hai il tempo e l'esperienza per scrivere codice, hai il tempo e l'esperienza per scrivere test al riguardo. Affidare questo compito a un team addetto al controllo di qualità non ha mai dato buoni risultati per noi e richiede tempo e documentazione aggiuntiva per tenere questi team sempre aggiornati.
D11: Se più team lavorano a più "prodotti" contemporaneamente, può essere utile che tutti i product manager partecipino alla pianificazione dello sprint e stabiliscano le priorità relative tra i prodotti? Avete altri consigli al riguardo?
R11: Fermati! Non può funzionare. Il team dovrebbe avere un proprio product manager e dovrebbe evitare di lavorare a più prodotti per più product manager esterni al team. Chiunque abbia il ruolo di team leader dovrebbe stabilire in modo chiaro la metodologia del team per l'assegnazione delle priorità e l'ordine in cui verrà svolto il lavoro sulla base di tale metodologia. Questo discorso si ricollega alla nostra idea che "devi essere allineato alla tua metodologia prima di poter mettere in atto un processo".
D12: Sto cercando di introdurre un team di servizi creativi di marketing alla metodologia Agile. Abbiamo alcuni incarichi che DEVONO essere portati a termine entro una determinata data (progettare un'inserzione da stampare su una rivista). Come possiamo inserire questi progetti in un framework Agile?
R12: Agile è in grado di gestire vincoli come questo. Spetta al team il compito di identificare cosa deve essere fatto ed entro quando e pianificare gli sprint di conseguenza. Agile dovrebbe aiutarti a rispettare queste scadenze perché ti dà la possibilità di adattare le tue priorità e il tuo lavoro pianificato (ambito) a ciascuno sprint. Se inizi a monitorare la tua velocity, molto presto potrai capire se sarete in grado di rispettare o meno tali scadenze. È poi compito di un buon team leader essere in grado di negoziare ciò di cui il team ha bisogno per ottenere i risultati desiderati.
D13: Modificare gli obiettivi non equivale a uno scope creep?
R13: Sì, ma non parliamo di "scope creep" perché vogliamo incoraggiare la possibilità di apportare modifiche durante un progetto. Uno dei più grandi vantaggi di una filosofia Agile è che ti consente di adattarti a cose che sono al di fuori del tuo controllo. Se il panorama competitivo o le esigenze della tua azienda cambiano oppure sono disponibili nuove tecnologie, vuoi davvero proseguire con la matrice dei requisiti che è stata realizzata mesi prima? Se vuoi fornire al tuo cliente il miglior prodotto, accogli il cambiamento e utilizzalo a tuo vantaggio. Non esiste nessuno "scope creep" in Agile.
