Jak funguje Conwayův zákon, proč na něm záleží a jak ho využít ve svůj prospěch.

Komunikační kanály (ať už po firemní hierarchii, nebo mimo ni) v rámci organizace účinně omezují řešení, které může organizace navrhnout. Toho však můžeme strategicky využít ve svůj prospěch. Pokud chceme zabránit vzniku některých návrhů – třeba takových, které jsou příliš orientované na technické interní záležitosti – můžeme organizaci upravit tak, aby tomu struktura bránila. A naopak, pokud chceme, aby naše organizace objevila a přijala určité návrhy – třeba takové, které jsou příznivější pro flow -, můžeme tomu reorganizací napomáhat. Neexistuje samozřejmě žádná záruka, vzniknou právě takové návrhy, které chceme, ale tím, že aktivně utváříme komunikační cesty, pravděpodobnost zvyšujeme. (Str. 17)

A také, že každá reorganizace potřebuje technickou expertizu!

Jak říká Michael Nygard: „Rozdělení na týmy je prvním návrhem architektury.“ (Str. 22)

Základem je pochopitelně „team-first“ orientace, tým na prvním místě. Týmy musí být stabilní, dlouhotrvající, s minimalizovanou kognitivní zátěží a řízenými interakcemi.

Pak už následuje těžiště knihy, Team Topologies that Work for Flow. Nejprve to, co nefunguje, antipatterny, pak vysvětlení Dev, Ops a DevOps, nutnost respektovat aktuální situaci a konečně identifikování čtyř základních topologií

• Stream-aligned neboli feature / produktové týmy
• Enabling týmy pro zkoumání a zavádění nových věcí (na které produktové týmy řešící byznysové dodávky nemají prostor)
• Týmy nad komplikovanými subsystémy, kdy bychom nedokázali do každého produktového týmu dát specialistu na danou oblast
• Platformové týmy, které dodávají takové služby, aby se produktové týmy mohly soustředit na dodávky

V každém případě bychom se měli snažit o co nejmenší smysluplnou platformu (minimum viable platform, MVP) a nedopustit, aby měla rozhodující slovo. Jak říká Allan Kelly, „vývojáři softwaru rádi budují platformy a bez produktového řízení vytváří víc než je třeba.“ Je třeba hledat takový rozsah, který je dostatečně malý a zároveň pomáhá urychlovat a zjednodušovat dodávání softwaru týmům, které ji používají. (Str. 101)

Nechybí tipy čemu se vyhýbat a na co dávat pozor, jako skryté monolity, přirozené „linie rozpadu“ apod.

Ve třetí části Evolving Team Interactions for Innovation and Rapid Delivery navazují modely spolupráce mezi týmy. I těch je jen několik základních a je dobré si je uvědomovat a jasně si je deklarovat. Jsou to

• Collaboration neboli spolupráce na stejném cíli, obvykle průzkum nové technologie nebo přístupu. Je to drahé, ale přináší vysokou míru učení.
• X-as-a-service – tým poskytuje svůj produkt jako službu ostatním, má definované rozhraní, informace a spolupráce je tak minimální.
• Facilitating mode – jeden tým, obvykle „enabling“, školí a provádí při nástupu do nové technologie.

Je tedy třeba pečlivě zvolit, jaký typ práce (a spolupráce) tým potřebuje, efektivně zkombinovat – a také dále sledovat v čase, vše se vyvíjí, potřeby se mění a existují indikátory, jak pravý čas rozpoznat. Třeba že systém přerostl jeden tým, klesá frekvence dodávek, nebo je příliš závislostí na jiných systémech.

Čtení je to fascinující a plné „aha“ momentů, obzvlášť pokud jste z oboru a z velké firmy s bohatou historií nejrůznějších reorganizací a snah poskládat týmy znovu a lépe. Pro manažery by to mělo být povinné čtení. A pro nemanažery přinese vysvětlení principů, potřeb a argumenty do diskuzí.

Odkazy: