Come possono gli architetti lavorare con i team Scrum autoorganizzanti?

Un'organizzazione con un numero di agili team Scrum ha anche un piccolo gruppo di persone nominate come "architetti aziendali". Il gruppo EA funge da controllo e gatekeeper per qualità e aderenza alle decisioni. Ciò porta a sovrapposizioni tra la decisione del team e le decisioni EA.

Ad esempio, il team potrebbe voler utilizzare la libreria X o utilizzare REST invece di SOAP, ma l'EA non lo approva.

Ora, questo può portare alla frustrazione quando le decisioni del team vengono annullate. Se preso abbastanza lontano, può potenzialmente portare a una situazione in cui il popolo EA "prende" tutto il potere e il team finisce per sentirsi demotivato e per niente agile.

Le guide Scrum hanno questo da dire al riguardo:

Auto-organizzazione: nessuno (nemmeno lo Scrum Master) dice al Team di Sviluppo come trasformare il Product Backlog in Incrementi di funzionalità potenzialmente rilasciabili.

È ragionevole? Il team EA dovrebbe essere sciolto? Le squadre dovrebbero rifiutare o semplicemente rispettare?

Un team di sviluppo è composto da 3–9 persone con competenze interfunzionali che svolgono il lavoro effettivo

Scrum Master dovrebbe invitare "Enterprise Architect" a far parte del team di progetto. Quindi la comunicazione tra architetto e programmatori sarebbe eccellente.

La scelta della tecnologia utilizzata fa parte dei requisiti del software, il che significa che fa parte della richiesta di funzionalità che non si utilizzano determinate tecnologie, per qualsiasi motivo.

Gli architetti parlano per i sistemi e il codebase perché i sistemi e il codebase non possono parlare da soli. Avere un architetto è generalmente nel migliore interesse a lungo termine di un'azienda, in particolare uno che si basa su un software che è costruito internamente.

Gli architetti non stanno dicendo agli sviluppatori come trasformare il backlog in incrementi (sprint), stanno dicendo quali tecnologie possono e non possono essere utilizzate. Stai combinando due diversi problemi.

La soluzione è di non cambiare nulla. Se i tuoi team si sentono frustrati perché gli architetti sono troppo restrittivi o prepotenti, questo è un problema del personale che non ha nulla a che fare con SCRUM e dovrebbe essere affrontato con gli stakeholder aziendali come un problema di soddisfazione dei dipendenti e, se possibile, i profitti ("Ci vuole x%più tempo per sviluppare funzionalità yperché l'architetto znon ci permetterà di usare Turbo Pascal.")

Questo genere di cose è necessario per mantenere l'equilibrio tra la necessità di un grande team per portare a termine il progetto e la necessità di mantenere piccoli team agili.

In generale, la "mischia di leader di squadra" è composta da un membro eletto da ciascuna delle squadre più piccole. Ciò fornisce un po 'della natura auto-organizzante, oltre a fornire un qualche modo di rappresentazione in modo che le decisioni prese dal gruppo di alto livello siano accettate dal gruppo agile.

Per il tuo particolare scenario, qualcosa dovrebbe essere fatto per fermare l'agile demotivazione della squadra, ma probabilmente non ribellione o semplice accettazione. Il team deve rendersi conto che sei lì per creare un buon software, non parlare agli ideali. Avere un gruppo di team diversi, ognuno con tecnologie diverse per fare cose simili nello stesso progetto, porterà a un software peggiore. Avere un gruppo di team diversi che utilizzano standard di codifica diversi nello stesso progetto porterà a un software peggiore.

Quindi avrai bisogno di un modo per raggiungere un consenso su come funzionerà il progetto. La mischia principale del team viene utilizzata in altri luoghi in modo efficace. Potrebbe essere necessario fare qualcosa in modo diverso o esaminare perché il tuo gruppo non lo sta facendo in modo efficace.

La domanda è: qual è la ragione per cui esiste questo team di architetti? L'unica ragione che mi viene in mente è di rafforzare l'interoperabilità tra i vari team. Oppure i team stanno lavorando su varie parti del singolo prodotto e questo team di architetti esiste per far sì che ogni parte lavori insieme.

Non credo davvero che questo schema possa funzionare bene in un ambiente agile, per le ragioni esatte che dici. Le varie squadre dovrebbero essere autonome e così dovrebbero essere i loro input e output. Pertanto, limitare i loro risultati dovrebbe essere solo una parte dei requisiti in materia di input. Ma tali vincoli dovrebbero essere ragionevoli. Qualcosa del tipo "Non usare la libreria X" non è un buon requisito, ma dire "Devi limitare al minimo il numero di librerie di terze parti usate" o "L'aggiunta di nuove librerie che non sono utilizzate in altri team dovrebbe essere limitato". dovrebbe andare bene.

Quindi dissolverei il team di architetti in tutti i team e utilizzerei la loro esperienza in questioni di architettura. Entrando a far parte del team, saranno in grado di vedere meglio i problemi del team e potrebbero avere idee migliori o opinioni più istruite sul cambiamento delle parti fondamentali dell'architettura. Dovrebbe inoltre essere incoraggiato gli architetti di tutti i team a comunicare per garantire che l'architettura rimanga coerente tra i team.

