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.

Dziś zwinność to zupełnie co innego niż kilka tysięcy lat temu, kiedy nasi praprzodkowie, aby przeżyć następny dzień, musieli zapewnić sobie i swoim rodzinom pożywienie oraz schronienie. Musieli być dużo silniejsi od nas współczesnych, musieli być sprytniejsi, bo sztuki życia nie uczyli w szkołach i nie znane było pojęcie przystosowania do życia w rodzinie, nie wspominając o rolach społecznych. Musieli być zwinni, by w walce o kawałek mięsa polować i zabijać zwierzęta, wszak lepiej niż człowiek przystosowane do warunków ówczesnej egzystencji. Oni byli zwinni w tym podstawowym, tradycyjnym i rudymentarnym znaczeniu angielskiego słowa agile.

Zatem kiedy dziś mówimy, że coś, bądź ktoś jest agile? Wedle mnie określenie to jest mocno nadużywane w sferze marketingu przedmiotów, organizacji i ludzi, przy czym nie jest de facto niczym nowym, czego nie znalibyśmy wcześniej. Bo kiedyś mówiliśmy, że produkty są uniwersalne, czy wielofunkcyjne i łatwo się dopasowują do naszych potrzeb. Z tego punktu widzenia klasycznym produktem, jakbyśmy nazwali to dziś – agile, jest wieloostrzowy scyzoryk szwajcarski. Nie widzę innego pola eksploatacji tego pojęcia w odniesieniu do produktów, zwłaszcza materialnych.

Trochę inaczej jest z organizacjami. Organizacje dziś określane jako agile, to kiedyś były organizacje otwarte w sensie adaptacyjnym i zdolności przyjmowania nowości technicznych oraz technologicznych, elastyczne w swej strukturze i dobrze powiązane z rynkiem, aby szybko reagować na zmieniające się potrzeby klientów. I wreszcie ludzie agile… Czy to ma być jakieś nowe plemię ludzkie, plemię przyszłości? Czy nie istnieli wcześniej, zanim rozszerzono cechę zwinności na sferę intelektu i emocji? Otóż nihil novi sub sole. Tacy ludzie istnieli zawsze i to oni pchali świat, ludzkość i naszą cywilizację do przodu. To grupa (choć w przeszłości działająca w ogromnym rozproszeniu) innowatorów lub osobników zadających niewygodne pytania, trwających w swych przekonaniach odbiegających od standardów im współczesnych, często kwestionujących ogólnie przyjęte poglądy (że wspomnę słynne galileuszowe eppursi muove), a na koniec bacznych i bystrych obserwatorów otaczającego świata, zdolnych do wyciągania rewolucyjnych wniosków i tez (tu nasuwają mi się dwa nazwiska, z dwóch różnych dziedzin: Karola Darwina i Zygmunta Freuda). Na tym etapie śmiem sformułować tezę, że agility istniała zawsze, a popularność tego słowa wynika stąd, że odnosimy je dziś do bardziej zniuansowanych obszarów sfery i otoczenia, w którym działamy.

Teraz trochę o tym, czy agility to coś, co się kupuje, czego się uczy i czy to się dziedziczy. Otóż tego kupić nie można i chyba tu nie będzie głosów przeciwnych. Nawet, jeślibyśmy zainwestowali ogromne środki i kupili najbardziej elastyczne, nowoczesne i zaawansowane produkty, to będą one jedynie namiastką zaspokojenia naszej potrzeby zwinności. Aby być zwinnym zawsze, należałoby produkty kupować szybciej, niż jesteśmy je w stanie oswoić. A to zaprzecza sensowi celowości działania, bo kupujemy coś, aby tego używać, a nie, aby używania się uczyć, a potem wyrzucać i kupować coś bardziej agile. Klasycznym przykładem na tym polu może być zachowanie topowych użytkowników telefonów komórkowych jakieś 10 lat temu. Brak ugruntowanych standardów technologicznych, szalona konkurencja i możliwości implementowania w telefonie coraz to nowych użyteczności powodowały, że najbardziej oszalali i dysponujący odpowiednia kasą (swoją czy firmową) zmieniali telefony co miesiąc. Nie znaliście takich? Ba, ja kilku! Co warte podkreślenia – byli zawsze niezadowoleni z tego, czym dysponowali. Ciekawe dlaczego?

Nie da się zatem tego kupić, to może da się to wykształcić? Może. Nie wiem, nie próbowałem i raczej nie zalecam. Dlaczego? Bo generalnie nie wszyscy na świecie mogą nauczyć się mówić kilkoma językami obcymi. Nie chodzi mi nawet o pieniądze i czas, a raczej o zdolności i gotowość. Nie wszyscy są dostatecznie cierpliwi, zmotywowani (przykład Jana Himilsbacha z jego angielskim), czy zdolni mentalnie. Nie mówię tu o argumentacji w stylu Gogola z jego komedii „Ożenek”, kiedy swatka brak francuszczyzny u swatanej przez nią panny tak uzasadnia: „mówi po rosyjsku, bo to język od innych zrozumialszy, a i wszyscy święci po rosyjsku mówili”. Czyli z nauczaniem zwinności będzie kłopot, bo to nie jest wiedza, czy rzemiosło. To cecha osobowości, a te się raczej dziedziczy lub doskonali w długim procesie wychowania, dorastania i kształtowania osobowości. Tu nic nie da się zrobić i nic zmienić na chybcika.

Wnioski z tego płyną następujące: po pierwsze, na pewno zwinność jest cechą pożądaną i wartościową. Kształtuje się poprzez to, co dziedziczymy i jak jesteśmy wychowywani, a uwydatnia się i emanuje w środowisku, które jest na to przygotowane i promuje ten typ zachowania. Po drugie, współcześni headhunterzy to dobrze wiedzą i mając zlecenie na człowieka agile, takich elementów osobowości wśród kandydatów szukają. Ale wpadają w jedną pułapkę. Pułapkę zastawiają na nich zleceniodawcy, bo kupując proces rekrutacji ludzi zwinnych nie określają, po pierwsze, do czego ta zwinność ma służyć, a po drugie, czy oni sami są zwinni i czy już w organizacji istnieje wdrożony paradygmat zwinności. Bo zwinność to na przykład gotowość na akceptację popełniania błędów i pomyłek. Nie można być zwinnym łowcą nie mając blizn po kłach i pazurach wcześniej upolowanych zwierząt. Nie można skutecznie polować, kiedy zwyczaj firmy jest taki, że o 17:00 wszyscy zamykają swoje laptopy i udają się całkowicie w sferę prywatności tłumacząc swoje zachowanie koniecznością zachowania work-life balance. Nie będzie agility nawet z personalnie najzwinniejszymi osobnikami, gdy z każdym działaniem i decyzją trzeba udać się do najwyższego w organizacji czynnika, pytając go o zgodę.

A zatem zanim zaczniemy myśleć o przekształcaniu naszych firm i organizacji w te podobno dziś najsprawniejsze, czyli zwinne, zapytajmy samych siebie, czy jesteśmy na to gotowi? Czy tego naprawdę chcemy? Do czego ta zwinność będzie wykorzystana? Czy umiemy zwinność tolerować i jak określimy w naszej organizacji zasady checks and balances, aby nie osiągnąć statusu zwinnego bankruta? Fajnie jest dociągać do międzynarodowych standardów organizacyjnych. Fajnie jest brylować marketingowo i wizerunkowo w mediach czy świadomości ludzi nie bardzo zorientowanych w meritum jako zwinny menedżer. Tylko miejmy świadomość, że aby to było prawdziwe i skuteczne, muszą być najpierw wybudowane podstawy, czyli właściwy klimat organizacyjny i atmosfera pracy w naszych firmach. Bo inaczej będziemy postrzegani jako nadęci bufoni i więcej przyniesiemy szkody niż pożytku. Tym bardziej, że polskie środowisko biznesowe zajęte dziś jest czym innym niż zwinnością. Zdaje się, że nie zwinność będzie główną troską menadżerów i właścicieli firm w nadchodzącym czasie.

Dlatego też uważajmy, w co inwestujemy. A poza tym otwartym, miłym, sympatycznym, sprawiedliwym i rzeczowym warto być zawsze, nie tylko w biznesie, czy wobec przełożonych i podwładnych.

Artykuł Zwinność pochodzi z serwisu CRN.

Spółka wykona również prace związane z instalacją i konfiguracją infrastruktury technicznej oraz przeprowadzi integrację dostarczonego rozwiązania ze środowiskiem informatycznym klienta. Wdrożone rozwiązanie zostanie objęte dwuletnim okresem gwarancji. Zgodnie z postanowieniami umowy Symmetry będzie również świadczyć usługi utrzymania i rozwoju systemu przez okres 24- miesięcy. 

Warto podkreślić, że wdrożenie będzie realizowane w oparciu o technologię polskiego producenta oprogramowania – firmy P2ware. Oprócz Symmetry ofertę złożyła firma Enovatio.

Artykuł Poczta Polska wybrała Symmetry pochodzi z serwisu CRN.

Różnica w sposobie prowadzenia projektu wpływa na odmienne podejście do czasu, kosztów, budżetu, ryzyka i zarządzania przedsięwzięciem. Dlatego wymaga nowego formułowania umów IT. 

– Kontrakty Waterfall najczęściej nie skupiały się szczegółowo na sposobach realizacji projektu, poszczególnych rolach i ich wzajemnej korelacji, natomiast  dla kontraktów Agile te elementy są szczególnie istotne i decydują o powodzeniu projektu – tłumaczy Anna Serpina-Forkasiewicz, prezes firmy LegalHut. 

Radzi, by w umowie dotyczącej metodyki zwinnej zawrzeć precyzyjnie opisany przebieg postępowania w poszczególnych sprintach (sposoby dojścia do celu projektu), co następnie przekłada się na prawidłowe zdefiniowanie składowych projektu takich jak czas, koszty i zakres prac. 

Umowa powinna precyzyjnie określać poszczególne role projektowe, zakres ich praw i obowiązków oraz wskazywać konkretne obszary odpowiedzialności. Osoby odpowiadające za przygotowanie umowy muszą zadbać również o to, aby dokument zawierał szczegółowo opisany proces wytwarzania oprogramowania. Dobrze, jeśli jest on podzielony na krótsze odcinki czasowe. Dobrym rozwiązaniem jest uzgodnienie sposobów wyjścia z przedsięwzięcia, połączonych z właściwymi klauzulami określającymi rozliczenia partnerów w momencie zakończenia współpracy. 

Artykuł Jak prawidłowo formułować umowy IT pochodzi z serwisu CRN.