Sytuacja kobiet w IT w 2024 roku
30.07.20218 min
David Pereira

David PereiraHead of Product Management

Czy to już rzeczywiście koniec Scruma?

Sprawdź, dlaczego Scrum staje się coraz mniej popularny wśród specjalistów, a nawet całych organizacji.

Czy to już rzeczywiście koniec Scruma?

Nie da się nie zauważyć, że Scrum jest niezwykle popularny — większość największych firm na świecie w pierwszej kolejności decyduje się właśnie na tę metodykę. Coś się jednak ostatnio zmieniło — wiele organizacji przestaje ufać Scrumowi. 

W wielu firmach Scrum jest zastępowany przez SAFe, Kanbana i inne metodyki. Oprócz całych organizacji, wielu niezależnych specjalistów również decyduje się na odejście od Scruma. Żeby tego było jeszcze mało, to wielu ludzi wstydzi się, że pracuje jako Product Ownerzy albo Scrum Masterzy. 

Rynek nastawia się na nowy kierunek — czy nadal będzie na nim miejsce na Scrum? Firmy chcą być zwinne, ale ciężko im wyrzec się starego stylu kontrolowania rzeczy. Porozmawiajmy trochę, dlaczego uważam, że to już koniec Scruma. 

Uwaga: treść tego artykułu jest oparta na moim własnym doświadczeniu i obserwacjach w przeciągu ostatnich 10 lat. Jeśli chcesz się podzielić swoją perspektywą, to gorąco Cię do tego zachęcam. 

Scrum nie jest procesem!

Rozwijanie oprogramowania to nadal coś nowego — pierwszy program pojawił się dopiero w 1948. Wydaje mi się, że Tom Kilburn nie wyobrażał sobie wtedy, jak świat pójdzie do przodu dzięki Software Developmentowi. 

Tom Kilburn jest odpowiedzialny za stworzenie pierwszego programu, który uruchomiono o 11 rano dnia 21 czerwca 1948 na University of Manchester w Anglii — Micah Yost, A Brief History of Software Development


Zanim nadeszło nowe millenium, firmom brakowało technik, dzięki którym mogli sprostać oczekiwaniom klientów. Większość organizacji skupiała się na ulepszaniu procesów wokół Software Developmentu. Pomimo istnienia takich metod, jak Rational Unified Process, jakość nadal była wątpliwa a klienci niezadowoleni. Tworzenie bezużytecznego oprogramowania frustrowało wielu ludzi — potrzeba było rewolucji. 

Pomimo że metodyki agile’owe takie jak Scrum i eXtreme Programming już wtedy istniały, to dopiero w 2001 roku, kiedy to pojawił się Agile Manifesto, podejście do tworzenia oprogramowania zmieniło się globalnie. Po tym wszystkim Scrum stał się najpopularniejszym wyborem. 

Biorąc pod uwagę sytuację, jak była na początku nowego milenium, to warto się zastanowić, czy Scrum rzeczywiście rozwiązałby wszystkie problemy z rozwijaniem oprogramowania? Warto by zrozumieć pierwotny problem, ale wiele firm ignorowało ten krok i decydowało się po prostu na znalezienie nowego procesu. I właśnie dlatego wiele organizacji nie skorzystało na Scrumie zbyt wiele. 

A podstawowym problemem nie był proces, tylko brak zwinnego myślenia. 

Jako przykładu użyjemy piłki nożnej — Barcelona wygrała 14 pucharów w ciągu 4 lat pod przewodnictwem Pepa Guardioli — od 2008 do 2012 byli najlepszym klubem piłkarskim na świecie. Wielu ludzi przypisywało sukces Barcelony sposobowi, w jaki Guardiola szkolił drużynę. 

Jednym z ważniejszych aspektów była dominacja piłki na polu gry - Barcelona często miała aż 70% posiadania piłki. Czy oznacza to, że styl gry Tiki Taka (polega on na szybkim podawaniu piłki i szybkich ruchach, co sprzyja jej utrzymywaniu przy sobie) będzie też dobry dla innej drużyny? 

Guardiola był również trenerem Bayernu Monachium od 2013 do 2016 — wykorzystał on ten sam styl gry dla niemieckiej drużyny. Sukces nie był porównywalny z sukcesem Barcelony - Bayern wygrał 5 pucharów narodowych, ale żadnego europejskiego. Wniosek z tego taki, że sam proces nie wystarczy, aby osiągnąć sukces - potrzeba czegoś więcej. 

Firmy, które podchodziły do Scruma jak do procesu, niestety poległy. Żadna metodyka agile’owa nie doprowadzi firmy do sukcesu bez bardziej znaczących zmian. Zanim firmy nie rozwiążą swoich problemów z funkcjonowaniem, to środowisko uniemożliwi wszystkim rozwój. 

