L'ultima introduzione alla gestione agile dei progetti

Il Breve

Sei incaricato di fornire l'ultima e più grande iniziativa della tua azienda che cambierà per sempre il volto di "Widgets International". È un progetto software che coinvolgerà e affascinerà i tuoi clienti, renderà la vita dei tuoi colleghi più facile e farà guadagnare milioni all'azienda. C'è una grande quantità di anticipazione, fervore, eccitazione e aspettativa. Devi farlo il più rapidamente possibile in modo che la tua azienda possa iniziare a trarne vantaggio. Il successo futuro dell'azienda dipende da te. Tutti gli occhi sono puntati su di te. Non puoi fallire.

All'inizio, stai pensando a te stesso: "Fantastico, sono pronto per la sfida. Facciamo questa cosa!” Ti fermi per un momento, fai un passo indietro e pensi a te stesso "Va bene, quindi come lo facciamo?" Inizi a parlare con i tuoi colleghi e colleghi. Trascorri del tempo alla ricerca delle migliori pratiche di sviluppo software e tecniche di gestione dei progetti, ma le opzioni e gli approcci sono innumerevoli. Ci sono sigle e metodologie in abbondanza. Quelli notevoli salgono in cima. Il dubbio si insinua. Quale dovremmo usare? Come posso garantire il successo? E se prendo le decisioni sbagliate?

Quando si tratta di gestire progetti software, c'è un inebriante mix di opzioni supportate da una miriade di opinioni. Voci dagli angoli della stanza sussurrano: "Prova a farlo in questo modo"; altri gridano: "Questo è l'unico modo per farlo"; e il resto si limita a piagnucolare: "Non gestirlo affatto, vai avanti". In realtà, tutte quelle voci dicono una verità. Ma ciò che è importante è capire cosa è giusto per le tue esigenze, il tuo team, la tua azienda e i tuoi clienti.

Organizzare la scena

C'è stato un tempo in cui la gestione dei progetti software si trovava esattamente in uno dei tre campi. C'erano strutture pesanti che ti permettevano di prendere decisioni su come eseguire e fornire, offrendo al contempo una struttura per mantenere il controllo e la governance. C'erano metodologie sequenziali prescrittive come la cascata che ti costringevano a pianificare progetti lunghi, comprendere e impegnarti per tutti i tuoi requisiti, progettare e firmare sistemi complessi, scrivere molto codice e quindi testare (il tutto prima che il tuo cliente lo veda per la prima volta volta). E infine, i cicli di vita dello sviluppo del software (SDLC) meno prescrittivi ma iterativi che incoraggiano la prototipazione rapida o la progettazione, la costruzione e la consegna di sistemi più grandi in fasi incrementali, uno sull'altro.

Lo sviluppo software agile e la gestione dei progetti Agile sono nati dalle inadeguatezze della cascata e dai vantaggi degli approcci iterativi alla distribuzione del software. Possono far risalire le loro radici agli anni '50, alla leadership del pensiero negli anni '70, alla maturità negli anni '90 e all'adozione negli anni 2000. Nel 2001, un gruppo di professionisti ed esperti ha creato il Manifesto Agile, volto a definire 4 valori e 12 principi guida che cercano di incarnare lo spirito dello sviluppo del software Agile e di incoraggiarne l'evoluzione. E si è decisamente evoluto.

Ora, chiamare semplicemente qualcosa di Agile non è particolarmente utile. La parola, anche in un contesto software, significa cose diverse per persone o organizzazioni diverse. Ci sono molte sfaccettature, definizioni, implementazioni e interpretazioni. Ogni corpo che abbraccia Agile tende a cercare di dargli una propria definizione.

Basti dire che lo sviluppo del software Agile e la gestione dei progetti sono un gruppo di comportamenti, framework, tecniche e concetti correlati che favoriscono fondamentalmente la consegna del giusto software funzionante il più presto e con la frequenza più realistica possibile.

Ho accennato in precedenza che Agile, applicato allo sviluppo di software o alla gestione dei progetti, può essere cose diverse. In poche parole, lo sviluppo del software Agile si occupa dello sviluppo di un ottimo software in un contesto di business as usual (BAU) o di progetto. La gestione agile dei progetti, d'altra parte, si occupa della governance e del controllo necessari per fornire progetti complessi, incluso ma non limitato al software.

Sono disponibili molti metodi di sviluppo software Agile, come Scrum, Kanban, XP e Lean Software Development. Ma proprio come il gioco del rugby è qualcosa di più della mischia, così è Agile. In isolamento, questi paradigmi Agile non affrontano l'intero ciclo di vita della gestione dei progetti richiesto in progetti complessi come governance, risorse, gestione finanziaria, esplicita del rischio e molti altri importanti concetti di gestione dei progetti. Per questi, potresti prendere in considerazione PMI Agile o PRINCE2 Agile, pensalo come "Agilità governata".

Perché dobbiamo essere agili?

Molto tempo fa, abbiamo vagato per la terra per raccogliere cibo e un riparo per sopravvivere. Erano esigenze semplici, ma piuttosto agili. Qualche tempo dopo, i paesi e le economie crebbero e prosperarono sulla scia della rivoluzione industriale. Questa è stata la nascita della gestione e del controllo e la perdita di agilità. Ora siamo nell'era dell'informazione o rivoluzione, in cui le aziende impiegano lavoratori della conoscenza. I lavoratori della conoscenza siete voi, i vostri partner e i vostri colleghi e colleghi, che si sforzano di creare ottime soluzioni ai problemi dei clienti, aziendali, sociali, economici e mondiali. I knowledge worker applicano analisi, conoscenze, ragionamento, comprensione, esperienza e abilità a bisogni spesso definiti in modo impreciso e mutevoli. Queste imprese e questi lavoratori hanno bisogno di metodi e tecniche che non possono essere soddisfatte dai processi e dalle procedure della vecchia era industriale. Agile supporta le interazioni.

Praticamente nessun progetto software può iniziare con sicurezza all'inizio e conoscere tutto ciò di cui ha bisogno per fornire un prezioso software funzionante senza modifiche. Il cambiamento presenta sia opportunità che rischi per il successo di un progetto. Le opportunità non gestite possono fare la differenza tra una grande azienda e una fantastica azienda. Il rischio non gestito è sinonimo di disastro e rovina. Agile gestisce il cambiamento.

L'adozione di Agile ti consente di essere reattivo ai cambiamenti o ai nuovi requisiti. Consente ai team di sviluppo di essere gli esperti e di prendere decisioni supportate da un'azienda impegnata, fiduciosa e informata. Ti consente di fornire ai clienti ciò che vogliono veramente. In definitiva, consente a te e alla tua organizzazione di avere il controllo della fornitura di software prezioso e di alta qualità che soddisfa le esigenze e le aspettative dei clienti, estraendo un ritorno sull'investimento il prima possibile. Agile crea valore.

L'adozione di Agile comporta un costo. Non viene gratis. Il passaggio a un approccio Agile per la distribuzione del software può essere un percorso difficile da seguire. Tuttavia, se interiorizzi la filosofia Agile, procedi con cautela, coinvolgi il team giusto con l'atteggiamento giusto, scomponi le cose, le rendi realizzabili e realistiche e rispondi ai feedback, raccoglierai frutti. Agile sottolinea la collaborazione.

Di seguito sono elencati alcuni vantaggi che puoi aspettarti:

• Velocità al mercato
• Generazione di entrate anticipata
• Consegna regolare di valore reale
• Protezione per il tuo investimento
• Dati, dati, dati
• Migliore qualità del prodotto
• Aspettative gestibili
• Maggiore soddisfazione del cliente
• Squadre più performanti
• Migliore visibilità sui progressi
• Prevedibilità, trasparenza e fiducia
• Rischio gestibile

Il successo non è definitivo, il fallimento non è fatale: è il coraggio di continuare che conta.

Winston Churchill potrebbe non averlo mai detto, ma penso che sia una buona sintesi di Agile. Sappiamo che Agile è il miglior passo avanti per la maggior parte dei progetti. Ti incoraggia a lottare per il successo, ma ripetiamo sempre e continuiamo a costruire su di esso. Agile ti incoraggerà a fallire, ma fallire presto e andare avanti. Avere il coraggio di continuare e di costruire la soluzione giusta sulla base delle informazioni fornite dal cliente è ciò che porta la ricompensa.

La cosa da tenere a mente è che puoi adattare Agile alle tue esigenze. Usa il metodo e la governance adatti alla tua azienda. Ovunque inizi, sii fedele al contenuto, al contesto e allo spirito del metodo che usi, mantienilo vanigliato. Se hai appena iniziato, impara . Se lo fai da un po', capisci . Se stai diventando fantastico, candidati . Infine, se il tuo business e i tuoi progetti sono complessi e interdipendenti, governa . Nel tempo, tu e i tuoi team scoprirete cosa funziona meglio per la vostra attività.

Fattibilità

Quindi ora stai pensando: "Okay, ho capito. Come inizio? Da dove comincio?" Bene, con tutte le cose buone, iniziamo dall'inizio. E con Agile, è chiedendoti "Quale valore aziendale voglio offrire?" Dopotutto, è per questo che intraprendiamo progetti, per generare valore aziendale. Per stabilire se vale la pena intraprendere il progetto per ricavarne il valore di business, è necessario capire se è fattibile.

Visione

Il tuo progetto è progettato per aumentare le entrate, entrare in un nuovo mercato, acquisire più clienti, migliorare la percezione dei clienti o rendere la vita più facile per un determinato problema che hai identificato? Con questo in mente, puoi affermare la tua "visione".

• La tua visione può provenire da diverse fonti: la tua audace startup per risolvere un problema comune, la strategia di gestione aziendale, il progetto preferito del tuo CEO, un team di prodotti specifico o persino le esigenze dei tuoi clienti.
• Prova a fare un passo indietro rispetto alle tue scarpe e a "vedere" come sarà il futuro con il tuo nuovo prodotto o servizio nelle mani dei tuoi clienti.
• Coinvolgi i tuoi stakeholder: CEO, product guy e clienti. Offrilo, non tentare questo in isolamento. Sfida le ipotesi e convalida le argomentazioni.
• Scrivilo, mantienilo breve. Concentrati sul valore aziendale.
• Affinalo fino a quando non sarai d'accordo, la visione risuona con tutti e incontra un'interpretazione comune che afferma dove stai andando.
• La tua visione, se valida, cambia raramente. Come ci arriverai sicuramente lo farà.

Le persone non comprano quello che fai, o come lo fai. Comprano il "perché" lo fai. Questo è ciò che crea la connessione emotiva tra la tua azienda e i tuoi clienti. La visione aiuterà a illustrare questo.

È fattibile?

La fattibilità arriva in almeno un paio di sfumature. In genere, vorrai capire se la tua visione di un futuro più luminoso per la tua azienda e i tuoi clienti è sia tecnicamente fattibile sia se è fattibile per la tua azienda realizzarlo.

• Se la tua visione è quella di viaggiare in qualsiasi parte del mondo in meno di un'ora, potresti avere un problema con la fattibilità tecnica. Dal momento che scienza, fisica e tecnologia non hanno ancora raggiunto quel sogno, la tua soluzione tecnica potrebbe non essere praticabile in nient'altro che in teoria. Inoltre, se la tua soluzione fosse nuova, ciò andrebbe ben oltre l'idea di un prodotto minimo sostenibile (MVP).

• Per testare la fattibilità tecnica del tuo prodotto, considera di esplorarlo ulteriormente in un progetto di prototipo Discovery o di eseguire un picco nelle prime fasi del progetto. Saprai quale metodo utilizzare pensando alla scala o alla complessità della soluzione che hai in mente.

  “Alcune delle migliori conoscenze che i miei team hanno acquisito nella comprensione della fattibilità tecnica sono derivate dall'esecuzione di un picco. E spesso è la soluzione più semplice che vince!”

