Znásilněný scrum

Zamyšlení nad významem nálepky Agilní a zaváděním Agile do firem

Příchod agilního vývoje software (rok 2001) mi vždycky přišel jako takové osvícenecké období v IT světě. Vývojáři v té době zjistili, že jsou lapeni v kleci rigidních pravidel definovaných systémem, který se stále více podobal továrnám Henryho Forda. Nejen, že to pro ně nebyla příjemná pozice, ale celé to bylo i velmi neužitečné a neefektivní. Agilní manifest jasně definoval změnu a přinesl svěží vítr do vývojových kanceláří. Je tomu ale stále tak nebo se nám to nějak zvrtlo?

henryford_gallery_05

Svěží vítr

Občas s někým mluvím o agilním vývoji a v duchu přemýšlím nad tím, jestli ten člověk vůbec kdy slyšel o agilním manifestu a jeho 12 základních principech. Nechci, aby to vyznělo jako kritika, dost lidí se k agilnímu vývoji dostala tak, že jednoho dne prostě začali pracovat ve firmě, co dělá „scrum“ a tím se pro ně význam slova agilní zdeformoval.

Nejkrásnější věcí na příchodu agilního pojetí vývoje byla potřeba změny, potřeba zboření zkostnatělých zažitých systémů, potřeba zlepšení komunikace, vzájemného porozumění a kvality práce a to vše za účelem vytváření a doručování užitečnějších produktů. Pokud máte pocit, že přestože pracujete v agilní firmě, vaše pracovní prostředí podobné hodnoty nectí, tak vězte, že jste ustrnuli v nějakém polotovaru, který využívá spíše jen konkrétních agilních praktit. Občas velmi účelově.

Management, který nebyl

Pokud budete chtít stavět výletní lodě, které vozí pasažéry, budete muset projít dost specializovaným vzdělávacím procesem. To je nám všem jasné. V oblasti vývoje software ale podle mě vznikla určitá bludná představa, že vývoj může řídit tak trochu kdokoliv. Senior vývojáři, co mají pocit, že je potřeba se někam posunout, ekonomové, co si udělali vlastní webové stránky, ufóni, co dříve prodávali skútry. Myslíte, že přeháním? Všechny tři příklady jsou reálné.

Proč existuje pocit, že řídit vývoj může kdokoliv, můžu pouze odhadovat. Důvodem, může být například fakt, že většina špatných rozhodnutí v software oblasti nikoho nezabije, nikdo chybná rozhodnutí neodlévá ve slévárně nebo se je nepokouší dát dohromady, když si je koupí v krabici v obchodě. Chyby tak trochu zůstavají doma a vždycky se to dá nějak ututlat.

Jenže ono to je přesně naopak. Vývoj software probíhá v neuvěřitelně dynamickém a kompetitivním prostředí. Pravidla komunikační teorie se dají aplikovat téměr na všechno: komunikace se zákazníkem, pochopení očekávání, vytváření společného pochopení požadovaných cílů, transformování úkolů definovaných v přirozeném jazyce do umělého jazyka počítačů. Jsou zde nároky na perfektní orientaci v technologiích, řízení lidí, udržování kvality…

sprint-burndown

ukázka detailního burndown diagramu

Nezkušený manažer se topí, projekty hoří, lidé si stěžují. Sáhnutí po agilních nástojích je na snadě – jsou módní a je k nim všude spousta informací. Prvoplánové nasazení dokáže situaci ve společnosti ještě víc zhoršit. Už jste například slyšeli o vytočených support lidech, kteří najednou vůbec nesmí mluvit s vývojáři a věčně jen čekají na konec nějakého sprintu? Jsou i firmy, kde je slovo agilní seznamu zakázaných slov.

Nepíši to proto, abych vás demotivoval. Sám jsem původní profesí databázový administrátor. Jen vás chci varovat, že je potřeba jít trochu dál, než udělat každé ráno standup. Chtěl bych vás motivovat k tomu, abyste se pídili po principech, experimentovali s nimy, reflektovali, jak se vám to daří a vzdělávali se.

Scrum – mikromanagement v akci

Pokud by mě někdo požádal, abych pomocí týmu polo-inteligentních robotů doručil jednorázově software projekt a zároveň jsem byl tak trochu control-freak, jednoznačně bych sáhnul po scrumu.

Slovo scrum není ekvivalent slova agilní a naopak. Scrum už není princip nebo filozofie, scrum je metodika. Soubor nástrojů, které vám pomohou agilními být.

Znám jen málo jiných metodik, které by manažerovi umožnili tak detailně sledovat průběh práce na projektu a to až na úroveň jednotlivých zaměstnanců a dílčích prací. Jednotkami času jsou hodiny nebo dokonce minuty. O tom si lidé z jiných oborů mohou nechat jen zdát. Nejen, že máte možnost sledovat čas strávený na práci, dostáváte navíc edukované odhady času zbývajícího, vynášíte je do grafu, masírujete lidi v týmu, aby křivka na burndownu měla správný sestupný tvar. Tahle dáte několik sprintů, doručíte projekt (možná ne) a vyhořelé poškozené polo-inteligentní roboty vyhodíte. Vím, přeháním jako vždy…

Jde to takto dělat, ale nebylo to tak myšleno. Scrum měl týmu vývojářů poskytnout bezpečné prostředí na práci, vynutit alespoň určitou míru komunikace mezi lidmi, zavést průběžnou sebereflexi a to jak produktu, tak i způsobu jakým produkt vytváříme. Sprinty mají sloužit k rozdělení práce na menší, dokončitelné a doručitělné celky. Vytvořit přirozený rytmus pracování, předávání zákazníkovi, přemýšlení o procesu. Burndown diagramy nemají být bič, ale zdroj informací z nichž se tým může a chce poučit. Mohou být detailní, ale informace, které z nich zjistíme, jsou informace pro tým a ne pro HR oddělení. Backlog, user stories, task cards, acceptance testy, story-pointování jsou praktickými nástroji, které mají podpořit komunikaci a porozumnění mezi všemi zůčastněnými – business i software lidmi.

Měření efektivity

Nedávno jsem jsem dostal otázku „Jak byste měřil efektivitu výkonu softwarového týmu?“ Kdybych seděl na židli v kanceláři velké korporace, měl bych pro to určité pochopení. A upřímně si myslím, že ve velké firmě to potřeba je. Seděl jsem ale v malé startup firmě. Odpověděl jsem otázkou: „Proč potřebujete měřit efektivitu vývojového týmu?“ Tím jsem asi prohrál svůj svůj pracovní pohovor, ale otevřelo to zajímavé téma. Ve firmě byla obvyklá nepřátelská atmosféra mezi business a software lidmi. Obchodníci opravdu něměli rádi skutečnost, že nemohou komunikovat přímo s vývojáři – z minulosti na to byli zvyklí. Také si mysleli, že vývojáři toho vlastně moc nedělají a tak management intenzivně řešil otázku, jak měřit výkon vývojářů. Skutečný problém byl ale někde jinde.

Startup a malé firmy by neměli pálit čas a peníze na nesmyslných reportech interní efektivity. Speciálně pokud příjdou příkazem shora. Výkon vývojářů a dobře odvedená práce obchodních lidí musí přímo ovlivňovat KPI (key preformace indicator) celého produktu. A vše by se mělo odrážet od trendu těchto ukazatelů. To samé je aplikovatelné i na velké společnosti. Problém ale je, že velké a složité systémy potřebují větší počet kontrolních mechanismů a setrvačnost KPI mužů být velká (více ve článku Frustartion board).

Co se týče efektivity v týmu, agilní prostředí spoléhá na upřímnost, otevřenost, čitelnost celého procesu a kompetentnost lidí. Pokud děláte kolečka a retrospektivy a jste upřímní, všechny nešvary postupně vyjdou na povrch a někdo je bude  řešit. Způsob práce týmu se tak bude zlepšovat. Pokud vývojový tým pracuje optimálně nebo se dokonce zlepšujě a není to znát na KPIs, něco je špatně na straně produktu. Nejlepší, co můžete udělat, je tyto problémy otevřeně prodiskutovat napříč firmou a se zákazníky. Možná se budete divit kolik vstupu dostanete od lídí, od kterých byste to nečekali.

