Na tento vzorec jsem nedávno narazil v knížce Lead with Respect. I když je to takový překladatelský oříšek, v originále job = work + kaizen, tak myšlenka za ním je jednoduchá. Naše práce se skládá ze dvou stejně důležitých částí. Jednou je plnění úkolů, samotná pracovní činnost, to za co nás platí. U programátorů je to programování. To je jasné. Na co se ale často zapomíná, je druhá část, neustálé zlepšování se – kaizen. To by také mělo být nedílnou součástí pracovního dne. Důvod je jednoduchý. Věci mají tendenci se samy od sebe zhoršovat. Náš skvělý kód se nějakým zázračným způsobem přes noc zkazí. Technologie se posouvají vpřed. Lidi zapomínají. Co včera platilo, dneska už neplatí. Co včera fungovalo, dneska už nefunguje. Proti těmto tendencím musíme vědomě, systematicky, dennodenně bojovat.

I když ten vzorec platí stejně dobře pro jednotlivce jako pro celé firmy, chtěl bych se zamyslet nad tím, co to znamená pro scrumový tým.

Co jsou úkoly je jasné. To jsou věci z backlogu, věci, které po týmu někdo chce. Kde je ale ten kaizen? Je to ta retrospektiva jednou za čtrnáct dnů? Těžko. Smutnou pravdou je, že kaizen v mnoha týmech chybí. Není se čemu divit, ono je to takové nehmatatelné a těžko popsatelné. Vždyť na to ani nemáme pořádné slovo. Je ohromě snadné sklouznout do stavu, kdy tým jenom plní úkoly, které mu přichazí z backlogu. Vždyť to je důvod, proč ten tým vůbec existuje.

Takže se nemůžeme divit, když si někdo myslí, že by úplně všechna práce měla být v backlogu. Včetně refaktoringu, vylepšování infrastruktry nebo zlepšování testů.

Mě připadá, že je to lepší dělat jinak. Je mnohem jednoduší zařídit, aby měl tým na kaizen čas. Dá se snížit zátěž (velocity) týmu tak, aby měl ve většině sprintů časovou rezervu a tím pádem čas na kaizen. Co si ve zbylém čase bude tým dělat, je jen na něm. Může refaktorovat, zlepšovat automatizaci, něco si zkoušet, učit se. Je to oddělená část rovnice, product owner rozhoduje o úkolech, o kaizenu si rozhoduje tým sám. Proč? Protože tým nejlíp ví, kde ho tlačí bota. Je to samoorganizující se tým, proč by mu měl někdo kecat do toho, jak se má zlepšovat?

Snížení zátěže týmu je ta jednodušší část. Ta těžší část je naučit se to zlepšování samotné. Většina lidí to jednoduše neumí (mě nevyjímaje). U refaktoringu je to jednoduché, z ošklivého kódu udělám hezčí. Co ale takové to zlepšovaní procesu, toho jak fungujeme jako tým, ten původní význam slova kaizen? To jsme nikdy nedělali, nikdo nás to nikdy neučil a ošklivě v tom tápeme. Plnění úkolů je mnohem jednodušší a uspokojivější. Proto si musíme neustále připomínat, že práce = úkoly + kaizen.

Světonázor je více či méně koherentní chápání podstaty reality, které pomáhá jeho držitelům interpretovat nové informace ve světle jejich předsudků. Střety mezi světonázory nemohou být ukončeny jednoduchým odovláním se na fakta. I když se soupeřící strany shodnou na faktech, nemusí se shodnout na závěrech kvůli rozdílům v předpokladech. Michael Lind

Každý z nás má nějaký světonázor. Někdo věří, že existuje Bůh, někdo že ne. Někdo věří, že svět bude bezpečnější, když budeme mít všichni bouchačku, někdo že ne. Někdo věří, že funguje evoluce, někdo věří, že byl svět stvořen za šest dní. Podobných příkladů si určitě sami vymyslíte spoustu. Na světonázoru je zajímavé to, že je to něco uvnitř nás, na co mají fakta a realita velmi malý vliv. Naopak, světonázor ovlivňuje to, jak realitu vnímáme. Navíc je hrozně těžké si představit opačný pohled na věc. Říkáte si, jak se ten druhý může tak moc mýlit v tak evidentní věci.

Včera mi došlo, že agilní přístup je taky světonázor. Někteří lidé prostě věří tomu, že lidi jsou důležitější než procesy. Že je potřeba dělat chyby, abychom se mohli učit. Že je potřeba dát lidem autonomii, aby ze sebe mohli vydat to nejlepší. Jednoduše věří ve spoustu věcí. Když v ně věří, tak vidí spoustu příkladů, které jim ten pohled potvrzují. Nejen to co vidí kolem sebe, ale i každá knížka, každá přednáška jim říká, že mají pravdu.

Pak jsou ale lidé, kteří mají jiný světonázor. Věří, že je lidi potřeba řídit, říkat jim jak dělat svoji práci. Že je nejdůležitější, aby bylo všechno standardizované a zaškatlukované. Tito lidé zase vidí spoustu důkazů pro to, že mají pravdu oni.

Bohužel rozdíly ve světonázorech vedou ke sporům. Navíc k takovým, které se špatně řeší. Představme si, že někdo udělá chybu. Člověk s agilním přístupem by měl začít pátrat po příčinách. Měl by to brát jako příležitost k učení. Pro člověka s opačným pohledem na věc, jde o selhání, které je přirozené řešit procesem. Když se ho zeptáte, jestli si zkusil přesně pojmenovat ten problém a odhalit příčiny, tak se na vás kouká jako na blázna. Vždyť stačí napsat do dokumentu, že se lidi mají chovat tak a tak, a oni se tak chovat začnou. Když nepomůže dokument, tak kontrolní mechanismus zabere určitě. Proč to zbytečně komplikujete?

No jo, ale co s tím? Jelikož jsem známý průkopník slepých uliček, tak vám řeknu co nezabírá.

Logická argumentace
S tím jsem hrozně bojoval. Pořád jsem si myslel, že když to dokážu dost dobře vysvětlit, tak přeci musí pochopit, že mám pravdu. Vždyť je to tak evidentní. Bral jsem jako svoje selhání, že nedokážu předat to, proč musíme dát lidem co největší autonomii. Teď mi došlo, že jsem měl stejnou šanci na úspěch, jako kdybych chtěl Václavu Klausovi dokázat globální oteplování.

Ostrá letáková kampaň
Když to nedokážu vysvětlit já, tak to nechám na autoritách. Stačí kolegům jenom podstrčit knížku nebo jim pustit video a oni pochopí, že jak moc se mýlí. No jo, ale když jde o střet světonázorů, tak to nemůže zabrat. Naopak, často to pochopí „špatně“ a nejdou si tam důkazy pro to svoje. Dochází mi, že jsem působil jako Jehovista – úplně se vidím jak stojím u východu z metra a mám stojan s publikacemi o agile zdarma.

Takže vím co nefunguje, bohužel ale nevím co funguje. Lidi svůj světonázor můžou změnit, ale musí to vyjít z nich, zevnitř. Jediné co mě napadá je naučit se s tím žít a jít příkladem. Neznamená to, že radostně přijmu jakýkoliv proces, ale snad budu víc chápat, jak někdo tak chytrý, může přijít s věcí, která mi vůbec nedává smysl. Jednoduše má jiné vnímání reality.

Napadla mě taková pěkná otázka. Co je na Scrumu, nebo jiné vaší oblíbené agilní metodice, to nejdůležitější? Ano, je to nesmyslná otázka, ale mě se přesto líbí, protože krásně odhaluje, jak kdo o agile přemýšlí. Přestaňte číst a schválně se nad tím zkuste zamyslet. Co je pro vás na agile nejdůležitější? Bez čeho by to nedávalo smysl? Teď přestanete číst a přemýšlejte.

Já jsem si třeba kdysi myslel, že nejdůležitější jsou iterace. Tenkrát jsem dělal ve vodopádu a iterace mi přišly jako to nejdůležitější. Dnes to vidím jinak, a nemůžu pochopit jak jsem to mohl nevidět. Nejdůležitější je přeci tým. Ať se podíváte na jakoukoliv agilní praktiku, tak existuje kvůli týmu. Scrum Master pomáhá týmu dosáhnout jeho cílů, Product Owner musí být týmu k dispozici, retrospektiva je tu proto, aby se tým mohl zlepšovat, standup je od toho, aby tým věděl co kdo dělá. V Kanbanu se sleduje WIP aby tým viděl, jestli mu něco nedrhne. V XP je zákazník součástí týmu, tým má společné vlastnictví. Všechno se to točí kolem týmu. Slovo tým na nás kouká odevšud, nevidět ho je jako nevidět pro stromy les. Abych byl spravedlivý, přede mnou se ten les za stromy skrýval hodně dlouho.

Proč je tým tak důležitý? Použiji slova klasiků:

Stmelený tým je skupina lidí tak silně spojena, že celek je víc než součet jeho částí. Výkonnost takového týmu je větší než výkonnost těch samých lidí pracujících mimo stmelený tým. Neméně důležitá je radost z práce ve stmeleném týmu, která je často větší, než by odpovídalo povaze dané práce. … Jakmile se tým začne stmelovat, pravděpodobnost úspěchu roste dramaticky. … Tým nemusí být řízen v tradičním slova smyslu a rozhodně nemusí být motivován. Je rozjetý. … Důvod je jednoduchý, týmy jsou ze své podstaty formovány kolem cílů. … Před tím než se tým stmelí, jednotlivci můžou mít různé cíle. Nicméně jako součást stmelování, všichni přijali společný cíl.

Není toto pěkný popis toho, jak by měl fungovat agilní tým? Mimochodem, je to citát z mé oblíbené knihy Peopleware, z roku 1987. Nedávno se mi poštěstilo vidět počátky tmelení týmu v praxi a je to hodně zajímavé. Vidíte, jak se lidi najednou snaží řešit problémy, jak se začínají sami řídit, jak se víc a víc zajímají o to co a jak dělají. Vidíte jak ten vlak nabírá rychlost.

Tým je tedy srdcem každé agilní metodiky. Je bohužel i její achilovou šlachou. Iterace nebo retrospektivy zavedu snadno, ale jak zařídit, aby tým fungoval dohromady? Zalistujme v Peopleware o kus dál, do kapitoly týmovražda, kde se dočteme

Tým nemůžete stmelit. Můžete jenom doufat, že se to podaří, můžete se modlit, můžete zvyšovat šance na stmelení, ale nemůžete zařídit, aby se to stalo. Je to příliš křehký proces na to, aby se dal kontrolovat.

Autoři dál pokračují a píší jak se jim nedařilo najít způsoby, jak zařídit aby se tým stmelil, hrdě to přiznávají a říkají, že se jim naopak podařilo najít hromadu způsobů jak zařídit, aby se to nepovedlo. Jsou to hlavně:

• Defenzivní management – kdy manažeři nevěří svým lidem
• Byrokracie
• Fyzické oddělení členů týmu
• Fragmentace času lidí
• Snižování kvality produktu
• Nesmyslné termíny
• Clique control

Takže pokud se u vás zavádění agile nedaří, podívejte se, jestli fungují týmy. Pokud ne, zkuste mu odstranit překážky a doufejte, že to začne fungovat.