…le cose funzionano bene perché tutti fanno solo ciò che deve essere fatto per pura passione, così senza soluzione di continuità che un osservatore potrebbe concludere che tutti hanno la capacità di leggere la mente degli altri. Tuttavia, man mano che l’organizzazione e il prodotto crescono, cresce anche la quantità di informazioni che i team devono padroneggiare, gestire e condividere per portare a termine il loro lavoro. Le decisioni stanno diventando più sensibili al contesto (sia dei team che dei prodotti), con una complessità che richiede un qualche tipo di struttura per mantenere le cose senza intoppi mentre l’organizzazione matura. State cercando una struttura organizzativa che ottimizzi la capacità del team di fare le cose per creare il massimo valore.

✥ ✥ ✥

Una comunicazione e un feedback efficaci sono il cuore dello sviluppo efficace di un sistema complesso, e la struttura organizzativa dovrebbe essere ottimizzata per i percorsi di comunicazione più cruciali. La comunicazione e il feedback regolare, insieme all’auto-organizzazione, sono il cuore agile. L’interazione di persone con preoccupazioni diverse e trasversali è il cuore dell’innovazione ().

I team di sviluppo che lavorano su prodotti complessi lottano continuamente con la doppia natura di funzione e forma. Tendiamo a creare confini tra le attività di sviluppo e le unità organizzative lungo queste linee. Eppure la funzione e la forma sono solo categorie socialmente costruite e in qualche modo arbitrarie: l’affidabilità potrebbe essere una preoccupazione altrettanto forte per un dato sistema, mentre la bellezza, la compatibilità all’indietro, o qualche altra preoccupazione potrebbe dominare un dato sforzo di sviluppo. In ogni caso, il business sarà servito meglio se il team di sviluppo si organizza intorno alle preoccupazioni più cruciali per il business, qualunque esse siano.

Quando il vostro team comincia a maturare nei suoi primi giorni e comincia a muoversi verso la costruzione di uno Scrum Team, avete più persone che possono convenientemente lavorare come una sola unità organizzativa per coprire tutte le funzioni di un business (pianificazione del rilascio, sviluppo e crescita professionale). Ma la crescita e la maturità causano anche disagio, in quanto i team desiderano l’efficacia non strutturata dei semplici giorni di lavoro informale. Eppure, crescere e gestire correttamente il prodotto sul mercato richiede una struttura organizzativa un po’ disciplinata e una governance leggera.

Le culture hanno un bisogno intrinseco di struttura per il funzionamento efficiente dell’insieme. La comunicazione più efficace avviene sempre a livello locale nel regno del familiare, quindi è cruciale localizzare il processo decisionale intorno alle preoccupazioni organizzative più cruciali. È importante in qualsiasi organizzazione sociale non banale che le persone siano in grado di associare rapidamente qualsiasi dominio di interesse con il “posto dove andare” più efficiente quando hanno bisogno di informazioni su quell’area o devono intraprendere un’azione in quell’area.

Una semplice suddivisione organizzativa (cioè, una gerarchia) è sufficiente in domini semplici che devono trattare solo un insieme di preoccupazioni separabili. Ma l’approccio gerarchico si rompe nel caso più tipico di sforzi di sviluppo con molteplici preoccupazioni sovrapposte. Questo spinge verso unità organizzative più grandi e complesse che cercano di correggere il problema con economie di scopo. Eppure i team di lavoro più efficaci sono piccoli team, ed è necessario dividere il lavoro in qualche modo.

Tuttavia, nessun team è un’isola, e una nazione di sviluppo è più di un insieme di isole. I team sviluppano individualmente la propria identità, dove un naturale senso di xenofobia (bisogno del familiare) fa sì che i team diano solo una statura secondaria alle preoccupazioni provenienti dall’esterno della loro cerchia sociale. Se si limita l’impresa ad una serie di interazioni sociali, basate su un’unica semplice suddivisione, si chiudono le idee fuori dai limiti che alimentano l’innovazione.

La velocità del processo decisionale è fondamentale. Alcune questioni sono urgenti (“Siamo stati attaccati da un’altra tribù e dobbiamo organizzare una difesa contro di loro”), mentre altre, anche se importanti, tollerano o addirittura richiedono una deliberazione più lunga (“Qual è la posizione migliore per la nuova sala riunioni?”). Il termine strati di taglio descrive processi correlati che si muovono a velocità diverse, dopo la nozione di placche tettoniche che si muovono l’una sull’altra, come nel caso di un terremoto. Sia gli architetti edili () che il campo dell’architettura del software (vedi ) hanno adottato la frase per descrivere strutture o preoccupazioni con diversi tassi di cambiamento in un sistema strettamente accoppiato. Un’azienda dovrebbe strutturare la sua organizzazione per essere in grado di rispondere rapidamente ai problemi della prima categoria senza distruggere la sua efficacia per i problemi della seconda.

Un altro principio agile è che siamo rivolti verso l’esterno: cioè, la nostra attenzione e preoccupazione sono sull’utente finale, sul mercato e sui clienti piuttosto che sugli strumenti e le tecnologie che usiamo per fare il nostro lavoro. Anche l’organizzazione dovrebbe riflettere questa preoccupazione, poiché è la chiave per la proposta di valore e la costruzione dell’intero flusso di valore dello sviluppo.

Alla fine, la struttura dell’organizzazione dovrebbe avere tanto a che fare con la struttura del processo quanto con la struttura del prodotto.

Pertanto,

Organizza la forza lavoro in piccoli team di più o meno cinque persone, suddivisi secondo le preoccupazioni più importanti per la creazione di valore per l’impresa. Completa questa struttura con un piccolo numero di strutture trasversali per preoccupazioni secondarie ma importanti, senza mai dimenticare che queste strutture sono solo ottimizzazioni in quello che è altrimenti un ambiente aperto di cooperazione senza vincoli.

Considera un’impresa che sta costruendo un telefono cellulare. Potrebbero organizzare i loro Scrum Team intorno ai principali deliverable o alle opzioni acquistabili. Quindi ci potrebbe essere un team per la rubrica, un altro per il calendario, e un altro per le funzionalità più tradizionali del telefono: vedi Area di Valore. Queste sono le preoccupazioni primarie del business. Ma ci possono essere gruppi che si riuniscono per definire le pratiche, le politiche e gli standard aziendali (per esempio, il look and feel dell’interfaccia utente), comprendendo rappresentanti di ogni Team Scrum. Questi gruppi non costruiscono prodotti ma servono come scambi di informazioni e come fonti di standard che guidano lo sviluppo. Nelle organizzazioni sane c’è una sovrapposizione quasi completa tra l’appartenenza a questi ultimi gruppi e l’appartenenza al team di sviluppo.

Nella maggior parte degli ambienti, la struttura organizzativa primaria riflette la struttura primaria degli stakeholder, che di solito è il mercato. Per questo motivo, non organizziamo gli Scrum Team secondo la suddivisione degli artefatti interni, né secondo i luoghi di competenza del dominio, ma piuttosto secondo le linee dei deliverable di mercato come le feature. Organizzarsi intorno alle feature o ad altri deliverable di mercato è anche un vantaggio per la reattività del mercato e la riduzione del time-to-market, perché il team è il luogo di tutto il lavoro necessario per implementare una feature. Questo mantiene il coordinamento all’interno di un confine organizzativo. Se i sottoinsiemi di lavoro o le competenze principali guidano la struttura organizzativa, allora i cambiamenti nel mercato o nella natura del deliverable comporteranno probabilmente il coordinamento tra più team o organizzazioni – riducendo la reattività e aumentando il tempo di decisione.

Se questa è l’unica struttura, supporta solo la visione del mercato, ed emargina una serie di altre valide preoccupazioni aziendali. Perché questa struttura funzioni, deve essere integrata da strutture trasversali che sostengono un secondo livello di efficienza della comunicazione, per esempio quelle relative alle competenze principali. Così questo modello appare quasi sempre insieme ad un modello come Birds of a Feather e il modello descritto in Domain Expertise in Roles. La struttura organizzativa dei ruoli taglia i muri che si formano naturalmente tra i team. Coinvolgere gli sforzi del prodotto all’interno di un’impresa per connettersi tra loro e con la gestione esecutiva attraverso il MetaScrum. I team che hanno sviluppato un grado di orgoglio di squadra (vedi Orgoglio di squadra) saranno più efficaci, poiché questa o qualche altra forza equivalente incoraggerà la responsabilità. Questo aiuta a garantire che queste strutture rimangano in gioco nonostante gli effetti xenofobi dell’appartenenza al team.

Collegare il tutto con un ambiente aperto senza muri e senza porte. I team di sviluppo sono unità solo di impegno nello sviluppo, e non ci dovrebbero essere interferenze che limitano il libero interlavoro tra gli sviluppatori attraverso i team. Aggiungete piccole stanze nelle vicinanze per brevi periodi di calma, riflessione seria e piccole riunioni.

Qualsiasi componente di valore è un gioco leale come criterio organizzativo. Per esempio, Scrum valorizza molto la collocazione dei membri del team, quindi i confini organizzativi più basilari corrispondono probabilmente ai Collocated Teams.

✥ ✥ ✥

Nota che ci sono due livelli della legge di Conway in un buon Scrum: uno guidato da un focus sul prodotto, e un altro guidato da un focus sulle aree di competenza. Al livello superficiale organizziamo il team in base al processo; questa è la preoccupazione principale per entrambi gli aspetti del processo rivolti verso l’interno e verso l’esterno. Così le tre sfere di dominio del processo sono:

• il Team di Sviluppo che possiede le decisioni sull’uso appropriato della tecnologia e della tecnica nella costruzione del prodotto;
• il Product Owner, che possiede la definizione e la direzione del prodotto; e,
• lo ScrumMaster che è responsabile che il processo supporti la consegna regolare del Team di Sviluppo.

I Team di Sviluppo Scrum sono team di funzionalità (prodotto). Cioè, il principio organizzativo primario di un team Scrum è che si allinea con un treno di consegne di feature lungo un Value Stream. C’è un’organizzazione gerarchica debole e poco profonda all’interno di Scrum che ospita più Team di Sviluppo all’interno di ogni sviluppo prodotto, condividendo un Product Owner comune, in un’organizzazione chiamata Scrum of Scrum. Ogni team di sviluppo all’interno di un singolo prodotto costruisce una serie di caratteristiche alla volta. Nel corso del tempo, i driver chiave del business, la conoscenza condivisa del business, e gli artefatti del Value Stream legheranno insieme queste caratteristiche. Non ci sono titoli riconosciuti o suddivisioni all’interno del Team di Sviluppo.

Ci sono molti modi di dividere il lavoro in team di feature. Un team di sviluppo può fornire funzionalità ad un determinato mercato (vedi L’organizzazione segue il mercato), o sviluppare prodotti per alcuni sottoinsiemi dello spettro tecnologico aziendale (un team per i telefoni e un altro per i tablet, anche se entrambi condividono molto dello stesso software). In generale, ogni team dovrebbe essere formato intorno a qualche prodotto che rappresenta una componente del valore aziendale: vedi anche Value Stream Fork. Comunque, Scrum scoraggia una struttura di Team di Sviluppo dove ogni team possiede una parte del prodotto, o solo un sottoinsieme del prodotto. Se i membri di ogni singolo team possono sviluppare solo una parte del sistema, allora avranno bisogno di coordinare più decisioni di sviluppo con altri team. Diventa difficile per i team prendere decisioni a livello locale, e i risultati includono feedback e handoff ritardati.

Al secondo livello della legge di Conway all’interno di Scrum, le persone si organizzano intorno ad aree di competenza in cui la competenza porta valore. Questi Birds of a Feather aiutano i membri ad approfondire la loro struttura in qualche area professionale o tecnica mentre condividono idee o seguono la formazione. La maggior parte delle persone ha un desiderio innato di migliorare (vedi ), e questi gruppi alimentano l’orgoglio individuale mentre i membri del team imparano e crescono. Ma di nuovo, questi gruppi non formano una struttura di reporting, e ogni membro del team può appartenere a diversi Birds of a Feather così come al proprio Scrum Team. Vedere anche Competenza di Dominio nei Ruoli.

I confini e l’identità del Team di Sviluppo, così come i confini e l’identità dello Scrum Team, sono espliciti. La nozione di identità del team è fondamentale per l’orgoglio del team e per il funzionamento efficiente dell’organizzazione, poiché l’identità del team porta il contesto sociale che aiuta ad ottimizzare il processo decisionale. Qualsiasi nozione di identità organizzativa oltre queste due dovrebbe essere tacita piuttosto che esplicita o amministrata. Di nuovo, non ci sono titoli formali all’interno del Team di Sviluppo oltre a “Sviluppatore”. Se c’è solo una regola inviolata, è che nessun individuo può usare la sua tacita stazione di competenza per scavalcare un consenso di squadra o in qualsiasi altro modo diminuire lo spirito di lavoro di squadra, come in The Spirit of the Game. Una norma di condotta sviluppata congiuntamente è un forte messaggero dell’identità della squadra.

Ci può essere competenza nei ruoli a livello individuale, ma è importante completare questo modello con squadre interfunzionali ogni volta che è possibile per ottimizzare la possibilità di prendere decisioni locali.

La legge di Conway originale è nata dal software (vedi , pp. 28-31). Ci sono molti miti associati all’origine e alla pratica della Legge di Conway. È stato a lungo ritenuto che l’orientamento agli oggetti supportasse la Legge di Conway localizzando le preoccupazioni del mercato all’interno delle classi. Questo è vero a metà; le classi tendono ad incapsulare le preoccupazioni a lungo termine della competenza centrale dell’organizzazione. Tuttavia, l’orientamento agli oggetti sembra concentrarsi sulla connessione tra le competenze degli sviluppatori e gli artefatti che sviluppano piuttosto che su qualsiasi connessione al mercato o ai casi d’uso. Le preoccupazioni per l’allineamento con la struttura del mercato dovrebbero prevalere sulle preoccupazioni per la visione del mondo degli sviluppatori del loro processo e prodotto.

Lo stile di sviluppo a cascata ha avuto il suo periodo d’oro. Nelle organizzazioni a cascata, la struttura organizzativa primaria seguiva le fasi del processo: analisi dei requisiti, progettazione, implementazione e test (, pp. 1-9). Per la legge di Conway, la struttura organizzativa rifletteva quei processi. Anche il software potrebbe benissimo riflettere quelle fasi: per esempio, un’architettura orientata ai servizi (SOA) evidenzierà la maggior parte dei requisiti a valore aggiunto nel livello di integrazione dei servizi, mentre i singoli servizi si trovano in un altro livello. Waterfall mette tutte le caratteristiche nelle mani degli sviluppatori in una volta sola, il che supporta il ragionamento sulle interazioni tra le caratteristiche. Mentre gli approcci alla progettazione del software dell’era waterfall cercavano di portare le preoccupazioni del mercato (casi d’uso) in linea con l’architettura, la struttura organizzativa tagliava quella tassonomia. Lo stesso si può dire dell’organizzazione della catena di montaggio nelle fabbriche.

Perché i team di sviluppo sono team di feature, dovrebbero concentrarsi su una feature alla volta (come in Swarming). La deliverable primaria del mercato di Scrum è una feature, e in questo senso, c’è un buon allineamento tra la struttura del team e il mercato. Scrum tace sulla forma dell’architettura del prodotto, ma nello spirito dell’agile tende a scoraggiare la proprietà individuale del codice. Ogni team di sviluppo ha la licenza di lavorare su qualsiasi parte del prodotto. Possiamo dire che Scrum bilancia i benefici organizzativi dell’incapsulamento con i benefici dell’allineamento del team alla deliverable del mercato. Il proprietario del prodotto, con il supporto del team di sviluppo, gestisce come gestire le interazioni tra le caratteristiche che emergono nel tempo.

Considera, per esempio, che un team può implementare la caratteristica di Call Waiting per un sistema di telecomunicazioni mentre un altro implementa Call Forwarding. A causa dell’emergenza, non si può sempre prevedere il costo della risoluzione delle dipendenze tra due qualsiasi Product Backlog Items (PBIs) quindi è, in generale, impossibile superare questo problema assegnando i PBIs ai team. In ogni caso, assegnare prematuramente il lavoro ai team può rendere impossibile alle persone di lavorare efficacemente sulle parti difficili (specialmente quelle relative all’interazione tra le parti) e limita l’auto-organizzazione a livello di Scrum Team. Le due caratteristiche possono essere altamente interdipendenti, ma la struttura Scrum non dà una statura di prima classe a queste interazioni. In questo caso, probabilmente sarebbe meglio se un singolo team sviluppasse entrambe le caratteristiche. Il modo di assegnare il lavoro ai team si basa sulla pianificazione continua e sul processo decisionale condiviso, a partire dalla pianificazione dello sprint. Un buon team Scrum si sforza di suddividere il lavoro tra i team di sviluppo attraverso interazioni intime, ma a tempo, tra il Product Owner e il team di sviluppo, come negli eventi per ristabilire continuamente un Refined Product Backlog così come attraverso lo Sprint Planning.

La gestione è solitamente una componente del mix organizzativo, anche se ci sono alcuni sviluppi Scrum che funzionano senza alcun manager (per esempio, vedi il recente video sulla trasformazione agile presso Bosch Software Innovations. ) L’etica Scrum tende a concentrarsi sulle persone e sul prodotto, e il focus è incarnato nei ruoli Scrum e nelle organizzazioni (come il Team di Sviluppo e il Team di Product Owner) che rappresentano. Se un’organizzazione con manager preesistenti si prefigge di introdurre Scrum, è troppo facile per lo sforzo di Scrum liquidare la parte di gestione dell’organizzazione come ultraterrena. In queste situazioni in cui un’organizzazione senza manager non è un’opzione, è cruciale coinvolgere i manager.

Steven Johnson. Da dove vengono le buone idee. New York: Riverhead Trade, 2011.

Stewart Brand. Come gli edifici imparano: What Happens After They’re Built. New York: Penguin, 1995.

Brian Foote e Joseph Yoder. “Big Ball of Mud.ˮ In Pattern Languages of Program Design 4, Brian Foote et al., eds. London: Pearson, 2000.

Daniel Pink. Drive: La sorprendente verità su ciò che ci motiva. New York: Riverhead Books, 2011.

Melvin E. Conway. “How do committees invent?ˮ In Datamation 14(4), April, 1968, pp. 28-31.

Dr. Winston W. Royce. “Managing the Development of Large Software Systems.ˮ In Proceedings IEEE WESCON, agosto 1970, pp. 1-9. (Originariamente pubblicato da TRW.)

Bosch Software Innovations. “Lezioni apprese: Organizzazione agile presso Bosch Software Innovations.ˮ YouTube.com, 15 giugno 2018, https://www.youtube.com/watch?v=CwodQs7D8BY.

Crediti immagine: Immagini fornite da PresenterMedia.com.

.