Přecházení na agile

Téma na celou knihu, ale nemůžu si odpustit pár poznámek.

Vyhněte se extrémům

Firma Shooting star s.r.o byla maličká, všechno bylo možné, všichni byli kamarádi, všichni spolu mluvili, kdykoliv to bylo potřeba. Není na tom nic špatného, vlastně je to asi to nejlepší, co může být. Když je malý tým složen z kompetentních lidí a cíl jejich spolupráce je všem jasný, téměř odpadá potřeba jakékoliv metodiky. Takový tým bude samo-řídící bez potřeby nějakého extra řídícího mechanismu.

Firma začne být úspěšnou, tím pádem začne růst a přijde okamžik, kdy musí poupravit původní modus operandi. Neznamená to ale, že:

  • začnete používat pravidla, která dávají smysl jen ve velkých  společnostech (několika-úrovňová hierarchie, byrokracie, buzerace). Nebude vám to pravděpodobně fungovat a budete plýtvat časem.
  • začnete striktně používat najednou všechno, co vám diktuje nějaká – byť agilní metodika. Pravděpodobně to nezvládne te.
  • začnete utrácet peníze za nástroje a konzultanty, kteří vás mají spasit. Možnost změny je ale primárně ve vás.

Jeden příklad běžného extrému. Ve firmě Shooting star mohl kdokoliv s kýmkoliv kdykoliv o čemkoliv mluvit. Pak přišel scrum a od toho dne jsou vývojáři nedostupní. Pomohlo vám to? Jste si jistí, že jste ve firmě vytvořili jiný, dostatečně dobrý, komunikační kanál?

Scrum vzniknul v nějakém kontextu

Kdysi jsem se setkal s Marry Poppendieck  a výjádřil jí svou pochybnost nad smyslem zákazu mluvení pro některé lidi během standup kolečka. Odpověd byla prostá: „když on tam tenkrát Ken měl fakt hrozný lidi„. Ken Schwaber je spoluautor scrumu. Mějte to na paměti a vězte, že slovo agilní opravdu není jen scrum a kanban. A všechno má svůj význam a důvod a vždy nějakém kontextu. Co firma to kontext.

Iterujte i přechod na agile

Pokud nemáte s agilním vývojem žádné předchozí zkušenosti, doporučuji vám zavádět jednotlivé agilní rituály a techniky postupně. Ideálně jednu po druhé. Jedna z prvních by měla být retrospektiva. Ta vám vytvoří bezpečnou zpětnou vazbu na další kroky. Článek Frustration board a retrospektiva popisuje jeden z mnoha možných způsobů.

Některé techniky se uchytí snadno, jiné jdou ztuha a dřou, nebo máte pocit, že do vašeho prostředí nepasují. V takovém případě netlačte na pilu, dejte lidem možnost to prodiskutovat na retrospektivě. Když ani to nepomůže, klidně se techniky dočasně vzdejte. Pravděpodobnost, že se to podaří později, až uzraje čas, je velká. Nebo existuje jiný způsob, jak danou potřebu vyřešit a bude ve vašem kontextu lepší.

Příklad: mockrát jsem se pokoušel v jednom týmu prosadit psaní acceptance testů k user stories v gherkinu a cucumber testy pak pouštět automaticky. A mockrát mě s tím vývojáři vyhnali a pokládali to za nesmysl. Nakonec s tím přišli sami a dnes je to standard jejich práce. User story bez gherkina je tam nemyslitelná.

Agile nejsou kavárny, kulečníky a výlety na měsíc