Il gruppo di Scaled Agile Framework ne parla davvero bene. La maggior parte di noi opera a livello di squadra, ma quando si ingrandisce è necessario riconoscere che ci sono ruoli da svolgere anche a livello di programma e portafoglio. Le decisioni sull'architettura devono essere prese in tutta l'organizzazione e ciò dovrebbe alimentare ciò che sta accadendo ai livelli inferiori dell'organizzazione. Non c'è niente di sbagliato nell'avere decisioni architettoniche!

A questo proposito, il recente libro di Dean Leffingwell su Agile Software Requirements è una buona lettura su questo argomento, l'ho letto da solo.

Abbiamo anche più team agili (alcuni fanno Kanban, altri Scrum) e architetti. Gli architetti sono responsabili dell'infrastruttura che copre tutti i nostri prodotti (librerie di supporto, autenticazione, costruzione di infrastrutture) ecc. Prendono decisioni tecniche, ma implementano anche cose, principalmente componenti di infrastrutture.

Funziona bene e di solito non c'è conflitto. Credo che un punto cruciale sia:

Gli architetti non hanno alcuna autorità formale nei confronti dei team e non possono semplicemente annullarli. Normalmente, gli architetti prendono decisioni che si applicano a tutti i prodotti e i team prendono decisioni per il loro prodotto. In caso di conflitto, l'architetto e il team devono solo raggiungere un accordo o passare alla direzione (sebbene ciò accada raramente).

Penso che sia davvero importante fare pari tra architetti e sviluppatori. Entrambi lavorano per un obiettivo comune, solo in aree diverse. Se nessuno può semplicemente "prevalere" sull'altro, la cooperazione sarà migliore.

Non vedo alcun conflitto qui. Da quello che ho capito, tutto l'EA (per quanto pomposo sia un titolo che penso sia) è destinato al QA. Tutti dovrebbero esserne consapevoli.

Dovresti considerare che in qualsiasi metodologia di sviluppo (che merita di essere considerata una) la raccolta dei requisiti è un passaggio cruciale, sia esso iterativo o iniziale.

Alcuni di questi requisiti sono stabiliti dalla politica aziendale. E questi stabiliscono le regole di base:

• Il team dovrà attenersi a loro come a qualsiasi altro requisito. La sfida della politica è quindi semplicemente al di fuori dell'ambito del progetto e dovrebbe essere gestita separatamente.
• Il compito di EA è far rispettare questi requisiti e non imporre la loro fantasia personale. A loro non piace X, questa è la loro opinione personale. Niente di più, niente di meno. Trattalo come qualsiasi altra opinione. Tuttavia, se l'EA può dimostrare che l'uso di X viola un requisito esistente, allora hanno il diritto di vietare l'uso di X e se conoscono un'alternativa praticabile e il team non lo fa, allora è loro diritto applicarlo.

Ma in entrambi i casi, un requisito è soddisfatto o meno. Se tale determinazione è difficile da prendere, allora il requisito è carente e devi ribadirlo per diventare veramente testabile (in senso lato). Dovresti gestirlo come qualsiasi reiterazione dei requisiti.

Il tuo architetto non dovrebbe annullare le decisioni prese dai tuoi team agili. Il tuo architetto dovrebbe includerli nei requisiti / storie passati ai team. Dovrebbero tenere aggiornati i team quando vengono introdotti gli scenari del progetto e vengono introdotti nuovi requisiti di interoperabilità.

Gli architetti che impartiscono ordini e controllano le decisioni tecniche sono un difetto culturale. Si vedono come il "capo" piuttosto che semplicemente mantenere un obiettivo / visione condivisi e mantenere squadre separate sulla stessa pagina. Le metodologie agili si basano su comunicazione e contatto. Quando i tuoi architetti non vengono coinvolti fino a quando non vengono prese le decisioni, non riescono ad agili.

Martin, penso che potresti avere un'idea sbagliata di come una squadra auto-organizzante funzioni nel suo ambiente.

Hai citato la Scrum Guide: "Nessuno (nemmeno lo Scrum Master) dice al team di sviluppo come trasformare l'arretrato di prodotto in incrementi di funzionalità potenzialmente rilasciabili".

Questa non è una licenza per il team Scrum di fare tutto ciò che vuole (purché fornisca) senza tener conto delle esigenze tecnologiche e di business dell'azienda nel suo complesso e delle esigenze degli altri team.

Le parti interessate possono abusare della loro influenza. Questa è una delle sfide della collaborazione e certamente non si limita all'EA. Ma la collaborazione non finisce ai confini del team.

Waterfall o Scrum (questo sembra mescolare due, che sì, non funzionerà), che suona come un livello di gestione piuttosto inutile per me in primo luogo. I gatekeeper sulle decisioni tecnologiche dovrebbero essere i principali sviluppatori, il responsabile generale dello sviluppo il cui compito dovrebbe essere quello di impedire alle preferenze degli sviluppatori di trasformare la tua app in un'idra di scelte tecnologiche e chi ha il budget deve pagare il conto potenziale.

Niente continua a stupirmi come i non-sviluppatori che hanno davvero il coraggio di prendere decisioni tecnologiche senza nemmeno consultare le persone reali che devono subire le conseguenze di quelle decisioni.