• La seconda sfumatura di fattibilità da considerare è se tu, il tuo team o la tua azienda avete le capacità e la motivazione per farlo funzionare. Usando un esempio, se sei bravo a cuocere le torte a casa per il compleanno dei tuoi bambini, è dolce. Ma se vuoi trasformarla in un'attività che vende le migliori torte al mondo, devi capire se puoi ridimensionarla, gestire l'attività e la produzione, gestire la distribuzione e l'adempimento e occuparti del servizio clienti.
• Questo tipo di visione potrebbe essere realizzabile a lungo termine. Ma per ora, forse no. Quindi ridimensionalo, pensa in piccolo, prendi un piccolo pezzo che sembra realistico e concentrati sul fornire la migliore aspirazione più piccola possibile. Se ciò riesce a coinvolgere e deliziare i tuoi clienti, falli tornare per saperne di più e dirlo ai loro amici, quindi amplialo da lì usando il feedback dei tuoi clienti come guida e bussola.
• Inoltre, devi sapere se il tuo progetto è fattibile in termini di budget e tempi. La tua azienda può permettersi di realizzare questo progetto? La tempistica è realizzabile? Tempo e denaro sono due dei tre vincoli in un progetto Agile che sono fissi. Miriamo a consegnare entro un determinato tempo e entro un determinato budget.
• La qualità di un prodotto si riferisce al prodotto finale utilizzato dai tuoi clienti e alle pratiche ingegneristiche utilizzate dal tuo team per fornire un software eccezionale, robusto e affidabile. La qualità è anche qualcosa che non cambiamo a breve. I criteri di qualità, invece, possono cambiare. Se non hai intenzione di costruire una Ferrari, il prodotto potrebbe non avere una percezione di alta qualità. Se non stai costruendo razzi spaziali, le tolleranze raggiunte in termini di produzione potrebbero essere molto più elevate. Impostare il tono e l'aspettativa appropriati all'inizio.

Quindi ora hai confermato che il tuo sogno è più di una fantasia al cioccolato, hai deciso di testare le tue ipotesi e dimostrare alle persone che vale la pena investire in questa impresa.

Giustificazione

Ora, a seconda delle circostanze, la giustificazione arriverà in forme diverse. Ma essenzialmente, vuoi dimostrare che questo progetto soddisferà i criteri di successo dei clienti, ha una possibilità di successo, fornirà valore ed è conveniente.

• Esprimi le tue ipotesi in base alle esigenze dei tuoi clienti, quindi convalidale. La Lean Startup offre un'ottima guida per identificare e dimostrare che il tuo prodotto è necessario ai tuoi clienti e creerà valore.

• Scrivi, testa e convalida il tuo business plan. Ora questo non assomiglia per niente a quelli che la tua banca o il tuo specialista in affari e finanza ti hanno detto di produrre. Non usarli: saranno scaduti prima che l'inchiostro si asciughi. Invece, controlla il Business Model Canvas. Questo è essenzialmente un piano aziendale in forma abbreviata che mantiene la tua attenzione sulla tua proposta di valore, sui tuoi clienti, sulle entrate e sui costi. Usalo per convalidare se hai un'attività che funzionerà.

  “Ho ignorato questo consiglio una volta e ho passato molto tempo a scrivere un lungo piano aziendale tradizionale di 50 pagine. Non mi ha portato da nessuna parte. Tutte le ipotesi che avevo fatto erano infondate e tutte le proiezioni che avevo fatto non potevano essere convalidate. È stata un'esperienza dolorosa e costosa che mi ha insegnato a non farlo mai più".

• Se sei in un'azienda matura con portafogli di progetti consegnati in un ambiente complesso, potrebbe essere necessaria la modellazione finanziaria. Se devi, fallo solo dopo aver dimostrato quanto sopra.
• Una volta creato il tuo MVP, potrebbe essere opportuno creare un piano aziendale più tradizionale, ad esempio se devi cercare finanziamenti o selezionare all'interno del portafoglio della tua azienda di progetti e risorse concorrenti. Ma questo sarà un business plan basato e informato dagli strumenti utilizzati sopra. Sarà anche più leggero.
• In ogni caso, usa questi strumenti come artefatti viventi e respiratori. Usali come guida e campanile. Non sono mai statici. Consultali e rivedili man mano che il tuo progetto o la tua attività si evolve.

Una volta che avrai la tua giustificazione e tutti i tuoi stakeholder saranno a bordo, andrai a fuoco.

La fase di fattibilità viene in genere eseguita una volta nella vita del progetto. Potresti scoprire di rivedere la visione e la fattibilità del progetto, soprattutto se i tuoi dati, clienti, mercato o attività lo indicano. Per lo meno, saranno le tue luci guida per tutto il tempo.

Iniziazione

Stupendo. La decisione è stata presa, il progetto ha il via libera e sei pronto per costruire. Bene, quasi. So che stai pensando: "Dai già, davvero? Se non lo facciamo ora non lo faremo mai. Portiamo questo spettacolo on the road!” Ma considera questo: Agile non è altro che fornire valore in anticipo e spesso, deliziando i tuoi clienti lungo il percorso. Prendersi del tempo per capire il modo migliore per realizzare il tuo progetto è la migliore base per il successo.

Il gruppo

Nello sport, pensando al tuo gioco di squadra preferito, sarai in grado di riconoscere i ruoli chiave che consentono alla squadra di esibirsi come loro. Tradizionalmente, troverai un allenatore, un capitano e il resto della squadra. Oltre a ciò, troverai allenatori, fisioterapisti, nutrizionisti e un assortimento di personale di supporto. Ma se guardiamo al gioco del rugby, c'è una squadra nella squadra: i giocatori che compongono la mischia. Questo pacchetto è composto da giocatori designati il ​​cui compito è riconquistare la palla e continuare a giocare. Quando è in gioco una mischia, i giocatori di ciascuna parte lavorano, senza un leader, come una singola unità nel modo più collaborativo, comunicativo ed efficiente possibile per riportare la palla in possesso. È il gioco del rugby che ha ispirato Jeff Sutherland a chiamare "Scrum" la sua metodologia di sviluppo software.

