Come possono gli architetti lavorare con team Scrum auto-organizzanti?

A Development Team is made up of 3–9 people with cross-functional skills who do the actual work

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

La scelta della tecnologia utilizzata è 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 dei sistemi e del codice base perché i sistemi e il codice base non possono parlare da soli. Avere un architetto è generalmente nell'interesse a lungo termine di un'azienda, specialmente se si basa su un software 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 confondendo due diversi problemi.

La soluzione è di non cambiare nulla. Se i vostri team si sentono frustrati perché gli architetti sono troppo restrittivi o troppo prepotenti, si tratta di una questione personale che non ha nulla a che fare con SCRUM e dovrebbe essere affrontata con gli stakeholder aziendali come una questione di soddisfazione dei dipendenti e, se possibile, la linea di fondo ("Ci occorrono x% in più per sviluppare funzionalità per y perché l'architetto z non ci consente di utilizzare Turbo Pascal.")

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

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

Per il tuo scenario particolare, qualcosa dovrebbe essere fatto per fermare la demotivazione agile del team, ma probabilmente non per ribellione o semplice accettazione. Il team deve rendersi conto che tu sei lì per fare del buon software, non per cedere agli ideali. Avere un gruppo di diversi team, ciascuno utilizzando tecnologie diverse per fare cose simili nello stesso progetto, porterà a software peggiore. Avere un gruppo di squadre diverse usa standard di codifica diversi nello stesso progetto porterà a software peggiore.

Quindi avrai bisogno di un qualche modo per raggiungere un certo consenso su come il progetto funzionerà. Il team lead scrum viene utilizzato in altri posti in modo efficace. Potrebbe essere necessario fare qualcosa di diverso, o cercare perché il tuo gruppo non lo sta facendo in modo efficace.

La domanda è: qual è la ragione per cui esiste questo gruppo di architetti? L'unico motivo per cui posso pensare è quello 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 mantenere ogni parte a lavorare insieme.

Davvero non penso che questo schema possa funzionare bene in un ambiente agile, per ragioni esatte che dici. Le varie squadre dovrebbero essere autosufficienti e quindi dovrebbero essere i loro input e output. Quindi limitare le loro uscite dovrebbe essere solo parte dei requisiti in ingresso. Ma quei vincoli dovrebbero essere ragionevoli. Qualcosa come "Non usare la libreria X" non è un buon requisito, ma dire "Limitare il numero di librerie di terze parti utilizzate al minimo" o "Aggiungere nuove librerie, che non sono utilizzate in altri team dovrebbero essere limitate." dovrebbe andare bene.

Quindi dissolverei il team di architetti in tutti i team e userei la loro esperienza in questioni di architettura. Diventando parte del team, saranno in grado di vedere meglio i problemi che il team sta avendo e potrebbero avere idee migliori o opinioni più istruite su come cambiare le parti fondamentali dell'architettura. Dovrebbe anche essere incoraggiato gli architetti tra i team a comunicare per garantire che l'architettura rimanga coerente tra i team.

Il gruppo su Scaled Agile Framework parla molto bene di questo. La maggior parte di noi si occupa di livello di squadra, ma quando si scala, è necessario riconoscere che ci sono ruoli da svolgere anche a livello di programma e di portafoglio. Le decisioni architetturali devono essere prese in tutta l'organizzazione e questo dovrebbe alimentare ciò che sta accadendo ai livelli più bassi dell'organizzazione. Non c'è niente di sbagliato nel prendere decisioni architettoniche!

In relazione a questo, il recente libro di Dean Leffingwell su Agile Requisiti software è una buona lettura su questo argomento, L'ho letto da solo.

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

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

Gli architetti hanno nessuna autorità formale sui team e non possono semplicemente annullarli. Normalmente, gli architetti prendono decisioni che si applicano a tutti i prodotti e le squadre prendono decisioni per il loro prodotto. Se c'è un conflitto, allora architetto e amp; il team deve solo raggiungere un accordo o inoltrarsi alla direzione (anche se ciò accade raramente).

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

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

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

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

• Il team dovrà rispettarli come da qualsiasi altro requisito. Sfidare la politica è quindi semplicemente al di fuori dello scopo del progetto e dovrebbe essere gestito separatamente.
• Il lavoro di EA è quello di 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. Tratta come qualsiasi altra opinione. Tuttavia, se l'EA può dimostrare che l'utilizzo 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 no, allora è loro il diritto di applicarlo.

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

Il tuo architetto non dovrebbe ignorare le decisioni prese dai tuoi team agili. Il tuo architetto dovrebbe includere questi nei requisiti / storie passate ai team. Dovrebbero tenere aggiornati i team quando il panorama del progetto cambia e amp; vengono introdotti nuovi requisiti di interoperabilità.

Gli architetti che emettono ordini e controllano le decisioni tecniche sono un difetto culturale. Si considerano i "boss" piuttosto che semplicemente mantenendo un obiettivo / visione condivisa e amp; mantenendo squadre separate sulla stessa pagina. Le metodologie agili si basano su comunicazione e amp; contatto. Quando i tuoi architetti non vengono coinvolti fino a quando non vengono prese le decisioni, non riescono ad agilmente.

Martin, penso che potresti avere un'idea sbagliata su come funzioni un team auto-organizzante nel suo ambiente.

Hai citato la Guida Scrum: "Nessuno (nemmeno lo Scrum Master) dice al Team di sviluppo come trasformare il Product Backlog in Incrementi di funzionalità potenzialmente rilasciabili."

Questa non è una licenza per il team di Scrum per fare tutto ciò che vuole (a patto che fornisca), indipendentemente dalle esigenze tecnologiche e aziendali dell'azienda nel suo insieme e dalle esigenze degli altri team.

Certe parti interessate possono abusare della loro influenza. Questa è una delle sfide della collaborazione, e non è certamente limitata all'EA. Ma la collaborazione non finisce ai confini della squadra.

Waterfall o Scrum (questo sembra mixare due, che sì, non funzionerà), questo mi sembra un livello di gestione piuttosto inutile. I gatekeeper sulle decisioni tecnologiche dovrebbero essere lead devs, il manager generale dello sviluppo il cui compito dovrebbe essere quello di mantenere le preferenze di sviluppo di trasformare la tua app in una idra di scelte tecnologiche, e il budget di chiunque deve pagare il conto potenziale.

Niente continua a stupirmi come i non-dev in realtà hanno il coraggio di prendere decisioni sulla tecnologia senza nemmeno consultare le persone reali che devono subire le conseguenze di tali decisioni.