Największa wada Scrum

Nikt z autorów niniejszego bloga nie jest ewangelizatorem żadnej metodyki, ani tym bardziej Scruma, w którym w dodatku do niezliczonej liczby zalet widzimy wiele też wiele wad. Ponieważ zewsząd atakują nas głosy hurraoptymizmu, ostatnio nasze teksty i filmy starają się dodać nieco realizmu do tego obrazu i sprowadzić na ziemię bujających w obłokach. Dlatego dziś bierzemy na warsztat największą wadę Scruma, która zresztą wywodzi się właśnie z jego największych zalet.

 

Pod czas jednego ze szkoleń, które przeprowadzałem, dostałem bardzo dobre pytanie od uczestnika: „Dużo się mówi o zaletach Scruma. A czy mógłbyś określić jego wady?”  To pytanie jest świetne, bo demonstruje duży problem z postrzeganiem Scruma który wciąż mamy: że to jest przereklamowana, modna tabletka która niby rozwiązuje wszystkie problemy i którą próbuje się nam  wcisnąć. Tu od razu przychodzi na myśl książka „Jak robić dwa razy więcej dwa razy szybciej”. Stąd też powszechne wątpliwości co do zalet tego frameworku.

Jeśli chcemy, żeby nasza zwinna transformacja przeszła pomyślnie, każdy Scrum Master i Agile Coach powinien powtarzać ludziom, których szkoli, że Scrum – to framework, czyli sprawdzone narzędzie do konkretnych zadań, które jest dobre w tych zadaniach i nie do końca właściwe w innych. I trzeba to powtarzać, póki wszyscy tego nie zrozumieją.

Mimo, że to jest prawda, że Scrum nie jest dla każdego i że nie rozwiązuje on wszystkich problemów, to nie zgodzę się, że to jest jego największa wada. Nie jest to w ogóle wadą! Tak samo, jak wadą śrubokręta nie jest to, że nie nadaje się do otwierania wina. Jest to po prostu poza obszarem przeznaczenia tego narzędzia, a rozmawiamy o tych nie-wadach właśnie z powodu fałszywego wizerunku Scruma („dwa razy więcej dwa razy szybciej”).

Dlatego dziś chcę omówić realne wady narzędzia, którym jest Scrum, a nie jego błędne postrzeganie. A dokładniej chciałbym zgłębić to, co ja uważam za jego największą wadę.

Największą wadą Scruma jest to, że jego korzyści nie są darmowe. Płacimy za nie swoim stuprocentowym poświęceniem się.

Patrząc na scrumowe wartości, na samozarządzanie się zespołów, na ciągle ulepszanie produktu i sposobów pracy oraz na inne obietnice Scruma, możemy odnieść wrażenie, że to wszystko brzmi za dobrze, żeby być prawdą. I dla wielu ludzi właśnie tak będzie, bo wszystkie te aspekty są bardzo trudne w realizacji. Scrum jest bardzo trudny. Jego uczestnikom nie wystarczą same umiejętności twarde, bo konieczny jest też wysoki poziom odpowiedzialności, dyscypliny, empatii i pokory. Trzeba regularnie patrzyć w oczy niemiłej prawdzie, przyznawać się do błędów, znajdować słabe punkty we własnym rytmie i stylu pracy. Regularnie wychodzić poza swoją strefę komfortu.

Z punktu widzenia Developerów, samo zostanie kwalifikowanym programistą jest już nie lada wyzwaniem. Trzeba ogarnąć sporo wiedzy o języku oprogramowania i jego frameworkach, bazach danych, architekturze oprogramowania, Clean Code, itp. Trzeba mieć ciągłą praktykę w tych umiejętnościach, żeby ich nie stracić. A teraz okazuje się, że trzeba nauczyć się jeszcze wielu innych rzeczy, żeby być Developerem Zwinnym i też ciągle te rzeczy praktykować. Nic dziwnego, że niektórzy wolą Waterfall, gdzie mogą po prostu pisać kod, wykonywać to zadanie, które ktoś do nich przypisał i nie przejmować się niczym innym.

Z punktu widzenia Product Ownera czy interesariuszy Scrum też nie jest łatwy. PO musi rozwijać swoją wiedzę na temat produktu, propagować ją spośród Developerów, często podejmować trudne decyzje z którymi interesariusze lub Developerzy mogą się nie zgadzać. Interesariusze muszą nauczyć się pracować z PO oraz Developerami. Wszystkie strony muszą znaleźć sposób żeby radzić sobie z niezgodami oraz konfliktami które powstają w tym procesie, aby cała ta praca nie poszła na marne.

Lubię porównywać samozarządzające się zespoły zwinne do małych biznesów. Takie przedsiębiorstwa są bardziej skuteczne w wykorzystaniu własnych środków oraz zapewnianiu satysfakcji swoich klientów niż duże organizacje. Ze względu na to, że duża część producentów oprogramowania to właśnie duże firmy, Agile powstał jako rozumienie, jakie problemy i ryzyka z tego się wywodzą i jak je można wyeliminować. W dużym stopniu jest to naśladowanie tego, jak działają małe firmy.

Niestety, jest z tym wszystkim jeden problem. Każdego razu, jak wspominałem w swoich artykułach czy szkoleniach o tym, że Developer Zwinny powinien traktować produkt nad którym pracuje jako własną sprawę napotykałem sprzeciwienie ze strony Developerów. „Dlaczego mamy traktować to jako własny biznes skoro nie będziemy mieli odpowiednich zysków?” I nie ma w tym nic dziwnego. Ludzie instynktownie rozumieją, że przedsiębiorczość ma swoje ryzyka oraz wymaga większego poświęcania się. Jeśli potencjalny zysk się nie opłaca, to nie chcą się angażować. Czy znaczy to, że żeby działać w Scrumie firmy muszą zacząć płacić swoim pracownikom więcej? Odpowiedź na to pytanie w najlepszym przypadku wykracza temat tego postu, a może i moje kompetencje. Moim celem tu jest tylko zgłosić istniejący problem: Scrum nie jest darmowy, i jest bardzo trudny.

Artur Komendatskyi

5 lat doświadczenia w IT, PSM I-II, starszy inżynier oprogramowania, Scrum Master zespołów zwinnych

Click Here to Leave a Comment Below

Leave a Reply: