Blog

Pubblicato il

Sprint Retrospective: come funziona?

Sprint Retrospective

Sprint Retrospective: come funziona?
Partiamo con alcune citazioni.

Nel Manifesto per lo Sviluppo Agile di software il principio n. 12 richiama il concetto di retrospective: “a intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza”.

Nella Guida Scrum nel paragrafo dedicato alla Sprint Retrospective si stabilisce che: “Lo Scrum Team ispeziona come è andato il precedente Sprint relativamente agli individui, alle interazioni, ai processi, agli strumenti ed alla propria Definition of Done”.

La Guida al Project Management Body of Knowledge (PMBoK) edizione 7  al paragrafo §2.5.8 si parla in generale di apprendimento nel corso del progetto: “Periodicamente, il gruppo di progetto potrà incontrarsi per determinare sotto quali aspetti può migliorare (lesson learned) e come può migliorare e sfidare il processo nelle iterazioni successive (retrospettive)”.

Sprint Retrospective: come funziona?
Vediamo a partire dalle definizioni il suo funzionamento a grandi linee.

La retrospective è un incontro presente in tutti gli approcci: agili, ibridi e predittivi. Quando tenere la retrospective può essere o meno formalizzato nel framework o metodo utilizzato. Ad esempio: in Scrum è un evento denominato Sprint Retrospective e si tiene alla fine di ogni Sprint; nel metodo Kanban non è definito un momento specifico in cui tenere la retrospective ma spetta al team che si auto-gestisce stabilire la periodicità di questo incontro.

La definizione della Guida Scrum mette in evidenza degli ambiti specifici su cui confrontarsi durante la retrospective:

  • Individui
  • Interazioni
  • Processi
  • Strumenti
  • Definition of Done

In modo trasversale rispetto a questi ambiti, il team mette in evidenza cosa ha funzionato, cosa non ha funzionato e cosa migliorare rispetto ad un arco temporale trascorso (iterazione o sprint). L’output di una retrospective è una lista ordinata per priorità delle azioni di miglioramento che può attuare immediatamente. Il risultato atteso dall’implementazione delle azioni è l’effettivo miglioramento in termini di efficacia ed efficienza.

Sprint Retrospective: perché non funziona?
Può stupire ma questo evento è molto delicato, frequentemente perde di efficacia sino ad essere abbandonato o svolto solo perché è scritto nella guida Scrum.

Che la Retrospective sia un momento ritenuto da tutti importante è un dato di fatto, banalmente ho potuto averne dimostrazione con un breve e semplice esercizio che svolgo in aula. L’esercizio consiste nel dividere in gruppi i partecipanti (3-5 persone per gruppo), dar loro i 12 principi dell’Agile Manifesto e chiedere di scegliere i 3 principi che ritengono essere i più importanti. Questo esercizio lo svolgo da oltre cinque anni, purtroppo non mi sono mai divertito a tirare giù una statistica, ma potrei iniziare a farlo. Ad oggi ho rilevato qualitativamente che il principio numero 12 ha un’elevata frequenza di scelta, una buona fetta delle persone ritiene che sia molto importante avere un momento durante il quale riflettere e migliorarsi, come dargli torto.

Cosa accade nella realtà?
Questo evento tende ad essere abbandonato o a non generare valore per il team.

Quali sono gli anti-pattern della retrospective?
Ovvero, quali dinamiche riconoscibili emergono da un’esecuzione disfunzionale della retrospective?

Stefan Wolpers fa un elenco completo nella sua Guida agli Anti-Patterns di Scrum, di seguito riporto un estratto di alcuni anti-patterns:

  • #NoRetro: lo Scrum Team chiede di eliminare o non tiene più la retrospective.
  • Dispensable buffer: la retrospective viene cancellata per completare il lavoro necessario a raggiungere lo Sprint Goal.
  • Rushed retrsospective: lo Scrum Team alloca meno di 60 minuti per l’evento.
  • Someone sings: quanto viene condiviso nella retrospective viene raccontato a stakeholder esterni, violando la regola: “quanto si dice nel team resta nel team”.
  • Extensive whining: l’evento diventa un momento per lamentarsi e per fare le vittime.
  • UNSMART: lo Scrum Team sceglie azioni di miglioramento non misurabili e poco chiare, ad esempio: migliorare la comunicazione, ridurre il numero di bug, ecc. Un’azione SMART è Specifica, Misurabile, Attuabile, Rilevante e Temporalmente definita. Ad esempio: invece di “migliorare la comunicazione”, è meglio “accendere tutti le webcam”.
  • #NoAccountability: le azioni di miglioramento non hanno un responsabile.
  • What improvement: lo Scrum Team non verifica lo stato dei miglioramenti emersi nelle precedenti retrospective.

Se interessati ad approfondire gli anti-pattern, consiglio di completare la lettura scaricando la guida gratuita messa a disposizione da Stefen Wolpers.

Sprint retrospective: come funziona?
Bene, è giunto il momento di condividere suggerimenti utili per migliorare le nostre retrospective.

L’esperienza mi ha insegnato che per iniziare a rendere funzionali le retrospective è utile porre attenzione su alcuni aspetti in particolare:

  • Evitare la noia e la ripetitività: ogni retrospective va progettata rispetto a quanto il team ha esperito durante lo Sprint, selezionando strumenti che riteniamo possano aiutarlo nella riflessione. Piccolo sfogo, finiamola di utilizzare sempre e solo uno strumento come lo Stop/Start/Continue o similari (mongolfiera, barca, ecc.); liberiamo la nostra creatività e divertiamoci.
  • Webcam accesa: se lo Scrum Team lavora da remoto è necessario sensibilizzare le persone a tenere accese le webcam, questa è sempre una buona abitudine, a maggior ragione durante la retrospective. Vale il principio numero sei: “una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team”. Ovviamente non è un obbligo, non sempre è possibile accenderla, l’aspetto importante è far emergere il bisogno e la dimostrazione della sua efficacia nella comunicazione.
  • No finger point: creare un clima sicuro e sereno dove sia in discussione il lavoro e non le persone, rinforzare l’atteggiamento di astensione dal giudizio.
  • Risoluzione di conflitti: è impossibile evitarli, è necessario gestirli sin dai primi segnali, lo Scrum Team deve sviluppare la capacità di affrontare i conflitti e risolverli senza spargimenti di sangue.
  • Intelligenza emotiva: chiedere frequentemente alle persone cosa hanno provato, come si sono sentiti in determinate situazioni, condividendo emozioni positive e negative. Anche questo è un aspetto su cui le persone hanno bisogno di allenarsi e acquisire consapevolezza.

Questo elenco non è esaustivo, sicuramente ciascuno di noi ha altre esperienze e aspetti che può integrare, leggendo la guida agli anti-patterns emergeranno altre strategie per evitare situazioni disfunzionali.

Come strutturiamo a questo punto la retrospective?

Nel mio caso mi sono stati d’aiuto due elementi:
- La struttura in cinque fasi suggerita nel libro Agile Retrospective 
- Gli spunti per personalizzare i diversi giochi forniti da Retromat e FunRetrospective 

La struttura della retrospective proposta nel libro di E. Derby e D. Larsen è composta da cinque fasi:

  • Set the stage: ha come obiettivo quello di aiutare le persone a concentrarsi, deve creare un’atmosfera confortevole dove le persone sentano di poter parlare apertamente.
  • Gather data: l’obiettivo è quello di creare una rappresentazione condivisa di quanto accaduto durante l’iterazione, sono raccolti eventi, fatti, osservazioni e risultati.
  • Generate insights: il team ricerca e discute sulle possibili cause, i dati raccolti durante la fase precedente vengono valutati e se ne ricava una visione significativa.
  • Decide what to do: l’obiettivo è quello di spostare l’attenzione dall’iterazione appena conclusa, alla prossima iterazione. Si decide cosa e come cambiare, sono identificate e ordinate per priorità le azioni di miglioramento, i responsabili e le metriche per determinare il raggiungimento dell’obiettivo.
  • Close the retrospective: è un’opportunità per riflettere su cosa è accaduto durante la retrospective, elencare le decisioni prese, ed è anche un momento per riassumere ciò di cui il team è grato.

