User Story, Kanban, Iteration Meeting, Pomodori... tutto regolare per un team di sviluppatori. Ma che succede se aggiungiamo al team degli UX Designer e magari anche un Copy Writer e un Marketer? Vediamo come continuare ad utilizzare metodi e strumenti Agile in team cross funzionali e come i non-developers possono beneficiarne.

1. Agile for non-developers

2. Flowing
• 40+ persone
• 23 sviluppatori
• 6 designer
• 3 devops
• 2 comunicazione e marketing

3. @N1c0l_3Nicole Bartolini
Parliamo di:
1. Il Manifesto Agile per i non-developers
2. Le metodologie agili in un team cross funzionale
3. User story vs. Feature
4. Definition of Ready & Definition of Done
5. Impact mapping: overview
6. Racconti di vita vissuta: cos’ha funzionato e cosa no

4. Il Manifesto Agile
per i non-developer
1

5. @N1c0l_3Nicole Bartolini
Valori
• Gli individui e le interazioni più che i processi e gli strumenti
• Software funzionante Consegna di valore più che la
documentazione esaustiva
• La collaborazione col cliente più che la negoziazione dei contratti
• Rispondere al cambiamento più che seguire un piano

6. @N1c0l_3Nicole Bartolini
Principio #1
La nostra massima priorità è soddisfare il
cliente rilasciando software di valore, fin da
subito e in maniera continua.

7. @N1c0l_3Nicole Bartolini
Principio #2
Accogliamo i cambiamenti nei requisiti, anche a stadi
avanzati dello sviluppo del processo.
I processi agili sfruttano il cambiamento a favore del
vantaggio competitivo del cliente.

8. @N1c0l_3Nicole Bartolini
Principio #3
Consegnamo frequentemente software funzionante
un prodotto funzionante, con cadenza variabile da
un paio di settimane a un paio di mesi, preferendo i
periodi brevi.

9. @N1c0l_3Nicole Bartolini
Principio #4
I committenti e gli sviluppatori i membri del
team devono lavorare insieme
quotidianamente per tutta la durata del
progetto.

10. @N1c0l_3Nicole Bartolini
Principio #5
Fondiamo i progetti su individui motivati.
Diamo loro l'ambiente e il supporto di cui hanno
bisogno e confidiamo nella loro capacità di portare il
lavoro a termine.

11. @N1c0l_3Nicole Bartolini
Principio #6
Una conversazione faccia a faccia è il modo più
efficiente e più efficace per comunicare con il team
ed all'interno del team.

12. @N1c0l_3Nicole Bartolini
Principio #7
Il software funzionante Un prodotto di qualità
è il principale metro di misura di progresso.

13. @N1c0l_3Nicole Bartolini
Principio #8
I processi agili promuovono uno sviluppo
una consegna di valore sostenibile.
Gli sponsor, gli sviluppatori il team e gli utenti
dovrebbero essere in grado di mantenere
indefinitamente un ritmo costante.

14. @N1c0l_3Nicole Bartolini
Principio #9
La continua attenzione all'eccellenza tecnica
e alla buona progettazione esaltano l’agilità.

15. @N1c0l_3Nicole Bartolini
Principio #10
La semplicità - l'arte di massimizzare la
quantità di lavoro non svolto - è essenziale.

16. @N1c0l_3Nicole Bartolini
Principio #11
Le architetture, i requisiti e la progettazione
migliori emergono da team che si
auto-organizzano.

17. @N1c0l_3Nicole Bartolini
Principio #12
A intervalli regolari il team riflette su come diventare
più efficace, dopodiché regola e adatta il proprio
comportamento di conseguenza.

18. Le metodologie agili in un
team cross funzionale
2

19. @N1c0l_3Nicole Bartolini
Kanban
• Si crea una board suddivisa in colonne: to do, doing e done. Si
possono aggiungere altre colonne utili a tracciare il flusso delle attività,
come “ideas/backlog", "in review", …
• Il team e il cliente scrivono insieme l’elenco delle attività da svolgere
• Il team e il cliente prioritizzano le attività in to do, dalla più alla meno
importante
• La board con i task ordinati viene resa ben visibile a tutti, anche a chi
non fa parte del team

20. @N1c0l_3Nicole Bartolini
Gestire la kanban
• I task si spostano da sinistra a destra: l’obiettivo è quello di far arrivare
il più velocemente possibile le attività nella colonna “done”
• I task più a destra nella kanban hanno priorità più alta: la conclusione
di un’attività in “review” è prioritaria rispetto all'inizio di un task in “to
do” ⟶ il principio del WIP nella kanban serve per impedire che ci
siano troppe attività avviate che non vengono concluse
• Per gestire le attività di un team cross funzionale è utile separare i task
in lane, in modo che ognuno possa seguire il flusso delle attività per le
quali può contribuire con le sue competenze

22. @N1c0l_3Nicole Bartolini
Rituali agili
• Ogni giorno il team fa stand-up meeting: ci si focalizza sui roadblock
dei membri del team piuttosto che sulle attività fatte il giorno prima e
su quelle da fare ora
• Iteration meeting: un check della kanban board che viene svolto
periodicamente e serve a popolare la colonna “to do” di attività nella
giusta priorità
• Periodicamente il team partecipa ad una retrospettiva, per capire ciò
che è andato bene e ciò che va migliorato nelle successive iterazioni

23. @N1c0l_3Nicole Bartolini
Retrospettiva: a cosa serve
• Aumenta il livello di interazione e condivisione del team
• Identificare cosa è andato bene o male, in relazione a processi,
strumenti e dinamiche di gruppo
• Permette di discutere e scoprire opportunità di miglioramento e
definire un piano d'azione per implementarlo
• Evidenzia ciò che è andato bene: è importante concentrarsi sul positivo
e identificare ciò che funziona bene in modo che continui a farlo

24. User Story vs. Feature
3

25. @N1c0l_3Nicole Bartolini
Le User Story
Le User Story sono brevi e semplici descrizioni di
una funzionalità, raccontate dal punto di vista della
persona che le desidera.

26. @N1c0l_3Nicole Bartolini

27. @N1c0l_3Nicole Bartolini
Esplicitiamo il perché
Le user story rendono esplicito il perché quell’attività va
fatta, cioè il desiderata della user persona/attore.
Questo permette a tutto il team di restare allineato
sull’obiettivo della storia.

28. @N1c0l_3Nicole Bartolini
Criteri di accettazione
Una buona pratica consiste nell’aggiungere alla
descrizione delle attività, dei criteri di accettazione: le
condizioni necessarie per rendere la lavorazione valida.
es. L’utente che si registra al sito deve scegliere una password di almeno 8
caratteri, con un numero, una lettera maiuscola e un carattere speciale.

29. @N1c0l_3Nicole Bartolini
Feature
• Le feature sono funzionalità complesse raggiunte tramite il
completamento di più user story
• Gestire le feature come collezione di user story rende più semplice
stimare le attività e tracciarne l’avanzamento
• Avere visibilità sull’intera feature consente al team di progettare per
la funzionalità che si vuole ottenere, in maniera coerente e senza
incappare in strade morte e lavorazioni inutili

31. User Story
INVEST

32. Una singola user
story è sufficiente
per portare valore
all’utente per cui è
stata scritta
INDEPENDENT

33. La storia lascia
spazio alla
sperimentazione,
per raggiungere
meglio l'obiettivo
NEGOTIABLE

34. La user story
fornisce
chiaramente valore
alla persona per cui
è stata scritta
VALUABLE

35. La storia ha un
costo chiaro
rispetto al valore
(tempo, soldi,
risorse)
ESTIMABLE

36. La storia è la più
piccola possibile,
nel rispetto dei
principi di
indipendenza e
valore
SMALL

37. La storia ha KPI
chiari, tali da
consentire la
valutazione degli
obiettivi
TESTABLE