• Scrum non è l'unico metodo di sviluppo software nel playbook Agile. Ma è quello che meglio descrive il concetto e i comportamenti Agile di lavorare come una squadra, motivare gli individui, creare relazioni di fiducia, auto-organizzazione, leadership di servizio, comunicazione, trasparenza e collaborazione.
• Il tuo team sarà formato in gran parte dalle circostanze in cui ti trovi. Potresti avere sviluppatori a tua disposizione. Alcuni, nessuno o tutti potrebbero avere familiarità con Agile in vari gradi. Potresti voler assumere una nuova squadra o collaborare con una terza parte.
• Saranno richiesti anche altri ruoli, ma di quelli ne parleremo più avanti.
• È stato detto che se costituisci il tuo team di sviluppo, allora hai scelto la tua tecnologia. A seconda di dove riunisci la tua squadra, arriveranno con competenze specifiche. Quindi, pensa attentamente a come formare il tuo team di sviluppo e se è necessario eseguire una valutazione tecnica prima di arrivare a questo punto del tuo viaggio.
• Questo ci porta a team interfunzionali. I team funzionano meglio quando lavorano insieme, quando le persone si impegnano a portare a termine il lavoro indipendentemente dal loro titolo. Cerca di costruire una squadra che sia autosufficiente e individui che assumano più di un ruolo.
• Costruisci un ambiente, una cultura e un centro relazionale, un luogo in cui il team può lavorare, libero da vincoli o restrizioni. Fornisci al team gli strumenti, le persone, le risorse e lo spazio per essere efficace e performante.
• Mantieni le dimensioni della squadra a non più di sette o otto. Se hai bisogno di molti più sviluppatori, dividi il team in più nuovi team. Ogni squadra potrebbe quindi essere responsabile di una determinata area funzionale. Se hai più team in più posizioni, considera di tenere uno Scrum of Scrums. E dove questi sono numerosi in ambienti complessi, usa la gestione dei progetti Agile.
• Assicurati che il team, l'azienda, le parti interessate e persino i clienti abbiano accesso l'uno all'altro. Assicurati che comunichino e collaborino e rimuovi tutto ciò che ostacola il progresso. La comunicazione quotidiana è la migliore cura per i disturbi del progetto. Quando le persone parlano, fanno le cose.

Ci sono molti modi in cui un team può essere messo insieme per fornire software.

Riassunto del progetto

Nella fase di fattibilità, hai capito il "perché" del tuo progetto e hai costruito la tua fiducia per andare avanti con la tua startup o hai ottenuto il sostegno per procedere. Il brief del progetto è il documento vivo che unisce il “perché” con il “cosa” e il “quando” e il “chi”. È "vivere" perché, man mano che avanzi, la tua conoscenza, comprensione e percorso possono cambiare. Lasciare questo documento una volta scritto e non tornarci mai più consegna semplicemente i tuoi pensieri a un punto nel tempo. In un mondo Agile, il tuo riferimento temporale può cambiare settimanalmente o addirittura giornalmente all'inizio, quindi è importante mantenerlo aggiornato.

• Un ottimo strumento per racchiudere e mantenere il brief del tuo progetto è qualcosa che Jonathan Rasmusson chiama il "mazzo iniziale" nel suo libro The Agile Samurai . Qui troverai ottimi consigli per assicurarti che tutti coloro che sono interessati, interessati o coinvolti nel tuo progetto siano sulla stessa pagina.
• Il più grande nemico della realizzazione dei progetti è avere una comprensione poco chiara, incoerente o semplicemente diversa di cosa sia il progetto e quali "requisiti" debbano essere soddisfatti. Se anche un importante stakeholder ha una diversa comprensione o visione di ciò che stai facendo, le conseguenze possono essere sostanziali.
• Un buon brief di progetto comunica:
  1. Un'aspettativa comune e concordata tra le parti interessate e i membri del team.
  2. Una comprensione del progetto, con la stessa comprensione tra tutte le parti.
  3. L'obiettivo, la visione, l'obiettivo, l'ambito e il contesto del progetto.
• Avrai molte buone informazioni per il brief raccolte dalla fattibilità. Il brief del progetto ti aiuterà a definire e trovare le risposte alle domande di ricerca. Riunirà le parti interessate, la tua ragion d'essere , l'ambito di alto livello, i rischi, la soluzione target, il budget, la tempistica, le aspettative e le priorità.

Un collega una volta mi ha fermato in un corridoio e mi ha chiesto dove poteva trovare il brief del progetto per il progetto. Ho scherzato "Non abbiamo bisogno di un brief, siamo Agile". Sembrava confuso, come se stesse mettendo in dubbio la mia sanità mentale o autorità. Aveva ragione a farlo.

Prima di procedere, assicurati di avere tutti sulla stessa pagina, elaboralo, poni le domande difficili e inchiodalo in un punto in cui le persone possono fermarsi, leggerlo, commentarlo e aiutarlo a rivederlo.

Cultura e modi di lavorare

Conosci il modo in cui funziona la tua azienda e la sua cultura, il modo in cui le piace portare a termine le cose. Agile, per sua stessa natura, può mettere in discussione alcuni di questi modi di lavorare che la tua azienda ha coltivato negli anni. Non aspettarti che Agile venga implementato e che tutti lo adottino amorevolmente fin dall'inizio. Alcune persone potrebbero trovarlo confuso e vederlo solo con timore e paura. Alcune persone potrebbero rifiutarsi apertamente di impegnarsi in esso. Queste sono sfide e percezioni che devi superare. Ma nei tuoi primi giorni, non andare in giro ad agitare il bastone Agile picchiando chiunque non lo ascolti. Ciò non creerà fiducia, adozione o coinvolgimento.

Ero un fan di sventolare grandi bastoni proverbiali una volta, e mi è valso molta stampa negativa. L'ho girato, ma non prima di aver subito un dolore considerevole.

Mentre intraprendi il tuo percorso di adozione, procedi con cautela, rispetto e empatia. Se sei in un'azienda tradizionale e scricchiolante, forse non sarà l'approccio migliore per allineare l'intera azienda. Inizia in piccolo e guadagna in modo incrementale rispetto e riconoscimento. Inizia solo con la tua squadra. Una volta che inizi a fornire un software più veloce con una qualità migliore che mai, le persone inizieranno a notarlo e vorranno venire a giocare al tuo gioco. Quando lo fanno, offri loro la palla, portali fuori per un caffè e portali nel tuo nuovo mondo. Aiutali.

