Agile Life

aprile 2013 - Post

High Performance Team by Metaphor

La fase di Inception di DAD ha tra i propri Goal la formazione (creazione) del Team di Delivery, estensione più ampia del Team di Implementazione che contempla esclusivamente i professionisti impegnati nello sviluppo della soluzione.

Tale attività è decisamente complessa, richiedendo una costante attenzione e un costante investimento per arrivare a trasformare dei professionisti che lavorano insieme in un High Performance Team (HPT). Da questo dipende il successo del progetto stesso.

Un High Performance Team è un Team focalizzato sui Goal del progetto, che si auto organizza, auto disciplina ed è in grado di abbracciare il cambiamento e reagire alle difficoltà che si presentano lungo il suo cammino.

Per aiutare a raggiungere tale obiettivo, oltre alla guida di un valido Coach Agile, è importante ricorrere ai cosiddetti Information Radiator, ovvero degli artefatti in grado di trasmettere sinteticamente gli obiettivi che si intende raggiungere (Goal di Progetto, Goal Personali, ecc…) e pubblicamente visibili nell’ambiente di lavoro.

La definizione “Information Radiator” è stata coniata, praticamente in contemporanea con la definizione del Manifesto Agile, da Alistair Cockburn:

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

Gli Information Radiator più comuni in un contesto Agile sono le classiche Task Board e i Big Visible Chart (ad esempio i burndown chart). Della loro rilevanza, unitamente ai vantaggi del Visual Management, parleremo nel prossimo post.

Questo post, invece, è dedicato agli HPTs e alla succitata complessa attività di formazione. In tale contesto un Information Radiator particolarmente efficace è quello suggerito da Lyssa Adkins, uno dei migliori Coach Agile a livello mondiale.

La Adkins, infatti, suggerisce la metafora dell’High Performance Tree come strumento per la crescita di un Team, da cui deriva un Information Radiator simile a quello della figura seguente.

hpt

High Performance Tree

La metafora dell’Albero si sposa alla perfezione con quella che è la vita e l’evoluzione di un Team che punta a divenire un HPT. Infatti, con essa risulta decisamente più evidente l’impegno e la complessità che si cela dietro l’adozione dell’Agile e la formazione di un Team Agile, cosa molto più profonda di quanto si possa credere. Non si tratta infatti di “buon senso” o di applicare nuove pratiche più o meno articolate, ma di cambiare la propria Cultura e il proprio Approccio inerente lo sviluppo del Software.

Così come le Radici sono il sostegno fondamentale per l’Albero, i valori di ogni membro del Team sono il cemento del Team stesso.

roots

Roots (Radici)

In particolare, Scrum definisce i Five Scrum Values (FSV), sintetizzati nel primo Valore del Manifesto Agile (GLI INDIVIDUI E LE INTERAZIONI più che i processi e gli strumenti) e adottati in pieno da DAD:

  • Focus: tutto il Team deve essere concentrato sulle proprie attività e limitare (idealmente eliminare) le "distrazioni". Il Membri del Team sono impegnati nello sviluppo delle User Story previste per la specifica iterazione, il Team Lead è focalizzato sul rimuovere ostacoli e impedimenti, il Product Owner è concentrato sulla priorizzazione dei Goal di progetto.
    • "Concentrate all your thoughts upon the work at hand. The sun's rays do not burn until brought to a focus." – Alexander Graham Bell
  • Courage (Coraggio): il "coraggio" deve manifestarsi in varie forme ed è caratterizzato dalla fiducia reciproca dei membri del Team. Il Team Lead deve avere il coraggio di "proteggere" il Team dalle intemperie esterne, il Product Owner deve avere il coraggio di affidare la definizione dell'Iteration Backlog al Team, che, a sua volta, deve avere il coraggio di mettere in cantiere solo le User Story che crede di poter realizzare.
    • "Fortes fortuna adiuvat – fortune favours the brave" – Proverbio Latino
  • Openess (Apertura): bisogna che ogni membro del Team abbia una mente aperte per poter progredire e contribuire alla crescita d'insieme. Il Product Owner deve abbracciare i cambiamenti nelle specifiche di progetto e le innovazioni che vengono dagli stakeholder così come dai membri del Team. I membri del Team devono avere una mente aperta per poter individuare la soluzione migliore e utilizzare i Retrospective Meeting per migliorarsi insieme al Team Lead.
    • "It is impossible for a man to learn what he thinks he already knows." – Epitteto
  • Commitment (Impegno): il Team è impegnato nell'adozione con successo delle pratiche Agile. I membri del Team si impegnano nella definizione dell'Iteration Backlog e nella definizione stessa di "successo" dell'iterazione. Il Team Lead è impegnato nella guida del Team e della sua coesione, mentre il Product Owner è costantemente impegnato a soddisfare gli stakeholder ed accoglierne le richieste.
    • "Do, or do not. There is no try." – Maestro Yoda
  • Respect (Rispetto): ogni membro del Team è uguale. Questo valore è fondamentale e tutti devono sforzarsi per ottenere il difficile risultato. Il Product Owner deve concentrarsi sull'ottenere una soluzione che soddisfi gli stakeholder, non dettando regole e altri vincoli. Allo stesso modo il Team Leader è un facilitatore, un mentore, e non un controllore, mentre ogni membro del Team deve rispettare l'altro e rispettare i vari ruoli previsti da un DAD Team.
    • "I speak to everyone in the same way, whether he is the garbage man or the president of the university." – Albert Einstein

Gli SFV devono essere assimilati da ogni membro del Team (di Delivery) ed è utile che essi siano oggetto di discussione, soprattutto nei primi tempi di attività, visto che la relativa percezione, e di rimando il comportamento da assumere, può essere inizialmente differente.

Una volta che le Radici (SFV) si sono solidificate, il Team passa nella seconda fase in cui le singolarità cedono il posto all’unione. Arriviamo così alle Foglie:

  • Committed to Team Success (Impegno per il successo del Team): il Team è impegnato nel suo successo complessivo. Se il Team ha successo, tutti i suoi membri hanno successo, se il Team fallisce, tutti i membri falliscono, indipendentemente dalle responsabilità individuali;
  • Owns its Decisions & Commitments (Gestisce le proprie decisioni e il proprio impegno): il Team decide come e su cosa impegnarsi rispetto ai Goal di progetto e a quelli dell'iterazione;
  • Constructive Disagreement (Disaccordo costruttivo): implica che il Team si confronta per trovare la soluzione migliore facendo tesoro dei vari punti di vista senza mai degenerare in conflittualità tra i propri membri;
  • Self Organizing (Auto organizzazione): il Team è assolutamente in grado di auto-organizzarsi e gestire le proprie attività;
  • Trust Motivate Them (La fiducia motiva il Team): il Team ha acquisito sicurezza, cosa che lo rende più forte, coeso e motivato;
  • Belive they can solve any problem (Credere di poter risolvere ogni problema): il Team è sicuro, motivato e auto-organizzato, elementi che gli permettono di affrontare ogni problema con una robusta consapevolezza di poterli superare;
  • Consensus Driven (Guidato dal Consenso): le azioni e le scelte del Team sono guidate dal consenso (il più ampio possibile) dei suoi membri;
  • Empowered (Crescita): il Team è cresciuto e continua a crescere sia come Team nel suo insieme che nelle sue singole componenti individuali.

 

leaves

Leaves (Foglie)

Una volta che il Team si sente e si comporta come tale (Being a Team) è pronto a cogliere i frutti del proprio lavoro e diventa un High Performance Team:

fruits

Fruits (Frutti) 

  • Get Business Value Fast (Ottenere velocemente Valore): produrre velocemente (termine chiaramente relativo) nuovo valore per il proprio business;
  • Team that Can Do Anything (Fare qualsiasi cosa): il Team può realizzare qualsiasi cosa, affrontando le complessità e le difficoltà che incontrerà lungo il suo commino;
  • Get Astonishing Result (Ottenere risultati sorprendenti): sorprendere i propri stakeholder con soluzioni e risultati inattesi o insperati;
  • Get the Right Business Value (Ottenere il giusto Valore di Business): il Team è in grado di ottenere la giusta misura di Valore in relazione ai vincoli esistenti;
  • Room for Individual and Team Growth (Ambiente per la crescita individuale e del Team): il Team e i suoi membri hanno realizzato un ambiente personalizzato idoneo alle proprie aspettative e alla propria crescita.

Per arrivare ai frutti è necessario molto lavoro e molto impegno, ad ogni livello, ma soprattutto da parte del Team. I risultati sono tuttavia straordinari e un HPT è uno dei fattori di traino dell’azienda, garantendo il raggiungimento di risultati e alte performance.

NFR: come definire correttamente uno scenario

Abbiamo più volte affrontato la questione dei Requisiti Non Funzionali o di Qualità, e affermato la loro fondamentale rilevanza nella definizione dell’Intentional Architecture. Inoltre, abbiamo visto come in Agile sia possibile pensare a delle (Technical) User Story che contemplino gli NFR e come esista una loro congiunzione diretta all’ALM con un occhi particolare a DAD.

A questo punto, cerchiamo di rispondere più in dettaglio ad una semplice domanda che, però, cela una risposta complessa:

            “Come catturo opportunamente gli NFR, in modo sintetico e non ambiguo?”

Una soluzione interessante è quella proposta da Bass, Clements e Kazman in “Software Architecture in Practice”, che propone di definire uno specifico attributo di qualità (o meglio di dettagliare quali aspetti di esso afferiscono al contesto/progetto specifico) attraverso un Quality Attribute Scenario.

specify nfr

Quality Attribute Scenario

Nel dettaglio, uno tale scenario è esplicitato attraverso 6 elementi:

  • Stimolo (Stimuls), ovvero l’evento che sollecita il sistema;
  • Source of Stimuls (Sorgente dello Stimolo), la sorgente da cui proviene lo stimolo;
  • Artefatto (Artifact), la parte del sistema sottoposta allo stimolo. Chiaramente può essere l’intero sistema;
  • Environment (Contesto), il contesto in cui si verifica lo stimolo;
  • Response (Risposta), come il sistema risponde allo stimolo;
  • Response Misure (Misura della Risposta), permette di valutare se la risposta del sistema è soddisfacente.

Vediamo un esempio concreto di scenario generale afferente alla requisito di Availability (Disponibilità)

 

availability scenario

Quality Attribute Scenario for Availability

In cui troviamo:

Elemento

Possibili Specifiche (nel dettaglio ne verrà selezionato solo uno)

Source of Stimulus

Interno/Esterno

Persone/Hardware/Software

Infrastrutture e Ambienti fisici

Stimulus

Fault, Tempi di risposta incorretti, Risposte Incorrette

Artifact

Processori, Canali di Comunicazione, Sistemi di Storage, Processi

Environment

Esercizio, Startup, Riavvio, In Manutenzione, ecc…

Response

Evitare che i fault si tramutino in failure

Tracciare il fault: log, notifiche

Inibire la sorgente dello stimolo

Response Measure

Tempo o relativo intervallo di disponibilità

Percentuale di Availability

Tempo per individuare un fault e tempo di recovery

Personalmente ritengo che questo approccio permetta di definire dettagliatamente gli NFR, scrollandogli di dosso quella aleatorietà che spesso gli si associa con affermazioni del tipo “Il Sistema deve essere sicuro!”, prendendo, eventualmente, come riferimento gli attributi esplicitati nello standard ISO 9126 (ISO/IEC 25000 dal 2005).

Una volta definiti gli scenari è possibile passare alla stesura di una prima ipotesi di Intentional Architecture, utilizzando Tattiche e Pattern Architetturali per abbracciare l’insieme degli NFR. Inoltre è possibile definire le (Technical) User Story per il ciclo di sviluppo, o un'altra formalizzazione delle specifiche dipendente dalla metodologia scelta.

La cosa su cui ritengo untile spendere un ulteriore passaggio è che tale approccio si applica sia agli attributi che afferiscono ai componenti e alle loro iterazioni (component-and-connector) sia agli attributi relativi alla definizione statica dell’architettura (modules). Quest’ultimo aspetto non è immediato come quello che più afferisce al funzionamento del sistema, ma è altrettanto fondamentale. Un esempio per tutti è la Modifiability, alias l’attitudine del sistema ad essere modifica e/o adattato.

modifiability scenario

Modifiability Scenario relativo al cambio della UI

Come si vede dalla figura precedente, l’Environment è “Design Time” e quindi implica uno scenario che afferisce alla specifica fase di definizione della struttura del sistema.

Non solo Valori: i 12 (+3) principi dell’Agile riletti in chiave DAD

Nei post precedenti abbiamo fatto un tuffo nel cuore dell'Agile, analizzando i 4 Valori che lo caratterizzano ed evidenziando la re-interpretazione fatta dal framework DAD.

agile manifesto rally mini

Non bisogna stupirsi che gli stessi Valori dell'Agile possano (debbano!) evolvere, perché il concetto di learning è alla base dell'Agile stesso, tanto che pratiche come "inspect-and-improve" sono oggi alla base delle attività di un VERO Agile Team.
Più volte abbiamo evidenziato come il framework Disciplined Agile Delivery sia da considerarsi un'estensione delle metodologie Agile CORE, che rende "agili" anche le fasi di Inception e di Transition, fasi tipicamente affrontare in modo classico all'interno dei contesti Enterprise.


In tale ottica abbiamo riletto i 4 valori in chiave più ampia:

  1. GLI INDIVIDUI E LE INTERAZIONI più che i processi e gli strumenti (stessa formulazione), focalizzando la nostra attenzione sul Delivery Team e non esclusivamente sull'Implementation Team;
  2. SOLUZIONI FUNZIONANTI più che la documentazione esaustiva ("soluzioni" e non "software"), perché quello che viene rilasciato è una soluzione. Il Core è effettivamente il software che però viene sempre completato con elementi quali: manuali, formazione, attività di aggiornamento, ecc...;
  3. LA COLLABORAZIONE CON GLI STAKEHODLER più che la negoziazione dei contratti("stakeholder" e non "clienti"), perché se è vero che il cliente rappresenta il key stakeholder è altresì comprovato che lo sviluppo di una nuova soluzione (o di una sua nuova release) genera valore ad una pluralità di soggetti, interni ed esterni all'azienda;
  4. RISPONDERE AL CAMBIAMENTO più che seguire un piano (stressa formulazione), perché la vera comprensione della soluzione che si sta sviluppando e delle proprie potenzialità è possibile solo attraverso un continuo apprendimento e un altrettanto continuo arricchimento del know-how, che porta, inevitabilmente, al cambiamento.


Chiaramente è facile aspettarsi che anche i 12 Principi alla base dell'Agile possano essere rivisti in funzione di questa nuova prospettiva:

  1. La nostra massima priorità è soddisfare gli stakeholder rilasciando soluzioni di valore, fin da subito e in maniera continua;
  2. Accogliamo i cambiamenti nei requisiti anche a stadi avanzati del ciclo di delivery della soluzione. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo deglistakeholder;
  3. Consegniamo frequentemente soluzioni funzionanti, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi;
  4. Stakeholder e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto;
  5. Fondiamo i progetti su individui motivati. Diamo loro l'ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine;
  6. Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con ed all'interno del team di delivery;
  7. Il Valore della Soluzione è il principale metro di misura di progresso;
  8. I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante;
  9. La continua attenzione all'eccellenza tecnica e alla buona progettazione esaltano l'agilità;
  10. La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale;
  11. Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano;
  12. A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza;

Anzi, oltre ai 12 principi "standard" è utile introdurre altri 3 nuovi principi:

  1. (13) Far evolvere le attività all'interno dell'ecosistema organizzativo aziendale, collaborando con i responsabili di esse;
  2. (14) Focalizzare un workflow del processo di delivery costante, in modo da minimizzare le attività inerenti;
  3. (15) L'intera organizzazione deve evolvere per massimizzare i risultati del team agile, restando sufficientemente flessibile da supportare team-non-agili o team ibridi.