Per ciascuna delle fasi è possibile utilizzare delle attività differenti, le attività possono essere selezionate rispetto al livello di maturità del Team (5 fasi di Bruce Tuckman) e, ovviamente, possono essere personalizzate per aderire pienamente con lo spirito del team.

Non elencherò tutte le attività possibili, sono consultabili sui siti di Retromat e FunRetrospective. Per approfondire e vedere un esempio di applicazione di quanto scritto, suggerisco di leggere gli articoli del mio collega Riccardo Ciocci:

Un breve viaggio tra le sue prime retrospective e la loro progettazione decisamente originale, raccontato anche nel webinar The sprint retrospective show.

Libera la tua creatività progettando la tua prossima retrospective.
Se ti va di condividere con me la tua esperienza non esitare a scrivermi.

Se vuoi sviluppare le tue competenze nel facilitare le retrospective e gli altri eventi Scrum, potrebbe interessarti il corso di certificazione ICAgile Agile Team Facilitation.

Per restare aggiornati su nuovi articoli e webinar puoi seguirmi sui social (link nel footer) e sul sito Agile Made in Italy.

Pubblicato il

Corporate Rebels – Joost Minnaar, Pim De Morree

Genere e contesto

Saggio di business e management, il libro racconta il viaggio degli autori alla scoperta delle aziende più innovative al mondo e di come abbiano rivoluzionato i tradizionali modelli di lavoro.

Trama

Joost Minnaar e Pim De Morree, stanchi del lavoro aziendale convenzionale, decidono di esplorare come le organizzazioni possono essere più umane, produttive e felici. Visitano diverse aziende all'avanguardia, tra cui Spotify e Semco, per scoprire pratiche radicalmente diverse e più efficaci.

Stile e linguaggio

Lo stile è dinamico e accessibile, scritto in forma di diario di viaggio aziendale, che rende la lettura scorrevole e coinvolgente. Gli autori alternano riflessioni personali a studi di caso.

Tematiche

I temi centrali sono la libertà lavorativa, l’autogestione, la trasparenza e la felicità dei dipendenti. Il libro sfida i modelli aziendali gerarchici tradizionali e promuove l'empowerment delle persone in azienda.

Punti di forza

Ispirante per chi è in cerca di un nuovo modo di lavorare e gestire le risorse umane. Gli esempi concreti mostrano che le organizzazioni possono essere sia innovative che umane.

Debolezze

Alcune delle pratiche illustrate possono sembrare utopiche o difficilmente applicabili in contesti più conservatori.

Conclusione

Corporate Rebels è una lettura ispirante e pratica per chi è interessato a modelli di lavoro non convenzionali e vuole trasformare la propria azienda in un ambiente più libero e innovativo.

Compralo ora su Amazon
Pubblicato il

Sense & Respond, di Jeff Gothelf e Josh Seiden

Genere e contesto

Un saggio di business e management, Sense & Respond si concentra sulla trasformazione delle aziende digitali, esplorando come possano diventare più agili e reattive in un mercato in continua evoluzione.

Trama

Il concetto chiave del libro è la capacità delle organizzazioni di "sentire" (sense) ciò che accade nel loro ambiente attraverso il feedback continuo e di "rispondere" (respond) rapidamente alle esigenze dei clienti e alle mutevoli condizioni di mercato. Gothelf e Seiden offrono un approccio pragmatico per gestire l'incertezza, facendo leva sull'apprendimento iterativo e sulla sperimentazione continua.
Il libro è ricco di casi aziendali reali che illustrano come organizzazioni come Zappos, Amazon e The New York Times abbiano abbracciato questi principi per migliorare il proprio approccio al mercato.