Con il tuo team, ora che sa di cosa tratta il progetto e che i tuoi piani per l'adozione Agile sono stati concordati, lascia che il team decida come desidera comportarsi e operare come una squadra.

• Guida il tuo team a identificare i concetti, le tecniche, i comportamenti e i framework Agile che ritieni adatti alle tue esigenze collettive.
• Accetta le richieste dei membri del tuo team in merito ai requisiti che hanno per aiutarli a funzionare al meglio. Alcune di queste richieste le potrai risolvere immediatamente. Altri, potresti aver bisogno di un budget o di un aiuto esterno. Fai quello che puoi per realizzarlo.
• Questi sono i tuoi primi passi per diventare un vero servo-leader.
• Prendi in considerazione l'idea di organizzare una formazione adeguata sui concetti e sulle tecniche che il tuo team decide di adottare. Questo è il modo migliore per garantire che tutti i membri del tuo team, anche le parti interessate, siano sulla stessa pagina e ricevano lo stesso messaggio. Collabora con un'organizzazione di fornitori in grado di adattare la propria offerta alle tue esigenze.
• Sii prudente. Nessuno sarà un ninja Agile dopo alcuni giorni in un workshop che imparerà a diventare Agile. Il tuo percorso sarà lungo. La parola "diventare" è abbastanza definita. Solo quando abbraccerai veramente Agile ne vedrai il valore. Dovrebbe eccitarti. Se ti eccita, allora vai a eccitare anche gli altri.
• Ora che il tuo team ha concordato i concetti e le tecniche, ha soddisfatto i suoi desideri e si trova in formazione Agile, rivolgi l'attenzione del tuo team su se stesso e su ciò che si aspetta da te, dall'azienda e l'uno dall'altro.
• Definire alcuni modi di lavorare (WoW) all'interno e tramite il team aiuta a creare fiducia, relazioni e aspettative. Il WoW non è Guerra e Pace . Dovrebbe essere breve e al punto, tra sette e dieci frasi puntate. Queste frasi indicano chiaramente come le persone si comportano, comunicano, collaborano, supportano, forniscono e si esibiscono insieme. Dovrebbe anche indicare cosa si aspetta il team dall'azienda.

• Agile è tanto una mentalità quanto principi e concetti guida. Ti aiuta a sviluppare il modo in cui ti comporti, pensi, negozia, interagisci, comunichi, esegui e migliori. Si basa su individui motivati ​​che si sostengono a vicenda per raggiungere un obiettivo comune, insieme come uno. C'è un proverbio africano:

A questo punto, la tua squadra dovrebbe essere super eccitata, piena di energia e motivata. Ora, coinvolgili ulteriormente con il tuo backlog di storie degli utenti.

arretrato

Non avere dubbi nella tua mente che c'è incertezza coinvolta nel tuo progetto. Non puoi assolutamente sapere esattamente cosa ci vorrà per costruire il prodotto giusto per i tuoi clienti così presto nella sua vita. Non puoi guardare malinconicamente in una sfera di cristallo e prevedere il futuro.

Il "backlog" o "product backlog" è il luogo in cui risiedono le tue esigenze. Agile predilige la scrittura di affermazioni brevi e concise che catturano l'essenza di un "requisito". Il backlog è semplicemente un lungo elenco di voci, ciascuna voce che definisce un singolo e discreto “requisito” come una user story. E d'ora in poi, useremo la parola storia dell'utente e non "requisito". Probabilmente stai chiedendo "perché?" Questa è una buona domanda. Per quello che sembra un'eternità, dichiarare le caratteristiche o le sfaccettature necessarie in un progetto software da parte di un cliente è sempre stato definito un requisito. Quella parola ha un'interpretazione che non ha valore in Agile. Il dizionario di Oxford lo definisce come:

Una cosa che è necessaria o desiderata. Oppure, una cosa che è obbligatoria; una condizione necessaria.

E sfortunatamente, se ci impegniamo a definire quale dovrebbe essere la nostra soluzione, affermando che le cose sono "obbligatori", finiremo nei guai. È troppo facile dire che tutte queste user story siano obbligatorie. Se prendiamo questo punto di vista, corriamo il rischio di andare oltre la pianificazione e il budget nel tentativo di fornire tutto un determinato ambito. Non è un problema dire che, per questo prodotto queste storie sono necessarie affinché la soluzione sia praticabile, vogliamo solo evitare l'interpretazione di quella particolare parola.

• Scrivi sempre storie dal punto di vista di una persona. Una persona rappresenta un utente o uno stakeholder della soluzione. È una buona idea sviluppare queste personalità prima di iniziare un backlog.
• In questa fase, scrivi solo affermazioni brevi e semplici che fondamentalmente suggeriscono un promemoria per avere una conversazione più approfondita sulla storia dell'utente quando è il momento giusto.
• Le persone reali pensano in termini di compiti che devono svolgere per raggiungere un obiettivo. Scrivi le tue storie dal punto di vista della persona e in termini di ciò di cui hanno bisogno per fare.
• Non è necessario scrivere l'intero arretrato: scrivi solo quanto puoi immaginare i tuoi clienti avranno bisogno per rendere fattibile il tuo prodotto.
• Scoprirai più avanti nel corso della vita del prodotto che le storie degli utenti cambieranno, diventeranno più o meno importanti o potranno essere cancellate completamente. Rilasciare spesso, ricevere feedback e valutare quale sia una priorità informerà questo comportamento.
• Non scrivere storie in isolamento. Coinvolgi il tuo team, le parti interessate e persino i tuoi clienti. Le storie possono essere aggiornate in qualsiasi momento nella vita di un progetto, ma dovrebbero evitare di essere modificate una volta iniziato il lavoro di sviluppo su di esse.
• Alcune delle tue storie possono essere considerate "epiche". Queste sono storie grandi che coprono molto e saranno suddivise più vicino al momento della consegna in storie più piccole.
• Prendi in considerazione l'utilizzo del modello INVEST, una lista di controllo per convalidare la qualità di una buona user story.
• Chiunque può aggiungere una storia al backlog. Dovrebbe essere posizionato in basso, o in un "parcheggio" appositamente creato. Questa storia aggiunta serve come spunto per discutere con il team e l'azienda. Se l'azienda e il team lo supportano, è possibile stimarlo e assegnare priorità
• Puoi anche considerare quelle parti del sistema che sono più rischiose. Se disponi di una user story o di una funzionalità complessa, nuova o tecnicamente sconosciuta, dai la priorità all'inizio del tuo backlog. In questo modo, non tenterai di fornire le parti difficili e critiche del tuo prodotto poche settimane prima del tuo primo rilascio.

