W pierwszym przypadku (projekt) możemy zapewne posłużyć się mechaniką zwinną, ale im więcej decyzji podejmiemy z góry, im bardziej detalicznie zdefiniujemy punkt końcowy (czyli to, co ma powstać), tym mniejsze szanse na uzyskanie dużych korzyści z działania zwinnego, o ile w ogóle będzie ono możliwe. Jeśli bowiem realizować będziemy po prostu poczynione z góry plany, to naszą intencją raczej nie będzie ich zmienianie, by dostosować się do bieżącej sytuacji. Zrobimy to, jeśli nie będzie wyjścia, minimalizując zakres tego dostosowania.

W drugim przypadku (nazwijmy go rozwojem produktu albo ogólnie rozumianej wartości), działanie zwinne ma dużo większy potencjał i jeśli będziemy umieli go zastosować, przyniesie wymierne korzyści. Jakie? Eliminację marnotrawstwa, redukcję ryzyka inwestycyjnego, większą wartość tego, co wytwarza organizacja dzięki lepszemu dopasowaniu do zmieniających się potrzeb. Inaczej mówiąc, w tym przypadku zwinność nie ograniczy się do samego procesu wytwórczego (jak przy „zwinnym realizowaniu projektów”), ale obejmie też proces selekcji tego, co zrealizowane zostanie.

Cel

Kluczowe jest ustalenie celu, jaki chcemy osiągnąć. Metody zwinne nie są „innym sposobem na robienie tego, co robiliśmy dotychczas”, ani nie pozwolą „robić więcej lub szybciej tego, co robimy dzisiaj za wolno, albo w zbyt małej ilości”. Zwinność to w istocie sztuka skutecznego wybierania, co warto zrobić i robienia tego jak najszybciej. Dzięki temu, choć zrobimy dużo mniej, to co potrzebne i wartościowe pojawia się szybciej.

A zatem do czego takich mechanizmów chcemy użyć? Bo jeśli chodzi wyłącznie o „efektywniejsze zarządzanie projektami”, to właściwie możemy sobie od razu powiedzieć, że żadnej zwinności nie uzyskamy. Użycie metod Agile, jeśli po nie sięgniemy, może spowodować poprawę samego procesu wytwarzania rozwiązań, ale to jeszcze nie świadczy o zwinnym działaniu. Żeby o nim mówić, empiryzm musi działać nie tylko na poziomie wytwórczym, ale również (albo przede wszystkim) na poziomie decyzji odnośnie do tego, co będziemy wytwarzać.

A gdy już określimy cel, jaki chcemy osiągnąć dzięki Agile, warto zastanowić się, co jest miarą jego osiągnięcia i zdefiniować, jak chcemy te miary sprawdzać: jak często i kto je będzie sprawdzał, jakie wartości są oczekiwane, co świadczy o tym, że idziemy w dobrą stronę.

Ewolucja, nie projekt

Kolejna sprawa: nie da się „wdrożyć metod zwinnych”, bo to implikuje przeprowadzenie czegoś na kształt projektu, gdzie na koniec będzie można ogłosić sukces i orzec, że „od teraz firma jest zwinna”. Pamiętajmy, że zwinność to umiejętność reagowania na zmiany, a te pojawiają się nieustannie. Jeśli założymy, że potrafimy zdefiniować z góry, co to znaczy „zwinny” i zaplanujemy, jak i kiedy to osiągniemy – to już ponieśliśmy klęskę, zanim w ogóle ten nasz projekt zaczniemy realizować. Dlaczego? Bo postępując w skrajnie niezwinny sposób, nie da się nauczyć zwinnego działania, a bez tej umiejętności ciężko mówić o zwinności, czyż nie?

Poprawne użycie metod zwinnych polega na czymś innym. To ciągły proces, w którym poszukujemy, jak lepiej korzystać z empiryzmu przy podejmowaniu decyzji i realizowaniu ich. Nie da się stworzyć uniwersalnej recepty, jak zacząć, a co dopiero mówić o próbie określenia „stanu docelowego”. Prawdę mówiąc, przekonanie o tym, że istnieje jakiś „stan docelowy”, jest pierwszym sygnałem, że chyba nie rozumiemy istoty empirycznej kontroli procesu i jej zastosowania do radzenia sobie ze złożonymi problemami.

Zwinne stawanie się zwinnym

Dlatego, gdy już określimy cel, jaki chcemy osiągnąć (albo osiągać) za pomocą Agile, i gdy mamy już zdefiniowane miary, którymi chcemy mierzyć jego osiąganie, przeanalizujmy: co najbardziej potrzebne jest do osiągnięcia tego celu? Co zrobić, by to coś się pojawiło? Co utrudnia osiągnięcie celu? Co zrobić, by te utrudnienia usunąć? 

Z tych rozważań wyłoni się lista rzeczy, o które trzeba zadbać (problemów, procesów, narzędzi, kompetencji itd.). W krótkich interwałach, oceniając regularnie, czy uzyskujemy właściwe efekty, pracujmy nad tymi rzeczami. Tak, jak buduje się złożony produkt. Iteracyjnie i inkrementalnie (przyrostowo). Oczywiście w miarę, jak będziemy posuwać się do przodu, odkryjemy nowe problemy, możliwości, konteksty, narzędzia itd. – wtedy musimy nasz plan działania („backlog”) dostosowywać. Bo gdybyśmy z uporem trzymali się pierwotnych zamysłów, realizując je w klasyczny projektowy sposób, od pewnego momentu będziemy na pewno szli w złą stronę, rozmijając się z realiami środowiska i problemami, jakie nas otaczają.

Artykuł Metody zwinne w dużych projektach pochodzi z serwisu CRN.

Uważam tak, bo istotnym elementem idei agile w ogólności, a Scruma w szczególności, jest założenie, żeby to ludzie wykonujący pracę sami ją sobie organizowali. W Scrumie organizacja narzuca być może strukturę, w tym właśnie Scrum, narzuca podział na zespoły (choć lepiej jeśli pozwoli się ludziom, aby sami się do nich przypisali lub choćby o tym współdecydowali), ale o całej reszcie ma decydować zespół. Ba! Cała następna fala nowatorskich metod zarządzania typu Holakracja idzie jeszcze dalej: pracownicy sami ustalają również struktury oraz podział odpowiedzialności i obowiązków, który jest przez nich dynamicznie dostosowywany zależnie od potrzeb.

Skąd ta idea się wzięła? Choćby z obserwacji, że to ludzie bezpośrednio wykonujący pracę mają najwięcej wiedzy na temat tego jak ona jest wykonywana, a zatem są w najlepszej pozycji do tego, żeby ją usprawnić, poprawić. A także z obserwacji, że jeśli ludzie mają wpływ na to jak pracują, to są bardziej zaangażowani w pracę – co powoduje, że jeszcze bardziej im zależy, żeby to dobrze działało. I tak mamy w organizacji – a przynajmniej w zespole – pozytywne sprzężenie zwrotne, które podnosi i jakość pracy, i zaangażowanie. Do tego właśnie służą w Scrumie retrospekcje – robiliśmy cały sprint, teraz pomyślmy jak tę pracę robiliśmy, abyśmy w przyszłości robili ją jeszcze lepiej, ponieważ nam na tym zależy.

Zresztą, Scrum wziął się stąd, że zaangażowani deweloperzy i współpracujący z nimi produktowcy oraz menedżerowie kombinowali, jak pracować lepiej. W skrócie, Scrum to jest coś co zespół robi, żeby lepiej działać (o czym pisałem szerzej w przywołanym już artykule, „Kryzys agile”, CRN Polska nr 12/2020). Mentalność „my wam to poustawiamy, nie musicie tego robić, wy macie kopać” jest z tym sprzeczna, wręcz szkodliwa. Obniża zaangażowanie, promuje postawę klasy „ja tu robię X od-do, a resztę mam w… głębokim poważaniu” albo „niech menedżer, to znaczy Scrum Master się tym zajmie, to nie moja sprawa”. To jest stawianie Scruma na głowie, powrót do biernych deweloperów zarządzanych przez menedżerów, którzy – jako ci starsi i mądrzejsi – poustawiają im świat. Czyli powrót dokładnie do tego, czemu przeciwstawił się cały ruch agile. Innymi słowy, takie myślenie to prosta droga do tego, żeby Scrum nie był czymś, co robią deweloperzy, aby lepiej działać, ale stał się czymś, co inni robią deweloperom. A to, jak już wiemy, nie działa. Właśnie między innymi dlatego, żeby walczyć z takimi pomysłami, w najnowszym „Scrum Guide” nie ma już ról. Są odpowiedzialności w zespole (Scrum Team). Cały zespół odpowiada za to, czy praca jest dobrze zorganizowana i czy jest wartościowa.

Jeśli to czytasz, a masz odpowiedzialność Scrum Mastera, apeluję: nie stawiaj Scruma na głowie! Nie próbuj we wszystkim zespołu wyręczyć. Pewnie, jeśli zespół jest mało doświadczony, w ogóle świeży to układania potrzebuje więcej. Ale z czasem ma być go coraz mniej. Nigdy nie stawiaj się ponad zespołem, nie myśl, że TY im poukładasz, a oni nie muszą o tym myśleć. Przeciwnie – powinni o tym myśleć. Jako SM dąż do tego, żeby każdy członek zespołu czuł się odpowiedzialny nie tylko za swoje od-do, ale za całość: całość tego, jaki produkt jest, jak wygląda zespół, jak wygląda organizacja, co można poprawić. Jeśli będzie inaczej, Twój zespół odrzuci Scruma, traktując go jako kolejny wymysł menedżerów wciskany im na siłę. A nie o to przecież chodzi.

Andy Brandt  

jest założycielem i senior consultantem firmy doradczo-szkoleniowej Code Sprinters. Wcześniej był między innymi Country Managerem Swisscom CEE (w Polsce pod marką Air Bites), a także menedżerem i konsultantem w 4pi, Unisys i T-Mobile Polska, jak też pierwszym redaktorem naczelnym „Linux+”.

  

Artykuł Nie stawiajcie Scruma na głowie! pochodzi z serwisu CRN.

Kiedyś było inaczej: dziesięć, a nawet jeszcze sześć lat temu o scrumie i agile chętnie mówiło się na konferencjach dla programistów, a oni sami stanowili dużą część uczestników szkoleń dla scrum masterów. Teraz trafiają się tam pojedynczo, a na blogach i konferencjach developerskich już się o agile pozytywnie nie mówi. Coś  się ewidentnie zmieniło w tym, jak programiści i testerzy postrzegają agile i scrum – i z czegoś ta zmiana wynika. Moim zdaniem z tego, że coraz częściej scrum jest czymś, co inni robią developerom, a nie czymś, co developerzy stosują, żeby lepiej działać.

Dzieje się zatem fatalna rzecz – scrum w szczególności, a agile w ogólności, odrywają się od swoich korzeni. Bo przecież obie te metody, które w swoich zrębach tworzono pod koniec ostatniej dekady ubiegłego wieku, powstały w zespołach budujących oprogramowanie, zmagających się z trudnymi projektami. I to nie w byle jakich zespołach, ale wysoce zmotywowanych, niewielkich i zgranych, złożonych z ludzi, którym zależało zarówno na powodzeniu produktu, jak i na dobrym rzemiośle. Agile – w znaczeniu zwinnych sposobów pracy – to zatem efekt organicznych wysiłków tych ludzi: programistów, testerów i pracujących z nimi bezpośrednio menedżerów. To tacy ludzie (zaangażowani i rozumiejący istotę pracy nad rozwojem oprogramowania) wypracowywali w boju praktyki i schematy, które później zostały ujęte w metodach takich jak scrum. Podobnie, to dyskusja nad tymi podejściami doprowadziła uczestników pamiętnego spotkania w lutym 2001 roku do zapisania pewnych wspólnych ich cech w tzw. manifeście agile.

Wiem to nie tylko z ich relacji, ale i z własnego doświadczenia. Wraz z moim zespołem dokładnie w taki właśnie sposób odkryłem agile. To znaczy najpierw pracowaliśmy w krótkich sprintach i tak dalej, bo to było rozsądne rozwiązanie w naszych warunkach, a dopiero potem dowiedzieliśmy się z książek, że to ma już nawet swoją nazwę.

Wyimaginowane problemy, narzucana metodyka

Dziś niestety coraz częściej scrum jest narzucaną odgórnie metodyką, wciskaną często bez sensu, w sposób nieprzemyślany. Począwszy od braku podziału na produkty (za czym powinna iść odpowiednia struktura zespołów), poprzez próby pogodzenia scruma i zwinności z silosową organizacją, stosowanie go jako best practice (co wiąże się z przymusowym sposobem pracy nawet tam, gdzie akurat nie ma on sensu), a skończywszy na kompletnym ignorowaniu faktu, że żadnego scruma nie da się zrobić, jeśli zespoły nie mają podstawowych narzędzi do pracy (sprawnych i szybkich komputerów, repozytoriów kodu, systemów testowych itd.) oraz – co najważniejsze – jakiejkolwiek motywacji do tego, by faktycznie pracować lepiej.

Co gorsza, Scrum Master i Agile Coach stały się osobnymi zawodami. To już nie są członkowie zespołu, którzy otrzymali dodatkowe zadanie dbania o jego rozwój i usprawniania jego pracy. Obecnie to są już osobni specjaliści, których umiejętności to facylitacja, otwarte pytania, „uwalniające struktury”, flipowanie, dawanie feedbacku  (dowiedziałem się ostatnio, że istnieją konkursy w dawaniu feedbacku!) – i którzy najczęściej nigdy w życiu nie programowali, w związku z czym kompletnie nie rozumieją, co tak naprawdę robią ludzie, z którymi pracują.

Ta sytuacja ma zresztą inne wymiary. Scrum Master, który nie umie czytać kodu, nie wie czym różni się funkcja od metody, nie wie co to repozytorium czy branch, nie tylko nie rozumie wyzwań jakie stoją przed zespołem, ale nie jest także w stanie efektywnie pomóc we wdrożeniu dobrych praktyk technicznych, bo najpewniej nie wie o ich istnieniu. Często także nie rozumie, jak istotne jest częste integrowanie i testowanie działającego oprogramowania. W efekcie zamiast na tym, żeby produkt działał, a kod był dobry, koncentruje się na dobrej atmosferze albo na zwalczaniu wyimaginowanych problemów (np. nierówności w zespole).

Niski poziom zaangażowania w pracę

Warto tu podkreślić, że nie chodzi o to, by skreślić każdą osobę, która, nie mając żadnej wiedzy technicznej ani doświadczenia, została Scrum Masterem. Zdarzają się i tacy, którzy pomimo to dobrze pracują ze swoimi zespołami (choć najczęściej, kiedy się przyjrzeć tym przypadkom, to wykonali jednak jakiś wysiłek, by lepiej zrozumieć, co zespół robi). Niestety, odkąd niemający pojęcia o programowaniu Scrum Masterzy stali się nie wyjątkiem a regułą, zaczęliśmy mieć problem. Właśnie ten problem, że scrum staje się czymś, co inni robią developerom… W dodatku ci inni nie mają pojęcia o tym, na czym w istocie polega praca developerów.

Połączenie tych dwóch elementów – wciskania na siłę, bez przemyślenia scruma oraz Scrum Masterów czy Agile Coachów, którzy nie rozumieją meritum pracy zespołów – to główne przyczyny, dla których tenże scrum w wielu miejscach nie działa. Inną ważną przyczyną jest ogólnie niski poziom zaangażowania ludzi w ich pracę. Jak już pisałem, scrum (i agile w ogóle) powstał wśród ludzi zaangażowanych w to, co robili – zarówno na poziomie rzemiosła, jak i zaangażowania w los produktu, który tworzyli. Przełożenie ich doświadczeń i wypracowanych przez nich metod na ludzi, których z produktem wiąże wyłącznie wypłata, a którzy rzemiosło (czyli jakość kodu i architektury) mają w głębokim poważaniu, okazuje się trudne (delikatnie rzecz nazywając).

Zatem zamiast zaangażowanych (a więc chcących!) programistów i testerów, którzy empirycznie wypracowują lepsze sposoby pracy nad produktem, na którym im zależy, mamy teraz coraz częściej zdemotywowanych programistów i testerów, którzy są zmuszani do udziału w „ceremoniach” – i to w dodatku przez „szamanów” niemających pojęcia o tym, co taki programista czy tester robią. Nic dziwnego, że im się to nie podoba. I nic dziwnego, że nie daje to obiecywanych efektów (a więc często wydawanego, działającego i wartościowego oprogramowania).

Róbmy swoje

Duch czasów – obowiązkowy optymizm – nakazuje zakończyć ten tekst jakimiś pozytywnymi wskazówkami lub propozycją wyjścia z problemu. Na tę chwilę jednak nie widzę tu żadnego rozwiązania, a więc czegoś, co mogłoby szybko i radykalnie poprawić sytuację. Pozostaje zatem robić swoje, a więc przede wszystkim szerzyć dobrą, solidną widzę o scrumie i agile wśród tych, z którymi mamy okazję pracować – dbać o to, by Scrum Masterzy dobrze rozumieli swoją rolę i dbali o to, by scrum był tym, co robi ich zespół, a nie czymś, co oni robią temu zespołowi. Ważne by mieli też zdrowy, a więc pragmatyczny stosunek do samej metody.

Trzeba także zmienić sposób kształcenia Scrum Masterów, biorąc pod uwagę fakt, że coraz więcej z nich nie ma pojęcia o programowaniu. Trzeba im zatem dostarczyć namiastki tego doświadczenia oraz przekazać wiedzę niezbędną, by mogli dobrze rozumieć zespoły i nawiązać z nimi merytoryczną komunikację. Innymi słowy Scrum Masterzy powinni poznać podstawy programowania – i to najlepiej nie ucząc się ich od swojego zespołu, już podczas pracy z nim. Jeśli nie mają nawet podstaw, będzie to dla zespołu frustrujące i spowalniające, o ile w ogóle zespół zechce podjąć się tłumaczenia tychże podstaw swojemu Scrum Masterowi. Lepiej zrobią to profesjonaliści mający doświadczenie w nauczaniu.

Andy Brandt  

Założyciel i senior consultant firmy doradczo-szkoleniowej Code Sprinters. Wcześniej był między innymi Country Managerem Swisscom CEE (w Polsce pod marką Air Bites), a także menedżerem i konsultantem w 4pi, Unisys i T-Mobile Polska, jak też pierwszym redaktorem naczelnym „Linux+”.

  

Artykuł Kryzys Agile pochodzi z serwisu CRN.