Nell'adozione di agile o delle pratiche lean, il contesto culturale è tutto. Operando nell'ambito del cambio delle organizzazioni, la cultura non è un fattore che può essere trascurato ma al tempo stesso, non è soggetto a principi di design. Matteo Carella esamina gli "errori del passato" da Toyota al modello Spotify per capire il presente e il futuro.

Il talk di Matteo, presentato all'ultimo AgileBusinessDay enfatizza il ruolo e il peso della cultura nell'ambito dell'adozione delle pratiche agili. Differenti culture conducono a differenti risultati, dipendentemente dal contesto. Seguono alcune note sulla cultura come fenomeno complesso, che non può essere soggetto a principi di design (banalmente come quelli della mera applicazione di processo), ma che può essere solo analizzato in base alla sua naturale disposizione (che cambia continuamente).

Considerare la cultura come qualcosa suscettibile di design o "impiantabile" comporta una serie di antipattern e misconceptions che conducono a cambi culturali poco o per nulla effettivi (es. la replica a tutti i costi del modello Toyota nelle industrie americane fino all'ossessione per il "modello Spotify" inteso erroneamente come framework piuttosto che come esempio di cultura). L'utilizzo dei rituali nell'ambito dell'organizational design e il loro significato cognitivo. Esempi di successo (Zalando e Lego®) basati su una cultura aziendale sana, radicata e spontanea.

Agli ultimi Agile Days a Urbino, Joe Bew ha spiegato cosa significa fare Continuous Delivery, quali sono i passi che in modo iterativo e incrementale aiutano il team a raggiungere una maggiore consapevolezza e conoscenza sul tema, al fine di modellare il processo di rilascio software per adattarsi meglio ai requisiti di business.

Durante le sue attività di supporto ai team, Joe ha messo a punto una tecnica per fare emergere l’attuale processo di delivery per visualizzare gli impedimenti e capire quali passi compiere per visualizzare il processo corrente:

1. expectation
2. discover
3. visualize
4. redesign
5. realize
6. share

Grazie a questo format i vari stakeholder sono riusciti ad evidenziare eventuali roadblock e migliorare il loro processo di delivery.

Spesso le persone con maggiori conoscenze tecniche e di maggiore esperienza tendono col tempo a diventare over protettive nei confronti del software che hanno costruito con tanta passione. Durante il talk dell'ultimo Agile Days, Paolo D'incau ha raccontato quali sono i principali danni che questo comportamento può arrecare in un’azienda agile e come la figura del “guardiano” possa naturalmente evolvere in un’altra figura che agisce da catalizzatore per la crescita del team.

Il talk nasce dall'osservazione sul campo di un pattern presente in tanti team dove spesso la persona con più conoscenza tecnica e di prodotto non riesce a rilasciare il controllo e far crescere le persone che ha accanto, perché teme di far abbassare la qualità della codebase.

Il tema è molto caro a Paolo, che afferma: "mi considero un guardiano della codebase "disintossicato" e ho avuto a che fare con parecchi guardiani negli ultimi anni quindi ho moltissimi esempi reali da raccontare durante il talk per guidare la discussion. Credo che in un mondo come il nostro, in cui si parla spesso di eccellenza tecnica e di craftsmanship valga la pena ricordare che alla base di un team agile c'è ben altro, come il lavoro di squadra e la crescita omogenea delle persone."