Agilní týmy často vznikají z důvodu pružnější reakce na změny trhu. Jejich výhody jsou nesporné, pokud se zavedou správným způsobem. Ale ruku na srdce: v řadě velkých firem je správné nastavení agility nelehký úkol:

Chybí seniorní backend specialisté.
Lidé nejsou zastupitelní.
Product Owner nemá čas sedět s týmem.
Bráníme se reworku, pokud hned napoprvé netrefíme zadání.

Lidem se do změny nechce a není divu, léta sbírali svoje zkušenosti a agilní přístupy na nich lecos mění.

Do této situace dnes vstupuje AI, která pomáhá měnit ekonomiku práce ve vývojových a produktových týmech. Nejde ale jen o to, že generuje kód nebo testy. Jde i o to, že mění samotnou strukturu týmů, jejich kompetence a způsob, jakým vzniká hodnota.
Jde o strukturální změnu agilních týmů.

Níže najdete 5 změn, které dnes vidíme v týmech, které AI integrují systematicky, ne jen jako osobní asistenty jednotlivců.

1. Specializace přestává být bariérou (I-shape → T/M-shape)

V tradičním vývoji jsme dlouhou dobu budovali týmy na principu specializace (tzv. I-shape). Čím větší firma, tím více specializací a úzkých rolí. Typické I-shape specializace jsou například:

Backend developer
Frontend developer
QA engineer
Architekt

S příchodem agilních frameworků se I-shape začal postupně měnit na T-shape (hluboká expertiza + drobné přesahy do dalších řemesel). To pak dost pomáhá s plánováním činností týmu i zastupitelností lidí. U univerzálnějších týmů plánujete kapacitu jako celek, ne jednotlivé specialisty.

A AI tento trend dále dramaticky akceleruje. Dnes „builder“, tedy člověk pracující na vývoji s podporou AI, řeší:

produktové zadání
frontend i backend
kvalitu kódu
generování testů
dokumentaci

Hodně samozřejmě záleží na tom, kam AI pustíte a kde pracuje tým. Ale jedno je zřejmé: AI rozšiřuje akční rádius každého člena týmu. To ale neznamená, že specializace zmizí. Jen to znamená, že specializace přestává být, tam kde začnou AI při vývoji využívat, bariérou. Firmy, které to pochopí, přecházejí od role-based struktury k flexibilnějším modelům práce. A to má zásadní dopad na adaptivitu i produktivitu týmu.

A jedna otázka k zamyšlení:
Kolik vašich rolí dnes existuje jen proto, že technologie dříve nedovolovala širší záběr?

2. Cross-functional týmy zbavené bariér

Velká specializace a organizace kolem různých řemesel vytvářely v tradičních firmách řadu externích závislostí. Vznikala tzv. sila. Tyto týmy nebo oddělení musí spolupracovat na různých projektech, ale mají obvykle i vlastní cíle a vlastní priority. A právě kvůli jejich vlastním prioritám pak sila často omezují spolupráci s okolními týmy/odděleními. Nemají společné cíle jako tým napříč celou firmou,

Oproti tomu. agilní týmy se staví jako tzv. cross-functional. V jednom týmu jsou lidé z více oddělení: vývoj, business, QA, někdy i právník nebo marketing. Externí závislosti a bariéry spolupráce tak ubývají. Ve velkých firmách se ale často setkáte s řadou výzev, jak týmy nastavit:

potřebujete jen část kapacity specialisty
člověk je sdílený mezi týmy
oddělení potřebují klíčové lidi pro sebe

AI v agilních týmech navíc znamená další posun, snižuje bariéry mezi rolemi. Tým už není cross-functional jen proto, že má různé role. Je cross-functional navíc i proto, že dokáže pokrýt širší spektrum činností bez čekání na „správného specialistu“.

AI například pomáhá:

s prvotní analýzou textů
s generováním marketingových variant
s návrhem architektonických řešení
s testovacími scénáři

Samozřejmě vždy záleží na tom, kde chcete mít kontrolu a kam AI pustíte. Ale realita je taková, že některé role, na které byste jinak čekali týdny, dnes zvládne tým s podporou AI během hodin.

Cross-functional už není jen organizační ambice. Stává se technologickým efektem.

3. Zvyšuje se zastupitelnost lidí

Jedním z největších problémů tradičních týmů byl tzv. bus factor – závislost na konkrétním seniorovi.

Vše bylo v hlavě jednoho člověka.
Dokumentace byla minimální.
A pokud senior nebyl v práci, tým se zastavil.

Agilní přístupy se proto snaží budovat zastupitelnost v týmech pomocí T-shape a sdílení know-how. Lidé v týmech si vychovávají svoje kolegy, kteří pak mohou pomoci s jednoduššími úkoly s větší či menší mírou kontroly od seniornějších kolegů.

A AI ve vývoji software tento proces dál výrazně zrychluje. AI dnes navíc:

vysvětluje existující kód
analyzuje historii změn
generuje dokumentaci
pomáhá s onboardingem

Načtení složité aplikace je pro AI otázkou minut. Pro člověka to bývaly týdny. To ale opět neznamená, že zkušenost seniora zmizí. Znamená to, že jeho znalost už není jediným zdrojem pravdy, týmy se tak stávají efektivnějšími a soběstačnějšími. A z pohledu leadershipu je to zásadní posun v řízení rizika.

A opět jedna otázka:
Je vaše organizace připravena na to, že know-how už nemusí být hlavní vyjednávací páka jednotlivců?

4. End-to-end produktové týmy se stávají realistickými

Ve světě tradičního vývoje byly dříve týmy organizované podle systémů, šlo o tzv. komponentní týmy. To znamenalo silnou potřebu řídit závislosti, abyste mohli dodat celý projekt.

Agilní přístupy přinesly změnu, koncept end-to-end (E2E) týmů. Tedy týmů poskládaných ze všech rolí, které dokážou dodat hodnotu vašeho produktu od A až po Z.

.Tento princip se snadno zavádí v menších firmách, ale ve velkých korporátních společnostech se tento přístup setkává s řadou nutných kompromisů.
A v některých velkých korporacích je E2E tým v krátkodobém horizontu těžko dosažitelný ideál.

AI dnes umožňuje pokrýt větší část value streamu přímo v rámci jednoho týmu:

vývoj frontendu
vývoj backendu
generování testů
průběžnou kontrolu kvality

Pokud jste ochotni používat AI napříč systémy, část historických závislostí mizí. E2E tým přestává být organizační revolucí. Stává se technologickou možností.

A to je pro velké firmy zásadní změna.

5. Rework se zmenšuje díky kratším feedback loopům

Tradiční projektové řízení obvykle počítalo u projektů s omezeným množstvím změnových požadavků. A na to byly v plánu v lepším případě připravené rezervy.

Agilní přístupy naopak přijímají změnu jako přirozenou součást cesty. Zaměřují se na život s neustálou změnou. Cílem je zjistit, že jdeme špatným směrem včas, dokud nás změna ještě příliš nestojí. A proto bývá tento způsob práce spojován s přepracováváním toho co už bylo uděláno (tzv. reworkem). Moje zkušenost je, že firmy se reworku často obávají, aby jim nezdražil vývoj. Ve skutečnosti ale dokáže rework zaměřený na zvýšení hodnoty pro zákazníky ušetřit mnohonásobně větší náklady, než vás stála jeho implementace.

I s využitím vývoje pomocí AI je patrné, že rework nikdy úplně nezmizí. Ale AI snižuje úsilí na řešení reworku. A tak týmy mohou snáze experimentovat a hledat správný směr, který ocení vaši zákazníci a nakonec i vy.

Využití AI pro rework znamená:

méně nákladné opravy
vyšší kvalitu výstupu
lepší predikovatelnost týmů

A hlavně: větší odvahu experimentovat. Firmy, které kombinují agilní přístupy a AI systematicky, často zjišťují, že rework už není strašák. Je to řízený nástroj kvality.

Co z toho plyne?

Většina firem dnes experimentuje s AI individuálně:

lidé používají AI asistenty
generují části kódu
testují automatické code review

To je dobrý začátek. Skutečný náskok ale vzniká ve chvíli, kdy se AI stane součástí struktury týmu a ne jen osobní pomůckou jednotlivců.Otázka tedy dnes není: „Používáme AI?“

Ale spíše se jedná o otázky typu:

Změnila AI strukturu našich agilních týmů?
Zvýšila zastupitelnost a autonomii?
Snížila závislosti mezi rolemi?
Upravili jsme metriky a governance?

Protože pokud se mění způsob práce, musí se změnit i způsob řízení.

Pokud to teď řešíte

Pokud stojíte před otázkou, jak systematicky integrovat AI do produktových a vývojových týmů tak, aby to vedlo ke skutečnému zvýšení výkonnosti a ne jen k experimentům, dává smysl projít váš konkrétní kontext.

Během 30 minut můžeme projít: