28.05.2013

Problémy s adopcí agilních přístupů – část 2

Tak máme zavedený Scrum… ale ono to pořád moc nefunguje. Měli jsme školení, máme postup, ale lidé hrají mrtvé brouky, já jako Scrum Master je musím kopat do zadku, v každé iteraci přesouváme nedokončené úkoly do další, neřešíme architekturu a technický dluh se hromadí. Nevíme, jak efektivně přejít z vágních user story ke kódu, nedoručujeme spustitelné celky, kódujeme po technologických vrstvách, ne podle scénářů apod. Znáte takovou situaci? Připomíná vám to něco? Scrum nám „nějak“ funguje, ale pořád se nedaří…

V jednom z prvních blogů jsem popsal typické nepravdy a nepochopení ohledně agilních přístupů.  V tomto se zaměřím na konkrétnější praktické a detailní problémy, se kterýma se setkávám u týmů zavádějících agilní přístupy. Jaké jsou či mohou být příčiny v úvodu zmíněných problémů? Typické příčiny bývají podle mé zkušenosti následující:

  1. Nevíme, proč implementujeme Agile a navíc ho tlačíme shora (nebo zdola).
  2. Chybějící nám akceptační kritéria a definition of done (DoD) – nevíme, co všechno máme dělat.
  3. Neřešíme architekturu ani možná rizika a tak se nám hromadí technický dluh a překvapuje/brzdí nás každá integrace.

Pojďme tedy jednotlivé oblasti prozkoumat detailně.

Proč a jak Agile? Zahrňte tým do procesu zavádění změny!

Veškeré snahy o Agile by měly začít otázkou PROČ? Proč vlastně chceme něco měnit? Není současný model/metoda dost efektivní? To co fungovalo s pár lidmi už nefunguje ve větším týmu? Nedaří se nám soustavně doručovat hodnotu a vydělávat na ní? Tak by měly znít úvodní otázky. Možná jste malý tým a vyhovuje vám současný ad hoc nebo vodopádový přístup, při kterém jste nejefektivnější. Sice třeba jen vy víte co je třeba udělat pro spuštění verze, ale prostě to funguje a všem to stačí. Pak není co měnit. Může to znít divně a nemoderně (dnes přece všichni musí být Agile ;)), ale je to tak. Agile by vás mohl připravit o efektivitu a hodiny nutné pro synchronizaci, plánování, demo, retrospektivu.

Moje zkušenost z workshopů a koučování je taková, že většina firem hledá efektivní metodu, která jim umožní rychle ověřovat a zkoumat jestli jsme pochopili zadání a jestli a jak navržená architektura vyhovuje. Právě k tomu je ideální iterativně inkrementální (agilní) přístup s častými demonstracemi nějakého výsledku, kdy si můžeme ověřit jak pochopení byznys stránky požadavku, tak to, že nám to funguje (architektura).

Druhým problémovým aspektem zavádění Agile je „o nás bez nás“. Na což jsme obzvlášť my Češi háklivý. Někdo se rozhodl (vedení, nadřízený týmu), že začneme s Agile, přijde a řekne nám, že máme dělat naši práci jinak. Připraví nový postup a představí nám jej, pošle nás na školení nebo pozve trenéra a už to jede… Takový „příkaz shora“ je silně spojený s výše zmíněným – nechápeme, nevíme proč něco měnit. No a jelikož to nechápeme a navíc jsme se návrhem nepřišli my jako tým (nikdo se nás neptal, jak a co bychom chtěli změnit), tak to dělat nebudeme, hrajeme výše zmíněné mrtvé brouky, aktivně podrýváme autoritu vedoucího či Scrum Mastera a říkáme, tak mi tedy řekni, co mám dělat a jak apod. Je to pochopitelné, protože my víme nejlépe, jak danou práci dělat a kde máme problémy a jak by šla zlepšit, protože my tu práci reálně děláme!!! Na rozdíl od těch, co pro nás tuto změnu nachystali a neptali se. V anglofonních zemích se tomuto chování říká „not invented here syndrome“.

Pokud si na to, že potřebujeme něco zlepšit nepřijdeme sami, pokud nejsme zahrnuti do procesu plánování této změny (jak to tedy dělat jinak), tak tíhneme po úvodních snahách ostatních k našemu původnímu postupu a zvyku. Toto chování je naprosto lidské a lze je překonat a vyhnout se mu pouze, pokud známe smysl proč něco měníme a také zahrneme nás jako tým do procesu změny.

1/ Ptát se a sdílet, proč něco chceme měnit a zda vůbec.

2/ Změnu provádět s týmem, s lidmi, kteří vykonávají danou práci.

Jak tedy začít?

Prvním krokem by měla být diskuse o tom, co je hodnota, kterou doručujeme a jestli je se současným stavem spokojen zákazník, my i náš vlastník. Pár otázek, které se můžete ptát:

  • Stíháme dodávat nové věci, které jsme slíbili?
  • Nemáme moc chyb?
  • Vyděláváme?
  • Neděláme 10 a víc hodin denně?
  • Máme potřebné znalosti, dovednosti, technologie?
  • Mají naše služby přidanou hodnotu a plníme jimi cíl a smysl firmy?

Pokud jsou odpovědi na takové otázky kladné, pak není třeba nic měnit! Pokud jsou některé negativní, tak začínáte tušit proč je třeba něco změnit a analýzou příčin můžete dojít k tomu, co je třeba změnit, jelikož tato částečná a viditelná nespokojenost je jen symptomem. Jak na to, jsem popsal v předpokladech úspěšné implementace Agilního (resp. jakéhokoliv) přístupu už dříve.

Inspirovat se můžete také mým bývalým finským kolegou, jehož zajímavé cvičení jak začít v týmu s Agile jsem popsal už dříve.

Shrňme si tedy ještě první krok. Důležité je vědět co a proč chci změnit a zjistit příčiny problémů, abych jen nereagoval na symptomy, ale zároveň řešil i příčiny daných problémů. Když víte proč a co, můžete pokračovat dále s celým týmem nebo jeho zástupci s návrhem změny, tedy jak to změnit.

Nepospíchejte, šanci máte jen jednu, pak už lidi nebudou mít k novému přístupu a k jakékoliv jiné změně důvěru.

V dalším díle se budeme věnovat akceptačním kritériím, rizikům, architektuře a technickému dluhu.

Máte k tomu co říct?

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *