Proč agilní vývoj leckde selhává
Cílem tohoto příspěvku je zamyslet se nad tím, proč agilní vývoj leckde selhává, a co je skutečnou příčinou tohoto selhání.
Rozhodně nechci pohanit agile. On totiž selhává i ten vodopád, jenže od toho agile se jaksi naivně očekávalo, že určité problémy vyřeší. A on je nevyřešil a naopak je ještě více odhalil a poukázal na ně.
Ony problémy spočívají především ve způsobu uvažování, interních procesech a firemní kultuře, není v souladu s agilními principy, a která je příčinou tohoto, proč agile, se kterým uspěly startupy, nevyřešil problémy s vývojem v mnoha korporacích.
Hlavní myšlenkou agilního vývoje je iterativní uvolňování nových verzí a to v poměrně rychlém sledu. Světlo světa tak mohou velice rychle spatřit nové verze produktu, které se rychle dostanou ke svým uživatelům a od nich se pak vývojářům dostane i okamžité zpětné vazby. A nemusí to být ani levnější nebo rychlejší.
Jinak však uvažuje startup a jinak konzervativní firma. Je třeba znovu připomenout, že agile se začalo jako první používat ve startupech, které se rozhodně nevyznačovaly nějakým tradičním způsobem řízení a že jejich zaměstnanci byli vždy vysoce motivováni na dosažení cíle a táhli tak společně a bez rozdílu za jeden provaz.
Zpravidla proto, že se zároveň jednalo i o samotné zakladatele či obchodní společníky, kteří měli přímou možnost se podílet na rozhodování a zároveň byli hmotně zainteresováni na dosažení cíle a tedy i zisku. Někteří koneckonců zakládali startup jen proto, aby ho mohli co nejdříve prodat anebo transformovat na akciovou společnost a dosáhli zisku.
V takovém případě je nutné co nejdříve představit funkční prototyp a zvolit takovou metodiku vývoje, která povede co nejrychleji k tomuto cíli. Použití takových frameworků jako je extrémní programování, Scrum, FDD, Lean, Kanban anebo SAFe, je zcela na místě, neboť umožňuje rychlé iterativní uvolňování nových verzí.
Vzhledem k tomu, že startup má zpravidla minimální počet zaměstnanců a zároveň nemá téměř žádné zákazníky, tak si může dovolit vrhnout na trh takový produkt, kterým může být jak výrobek, tak i služba, která pak může obsahovat větší či menší množství chyb a projde mu to, protože jeho fanoušci mu to prostě odpustí. A v dalších verzích se pak ony chyby i odstraní.
A pokud takový startup zanikne, tak ani to to pro něj nemusí být žádná tragédie, protože titíž lidé založí krátce nato nový startup a zkusí to prostě znovu a zkoušet to mohou do aleluja anebo minimálně tak dlouho, dokud se najde investor, který bude ochoten do těchto lidí dál investovat. Není také výjimkou, že se většina startupů pohybuje několik let v červených číslech a většina jich poté i zanikne. Nezapomínejme, že jako příklad jsou nám dáváni jen ty, co uspěly.
Zde se pomalu dostáváme k tomu, proč dost často tento způsob vývoje v konzervativní společnost nefunguje anebo nefunguje tak, jak by si management přál. Asi už tušíte, proč tomu tak je. Je to dáno tím, že čím větší firma je, tím větší nese odpovědnost za dodání kvalitního produktu, odpovídá většímu počtu zákazníků, usiluje o dosažení přiměřeného zisku, a v neposlední řadě i zajištění práce pro své zaměstnance.
Společnost, která již má nějaké jméno a obrovské množství zaměstnanců a zákazníků si však nemůže na rozdíl od startupu dovolit vypustit na trh produkt, který by obsahoval nějaké banální chyby a ještě po svých zákaznících chtít, aby jej v podstatě zadarmo testovali. Neříkám, že to nejde, ale znamená to mít neskutečně nadšené a loajální zákazníky, kteří budou ochotni stát i několik hodin ve frontě, aby si mohli domů odnést váš nový produkt. (Schválně, kolik takových firem znáte?)
Těm ostatním, kterých si troufám tvrdit, že je většina, by to u jejich zákazníků nejspíš neprošlo, protože její zákazníci od ní očekávají špičkovou kvalitu a i drobné chyby, které nemusí mít vůbec žádný dopad na funkčnost, si zde může povšimnout obrovské množství zákazníků a vyvodit z toho i zcela nesmyslné závěry, které mohou vést i ke ztrátě důvěry a rapidnímu poklesu zisku nebo hodnoty akcií.
Nehledě na to, že by oné chyby mohl i někdo zneužít, daný systém hacknout a zkopírovat třeba všechna data a asi uznáte, že je rozdíl, jestli je v databázi pár záznamů rodinných příslušníků zakladatelů startupu anebo několika desítek tisíc platících klientů.
Z tohoto důvodu se jeví jako vhodnější a bezpečnější nové verze ihned neuvolňovat. Anebo je uvolňovat třeba jen pro zaměstnance dané společnosti. Tím ale tak trochu padá jedna z hlavních myšlenek agilního přístupu. Tedy přímá komunikace mezi vývojovým týmem a zákazníky a zjišťování jejich skutečných potřeb, což zde často neprobíhá.
Kromě toho pokud požadavky na produkt definují výhradně jen vlastní zaměstnanci a zároveň tito zaměstnanci vystupují i v roli testerů, tak nejenže nepředstavují dostatečně reprezentativní vzorek, na který by organizace ráda cílila, ale mohou jim i uniknout podstatné skutečnosti.
Proč tomu tak je? Nabízí se dvě odpovědi, do hry vstupuje mezičlánek v podobě útvaru marketingu nebo komunikace a dále pak zde panuje jistá obava z konkurence. Ta by totiž mohla s daným produktem přijít na trhu dříve. A tak na rozdíl od agilních týmů ve startupech, které komunikují velice nahlas a intenzivně, je zde mnohdy patrná snaha informace o vývoji nového produktu tajit. Což logicky brání zjišťování skutečných potřeb od zákazníků.
Další celkem zásadní problém je pak ten, že v konzervativních společnostech zpravidla převažuje tradiční byrokratický způsob řízení a hierarchická organizační struktura. Málokde najdeme samořídicí týmy a pokud ano, tak tyto týmy fungují ve značně omezeném módu, tj. mají omezené pravomoci. Právě z výše uvedeného důvodu spočívajícím v obavě z možné chyby.
Další rozdíl pak spočívá v tom, že ve startupu se sdružují lidé, kteří daný produkt zpravidla sami chtějí anebo jsou přesvědčeni o jeho úspěchu. V korporaci pak jsou členy týmu ti, kteří do něj byly najmenováni a vyvíjet jej musí. Rozdíl v přístupu člověka, který něco dělá jen proto, že musí a člověkem, který to dělá proto, že sám chce, je obrovský. Ideální je, když má zaměstnanec možnost se rozhodnout, zda se chce do vývoje daného produktu zapojit nebo ne. A jsme opět u nedostatečné motivace, a s tím souvisejícím minimálním podílu na rozhodování a rovněž i podílu na zisku.
Opomenout také nemůžeme skutečnost, že konzervativní společnosti mají nízký rizikový apetit, což je opět něco, s čím zpravidla rovněž nic neuděláme, protože to souvisí s výše uvedenou vysokou odpovědností, kterou startup prostě nemá. Projevuje se to i na obyčejném A/B testování a použití i dalších technik jako je canary releasing, feature toggling, kdy je nejspíš paralyzuje pocit, že by třeba určité skupině klientů zobrazili něco jiného a někdo by se pak třeba mohl cítit znevýhodněn.
K článku “Proč agilní vývoj leckde selhává” se zde nenachází žádný komentář - buďte první.
Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.