38. Definition of Ready &
Definition of Done
4

39. @N1c0l_3Nicole Bartolini
Definition of Done
La Definition of Done (abbreviato DoD) è una lista informale di
attività che devono essere portate a termine affinché una user story
possa essere considerata completata.
Al contrario dei criteri di accettazione, che sono specifici di una card,
la DoD è comune a tutte le storie.

40. @N1c0l_3Nicole Bartolini
Definition of Ready
La Definition of Ready indica quando una storia è pronta per essere
messa in to do, ovvero quando tutto il materiale necessario alla sua
lavorazione è pronto.

41. @N1c0l_3Nicole Bartolini
Com'è composta la DoR?
• La user story è scritta nel formato scelto dal team
• La user story ha una stima in story point
• C’è una breve descrizione dell’attività da svolgere
• I criteri di accettazioni sono definiti e misurabili
• Il valore di business è specificato
• Eventuale documentazione, elementi grafici e mock-up sono allegati alla card
• I requisiti non funzionali sono specificati (es. vincoli temporali, performance)

42. Impact Mapping: overview
5

43. @N1c0l_3Nicole Bartolini
Cos'è una Impact Map?
• È una mappa mentale che rappresenta il percorso da uno specifico
obiettivo di business alle azioni che consentono di raggiungerlo
• Risponde a queste 4 domande fondamentali: Perché? Chi? Cosa?
Come?
• Lo scopo finale è raggiungere l’obiettivo di business, non un set
prestabilito di funzionalità

44. @N1c0l_3Nicole Bartolini
Quali vantaggi offre l’Impact Map?
• L’Impact Map offre un contesto alla progettazione, colmando la
mancanza di big picture tipica della progettazione iterativa
• Ha il vantaggio di farci mantenere un focus forte e ci aiuta a
prioritizzare, facilita la collaborazione e l’interazione oltre a rendere
visibili le assunzioni.

45. Storie di vita vissuta:
cos’ha funzionato e cosa no
6

46. @N1c0l_3Nicole Bartolini
Il sito flowing.it
x lavorare ad attività che
non rispettavano la
Definition of Ready
x fare i kanban meeting
con parte del team
assente
✓ mappare gli obiettivi di
business da raggiungere
prima di iniziare il progetto
✓ fare retrospettiva a metà
progetto
✓ allungare gli iteration
meeting da 1 a 2 settimane

47. @N1c0l_3Nicole Bartolini
La ri-organizzazione del team marketing
x fare retrospettiva da
remoto
x non stimare le attività
x non applicare il WIP
✓ coinvolgere altre persone
durante i kanban meeting
✓ incontrarsi di persona al
raggiungimento delle
milestone

48. I'm a retired Pokémon master with 20 years of
experience, WoW free since 2013, Zelda addict,
homemade pastry lover, and a metalhead
undercover.
Singer, swimmer, snowboarder, liar. Hater Eater.
Grazie!
Nicole Bartolini
Marketing & Communication

49. @N1c0l_3Nicole Bartolini
Link utili
• https://agilemanifesto.org/
• https://www.slideshare.net/ShaneWheller/nonit-agile-values-and-principles-deck
• Agile value and principles for non software developers team (Agile on the beach 2016): https://www.youtube.com/
watch?v=RP7lu1TkLnM
• http://agilemarketingmanifesto.org/
• https://www.flowing.it/blog/daily-kanban-meeting-adattare-le-pratiche-alle-nostre-esigenze
• https://medium.com/@kay_flew/how-to-write-user-stories-for-more-customer-focused-marketing-results-
bd79f707505e
• https://uxplanet.org/aligning-design-to-user-stories-614b4845fc8d
• https://www.mountaingoatsoftware.com/blog/the-two-ways-to-add-detail-to-user-stories
• https://www.agileway.it/definition-of-ready/
• http://www.susannafer.com/wordpress/impact-mapping-per-la-pianificazione-strategica/