Stile e linguaggio

Il linguaggio è semplice e accessibile, ideale sia per professionisti del business che per lettori meno esperti. Gli autori forniscono esempi pratici e concreti che rendono i concetti immediatamente applicabili nella vita aziendale di tutti i giorni.

Tematiche

Il libro esplora temi come l'adattabilità aziendale, l'importanza del feedback continuo, il fallimento come opportunità di apprendimento e la centralità del cliente nelle strategie aziendali.

Punti di forza

Il libro è particolarmente utile per coloro che operano in contesti dinamici e complessi. La struttura chiara e i numerosi esempi pratici aiutano a comprendere i concetti e a metterli subito in pratica.

Debolezze

Alcuni concetti, come il focus sul feedback continuo, possono risultare ripetitivi, specialmente per lettori già familiari con metodologie agili o lean.

Conclusione

Sense & Respond è un manuale pratico e illuminante per manager, imprenditori e professionisti del business che vogliono migliorare la reattività della propria azienda e affrontare con successo le sfide di un mercato in costante cambiamento.

Compralo ora su Amazon
Pubblicato il

Il Quarto Valore

Il quarto valore dell’Agile Manifesto presenta un’alternativa alla rigida pianificazione. Una pianificazione leggera e adattiva ci consente di abbracciare il cambiamento.

 

La pianificazione è importante, i cambiamenti alimentano le nostre conoscenze e aumentano la nostra consapevolezza nel prendere decisioni.

 

Oggi più del passato adattarci rapidamente ci porta a scoprire nuove capacità e a sviluppare nuove competenze.

Pubblicato il

Il Terzo Valore

Il terzo valore dell’Agile Manifesto aiuta a creare un clima di fiducia tra le parti coinvolte. 

I contratti sono importanti, ma solo la collaborazione e la fiducia reciproca ci consente di raggiungere il pieno successo delle parti coinvolte.

I contratti si basano sulla sfiducia reciproca, se già partiamo con questa premessa negativa come potremmo raggiungere un risultato vincente per tutti gli attori coinvolti?

Pubblicato il

Il Secondo Valore

Il secondo valore dell’Agile Manifesto va letto sostituendo “soluzione” alla parola “software”. Tutti compriamo prodotti aspettandoci che funzionino, poco importa se il manuale ci sia e sia bello. Chi lo legge?

Questo valore non supporta l’assenza di documentazione, spinge alla ricerca del feedback rapido e iterativo, documentando solo quanto basta.

Cosa importa del manuale se la soluzione non funziona o non è utile?

Pubblicato il

Il Primo Valore

Il primo valore dell’Agile Manifesto mette al centro la squadra, persone che interagendo insieme sono capaci di liberare creatività e innovazione andando oltre gli schemi predefiniti.

Alcune squadre (sportive, musicali, staff di ristoranti, ecc.) raggiungono elevate prestazioni perché unite da valori e obiettivi, e non grazie a procedure e strumenti.

Se ti diverti in quello che fai, la fatica si dimezza, se il divertimento è condiviso la fatica non pesa.

Pubblicato il

Introduzione all’Agile Manifesto

L’Agile Manifesto, che nasce per il mondo del software, trova esempi di applicazione nella vita di tutti i giorni.

Agile è solo un termine ombrello per comprendere meglio il mondo che ci circonda, che ci invita ad accogliere i cambiamenti per cogliere nuove ed infinite opportunità.

Che cosa vuoi fare da grande? Mi auguro di poter sempre continuare a pormi questa domanda.

Pubblicato il

Dinamica del gruppo: le 5 fasi di Bruce Tuckman in uno Scrum Team

