Agile Life

maggio 2013 - Post

Team Conflict

 

Uno dei temi più ostici nella gestione (Project Management in senso classico) o nell’auto organizzazione (Agile) di un Team è la governance dei conflitti tra i membri del Team stesso: come consentire a professionisti in contrasto tra loro di superare tale situazione?

Lyssa Adkins propone diverse tattiche in base al livello di conflittualità individuabile all’interno del Team, ovvero:

5levels conflict

5 Levels Conflict (tratto da Coaching Agile Teams di L.A.)

  • Livello 1: Problem to Solve (problema da risolvere). Questo livello di conflittualità è dato da fattori tipici di ogni ambiente di lavoro, come stress o frustrazione per il non raggiungimento di determinati obiettivi. Tutto sommato, però, il rapporto con i propri colleghi resta nel limite della norma, e le conflittualità vengono utilizzate come fattore di confronto e di crescita per l’intero team, diventando così “constructive disagreement” che caratterizza il percorso che porta un Team a diventare un high-performance Team.
  • Livello 2: Disagreement (disaccordo). A questo livello i membri del Team cominciano ad essere “distanti”. Ognuno di essi cerca di proteggere la propria posizione, non condividendo tutte le informazioni a propria disposizione e spostando il discorso da elementi di dettagli a elementi generici;
  • Livello 3: Contest (competizione). A questo livello il Team comincia a degenerare e si creano delle vere e proprie fazioni che tendono a difenderne gli aderenti. Cominciano ad emergere accuse reciproche (es: “non è particolarmente attendo alla gestione dei fault”) e gli attacchi si spostano anche sul piano personale, cominciando a perdere di vista l’obiettivo (Valore) del progetto;
  • Livello 4: Crusade (crociata). A questo punto l’obiettivo delle varie fazioni che si sono create è uno solo: costringere gli altri a lasciare il Team. La discussione si sposta su questioni ideologiche e le questioni afferenti il progetto sono praticamente dimenticate;
  • Livello 5: World War (guerra mondiale!). Apice del conflitto: nessuno è disposto a cedere e trovare una soluzione diplomatica. L’importante è vincere e distruggere il “nemico”. Nessuna soluzione autonoma è più possibile.

 

Cerchiamo ora di evidenziare alcune possibili tattiche per intervenire in queste situazioni, partendo dalla maturità del Team.

Nel caso in cui il Team sia “acerbo”, ovvero abbia abbracciato da poco il mondo Agile è possibile destreggiarsi tra il Livello 1 e il Livello 3 (forse meglio 2 e ½) focalizzando le attività sui Task da realizzare. Ciò costringe implicitamente i membri del Team a lavorare per obiettivi e migliorare, inevitabilmente, il rapporto tra essi, in un approccio di tipo cooperativo.

Se, al contrario, il Team ha una discreta esperienza con il mondo Agile, la via consigliata è quella di ricorrere ai fondamenti dell’Agile, in modo da consentire al Team di fare mente locale sui Valori e i Principi alla base del proprio lavoro e qual è l’obiettivo finale. In tal caso si adotta un approcciocollaborativo.

Questa seconda strada è da preferire, visto che una ricerca del Gottman Institute ha dimostrato che circa il 69% dei conflitti non viene mai risolto, ma che la strada maestra è quella di imparare a gestirli, migliorando i rapporti specifici. Alla base di questo approccio ci sono gli elementi fondanti dell’Agile (Bones of Agile) o le cosiddette Structure (strutture), così definite da Whitworth:

“devices that remind people of theri vision, goal or purpose, or the action they need to take immediately. Collages, calendars, message on voice mail, and alarm clocks can serve as structure.”

Un esempio di struttura: gli Information Radiator di cui abbiamo parlato nei due post precedenti, o, più semplicemente, il Manifesto Agile.

Come intervenire, allora, in base al livello di conflitto che abbiamo riscontrato nel Team? Sempre la Adkins suggerisce una serie di possibili tattiche:

Livello del Conflitto

Tattiche

Livello 1

Collaborazione: ricercare una situazione che risulti vincente per entrambe le parti in conflitto;

Consenso: favorire il raggiungimento autonomo dell’accordo su una delle soluzioni proposte;

Livello 2

Supporto: responsabilizzare le parti per risolvere il problema;

Sicurezza: lavorare su elementi che restituiscano un senso di sicurezza al Team. Si pensi, ad esempio, ai collaboration game o ai Valori Agile.

Livello 3

Adattarsi: proporre ad una delle due parti di “verificare” quanto insistentemente proposto dall’altra (da usare solo per tamponare la situazione);

Negoziare: cercare di accogliere un sottoinsieme delle richieste di entrambe le parti. Questo approccio funziona particolarmente bene quando l’elemento conteso è una risorsa condivisa;

Assessment: analizzare la situazione per mettere il Team difronte all’evidenza e alle proprie responsabilità.

Livello 4

Diplomazia: lavorare sulle strutture (ovvero gli strumenti di un Team Agile), mediando tra i due gruppi finché la situazione non regredisce ad uno dei livelli precedenti. In tale condizione può essere utile anche valutare la possibilità di proporre ad alcuni elementi del Team una ricollocazione in un altro Team.

Livello 5

Intervenire con misure invasive rompendo quello che è lo status diself-organizing Team.

[FELICEPESCATORE.IT]

DAD, Keep Inception short http://tinyurl.com/a66nmq2

Come abbiamo rimarcato più volte, DAD prevede un’esplicita fase di Inizio, o Scoperta, del progetto, definita Inception. Tale fase è fondamentale per una corretta valutazione del progetto e per l’individuazione del relativo valore e dei relativi rischi (value and risk driven). Sinteticamente è utile ricordare i principali Goal della fase di Inception:

  • chiarire l'esigenza (bisogno) che si intende risolvere;
  • identificare una soluzione tecnica percorribile;
  • pianificare una strategia;
  • costituire il Team e attrezzare l'ambiente di lavoro;
  • garantirsi il consenso degli stakeholder e i finanziamenti necessari.

Quello che è utile evidenziare è la disciplina necessaria a gestire ed attuare tale fase, necessaria al fine di evitare di far ricadere l’intero framework Agile nel poco desiderato water-fall-scrum. Secondo i sondaggi che Scott Ambler sottopone a cadenza annuale a decine di aziende che utilizzano metodologie Agile, la fase di Inception (non necessariamente identificata formalmente come tale) ha, tipicamente, una durata media di 4 settimane, a seconda della complessità del progetto e della maturità dell’azienda e del Team nell’utilizzo delle pratiche Agili.

Per affrontare correttamente il tutto, è possibile affidarsi ad alcune linee guida:

  • Riconoscere che l’obiettivo è quello di incamminarsi nella direzione giusta. Per ogni progetto è indispensabile comprenderne l’essenza e la relativa complessità, effettuando un planning iniziale del contesto di risoluzione e una prima definizione dell’Intentional Architecture;
  • Educare le persone ad accettare che i dettagli emergono successivamente. Questo è un fattore chiave: la fase di Inception non deve avere la presunzione di definire puntualmente il tutto, ma solo di definirne i contorni, impiegando l’effort effettivamente necessario. Il Team (così come gli stakeholder) devono comprendere un concetto fondamentale: rimandare la definizione puntuale al momento in cui essa è indispensabile, permette di effettuarne l’analisi con il massimo know-how afferente, sicuramente molto più di quanto si ha all’inizio del progetto. Ciò è particolarmente vero se il tutto avviene durante la fase di Construction;
  • Promuovere un senso di urgenza. Se da un lato è vero che una non attenta analisi dei fattori associati allo start-up di un nuovo progetto può aumentare il rischio di fallimento del progetto, dall’altro impiegare troppe energie nella fase di up-front ritardando lo sviluppo è altrettanto rischioso perché si ritarda la possibilità di confrontarsi con soluzioni funzionanti (incrementali) e verificare le assunzioni e le scelte effettuate;
  • Mantenere la modellazione leggera. La fase di Inception predilige la definizione di un piano iniziale e di una intentional architecture (architecture envisioning) che servirà da boundary alle azioni intraprese per soddisfare il progetto. Tali artefatti devono essere in grado di raccogliere l’essenza dei proprio obiettivi, restando flessibili in modo da poter essere rivisti e, se necessario, corretti quando richiesto;
  • Dedicare al planning il minimo effort necessario. Esattamente come per gli aspetti più specificamente tecnici (architettura e scope) anche le attività afferenti al planning devono essere ridotte al minimo durante la fase di Inception. Si può, a tal proposito, sfruttare il noto “cono di incertezza” che permette di raffinare il planning man mano che si procede nel completamento delle Iterazioni (Construction).

In pratica, la fase di Inception deve dare una visione complessiva del progetto, della sua complessità, dell’effort di realizzazione richiesto e dei rischi annessi. Il tutto deve essere effettuato ad un livello sufficiente per iniziare il processo, evitando però di concentrarsi su un’analisi estremamente puntuale come avveniva nel modello a cascata.

Information Radiator

Parlando nel precedente post dell’High Performance Tree, abbiamo introdotto il concetto diInformation Radiator.

Il termine, è stato coniato da Alistair Cockburn, all’incirca nello stesso periodo in cui viene definito il Manifesto Agile (inizio degli anni 2000), al fine di indicare tutti quegli artefatti in grado di trasmettere, sinteticamente e velocemente, gli obiettivi che si intende raggiungere (Goal di Progetto, Goal Personali, ecc…), rendendoli pubblicamente visibili nell’ambiente di lavoro.

Si tratta di elementi molto comuni in ambito Agile e alla base della pratica del Visual Management. Tutti abbiamo avuto esperienza con i post-it per la definizione delle User Story e i più fortunati hanno toccato con mano strumenti più elaborati come la Kanban Board: ecco, sono entrambi elementi di Visual Management.

Tutti gli Information Radiator condividono una serie di elementi caratterizzanti:

  • Semplici, in modo che le informazioni rappresentante possano essere immediatamente interpretare;
  • Minimali, in modo da evidenziare le informazioni che si vogliono comunicare;
  • Aggiornati, in modo da rispecchiare sempre lo stato aggiornato delle attività allo stato attuale;
  • Ben visibili, in modo che chiunque possa vedersi agevolmente. Soprattutto il Team;
  • Funzionali, in modo che il Team li senta propri e li adotti naturalmente.

Tali elementi sono ben sintetizzati dallo stesso Cockburn:

information radiators are best when they are big, very easy to see (e.g. not online, generally), and change often enough to be worth revisiting.”

Senza voler essere esaustivi, possiamo raggruppare gli Information Radiator in tre macro-categorie:

  • Task Board, probabilmente il più importante degli Information Radiator, in quanto permette di visualizzare immediatamente lo stato delle attività in corso. Si tratta di un radiator "real-time", nel senso che muta il suo stato con estrema rapidità, che segue l'evoluzione delle attività e l'evoluzione del know-how afferente il progetto.

iradiator taskboard

Task Board

Tipicamente le Task Board possono essere sia fisiche che digitali, queste ultime particolarmente adatte al contesto @Scale, ovvero con Team distribuiti in diverse sedi geografiche;

  • Big Visible Charts, rientrano in questa categoria gli Information Radiator che offrono sinteticamente, e in modo aggregato, un considerevole numero di informazioni. Ad esempio, nel Burndown Chart, è possibile ottenere un'analisi dell'andamento di sviluppo delle UserStory (story point o ideal days).

 

iradiator burndown chart

Burndown chart

Spesso il Burndown Chart è accompagnato dal Risk-O-Meter che evidenzia il grado di rischio che accompagna il progetto. 

iradiator risk-o-meter

Risk-O-Meter

In questa categoria rientra anche il Trade-off siders, radiator che permette di visualizzare il bilanciamento richiesto dai vari fattori primari per il progetto. Nel Trade-off siders viene impostato un valore prefissato (project weight) che bisogna garantire: se si aumenta il peso relativo di un fattore, inevitabilmente quello di un altro deve diminuire in modo da mantenere costante il peso di progetto.

iradiator tradeoff slider

Trade-off slider

  • Continuous Integration build health indicators, meno comuni dei precedenti ma con un obiettivo importante: capire come la Cultura Agile si sta diffondendo nel Team e qual è l'attuale stato di salute del progetto. Rientra in questa categoria l'High Performace Tree, così come i Semafori (luce rossa, gialla, verde) e le Lava Lamp (stato/grado di illuminazione), che permettono di evidenziare lo stato di salute delle attività e, di conseguenza, intervenire adeguatamente.

iradiator traffic light

Traffic Light

Torniamo, ulteriormente, sulla Task Board (nota in Scrum anche come Scrum Board).

Proprio la sua importanza consegna al suo progettista (coach o team lead) il delicato compito di bilanciare due elementi fondamentali: readability (leggibilità) e usability (usabilità). Il tutto al fine di integrarla al meglio nell'ALM e non trasformare il Radiator in uno sterile esercizio effettuato più per prassi che per reale utilità. Sinteticamente possiamo definire una "great taskboard" una taskboard che:

  • Il Team utilizza e aggiorna in modo naturale, senza considerarla un peso;
  • E' "protagonista" durante lo stand-up meeting;
  • Attira l'interesse di persone esterne al Team, che si fermano a guardarla e commentarla;
  • E' motivo di orgoglio per il management;
  • Viene continuamente aggiornata dal Team durante le attività quotidiane;
  • Soddisfa un primario criterio di usabilità: anche una persona che non l'ha mai vista, può trarre da essere informazione in modo chiaro e rapido;
  • Cattura l'attenzione di un senior manager che passa per caso nelle sue vicinanze.

 

A voi il compito di scegliere l'Information Radiator più adatti al vostri Team, al vostro scopo e ai vostri progetti.