Press "Enter" to skip to content

Demo třetího sprintu

Ve třetím sprintu jsme zase nic nedodali.

Ve sprintu byly čtyři user stories (a tentokrát opravdové user stories, žádné nesmysly typu „vyrobte wireframe“). Od všech jsme dodali analýzu, UI design (wireframe), ale nedodali jsme SW design a nakódované obrazovky. Tím pádem jsme nesplnili „definition of done“.

Lidi, kteří to měli na starost, mají samozřejmě dobré objektivní důvody, proč to nestihli dodělat – přednost dostala práce na jiných projektech, podklady pro svoji práci dostali pozdě atd., no však to znáte.

Pokusy zastoupit je nebo jim pomoci taky nezafungovaly – kodér nedá žádným amatérům přístup do GITu, SW designér zase neposkytne nekvalifikovaným lidem přístup do vývojářského modelu. Nehledě na to, že každý chce přednostně odbavit svoje úkoly, než začne někomu pomáhat nebo za něj zaskakovat.

Z toho je dobře vidět, proč SCRUM tak často selhává – některé prvky „agilního mindsetu“ jsou totiž v podstatě proti „zdravému rozumu“:

  • práce bez zadání: ještě nevím, co přesně budu dělat, ale už na tom musím pracovat, jinak bychom nestihli demo
  • izolace od vnějšího světa: když jsem ve SCRUM týmu, nesmím dát přednost jiné práci, i kdyby pro to byly přesvědčivé důvody
  • amatérská improvizace: pokud nějaký člen týmu nestíhá a já mám volno, musím mu pomoci, i když jeho práci moc dobře neumím
  • nedokonalý výsledek: často už během sprintu zjistím, že to, co děláme, není úplně dobře, ale musím to stejně dotáhnout a dodat.
  • neefektivita – mám-li všechno stihnout, nemůžu čekat, až mi kolegové dodají podklady. To samozřejmě vede k tomu, že pak musím část práce předělávat, což je neefektivní.

Tyhle věci vám ale na školení Scrumu neřeknou, ačkoli si myslím že by rozhodně měli. Tam se mluví furt o tom, jak je Scrum skvělý a po všech stránkách dokonalý.

Pokud se ale člověk s těmito problémy psychicky nesrovná, bude svůj tým brzdit. A pokud takových lidí bude v týmu většina, snadno sklouznou k nějakému prokrastinačnímu modelu typu „waterfall“ a přestanou dodávat. Nebo ani nezačnou, jako my teď.

Tři sprinty, to je 6 týdnů. Už šest týdnů jsme nedodali nic, co by stálo za řeč. Někteří kolegové říkají, že přeci pracujeme a postupně náš proces vylepšujeme, takže vlastně nevadí, že jsme úkoly nedokončili. Na mě to ale působí jako příšerné plýtvání a fakt, že se to učíme, nepovažuji za dostatečnou výmluvu.

——————————————–
UPDATE:
@Kojotak se ptá: “ Jak jste opakované nedodání řešili na retrospektivě? Pokud amatérská výpomoc nestačí, tak tým zřejmě není samostatný. “

To je velmi dobrá otázka, podíval jsem se tedy do historie retrospektiv a našel tam toto:

  • 1. sprint – „Problém s kapacitou některých členů týmu“, scrum master se pokusil vyjednat pro ně větší alokaci, ale neuspěl.
  • 2. sprint – mezi problémy se objevily položky „Chybí tah na branku, není tlak na dodání výstupu“, „Prokrastinace“ a „Kapacity členů týmu, omezené zapojení některých členů“. Úkol vyřešit to dostali ti členové týmu, kterých se problém týká, ale taky neuspěli.
  • 3. sprint – opět stížnost na alokaci a kapacity členů týmu, o řešení se opět pokusí scrum master. Objevila se i stížnost „Tým nebyl dostatečně utilizován“ – zatímco někteří lidi by měli pracovat a nemají čas, jiní mají čas a nemají práci. Nepříjemný důsledek specializace.

Jak je to se samostatností týmu? „Papírově“ sice máme schopnosti, abychom dodali, co se po nás žádá, ale je nám to houby platné v okamžiku, kdy někdo „odvelí“ důležitého člena týmu na jiný projekt který má „větší prioritu“.