Creare le condizioni per avere un ottimo Scrum Team può rivelarsi un’operazione molto complessa, ma se si conoscono le dinamiche dei gruppi, c’è una maggiore probabilità di raggiungere un alto livello di collaborazione e di prestazione tra tutti i membri dello Scrum Team.

Nel 1965, Bruce Tuckman, professore di psicologia educativa alla Ohio State University, ha studiato l’evoluzione delle relazioni nei rapporti di gruppo in ambito lavorativo, elaborando un modello specifico. Tuckman ha individuato così le 5 fasi che scandiscono le dinamiche dei singoli gruppi. Analizziamole singolarmente calandole nel contesto dello Scrum Team.

Libro consigliato
Patrick Lencioni, La Guerra nel Team: Racconto sulle 5 disfunzioni del lavoro di squadra

FASE 1: Forming

Lo Scrum Team si trova in questa prima fase ogni volta che si verifica una di queste due situazioni: nuova costituzione dello Scrum Team o modifica con inserimento e/o rimozione di uno o più membri del team.

Le singole persone dello Scrum Team inziano a conoscersi, si sviluppa un senso di appartenenza tramite la condivisione dei valori. In questa prima fase ciascun membro del team cerca una figura di riferimento per acquisire le regole di comportamento. Potrebbe essere lo sponsor, il product owner o lo scrum master. Le persone appartenenti allo Scrum Team si osservano e si confrontano per orientarsi, non hanno ancora chiari i comportamenti consentiti, lo stile di comunicazione e le modalità di collaborazione. Da questa fase si transita verso la successiva in modo graduale con l’aumentare della pressione sul lavoro da svolgere. L’urgenza nel dover iniziare le attività porta il team a doversi organizzare rapidamente, causando inevitabili conflitti, e portando alla fase 2.

FASE 2: Storming

Nella fase di Storming (da “Storm” che significa tempesta) si presenta la situazione di conflitto. Il conflitto emerge in modo naturale quando il team deve svolgere attività con forti vincoli temporali. In queste situazioni è necessario che ogni componente del team, esca dalla propria zona di comfort per collaborare e raggiungere l’obiettivo comune. La figura dello Scrum Master è fondamentale, perché assume il ruolo di un coach. Tra i diversi eventi di Scrum questa è in particolare la fase dove valorizzare la Sprint Retrospective, questo evento fornisce supporto nel distendere le tensioni e risolvere i conflitti in modo collaborativo (win-win).

Durante la fase di Storming lo Scrum Team tocca il minimo della sua efficienza, i conflitti non risolti diventano dei veri e propri ostacoli al raggiungimento della massima prestazione possibile. Quante volte ci è capitato, o abbiamo sentito dire: “Preferisco fare io questa attività anche se non dovrei, perché è impossibile parlare con il collega e giungere ad un accordo.” Questo è proprio uno dei sintomi che segnalano la presenza di conflitti non risolti e bassa efficienza.

Come è possibile immaginare, i conflitti nello Scrum Team non termineranno mai, ciò che cambierà con l’allenamento, sarà la capacità di ciascuna persona di riconoscerli e risolverli immediatamente. Questa abilità che si andrà a sviluppare gradualmente nel tempo consentirà dapprima di passare alla fase 3 e poi alla fase 4 delle dinamiche descritte da Tuckman.

FASE 3: Norming

Quando lo Scrum Team diventa consapevole dell’esistenza dei conflitti, dell’importanza che ha la loro risoluzione in ottica collaborativa e non di compromesso, si passa gradualmente alla fase del Norming. In questa fase il team non padroneggia ancora le tecniche di risoluzione dei conflitti, ha ancora bisogno di allenamento, tuttavia ora il team ha reso pubblici i propri conflitti e la propria volontà di superarli insieme e questo è già un ottimo risultato in termini di clima di squadra. Superata la tempesta si rafforza il senso di unità e le singole persone iniziano a sentirsi parte di un team. In questa fase il team si autoregola e si chiariscono anche i contributi che ciascuno può dare allo sviluppo del lavoro. Aumenta il senso di trasparenza e di conseguenza la fiducia, si mettono a punto gli strumenti e le azioni per raggiungere l’obiettivo.

