Nápadov, ako situáciu zlepšiť môže mať mnoho. Môže ho napríklad napadnúť "rýchla akcia", pretože nechce venovať situácii veľa času a možno ho už štve ako dlho problém trvá. A tak sa rozhodne (v prípade ak ide o manažéra) niekoho vyhodiť, alebo vymeniť scrum mastera. Alebo v lepšom prípade niekoho pošle na 3-dňové školenie (korporátny sheep dip) s očakávaním, že človek sa vráti ako "odborník" a že situácia sa tým vyrieši.
Ak to nezaberie, môže skúsiť iný nápad. Napríklad, zaviesť rotáciu ľudí. Čas od času môže povymieňať ľudí, aby sa nedostali do "provoznej slepoty", alebo aby každý mal možnosť pracovať na niečom inom, aby ľudia mali stále pocit, že sa učia. V prípade, ak firma bojuje s technickým dlhom legacy kódu formou maitenance oddelenia, tak ľudia sa môžu preplachovať aj tam. A tak sa tím vlastne nikdy nestihne stabilizovať, keďže to (podľa psychologických výskumov) trvá tak zhurba pol roka.
Ďalším nápadom môže byť napríklad skúsiť zaviesť párové programovanie. Myslím si však, že toto napadne skôr scrum mastera ako manažéra. Dvaja programátori sedia za jedným počítačom s jednou klávesnicou. Jeden píše, druhý ho kontroluje, a po hodinke alebo nejakom čase sa striedajú. Má to veľa výhod a aj poprední programátori to veľmi chvália. Ale nariadiť takúto zmenu "zhora" môže mať tiež negatívny efekt - ľudia môžu byť k takémuto prístupu skeptickí, pretože ak to predtým nikdy neskúšali, predstava, že budú musieť robiť "s tým" alebo "s oným", ich neláka. A tiež to vyžaduje vyjdenie z určitej komfortnej zóny, čo dokážu iba tí čo naozaj niečo "chcú".
Iný príklad môže zahŕňať ďalšie drastickejšie zmeny, ako napríklad zmena kompletného procesu. Napríklad "od dnes sme agile". Alebo rôzne typy vyhrážok či odmien, extra bonusov. Každý manažér má rôzne nápadité "nápady", ktorými si môže myslieť, že si ďalší problém môže škrtnúť z (asi dlhého) zoznamu problémov.
V týchto príkladoch, a vlastne je úplne jedno, koľko ich ešte vymyslím, a aké super overené sú, budem bohužiaľ veľmi skeptický. Myslím si, že je veľká pravdepodobnosť, že to nevyjde. Prečo? Jednoduchá odpoveď znie, pretože prichádzajú od manažéra. To, že tím nefunguje, si vlastne všimol manažér. Riešenie na problém tiež objavil manažér (alebo scrum master).
Základom je diskusia
Je myslím úplne v poriadku, keď si problém všimne niekto iný. Samozrejme, veď problém tímu môže byť aj v tom, že si sami nevidia ďalej od nosa. Dôležité však je neísť ďalej. Pretože funkcia tímu v agile ale aj z psychologického hľadiska je hlavne samostatné riešenie problémov, alebo úloh. A to, že má tím problém, si myslím že sa nijakým spôsobom nelíši od iných úloh. Je to tiež úloha, ktorú by mal tím zvládnuť sám (samozrejme pomoc tam byť môže).
Jeden z princípov agile hovorí:
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
Myslím si, že ak má tím problém, je najdôležitejšie aby o tom vedel sám tím, aby si to naozaj uvedomoval. Žiadne riešenie, ktoré manažér poskytne, problém nevyrieši, ak tím sám neprijme fakt, že má problém.
Predstava manažéra ako "zadávateľa príkazov", alebo egoisticko-naivného "ja viem najlepšie čo pomôže, pretože mám informácie a skúsenosti, ktoré oni nemajú", veľmi rýchlo stroskotá na výsledkoch. Tím sa "zlepší" len naoko. Prečo?
Nápady nemusia byť zlé
Povedzme si to na rovinu. Manažér nemá vo firme úlohu kreatívneho prispievania k produktu, ktorý firma vytvára. On sa nestretáva s každodennou pracovnou rutinou tímu, s každodennými problémami a "aha!"-efektami, ktoré ľuďom v tom tíme formujú myslenie. Skúsenosti, ktoré tím získava svojou každodennou prácou, tým, že manažér presadzuje vlastný pohľad, bohužiaľ začnú vychádzať nanivoč.
Samotná kreativita ľudí, ktorá v tvorbe softvéru je primárne žiadanou vlastnosťou, je pošliapavaná manažérskymi rozhodnutiami. Je dôležité, aby tím mal možnosť svoje skúsenosti aplikovať na ďalšie zlepšovanie. Aby cítil slobodu a otvorený priestor "nekonečných možností", a k tomu by mal manažér a všetci ostatní pomáhať. Týmto smerom si myslím, že by mal tím viesť.
Aby sa odstránili vzťahové problémy, komunikácia, aby ľudia VEDELI byť k sebe úprimní. Nejde o to, aby bol v miestnosti "hluk" ako každému ide huba, ako sa tu super komunikuje, ide o to, aby človek dokázal bez manipulácie a presadzovania vlastného ega úprimne "ľúbiť" softvér, na ktorom pracuje, aby sa každý mohol tešiť z toho, čo robí, pri vzájomnom rešpekte.
A problém preto často nie je v zlom procese, alebo že sa nerobí párové programovanie, alebo, alebo.. Problém je často v tom, že sa potrebujeme vedieť zastaviť bez strachu z nestihnutia termínu, a riešiť problém. Že sa občas potrebujeme vydať smerom, ktorý možno nikam nebude viesť, ale že to nebude znamenať náš "koniec". Potrebujeme mať pocit, že náš fail nevadí. Fail safe. Ako manažér, aj tam je naša úloha vhodná.
Druhou vecou je, že musíme byť úprimní. Musíme svoje osobné vlastnosti zlepšovať, musíme sa chcieť zlepšovať. Budovať svoju osobnosť. Dôvodom je, že nám to dá otvorenú myseľ. Vedieť, že nie sme dokonalí, vedieť o svojich nedostatkoch a vidieť tú diaľku vecí ktoré nevieme, nám pomôže pochopiť druhého človeka, pretože pravdepodobne má tiež nedostatky, tak ako my, a my budeme vedieť, aké ťažké je na sebe pracovať. To je podľa mňa myslené už spomenutou vetou:
"Build projects around motivated individuals."
Manažér ako služobník
Vo svojej podstate, prečo vlastne existuje softvérová firma? Moderné softvérové firmy sa začali formovať s príchodom mikropočítačov. Je snáď každému jasné, že ľudia pracujúci s mikropočítačmi 70-tych a 80-tych rokov boli nadšenci. Vtedy sa kašľalo na nudné procesy, vtedy išlo o to vyhrať vojnu o prestíž, o novinku, o to byť najlepší na trhu.
Existovala obrovská diverzita počítačov a vlastností, dnes už takú nemáme. Všetko sa nejak štandardizuje, a čo je vlastne dobre, pretože nám to zlepšuje systematizáciu práce, jednoduchšie sa nám prenášajú dáta, atď.
Čo však mnoho dnešným softvérovým spoločnostiam chýba, je uvedomiť si, ako boli vedení ľudia tej doby. Viem, že mnoho z nich veľa nespali, že to pracovne preháňali. O tom nechcem tvrdiť, že to bolo dobré. Ale tí ľudia boli zo svojej práce nadšení. Tímy chodili za svojimi manažérmi vlastne "ukazovať", čo vymysleli, na čo prišli. Mali z toho radosť, a aj keď nie vždy bola práca predajná, myslím si, že to bol ten dôvod tých najväčších úspechov.
Dnes, aj vďaka tejto minulej dobe už máme skúsenosti s mnohými vecami, ktoré sa osvedčili ako dobré, a ktoré zas nie. Je myslím prirodzené, že na začiatku je vždy všetko chaotické, a postupne sa to usporiadava a začína fungovať ako hodinky. To sa myslím stalo - a stále pokračuje - aj s vývojom softvéru.
Už myslím máme moderné prostriedky, a aj procesy na to, aby sme dokázali popísať čo má ten najväčší vplyv na produktivitu. Možno agile je takýmto procesom, ale myslím si, že mnoho princípov je iba vyjadrením zdravého sedliackeho rozumu, ktorým je, že človek sa najviac obetuje veci, ktorú má rád.
