Posts tagged: iterations

Scrum Simulation Game – The Product Box

A new amazing SCRUM simulation, inspired from both the brochure game and Sanjiv Augustine book ‘Managing Agile Projects’

In a previous post ‘SCRUM Simulation, the Resort Brochure Collaborative Game‘ I described a possible SCRUM simulation playing the Brochure Game collaborative game.
During my last class I used a variation of that collaborative game, taking suggestions from Sanjiv’s book and arranging better the timing of that simulation.

The main scope of the game is to create a Product Box of a hypothetical software product, using SCRUM and its rules, roles and ceremonies.
First of all, form groups of no more than six people.
You, the coach or the trainer, are the sponsor of the software that must be created. Initially you held a short briefing of the software the company is going to create.
What I choose is the creation of a social network application completely dedicated to marathon athletes and their coaches.
My explanation was something like this.

 

The athletes should be able to create their profiles inserting general and physiological data, information regarding their training session plans, the results attained to the races they run.
The coaches, after the profile creation, should be able to ask the friendship to the athletes they train and create plans, verify results achieved, inspecting on improvement area and suggesting new actions and tasks.
This new software should be compliant and integrable with the most important social networks.

 

Then, the teams were asked initially, to imagine and visualize the product box of that software and to think about an attractive elevator pitch.

 

A five minute speech was enough.

 

I asked each team to choose one person to be the product owner.
Then, some magazines with amazing pictures and drawings were supplied, together with scissors, rulers, glues, cardboards, coloured markers paper masking tape.

 

I asked the teams to start thinking about how to use that material to realize what they thought about the product box and the elevator pitch.

 

In the meanwhile, in another room, I met the product owners, explaining to them better my idea about the product and what really was important about it in order to give them some more information about the stories they should create, having some more details o how to prioritize them.

 

Then the simulation started following this timetable.

Preparation

  • 5 minutes: room preparation
  • 5 minutes: information about the product and seleciton of product owners
  • 5 minutes: briefing with POs
  • 5/10 minutes: writing user stories and prioritization

Iterations

Three iterations as follows:

  • 2 minutes: Daily/Planning Meeting
  • 5 minutes: Sprint
  • 2 minutes: Demo Meeting
  • 1 minute: Retrospective

When finished we had a 10 minutes debriefing.

SCRUM & Large Projects

Come conciliare SCRUM e grossi progetti?


Questo post è disponibile ai soli utenti registrati. La registrazione è libera.

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.


Sensibilità, agilità, qualità

Uno dei libri più interessanti che ho letto ultimamente è “Coaching e Leadership” di A. Deering, R. Dilts e J. Russel edito da NLPItaly.
L’opera è il risultato di anni di attività di consulenza e di coaching dei tre autori, svolte su businessman di alto livello in tutto il mondo.

Il libro raccoglie teorie, pareri, punti di vista, tecniche e suggerimenti, che possono essere di grande aiuto ai manager aziendali (e i project manager fanno parte di quella categoria) a muoversi e agire al meglio nei mercati e nelle aziende odierne.

In questo post ne evidenzio alcuni aspetti, ponendo il focus su come i prodotti e i servizi che i progetti rilasciano in produzione possano posizionarsi con successo sul mercato.


I review e i phase-out meeting, a mio avviso, sono tra le riunioni più importanti che si possano svolgere durante l’esecuzione di un progetto.
In questa sede, infatti, si valutano i risultati della fase o del progetto appena conclusi, valutandone non solo i riscontri economici e di profittabilità, ma verificando che i requisiti e gli obiettivi pianificati siano stati pienamente soddisfatti e raggiunti.

Nella mia esperienza quotidiana, riscontro sempre più spesso che l’aspetto della profittabilità economica dei singoli progetti, è quella che viene maggiormente soddisfatta, seppur con un trend al ribasso negli ultimi due anni, a seguito della crisi in atto e della conseguente riduzione dei margini.

Altrettanto frequentemente in quella sede, si riscontrano dati meno incoraggianti rispetto all’effettiva messa in produzione e utilizzo del prodotto realizzato.
Analizzando questi casi ci si imbatte quasi sempre in due fattori.

Il primo riguarda la mancanza di feedback del committente, sulle funzionalità e sull’usabilità dei diversi prototipi rilasciati durante lo sviluppo del progetto.
Questo pone l’agenzia che ha in carico il lavoro, nella condizione di dover continuare l’esecuzione del progetto a fronte di un “ok alla cieca” della deliverable appena rilasciata.
Condizione quella che porterà inevitabilmente a fine progetto, ad avere un prodotto non centrato sulle specifiche esigenze degli utenti finali a causa delle mancanza di feedback puntuali e sistematici sul prodotto.

Il secondo punto, invece, riguarda qualcosa che non è direttamente addebitabile ad una delle due parti cliente o fornitore e ha più a che fare con la velocità con cui cambia il mercato.
Sebbene infatti il prodotto o servizio venga effettivamente rilasciato nei tempi, nei costi e con le funzionalità e la qualità richiesta, accade che le necessità da soddisfare siano nel frattempo cambiate, obbligando voi e il committente ad una drastica revisione del prodotto.

Gli autori del libro che cito in apertura, in riferimento al secondo punto, riportano un esempio molto calzante: quello della pistola e del missile teleguidato, preso in prestito dal libro “New rules for the new economy” di Kevin Kelly.

Sostengono infatti che, negli anni addietro, la velocità del mercato era molto ridotta e consentiva un ampio ciclo di vita dei prodotti che in media si attestava in qualche anno (ovviamente con le opportune distinzioni in funzione del settore di riferimento).
Quando i manager d’azienda dovevano approcciare al mercato per la ricerca di nuovi prodotti o soluzioni, avevano quindi il tempo di effettuarne uno studio particolareggiato, percepirne le necessità, progettare il prodotto e finalmente lanciarlo.
Da qui l’esempio della pistola: avevano il tempo di puntare, di mirare e di fare fuoco, con una buona probabilità di centrare l’obiettivo.

Oggi velocità, complessità e avanzamenti tecnologici hanno portato il mercato a richiedere prodotti con ottime performance, a basso costo e entro finestre temporali molto strette.
Ci viene suggerito di abbandonare l’idea di dedicare troppo tempo per un’analisi dettagliata del mercato, per la definizione di una minuziosa strategia di progettazione o di articolati piani di lancio.
Quando il vostro prodotto arriverà sul mercato sarà già obsoleto.
I tre autori ci suggeriscono di adottare: sensibilità, agilità e qualità.

Sensibilità: è necessaria ai manager di oggi per meglio capire il mercato, percepirne i segnali deboli e, condicio sine qua non, che essi siano più presenti sul cliente e comunichino di più con quelle persone che hanno più a che fare con concorrenti, fornitori e clienti.
Agilità: non sono necessarie strategie, business plan o project plan complessi o troppo articolati perché le ipotesi che vi hanno portato a definirli si scioglieranno presto come neve al sole.
E’ necessario, invece, che si sappia fare fronte ai cambiamenti in maniera tempestiva attraverso una struttura aziendale elastica e versatile (vedi L’importanza del team)
Qualità: i consumatori vogliono prodotti ottimi, che siano di facile e veloce utilizzo. Se non produrrete prodotti di qualità verranno presto abbandonati.

Ecco che finalmente si svela la seconda metafora del missile teleguidato, che potremmo riassumere così: puntate, fate fuoco e solo dopo mirate.
Il missile teleguidato una volta lanciato nella direzione opportuna, infatti, a differenza della pistola permette aggiustamenti della rotta durante la corsa dell’ordigno. Questo aumenta, di fatto, le possibilità di successo quando ci si trova di fronte ad un bersaglio in continuo movimento.