Widziałem już w życiu wiele teamów Scrumowych, które kompletnie nie działały, ze względu na dysfunkcyjne środowisko. Największe dysfunkcje to: 

  • Brak zaufania
  • Brak jasno określonego kierunku
  • Ustalanie priorytetów w oparciu o stanowiska
  • Micromanagement


Jeśli firma nie rozwiązała problemów z funkcjonowaniem, to Scrum na pewno w niej polegnie. Jednak to Scrum będzie się za to obwiniać. A nie nadaje się on dla organizacji, które boją się zmian — bez tego nie można z nim odnieść sukcesu. 

Wielu zna na pamięć wszystkie role, wydarzenia oraz artefakty Scruma, ale zapomina o jego wartościach. Bez wartości, na których metodyka ta stoi, niemożliwym jest osiągniecie tego, co Scrum obiecuje Ci dać. 

Dlaczego Scrum może upaść? 

Scrum jest podobno prosty do zrozumienia, ale trudny do opanowania. Prawie wszyscy, których znam, zgadzają się z tym stwierdzeniem, ale ja polemizowałbym z prostotą Scruma. Kluczowy aspekt tej metodyki jest często ignorowany - spróbuj zapytać jakiś team, jakie są wartości Scruma. 

Pewnie zaskoczy Cię fakt, że prawie nikt ich nie zna. A są one bez wątpienia kluczowym aspektem tego podejścia.
 

Skuteczne użycie Scruma zależy od tego, czy ludzie będą działać w zgodzie z następującymi wartościami: oddanie, skupienie, otwartość, szacunek i odwaga — The Scrum Guide, November 2020


Gdy organizacje traktują Scruma jak proces, który należy zaimplementować, to z pewnością pojawią się problemy. Nieprzypadkowo Scrum jest niekompletny i żaden zespół nie będzie w stanie odnieść sukcesu bez dopasowania go do własnego zastosowania. Na przykład, Product Manager nie jest częścią Scruma, ale to kluczowe stanowisko, które zapewnia dostarczanie odpowiednich produktów. 

Aby odnieść sukces przy pomocy Scruma, organizacje muszę przejść masywną transformację. Niestety kadra kierownicza nie chce przystosowywać swoich środowisk firmowych, aby umożliwić teamom prawdziwy rozwój. Spotkałem się z następującymi paradygmatami w biznesie: 

  • Wzamacnianie zespołu kontra micromanagement
  • Rezultat kontra włożona praca
  • Dopasowanie się kontra konsensus 
  • Podejmowanie ryzyka kontra trzymanie się planu

Management wyższego stopnia wierzy, że posiadanie samo zarządzających się zespołów jest zbyt ryzykowne. I to właśnie dlatego Scrum odbił się od szklanego sufitu” — Willem-Jan Ageling, Scrum Has Hit the Glass Ceiling


Management wyższego stopnia często nie jest w stanie umacniać pozycji pracowników, ponieważ nie chce utracić kontroli. To właśnie dlatego wszyscy chodzą na skróty. Najpierw, zmień sposób pracy, a następnie, jeśli Scrum się sprawdzi, zmień kulturę —  to tak nie działa, a rezultatem tego wszystkiego jest frustracja. Gdy Scrum staje się procesem, to konkretne role przestają mieć sens. Pozwólcie, że podzielę się tym, czego się ostatnio nauczyłem. 

Product Owner

Bez odpowiedzialności za ustalanie priorytetów, Prodcut Ownerzy będą się zachowywać jak kelnerzy. Będą przyjmować zamówienia, sugerować dodatki i przekazywać zamówienie do kuchni. A bycie kimś od zbierania zamówień jest frustrujące — ich jedyna odpowiedzialność, to zarządzanie oczekiwaniami interesariuszy i zapewnienie komunikacji z developerami.

Niestety takie wypaczenie roli Product Ownera to bardziej reguła, niż wyjątek. Dlatego zastanawiam się, czy ktoś tak naprawdę może być Scrum Product Ownerem. Kiedy patrzę na swoją karierę, to wydaje mi się, że byłem blisko, ale nigdy nie miałem takiej mocy, jak w Scrum Guide. Moje pytanie jest więc następujące: czy Scrum Product Owner istnieje w korporacyjnym świecie? 

W ilu firmach Product Owner może tak naprawdę powiedzieć ostatnie słowo, jeśli chodzi o produkt? A nawet jeśli nie ma ostatniego słowa, to czy ktoś taki nadal jest Product Ownerem? Na rynku są setki pracowników, którzy twierdzą, że są Product Ownerami, a nie mają nic do powiedzenia w kwestii danego produktu — Maarten Dalmijn, Will the real Product Owner please stand up?

Jeśli chodzi o antywzorce, to zauważyłem, że wielu ludzi z odpowiednim nastawieniem do produktu traciło zainteresowanie swoją rolą. I pomimo że wiele firm nadal zatrudnia Product Ownerów, to tacy specjaliści czują wstyd, że ktoś ich tak nazywa. Marty Cagan uważa np., że Product Owner nie jest pracą, tylko rolą, a praca to coś więcej, niż to, co sugeruje nam Scrum. 

