Come gestire user stories tecniche

Tre approcci ai requisiti tecnici

Capita a tutti di dover inserire tra le attività del team task di tipo prettamente tecnico.
In questo articolo vi porto l’esempio di 3 modi differenti di gestire questo tipo di richieste.
Innanzi tutto ha senso parlare di user stories tecniche?
Mhhh, dipende…
Se siamo in grado di individuare nella richiesta un soggetto, un oggetto e un beneficio esplicito è utile definirla attraverso il format della user story.
Se non è così e ci si spacca la testa per far rientrare una richiesta in un modello che non le appartiene in alcun modo meglio evitare del tutto. Non l’ha prescritto il medico che tutto ciò che entra nel backlog sia esclusivamente una user story!
Ci può essere molto altro, ad esempio task di bug fixing, attività architetturali, prototipi, spike e via così.

Ha senso tracciare queste attività tecniche?
Assolutamente sì! Il team spende del tempo su questi task così come sull’implementazione di nuove funzionalità ed è importante tenerne traccia per monitorarle e pianificare il modo migliore di gestirle nel tempo.

Come affrontare user stories tecniche

Sprint funzionali e sprint tecnici

Quando nel corso del tempo non c’è stata un’attenzione continuativa alla qualità e al refactoring possono presentarsi casi in cui il codice legacy ha raggiunto livelli decisamente problematici.
In alcuni di questi casi mi è capitato di vedere i team di sviluppo alternare sprint in cui venivano implementate nuove funzionalità e sprint tecnici dedicati soprattutto al refactoring e alla “messa in sicurezza”.
Ad esempio a 3 sprint funzionali seguiva uno sprint tecnico.
Dico subito che non sono una fan di questa soluzione perché per la mia esperienza produce più svantaggi che vantaggi.

Svantaggi
E’ di difficile “digestione” da parte del business che fatica a comprendere uno stop forzato ogni mese e mezzo; è spesso difficile individuare un chiaro obiettivo dello sprint tecnico; il product owner ha difficoltà a misurare il valore di questo tipo di interventi (che peraltro poco si prestano a demo); richiede una maturità di gestione se possibile ancora più elevata da parte del team.
Infine spesso e volentieri questo sforzo non porta comunque un miglioramento effettivo in tempi brevi del codice legacy.

Vantaggi
Il team è fortemente focalizzato sulla risoluzione degli aspetti tecnici, li gestisce in totale autonomia e non subisce interruzioni.

User stories funzionali e tecniche nel medesimo sprint

Questa modalità di gestione è piuttosto frequente.
Il tempo disponibile dello sprint è suddiviso tra sviluppi funzionali e attività di tipo tecnico. Diciamo che il team concorda con il product owner di dedicare ad esempio l’80% del tempo ai primi ed il restante 20% ai secondi.
E’ il classico esempio di “un colpo al cerchio e uno alla botte”…

Svantaggi
Il team fa contest switching all’interno dello sprint (si tratta spesso di attività a sé stanti rispetto al resto); è difficile individuare un unico sprint goal.
Richiede comunque tempi lunghi per vedere effettivi benefici a livello di legacy.

Vantaggi
E’ un compromesso più che accettabile per il business perché non richiede periodicamente uno stop delle attività; questa modalità di gestione può essere adottata in ogni sprint; al termine di ogni iterazione consente di avere workable software da mostrare durante le demo.

Aspetti funzionali e tecnici nella medesima user story

Questa è un’altra possibilità e devo dire che tra tutte è quella dalla quale sento di aver tratto maggior beneficio.
In sostanza in ogni storia il team stima una quota parte di refactoring del codice e/o dei test. Questo si traduce in prima battuta in user stories che vengono valutate con un peso maggiore (e quindi in una diminuzione iniziale della velocity del team), ma in un tempo relativamente breve la situazione torna alla normalità e – addirittura – a migliorare.
E’ importante notare che richiede grande maturità tecnica ai membri del team e la capacità di fare solo ciò che è opportuno e nulla di più (no virtuosismi se non sono necessari).

Svantaggi
Il refactoring viene effettuato sulle sole storie funzionali lavorate nel corso dello sprint; iniziale diminuzione della velocity.

Vantaggi
Non ha effetti collaterali sugli stakeholder; questa modalità di gestione può essere adottata continuativamente; aumenta da subito la qualità del software e l’attenzione del team a questo aspetto; nel tempo porta grande confidenza ai dev sulle parti che hanno toccato e maggiore velocità di sviluppo.

E voi quale tipo di approccio adottate?
Quale ritenete più utile per il vostro caso? Avete esplorato altre possibilità?
Ci sono casi in cui per risolvere problemi di legacy avete dovuto adottare approcci più radicali?
Sono curiosa di sentire le vostre esperienze…

PO Camp: 10 motivi per andare

Si è concluso da qualche giorno a Baratti il  PO Camp 2015, evento dedicato ai temi della Product Ownership giunto ormai alla terza edizione.
Sulla scia dell’entusiasmo che questo appuntamento annuale mi lascia sempre alla sua conclusione ho deciso di raccontare perché mi piace e perché vale la pena spendere un week end in compagnia di alcuni tra i più appassionati agilisti italiani.

Ecco qui in ordine sparso i motivi per cui sinora non ho saltato alcuna edizione.

1. “Ma quanti Product Owner Madama Dorè…”

Quest’anno i Product Owner erano la rappresentanza più consistente tra i 46 partecipanti al PO Camp.
Che c’è di strano, direte voi?
Bè, innanzi tutto trovarsi 2 giorni in compagnia di una ventina di Product Owner italiani non capita spesso (… a me capita solo qui!).
Tanti Product Owner tutti assieme li ho visti solo al corso di certificazione, ma si teneva a Londra e lì è tutta un’altra storia…
In sostanza: i PO hanno spesso difficoltà, risorse e situazioni comuni. Potersi confrontare su questi temi con tante altre persone che vivono le medesime esperienze tutti i giorni per me è un lusso.

2. Open Conference

La formula del PO Camp è invariata sin dagli esordi.
Si tratta di una Open Conference, ovvero una conferenza in cui i temi trattati non seguono un’agenda predefinita ma emergono in base alle richieste, alle curiosità e ai dubbi dei partecipanti.
Chiunque può proporre un argomento che desidera presentare, approfondire o capire meglio grazie all’aiuto degli altri.
L’agenda viene creata collaborativamente all’apertura della prima giornata.
E’ una formula poco usata negli eventi in Italia che consente di trattare in un contesto informale ciò che sta davvero a cuore ai partecipanti.

3. La varietà dei temi

4 o più sessioni parallele ogni ora intervallate da pranzo, chiacchiere e coffee break. A volte è difficile scegliere tra le proposte concomitanti, tutte interessanti.
Si spazia dagli strumenti di lavoro del Product Owner al release planning, dai contratti agili ai framework per scalare in aziende di grosse dimensioni, dalle personas al change management.
Questi sono solo un esempio dei tanti temi proposti e se temete che il tono sia troppo serio per un weekend potete sempre dedicarvi a scoprire le similitudini tra il tango e lo Scrum (fantastica sessione “feet on”) o testare per primi un gioco da tavolo per insegnare lo sviluppo software ai bambini.
Qui si discute di tutto, anche a tavola o in serata davanti a una birretta.

4. Non solo Product Owner e non solo sviluppo software

Questo è un altro aspetto di grande interesse per me.
Al PO Camp non ci sono solo Product Owner (siamo tutt’altro che un circolo esclusivo!).
Sono presenti anche Scrum Master, Coach Agile, manager, product manager che si stanno avvicinando al mondo dell’Agile e vogliono farsi un’idea più precisa di cosa li aspetta ed anche professionisti che non hanno nulla a che fare con lo sviluppo software come architetti ed insegnanti.
Il bello è proprio mettere a fattor comune esperienze di utilizzo della metodologia in contesti differenti, una contaminazione di idee in grado di generare preziosi insight e soluzioni innovative.

5. Sessioni all’aperto

Il clima è ancora buono (cade sempre negli ultimi giorni d’estate) e la location ha ampi spazi all’aperto.
Per questo vi potrebbe capitare di discutere i problemi ricorrenti che incontra un Product Owner nella sua professione a bordo piscina o confrontare gli strumenti per definire le priorità al bar.
Quest’anno abbiamo saltato la sessione al mare (solitamente l’ultima della giornata di sabato) perché il vento era freschino, ma vedere gruppi in cerchio sulla spiaggia del golfo di Baratti che parlano assiduamente di Scrum mentre nonni e bambini fanno il bagno è uno spettacolo da vedere almeno una volta nella vita.

6. Interventi di valore

Quest’anno per la prima volta è stato introdotto un intervento di uno speaker d’eccezione.
Il concetto di valore è stato l’argomento del workshop tenuto da Andrea Provaglio, unica sessione predefinita in agenda.
Per quanto sia bello il confronto tra product owner, il punto di vista di chi ha grande esperienza e grande visione sistemica offre nuove prospettive… di valore appunto.
Il workshop è stato una gradita novità per i partecipanti!

7. I giochi serali

Il post-cena è sempre ludico e anche quest’ultimo anno non è mancato il divertimento.
Protagonisti 9 product owner, i rispettivi team e i Lego trasformer.
Nonostante la mia performance discutibile e la scarsa conoscenza dimostrata sul dominio macchine e motori (papà perdomani!), il gioco mi ha dato la possibilità di sperimentare in un ambito differente le dinamiche di team, così come i punti di forza e di debolezza nell’esercizio del ruolo.
Il gioco apre ad interessanti riflessioni che maturano nei giorni successivi.
E’ un’ottima dimostrazione dell’orgoglio del fare squadra e della creatività di ognuno… per non parlare poi dei virtuosi del product canvas, degli elevator pitch e delle presentazioni multimediali da far invidia al Google I/O.

8. La location

Si tiene a Baratti (provincia di Livorno), in uno dei tratti più belli del litorale toscano. A pochi chilometri dalle tombe etrusche di Populonia e dagli imbarchi per l’isola d’Elba.
Se partecipate forse non avrete tempo di visitare i dintorni, ma potrete apprezzare il profumo delle pinete, l’ottimo vino e i cieli tersi anche durante i lavori.
La location è stata scelta apposta in centro Italia per consentire a tutti i partecipanti da nord, sud, est e ovest di raggiungere abbastanza agevolmente il Camp.

9. La community

E’ la mia terza volta al PO Camp.
Ricordo la prima volta che sono venuta qui.
Non sapevo cosa mi aspettava, non sapevo chi avrei trovato, conoscevo solo una persona e temevo di essere “un pesce fuor d’acqua”.
Alla cena del venerdì sera mi sentivo già “a casa”.

E’ bello condividere le proprie passioni con chi è entusiasta tanto quanto te.
Pensavo che avrei preso contatto con altri professionisti del settore, ho incontrato degli amici.
E oggi ci si ritrova qua e là ai convegni o su hangout e si riparte ogni volta da dove ci si era lasciati.

All’inizio eravamo quattro gatti, oggi abbiamo quasi raggiunto la dignità di una community.

10. Sapere di non sapere

Tutte le volte che si chiude il PO Camp vivo questa sensazione: un misto di entusiasmo e di terrore.
Da una parte l’esaltazione di aver partecipato a qualcosa di unico, in compagnia di persone di valore che hanno dedicato tempo ed energia a mettersi in gioco; dall’altra la consapevolezza di aver ancora tantissima strada da fare per diventare davvero un bravo Product Owner.

Il sapere di non sapere mi fa compagnia.
Non resta che rimboccarsi le maniche…

Il panorama delle certificazioni Agile

Ritorno sul tema certificazioni – già affrontato in un post precedente – perché vedo crescere un discreto interesse nei gruppi Lean e Agile in rete e sono certa che i potenziali interessati hanno molte domande in merito.

L’occasione per parlarne è un articolo sull’argomento letto proprio ieri in cui sono presentati alcuni dati e di cui riassumo i punti salienti.

Certificazioni Agile: quante sono?

E’ difficile rispondere in maniera esaustiva a questo quesito.
Non è possibile dare un numero perché il panorama cambia velocemente.
La lista è corposa e potremmo dire che nuove certificazioni “spuntano come funghi” (in fondo è un business come un altro…), ma è necessario tenere presente che molte di queste nascono e muoiono nel giro di breve tempo.

Oltre alle certificazioni offerte da organizzazioni consolidate è infatti presente sul mercato una pletora di società di formazione che “cavalcano l’onda” dell’Agile. In quest’ultimo caso si tratta spesso di Training Providers – a volte riconosciuti a volte no – che arricchiscono il proprio catalogo con topic “di moda” con l’intento di ampliare la propria fetta di mercato.

Esistono inoltre – soprattutto negli Stati Uniti – certificazioni in-house, ovvero attestati che vengono rilasciati per corsi di formazione svolti sul tema Agile in azienda. La maggior parte di questi documenti tuttavia non ha un valore professionale spendibile all’esterno della società stessa.

In sintesi la gamma delle certificazioni è ampia e le più note competono tra loro.

Certificazioni Agile: quali sono le più diffuse?

E’ possibile esporre qualche dato sulle certificazioni più note e riconosciute sul mercato.
I dati sono relativi al numero di certificazioni attive rilasciate sino a gennaio 2015 e sono stati forniti dalle rispettive società (ad eccezione di Scaled Agile Inc. che non fornisce numeri di dettaglio).

Titolo Rilasciato da N° certificazioni (a gen 2015)
Certified Scrum Master (CSM) Scrum Alliance 309,309
Professional Scrum Master (PSM-I) – Level 1 Scrum.org 31,580
PMI-Agile Certified Practitioner (PMI-ACP) Project Management Institute 6,987
Certified Scrum Practitioner (CSP) Scrum Alliance 2,627
SAFe Agilist (SA) Scaled Agile Inc. 1,000+
SAFe Program Consultant (SPC) Scaled Agile Inc. 1,000+
SAFe Practitioner (SP) Scaled Agile Inc. 1,000+
Professional Scrum Master (PSM-II) – Level 2 Scrum.org 198
Certified Scrum Coach (CSC) Scrum Alliance 63

Il CSM – Certified Scrum Master è in assoluto l’attestazione più diffusa e anche la più “antica” delle certificazioni Agile.
Crescono i numeri anche delle certificazioni più”giovani”: il PMI-ACP introdotto dal Project Management Institute nel 2011 e SAFe, il framework per scalare Agile e applicarlo nelle grandi aziende.

Non sono presenti in questo prospetto le certificazioni relative alla figura del Product Owner, ovvero CSPO (Certified Scrum Product Owner) di Scrum Alliance e PSPO (Professional Scrum Product Owner) di Scrum.org. Tuttavia una breve ricerca su Linkedin ci può fornire un ordine di grandezza degli attestati rilasciati dalle due organizzazioni.
Ad oggi sono presenti sul popolare network professionale più di 16.000 CSPO e ca. 1.600 PSPO (numeri ben ridotti a confronto con i 160.000 CSM e 50.000 PSM indicizzati su Linkedin).

Certificazioni Agile: cosa certificano?

Quasi tutte le certificazioni presenti sul mercato attestano la conoscenza del candidato, ovvero il fatto che abbia appreso i principi e le linee guida della metodologia Agile.
Poche pochissime ne valutano invece l’esperienza, cioè l’applicazione pratica di queste conoscenze nel contesto professionale.
Solo il PMI-ACP e la certificazione per coach (CSC) fanno un assessment dell’esperienza, seppur in modo puramente quantitativo (in base al numero di ore erogate “sul campo”).
Nessuna delle certificazioni attualmente più diffuse fornisce una garanzia sulla competenza del candidato, relativa quindi alla qualità dei risultati che è in grado di produrre.

Certificazioni Agile: tra le tante quali scegliere?

Anche in questo caso non esiste una risposta valida per tutti indistintamente. Bisogna valutare quale può essere la soluzione più adatta in base agli obiettivi della persona e al contesto di riferimento.
Se un amico mi chiedesse un consiglio inizierei porgendogli semplici domande:

    1. Prima di tutto a cosa sei più interessato? In quale ruolo senti di poter esprimere al meglio le tue capacità? Come Scrum Master, come Product Owner o come Coach?
    2. Per quale motivo senti di aver bisogno di una certificazione? Perché vuoi approfondire la conoscenza di queste tematiche o perché te l’ha chiesto/imposto l’azienda (ma non sei granché interessato)?
    3. Come preferisci che sia erogata la formazione? On-site, online, in aula?
    4. Pensi di sfruttare la certificazione come un vantaggio competitivo sul mercato del lavoro? Quanto vuoi differenziarti dagli altri professionisti del settore?

Queste sono solo alcune delle domande che dovrebbero aiutarvi a chiarire le idee.
In ogni caso il mio consiglio è di investire sempre sulla credibilità e l’affidabilità sia della certificazione sia del formatore.
Se avete curiosità specifiche sulla certificazione da Product Owner non perdetevi questo articolo!