#Scrum – Integrare Scrum e Agile Project Management (#AgilePM) – Perchè è utile integrare Scrum?

Scrum è un framework di prodotto e, nella sua semplicità, molto difficile da applicare. In generale, se essere Agili è una questione di buon senso, come indica Steve Messenger, Chairman del DSDM Consortium, spesso “non usiamo il buon senso quando siamo agili”. In questo senso uno dei grandi problemi di Agile è quello di sviluppare un prodotto con Agilità quando il resto dell’organizzazione non è Agile o comunque dove le varie funzioni di business e di supporto invece sono strutturate per un contesto più tradizionale o waterfall. In questo scenario l’utilizzo di Scrum senza integrazione non è solo difficile, ma spesso può comportare problemi. Pertanto è possibile utilizzare l’Agile Project Framework e l’Agile Project Management in combinazione con Scrum per ottenere il massimo da entrambi i framework a supportare l’integrazione di un mindset Agile.

dt050324 Continue reading

#Scrum – Integrare Scrum e Agile Project Management (#AgilePM) – I ruoli di Scrum

Scrum prevede l’utilizzo di tre ruoli che compongono lo Scrum Team. Il Product Owner, il Team di Sviluppo (o Development Team, in inglese) e lo Scrum Master. E’ cruciale che questi tre ruoli collaborino tra loro. Uno Scrum Team efficace è un team che si auto-organizza e cross-funzionale. Quindi un team che in autonomia definisce come meglio svolgere il lavoro considerando che il team ha anche tutte le competenze per poter sviluppare il prodotto, il fatto di essere cross-funzionale.

dt100404_scrum_team

Continue reading

#Scrum – Integrare Scrum e Agile Project Management (#AgilePM) – L’eleganza del processo di Scrum

Nel Manifesto Agile è scritto che sono più importanti gli individui e le interazioni più che i processi e gli strumenti. Questo non non vuol dire che strumenti e processi siano inutili, come specifica l’ultima frase del Manifesto, ma che non gli deve essere data un’enfasi eccessiva. Pertanto i processi dovrebbero essere leggeri e servire come traccia e guida, più che come un’asettica lista di cose da fare. Come ben descritto da Andrew Craddock, il processo di Scrum è semplice ed elegante e può essere sintetizzato come segue

dt900406dhc0_scrum_agilepm_process

Il processo di Scrum

  • Il Product Owner definisce una lista ordinata di requisiti in relazione al prodotto da sviluppare. Questa lista è contenuta nel Product Backlog, un artefatto – prodotto di gestione – che cambia nel tempo secondo le necessità del business e man mano che viene sviluppato il prodotto.
  • Lo Scrum Team utilizza la sua conoscenza, esperienza – dopotutto siamo in un contesto empirico – e la comprensione sul prodotto per accordarsi di quanti e quali requisiti, partendo da quelli all’inizio della lista, saranno sviluppati in un frangente temporale pre-fissato – quindi una Timebox – chiamato appunto Sprint. Pertanto nell’evento – o cerimonia – che chiameremo Sprint Planning gli elementi selezionati saranno inseriti nello Sprint Backlog e sarà definito un obiettivo della Timebox, chiamato lo Sprint Goal. Ovviamente gli elementi all’interno dello Sprint Backlog saranno ad un livello di granularità differente e potrebbe essere necessario raffinarli man mano.
  • Quindi, durante lo Sprint, lo Scrum Team si incontra ogni giorno durante il Daily Scrum – un evento di 15 minuti (altra Timebox) per sincronizzarsi e creare un piano per la giornata – quindi di 24 ore. Nel Daily Scrum si verifica inoltre quanto sviluppato dopo l’ultimo Daily Scrum e si identificano eventuali problematiche che bloccano il raggungimento dello Spring Goal così da poterlo gestire. Dopo il Daily Scrum il Team lavora come d’accordo.
  • Alla fine dello Sprint viene eseguito lo Sprint Review meeting dove si verifica e accetta quanto prodotto e si fa la Sprint Retrospective, un momento in cui il Team riflette sull’efficacia del metodo di lavoro e si accorda su come migliorare quanto necessario per lo Sprnt successivo.
  • Quindi il processo viene ripetuto fino a che il prodotto non soddisfa tutti i requisiti, non si finisce il budget o fino a che il Product Owner non decide che non è più necessario procedere. Per tutta la durata dello sviluppo, lo Scrum Master supporta il Team ad essere focalizzato in diversi modi, per esempio facendo il Coach e/o il Facilitatore.

#Scrum – Integrare Scrum e Agile Project Management (#AgilePM) – Introduzione a Scrum e all’integrazione

Scrum è un framework empirico e adattivo per sviluppare prodotti nato in ambito software che si pone lo scopo di rialasciare del valore in modo efficace. Il framework si basa sulla Guida a Scrum (in inglese, Scrum Guide). Un breve testo – di 17 pagine per quel che riguarda la traduzione in italiano – che descrive i ruoli, gli eventi e gli artefatti – che in PRINCE2® chiamiamo prodotti di gestione – e come si legano questi elementi attraverso una serie di regole. Come da definizione, Scrum è un framework empirico, pertanto la conoscenza si basa sull’esperienza. L’esperienza si ottiene attraverso una approccio iterativo e incrementale – come accade spesso per Agile – adattandosi in maniera continua.

dt100611_scrum_agilepm_integration

Continue reading

#AgilePgM: Agile Programme Management – Parte 12 – La fase di Programme Close

La fase di Programme Close di Agile Programme Management si attiva quando, dopo le opportune retrospettive, ci si rende conto che è conveniente chiudere il Programma sia perchè oramai le capability sono state sviluppate come era stato previsto sia perchè  i cambiamenti nel contesto di business hanno portato alla decisione di una chiusura inizialmente non prevista. Anche in questo secondo caso non vuol dire che il programma sia necessariamente stato un fallimento ma che, in un contesto Agile, si può decidere di terminare prima del previsto in quanto potrebbe essere anche conveniente da un punto di vista di profitti.

dt120201_closure

Continue reading

#AgilePgM: Agile Programme Management – Parte 11 – La fase di Benefits Management

La fase di Benefits Management di Agile Programme Management si attiva quando sono stati definiti i benefici da ottenere tramite le capability e serve per assicurarsi che i benefici vengano realizzati quanto prima e come previsto nel programma. Il ciclo di vita dei benefici è:

  • Programme Fasibility: i benfici sono definiti e prioritizzati.
  • Programme Foundations: i benfici sono revisionati e messi in baseline.
  • Capability Evolution: i benefici realizzati.
  • Tranche Review: i benefici revisionati ed eventualmente modificati, considerando il concetto di agilità.
  • Programme Cose: i benefici vengono revisionati e, se alcuni saranno realizzati dopo la chiusura del programma, si pianifica la gestione futura dei benefici.

dt920512dhc0_benefits

Continue reading

#AgilePgM: Agile Programme Management – Parte 10 – La fase di Tranche Review

La fase di Tranche Review di Agile Programme Management si attiva quando sono state abilitate abbastanza capability nella fase di Capability Evolution  per revisionare la redditività, attuabilià e vivibilità del Programma e quindi comprendere se sia il caso di cambiare i piani già stabiliti o da quanto definito nella Programme Foundations. Se sono presenti Tranche sovrapposte e interdipendenti tra loro e si rendono necessari dei cambiamenti – in pieno approggio agile – che impattano anche le altre Tranches, è fondamentale revisionare anche le Tranche impattate.

dt_c110606

Continue reading

#AgilePgM: Agile Programme Management – Parte 9 – Il processo di Capability Enablement

All’interno della fase di Capability Evolution in Agile Programme Management sono presenti due processi che – attraverso una serie di iterazioni in parallelo – si completano l’un l’altro e fanno evolvere la capability, cioè l’abilità o la capacità dell’organizzazione di rilasciare i benefici che si ottiene attraverso processi di business, persone, asset fisici e informazioni.

dt131024_capability

Continue reading

#AgilePgM: Agile Programme Management – Parte 8 – La fase di Capability Evolution

La fase di Capability Evolution è quella centrale del ciclo di vita di Agile Programme Management. E’ una fase iterativa e incrementale nella quale si sviluppano le varie capability fino a quando non diventano parte integrante dell’organizzazione. In questa fase è bene che le varie capability siano rese disponibili al più presto possibile così da ottenere quanto prima i prodotti (output) correlati. Dato l’approccio iterativo e incrementale si parla di evoluzione delle capability e non solo di “sviluppo”.

dt920208dhc0_evolution

Continue reading

#AgilePgM: Agile Programme Management – Parte 7 – La fase di Programme Foundations

Agile Programme Management prevede la fase di Programme Foundations nella quale si preparano delle solide fondamenta per il Programma.  E’ in questa fase che si gestiscono questioni come la vision, la progettazione e l’archittettura del programma, la governance e la comunicazione. Relativamente alla pianificazione, essendo in un contesto Agile, si pianifica in dettaglio solamente la prima trance, considerando che il feedback ottenuto dalla prima trance sarà usato per le future pianificazioni.

dt100930_change

Continue reading