Il team player ideale

Oggi cambiamo topic, non parliamo di prodotto bensì di team e in particolare delle caratteristiche ideali di un team member.
Un amico mi ha segnalato questo libro – “Il team player ideale” di Patrick Lencioni – dicendomi che “gli ha aperto un mondo”.

E’ un Agile coach di grande esperienza e i suoi suggerimenti sono sempre preziosi per me quindi mi sono sparata la lettura in 2 giorni e vi condivido le principali riflessioni che mi sembrano interessanti.

Come scegliere il team player giusto?

Il libro parte da una domanda: le aziende che dicono di puntare sul lavoro di squadra come possono essere certe di selezionare e trattenere le persone giuste?

Jim Collins in “Good to Great” spiega quanto sia importante per le imprese di successo “imbarcare le persone giuste ”, ovvero assumere e poi trattenere in azienda dei dipendenti che sono allineati alla cultura aziendale, tenere nei posti chiave personaggi adatti alla cultura dell’azienda e far presidiare loro il processo di selezione dei nuovi candidati.

Ma quali caratteristiche definiscono esattamente un team player ideale?
Secondo Lencioni un vero team player è umile, appassionato e brillante. Vediamo cosa intende esattamente con queste qualità.

Le 3 qualità del team player ideale

Umiltà

L’umiltà è secondo l’autore il più importante e indispensabile attributo di un vero team player ma anche – sorprendentemente – l’aspetto più trascurato da così tanti manager che danno valore al lavoro di squadra.

Questa è la descrizione di umiltà che dà Lencioni:

“I team player migliori non hanno un ego ipertrofico e non danno importanza al proprio status. Sono rapidi nell’evidenziare i contributi degli altri e lenti nel sottolineare i propri. Condividono i meriti, elogiano la squadra molto più di se stessi e preferiscono parlare di successo collettivo anziché di successo individuale”.

Secondo l’autore ci sono due tipi di persone non umili che è bene individuare:

  • il tipo più ovvio è quello apertamente arrogante, totalmente concentrato su se stesso, che tende a vantarsi e ad assorbire tutta l’attenzione;
  • l’altro tipo sono le persone che mancano di fiducia in se stesse, pur essendo generose e positive nei confronti degli altri.

Questa seconda casistica mi ha spiazzato ma nella visione di Lencioni è chiaro perché si tratta di un problema: una persona che ha scarsa considerazione del suo valore nuoce gravemente ai team perché non sa sostenere le sue idee o non è in grado di attirare l’attenzione sui problemi che vede.

In sostanza l’insicurezza è sempre un problema nel lavoro in team sia che si vesta di presunzione sia nella svalutazione delle proprie capacità.

Passione

“Le persone appassionate non devono quasi mai essere spinte da un capo a lavorare più sodo, perché sono diligenti e trovano in sé la motivazione per svolgere i compiti loro affidati.”

La passione è la motivazione interna che spinge una persona a dare il massimo nel proprio lavoro perché questo è fonte di soddisfazione e di crescita.

Questa qualità più di tutte le altre può essere millantata durante i colloqui perché la maggior parte dei candidati sa come proiettare un’immagine di sé quale persona appassionata, tuttavia è una bugia con le gambe corte: è osservabile nel comportamento e spesso misurabile. Ecco perché nella vita lavorativa di tutti i giorni non si può fingere di essere appassionati quando questa motivazione interiore non c’è.

Qual è il risultato? Manager che finiscono per passare una quantità spropositata di tempo a cercare di motivare, punire o licenziare questo genere di collaboratori portati a bordo con poca attenzione.

Per evitare assunzioni di questo tipo Lencioni fornisce una serie di suggerimenti sul tipo di domande che potete utilizzare nei colloqui per “smascherare” finti appassionati.

Essere brillanti

Essere brillanti è – secondo l’autore – un concetto relativamente semplice e sensato, ma che viene spesso trascurato poiché molti dirigenti assumono personale guardando più alle competenze e alle abilità tecniche che alle cosiddette soft skills.

“L’essere brillanti significa semplicemente utilizzare il buon senso nelle relazioni con gli altri.”

Potremmo definire questa qualità come intelligenza sociale o intelligenza emotiva.

Quando una delle qualità manca

Il modello in oggetto prevede la compresenza delle 3 qualità “umile – appassionato – brillante” ma – parliamoci chiaro – sono poche le persone che incarnano la perfezione da questo punto di vista. La situazione più frequente che potete incontrare è una persona che non possiede tutte e 3 le caratteristiche allo stesso tempo o che ne presenta una sbilanciata rispetto alle altre.

