La metafora dell’ospite

Avete mai organizzato una festa?
Invitare le persone, preparare la sala, accogliere gli ospiti, divertirsi, pulire il giorno dopo…

E se vi dicessi che siete stati un ottimo esempio di Host Leader?

Parte proprio da questa metafora il lavoro sulla Host Leadership di Mark McKergow, che abbiamo avuto l’opportunità e il piacere di avere come ospite nel nostro ultimo meetup della community.

Il modello di leadership

Siamo partiti dalla consapevolezza che la leadership non è un ruolo, ma un modo di relazionarsi con gli altri, e i modelli di leadership tradizionali sono in qualche modo inadatti ad affrontare tutte le situazioni che troviamo nel mondo di oggi. Un mondo che è sempre più complesso, volatile, incerto e ambiguo.

Il modello di leadership a cui siamo abituati è quello del “leader come eroe”, sempre un passo avanti al gruppo. Perché a lui spetta il compito di ‘salvare’ gli altri. E’ l’eroe, in fin dei conti.
Contrapposto a questo approccio c’è quello del “leader come servo”, familiare a chi conosce il framework Scrum, che porta agli altri ‘cibo e acqua’ e resta un passo indietro.

Mark McKergow con la sua metafora del “leader come host” ci racconta che lo stile di leadership non ha una sola marcia – sempre avanti, come Leader Eroe o sempre indietro come il Leader Servo – ma è una danza continua – un passo avanti (step forward) e poi indietro (step back). Nel modello di Host Leadership, il leader è visto come il “conduttore di una festa” con il giusto mix di “Step Forward” e “Step Back” a seconda del momento specifico.

Organizziamo una festa!

Mark ci ha fatto ricordare tutte le volte in cui abbiamo organizzato una festa e abbiamo pensato a tutti i passi da compiere per assicurarci che la festa sia successo, ricordandoci che è altrettanto importante divertirci noi stessi nel farlo!

Sono usciti diversi punti nella sfera dello “Step Forward“, come invitare gli ospiti alla festa, dar loro il benvenuto quando arrivano nella nostra casa, intrattenere le persone durante la festa e creare connessioni fra gli ospiti. Ma ci sono anche dei momenti in cui l’host fa “Step Back“, come essere in cucina a preparare, osservare l’andamento della festa o riempire i bicchieri.

I sei ruoli

Successivamente Mark ci ha introdotto i sei ruoli che caratterizzano la Host Leadership e abbiamo provato ad associare ognuno dei momenti emersi nell’attività precedente ad uno tra i seguenti ruoli:

• L’initiator: sa cosa deve essere fatto e quali sono le priorità
• L’invitor: usa il “soft power” dell’invito e non dà ordini
• Lo space creator: crea le condizioni ideali per ciò che deve accadere
• Il gatekeeper: si accorda con il gruppo per decidere i limiti e le regole che è bene vengano rispettate
• Il connector: mette in comunicazione le persone, fa in modo che la comunicazione sia efficace
• Il Co-partecipator: agisce come effettivo membro del gruppo seguendone le regole

Dopo un approfondimento sui ruoli, abbiamo concluso l’incontro con una corposa sessione di Q&A durante la quale Mark si è reso disponibile a rispondere a tutte la nostre domande.

Prima di andare via…

C’è una piccola sorpresa per voi, abbiamo avuto la possibilità di registrare tutta la durata dell’evento e renderla disponibile alla community!

E non è tutto, insieme alla registrazione, trovate anche il link alle slide usate e ad un bellissimo visual recap fatto da Eleonora Della Bernardina!

Ringraziamo di cuore Mark McKergow per essersi reso disponibile e i numerosi partecipanti senza i quali l’incontro non sarebbe stato altrettanto interessante.

Alla prossima!

Link alle slide: https://agile.to.it/wp-content/uploads/2023/03/Agile-Turin-HL-session-2023.pdf
Link al visual recap: https://agile.to.it/wp-content/uploads/2023/03/Host_Leadership_Visual_Recap.pdf

Registrazione:

[This post contains video, click to play]

— English version —

The host metaphor

Have you ever hosted a party?
Inviting people, preparing the room, welcoming guests, having fun, cleaning up the next day…

What if I told you that you were a good example of a Host Leader?

This metaphor is the starting point for the work on Host Leadership by Mark McKergow, whom we had the opportunity and pleasure to have as a guest at our last community meetup.

The leadership model

We began with the realization that leading is not a role, but a relationship, and traditional leadership models are somehow unsuitable to deal with all the situations we find in today’s world. A world that is increasingly complex, volatile, uncertain and ambiguous.

The leadership model we are used to is the ‘leader as hero‘, always one step ahead of the group. Because it is up to him to ‘save’ others. He is the hero, after all.
On the other hand there is the ‘servant leader‘, well known to those familiar with the Scrum framework, who brings others ‘food and water’ and stays one step behind.

Mark McKergow with his metaphor of the ‘leader as host‘ tells us that the leadership style does not have only one gear – always forward as the Hero Leader or always backward as the Servant Leader – but is a continuous dance – one step forward (step forward) and then backward (step back). In the Host Leadership model, the leader is seen as the ‘host of a party’ with the right mix of ‘Step Forward‘ and ‘Step Back‘ depending on the specific moment.

Let’s have a party!

Mark reminded us of all the times we have thrown a party and thought about all the steps we need to take to make sure the party is successful, reminding us that it is just as important to have fun ourselves while doing it!

Several points came up in the “Step Forward” sphere, such as inviting guests to the party, welcoming them when they arrive at our place, entertaining people during the party, and making connections among guests. But there are also times when the host does “Step Back“, such as being in the kitchen preparing, observing the progress of the party or filling glasses.

The six roles

Next, Mark introduced the six roles characterizing the Host Leadership, and we tried to associate each of the steps that emerged in the previous activity with one of the following roles:

• The initiator: knows what needs to be done and what the priorities are
• The invitor: uses the “soft power” of the invitation and does not give orders
• The space creator: creates the ideal conditions for what needs to happen
• The gatekeeper: agrees with the group to decide the boundaries and rules that should be followed
• The connector: connects people, makes sure that communication is effective
• The co–participator: acts as an effective member of the group by following the rules

After an in-depth discussion of roles, we concluded the meeting with a large Q&A session during which Mark was available to answer all our questions.

Before we leave…

There is a little surprise for you, we had the opportunity to record the entire event and make it available to the community!

And that’s not all, along with the recording, you will also find a link to the slides used and a beautiful visual recap done by Eleonora Della Bernardina!

We sincerely thank Mark McKergow for making himself available and the many participants without whom the meeting would not have been as interesting.

Until next time!

Link to the slides: https://agile.to.it/wp-content/uploads/2023/03/Agile-Turin-HL-session-2023.pdf
Link to the visual recap: https://agile.to.it/wp-content/uploads/2023/03/Host_Leadership_Visual_Recap.pdf

Recording:

[This post contains video, click to play]

Stefano

More Posts

Follow Me:

L'articolo Host Leadership con Dr Mark McKergow! proviene da Agile Community Torino.

La nostra giornata tipo 

Come si esplora User Story Mapping?

Semplice! All’incontro del 30/11/2022 al Toolbox con Jacopo Romei abbiamo risposto ad una domanda “Cosa fai per uscire di casa per andare al lavoro?” 

Si scopre come ognuno dei partecipanti da quando spegne la sveglia a quando varca la soglia di casa ha i suoi passaggi, si beve un caffè ancora prima di alzarsi, si porta il cane ancora prima di essersi tolto il pigiama, tante abitudini diverse.

Messi insieme tutti questi passaggi, trovata una linea comune con tutti i partecipanti (user) abbiamo sviscerato la nostra Epica “Cosa fai per uscire di casa per andare al lavoro?”. Perfetto!   

Ora inizia la sfida! 

Ora però la cosa si complica …. Hai 5 minuti per andare al tuo appuntamento di lavoro, quali passaggi salti? E così saltano doccia e caffè, ci vestiamo per non andare in pigiama, ma il cane ahimè poverino rimane in casa ad aspettare e via si corre all’appuntamento! Ecco qui! Scopriamo di avere in mano la nostra prima release, un primo MVP che abbiamo chiamato “Fretta”.

E tutto il resto delle cose che abbiamo trascurato? Beh! abbiamo un prossimo MVP che si chiama “Decenza” che ha dentro il lavaggio personale minimo faccia/denti e finalmente portiamo giù il povero cagnolino! 

Si però una doccetta non farebbe male… vero! Ed ecco il prossimo incremento MVP “Civiltà” una bella doccia completa!

Un po’ di attività

Fatta un po’ di pratica tutti insieme è arrivata l’ora di sperimentare in prima persona, divisi in gruppi abbiamo provato a ipotizzare il primo MVP di Twitter. 

Post-it colorati, pennarelli e i tavoli si sono riempiti di idee! 

Idee che poi abbiamo condiviso tutti insieme… Ci sono stati tavoli di “introspettivi” che come primo MVP hanno ipotizzato alla condivisione di pensieri tra sè e sè, fino ad arrivare a tavoli “legali” in cui il pensiero lo condivido con il mondo ma c’è bisogno di un account perchè c’è una normativa dietro. 

L’arte dello User Story Mapping

Quindi? Qual è la giusta regola più introspettivi o più legali? 

Jacopo ci ha aperto al mondo della magia: “il set delle cose da suddividere e come le si suddivide è arte non è scienza!”

E così ci portiamo a casa questa magia per sperimentare lo User Story Mapping il prima possibile nella nostra prossima epica!

Concludiamo con qualche foto dell’evento

Giada.pallavicini

More Posts

L'articolo Esploriamo User Story Mapping! proviene da Agile Community Torino.

C’era un indovino, un divinatore, un mago dell’ultimo minuto che, con un turbante in testa, leggeva i tarocchi. Era il 12 novembre 2021 alle ore 15.20 e questo losco figuro presentava un gioco per l’unconference di Italian Agile Days 2021, gioco prodotto dall’Agile Community Torino per affrontare un tema emerso più e più volte durante le conversazioni ai meetup e gli incontri agili: “taroccare” il mindset agile, nascosto dietro una facciata di  Scrum per metterlo al servizio delle organizzazioni che si illudono di usarlo come strumento di controllo delle persone. Come se questo servisse a creare più valore e maggiori risultati!

Ecco, questo l’argomento provocatorio, trattato in modo ironico, totalmente non convenzionale e innovativo utilizzando un gioco che andremo a descrivere qui brevemente. Vedremo anche palle di cristallo, tarocchi, esoterismo, divinazioni e altro, ci sarà da divertirsi.

Il gioco lo vogliamo rilasciare con una licenza libera (tipo free software, copyleft) per cui al fondo di questo articolo troverete un link da cui partire per utilizzare il gioco e migliorarlo, mi raccomando, scriveteci e proponeteci questi improvement!

Ma andiamo per gradi.

Com’è andata

La Agile Community Torino, in una formazione composta dai magnifici 7 che hanno accettato di affrontare questa sfida, ha iniziato con il presentarsi, attraverso un video auto-prodotto:

[This post contains video, click to play]

Raccontiamo ora com’è andata la prima sessione pubblica del gioco, palla di vetro alla mano…

Il gioco giocato

Titolo del gioco: Come ti tarocco Scrum

Abstract: E’ il tipico “peccato originale” che le organizzazioni commettono: utilizzare Scrum per raggiungere l’illusione di CONTROLLO. In alcuni casi è inconsapevole. Con questo gioco ti aiuteremo a prendere coscienza di questo scempio e se vincerai ti daremo la formula della felicità!

Si ma come si gioca? Come lo abbiamo fatto?

Qui elencati gli elementi principali del gioco raccontati all’inizio della sessione di 25 min:

• Chi può giocare? SM, PO, Dev (soprattutto sviluppatori). 7 giocatori al massimo
• Come si vince? Chi fa più punti vince
• Come iniziare a giocare? Siediti e punta su una o più carte (di cui si vede solo la figura simbolo dei tarocchi) le tue tre monete, preferendo le carte che a istinto riconosci nella tua esperienza lavorativa
• A cosa fare attenzione? Imprevisti a sorpresa (poi si capirà che si può pestare una merda secca :-))
• Durata? 25 min timebox
• Cosa si vince? Curiosoni, lo saprete alla fine! (nel nostro caso abbiamo messo in palio una copia del libro “Live Happily Ever After Without Projects: A #noprojects Book” di Dimitri Favre, sembrava proprio la formula del felici e contenti per sempre!)

Il campo di gioco si presentava quindi così:

Dopo che i 7 concorrenti hanno puntato le loro monete, abbiamo cominciato a scoprire man mano le carte, privilegiando le più puntate e cercando di dare a tutti i giocatori la possibilità di partecipare raccontando la propria esperienza, speriamo di esserci riusciti.

Scoprendo una carta alla volta, veniva recitata la predizione e i concorrenti dovevano riconoscere se fossero stati affetti dalla “taroccata”. Se ben convincenti, attraverso la breve storia raccontata, avrebbero guadagnato il punteggio indicato sulla carta stessa.

Un esempio:

Conclusione del gioco e premi

Dopo un po’ di giri, allo scadere del timebox predefinito, è il giocatore con il punteggio più alto a vincere. Nel nostro caso ne abbiamo avuti tre!!! E nemmeno uno spareggio ha risolto la situazione: i vincitori sono stati tre con lo stesso punteggio! Quindi li abbiamo proclamati tutti e tre vincitori e abbiamo dato il premio a ciascuno, se lo sono meritato

Ecco il premio vinto da 3 fortunati, la formula magica per vivere felici per sempre (fortunati? non saprei…):

Come valutare l’esperienza dal punto di vista di chi ha proposto questa attività non convenzionale? Noi ci siamo molto divertiti ed è stato un modo per mettere in contatto in modo diretto e attivo i componenti della community (che hanno creato le carte e le hanno raccontate durante il gioco) e qualcuno dei partecipanti alla conferenza. Un modo nuovo per poter connettere anche in virtuale, costretti ad interagire per mezzo di un dispositivo elettronico.

Feedback che ci hanno regalato gioia

Dimenticavo, sembra che il gioco sia piaciuto molto e abbiamo ricevuto tantissimi feedback, qui alcuni simpatici. Fateci sapere se siete tra coloro che hanno apprezzato o avete feedback differenti.

Come abbiamo creato il gioco

Il team “di prodotto” si è incontrato durante le settimane precedenti IAD 2021 e, dopo un brainstorming iniziale, è emerso il concetto di “Scrum tarocco”, su cui il team ha lavorato per iterazioni settimanali, sviluppando i contenuti (le disfunzioni dello Scrum tarocco e la loro descrizione in termini “divinatori”) e le dinamiche di gioco, testate sul campo con esperimenti, a cui hanno fatto seguito discussioni e aggiustamenti.

Tarocco libero! Gioco utilizzabile in copyleft

Il gioco è rilasciato con licenza totalmente free, copyleft. Per usarlo ti chiediamo solo questo, chiaramente non è obbligatorio, a tuo buon cuore:

1. Mantieni il logo e l’indirizzo di agile community torino
2. Se hai dei feedback o dei miglioramenti ti preghiamo di condividerli (https://agile.to.it)
3. Fai o fai fare una piccola donazione per la community (https://paypal.me/pleinadIT)

Dopo questo doveroso preambolo, qui il materiale visionabile e scaricabile:

• Link alla baord in lettura: https://miro.com/app/board/o9J_lh3b7D4=/
• Backup della board: https://agile.to.it/video/Copyleft%20Come%20ti%20tarocco%20Scrum.rtb

Per poterlo usare, sarà sufficiente ripristinare il backup di miro su un proprio account personale. Ricorda di condividere se fai modifiche significative che funzionano: per farlo, utilizza i link sulla board.

Buon divertimento e grazie per la lettura!

Agile Community Torino

Siamo una community di appassionati del mindset Agile e Lean. Lavoriamo professionalmente in questo contesto come Scrum Master, Product Owner o Coach agile. Alcuni di noi invece sono semplici curiosi che vogliono capire meglio di cosa si tratta e come applicare principi e pratiche sul lavoro e nella vita di tutti i giorni... Siamo una tribù in continua crescita in un territorio (il Piemonte) dove questi valori e principi stanno diventando sempre più diffusi e popolari. Speriamo di contribuire alla loro affermazione!

More Posts - Website

L'articolo Come ti tarocco Scrum – Italian Agile Days 2021 proviene da Agile Community Torino.

Nato come strumento di analisi per la realizzazione di software, EventStorming può essere usato più in generale per analizzare i processi di business, identificare punti critici, opportunità di miglioramento. In particolare, permette di mettere in relazione tra loro ambiti di business diversi che altrimenti non si parlerebbero e creerebbero un fattore di rischio per il progetto software o per l’intero business.

In quali contesti si usa EventStorming

Dal punto di vista dello sviluppo software, EventStorming nasce come strumento di facilitazione per affrontare lo sviluppo di un’applicazione usando i principi del Domain-Driven Design, il cui obiettivo è identificare e analizzare il dominio del problema da risolvere prima di fare considerazioni implementative.
Per fare questo, è necessario mettere insieme e fare interagire le competenze di stakeholder con diversi background e una delle caratteristiche più importanti di EventStorming è quella di permettere questa interazione, senza richiedere competenze specifiche sul formato ai partecipanti (solo il facilitatore deve conoscerne le “regole”).
Il prodotto di questa progettazione è un “modello”, che costituisce la base (spesso espressa come codice o altri artefatti software – classi, interfacce, se si lavora con OOP) per lo sviluppo dell’applicazione.

Ma l’ambito di applicazione di EventStorming non si limita allo sviluppo di software, si presta anche all’utilizzo per altri scopi, come: analizzare il flusso di business di un’organizzazione per identificare gli impedimenti e capire come produrre valore rilevante; esplorare il mercato in cui si colloca una nuova impresa e pianificarne la crescita/evoluzione; progettare nuovi servizi in modo collaborativo.

Come si fa

Un workshop realizzato in EventStorming inizia creando uno ampio spazio di lavoro costituito da una lunga striscia di carta, a cui verranno attaccati (e spostati) dei post-it. La superficie deve essere abbondante, non basta un singolo foglio perché, andando ad analizzare processi complessi e facendo partecipare quanti più stakeholder possibile, deve essere possibile, almeno inizialmente, mappare un gran numero di event.

Gli event sono infatti il punto di partenza del workshop: una volta definito l’ambito dell’analisi e quindi quale dominio si vuole descrivere e definire, i partecipanti devono pensare e trascrivere su post-it dello stesso colore (arancione) dei singoli event rilevanti, che si posizionano in un’ideale linea temporale e/o logica.
Dopo questa prima fase, inevitabilmente “storming”, il facilitatore può affidare al gruppo o eseguire di persona un walkthrough della narrativa che gli event compongono sulla superficie di modellazione; in questo momento si verifica che gli event siano effettivamente in ordine, si fa “clustering”, ed è auspicabile che emergano degli event “pivot”, cioè dei momenti chiave nella linea temporale, che possono marcare anche confini tra parti più o meno discrete del flusso del processo. Gli event pivot sono marcati usando un pezzo di nastro adesivo verticale che parte appunto dall’event (o da un cluster).

Inoltre, durante il walkthrough, i partecipanti al workshop possono discutere di tutto quello che riguarda gli event presenti sulla superficie: la loro posizione nella timeline, la loro rilevanza, ecc. Questo aiuta a far emergere conoscenze implicite che, se non condivise – soprattutto tra stakeholder con background diversi, possono portare a incomprensioni e quindi a problemi implementativi.
Il riepilogo della narrativa del processo è qualcosa che va eseguito diverse volte durante il workshop, per stimolare commenti e validare collettivamente l’analisi svolta. Le linee narrative possono diventare più d’una mentre la discussione tra i partecipanti si sviluppa.
Il facilitatore non dovrebbe necessariamente guidare verso un completamento del modello: l’obiettivo della completezza potrebbe non aver valore per tutti i partecipanti e in alcuni casi spaventarli o frustrarli quando non fosse raggiunto. L’obiettivo vero è quello di imparare più cose possibili nel minor tempo possibile.

Altri elementi del modello

Sulla superficie del modello trovano posto diversi event e altri elementi

Nell’incontro in cui abbiamo provato EventStorming insieme a Jacopo, abbiamo utilizzato uno dei diversi formati in cui si può articolare il workshop, detto “Big Picture”. In questo formato, l’obiettivo è descrivere un’intera linea di business per averne una visione d’insieme, con l’obiettivo primario di superare le suddivisioni organizzative in “silos”. Questo formato si concentra sull’identificare gli event del dominio e nel sistemarli sulla timeline, tracciando event pivot e discutendo criticità e contesti, risolvendo eventuali ambiguità nel linguaggio usato per descrivere le parti del processo.
Se si opera in un ambito più strettamente di sviluppo software, conviene passare a un modello più articolato, che per ogni event cerca di descrivere i command che lo provocano (azioni degli utenti, interazioni con altri sistemi, il tempo che passa…) e gli aggregate (concetto familiare a chi già pratica DDD).

Mappando un dominio complesso come può essere un’intera linea di business rappresentata in un workshop “Big Picture”, si arriverà a identificare dei bounded context, modelli coerenti al loro interno – anche nell’uso del linguaggio e dei termini, con aree di confine e talvolta di sovrapposizione con altri modelli “confinanti”, con cui si creano aree di conflitto (linguistico/semantico, di competenze, di responsabilità…).

Quando si trova un’area di conflitto o di incertezza, questa deve essere annotata nel modello con un post-it di colore diverso (fucsia). Questo è uno dei motivi per cui bisogna usare una sola grande superficie per il modello: inizialmente, gli esperti provenienti dai loro “silos” creeranno sequenze di event relative o rilevanti per il loro bounded context, ma presto emergeranno i confini tra questi context e le relazioni tra essi obbligheranno ad avviare conversazioni fruttuose.
Nel proseguimento del workshop e della discussione, emergeranno le strutture che costituiscono il modello, gli utenti, i sistemi ed emergerà il consenso su quali siano i problemi principali da risolvere.

Risorse

• https://www.eventstorming.com/resources/
• http://ziobrando.blogspot.com/2013/11/introducing-event-storming.html
• https://www.slideshare.net/ziobrando/50000-orange-stickies-later
• https://martinfowler.com/tags/domain%20driven%20design.html

Marcello Testi

More Posts

L'articolo Introduzione a EventStorming proviene da Agile Community Torino.

Un altro successo della Community!!

Di cosa sto parlando? Ma naturalmente del Mini #Play14 che si è tenuto sabato 9 marzo presso i locali di Cascina Roccafranca a Torino!!

La partecipazione è stata numerosa e il coinvolgimento totale, grazie anche ai due moderatori (oserei dire trascinatori) Antonio Fazio e Francesco Pratolongo.

Ci siamo divertiti un sacco, abbiamo giocato, pensato e imparato.

Quali erano i giochi? Non è importante. L’importante è il come.

Tornare bambini fa piacere a tutti e vedere persone adulte che giocano come se fossero dei “mocciosetti” fa sorridere.

Quando l’atmosfera è giocosa non si pensa alle sfide o a primeggiare: questo rende liberi di agire e anche di sbagliare senza remore, liberando così il pensiero laterale.

È stato dimostrato, infatti, che in alcune attività ludiche i bambini superano gli adulti in prestazioni, proprio perché per loro non si tratta di una sfida, ma di un momento di divertimento e di aggregazione. Nulla di più.

Ma allo stesso tempo sappiamo che per i più piccoli il gioco è un momento fondamentale di crescita e di apprendimento.

Ed è proprio questo aspetto che viene sfruttato nel #Play14: il gioco diventa momento per imparare a liberarsi, a stare con gli altri, a ricaricarsi di energia positiva.

Risultato? Eccolo!!!

Nicola

More Posts

Follow Me:

L'articolo Mini #Play14 sbarca a Torino proviene da Agile Community Torino.

“Le ricerche non lasciano spazio ai dubbi: le persone felici fanno meglio, a casa, sul lavoro e nella vita. Guadagnano di più, hanno posizioni migliori, si laureano e vivono più a lungo. […]. Sono migliori praticamente in tutto. […]. Proprio così. Le persone non sono felici perché hanno successo; hanno successo perché sono felici”.

Queste parole da allora continuano a tornare nella mia mente.

Lo scorso 10 marzo ho partecipato al mini IAD di Bari e, leggendo il titolo del talk: “Felicità e produttività: come un’azienda più felice arriva ad aumentare la propria produttività”, mi sono detto: “È il mio talk!”.

Lo speaker, Nunzio Gianfelice (nomen omen), ha mostrato con l’aiuto di alcune slide come felicità e benessere generale siano strettamente collegati e come, in particolare, ci sia un nesso fra felicità e produttività (www.nunziogianfelice.it/miniiadba.pdf).

La felicità permette al nostro cervello di entrare in uno stato positivo, che induce produzione di dopamina che a sua volta attiva di tutti i centri nevralgici, migliorando l’apprendimento, il controllo dei muscoli, il sonno, ecc.

Il risultato finale è un miglioramento delle nostre capacità, della creatività e della produttività fino al 31%!

Ma come si fa a rendere una persona felice sul luogo di lavoro?

Dagli studi effettuati è emerso che i fattori principali che rendono una persona felice sul luogo di lavoro sono la motivazione, il benessere di gruppo e la soddisfazione.

Una persona deve essere motivata a fare qualcosa, deve trovare persone di cui fidarsi e con cui sta bene, deve essere soddisfatta di quello che fa e di come lo fa.

Ma cosa vuol dire essere soddisfatto? E cosa vuole dire essere insoddisfatto?

Per comprenderlo meglio, un aspetto da non sottovalutare sono i cosiddetti falsi contrari.

Se vi chiedessi qual è il contrario di dolce, molti istintivamente  risponderebbero salato; ma se un caffè zuccherato è dolce, un caffè senza zucchero è salato?

No, un caffè senza zucchero è amaro.

Quindi il contrario di dolce è amaro, non salato e, d’altra parte, il contrario di salato è senza sale, insipido.

Allo stesso modo il contrario di soddisfatto è NON soddisfatto, il contrario di insoddisfatto è NON insoddisfatto. Questo perché essere NON soddisfatti non vuol dire essere insoddisfatti, sono due concetti diversi.

Le “non insoddisfazioni” sono legate all’ambiente lavorativo inteso in senso fisico, sociale, alla sicurezza del lavoro, alla sua remunerazione.

Le “soddisfazioni” sono legate, invece, agli obiettivi raggiunti, al lavoro svolto, alle mansioni ricoperte, alle responsabilità.

E allora, a quale conclusione giungiamo?

Possiamo dire che per rendere una persona felice bisogna creare un ambiente accogliente, creare connessioni fra colleghi in modo che si parlino, si scambino idee e creino gruppo, bisogna responsabilizzarli dando loro la possibiltà di scegliere, di decidere e anche di sbagliare, di parlare senza paura, fare in modo che nasca dentro  di loro l’iniziativa, che siano motivati ad agire senza che qualcuno necessariamente li sproni, senza KITA (Kick In The Ass).

Due esempi per tutti:

1. La Zappos, azienda leader nelle vendite online e con il miglior customer care al mondo (un dipendente felice trasmette felicità ai clienti), ha chiuso tutte le uscite dell’azienda tranne una per fare in modo che i dipendenti si incontrassero durante le pause o durante l’entrata e l’uscita.
2. La 3M dà due ore al giorno (e ribadisco al giorno, non a settimana o al mese) ai propri dipendenti per sviluppare dei propri progetti: da uno di questi progetti è nato il “post-it”, famoso in tutto il mondo.

Questo è creare felicità, soddisfazione e non insoddisfazione.

E la produttività crescerà di conseguenza.

Nicola

More Posts

Follow Me:

L'articolo Felicità e produttività proviene da Agile Community Torino.

È vero che le riflessioni sull’approccio agile alla gestione dei prodotti abbondano, in rete e in mille libri di carta, e che il mondo non è certo in ansiosa attesa di quel che sto scrivendo, però credo che ci siano due tipi di lettori per cui quanto segue può essere di qualche utilità:

1. il curioso esploratore che è attratto dalla mitologia che la parola agile evoca e che potrebbe essere emotivamente sfidato dal titolo,
2. chiunque viva la sfida quotidiana del lavoro agile, si chieda come diavolo sia possibile che qualcuno ci creda e provi sollievo nel leggere quel che il titolo afferma.

Inoltre: se, caro lettore, non ti identifichi nei due tipi di cui sopra, a maggior ragione vorrai arrivare fino all’ultima frase, perché in un qualche tuo personalissimo modo hai probabilmente percorso o stai percorrendo i miei stessi sentieri.

Torniamo ora al titolo con una domanda di buon senso: dal momento che la parola agile è definita da un manifesto ragionevole e virtuoso (cari lettori 1. e 2., lo conoscete, vero?), perché vietare ragionevolezza e virtù?

Obiezione facile da smontare.

Perché il manifesto è un punto d’arrivo: il risultato di un viaggio che troppo spesso è presentato, al contrario, come punto di partenza, come se nominare la meta compiendo il primo passo annullasse l’esigenza di percorrere la strada che porta alla meta stessa. Con il risultato di non arrivarvi mai.

Il divieto di dire agile non va dunque inteso come una censura dell’agilità, ma come volontà di preservarne la natura di visione del mondo, opposta a slogan da televendita che troppo facilmente e gratuitamente si fanno annunciare.

Bene, dirai forse, caro lettore, ed ora che abbiamo bandito la parola agile come fai a parlarne?

Domanda ottima.

Se ricordi la metafora del primo passo del viaggio, qualche riga fa, non ti sarà difficile scorgere la risposta: vietiamo di nominare la meta per concentrarci sulla scelta del primo passo.

Il primo passo, senza il quale il viaggio non può iniziare, è il valore.

Qualche lettore particolarmente attento e preparato potrebbe obiettare che il primo principio del manifesto mette al centro il cliente: non dovrebbe essere il cliente il punto di partenza?

No: anche il cliente è un punto di arrivo. Finché non esiste un prodotto, per cui qualcuno sia disposto a pagare in quanto ne riconosce il valore, non esiste nemmeno un cliente, se non come astrazione nella mente degli amici dell’ufficio marketing.

Occupiamoci quindi della Cenerentola del business: il valore.

Come Cenerentola, il valore va scoperto sotto la cenere della percezione: si tratta di un punto di partenza difficile (“challenging” direbbe qualche anglofono), dal momento che non è evidente con precisione di che cosa si parla e, in aggiunta, il tempo che è necessario dedicarvi è tutt’altro che trascurabile.

Chi conosce Scrum, così come altri approcci agili (ops, mi è scappato, prometto di non usare più la parola vietata), sa che a tutela e massimizzazione del valore di un prodotto è definito addirittura un ruolo apposito: il Product Owner. Chi non conosce Scrum può affidarsi all’altisonanza del nome: si tratta del prodotto fatto persona, colui che ha in mente il risultato da raggiungere e guida alla sua realizzazione.

Bene, dirai forse un po’ spazientito, ma in concreto che cos’è il valore?

Fornire questa risposta, sia in termini oggettivi misurabili sia in termini di percezione è il compito specifico del Product Owner di uno specifico prodotto: nella definizione del valore si sintetizzano visione, obiettivi economici, strategie, valori etici ed altri aspetti peculiari di quel prodotto in una ricetta unica.

Ora sei forse ancora più spazientito perché ti sembra che stia eludendo la domanda, ma se fai un passo indietro (e un bel respiro) puoi accorgerti che implicitamente la risposta è tra le righe di quanto già detto.

Il valore di un prodotto misura, qualitativamente e quantitativamente, la sua ragione di essere realizzato. Il valore è la sintesi dei motivi per cui il team che lo realizza prima ed il cliente poi credono nel prodotto stesso.

Non è rilevante se il valore del prodotto sia prevalentemente di natura economica o etica o strategica o una sapiente miscela di tutte quelle o altre componenti: ciò che conta è che il valore sia formulato opportunamente.

Il valore può essere formulato compiutamente da decine di pagine di documenti, ma deve saper convincere in non più di 30 secondi. Una o due frasi, non di più, devono essere sufficienti ad evocarlo in modo da suscitare il desiderio del prodotto.

Il valore infine va pensato come ciò che il prodotto realizza quando è nelle mani del cliente, quindi va pensato al di sopra del prodotto stesso, che è soltanto un mezzo.

Durante la realizzazione del prodotto i cambiamenti di piani e requisiti sono benvenuti (vedi il già più volte citato manifesto) proprio perché l’obiettivo non è realizzare il prodotto, mero strumento, bensì erogare valore al cliente.

Bene: siamo a giro di boa del ragionamento.

A questo punto possiamo togliere il divieto di dire agile: abbiamo individuato l’essenza dell’approccio agile (benvenuti i cambiamenti di piani e requisiti) nella differenza sostanziale tra il prodotto (punto di arrivo) ed il valore (punto di partenza) che esso eroga al cliente.

Dovrebbe essere più complicato ora fraintendere che cosa sia agile.

Nota bene che la flessibilità dei requisiti del prodotto è un aspetto essenziale dell’agilità, ma non l’unico (scorrendo il manifesto si possono trovare tutti). Questo articolo non mira alla completezza, ma a sottolineare con un ragionamento che agile non si riferisce ad una procedura che possa essere introdotta a comando (in questi casi varrebbe ben la pena di vietare la parola agile), bensì ad una visione del mondo imprenditoriale in cui tutti, team che produce e cliente che consuma, sono orientati al valore ben più che al prodotto.

Eccoci alla fine, caro lettore.

Termino il mio articolo evocando un altro pilastro dell’agilità: penso che ciò che ho scritto fin qui sia condivisibile, ma non di meno è possibile che tu non sia d’accordo.

Dove starebbe quest’altro pilastro, dirai tu?

Nella trasparenza: questo articolo non sottintende nulla e tutto è sul tavolo in bella vista in modo che possa essere eventualmente smontato, perché ciò che ha valore non è aver ragione, ma avanzare nella comprensione.

Luca Vettor

Luca V

More Posts

L'articolo Vietato dire “agile” proviene da Agile Community Torino.