Agile Life

settembre 2013 - Post

Servant Leadership

 contesti aziendali sono realtà complesse che si reggono su equilibri delicati, oltre che su regole esplicite ed implicite.

Come abbiamo più volte ribadito, la volontà di abbracciare un approccio Lean (o Agilenello specifico mondo dell’IT) porta con se la necessità di una profonda revisione delle dinamiche interne e a un ripensamento dei vari ruoli.

Scavando nelle origini di Lean, arrivando al Toyota Production System (TPS), troviamo un concetto rivoluzionario nella tipica catena di comando: il Leader Servente. Proprio in Toyota si delinea questo nuovo ruolo dei manager il cui compito non è quello di controllare e comandare (command-and-control) bensì essere al servizio della propria squadra, risolvendo gli impedimenti nel raggiungimento degli obiettivi.

servant leader bridge

 

Proprio da tale assunto parte Robert Grennleaf, il primo a coniare il termine Servant Leadership:

“The servant-leader is servant first…It begins with the natural feeling that one wants to serve, to serve first... Drinkso those served grow as persons; do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants?”

Chiaramente il “voler servire” non deve essere confuso con il concetto di “servitù” che indica un individuo in una posizione inferiore e che dà origine ad una obbligatorietànell’azione e non una volontà.

Adottare una Servant Leadership è difficile, così come lo è adottare Lean (ed Agile)!

Si tratta di una leadership più evoluta che riconosce il valore delle persone, le coinvolge pienamente negli obiettivi aziendali, ne valorizza l’operato e consente di abbracciare pienamente la Mission aziendale.

Alcune differenze evidenti tra le due tipologie di leadership possono essere schematizzate nella tabella seguente.

 

Command & Control

Servant Leadership

Metafora Aziendale

L’organizzazione è una macchina

Struttura guidata dalle relazioni tra le persone

Autorità

Top down

Partecipativa

Persone

Strumenti di produzione

Le Risorse più importanti per l’azienda

Stile di Leadership

Distante e Distaccato

Connesso e Presente

Approccio di Verifica

Imporre, controllare, punire

Ascoltare, facilitare, incoraggiare

Inquadramento della propria funzione

Self-serving – Cosa puoi fare per me e per l’organizzazione?

Other serving – Cosa posso fare per aiutarvi a raggiungere gli obiettivi, aziendali e personali?

 Lo stile "servente" è basato sull'assunzione olistica che le persone, una volta messe a proprio agio ed in rete tra loro, creano maggior valore della semplice somma dei risultati singolarmente ottenuti. Per questo, uno dei compiti fondamentali di un Leader "servente" è quello di favorire una ricca rete di relazione dei propri collaboratori (non chiamateli subordinati!) e generare continuamente nuovo Valore per l'azienda, per gli stakeholder, per i collaboratori stessi e per se.

servant leader traits

Tratti caratterizzanti un Servant Leader

 

[FELICEPESCATORE.IT]

Posted: 30 set 2013 9:13 da felice.pescatore | con 1 comment(s)
Inserito sotto: , , ,
DAD, a Cross Functional Team

In uno dei precedenti post abbiamo evidenziato l’importanza e la complessità del ruolo del Team Lead e le sue caratteristiche non esclusivamente tecniche.

Ma, come si sposano le figure tipicamente presenti in un azienda IT (business analyst, programmatori, solution architecttesterproject manager, ecc) con quelle presenti in DAD (team memberteam leadarchitecture owner, descritti nel post “DAD, Ruoli e Skill professionali”) e con il concetto di Cross Functional Team?

dad roles

DAD Roles

Rivedere il proprio ruolo, le proprie attività e, perché no, la propria posizione, è chiaramente una sfida importante per ogni persona all’interno di un azienda che inizia il difficile viaggio di adottare DAD (e più in generale un processo Agile).

Con DAD il concetto di “singolarità” scompare in favore del concetto di “insieme”, in cui è il Team ad essere responsabile del successo o dell’insuccesso del progetto, non il singolo componente.

Sicuramente, all’inizio, il DAD Team verrà formato partendo dalle professionalità già esistenti, e ogni membro cercherà di dedicarsi all’attività che conosce meglio. Ad esempio: l’analista cercherà di effettuare attività di analisi del dominio, mentre il programmatore si concentrerà maggiormente sulla parte di sviluppo. Questa situazione è però destinata a mutare velocemente se DAD viene applicato in maniera convinta, grazie alle continue interazioni tra i vari componenti del Team e la comprensione di una responsabilità condivisa su tutto il lavoro. Ciò porta ad avere persone con skill orizzontali (T-Skilled), portando beneficio al progetto, all’azienda e al proprio know-how individuale.

Ben presto espressioni del tipo:

            “Sono un tester, e come tale sono responsabile delle attività di test”,

verranno sostituite con:

            “Essendo un Team, vediamo come approcciare il testing”

che conserva la specificità dell’attività da realizzare, ma la affronta da una prospettiva completamente diversa che è quella del Valore e non del task associato al proprio ruolo.

 

Ricordate: DAD è Value Driven e ciò che conta è sempre produrre “Valore”.

 

 [FELICEPESCATORE.IT]

La difficile Arte della stima

Una delle attività più complesse annesse alla definizione di progetto software è la stima dei tempi, e quindi dei costi.

Tale stima, sia che si gestisca il progetto secondo i dettami Agili che secondo i dettami del project management più tradizionale, basa molto della sua accuratezza sui dati statici, ovvero sulla conoscenza del contesto operativo, sul Team a cui verrà affidato il progetto, e altri fattori collegati.

Ora, concentrandosi sulle tecniche Agili e, tralasciando stime di costi che piacciono molto ai PM ma che si rilevano decisamente poco affidabili (una per tutte quella basata sul numero di linee di codice ipoteticamente necessarie, alias LOC), vediamo come effettuare una “stima intelligente”.

Prima di tutto è utile chiarire che non è sufficiente effettuare una sola stima, ma ne servono almeno due:

  • - Release Estimation (long-medium time), che viene utilizzata per la stima dei tempi (costi) relativi all’intera release e porta con se la stima della Velocity, ovvero la capacità di sviluppo del Team;
  • - Iteration Estimation (short time), che viene utilizzata per la stima dei tempi (e parzialmente dei costi) durante un’iterazione.

Quando si approccia un nuovo progetto è necessario avere una stima di massima del tempo (costi) necessario per il suo delivery: attenzione, non parliamo solo della scrittura del codice, ma dell’intero ciclo di sviluppo connesso ad un nuovo prodotto! Tale stima consente al management di valutare il rapporto costi/benefici e decidere se imbarcarsi concretamente nella realizzazione del nuovo sistema.

Questo è lo scopo della Release Estimation, che avviene “pesando” i Goal di progetto, tipicamente Epic e User Story, grazie agli Story Point. Lo scopo è quello di stimare la complessità delle User Story che, una volta sommate, daranno la stima complessiva del progetto. A questo punto, è necessario calcolare la Velocity, ovvero la capacità di sviluppo/realizzazione del Team per singola Iterazione. Questo esercizio può essere fatto almeno in tre modi diversi:

  • - Per affinità di progetto, ovvero si calcola la Velocity considerando quella ottenuta per un progetto di complessità similare;
  • - Per Team, ovvero si calcola in base alla Velocity tipica del Team;
  • - Per stima empirica, utilizzata quando non si possono applicare le altre due tecniche e l’unica possibilità è quella di affidarsi alle competenze di chi effettua la prima valutazione.

Una volta calcolati gli Story Point totali e la Velocity, si possono calcolare il numero totale di iterazioni necessarie e da qui i tempi ed i costi relativi. Chiaramente la stima sarà rivista ad ogni iterazione per ridurre il cosiddetto “Cono di Incertezza”.

cono di Incertezza

Cono di Incertezza

Sempre restando nel campo della Release Estimation, in alternativa agli Story Point è possibile effettuare la stima basandosi sugli Ideal Day, ovvero ipotizzando quanti “giorni ideali” (quindi pieni e senza distrazioni) sono necessari per completare il progetto. Sebbene questo approccio sembri più semplice è anche più rischioso: prima di tutto si ha la tendenza ad identificare gli Ideal Day con i giorni di calendario, ignorando altre attività giornaliere dei membri del Team (ad esempio rispondere alle email) e ottenendo una stima spesso divergente dai tempi reali e meno incline ad essere corretta, non prevedendo un analogo della Velocity. Inoltre, la stima per Ideal Day non spinge a ragionare in funzione delle attività cross-functional, ma a silos. Infine, la stima è molto più “soggettiva” che “oggettiva” proprio perché tale è la definizione stessa di Ideal Day.

Una metafora utile per spiegare la differenza tra Story Point ed Ideal Day è quella della valutazione di un “sentiero”: due corridori possono concordare sul fatto che il sentiero è di circa 1 Km (lunghezza, Story Point) ma entrambi avranno una misura diversa per quel che riguarda la stima del tempo di percorrenza (timing, Ideal Day) che deriva dalla loro velocità. Mentre sulla prima questione è più semplice che raggiugano un accordo, sulla seconda è decisamente più difficile.

Detto questo, l’implicito suggerimento è quello di usare gli Story Point.

Una volta ottenuta l’approvazione del progetto, possiamo calarci nell’ Iteration Estimationche si preoccupa di stimare la quantità di lavoro che il Team è in grado di fare per singola iterazione. Tale stima riguarda un lasso di tempo molto più ridotto (tipicamente 2-4 settimane) e quindi può essere sin da subito decisamente più accurata.

Le User Story vengono splittato in Task, ovvero si passa da una descrizione delle funzionalità desiderate dai key stakeholder ad attività di sviluppo vere e proprie, che vengono stimati in Ore.

E qui sorge spontanea una domanda: perché per le User Story si utilizzano gli Story Point e per i Task le Ore? Ebbene la risposta si trova proprio nel diverso scopo della tipologia di stima a cui afferiscono. Gli Story Point sono molto utili per dare una visione complessiva della complessità del progetto, laddove una stima in Ore avrebbe poco senso, visto che, all’inizio delle attività, sono troppi i fattori ancora incerti (si pensi, ad esempio, alla necessità di costituire un nuovo Team). Dualmente le “Ore” sono uno strumento molto più efficace per stimare singole attività che dovranno essere realizzate dal Team.

Si tenga presente che non esiste una relazione diretta tra Story Point e Ore (totali dei Task): se in generale è vero che ad una User Story di “peso” 2X, con molta probabilità, è associato un effort in Ore superiore ad una User Story di “peso” X, ciò non può essere considerata una verità assoluta.

Ad esempio, una User Story che prevede la visualizzazione dei dati in una griglia: As a User I want view my data in a grid format, se sviluppata da un Team fortemente skillato avrà una bassa complessità (Story Point), ma potrebbe richiedere molto tempo di implementazione cumulativo se tra i test di accettazione è previsto che bisogna verificarne il funzionamento con 10.000 tuple e quindi si rende necessario popolare di conseguenza il database.

A questo punto si evince che non è conveniente (anche se è possibile farlo) stimare il numero di User Story da sviluppare il una iterazione sfruttando la Velocity (velocity-driven) perché potrei incappare in situazioni come la precedente (basso Story Point ma molto tempo necessario per il data entry). Al contrario risulta più adeguata la prassi di selezionare una Story Point per volta (rispettando le relative priorità nella Work Item List), splittarla in Task, valutarne le ore e verificare se il Team si “impegna” a sviluppare altre User Story, ripetendo lo stesso ragionamento iterativo. L’approccio è quindicommitment-driven.

from story point to hour

Combinando le due tecniche si riesce a pianificare le attività in modo più convincente, raffinando il tutto man mano che si completano le iterazione e fornendo semplici ma efficaci strumenti grafici di verifica come i Release e gli Iteration Burndown Chart.

 

[FELICEPESCATORE.IT]