Jistě jste si už mnohokrát zkusili zavádět v praxi nějaké novinky. Obvyklý postup je začít prezentací, ukázat o čem nový způsob práce je, co jsou jeho výhody, jaká jsou očekávání. Začnete-li takto ‘po staru‘ prezentovat Agilní metody, pravděpodobně se dočkáte spousty připomínek, že metody jsou moc americké, ve vašem případě z nejrůznějších důvodů nevhodné, přinesou spousty overheadu a sníží efektivitu. Proto se mě osvědčilo zavádět Agilní metody ‘agilně‘, tedy po částech a takříkajíc plíživě.
Základ je nikomu v týmu neříkat, že od teď nastane změna a bude se pracovat jinak. Lidé obecně změnu nemají rádi. Naopak. Vše je při starém, jen zavedeme každý den krátký meeting. Začneme neformálně, nějakou historkou, statusem projektu (stejně si všichni stěžují, že chtějí vědět co se děje) a postupně se začneme ptát jednotlivých lidí na to, co dělali včera a budou dělat dnes… zní to povědomě? Asi ano. A máme Scrum či Stand-up meeting tak jak má být. Tým si pozvolna zvykne, a ani mu to nepřijde. Vcelku snadný začátek.
K tomu aby se opravdu začalo plánovat v bodech sice nějaké vysvětlování potřebujete, ale když už umíte pěkně Scrum meetingy, znáte status jednotlivých úloh a i to jak vám jdou od ruky, máte pro to informace, co potřebujete. Mě se osvědčilo koncept seznamu úloh (nemusíte mu hned říkat backlog) vysvětlit, vysvětlit že ohodnocení odpovídá náročnosti a že ho budeme dělat v bodech. Pak už stačí nechat odhadovat úlohy jednotlivé členy týmu, klidně v hodinách, ale toto ohodnocení hned převádět na body. Složitější celky odhadnete sami. Po čase, kdy budete body vysvětlovat na konkrétních úlohách lidé koncept vstřebají a budou ho umět sami používat.
Dalším krokem je vytvořit plán na nějaké iterace (sprinty), ze začátku ho uděláte vy, později jeho vytváření delegujete na tým. A rovnou jim můžete dát burndown na nástěnku. Když budete mít týmů víc a podpoříte soutěživost, o pozornost máte postaráno. Někde během tohoto procesu zavedete prezentace zákazníkovi (customer demo) a začnete se ho ptát na zpětnou vazbu a priority. A to už máme v podstatě celý Scrum proces, aniž by o tom někdo věděl. A když už vám to tak pěkně funguje, můžete metody pojmenovat a dopilovat jejich formu.
Hledáte-li rady jak začít s Agilními metodami, většinou začínají komplexní teorií, kterou stejně tým bez vyzkoušení nepochopí a hlavně všemi metodami najednou (neboť jinak by to přeci nebylo dost agilní, to by nebyl ten pravý Scrum proces). Výše zmíněný postup je jen alternativou, která vám umožní dělat změnu procesu, aniž by to bylo vnímáno jako změna procesu. Jsou to jen takové drobné novinky, takové malé vrtochy našeho projekt managera, to přejde, chvíli budeme chodit na meetingy a on se třeba unaví…
Naučte se, jak transformovat firmy, měnit firemní kulturu a leadership pomocí Agilního & Enterprise Koučinku. Podívejte se na vypsaná školení zaměřených na Agile a Scrum na Sochova.cz. Pořiďte si kopii populární knihy The Great ScrumMaster: #ScrumMasterWay, Skvělý ScrumMaster #ScrumMasterWay, Agilní lídr: Využití síly vlivu nebo Agilní Metody Řízení Projektů.
Pocitam, ze to bude dobre fungovat, ale z voleje mne napadaji dve namitky:
– ztrati se terminologie, hrozi, ze bude kopec teamu pouzivat “takyscrum”, ale nebudou schopni se vzajemne pobavit o tom, co a jak delaji, ta znalost zustane uzamcena u jejich samanu. Spousta myslenek v IT neni nova, je to jen spojeni terminologie. Vsichni jsme psali singletony i nez prisla banda ctyr, ale az diky nim se o tom muzeme snadno bavit. Takze zbavit metodiku jeji terminologie muzeme vnimat spis jako degresi nez progresi.
– programatori (hlavne ti “ambiciozni”, coz neznamena karieristi, ale ti dychtivi jit po krku novym vecem) jsou prekvapive ochotni zkusit neco dalsiho (metodika, knihovna, jazyk…), pokud dostanou vysvetleni, proc je to dobre. To s timhle pristupem nedostanou.
Ono neslo ani tak o to, aby se nerikala terminologie a ‘co za tim je’, ale spise o koncept nejdrive praktiku zkusit, pak ji pojmenovat a vysvetlit. Ma to tu vyhodu ze nerikate proc by to melo fungovat, ale rovnou muzete ukazat konkretni vysledky, a poukazat na to jak praktika zafungovala a proc. Je to o to silnejsi, ze uz mate vysledky primoz vaseho specifickeho prostredi.
Navis zavadet veci postupne je podle me snazsi, nez menit vse najednou. Vse spojit a vysvetlit cely koncept muzete nakonec vzdy. To se nevylucuje.
Myslim, ze postupne zavadeni je lepsi, aspon podle me zkusenosti, ve firmach, kde neni zmena uplne vitanou veci nebo pripadne tam, kde je jen interni IT oddeleni a management nechce nejakeho “product ownera”. ve chvili, kdy se pak agilni metodika (i kdyz se ji tak nerika) osvedci, snaze se presvedci management, ze par dodatecnych tahu by umoznilo produktivitu jeste zlepsit. Myslim, ze nejtezsim oriskem stejne je zmena mysleni z “projekt bude hotov 31.5” na “projekt bude hotov jakmile product owner rekne a do te doby jsme schopni zhotovit priblizne 250 bodu kazde dva tydny, nasazene a otestovane”. V teto zmene mysleni nehraji nazvy a terminologie zadnou roli, bohuzel 🙁
Matej
To jde z pozice manažera, ale my, řadoví programátoři, si své manažery ke scrumu musíme sami vychovávat. Je to takový “guerilla scrum” – postupně je musíme přesvědčovat, že jednotlivé prvky scrumu jsou dobré, a že jim mohou pomoct. A je to tvrdá práce. Spousta vysvětlování a přemlouvání, abychom každou jednotlivou věc alespoň na zkoušku zavedli. Někdy nepomůže nic jiného než partyzánská akce – domluvit se s kolegy, kteří mají otevřenou mysl, že to zkusíte sami dobrovolně, a tím načas přejdete do částečné ilegality:-) Máme to štěstí, že nám tyto metody díky naší firemní kultuře celkem prochází. Dokážu si představit, že v jiných firmách takovýmto iniciativám manažeři zatnou tipec hned na začátku. A přitom to děláme vlastně pro jejich dobro:-)))
Satai: To máš sice pravdu, ale to může přijít zpětně; lidi, kteří prostě změny nechtějí se o nich stejně moc bavit nebudou.
Jinak já jsem taky ve fázi metascrumu, je to docela zajímavé.
Presne, az na to, ze ako to pozeram, agilne programovanie je prechod k slusnej ludskej komunikacii, co kedysi bolo normalne a nemuseli sa o tom pisat teorie. Aj ked v dnesnej dobe chodia analytici uz iba po postu, lebo programatori za nich pracuju za nizsie platy. Co robi taky biznis analytik? za dvojnasobny plat odo mna taha rozumy, a este mi ani neposle analyzu. Je to cele chore – ludia uz vymyslaju pakoviny aby mohli nadalej vytvarat dalsie a dalsie bubliny, ktore im. Myslim si ze najvacsou chybou bolo nazvat veducich pracovnikom manazermi. Mal im jednoducho ostat nazov veduci a kazdy by hned vedel, ze o koho ide.
Kubo, je mi lito, ze to tak ve firme mate. Bohuzel nikdo nedokaze posoudit praci na urcite funkci dokud ji sam nedela. I proto napr. deleguji jednotlive ukoly ve sprintu nebo dokonce cely sprint. 90% prace vedoucich/manageru/leadru je komunikace. Na tom zadny honosny nazev nic nezmeni.
Matej
😉
Bojím se, že “Kubo” je hodně blízko realitě. Většinou pracuji jako konzultant v metodách / systémech řízení … to, co vidím v malých, středních … ale především velkých firmách je celkem úděsné …
Souhlas s tím, že jde především o komunikaci, ale také souhlas s tím, že ta může fungovat pouze v podmínkách, které ji podporují … či spíše nekompromisně vyžadují. Kdy řídící pracovníci jsou hodnoceni za to, že jejich týmy mají či nemají výsledky … atd. atd.
Hodně jsem dříve agitoval za “partyzánské” šíření (tzn. rozumné metody, postupy a pravidla si musíme holt vytvořit sami, naši šéfové to dělat nebudou protože jim vyhovuje status quo … změna nejvíce “ohrožuje” právě ty, kteří mají zodpovídat za produktivitu, výkon a efektivnost) … ale po mnoha letech konfrontace s realitou jsem na vývojové spirále zpátky u “ryba smrdí od hlavy” (a naopak). Ve výjimečných případech to tak možná půjde, ale obecně je to mlácení hlavou do zdi.
Ovšem výchozí myšlenka – změnu neohlašovat, ale prostě provést (tzn. najít postupné dílčí kroky, které vedou v kumlovaných důsledcích k celkovému zlepšení) … nemám nic než hodně obdivný potlesk. Analyzovat situaci, navrhnout žádoucí stav, definovat kroky… to je přece “jasné”. Jenže všechny autority tvrdí, že změnový projekt musíme předem “důkladně komunikovat”. Musím přiznat, že až doteď jsem si to myslel (celkem “bezmyšlenkovitě”) taky. Jenže to, co je navrženo zde – prostě vzít si tu zodpovědnost a dát si tu práci a důsledně právě ty postupné kroky/změny připravit a provést, to je přece mnohem logičtější!
(clap)