…věci fungují dobře, protože každý prostě dělá, co je třeba, z čirého nadšení, tak hladce, že by pozorovatel mohl dojít k závěru, že všichni mají schopnost číst si navzájem myšlenky. S růstem organizace a produktu však roste i množství informací, které musí týmy ovládat, spravovat a sdílet, aby svou práci zvládly. Rozhodnutí jsou stále citlivější na kontext (týmů i produktů), což je složité a žádá si to nějakou strukturu, která by zajistila hladký chod organizace. Hledáte organizační strukturu, která optimalizuje schopnost týmu dělat věci tak, aby vytvořil Největší hodnotu.

✥ ✥ ✥

Efektivní komunikace a zpětná vazba jsou jádrem efektivního vývoje komplexního systému a organizační struktura by měla být optimalizována pro nejdůležitější cesty komunikace. Komunikace a pravidelná zpětná vazba jsou spolu se sebeorganizací srdcem agilního systému. Interakce lidí s různými, průřezovými zájmy leží v srdci inovací ().

Vývojové týmy pracující na komplexních produktech neustále bojují s dvojí povahou funkce a formy. Máme tendenci vytvářet hranice mezi vývojovými činnostmi a organizačními jednotkami podle těchto linií. Funkce a forma jsou však jen sociálně konstruované a poněkud arbitrární kategorie: spolehlivost může být pro daný systém stejně naléhavým zájmem, zatímco krása, zpětná kompatibilita nebo jiný zájem může danému vývojovému úsilí dominovat. V každém případě bude podniku nejlépe sloužit, pokud se vývojový tým zorganizuje kolem nejzásadnějších obchodních zájmů – ať už jsou jakékoli.

Když váš tým ve svých začátcích teprve dozrává a začíná směřovat k budování týmu Scrum, máte více lidí, kteří mohou pohodlně pracovat jako jedna organizační jednotka a pokrývat všechny funkce podniku (plánování vydání, vývoj a odborný růst). Růst a zralost však také způsobují nepohodlí, protože týmy touží po nestrukturované efektivitě jednoduchých dnů neformální práce. Přesto růst a správné řízení produktu na trhu vyžaduje poněkud disciplinovanou organizační strukturu a určité odlehčené řízení.

Kultury mají vnitřní potřebu struktury pro efektivní fungování celku. Nejefektivnější komunikace se vždy odehrává lokálně ve sféře známých, takže je nezbytné lokalizovat rozhodovací proces kolem nejzásadnějších organizačních problémů. V každé netriviální sociální organizaci je důležité, aby si lidé mohli rychle spojit jakoukoli danou oblast zájmu s nejefektivnějším „místem, kam jít“, když potřebují informace o této oblasti nebo potřebují v této oblasti jednat.

V jednoduchých oblastech, které se musí zabývat pouze jedním souborem oddělitelných zájmů, stačí jednoduché organizační rozdělení (tj. hierarchie). Hierarchický přístup se však hroutí v typičtějším případě vývojového úsilí s více překrývajícími se zájmy. To tlačí k větším a složitějším organizačním celkům, které se snaží problém napravit úsporami z rozsahu. Přesto jsou nejefektivnějšími pracovními týmy malé týmy a je třeba práci nějak rozdělit.

Žádný tým však není ostrov a vývojový národ je více než soubor ostrovů. Týmy si individuálně vytvářejí vlastní identitu, přičemž přirozený smysl pro xenofobii (potřeba známého) způsobuje, že týmy přisuzují pouze druhořadé postavení zájmům přicházejícím mimo jejich sociální okruh. Omezíte-li podnik na jednu množinu sociálních interakcí, založenou na jediném jednoduchém rozdělení, uzavíráte tím mimohraniční nápady, které pohánějí inovace.

Rychlost rozhodování je prvořadá. Některé otázky jsou naléhavé („Napadl nás jiný kmen a musíme proti němu podniknout obranu“), zatímco jiné, ačkoli jsou důležité, snesou delší zvažování nebo si o něj dokonce říkají („Jaké je nejlepší místo pro novou zasedací síň?“). Termín střižné vrstvy popisuje související procesy, které se pohybují různou rychlostí, podle představy tektonických desek, které se pohybují napříč, což vede například k zemětřesení. Jak architekti budov (), tak obor softwarové architektury (viz ) přijali tento výraz k popisu struktur nebo problémů s různou rychlostí změn v těsně propojeném systému. Společnost by měla strukturovat svou organizaci tak, aby byla schopna rychle reagovat na problémy v první kategorii, aniž by se zničila její efektivita pro problémy v kategorii druhé.

Další agilní zásadou je, že jsme orientováni směrem ven: to znamená, že se zaměřujeme a zajímáme o koncového uživatele, trh a zákazníky, nikoli o nástroje a technologie, které používáme k naší práci. Tento zájem by měla odrážet i organizace, protože je klíčem k hodnotové nabídce a konstrukci celého hodnotového toku vývoje.

Struktura organizace by nakonec měla mít stejně tak co do činění se strukturou procesu jako se strukturou produktu.

Proto,

organizujte pracovníky do malých týmů o více či méně pěti lidech, rozdělených podle nejdůležitějších zájmů pro tvorbu hodnoty podniku. Tuto strukturu doplňte malým počtem průřezových struktur pro vedlejší, ale důležité zájmy, přičemž nikdy nezapomínejte, že tyto struktury jsou pouze optimalizací v jinak otevřeném prostředí neomezené spolupráce.

Považte podnik, který vyrábí mobilní telefon. Mohl by uspořádat své týmy Scrum kolem hlavních výstupů nebo kupovaných možností. Může tedy existovat jeden tým pro adresář, další pro kalendář a další pro tradičnější funkce telefonu: viz Oblast hodnot. To jsou primární zájmy podniku. Mohou však existovat skupiny, které se scházejí za účelem definování postupů, zásad a podnikových standardů (např. vzhledu uživatelského rozhraní) a které se skládají ze zástupců jednotlivých Scrum týmů. Tyto skupiny nevytvářejí produkt, ale slouží k výměně informací a jako zdroj standardů, kterými se řídí vývoj. Ve zdravých organizacích se členství v těchto posledních skupinách téměř zcela překrývá s členstvím ve vývojových týmech.

Ve většině prostředí odráží primární organizační struktura primární strukturu zainteresovaných stran, kterou je obvykle trh. Z tohoto důvodu neorganizujeme Scrum týmy podle rozdělení interních artefaktů ani podle loţisek doménových expertíz, ale spíše podle trţních výstupů, jako jsou funkce. Organizace podle funkcí nebo jiných tržních výstupů je také přínosem pro rychlou reakci na trh a zkrácení doby uvedení na trh, protože tým je místem veškeré práce potřebné k implementaci funkce. Tím se udržuje koordinace v rámci organizačních hranic. Pokud se organizační struktura řídí dílčími pracemi nebo klíčovými kompetencemi, pak změny na trhu nebo v povaze dodaného produktu budou pravděpodobně znamenat koordinaci mezi více týmy nebo organizacemi – což snižuje schopnost reagovat a prodlužuje dobu rozhodování.

Pokud je toto jediná struktura, podporuje pouze tržní pohled a marginalizuje řadu dalších oprávněných obchodních zájmů. Aby tato struktura fungovala, musí být doplněna průřezovými strukturami, které podporují druhou úroveň efektivity komunikace, např. ty, které se týkají klíčových kompetencí. Tento vzor se tedy téměř vždy objevuje společně se vzorem typu Birds of a Feather a vzorem popsaným v kapitole Domain Expertise in Roles. Organizační struktura rolí protíná zdi, které přirozeně vznikají mezi týmy. Zapojte produktové úsilí v rámci podniku, aby se propojilo mezi sebou a s výkonným vedením prostřednictvím MetaScrum. Týmy, které si vytvořily určitý stupeň týmové hrdosti (viz Týmová hrdost), budou efektivnější, protože tato nebo jiná rovnocenná síla bude podporovat odpovědnost. To pomáhá zajistit, aby tyto struktury zůstaly ve hře navzdory xenofobním účinkům členství v týmu.

Spojte vše dohromady otevřeným prostředím bez zdí a dveří. Vývojové týmy jsou pouze jednotky vývojového nasazení a neměly by existovat žádné zásahy omezující volnou spolupráci mezi vývojáři napříč týmy. Přidejte poblíž malé místnosti pro krátká období klidu, vážného přemýšlení a malých schůzek.

Jakákoli hodnotová složka je férovým organizačním kritériem. Například Scrum vysoce oceňuje kolokaci členů týmu, takže nejzákladnější organizační hranice budou pravděpodobně odpovídat kolokačním týmům.

✥ ✥ ✥

Všimněte si, že v dobrém Scrumu existují dvě úrovně Conwayova zákona: jedna je řízena zaměřením na produkt a druhá zaměřením na oblasti kompetencí. Na povrchové úrovni organizujeme tým podle procesu; ten je primárním zájmem pro vnitřní i vnější aspekty procesu. Tři sféry ovládání procesu jsou tedy:

• vývojový tým, který vlastní rozhodnutí o vhodném použití technologie a techniky při budování produktu;
• vlastník produktu, který vlastní definici a směřování produktu; a,
• ScrumMaster, který je zodpovědný za to, že proces podporuje pravidelné dodávky vývojového týmu.

Vývojové týmy Scrum jsou funkční (produktové) týmy. To znamená, že primární organizační princip Scrum týmu spočívá v tom, že se přizpůsobuje souběhu dodávek funkcí podél hodnotového toku. V rámci Scrumu existuje slabá, mělká hierarchická organizace, která pojme více vývojových týmů v rámci každého vývoje produktu, které sdílejí společného Product Ownera, v organizaci zvané Scrum of Scrum. Každý vývojový tým v rámci jednoho vývoje produktu vytváří vždy jednu sadu funkcí. Postupem času tyto funkce propojí klíčové obchodní faktory, sdílené obchodní znalosti a artefakty hodnotového toku. V rámci vývojového týmu neexistují žádné uznávané tituly ani pododdělení.

Existuje mnoho způsobů, jak rozdělit práci do feature týmů. Vývojový tým může dodávat funkce pro daný trh (viz Organizace sleduje trh) nebo vyvíjet produkt pro určitou podmnožinu spektra podnikových technologií (jeden tým pro telefony a jiný pro tablety, ačkoli oba sdílejí většinu stejného softwaru). Obecně by měl být každý tým vytvořen kolem nějakého produktu, který představuje složku hodnoty podniku: viz také Value Stream Fork. Scrum však nedoporučuje strukturu vývojových týmů, kde každý tým vlastní jednu část produktu nebo jen dílčí část produktu. Pokud členové některého z týmů mohou vyvíjet pouze jednu část systému, budou muset koordinovat více vývojových rozhodnutí s ostatními týmy. Pro týmy se stává obtížné rozhodovat lokálně a výsledkem je zpožděná zpětná vazba a předávání.“

Na druhé úrovni Conwayova zákona v rámci Scrumu se lidé organizují kolem kompetenčních oblastí, v nichž odbornost zvyšuje hodnotu. Tito ptáci z peří pomáhají členům prohlubovat jejich vybavenost v některé odborné nebo technické oblasti, když sdílejí nápady nebo absolvují školení. Většina lidí má vrozenou touhu zlepšovat se (viz ) a tyto skupiny živí individuální hrdost, protože členové týmu se učí a rostou. Opět však platí, že tyto skupiny netvoří podřízenou strukturu a každý člen týmu může patřit do několika Birds of a Feather stejně jako do svého vlastního Scrum týmu. Viz také Doménová odbornost v rolích.

Hranice a identita vývojového týmu, stejně jako hranice a identita Scrum týmu, jsou explicitní. Pojem týmové identity je klíčový pro hrdost týmu a efektivní fungování organizace, protože týmová identita přináší sociální kontext, který pomáhá optimalizovat rozhodování. Jakékoli pojetí organizační identity nad rámec těchto dvou by mělo být spíše tiché než explicitní nebo spravované. V rámci vývojového týmu opět neexistují žádné jiné formální tituly než „vývojář“. Pokud existuje jen jedno nedotknutelné pravidlo, pak je to to, že žádný jednotlivec nemůže využít své tiché odborné stanice k tomu, aby převážil nad týmovým konsensem nebo jakýmkoli jiným způsobem oslabil ducha týmové práce, jako je tomu v Duchu hry. Společně vytvořené normy chování jsou silnou předzvěstí týmové identity.

Na úrovni jednotlivců může existovat odbornost v rolích, ale je důležité doplnit tento vzorec o multifunkční týmy všude, kde je to možné, aby se optimalizovala možnost lokálního rozhodování.

Původní Conwayův zákon vyšel ze softwaru (viz , str. 28-31). Se vznikem a praxí Conwayova zákona je spojeno mnoho mýtů. Dlouho se tvrdilo, že objektová orientace podporuje Conwayův zákon tím, že lokalizuje tržní zájmy uvnitř tříd. To je pravda jen napůl; třídy mají tendenci zapouzdřovat dlouhodobé zájmy klíčové kompetence organizace. Přesto se zdá, že objektová orientace se zaměřuje spíše na spojení mezi odborností vývojářů a artefakty, které vyvíjejí, než na nějaké spojení s trhem nebo případy užití. Obavy o soulad s tržní strukturou by měly převážit nad obavami o světonázor vývojářů na jejich proces a produkt.

Vodopádový styl vývoje měl svůj rozkvět. Ve vodopádových organizacích primární organizační struktura sledovala procesní fáze: analýzu požadavků, návrh, implementaci a testování (, s. 1-9). Podle Conwayova zákona organizační struktura odrážela tyto procesní zájmy. Software může tyto fáze velmi dobře odrážet také: například architektura orientovaná na služby (SOA) bude evidovat většinu požadavků s přidanou hodnotou ve vrstvě integrace služeb, zatímco jednotlivé služby se nacházejí v jiné vrstvě. Vodopád dává vývojářům do rukou všechny funkce najednou, což podporuje uvažování o interakcích mezi funkcemi. Zatímco přístupy k návrhu softwaru vodopádové éry se snažily uvést tržní zájmy (případy užití) do souladu s architekturou, organizační struktura tuto taxonomii protínala. Totéž lze říci o organizaci montážní linky v továrnách.

Protože vývojové týmy jsou funkční týmy, měly by se soustředit na jednu funkci najednou (jako ve Swarmingu). Primárním výstupem Scrumu na trh je funkce a v tomto smyslu existuje dobrý soulad mezi strukturou týmu a trhem. Scrum mlčí o podobě architektury produktu, ale v duchu agilního přístupu má tendenci odrazovat od individuálního vlastnictví kódu. Každý vývojový tým má licenci pracovat na libovolné části produktu. Můžeme říci, že Scrum vyvažuje organizační výhody zapouzdření s výhodami sladění týmu s tržním produktem. Vlastník produktu s podporou vývojového týmu řídí, jak řešit interakce funkcí, které se objeví v průběhu času.

Považte například, že jeden tým může implementovat funkci čekajícího hovoru pro telekomunikační systém, zatímco jiný tým implementuje přesměrování hovorů. Kvůli vzniku nelze vždy předvídat náklady na řešení závislostí mezi libovolnými dvěma danými položkami produktového portfolia (PBI), takže obecně není možné tento problém překonat přiřazením PBI týmům. V každém případě může předčasné přidělení práce týmům znemožnit lidem efektivně pracovat na náročných částech (zejména těch, které se týkají interakce mezi jednotlivými částmi) a omezuje samoorganizaci na úrovni Scrum týmu. Tyto dvě funkce mohou být silně vzájemně závislé, ale struktura Scrumu nedává těmto interakcím prvotřídní postavení. V tomto případě by pravděpodobně bylo lepší, kdyby obě funkce vyvíjel jeden tým. Způsob přidělování práce týmům staví na průběžném plánování a společném rozhodování, počínaje plánováním sprintu. Dobrý tým Scrum se snaží rozdělit práci mezi vývojové týmy prostřednictvím důvěrných, ale časově omezených interakcí mezi vlastníkem produktu a vývojovým týmem, stejně jako při událostech za účelem neustálého obnovování zpřesněného seznamu produktů (Refined Product Backlog) a také prostřednictvím plánování sprintů (Sprint Planning).

Součástí organizačního mixu je obvykle i management, i když existují vývojové týmy Scrum, které fungují bez manažerů (viz např. nedávné video o agilní transformaci ve společnosti Bosch Software Innovations. ) Étos Scrumu se obvykle zaměřuje na lidi a produkt a toto zaměření je ztělesněno v rolích Scrumu a organizacích (jako je tým vývojářů a tým vlastníků produktu), které zastupují. Pokud se organizace s již existujícími manažery pustí do zavádění Scrumu, je pro snahu Scrumu příliš snadné odmítnout manažerskou část organizace jako něco jiného. V takových situacích, kdy organizace bez managementu nepřipadá v úvahu, je zásadní zapojit manažery.

Steven Johnson. Odkud se berou dobré nápady. New York: Riverhead Trade, 2011.

Stewart Brand. Jak se budovy učí: Co se děje poté, co jsou postaveny. New York: Penguin, 1995.

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

Daniel Pink. Drive: Drive: Úžasná pravda o tom, co nás motivuje. New York:

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

Dr. Winston W. Royce. „Řízení vývoje rozsáhlých softwarových systémů.ˮ In Sborník IEEE WESCON, srpen 1970, str. 1-9. (Původně vydala společnost TRW.)

Bosch Software Innovations. „Poučení z praxe: Agile organization at Bosch Software Innovations.ˮ YouTube.com, 15. června 2018, https://www.youtube.com/watch?v=CwodQs7D8BY.

Obrázky jsou k dispozici: Obrázky poskytl PresenterMedia.com.