Je skvělé, když firma svým zaměstnancům vytváří dobré pracovní prostředí. Líbí se mi myšlenky svobodných firem. Ale pozor na jeden nešvar. Pokud při zavádení agilního přístupu nebo i svobodné firmy věnujete většinu času vymýšlení kavárny, umístění kulečníkového stolu nebo sauny v kanceláři, něco není v pořádku. Stejně tak to platí i opačně, pokud vás firma ždíme pomocí scrumu a zároveň vám poskytuje tyhle úžasné nadstandardní bonusy, asi vás jen uplácí.  Koneckonců, spousta ne-agilních firem vám také dá stravenky a příspěvek na dovolenou.

Agilní manifest nabádá k tomu, aby lidé byli respektování a pracovali v dobrém prostředí. To se dá ale vykládat různým způsobem.

Přirozený showmanship

Poslední střípek. Je dobré, když změnu do firmy přináší člověk, který dokáže ostatní zaujmout. Člověk, který dokáže věci prodat tak, aby je ostatní koupili. Člověk, který vám dá jasný signál, že všichni jsou aktéry toho, jak to bude a který jde příkladem. Svojí Certified Scrum Master certifikaci jsem dělal pod vedením Nigela Bakera. Byl to on, kdo způsobil mé agilní nadšení a udělal to tím, jak to všechno prezentoval.

Agilní – co to tedy vlastně je?

Metodika, metodologie, filozofie? Metodika je soubor metod, praktik a pravidel jejich aplikace. To znamená, že je to soubor nástrojů, který redukuje vaše možnosti na postup, jak dosáhnout určitého výsledku. Možná si to nalhávám, ale agilní manifest na mě působí přesně opačným dojmem, snaží se redukci odstranit. Bohužel většina firem přecházejících na agilní vývoj ustrne pouze v metodice.

Jestliže agilní manifest znáte nebo jste si jej právě přečetli, víte že tam žádná metodika není. Jsou tam sepsány principy a vy si nimi můžete naložit po svém. Na základě těchto principů vznikly určité praktiky, nástroje a rituály jako jsou standup meetings, user stories, retrospektivy, refaktoring, timeboxing, párové programování, TDD, BDD a mnoho dalších. Metodiky jako je scrum, kanban, XP, Crystal, scrumban jsou soubory těchto praktik a nástrojů vytvořených pro dosažení nějakého cíle. Nic vám ale nebrání vytvářet si vlastní nástroje a vlastní metodiky – pokud budete ctít agilní principy, budete i agilní.


 

Agilní manifest a 12 základních principů

Pro úplnost zde uvedu text agilního manifestu. Online ho naleznete na http://www.agilemanifesto.org.

Je to jednoduché, krásné a přemýšlením významem každého slova může člověk tento text použít jako nevyčerpatelný zdroj inspirace.

Agilní Manifest

Objevujeme lepší způsoby vývoje software tím,
že jej tvoříme a pomáháme při jeho tvorbě ostatním.
Při této práci jsme dospěli k těmto hodnotám:

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

Jakkoliv jsou body napravo hodnotné,
bodů nalevo si ceníme více.

 

Principy stojící za Agilním Manifestem

Řídíme se těmito principy:

Naší nejvyšší prioritou je vyhovět zákazníkovi časným
a průběžným dodáváním hodnotného softwaru.

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.

Dodáváme fungující software v intervalech týdnů až měsíců,
s preferencí kratší periody.

Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu.

Budujeme projekty kolem motivovaných jednotlivců.
Vytváříme jim prostředí, podporujeme jejich potřeby
a důvěřujeme, že odvedou dobrou práci.

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.

Hlavním měřítkem pokroku je fungující software.

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.

Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu.

Jednoduchost–umění maximalizovat množství nevykonané práce–je klíčová.

Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů.

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.

 

Reklamy

Zanechat Odpověď

Vyplňte detaily níže nebo klikněte na ikonu pro přihlášení:

WordPress.com Logo

Komentujete pomocí vašeho WordPress.com účtu. Odhlásit / Změnit )

Twitter picture

Komentujete pomocí vašeho Twitter účtu. Odhlásit / Změnit )

Facebook photo

Komentujete pomocí vašeho Facebook účtu. Odhlásit / Změnit )

Google+ photo

Komentujete pomocí vašeho Google+ účtu. Odhlásit / Změnit )

Připojování k %s

%d bloggers like this: