sobota 21. září 2013

Agilním vývoj není Scrum nebo Kanban


Když jsem byl malej smrad, na Štědrý den mi rodiče kladli na srdce, abych se postil - rozuměj nejedl maso až do štědrovečerní večeře - jinak neuvidím zlaté prasátko. To jsem samozřejmě poctivě dělal až do dovršení věku deseti let. Pak mi došlo, nejenom že žádné prasátko neuvidím, natož zlaté, ale že vlastně ani nevím co si pod tím mám představit. S pojmem Agilní vývoj případně Agile to má většina vývojářů a manažerů podobně. V tom lepším případě si představí Kanban nebo Scrum, případně nějakou konkrétní techniku - párové programování, standup meetings. V tom horším vůbec nic případně to zaškatulkuje pod klíčové slovo bullshit. Většinou je spojuje, že teoreticky zažili všechno, prakticky nic, a od určité doby přestali věřit podobně jako já na to zlaté prasátko. Cynik by mohl dodat, že obojí je to pěkná pohádka.

V tomhle článku se pokusím rozmetat představu, že praktikování Scrumu nebo Kanbanu vede k agilnímu vývoji. Je to asi stejná mentální zkratka, jako od sexu k početí potomka. Můžete mít orální sex, ale jenom těžko můžete očekávat, že z toho někdo otěhotní. Úplně stejně to funguje s agilním vývojem. Praktikujete Kanban a místo agilního vývoje máte produkt doručovaný jednou za půl roku s nulovou přidanou hodnotou zákazníkovi. Zatímco ten orální sex si někdo užije, po zpackaném agilním vývoji zůstane pouze frustrovaný zákazník a zpruzení vývojáři. Když dva dělají totéž nebývá to obvykle totéž.

Položme si jednoduchou otázku. Existoval agilní vývoj, před tím než byly představené metodologie jako Kanban? Samozřejmě, že existoval, jenom se tomu tak neříkalo. Mimochodem techniky, které se postupem času zpopularizovaly, jako například Párové programování nebo Test Driven Development existovaly pravděpodobně ještě před tím, než někoho napadlo přemýšlet o tom, že z nich udělá sadu pravidel. Pokud tedy agilní vývoj existoval před tím, než se ho snažil někdo sešněrovat do řekněme Scrumu, pak ovšem platí, že můžete dělat agilní vývoj, bez toho aniž byste se snažili slepě aplikovat řekněme opět Scrumu. Abych nebyl chycen za slovo, samozřejmě že Scrum nebo Kanban jsou velmi pružné a navržené, aby je bylo možné upravit podle kontextu použití, jak vám jistě řekne nejeden agile expert. Ještě jednou, není důležité jak tomu říkáte, ale jak to funguje.

Vezměte si prosím tužku a papír případně si jinak zaznamenejte, to co si představujete pod agilním vývojem.

Máte je? Výborně! Za chvilku se nám budou hodit.

Další část našeho cvičení pokračuje, kterou z možností (levou nebo pravou) v níže uvedených větách intuitivně preferujete.

  • Jednotlivci a interakce před procesy a nástroji
  • Fungující software před vyčerpávající dokumentací
  • Spolupráce se zákazníkem před vyjednáváním o smlouvě
  • Reagování na změny před dodržováním plánu

Pokud preferujete možnosti nalevo od slova před, pak máte správné mentální nastavení pro odbourání jakýchkoliv stereotypů o agilním vývoji. Pokud preferujete možnost napravo od slova před, pak v uvozovkách stále věříte na zlaté prasátko. V každém případě předchozí věty jsem si nevycucal z prstu, ale pocházejí z Agile manifesto tj. dokumentu absolutně zásadního k pochopení agilního vývoje. V tom samém dokumentu najdete 12 jednoduchých pravidel, kterými je definován agilní vývoj.

  1. Naší nejvyšší prioritou je vyhovět zákazníkovi časným a průběžným dodáváním hodnotného softwaru.
  2. Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje. Agilní procesy podporují změny vedoucí ke zvýšení konkurenceschopnosti zákazníka.
  3. Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody.
  4. Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu.
  5. Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme, že odvedou dobrou práci.
  6. Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace.
  7. Hlavním měřítkem pokroku je fungující software.
  8. Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo trvale.
  9. Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu.
  10. Jednoduchost--umění maximalizovat množství nevykonané práce--je klíčová.
  11. Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů.
  12. Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti.

Kolik z toho, co jste si představovali pod agilním vývojem, viz papír a tužka, vám sedí proti těmto pravidlům. Těchto 12 pravidel nic neříká o Scrumu, nic neříká o tom, že musíte dělat každý den standup meeting a dokonce to ani nic neříká o tom, jak ta pravidla realizovat. Ještě zajímavější srovnání se nabízí, pokud se snažíte používat Scrum nebo Kanban. Pokud ano, zkuste si položit otázku, jestli podle těch pravidel skutečně fungujete.

V GoodData jsme se pokoušeli dělat agilní vývoj několik let. Bohužel jsme na to šli přes Scrum a později přes Kanban a většinou selhali. Ten důvod nebyla ani jedna z těchto metodologie, ale to že jsme si nikdy neřekli, že to podle čeho chceme skutečně fungovat je těchto 12 pravidel - cíl. Scrum nebo Kanban může (a nemusí) být prostředek - cesta, jak se k němu dostat. Teprve potom, co se snažíme zaměřit na tyto pravidla, začíná agilní vývoj skutečně fungovat. Nedělejte proto stejnou chybu a místo na konkrétní metodologii si zaměřte na to, aby jste se snažili vždy fungovat podle těchto jednoduchých pravidel. Výsledkem bude skutečný agilní vývoj nikoliv jeho předstírání a lhaní si do kapsy.

neděle 15. září 2013

Nenajímejte jednotlivce, budujte tým - proč se nevyplatí klonovat Jaromíra Jágra

Jednou jsem byl na motivační prezentaci o budování úspěšné firmy. Hlavní poselství, alespoň po té době mi to přijde, spočívalo v důrazu na najímání takzvaných A-players - američané občas používají označení Rock Stars. Nikdo asi nemůže rozporovat fakt, že pokud má být firma úspěšná, musí v ní pracovat šikovní a schopní lidé. Na druhou stranu to vůbec nic neříká o tom, že byste potřebovali jenom A-players. V ideálním světě by opravdu k vytvoření skvělé firmy stačilo najmout jenom ty nejlepší (A-players). Drobná potíž je v tom, že mi nežijeme v ideálním světě, ba co hůře najímání A-players dláždí cestu do pekla. V tomto článku zkusím pomocí paralel ze světa sportu vysvětlit proč.

Tým je víc než jednotlivec

Z krátké historie sportu si vybavím jenom jeden tým sestavený z A-players, americký basketbalový Dream team na olympijských hrách v Barceloně, který měl úspěch. Za to si vybavím spoustu nepovedených pokusů sestavit úspěšný tým jenom z A-players - namátkou Real Madrid v éře El Galacticos. Předchozí věta obsahuje, ačkoliv to není na první pohled patrné, nejdůležitější slovo - tým. Když se ještě chvilku podržíme sportovní analogie, v týmovém sportu je tým více než jednotlivec. Proto nejsou ve sportu, případně velmi zřídka, úspěšné týmy složené pouze z A-players - nejlepších jednotlivců - ale týmy a sportovní organizace, které dokáží nejlépe využít vlastností jednotlivých hráčů ve prospěch týmu. Pokud přijmete fakt, že firma je tým a softwarový vývoj je týmový sport, pak se dá najít celkem dost paralel.

Kultura je víc než jednotlivec

Většina úspěšných sportovních organizací má jasně nastavenou filozofii, podle které se řídí ekonomické i sportovní fungování. Vzniká něco co bychom označili za firemní kulturu. Firemní kultura nastavuje vnitřní prostředí, tak aby byla naplněná filozofie firmy a tím pádem i její cíle. Pokud máte skvělého hráče, který nezapadá do vaší firemní kultury, existují jenom dvě možnosti. Změníte firemní kulturu a nebo ten skvělý hráč není ten pravý.


Jágrův malíček aneb team's bus factor

Během hokejového Mistrovství světa ve Vídní 2005 se po jednom ze zápasů základní skupiny, ve kterém byl zraněn Jaromír Jágr - ofenzivní eso české sestavy -, řešily šance týmu na dobrý výsledek. Vyhlídky na úspěch nebo neúspěch se točily kolem stavu Jágrova zlomeného malíčku. Nakonec vše dopadlo dobře a český tým vedený právě Jágrem dosáhl na zlato. Už se nikdy nedozvíme, jak by český tým dopadl bez kladenského barda v sestavě, ale to neznamená, že bychom se z něj nemohli poučit. Faktor štěstí nebo smůly je důležitý v jakékoliv lidské činnosti, fatální je pokud se stane středobodem nebo naopak nejslabším místem vaší strategie. Každý sportovní tým spoléhající na jednotlivce hraje doslova ruskou ruletu. Jednotlivec, byť sebegeniálnější, by měl být v jakémkoliv týmovém uspořádání nahraditelný. V knize Team geek to autoři nazývali team's bus factor: kolik lidí musí ve vašem týmu přejet autobus, aby šel projekt do kopru. Pokud je váš team's bus factor=1 znamená to, že jednoho atd. Schválně si položte otázku jaký je váš team's bus factor...


Týmová hierarchie

Nahraditelnost jednotlivce ovšem neznamená, že budete tým budovat způsobem všichni jsou si rovni. Jenom absolutní sportovní analfabet by si mohl myslet, že Jaromíra Jágra nahradí hráč čtvrtého útoku Zetoru Brno. Vždycky v jakémkoliv týmovém sportu potřebujete takzvané rozdílové hráče (A-players?). Ti plní rolí lídrů a leží na nich hlavní odpovědnost. Na druhou stranu ani oni se neobejdou bez podpory týmu. Zkuste si představit, jak by vypadal tým, který by byl složený jenom z hráčů, jako je Jaromír Jágr. Ten tým by měl zcela určitě chatrnou defenzivu a s pravděpodobností hraničící s jistotou i mizernou ofenzivu. I božský Jaromír potřebuje, aby mu někdo na ten gól přihrál. Kromě praktických důvodů by se ten tým dříve nebo později rozhádal zevnitř, protože by v autobuse neměli dostatek místa na poskládání ega všech hráčů.

Každý tým musí mít jasně definovanou hierarchii a každý hráč musí přesně znát svojí roli. Nejpatrnější je to asi v NHL, kde pozici v hierarchii týmu odpovídá nejenom platové ohodnocení, ale i patřičný ice time (čas strávený na ledě). Platí v podstatě jednoduchá rovnice: hrál jsi dlouhodobě dobře, dostaneš dobrý kontrakt, máš dobrý kontrakt, dostaneš patřičný čas na ledě, abys mohl svoje kvality prokázat. Ovšem pozor, ani v NHL se nehraje za zásluhy, týmová hierarchie nebývá rigidní co se týká personálního obsazení. Stejně i pracovní týmy, a to i ty softwarové, by měly mít jasnou hierarchii. Každý by měl znát svojí pozici v hierarchii týmu a měl by možnost v rámci ní postoupit. Všichni by si zároveň měli uvědomit, že bez týmové spolupráce se neprosadí nejenom jednotlivec, ale ani tým.


Vychovat, nekupovat

Ve fotbale je výchova a prodej hráčů obchodním modelem mnoha klubů. Pokud se bavíme o těch nejlepších hráčích, A-playerech, pak je jejich nákup velmi drahým špásem. I ty největší a nejznámější fotbalové firmy, jako je Barcelona nebo Manchester United (pozor neplést s městským rivalem City), mají spočteno, že se jim vyplatí A-playery vychovat. Kromě finančního efektu mají vlastní odchovanci ještě jednu výhodu. V klubu jsou dlouhodobě a znají jeho filozofii a kulturu. Funguje to i opačně, klub si mnohdy vychovává hráče od žákovských let a dokonale zná jeho přednosti i nedostatky. S nákupem hráčů, stejně jako s příchodem lidí z venku, je vždy spojená určitá nejistota s tím jak zapadnou a jestli budou opravdovou posilou. Ve sportu a ve fotbale zvlášť nemáte žádnou zkušební lhůtu a pokud někoho uděláte za pořádný balík na pět let, tak mu prostě těch pět let platíte. Proto platí jednoduché pravidlo, že kupovaný hráč musí být výrazně lepší než odchovanec.

Není žádný důvod neaplikovat stejná pravidla pro rozšiřování firemního týmu. Podoba se přímo nabízí. Vychovat si někoho uvnitř je mnohem levnější než ho najmout zvenku a to ještě s rizikem, že nezapadne ani do firemní kultury a ani do týmové hierarchie.


Je nepopiratelné, že jednotlivec označovaný jako A-player hraje důležitou roli v jakémkoliv týmu - softwarovém i sportovním. Vlastní tým, jeho kultura a hierarchie je ovšem důležitější než jednotlivec. Proto se soustřeďte na najímání lidí, kteří budou zapadat do vašeho týmu a ne naopak. Jinými slovy nenajímejte jednotlivce, ale budujte tým.