Una volta che hai un backlog che soddisfa le tue esigenze, puoi stimare le storie in esso contenute, classificarle in ordine di priorità e costruire un piano di rilascio.

Stima e prioritizzazione di alto livello

La stima di alto livello è il processo di dimensionamento del tuo backlog. Quanto è “grande” il progetto e quale valore offre? La definizione delle priorità è il processo per decidere quali storie sono più importanti per te, la fattibilità del prodotto e gli interessi dei tuoi clienti. Vogliamo consegnare prima gli articoli di valore più alto per offrire il massimo valore all'azienda, ottenere feedback dal cliente e non sudare per le piccole cose. L'output sarà un arretrato ordinato che è classificato in base alla priorità e dimensionato in modo appropriato.

• Le storie in cima sono considerate le più preziose. Vogliamo consegnare gli articoli più preziosi il prima possibile.
• Esistono molte tecniche per il dimensionamento e la stima, ma a questo punto vuoi solo avere una buona sensazione indicativa delle dimensioni di una storia.
  • Usa le taglie delle magliette, le taglie relative, i giorni ideali o i punti della storia.
• Non avrai nemmeno tutte le informazioni disponibili a questo punto, e va bene. Corri con esso.
• Coinvolgi i tuoi stakeholder aziendali o il product manager, se ne hai uno, e il team che svolgerà il lavoro.
• Vogliamo che coloro che progetteranno, svilupperanno e testeranno il lavoro per dimensionarlo, perché le persone migliori da valutare sono gli esperti.
• Il team potrebbe iniziare a scomporre le storie in parti più piccole. Se ciò accade, scrivi storie più granulari ma discrete.
• Il team potrebbe anche iniziare a classificare alcune storie, poiché naturalmente alcune cose devono essere consegnate prima di altre per supportare la tecnologia o un determinato percorso dell'utente.
• Tra te e il team, potresti anche iniziare a trovare dei buchi nell'arretrato che devono essere riempiti. Basta riempire quei buchi con nuove storie e stimare e assegnare le priorità a seconda dei casi.
• La definizione delle priorità viene eseguita più facilmente utilizzando un'analisi MoSCoW. MoSCoW è una tecnica semplice che ti aiuta a decidere quali storie sono "must have" per il successo del tuo prodotto.
• È possibile eseguire un passaggio di definizione delle priorità prima dell'inizio della stima. Tuttavia, il dimensionamento di alcuni elementi può anche determinare una decisione sulla priorità e sul reale valore aziendale. Quindi gioca alla stima e alla definizione delle priorità l'una rispetto all'altra, ma non litigarci!
• Non esistono due storie importanti quanto l'altra. La storia al rango 1 è più importante o preziosa della storia al rango 2.
• Un ottimo modo per dimostrare l'importanza o il valore di una storia è aggiungere un valore monetario ad essa. Se, ad esempio, si pensa che la storia A porti $ 5000 di entrate extra e la storia B potrebbe attirare $ 100, la storia A è più preziosa. Allo stesso modo, se la storia C salva l'azienda più della storia D, la storia C ha più valore.
• Dopo aver dimensionato il tuo backlog, ti verrà lasciato un numero. When we come to release planning, that number will help us understand how much can be delivered by our team within a given timeframe.

Remember that you don't need to know all your user stories up front. Also, remember that it's not necessary to deliver all of your stories before a customer sees your product. You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

Release Planning

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

Adaptive Planning

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

Story Creation

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

Sprinting

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• Lavorare con piccoli incrementi ha un enorme vantaggio. Significa che ti stai concentrando solo sull'immediato futuro della consegna e, con nuovi input, feedback e apprendimento, puoi rispondere al cambiamento entro un breve ciclo iterativo.
• All'inizio di un rilascio, esegui uno sprint 0. Ciò consente al team, all'azienda e al rilascio del tuo progetto di prepararsi e imposta la mentalità per una consegna di successo. Disegna la struttura tecnica e l'architettura di base che supporteranno le basi per il rilascio. Configura ambienti, account e strumenti. Esegui picchi per comprendere problemi difficili o sconosciuti. Elabora le storie degli utenti in vista dello sprint 1. Sprint 0 riguarda la preparazione.
• Durante un rilascio, continua a perfezionare il backlog. Man mano che capisci di più o impari qualcosa di nuovo, le tue priorità potrebbero cambiare, potrebbero svilupparsi nuovi requisiti e ciò che in precedenza ritenevi un'ottima funzionalità potrebbe essere completamente rimosso.
• Non iniziare un lavoro che non ha possibilità di essere completato entro uno sprint. Se non può, scomponilo in pezzi più piccoli. E non iniziare un nuovo lavoro quando il lavoro iniziato in precedenza non è stato completato. Non crei valore avviando molte cose che non possono essere considerate complete. Inoltre, evita il cambio di contesto. Questa è l'attività di iniziare un compito, di essere disturbato, di iniziarne un altro e, nella sua forma più problematica, di non portarlo a termine.
• Limitare la quantità di lavoro in corso dal team in qualsiasi momento. Ad esempio, se hai tre sviluppatori e un tester, puoi impostare un limite WIP per gli sviluppatori e per il tester.
• Non aggiungere mai più lavoro a uno sprint dopo che è stato pianificato. Non fermare mai uno sprint a metà. Le eccezioni a questo sono:
  • Se ti sei comportato più velocemente del previsto, prendi in considerazione la possibilità di prendere la storia successiva dall'inizio dell'arretrato, purché sia ​​adeguatamente preparata.
  • Se lo sprint sta andando così male da non essere completato. Questo di solito accade solo dove c'è stata una catastrofe di qualche descrizione.
  • Se l'obiettivo dello sprint non può più essere supportato a causa dell'immediato cambiamento delle esigenze del business.
• Se annulli uno sprint, fallo con grazia, prenditi del tempo per concentrarti di nuovo e inizia un nuovo sprint come faresti con qualsiasi altro.
• Verso la fine di un rilascio, considera uno sprint di rilascio finale. Non vengono scritte nuove funzionalità, alcuni bug possono essere eliminati e possono essere fatti i preparativi per rilasciare effettivamente una nuova versione del tuo prodotto ai tuoi clienti. Questo non vuol dire che nel frattempo non sia possibile effettuare rilasci incrementali per i clienti, è solo che si tratta di un meccanismo di rilascio controllato, misurato e sostenibile.
• Alla fine di un rilascio, potresti prendere in considerazione uno sprint di una settimana. In questo sprint, potresti collaborare con il team per analizzare alcune nuove idee o scoprire una nuova tecnologia. Questi sono ottimi strumenti che avvantaggiano l'azienda e danno al team uno spazio di briefing per pensare ed essere creativo. Non è per scherzare e creerà comunque valore. Allo stesso modo, tutti hanno bisogno di una pausa. Prendersi una vacanza in questo momento aiuta a mantenere la cadenza e la velocità in buona forma quando sei a metà del rilascio.

Definizione fatta

Definire cosa significa veramente "fatto" è molto importante. Ci sono molte versioni di "fatto" nella vita del tuo progetto: cosa significa essere "fatto" con una storia, una pubblicazione o un intero progetto. Tutto si riduce a ciò che tu, il tuo team e l'azienda considererete completo e al giusto livello di qualità per soddisfare la disponibilità alla spedizione.

Per il tuo team, la definizione di una storia "completata" sarà qualcosa di simile a tutto il codice completo, sottoposto a revisione paritaria, soddisfa i criteri di accettazione definiti, unit test, UAT'ed e inviato al tuo repository di codice. Per consentire il passaggio di una storia dal designer allo sviluppatore al tester, le definizioni di "fatto" dovranno essere accettate dalla persona successiva nella catena. Il proprietario del tuo prodotto avrà aspettative su cosa significhi per loro al fine di rilasciare l'incremento del prodotto ai tuoi clienti. In ogni caso, tutti devono essere consapevoli di cosa significa “fatto” ed essere parte responsabile nel garantire che il suo significato sia soddisfatto. Definisci la tua definizione di "fatto", comunicalo, concorda su di esso ed evolvilo. Fatto fatto.

Misurazione continua

Se non puoi misurarlo, non puoi gestirlo. Lo stesso vale per i miglioramenti. La necessità di raccogliere dati empirici in un progetto Agile è vitale quasi quanto il flusso sanguigno nelle vene! Come fai a sapere cosa deve essere gestito, corretto o migliorato se non ci sono dati? Bene, in parole povere, farai affidamento sulla sensazione viscerale e su congetture infondate, che crollano abbastanza rapidamente sotto esame. E a seconda di chi sta facendo il controllo, questo può essere un posto piuttosto scomodo dove stare. Quindi, fin dall'inizio del tuo progetto, assicurati di sapere come dimostrerai i progressi e con quali misure gli altri vedranno il tuo successo.

Fortunatamente, Agile viene caricato con strumenti e tecniche utili. La prima cosa da fare è tornare al Manifesto Agile, digitare le seguenti parole nel tuo elaboratore di testi preferito, gonfiarle fino a 96pt, stampare e applicare al muro affinché tutti possano vederle:

Il tuo più grande potere dimostrabile nella fornitura di software è mostrarlo alle persone che lavorano, facendo ciò che dovrebbe fare. Non solo questo renderà felici i tuoi clienti, ma guadagnerà grande rispetto per il tuo team e ungerà le ruote per una maggiore adozione attraverso l'azienda.

Ecco alcuni altri strumenti:

• Lo standup quotidiano: ci sono alcune varianti di questa cerimonia, ma l'essenza è che tutti i membri del team parlino tra loro faccia a faccia: mantienilo breve, mantienilo concentrato e mantienilo leggero. Se qualcosa ha bisogno di una discussione a lungo, parcheggialo per una conversazione più lunga tra quelli necessari dopo lo standup. Se vengono sollevati impedimenti, scrivili come una storia, aggiungili al tuo arretrato e falli affrontare il prima possibile. Tutto ciò che sta ostacolando il tuo team ne rallenta i progressi e sarà dimostrabile con velocità ridotta e software che non soddisfa le aspettative.
• Velocità: è uno strumento storico. È un po' come quegli avvertimenti finanziari che ti dicono che le performance passate non sono una garanzia di performance future. Ma nel caso di Agile, speriamo di raggiungere una velocità di squadra che sia in gran parte fluida. È la velocità che ci permette di proiettare le prestazioni future e la fiducia nei nostri piani. Potrebbero esserci influenze al di fuori del tuo controllo che potrebbero ridurre il numero di story point prodotti per un determinato sprint. Se ciò accade, probabilmente sarai in grado di recuperare. Non usare mai la velocità come un bastone con cui battere la tua squadra; non ti farà guadagnare favori. Una cosa certa è che la velocità sarà irregolare per i primi 2–4 sprint. Da qualche parte in quel lasso di tempo, tuttavia, dovresti iniziare a vedere coerenza e stabilità. Se la tua velocità oscilla da un estremo all'altro, hai un problema che dovrai risolvere con la tua squadra.
• Il diagramma di burndown: ora questa misura del progresso è spinosa. Per questo motivo, non ho fornito un link per saperne di più: dovrai fare le tue ricerche e concordare come una squadra e un'azienda che lavora per te. Il motivo per cui è spinoso? Beh, nessuna risorsa là fuori racconta la stessa storia! Una cosa concordata è che mostrerà, all'interno di uno sprint o di un rilascio, come ti stai comportando rispetto al tuo timebox. Se mantenuto quotidianamente, mostrerà se sei sulla buona strada o deviando. Alcuni team lo usano per rappresentare quanto valore è rimasto da creare, il più delle volte, altri lo usano per mostrare quanto lavoro è rimasto da completare. Il primo è una celebrazione del successo e della generazione di valore, il secondo è meno stimolante e motivante.
• Il grafico di burnup: se devi mostrare i tassi di completamento del lavoro, utilizza il grafico di burndown per quello. Ma l'utilizzo del diagramma di burnup ti consente di mostrare quanto valore è stato creato e quanto più valore intendi creare entro la fine dello sprint. Uno strumento molto più motivante per un team per dimostrare all'azienda cosa è stato fatto (o poco se le cose non stanno andando così bene...) e su cosa hanno ancora gli occhi puntati. In ogni caso, usa i grafici per individuare dove i progressi non vengono tracciati come previsto e cerca schemi o deviazioni e superali per risolvere il problema sottostante il prima possibile. Aggiornali quotidianamente per gli sprint e una volta alla fine di uno sprint per i grafici delle versioni di rilascio.
• Tabelloni delle attività: questi sono ottimi radiatori visivi per dimostrare il valore che viene creato. Quando vengono aggiornati quotidianamente, o in qualsiasi momento della giornata, mostrano immediatamente i progressi compiuti. Se combinati con Kanban, sono anche ottimi strumenti per visualizzare il flusso e i blocchi nel sistema. Se puoi vedere che molto sviluppo è stato completato, ma i test non sono così produttivi, puoi vedere il problema che si verifica e rispondere in modo appropriato e rapido.

Altri strumenti da considerare sono il valore guadagnato Agile, il tempo di ciclo e i diagrammi di flusso cumulativi (CFD).

Tieni queste misure, grafici e altri strumenti visibili, preferibilmente ad alta voce e con orgoglio su un muro affinché tutti possano vederli. Il team, le parti interessate e le altre parti interessate possono vedere immediatamente lo stato di un progetto. È trasparente e funge da prezioso strumento di comunicazione. Se non puoi mettere questi artefatti su un muro, usa strumenti condivisibili e collaborativi e assicurati che quelli che vogliono accedervi li abbiano.

Miglioramento continuo

Durante la tua vita Agile, cerca di identificare e imparare dove è possibile apportare miglioramenti. Le lezioni non vengono acquisite e apprese alla fine di un progetto. È come superare l'esame di guida e fare provvisoriamente il primo giro senza un istruttore. Saprai cosa funziona e cosa dovresti fare, ma col tempo adatterai le tue abilità e capacità di guida, imparando nuove tecniche. Prenderai anche cattive abitudini. Cercali, comprendili e trova modi per migliorare.

Ci sono molte opportunità per identificare ciò che non funziona e applicare i rimedi. L'approccio integrato a questo in Agile è la retrospettiva. Questo è lo strumento principale per la riflessione e l'adattamento. Alla fine di ogni sprint, prenditi del tempo con il team per migliorare il modo in cui viene svolto il lavoro, come viene fornita la qualità, come è possibile massimizzare l'efficienza, come ridurre al minimo gli sprechi e come aumentare la capacità. Quando identifichi le misure per il miglioramento, non essere tentato di risolvere immediatamente tutti i tuoi problemi. Identifica quelli che avranno il maggior impatto e possono essere implementati nel prossimo sprint. Misura e osserva. Se ha avuto l'impatto desiderato, bloccalo, scrivilo nei tuoi modi di lavorare e nelle definizioni di fatto. Se non funziona, ripensaci. Qualsiasi lezione appresa che non viene inserita nello sprint imminente può essere parcheggiata e assegnata la priorità all'attenzione nello sprint successivo.

Personalizza il processo. Rimuovere tutto ciò che non funziona. Rimuovere gli impedimenti. La tua maturità come team Agile non conoscerà limiti se glielo permetterai.

Oltre la gestione agile del progetto

È importante sapere cosa succede dopo la consegna del progetto. Il supporto e la manutenzione sono fondamentali per garantire che, una volta che il progetto è nelle mani dei clienti, rimanga performante; il feedback dei clienti può essere preso in considerazione nelle versioni future; e i problemi dei clienti vengono affrontati in modo appropriato. Un progetto è uno sforzo unico e limitato nel tempo. Il prodotto che offre ha una vita dopo che il team di progetto è stato sciolto. Assicurati di essere in grado di supportare il prodotto una volta che è attivo.

I progetti agili coesistono con approcci più tradizionali. Bilanciare i requisiti per il controllo di bilancio e la visibilità degli stakeholder con gli obiettivi Agile di flessibilità e reattività.

Un framework di governance o un modello di governance Agile viene utilizzato insieme a processi Agile standard, come Scrum. Funzionano in due modi specifici:

• Forniscono un wrapper per un progetto Agile chiarendo i processi che si verificano al di fuori delle iterazioni di sviluppo (sprint). Ciò include la fornitura di criteri chiari per il completamento con successo dell'avvio del progetto e la corretta convalida delle decisioni e del piano.
• Spostano l'enfasi su parti specifiche del processo Agile standard ed evidenziano principi e tecniche particolari che necessitano di governance o supportano la governance.

Nel mondo in continua evoluzione di oggi, le organizzazioni e le aziende desiderano adottare un approccio più flessibile alla realizzazione dei progetti e vogliono diventare più agili. Tuttavia, per le organizzazioni che realizzano progetti e programmi e laddove esistono già processi formali di gestione dei progetti esistenti, l'informalità di molti degli approcci Agile è scoraggiante e talvolta è percepita come troppo rischiosa. Queste organizzazioni incentrate sui progetti necessitano di un approccio agile maturo, agilità all'interno del concetto di consegna del progetto, gestione del progetto agile .

Impara e cresci con l'adozione di Agile. Fai sempre e solo ciò con cui il tuo team è a suo agio, assicurati che la sua voce sia ascoltata e agisci in base alle loro richieste. Incoraggia il tuo team ad adottare tecniche nuove e più preziose quando è il momento giusto. Negoziare con l'azienda e incoraggiarla a capire cosa significa essere un'organizzazione Agile.

Goditi il ​​viaggio.