čtvrtek 12. března 2015

7 příznaků, že děláte Agile blbě

Zavedli jste v podniku agilní metodiku, ale nějak to skřípe? Ujistěte se, že neděláte jednu z následujících chyb!

Děláte detailní zadání projektu

Analytik rozkreslí před začátkem projektu uživatelské rozhraní do posledního tlačítka a programátor si s tím pak musí poradit?
Fajn. Ale Agile je o tom, že dovolíte lidem hýbat rozsahem projektu. Pokud produkťák nemá možnost měnit priority, nedivte se, že nestíháte termíny.

Scrum master je nejlepší vývojář/analytik z týmu

Gratuluji. Právě jste zabili dvě mouchy jednou ranou: dali týmu neschopného vedoucího a snížili jeho výkon o 50%.
Nechte vývojáře a analytiky dělat svojí práci a nenuťte je kreslit burndown chart a vyplňovat tabulky. Buď to budou flákat a celý tým bude trpět, nebo se stanou brzdou, na kterou budou všichni čekat.

Scrum master je bývalý projekťák

Tím pádem vše funguje jako předtím, jen se změnila vizitka, že? PM rozdá práci, dohlíží na její splnění…
Správný Scrum master musí tým naučit pracovat samostatně, omezit svoje řídící návyky a zkusit postupně přenést zodpovědnost na celý tým.
Ale dobře … projekťák může být dobrý Scrum master – rozhodně je to lepší volba než vývojář. Musí však pochopit, že teď se nejen hraje jiná hra – teď se hraje na úplně jiném hřišti.

Nenecháte si poradit

Váš šéf si poslechl jednu prezentaci, přečetl Agile Manifesto a jdete do toho?
Tak určitě! Proč se zdržovat školením Scrum masterů nebo se nedejbože zajímat o zkušenosti jinde? U vás to klapne hned napoprvé. Jste šikulové!

Nedodáváte průběžně

„U nás v podniku není možné udržovat vývojové prostředí, kam se bude průběžně nasazovat.“
Pak se na celou agilitu vybodněte. Základní poučka říká, že feature je hotová ve chvíli, kdy jí mohu předvést. Pokud váš tým dodává pouze kompletní věci, staví jednu velkou Potěmkinovu vesnici.
Vývojové CI (continuous integration) udělat prostě musíte! Kupte server z vlastních peněz a šoupněte ho pod stůl, pronajměte si virtuál, vytvořte testovací data ručně, ...
Zásada č. 1: musí vám běžet prostředí, na kterém se každý den (max. týden) dá „proklikat“ nová verze.

Nedodržujete pravidla

„Ty hele, Jirko, ten Scrum mi přijde zajímavý – ale to každodenní scházení se mi zdá jako blbost. To zrušíme.“
Netvrdím, že pravidla je nutné dodržovat na 100%. Ale je dobré si vše nejdřív vyzkoušet podle pravidel a pak se bavit o změně. Uvidíte, že za pár měsíců nebudete chtít měnit skoro nic.
My třeba už dávno u standupů sedíme. Proč? Protože už jsme si zvykli mluvit stručně a jasně. Když se standup začne protahovat? Tak si stoupneme a je to hned.

Neděláte retrospektivy

Tady by stačilo odkázat na předchozí odstavec. Ale opakování je matka moudrosti. Retrospektiva je důležitá zejména pro duševní hygienu týmu. Všichni mají možnost upustit páru a vyříkat si věci mezi sebou, ale hlavně dostanou možnost (minimálně pocit), že opravdu něco změní – i kdyby to měla být jen otevírací doba bufetu.
Scum master by měl po retrospektivě alespoň část připomínek hned vyřešit! Jinak je to házení perel – hrachu na zeď ;)
Poznali jste se v některém z bodů? Gratuluji, ale nikdy není pozdě začít dělat věci správně!

1 komentář:

  1. Ahoj M&Ms & team :-) máte tu moc moc fajn věci a tohle je taky zajímavé; tuhle provokačku možná znáte taky a jestli ne, tak to berte jako od něco od virtual 10th mena :-))
    https://vimeo.com/110554082
    ... a link na Dave Thomase je taky cool; happy coding! :-)

    OdpovědětVymazat