Trasponendo l’esempio nel campo del project management, siate attenti a percepire dettagliatamente le esigenze dei clienti nei diversi meeting che farete, comunicate spesso con loro, confrontatevi, fatevi presentare le persone che dovranno utilizzare il prodotto parlate con loro, intervistateli, coinvolgeteli nel progetto.

Poi, create project plan consistenti ma non ultra-dettagliati.

Concordate con il cliente uno spazio di manovra/aggiustamento del tiro durante la corsa: prevedete dei buffer (tempi o costi), decidete con il cliente diversi livelli di contigency plan per far fronte a rischi o cambi di specifiche. Fissate regole che spieghino quando e come utilizzarli.

Create sistematicamente dei prototipi del prodotto.
Siate fermi nell’”obbligare” il committente a provarli e darvi feedback: questi rappresentano l’unico mezzo che avrete per aggiustare la mira durante la corsa e centrino in pieno il vostro target.

Affidatevi ad un team fatto di persone agili; che conoscano e comprendano cosa c’è dietro all’agile project management.

Siate insomma veloci a percepire e a gestire il cambiamento.

Planning a kick-off meeting

Un buon kick-off è garanzia di successo del progetto?

 

Un paio di giorni fà, ho condotto presso un cliente il kick-off di un nuovo progetto.

Progetto non particolarmente complesso nei suoi requisiti, che però nasconde diverse insidie in quanto obbliga un’interazione e integrazione molto forti con i sistemi del cliente, vede coinvolti diversi stakeholder, alcuni dei quali fuori dall’Italia e che, infine,  impone un adattamento a standard procedurali e di documentazione in uso presso il cliente.

La fase analitica inziale che ha dato vita alle stime e all’offerta, non è stata particolarmente dettagliata; diversi erano quindi i punti aperti e i dubbi circa alcune implementazioni.

Il kick-off sarebbe stato quindi momento fondamentale per cercare di chiarire al meglio quanto era ancora sfumato, privo di contorni nitidi.

Ho voluto affrontare il tema facendo uso di una mappa mentale in cui potessi raccogliere tutte, e dico proprio tutte, le tematiche che sarei andato a discutere nel meeting.

La prima cosa che ho fatto, è stata quella di fare una review completa di tutta la documentazione a mia disposizione suddividendo le tematiche nelle seguenti categorie:

  • Open Points, in cui ho raccolto tutte le questioni non ancora chiare alle quali si sarebbe dovuto dare risposta nel kick-off
  • Functionalities, categoria nella quale ho raccolto tutte le funzionalità del prodotto, implementando rami gerarchici a raggruppare funzionalità dello stesso tipo, in stile WBS
  • References, tutti i documenti di riferimento (allegati alla mappa) che hanno dato luogo alla formalizzazione del plan di progetto
  • Systems Involved, i diversi sistemi (hardware e software) esterni coinvolti, con i quali l’applicazione dovrà dialogare
  • Application Roles, i diversi ruoli applicativi con relativi permessi
  • Stakeholders, le persone coinvolte direttamente o indirettamente dal progetto
  • Risks, la categoria che raccoglieva una prima analisi dei rischi

Grazie a questa prima iterazione, la mappa ha cominciato a prendere corpo.

Con l’aiuto di un membro del team che si occuperà dello sviluppo, si è proceduto alla scomposizione delle funzionalità in attività; questo ha permesso di delineare la WBS (allegata in formato excel alla mappa) e sulla quale è stato possibile procedere con stime di dettaglio (primo riscontro della mia stima draft fatta in fase di offerta).

Al kick-off ci siamo voluti presentare subito con i layout di esempio delle pagine dell’applicazione, per permettere a tutti di discuterle e di trovare da  subito condivisione sulle interfacce e sulla loro navigabilità.

Anche questa presentazione è stata allegata alla mappa.

Un altro passo è stato organizzare le funzionalità in deliverable del prodotto.

Questo punto è stato ispirato dalla metodologia agile:

  • rilasci frequenti e temporalmente vicini
  • inclusione già primi rilasci delle funzionalità più importanti (customer business value)

Sono state quindi identificate 4 deliverable, a rilasci distanziati di circa due settimane lavorative l’una dall’altra, includendo le funzionalità più importanti nelle prime due.

Quest’ultimo punto permetterà di:

  • innalzare subito l’attenzione del cliente perché in grado di verificare subito le funzionalità più importanti
  • garantirci una maggiore “probabilità” di feedback sulle deliverable
  • fugare sin da subito dubbi o malintesi sulle funzionalità più importanti invece di scoprirlo alla fine con conseguenze dannosissime

Ho,infine, aggiunto:

  • una categoria “Legenda” che riportava le descrizioni delle diverse icone o simboli grafici presenti
  • una categoria “Agenda” che riassumeva i macro-punti che sarebbero stati discussi nel meeting
  • Una categoria “Attendees” che elencava i partecipanti al kick-off

Il kick-off è andato benone.
Ho potuto mostrare la nostra idea di implementazione del progetto e raccogliere diversi suggerimenti, correzioni, aggiustamenti da parte del cliente.

I punti nella categoria “Open Point” sono stati tutti completamente evasi ed hanno ricevuto le risposte attese.

Gli stessi, a fronte delle risposte, sono stati inclusi nella categoria “Decisions”.

E’ stata prevista un’ulteriore categoria “Action Points” in cui sono state aggiunte le azioni immediate che si sarebbero dovute svolgere e a carico di chi.

Infine sono state aggiunte alcune segnalazioni nella categoria “Risks”.

La mia mappa alla fine conta le seguenti categorie:

  • Legenda
  • Agenda
  • Attendees
  • References
  • Functionalities
  • Stakeholders
  • Systems Involved
  • Applications Roles
  • WBS
  • Draft Layouts
  • Deliverables
  • Decisions (prima chiamata Open Points)
  • Action Points
  • Risks

 Kick-off Mind Map

 

Ora non mi rimane che utilizzare una delle funzionalità di cui sono più innamorato di MindJet MindManager: l’esportazione in word. Questo permetterà la redazione della meeting minutes in pochi minuti, la spedizione agli altri partecipante del kick-off e finalmente….possiamo cominciare a lavorare.

Un buon kick-off non garantisce certo la riuscita del progetto, ma sicuramente siamo riusciti a creare commitment, responsabilità e chiarezza su cosa e come dovrà essere fatto il lavoro e chi e quando dovrà essere svolto.

Pronti, partenza…..via!

In questo post parleremo di scrum, sviluppo software agile e sprint e di come, in questi giorni, li abbiamo applicati da noi in Diesys. 

Scrum è una metodologia agile che pone il focus sull’esecuzione incrementale del lavoro (release), in tempi brevi, caratterizzati da grossa coesione e spirito di iniziativa del team.

In fase analitica utilizza linee di comunicazione molto corte e, in fase di sviluppo, tempi decisionali molto brevi al fine di non dover dedicare troppo tempo allo sviluppo di documentazione analitica e reinvestire quel tempo nello sviluppo effettivo del prodotto.

Esistono tre ruoli/figure fondamentali:

  • Product owner, colui che è responsabile del prodotto (solitamente il committente)
  • ScrumMaster, colui che governa il processo di produzione (project manager)
  • Team, gli sviluppatori che eseguono il lavoro

Le features del prodotto solitamente vengono tutte raccolte dallo ScrumMaster a seguito di interviste effettuate con il committente, gli utenti finali, gli stessi membri del team. Questa lista di funzionalità è chiamata “product backlog“.

Il secondo step è di decidere, con il product owner, quali funzionalità enteranno nelle diverse release (deliverable) ; la lista di funzionalità a capo di una release viene chiamata “release backlog“.

A questo punto entra in gioco il team che con lo ScrumMaster assegna priorità alle singole feature della release ed effettua la stima dei tempi per ciascuna.

Finalmente, in funzione del tempo in cui si vogliono suddividere gli sprint (solitamente da 2 giorni sino a 30 giorni), si scelgono le singole features e si raggruppano, appunto, in sprint.

Le singole attività vengono assegnate ai membri del team e finalmente si parte con lo sviluppo.

Scrum Process

Scrum Process

 La scorsa settimana abbiamo deciso di utilizzare tale tecnica per un cambio importante di release del nostro framework applicativo che ci supporta nello sviluppo delle soluzioni. L’ultimo intervento innovativo al progetto era stato fatto più di un anno fà e le segnalazioni di anomalie, bug, revisioni o migliorie erano piuttosto corpose.

Io, in quanto product owner, e il mio collega Massimiliano, ScrumMaster, abbiamo fatto la cernita di tutte le possibili features (product backlog) che potevano essere implementate.

E’ stata fatta una prima scrematura (legge 80/20 di Pareto, ricordate?) che ci ha portati ad avere una lista di features più importanti da sviluppare (release backlog).

A quel punto lo ScrumMaster e il team, hanno prioritizzato tali attività e suddiviso in sprint (che per noi era di 2 giorni), terminando con l’assegnazione dei compiti alle singole persone.

A quel punto è stato il momento del via!

Quali i risultati? Beh, oggi ho parlato con Massimiliano per avere un feedback in merito.

Cosa ha funzionato:

  • I tempi sono stati rispettati tranne piccole varianze
  • Praticamente tutte le feature sono state implementate
  • Il lavoro del team a stretto contatto, su tematiche comuni, ha permesso la nascita di buone idee/suggerimenti
  • La condivisione e la comunicazione attiva ha permesso di creare persone di backup su alcune aree di codice sino ad allora conosciute solo da singoli

Cosa non ha funzionato:

  • Non tutte le persone che inizialmente erano state scelte per far parte dello “sprint team” hanno potuto partecipare attivamente, cause incombenze e urgenze lavorative

In generale comunque possiamo ritenerci soddisfatti.

Il prossimo sprint lo faremo probabilmente il prossimo mese, e lavorare molto di più sulla qualità dei processi che utilizziamo per produrre soluzioni.

ByeBye :)

Successfull Projects

In questo post cercherò di identificare le principali cause fallimento dei progetti cercando di trovarne un denominatore comune.

Questo post è disponibile ai soli utenti registrati.

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users. Please register using the side-bar on the right.

Puntiamo al sodo

Per natura ho una certa predisposizione alla pragmaticità.
Nel lavoro raramente pratico il gold-plating e cattedrali nel deserto ne ho costruite ben poche.
Questo approccio prevede una contropartita da regolare: posso perdere alcuni dettagli o sfumature o a volte il mio interlocutore può percepirmi come poco sensibile alle sue istanze più particolari.
Accetto il rischio. Cerco comunque di mantenermi vigile per evitare di commettere tali errori.

Citano alcuni testi di project management: un progetto si può ritenere concluso con successo, quando termina nei tempi e nei costi prestabiliti e quando sono state realizzate tutte le funzionaltà previste e solo quelle previste.

Questa citazione spalanca la porta alle tematiche agili.

iStock_000005861755XSmall

Partiamo dal documento costituitente della disciplina agile (manifesto per lo sviluppo agile di software).
In quel documento sono esplicitamente evidenziati i quattro pilastri su cui si sviluppa l’intera disciplina e soprattuto su quali questioni deve essere posto il maggiore accento:

  • Gli individui e le interazioni più dei processi e degli strumenti
  • Il software funzionante più che la documentazione esaustiva
  • La collaborazione col cliente più che la negoziazione del contratto
  • Rispondere al cambiamento più che seguire i piani

Nascosta tra le righe io ci leggo una sola parola: concretezza.

Customer Value

La teoria agile mette al centro della sua esistenza il concetto di customer value, che potremmo così sintetizzare:

il giusto prodotto, al giusto prezzo, nei giusti tempi.

Ma come possiamo definire “giusto” un prodotto, il suo prezzo e i relativi tempi di realizzo?

  • Il giusto prodotto, è quel prodotto che implementa tutte le funzionalità richieste dal cliente, solo quelle, e che abbiano le caratteristiche e qualità necessarie.
  • Il giusto prezzo è quel prezzo, equo e correttamente comparato alle funzionalità, aspettative e al mercato.
  • I tempi giusti sono i tempi minimi di realizzo del prodotto, che vadano più possibile incontro alle aspettative del cliente.

Quando lessi la prima volta la definizione sopra, sorrisi: alcune le consideravo definizioni ovvie, altre semplicemente utopiche.

Però mi fecero pensare.

Era in effetti capitato in alcune occasioni, che alla presentazione di un prodotto appena realizzato il cliente mi facesse notare come alcune funzionalità introdotte non le ritenesse importanti; anzi spesso mi chiedeva di disabilitarle per evitare incomprensioni da parte degli altri utenti.
Quanto tempo e soldi mi erano costate quelle inutili funzionalità?

Altro problema centrale rispetto alla soddisfazione del cliente, è il tempo di realizzo di un prodotto o servizio.
Prima però un’altra considerazione a riguardo: sappiamo riconoscere il vero valore di business del prodotto che il cliente ci ha commissionato? Sappiamo identificare le funzionalità centrali del prodotto stesso?
Certo, credo proprio di si; spesso però tali funzionalità sono le ultime, in ordine cronologico, che vengono sviluppate.

Le motivazioni sono valide: è necessario oraganizzare prima il progetto, le risorse, l’architettura e, se si tratta di uno sviluppo software, il database e una buona parte dell’interfaccia utente.
Il cliente, di questo passo, vedrà le caratteristiche primarie del prodotto praticamente alla fine del progetto stesso.

Come fare quindi per conciliare tempi adeguati e soddisfazione del cliente?
La risposta è sicuramente procedere con rilasci progressivi.

Rilasci Progressivi

Il cliente ha appena firmato il contratto che gli abbiamo presentato per la realizzazione del prodotto richiesto.
Qual’è il più classico degli errori in cui ricadiamo?
Sparire per un tot di settimane, per poi ricomparire con il prodotto finito; chi di voi non ci è cascato almeno una volta? Personalmente, nonostante mille auto-raccomandazioni, mi capita tuttora.
Risultati:

  • il tempo trascorso senza contatti ha “raffreddato” il cliente
  • alcune, se non tutte, le funzionalità del prodotto, non sono come il cliente se le aspettava
  • la finestra temporale in cui il prodotto avrebbe riscontrato maggiore successo è ormai passato
  • il prodotto dovrà essere testato e sicuramente verranno richieste modifiche o aggiustamenti che avranno una ricaduta pesante considerando che siamo ormai alla fine della sua realizzazione

Ecco allora che lo sviluppo iterativo del prodotto/servizio e la predisposizione di rilasci progressivi di prototipi, perfettamente funzionanti nelle loro seppur parziali funzionalità, potrebbe essere la risposta opportuna.

Come fare?
Prima di tutto partiamo dalla WBS di prodotto: essa ci restituisce uno spaccato preciso e immediato di tutte le funzionalità del prodotto.
Insieme al cliente procediamo a prioritizzarne le funzionalità: partendo da quelle a più alto valore di business.
Queste dovranno essere quelle che andremo a rilasciare il prima possibile, abbattendo rischi di misunderstanding, cercando e ottenendo feedback immediati proprio perché caratteristiche più volute dal cliente, aumentando la soddisfazione del cliente perché indirettamente percepisce di avere il suo prodotto in tempi molto brevi.

In virtù di quanto detto sopra a proposito di architettura e organizzazione del progetto, non è però sempre facile rilasciare subito tali funzionalità al cliente; è per questo che è assolutamente necessario coinvolgere il team.

Solo il team è in grado di fornire indicazioni, suggerimenti, scorciatoie per arrivare a tale risultato.
Ovviamente tutti i mebri del team devono condividere pienamente le motivazioni che portano ad una scelta del genere, pena il fallimento dell’operazione.

WordPress Themes