Video, které mě tento týden nejvíce zaujalo, je prezentace Allena Holuba s názvem
The Dead of Agile. Pokud jste video ještě neviděli, je to rozhodně must see pro
každého, kdo se pohybuje ve světě vývoje softwaru.
Allen připodobňuje zavádění Agilního vývoje ve velkých společnostech ke
Cargo kultu.
Během druhé světové války vybudovali Japonci řadu letišť v Melanésii.
Místní domorodci získali díky leteckému provozu mnoho užitečných předmětů a jídla.
Po skončení války Japonci letiště opustili. Domorodci se stále snažili přivolávat letadla
pomocí bambusových tyčí jako napodobenin antén a skořápek kokosových ořechů místo přileb.
Domorodci věřili, že předměty jsou tvořeny duchy, a pokoušeli se tyto duchy přivolat
děláním věcí, které předtím dělali vojáci japonské armády.
Allen argumentuje, že podobný Cargo kult můžeme vidět v korporátech, které se napodobením
některých procesů snaží přiblížit Agilnímu vývoji.
Ve středu 13. 6. 2018 proběhl další ročník Agile Open Space.
Agile Open Space je otevřený formát (unconference), kde témata navrhují sami účastníci.
Kvalita konference je dána kvalitou publika a to je v tomto případě opravdu mimořádné.
Agile Open Space se tak řadí mezi agilní akce, které bych během roku jen velmi nerad vynechal.
Ať jste o Agile nikdy neslyšeli nebo jste zkušení konzultanti, Agile Open Space je event pro vás.
Poměr získaných informací k zaplacené ceně (peníze + den života) je na této velké agilní párty enormní.
Minulý týden jsem navštívil šestý ročník konference ScrumImpulz v Bratislavě.
Konferenci bych zařadil mezi menší - jeden den přednášek, 8 řečníků,
jen jedna paralerní session, sto posluchačů.
Témata přednášek byla vesměs praktická:
Agility as the way to survive (Timofey Yevgrashyn)
Contracts and Agile (Martin Strigač)
One team, one goal (Marina Schiffer)
EduScrum, the very real alternative for education process (Ján Majoroš)
Navigating Disruption, Why is integrated risk critical in Agile environments (Stanislava Pendziviaterova)
Agile transformation - from developers to CEO (Antonín Moravec)
Ve srovnání s tvrdou konkurencí brněnských a pražských konferencí byla ScrumImpulz slabší.
Nejvíc mi vadily dlouhé přestávky vždy po dvojici prezentací, dále ne všichni řečníci byli
tak zkušení, aby za ně byl návštěvník ochoten zaplatit 109€ vstupu na konferenci.
Mám rád Bratislavu a na ScrumImpulz jsem se těšil. Snad příští rok to bude zase lepší.
Malá skupinka lidí (Hana Jadavan, Irena Buršová, Martina Bártů, Martina Hlaváčková)
včera uvolnila neoficiální překlad Scrum Guide s aktualizací z konce minulého roku.
Je to nejlepší český překlad, který je v současnosti dostupný.
Stahujte zde.
Práva k oficiálnímu překladu má výhradně společnost Aguarra. Bohužel od roku 2015
se oficiální překlad nedočkal aktualizace a navíc se tento překlad velmi obtížně čte.
U oficiálního překladu jsem měl pocit, jako by jej překládal Google translator a rychle
jsem přešel na anglickou verzi.
Pravidelná setkávání Scrum Masterů mě inspirovala k zorganizování unikátního setkání vývojářů
bez ohledu na programovací jazyk. Pojďme si popovídat o výhodách i úskalích naší profese,
pojďme diskutovat nad architekturou, vedením lidí, organizací týmu, automatizací, testováním…
protože vývoj software není jen bouchání kódu.
Většinu vyjednávacích taktik používají lidí intuitivně.
Taktika je jednoduchý manévr, tah nebo protitah.
Níže je přehled šesti nejběžnějších, se kterými se můžete setkat.
V praxi nejde ani tak o to jednotlivé taktiky použít,
jako spíše být schopni je identifikovat a neutralizovat.
Největší chybou při vyjdednávání je myslet si, že druhá strana musí prohrát, aby vy jste mohli vyhrát.
Když ani jedna strana nemůže vyhrát, z teorie her víme, že musíme změnit pravidla hry.
V nové hře mohou vyhrát obě strany.
Deadline
„Pokud to nebude do pátku, nemohu ručit za termín dodání.“
Tlak termínu může obě strany donutit jednat. Termíny mohou být skutečné nebo umělé.
Externí termíny jsou vynucené třetí stranou, interní jsou stanovené vaší organizací.
Obrana: Osoba nastavující termín počítá s tím, že je v lidské povaze věřit, že termíny jsou skutečné.
Pokud se chcese pokusit zneutralizovat termín, otestujte ho.
Položte několik otázek a zjistěte, jak skutečný a pevný termín je.
V případě skutečného termínu se zeptejte, odkud termín pochází,
je-li možné jeho prodloužení a jaké jsou důsledky nedodržení termínu.
Tímto způsobem můžete napadnout například umělé termíny projektového managementu :)
Omezená autorita
„Bude to muset schválit můj šéf.“
Vyjednávající zdůrazní svoji omezenou autoritu a zpomalí vyjednávání.
Výhodou je získání více času na rozhodování, případně i snížení tlaku protistrany.
Obrana: Je nutné zjistit, kdo dělá rozhodnutí, a setkat se přímo s tímto člověkem.
Vždy když je to možné, začněte vyjednávat s tím, kdo má pravomoc dělat rozhodnutí.
Je to jedna z možných taktik při vyjednávání o zvýšení platu. Můj vedoucí mi jednou
sedm měsíců sliboval projednání mého platu se svým nadřízeným. Až teprve
vytvoření tzv. věrohodné hrozby („Odcházím z firmy.“) donutilo protistranu jednat.
Alternativou omezené autority je „chybějící osoba“.
V případě „chybějící osoby“ nemůžete udělat závazné rozhodnutí bez tohoto člověka:
„Nemůžu s vámi diskutovat termín dodávky, protože náš projektový manager je po zbytek týdne mimo firmu.“
Morálka
„Nabídněte nám férovou cenu. Nemůžete očekávat, že zaplatíme tolik při vašich problémech s cloud-dovým úložištěm.“
Odvolání se na morálku má připomenout, že cíl vyjednávání je vzájemná spokojenost.
Tato taktika apeluje na váš smysl pro „fair play“ a zahrnuje mnoho prohlášení,
jejichž účelem je dostat vás na druhou stranu.
Obrana: Připomenutí podmínek a vysvětlení, že tyto podmínky jsou v nejlepším zájmu obou stran.
Zjistěte, jaká je skrytá motivace druhé strany a čeho se druhá strana doopravky obává.
Hodný a zlý
Hodný a zlý. Všichni jsme tuto situaci mnohokrát viděli v televizi. Jeden člen vyjednávacího týmu zastává extrémně radikální pozici,
klade nadměrné požadavky a odmítá rozumné ústupky. Neochota slevit vás může zastrašit, vyvést z rovnováhy a snížit vaše očekávání.
Najednou přijde do hry „hodný“ vyjednavač se smířlivými, mírně lichotivými poznámkami, a nabídne rozumnější nabídku.
I když druhá nabídka je relativně lepší, stále nemusí být dost dobrá v absolutním smyslu.
Člověk má přirozené nutkání s druhou nabídkou souhlasit.
Obrana: Dávejte si pozor na svoje původní požadavky. I když nabídka hodného vyjednavače může znít fantasticky v porovnání
se zlým vyjednavačem, stále to nemusí být nabídka dost dobrá pro vaši stranu. Zjistěte, jestli nabízené podmínky
souhlasí s vašimi požadavky.
Příklad: Některé zahraniční společnosti využívají této taktiky při diskuzi o platu. Nejde o to, že by nemohli svým zaměstnancům
platit více, ale chtějí, aby zaměstnanci měli pocit, že si při vyjednávání sáhli na dno a byli maximálně spokojeni:
„Podařilo se mi domluvit nástupní plat 50 000Kč. Je to skvělé. To mému kolegovi Frantovi, tomu se něco takového určitě povést nemohlo…“
Každý to tak dělá
„Nikdo na našem oddělení nemá takový plat, jaký chcete.“
Malé děti jsou mistři této taktiky: „Mami, každý ve třídě má nový mobil.“
Tato taktika se vyskytuje často také v obchodě.
Cílem je přidat na věrohodnosti svému tvrzení a oslabit protistranu.
Obrana: Použijte ověřená data (standardní marže, průmyslové standardy, inflace, …) a stanovte si férové podmínky dohody.
Dále si zjistěte, co konkurence nabízí a jaké mají vztahy s ostatními klienty. „Kdo jsou všichni?“
Asociace
„Tento projekt mi připomíná jednu zakázku pro XYZ s.r.o.“
Nejúspěšnější obhodníci používají tuto taktiku na začátku hovoru,
aby přidaly svým slovům věrohodnosti a zlepšili svoji vyjednávací pozici.
Taktika, někdy nazývaná „name-dropping“, spočívá v asociaci s různými jmény firem, lidí, produktů, atd.
Asociace může být velmi efektivní, pokud je pravdivá, ale také velmi manipulativní, pokud je nepravdivá.
Obrana: zeptejte se druhé strany na to, co dělaly pro jiné firmy nebo lidi, které v rozhovoru zmiňují.
Na jakých podmínkách se dohodli. Jak velká byla jejich objednávka? Zjistěte co nejvíce detailů o tom,
co druhá strana se zmiňovanými subjekty dělala v minulosti.
Jak můžeme škálovat Kanban? Odpověď je překvapivě jednoduchá:
Aplikováním Kanbanu ve větším měřítku. Jakmile máme zavedený
kanban pro alespoň jednu službu, existují tři dimenze,
do nichž může náš kanban růst.
Škálování do šířky
Škálovat do šířky znamená zachytit delší část životního cyklu úkolů.
V ideálním případě je zachycen celý životní cyklus.
Odkud úkoly přicházejí? Co se děje po jejich dokončení?
Následuje test zákazníkem?
Širší cyklus umožňuje odhalit nové možnosti optimalizace a zvyšování efektivity.
Příklad: Původní board zachycující pouze vývoj produktu je rozšířen
o “backlog nápadů” a práci s těmito nápady ještě před tím, než se dostanou do produkce.
Škálování do výšky
Škálování do výšky předpokládá hierarchii úkolů, které dohromady tvoří
produkt nebo službu. Například strategické plánování na nejvyšší úrovni
lze rozpadnout na jasně definované user stories, jenž mají být doručeny zákazníkovi.
Tyto high-level features lze dále rozložit na drobnější user stories,
na kterých bude konkrétní tým pracovat.
Kanban používá stále stejné principy a funguje v jakémkoliv měřítku -
ať jde o úkoly trvající hodiny nebo měsíce.
Obvykle se můžeme setkat se čtyřmi úrovněmi Kanbanu:
Osobní Kanban. Osobní Kanban může využívat jednotlivec nebo velmi malý tým
k efektivnějšímu organizování práce.
Týmový Kanban. Práce týmu je chápána jako služba. Aplikování praktik
Kanbanu vytváří předvídatelný tok hodnoty k zákazníkovi.
Produktový Kanban. Položky v produktovém Kanbanu by měly být menší než typický projekt,
ale dostatečně velké, aby mohly být rozpoznány a ohodnoceny zákazníkem.
Portfolio Kanban. Portfolio management není varianta produktového Kanbanu s většími projekty,
ale úplně nová disciplína zabývající se řizením finančního portfolia.
Risk v projektech je vyvažován prací s časovými horizonty, návratností investice,
hledáním alternativ v produktu vzhledem k pravděpodobným změnám na trhu a diferenciací
portfolia.
Škálování do hloubky
Dodání služby jedním týmem může být blokováno potřebou
specializované podpory jiného týmu s odlišnou specializací.
(Např. potřebujeme zjistit, že technologie, kterou se chystáme implementovat,
již není patentovaná.) Škálování do hloubky
propojuje týmy a znázorňuje závislosti mezi úkoly.
Zásadním předpokladem je, že všechny týmu již v nějaké podobě Kanban praktikují.
Zkreslení výběrem je matematický fenomén, který chtě nechtě každý den zažíváme v praxi.
Zkreslení výběrem znamená, že naše pozorování, ze kterých tvoříme širší závěry,
nejsou pro danou situaci reprezentativní. Informace, které se k nám dostanou, mohou
být záměrně zkresleny nebo si je jen vybíráme dle určitého klíče a tedy si je zkreslujeme sami.
O co se konkrétně jedná?
Kupujeme rajčata
Zkreslení výběrem bych nejnározněj vysvětlil na příkladu kupování rajčat.
Představte si, že se zastavíte v obchodě, prohlédnete si jedno, dvě, tři rajčata,
a pokud se vám líbí, vezmete si kilo. Gratuluji, právě jste provedli něco, čemu se říká
statistical inference. Z vlastností malého vzorku rajčat jste odvodili kvalitu všech rajčat
u obchodníka. Obchodník vám z nich náhodně vybere kilo.
Všechno funguje dobře jen do té doby, dokud je výběr rajčat čistě náhodný.
Vybral-li vám rajčata obchodník, mohlo se stát, že vám záměrmě ukázal tři nejlepší kusy.
Mylně se pak může zdát, že všechna rajčata jsou krásná. A to je právě zkreslení výběrem.
Zkreslené informace tým lídra
Není-li k nějaké manažerské roli ze strany podřízenýc naprostá důvěra, je téměř jisté,
že se k této roli dostanou jen určité, filtrované, informace.
Ve chvílích, kdy se na první pohled může zdát, že tým exceluje, mohou lidé ve skutečnosti
zažívat své nejhlubší krize.
Vývojáři nemusí říkat všechno, protože:
se bojí, že budou potrestání;
nechtějí být sami pověřeni nápravou situace;
nevěří, že k nápravě (ze strany třetích osob) dojde;
mají strach o své prémie;
nechtějí vedení naštvat.
Cesta informací ke střednímu managementu musí naopak projít přes nižší management.
Vzniká tzv. kognitivní bublina, ve které management žije.
Objevování bugů při testování
Analogií výběru bugů z backlogy je navrtávání ropných polí v Texasu.
V následujícím grafu ukazuje osa x počet pokusných vrtů a osa y normované množství objevené ropy.
[citace: Root, Drew: The pattern of petroleum discovery rates]
Z grafu je vidět, že několik málo vrtů vedlo k objevení většiny známé ropy. Lineární aproximace
“uděláme dvojnásobek vrtů, abychom objevili dvojnásobek ropy” rychle přestala fungovat.
D. H. Root a L. J. Drew vysvětlují, že velká ložiska jsou objevena první, protože je nejsnadnější je objevit.
Při testování softwarového produktu se můžeme setkat se stejnou křivkou jako na obrázku výše.
Na ose x je doba testování, na ose y počet objevených bugů.
Během prvního dne je objeveno nejvýce chyb a množství nově objevených chyb další dny klesá.
Stejným způsobem, jakým bychom odhadovali množství neobjevené ropy, můžeme analogicky v některých případech
odhadnout množství bugů, které zatím unikly objevení v testech a budou nalezeny až u zákazníka.
Závěr
Podobných příkladů zkreslení výběrem bychom mohli nalézt bezpočet. V praxi je důležité o možném
zkreslení vědět. Na zkreslení výběrem můžeme provést korekci nebo data interpretovat jiným způsobem.
Jednou z věcí, které jsem se naučil ve své krátké kariéře agilního kouče, je nedělat
změnu tam, kde není vítána. Jednou z takových změn byl můj pokus o zlepšení přijímacích pohovorů.
Bylo to v době, kdy jsme akutně sháněli nového člena našeho Scrum týmu. Představy ideálního vývojáře
byly přibližně takovéto: dobrá znalost programovacího jazyka, komunikativní, týmový hráč, zkušenosti
z jiných firem nebo vlastní projekty, schopný vyznat se ve vícevláknové aplikaci.
Mysleli jsme si, že něco takového by mohla splňovat většina kandidátů. A nesplňovala.
Po pěti neúspěšných pohovorech jsem začal přemýšlet nad tím, co děláme špatně.
Vodí k nám agentury nevhodné uchazeče? Většina lidí totiž přišla na pohovor
právě přes agentury. Šestý člověk, jenž se ucházel o práci v naší firmě, byl poněkud zvláštní.
Byl to Ind, který nám narovinu ukázal svoje pracovní zkušenosti týkající se téměř výhradně
fixování bugů. Byl to člověk, který nikdy nic velkého nenapsal, zato
dobře věděl, jak analyzovat legacy kód. Oběma, mě a mému šéfovi, nám zamotal hlavy.
Nejprve jsme ho (alespoň pro sebe) zamítli. Později, při rozhovoru s Product Ownerem, jsem si uvědomil,
že fixování bugů je přesně to, co děláme. Při pohovorech hledáme nějaký - z našeho pohledu - ideální
typ vývojáře, který se ale vůbec nemusí hodit pro práci, jaká se u nás reálně dělá. A nechceme si to připustit.
Otázky, které na pohovorech můj šéf kladl, se za posledních pět let nezměnily.
Mí kolegové a já jsme byli všichni přijati dle úplně stejných otázek.
Bylo na čase se zamyslet nad tím, jak vlastně děláme pohovory. Klademe správné otázky?
Pomáhají nám tyto otázky zjistit to, co chceme zjistit? Nebo je to jenom taková naše formalita?
Nejsme předujatí? Umožňujeme různorodost lidí v týmu? Chtěl jsem si promluvit se šéfem.
V případech, kdy si nejsem jist výsledkem, otevírám téma velmi ze široka. Proč se nám nedaří hledat
vhodné uchazeče? Sledujeme otázkami to, to chceme zjistit? Můžeme pohovory nějak vylepšit?
Dostalo se mi rázného zamítnutí. Pohovory děláme dobře. Není co zlepšovat, protože už je to dobré.
Otázky jsou odzkoušené a fungují.
Můj nadřízený měl zkrácený úvazek a svoji práci nikdy nedelegoval.
Takže ano, chápu, že se mu toto téma nechtělo řešit. A já jako kouč nedělám změny tam, kde nejsou vítány.
Je to přibližně týden, kdy byla spuštěna stránka Hany Farkaš
jaktodelamja.cz. Jde o skvělou věc - konečně
máme všechna videa z Jak to dělám já pohromadě.
Jak to dělám já je komunitní akce pro Scrum Mastery, kteří tak mají
možnost nahlédnout do zákulisí práce jiných Scrum Masterů, aniž by opustili svoji firmu.
Protože každý Scrum Master přikládá důležitost jiným dovednostem a prezentuje svoji
práci z odlišné perspektivy, jsou prezentace velmi pestré.
[citace: Root, Drew: The pattern of petroleum discovery rates]