simone casciaroli - agile in tough economic times

30 April 2009

Simone Casciaroli

Slide 1Agile in tough economic times

© Zühlke 2009

Agile in tough economic times

30 April 2009

Simone Casciaroli


© Zühlke 2009

Indice

•Storia di una startup

•Agile nel nostro progetto

•Qual e’ il valore aggiunto di Agile nei periodi di incertezza

• Conclusioni

30 April 2009

Simone Casciaroli


© Zühlke 2009

Non disclosure agreement

•Ho firmato un NDA che non mi permette di condividere informazioni sul prodotto sviluppato e sull’azienda che c’e’ dietro

•La chiamerò HappyStartUp

•Questo tipo di informazioni non sono importanti ai fini del talk

30 April 2009

Simone Casciaroli


© Zühlke 2009

Introduzione

• “Responding to change over following a plan”

•Cambiamento spesso dovuto a:– Specifiche poco chiare– Hitting the moving target (il cliente

cambia idea)

•ma anche:– Riduzione dei costi

30 April 2009

Simone Casciaroli


© Zühlke 2009

Un’Idea Brillante

HappyStartUp

30 April 2009

Simone Casciaroli


© Zühlke 2009

Brainstorming

Sketches

Business plan

30 April 2009

Simone Casciaroli


© Zühlke 2009

Incertezza delle stime durante le varie fasi del progetto

30 April 2009

Simone Casciaroli


© Zühlke 2009

Soldi

30 April 2009

Simone Casciaroli


© Zühlke 2009

Il team

•4 ½ developers

•½ Scrum master

•Product Owner (real customer)

•Security specialists

•Usability expert

•Designer

Agile

30 April 2009

Simone Casciaroli


© Zühlke 2009

Si inizia…

•Iterazioni da 4 settimane

•L’obiettivo era di consegnare Release1 in 13 iterazioni

•Pratiche Scrum/ XP

•Abbiamo adottato la categorizzazione MoSCoW per le storie:

– Must have– Should have– Could have– Won’t have this time

1 4 13

30 April 2009

Simone Casciaroli


© Zühlke 2009

Incertezza

•Tecnologie nuove

•Nuovo business domain

•Target Users non ancora ben definito

•… tutte quelle incertezze che possono esserci in un progetto “innovativo”

1 4 13

30 April 2009

Simone Casciaroli


© Zühlke 2009

Terrore alla fine dell’iterazione

Realizzammo che non saremmo stati in grado di consegnare le

MUST HAVE functionality velocemente come pensavamo

1 4 13

30 April 2009

Simone Casciaroli


© Zühlke 2009

Dagli investitori…

•Gli investitori declinarono la possibilità di aumentare l’investimento

•…e iniziarono a domandarsi se continuare il progetto fosse la scelta migliore

1 4 13

30 April 2009

Simone Casciaroli


© Zühlke 2009

… e se questa fosse la fine della storia?

•Sarebbe stato un fallimento completo?•La cancellazione di un progetto in fase iniziale non e’ un fallimento completo perché libera risorse che possono essere reindirizzate

30 April 2009

Simone Casciaroli


© Zühlke 2009

Dagli investitori…

•Gli investitori declinarono la possibilita’ di aumentare l’investimento

•…e iniziarono a domandarsi se avesse avuto senso continuare il progetto

1 4 13

30 April 2009

Simone Casciaroli


© Zühlke 2009

Com’e’ stata evitatala cancellazione…1

Presentammo un software funzionante con un sub-set delle funzionalità MUST HAVE come

asset per

ristabilire la fiducia degli investitori

30 April 2009

Simone Casciaroli


© Zühlke 2009

Com’e’ stata evitatala cancellazione…2

•Riducemmo lo scope del progetto

Cost Time

Scope

Quality

30 April 2009

Simone Casciaroli


© Zühlke 2009

Come abbiamo ridefinito lo scope

•Ridefinimmo il significato di MUST HAVE

“What if the project will

stop tomorrow?”

30 April 2009

Simone Casciaroli


© Zühlke 2009

Come abbiamo ridefinito lo scope

A volte un uso poco “agile” delle best practices dell’usabilità può portare nella direzione sbagliata

30 April 2009

Simone Casciaroli


© Zühlke 2009

Agile non può rimuovere le incertezze

… ma da la possibilità di reagire prima e più velocemente

30 April 2009

Simone Casciaroli


© Zühlke 2009

La Stories board fa del progetto un progetto Agile?

30 April 2009

Simone Casciaroli


© Zühlke 2009

Com’e’ stata evitata la cancellazione…3

Grandi cambiamenti nel sistema:

•Passare da una costosa soluzione di DB clustering ad una economica

•Semplificare alcune funzionalità per ridurre il costo

•… ma anche perché i test di usabilità ci mostravano come le nostre assunzioni sul “cosa e’ usabile” fossero sbagliate

1 4 13

30 April 2009

Simone Casciaroli


© Zühlke 2009

Le pratiche XP portano alla manovrabilità del codice

•Grandi cambiamenti in maniera incrementale

•Avere un design flessibile che permette di fare modifiche facilmente

•Avere una rete di protezione (tests) che permette al team di modificare il codice senza paura

30 April 2009

Simone Casciaroli


© Zühlke 2009

Com’e’ VERAMENTE finita…

•Deploy della versione Alpha il mese scorso

•Basso numero di bugs trovati in Alpha

•Rilascio pubblico (come inizialmente stimato) in Giugno

1 4 13

30 April 2009

Simone Casciaroli


© Zühlke 2009

Non e’ stato semplice…

Pressione generata da:

“Abbiamo finito i soldi”

Sacrificata la qualità

sull’altare delle “più funzionalità”

Difficoltà nell’estendere il sistema

1 4 135

30 April 2009

Simone Casciaroli


© Zühlke 2009

Riepilogando: Il valore aggiunto di Agile

•Early risk indicator

•Avere un sistema funzionante fin dalle prime iterazioni

30 April 2009

Simone Casciaroli


© Zühlke 2009

Riepilogando: Il valore aggiunto di Agile

Per strategie di cost reduction:

•La riduzione dello scope con la priorità delle storie come timone

•Una codebase manovrabile che permetta di tagliare i costi senza overhead

30 April 2009

Simone Casciaroli


© Zühlke 2009

Conclusioni

•Business Mantra: Essere flessibile per rispondere ai cambiamenti di mercato

•… spesso derivano da un products lifetime molto breve

Oggi i cambiamenti vengono anche guidati dalla riduzione nel credito o dalla riduzione nei costi di “produzione”…and Agile still

rocks

simone casciaroli - agile in tough economic times

Technology