Ecco cosa succede in questi casi:

  • Gli individui che sono umili e appassionati ma non brillanti sono spesso “involontariamente caotici”.
    La loro mancanza di comprensione del modo in cui le loro parole e azioni sono recepite dagli altri li portano senza volere a creare problemi nel team.
  • Chi è umile e brillante ma non sufficientemente appassionato viene classificato come “adorabile lavativo”.
    Non è alla ricerca di attenzione e lavora bene con i colleghi ma tende a fare solo ciò che è richiesto e niente più. Tuttavia dato che di solito sono positivi e amabili i responsabili tendono a trascurare i loro limiti.
  • Gli individui che sono appassionati e brillanti ma mancano di umiltà rientrano nella categoria degli “abili politici”.
    Sono persone intelligenti, ambiziose e disponibili a lavorare sodo, ma solo nella misura in cui ne possono trarre un beneficio personale. Purtroppo essendo brillanti sono in grado di presentarsi come collaboratori umili e può risultare difficile per i responsabili dei team notare i loro comportamenti distruttivi.

Selezione e feedback

Lencioni insiste sul fatto che se il lavoro di squadra è davvero un valore per l’azienda (e non semplicemente uno slogan su carta) è necessario mettere in atto un processo di selezione che vada ad indagare puntualmente i 3 aspetti del modello e non faccia sconti di sorta.

“In tanti cercheranno di ottenere il posto anche se non in sintonia con i valori dichiarati, ma pochi lo faranno sul serio quando comprenderanno che saranno ritenuti responsabili giorno dopo giorno dei loro comportamenti.”

Che fare però con le persone che sono già presenti in azienda?
In questo caso è opportuno fare un assessment interno ed intervenire laddove sono presenti situazione problematiche.

“Troppo spesso i manager sanno che una determinata persona non è in grado di far parte di un gruppo e che starebbe meglio altrove ma non agiscono per mancanza di coraggio e questo atteggiamento non è né saggio né virtuoso.”

Prendere il tempo per conoscere il proprio team in maniera approfondita è sempre un ottimo investimento; se poi doveste rilevare atteggiamenti non consoni potete fare leva sul feedback.

Il feedback è lo strumento più importante del processo di miglioramento e la parte che è più spesso mancante. ll manager in questo caso ha il dovere di “ricordare” in maniera costante al collaboratore che non sta ancora facendo ciò che serve all’organizzazione. Senza questo intervento non c’è alcun miglioramento.
Chi di voi non lo ha sperimentato? Vi ritrovate per l’ennesima volta a dover dire a una persona che non sta lavorando come dovrebbe o che il suo modo di interagire con i colleghi è inadeguato. Non potete credere di dover rifare ancora questa spiacevole conversazione…

Ebbene sì. È spiacevole e imbarazzante, ma Lencioni sottolinea come sia esattamente ciò che ci si aspetta da chi dirige un team o un’organizzazione perché l’assenza di feedback puntuali e immediati crea situazioni ingestibili.

Secondo l’autore de “Il team player ideale” chiarire i comportamenti che ci si attende dai collaboratori è persino più importante che porre obiettivi di performance.
Che dite? Siete d’accordo?

Chi scrive le user stories nel tuo Scrum team?

Se pensate che sia una domanda retorica ebbene non lo è!
E’ anzi un interrogativo su cui può essere utile mettere a confronto esperienze di vita diverse.
Questa riflessione nasce in seguito alla partecipazione ad un meetup di Pierluigi Pugliese intitolato “Stupidaggini che avete sentito su Scrum, Ep. 3: Le User Stories non si scrivono!”, organizzato all’interno del gruppo Milano Scrum/Agile User’s Group.

Il titolo – inutile dirlo – mi ha attirato ed ero sicura che potesse aggiungere spunti interessanti alle riflessioni su uno degli strumenti più utilizzati dai Product Owner.
Ma non parleremo soltanto di chi scrive le user stories, smonteremo anche alcune “leggende metropolitane” che derivano da cattive pratiche ed insegnamenti discutibili discussi durante l’incontro con l’Agile coach.

Inutile dire che molti di questi comportamenti errati li ho vissuti in prima persona e in alcuni casi so di esserne stata anche corresponsabile, quindi voglio fare la mia parte nel smantellarli insieme a voi.
Nella mia esperienza con diversi development team Scrum ho visto un po’ tutte le situazioni: dai team che non fanno partire lo sviluppo se non ci sono user stories super-dettagliate, al PO che si sobbarca l’intero onere della chiarificazione dei bisogni, ai team che che contribuiscono solo al livello degli acceptance criteria fino a quelli più navigati che sono in grado di scrivere storie end-2-end e spacchettarle a dovere.
Tutte queste situazioni – giuste e sbagliate – sono dei pattern ed è utile sapere come affrontarle.

Ma partiamo dalla prima di queste male pratiche…

Il minimalismo delle user stories

Le storie sono:

  • il valore di business che vogliamo generare per l’utente
  • una promessa di conversazioni
  • riassumono l’aspettativa di business
  • descrivono l’attività da fare
  • sono un elemento di pianificazione
  • non si scrivono

Vi ritrovate in queste affermazioni?
C’è forse qualcosa che vi stona?
Davvero le user stories non si scrivono? Cosa intende dire Pugliese?

Pierluigi con questa affermazione provocatoria vuole ribadire che le user stories non sono semplicemente un modo un po’ diverso di esprimere i requisiti, un altro tipo di formato, bensì piuttosto un modo minimalista per descrivere le funzionalità e di semplificare la parte burocratica.

Questo approccio minimalista funziona a patto che la conversazione tra stakeholder, sviluppatori e Product Owner avvenga davvero.
La scrittura è secondaria; la card riassume la conversazione e non ne contiene tutti i dettagli, solo ciò che serve al team per ricordarsi cosa deve fare.

Capite bene che questo approccio definito lightweight dagli agilisti (= leggero) sta in piedi se e solo se una reale interazione avviene.
Se non c’è un momento di confronto e di approfondimento qualsiasi user story sarà monca, una promessa (di conversazione) non avvenuta.
E a quel punto nascerà inevitabilmente la richiesta di una maggiore documentazione.
Infatti una cosa che mi è spesso capitato di notare è che quando i team sono meno maturi tendono a utilizzare le storie come copertine di Linus e chiedono al Product Owner di specificare e dettagliare molto di più.

Quando ravviso questo comportamento so che è il momento di alzare le orecchie.
Può essere un indicatore rilevante del fatto che:

  • il chiarimento non è ancora avvenuto (la card non serve a eludere la conversazione)
  • Il vero valore dello strumento user stories non è stato compreso (siamo di fronte a una trasposizione dei vecchi documenti di requisiti)
  • il team demanda in toto la chiarificazione al PO (di questo aspetto ne parliamo più in là…)
  • c’è scarsa fiducia tra gli interlocutori (questo – se vero – è l’aspetto più problematico che richiede attenzione immediata).

Le parole di Pugliese per me sono sempre illuminanti…

Senza la conversazione le user stories non hanno senso. Non sono una religione alternativa per scrivere i requisiti! Se usate in maniera stupida, meccanica, inutile e dannosa fanno spegnere il cervello agli sviluppatori

Chi fa la business analysis?

Chi è l’owner della business analysis? La domanda sembrerebbe retorica… in fondo esiste una figura professionale proprio per questo, tuttavia negli Scrum team come sapete non ci sono singoli “detentori” di attività.
E’ un punto importante spesso poco capito. Nel team ideale tutti fanno tutto, o meglio sono in grado di fare tutto. Nella realtà spesso non è così perché le competenze e le seniority sono diverse, ma pratiche come il peer programming e le pair review ci vengono in aiuto facendo sì che la conoscenza di tutto il team aumenti progressivamente con il tempo.

La stessa cosa vale per l’analisi dei requisiti.
Magari date per scontato che il momento della chiarificazione dei bisogni sia appannaggio del Product Owner e del business analyst (se avete la fortuna di averlo) ma non è così!

“Voglio che il team faccia business analysis” – ha insistito il coach durante il meetup – “Più persone possibili devono saper fare le domande giuste e ovviamente devono avere competenze di dominio sufficienti per fare le domande giuste”.

Ma a cosa punta questo approccio? La finalità è avere una responsabilità condivisa dell’intero Scrum team sul risultato finale. L’analisi è una premessa fondamentale per fare la modellazione di un sistema attraverso le user stories.
Per questo motivo secondo Pugliese è un’attività che può essere portata avanti direttamente dal team con gli stakeholder senza necessariamente la presenza del Product Owner (ricordate quando si diceva di “smettere di fare il piccione viaggiatore”?)

Il vero ruolo del Product Owner

Ma se il product owner non scrive le storie e non fa chiarificazione – ha chiesto un partecipante – qual è esattamente il suo ruolo?
Esattamente quello che prescrive la Scrum Guide: essere il responsabile di massimizzare il valore prodotto.

Il PO non fa chiarificazione, può partecipare a questa attività ma non è il suo focus primario. Il product owner regola il sistema dal punto di vista delle priorità; decide cosa fare del backlog (se una storia entra, non entra e con quale priorità). In questo modo fa strategia di prodotto.
Impiegarlo solo per spiegare o scrivere le user stories è di fatto svilire questa figura a un lavoro di segretariato, quando invece il suo vero scopo è capire cosa c’è di valore e come massimizzarlo.

Non possiamo pensare che gli stakeholder si mettano d’accordo sulle priorità perché hanno solitamente interessi troppo diversi. Il team può chiarire autonomamente cosa vuole ottenere lo stakeholder, ma poi è con il PO che ci si confronta sulle priorità.
Non è compito degli sviluppatori, dei designer o degli analisti decidere cosa è più importante e cosa no.

Detto questo vi chiedo: nella vostra esperienza quanta parte del lavoro del PO è focalizzato sulla massimizzazione del valore e quanto sulla scrittura e la chiarificazione? Adesso che sapete qual è l’approccio più produttivo ed efficace avete voglia di condividerlo con i vostri team?

Le 3 C delle user stories: carta, conversazione e conferma

Oggi parliamo di storie, un grande classico per i product owner, e andiamo alla base della loro costruzione esplorando insieme le 3 C delle user stories: carta, conversazione e conferma.

Ma cosa sono le user stories? Sono semplici descrizioni, contenute in una frase, di ciò che un determinato utente vuole ottenere raccontate dal suo punto di vista.
Sono nate nell’ambito dell’Extreme Programming prima dell’inizio di questo millennio (la loro origine si fa risalire al 1998) e sono poi diventate popolari in tutti i processi agile.

User story: qualche esempio di scrittura delle card

Facciamo qualche esempio pratico per capirci meglio.
Immaginiamo di stare sviluppando un sito di annunci (i cosiddetti classified) che consente a venditori e acquirenti di scambiarsi beni materiali e servizi accordandosi tra privati.
La nostra piattaforma avrà user stories come queste:

  • come utente di <nome della piattaforma> , posso effettuare ricerche su articoli specifici.
  • come venditore, posso facilmente consultare la lista di tutti i potenziali acquirenti interessati al prodotto che ho messo in vendita.

Come vedete sono frasi brevi che descrivono cosa un utente vuole fare, raccontate secondo il suo punto di vista.
Un’altra cosa che possiamo notare è che abbiamo più tipologie di utenti: nel primo caso parliamo di un utente generico, nel secondo adottiamo il punto di vista di uno dei principali attori della piattaforma (in venditore).

Possiamo fare la stessa cosa mettendoci dal punto di vista dell’acquirente:

  • come potenziale acquirente di una macchina usata, voglio poter vedere delle foto del veicolo.

Cosa manca ancora in questo esempio?
Manca un dettaglio che per me è la parte più importante delle user stories, la cosiddetta clausola so-that.
Ciò che spiega perché un determinato utente vuole una certa cosa, qual è la sua finalità, qual è il risultato finale a cui tende (o outcome).

La storia potrebbe prendere allora questa forma:

“come potenziale acquirente di una macchina usata, voglio poter vedere delle foto del veicolo così da potermi accertare delle sue condizioni”

O dal punto di vista del venditore:

“come proprietario di un auto che desidero vendere, posso creare una pagina in cui descrivere lo stato dei veicolo e mostrarlo al suo meglio”

Notate che stiamo parlando della medesima funzionalità (le foto associate al prodotto) da due punti di vista differenti: quello del venditore e quello dell’acquirente.

User story: l’importanza del punto di vista

Bene, abbiamo introdotto il formato più classico con cui si scrivono le user stories:

Come <tipo di utente>, voglio <funzionalità> così da <obiettivo o valore per l’utente>.

Semplice ed efficace! Chiunque è in grado di esprimere un bisogno, una necessità o un desiderio secondo questo formato.
Ma non è solo la semplicità ad essere la chiave del successo delle user stories, l’elemento essenziale qui è la prospettiva: il punto di vista che adottiamo ci aiuta a relazionarci con specifiche tipologie di utenti, a metterci nei loro panni.

Sembra un dettaglio ma non lo è.
Ditemi se vi fa lo stesso effetto esprimere le medesime funzionalità come si descrivevano una volta nei documenti di requisiti …

  • il sistema consente all’utente di effettuare una ricerca
  • il sistema consente all’utente di pubblicare online un prodotto
  • il sistema consente all’utente di associare una o più foto a un prodotto

Il significato di queste affermazioni è lo stesso ma nel primo caso rispondiamo con più empatia perché stiamo mettendo l’utente – una persona – al centro della scena.

User story: la conversazione a partire dalla carta

Un errore in cui cadono spesso i team che muovono i primi passi con i framework agili è pensare che una volta scritta la user story tutto sia chiaro e definito.
In realtà chi ha un po’ più di esperienza alle spalle sa bene che la scrittura è solo l’inizio del gioco.
Non dobbiamo dimenticare che la user story comprende tre C:

  • una scheda o carta (= card),
  • la conversazione (= conversation)
  • criteri di conferma (= confirmation).

Le 3 C sono un’allitterazione ideata da Ron Jeffries per chiarire che una user story è più di un semplice testo scritto su carta fisica o su strumento software.
Le user stories sono brevi, non sono fatte per contenere molti dettagli bensì per agevolare delle conversazioni (si parla anche delle storie anche come “placeholder per conversazioni con il team”).
La carta è solo una delle tre C, la più visibile, e anche quella meno importante.

Mi è capitato in passato di lavorare con team che pretendevano di avere il massimo livello di dettaglio nelle storie; questo desiderio di chiarezza e completezza per quanto comprensibile dà l’illusione che tutto sia stato definito e compreso ma non aiuta le persone ad uscire dalla propria comfort zone e fare il “viaggio di scoperta” nei bisogni dell’utente.
E’ dall’interazione tra il product owner, il team allargato e gli utenti che nasce la vera comprensione di ciò che c’è da fare, non da una frase scritta su un pezzo di carta.

Non si tratta di un modo alternativo di scrivere requisiti, la card è “una promessa a due vie” come dice Mike Cohn:

  • la promessa del team di porre domande prima di iniziare a lavorare su una storia
  • la promessa del product owner di essere disponibile ad approfondire l’argomento.

Questi due aspetti insieme ci evitano di dover scrivere corposi documenti di specifiche contenenti ogni singola funzionalità.

Se il team si parla prima di iniziare a lavorare, il product owner può specificare solo quanto basta per poter avere quella conversazione.
E’ la conversazione in sé che rende agile un team, non la scrittura delle storie, l’utilizzo di post-it o di tool come Jira.

User story: la C di conferma

Quando Mike Cohn illustra questa parte delle storie dice che non gli piace iniziare qualcosa se non capisce come saprà quando ha terminato. E a chi piace questa incertezza?
I criteri di conferma di una user story servono proprio a questo; sono il modo in cui il product owner definisce insieme al team ciò che deve essere fatto affinché lo sviluppo possa essere considerato completo.

Ricordate quando a scuola per la prima volta un insegnante vi ha assegnato un riassunto di un libro? Alzi la mano chi non si è chiesto quanto dovesse essere lungo lo scritto!
Ecco, questo è un classico esempio di criterio di accettazione. Per alcuni professori una sintesi di una pagina è accettabile, per altri non si parla di sufficienza sotto le 3 pagine (e non pensate di barare con la dimensione del testo e l’interlinea!).

Una parte della conversazione tra il team e il product owner prima di lavorare una storia riguarderà proprio i criteri di conferma, ovvero come ciò che sarà sviluppato verrà valutato per l’accettazione durante la sprint review.
Si tratta delle “condizioni di soddisfazione” della storia. In altre parole, affinché il product owner possa considerare la user story fatta, una determinata cosa deve fare questo, quello e quell’altro.

Torniamo al nostro esempio di prima quando parlavamo della possibilità di associare delle foto all’auto che il nostro utente vuole mettere in vendita.
Per questa user story potremmo definire criteri di accettazione di questo tipo:

  • i formati di immagine accettati dal sistema (es. jpg, png, ecc.)
  • il peso massimo della singola immagine
  • la possibilità di vedere un’anteprima dell’immagine caricata
  • e magari anche la possibilità di poter ruotare eventuali immagini capovolte prima della pubblicazione.

User story: la prima C da sola non basta!

Siamo arrivati alla fine del nostro excursus sulle user stories.
Come abbiamo visto le storie non sono un nuovo modo di scrivere i requisiti, ma molto di più. Hanno come minimo 3 funzioni:

  • sono un placeholder per una conversazione sui bisogni degli utenti
  • sono strumenti per capire cosa vogliono gli utenti e cosa ha senso realizzare
  • sono un modo per programmare il lavoro del team.

Quindi ricordatevi di prestare attenzione a tutti e 3 gli aspetti: non solo al testo che andrete a scrivere su una scheda, ma anche alle conversazioni sulla funzionalità e ai criteri di conferma che utilizzerete per determinare se la storia è completa.

Note

Questo post è liberamente tratto dalle lezioni di Mike Cohn sulle user stories. Se volete approfondire vi consiglio il suo corso – molto valido – “Better User Stories“.

Nel blog trovate anche diversi post dedicati alle storie. Eccone qui una piccola selezione: