„Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.“
M. Conway
Problém s vývojem v naší korporaci je jednoduchý: aby se něco objevilo v produkci, je potřeba spolupráce několika vývojářských týmů: obvykle přinejmenším CRM týmu, týmu, který dělá frontend, a týmu který řeší notifikace. A na ně „prší“ požadavky ze všech stran, takže si je nemůžeme „uzurpovat“ na celý sprint, aby dělaly to co potřebujeme – musíme se o ně dělit s dalšími.
Říkal jsem sice mockrát, že agilní tým musí být postaven na vlastních vývojářích, že je nejde sdílet ani nějak „outsourcovat“. Protiargumenty jsou vždycky stejné: vývojářů je málo a systémy rozsáhlé. Pokud naše user story zasahuje do pěti systémů, museli bychom mít vývojáře, který rozumí všem pěti, nebo pět různých specialistů, což je velmi nákladné a ani bychom je nedokázali vytížit prací.
Tady je dost přesně vidět, že agilní transformace nemůže doopravdy fungovat, když struktura týmů neladí s IT architekturou.
V našem případě je to vlastně „inverzní Conwayův zákon“ – IT systém už existuje a my mu musíme přizpůsobit komunikační strukturu firmy.
Jak toho prakticky dosáhnout? Není to jednoduché, ale řekl bych že pro začátek by stačilo, aby každý agilní tým měl vlastní repozitář kódu, kam ukládá veškeré výstupy a za ty si ručí. Typicky to může být projekt v GITu (nebo několik projektů). Pokud se o jeden kód bude „přetahovat“ s dalšími týmy, nebude to fungovat.
Nevýhodou je, že jde o „vnitřní přístup“ – místo potřeb zákazníka dáváme na první místo vnitřní struktury společnosti. Pokud už ale existuje IT infrastruktura, nevím o žádné fungující alternativě.
Ne že bychom to nezkoušeli, vznikaly tu týmy kolem produktu, projektu, tržního segmentu, zadavatele, typu činnosti… Nic z toho dobře nefungovalo. Dokážu si představit, že by to mohlo fungovat v případě, že by firma měla hodně homogenní systém. Pak by kterýkoli vývojář dokázal pracovat na kterékoli části. Takovou výhodu my ale nemáme, takže nás to nutí stavět týmy jedním konkrétním způsobem.
Pokud máte zkušenosti s nějakým jiným životaschopným modelem, napište, rád se poučím. Strukturovat týmy podle IT systémů je totiž pro mě, jako designéra, mimořádně pitomé. V tuto chvíli však nevidím žádnou rozumnou fungující alternativu.