Developerzy

Developerzy to ci, którzy sami decydują o tym, jak wykonywać pracę — są oni odpowiedzialni za implementację rzeczy, którego stosu technologicznego użyć w projekcie itd. Pięknie to wygląda w teorii — w praktyce nigdy tego nie widziałem. Często firmy mają swojego CTO, Tech Leada, czy kogokolwiek innego, kto nie tylko podejmuje jakieś decyzje, ale też zarządza teamem developerów. 

Scrum zakłada autonomiczne zespoły developerów, ale czy tak naprawdę jest? Myślę, że w tym problem. Jest to dość smutne, ale większość developerów otrzymuje wytyczne, których musi się trzymać — nie są oni niestety zachęcani do pracy nad jakimś problemem bez deadline’u. 

Dotyka ich podobny problem, co Scrum Product Ownerów - prawdziwi Scrum Developerzy to fantazja. Tak naprawdę to specjaliści, którzy są zamknięci w fabryce funkcji. 

Scrum Master

Scrum Master to najbardziej pogardzana rola w Scrumie. Często spotyka się zespoły scrumowe bez Scrum Mastera, ponieważ firmy niechętnie kogoś takiego w ogóle zatrudniają. A nawet jak ktoś zatrudni Scrum Mastera, to nie daje im to żadnej mocy sprawczej.

W takim układzie Scrum Master jest skazany na porażkę, ponieważ nie będzie w stanie przeforsować zmian potrzebnych do rozkwitu Scruma. Mamy tu więc problem podobny do dwóch pozostałych ról — mało prawdopodobne jest to, aby znaleźć kogoś, kto byłby dokładnie taki, jak sugeruje nam Scrum Guide. Scrum Masterzy generalnie nic nie mogą.

Czy Scrum przetrwa? 

Wielu doświadczonych profesjonalistów jest zmęczonych Scrumem i straciło w niego wiarę. Chcą czegoś innego, więc szukają możliwości eksperymentowania z innymi metodykami.

Strach kadry kierowniczej przed zmianą blokuje prawdziwy rozwój zespołów scrumowych. Seria błędnych decyzji i nieporozumień może doprowadzić tę metodykę do jej końca. Management wyższego stopnia nie może dalej kierować organizacjami w nieadekwatnym stylu.

Jeśli rzeczywiście nastąpi koniec Scruma, to jego miejsce zajmie pewnie SAFe. Szczerze to obawiam się SAFe, ponieważ jest to ciężki proces i nie przypomina w żaden sposób zwinnego podejścia. Jak ktoś może w ogóle próbować zapamiętać, jak działa taka ciężka maszyna? Zastanawiam się, dlaczego ktoś śmie określać to mianem zwinnej metodyki.


SAFe 5.0

Scrum potrzebuje restartu, aby przeżyć 

Role Scruma nie są już tak czarujące jak kiedyś. Niewłaściwe postrzeganie Scrum przez wiele firm sprawia, że wielu specjalistów nie chce już z nim pracować. W scenariuszach, w których Scrum staje się procesem, ludzie nie chcą być Scrum Masterami ani Product Ownerami. Uważam, że Scrum potrzebuje restartu, jeśli ma być aktualny.

Żyjemy w innych czasach, niż 20 lat temu. W 2001 roku Scrum był nową i świeżą metodyką, ale świat się zmienił. Teraz Scrum stracił już tą wartość. Aby pozostał na czele, twórcy muszą wrócić do sedna metodyki i uważnie przyjrzeć się temu, co narosło przez lata. Niektóre z tych narośli mogą być dojnymi krowami - jak certyfikacje scrumowe. — Willem-Jan Ageling, Will Scrum Fall Victim to Its Own Success?

Niezależnie od tego, co się stanie, firmy, które są na tyle odważne, by zmienić podejście, mogą się naprawdę ze Scrumem rozwijać. Nigdy nie chodzi o zdefiniowanie procesu; chodzi o to, by mieć kulturę skoncentrowaną na wcześniejszym dostarczaniu wartości. Jest nadzieja, że niektóre odważne firmy mogą poczynić takie korki do zmiany, a znaki, po których można to rozpoznać, to:

  • Chief Product Officer staje się częścią kadry kierowniczej
  • Management wyższego stopnia koncentruje się na pokazywaniu kierunku zamiast przekazywaniu konkretnych instrukcji
  • Zespoły scrumowe mogą eksperymentować z różnymi alternatywami, aby osiągnąć kluczowe wyniki
  • Wdrożenie procesu Product Discovery. Menedżerowie wiedzą, że niezbędne jest poświęcenie odpowiedniej ilości czasu na znalezienie problemów, które warto rozwiązać.


Oryginał tekstu w języku angielskim możesz przeczytać tutaj

<p>Loading...</p>