FASE 4: Performing

L’allenamento continuo nella risoluzione dei conflitti, il miglioramento continuo del modo in cui si lavora porta il team nella fase del “Performing”, ovvero della massima efficienza. Questi team sono stati definiti team ad alte prestazioni (High Performace Team o Swarm Team). Lo Scrum Team ora è in grado di auto-organizzarsi e riesce a gestirsi autonomamente, si adatta rapidamente ai cambiamenti e mantiene lo slancio nel processo di miglioramento continuo. In questa fase tipicamente lo Scrum Master può dare maggiore delega al team, in quanto ha maturato tutte le caratteristiche necessarie per aderire totalmente ai valori e principi agili. Nel team tra i membri si è consolidato un clima di sicurezza psicologica (Psycological safety), nessuno ha timori ad aprirsi completamente, condividere debolezze, avere coraggio nello sperimentare, si è raggiunto il massimo livello di collaborazione.

FASE 5: Adjourning

In questa ultima fase delle dinamiche identificate da Tuckman, il team si separa perché il lavoro è stato portato a termine.

In uno Scrum Team questo può accadere, ad esempio, in contesti in cui il team non è interno all’azienda. In una relazione del tipo cliente-fornitore dove al termine degli impegni presi, non essendoci più l’esigenza, le parti si separano per essere impiegate in altri lavori. Un’altra possibile causa di scioglimento del team può riguardare il ritiro di un prodotto dal mercato e dal portfolio aziendale.

Le dinamiche del gruppo
Le 5 fasi del gruppo, di Bruce Tuckman

Alcune considerazioni

Bruce Tuckman ha notato che, ogni qualvolta si aggiunge o si rimuove anche un solo membro dal team, si retrocede e si ritorna alla fase iniziale per passare rapidamente a quella di conflitto (Storming). Se lo Scrum Team è maturo può essere in grado di assorbire rapidamente un cambiamento di un membro del team, perdendo di poco efficienza e per un periodo molto breve. Emerge dunque che il turnover, ovvero il continuo cambiamento di risorse all’interno dello Scrum Team, non è mai positivo e porta quasi sempre ad un rallentamento o blocco del lavoro.

Assumendo uno Scrum Team maturo, e attuando il turnover solo quando strettamente necessario, è possibile ripristinare in tempi brevi la fase di massima prestazione (Performing). Il turnover in questi casi è quello dovuto a cause comuni, ad esempio persone che cambiano lavoro o che si spostano in altri team. Questa capacità rapida di recupero è un beneficio della dinamica di lavoro cross-funzionale dello Scrum Team. All’interno del team c’è la massima condivisione di conoscenza, la più ampia condivisione di competenze e non esistono membri indispensabili, ma tutti sono dispensabili.

Non possiamo a priori stabilire il tempo necessario ad attraversare ciascuna fase, ogni team è unico. Così come non possiamo prevedere con certezza se un team sarà in grado di raggiungere il massimo della sua efficienza. Lo Scrum Master deve essere un coach e supportare il team nel riflettere su quali possano essere gli ostacoli che lo bloccano dal raggiungere la massima prestazione, deve fornire loro le tecniche per superare i conflitti e dar loro autonomia decisionale sulle azioni da intraprendere.

Pubblicato il

Esistono contratti Agili? Quali sono i rischi?

Contratti Agili
Businessman pressing contract on a digital screen, concept about agreement in business

La situazione sui contratti Agili

Il Framework Scrum si sta rapidamente diffondendo nei reparti di sviluppo software delle aziende italiane. Spesso le aziende si rivolgono all'esterno per lo sviluppo del software, per questo motivo in aula mi viene posta sempre la stessa domanda: Esistono contratti Agili?

Ad oggi, in Italia, non sembrano esistere ancora dei modelli contrattuali Agili legalmente riconosciuti. È possibile fornire informazioni sui contratti Agili in generale, ma non supportati da un parere legale.

In Italia, al momento, possiamo  utilizzare tipologie contrattuali che possono essere adattate ad un contesto Agile.

L’assenza di modelli contrattuali Agili può essere un ostacolo è un problema che alcune aziende stanno affrontando in questo momento. Molte vorrebbero affidare esternamente lo sviluppo del software, potendo così beneficiare di processi Agili per la creazione rapida di valore.

Tipologie di contratti internazionali e soluzioni nazionali

All'estero sono già presenti forme contrattuali specifiche per progetti che adottano processi Agili.

Tra le prime organizzazione che hanno sviluppato modelli contrattuali agili è possibile trovare l'Agile Business Consortium. Questo il link per scaricare il modello: Agile Project Framework Contract Template. Ovviamente per utilizzarlo in Italia, oltre alla traduzione, è necessario un adattamento attraverso una consulenza legale.

Esistono anche altri modelli contrattuali di riferimento:

Per ora questi contratti possono essere utili come fonte di ispirazione per adattare contratti legalmente riconosciuti.

Nell'attuale contesto italiano i contratti che meglio possono adattarsi al framework Scrum, e in generale ad Agile, sono il Time & Material e il contratto a rimborso. Nei contratti può essere determinato un tetto massimo di costo, la durata del progetto e la durata di uno Sprint senza necessità di determinare nel dettaglio l’ambito del lavoro. Lo Sprint avrà così sempre lo stesso costo. Sarà necessario porre particolare attenzione al valore che si intende produrre in ogni Sprint, per evitare di spendere più del valore che si otterrà in cambio.

Cosa rende critico un contratto Agile?

L'aspetto considerato critico in un contratto Agile è la potenziale completa assenza di un ambito dettagliato. Oggi è frequente la possibilità che un progetto venga avviato a partire da un’idea e bisogno non ancora tradotti in requisiti tecnici e funzionali.

Una delle caratteristiche del progetto, infatti, potrebbe proprio essere quella di esplorare e apprendere qualcosa di nuovo. I processi e le pratiche Agili sono particolarmente efficaci in progetti complessi. Il modello Agile prevede che a fronte di un ambito poco o per nulla definito, si fissino due variabili : il tempo e il costo. Allo scadere del tempo e del budget, si restituisce ciò che è stato realizzato fino a quel determinato momento. Vi sembra folle? Non lo è, vediamo perché.

Alcune ricerche hanno messo in evidenza che il numero di funzionalità utilizzate da un utente in un prodotto è nettamente inferiore rispetto al loro numero totale. Semplificando potremmo dire che: il 20% delle funzionalità di un prodotto costituisce l'80% del suo valore.

Quindi possiamo affermare che: il costo di ciò che è stato prodotto, è sicuramente minore del valore creato in termini di business (profitti e/o riduzione dei costi).

Pertanto in un progetto non è necessario realizzare tutto, ma tutto ciò che ha valore.

Oggi è ancora particolarmente difficile trovare aziende disposte a fare un contratto su un ambito poco definito.

Ad esempio, cliente e fornitore si accordano per un valore economico e temporale fisso, a fronte di un ambito poco chiaro. In caso di contestazioni su cosa ci possiamo basare?

La trasparenza e la frequente comunicazione tra le parti diventano un elemento centrale per sviluppare fiducia nella collaborazione. Citando il terzo valore dell'Agile Manifesto: "La collaborazione col cliente più che la negoziazione dei contratti". Questo aspetto, a mio parere, non credo sia un elemento gradito ad un ufficio legale e non solo.

Vuoi saperne di più? Inviami le tue domande, ti risponderò nei prossimi articoli.

Proudly powered by WordPress