Zdjęcie główne artykułu pochodzi z picjumbo.com
W tym wpisie wyjaśnię, dlaczego kierownicy projektów nadużywają tej metodologii oraz poruszę kwestię negatywnych skutków takiej sytuacji. Zapraszam do lektury.
Ogromne znaczenie w realizacji projektu (na czas i w budżecie) mają czynności jakie podejmiemy podczas jego planowania. To właśnie na tym etapie powinniśmy ustalić jaką metodologią poprowadzimy nasz projekt – w tym miejscu (niestety) wielu kierowników odpowiada bez zastanowienia: Scrum! Jeśli źle dobierzemy narzędzia do rozwiązania naszego problemu to w większości przypadków przyniesie to negatywne konsekwencje.
Przeglądając strony internetowe software house’ów często widzę na nich slogan „Prowadzimy wszystkie projekty Scrum/Agile” – tak jakby to był wyznacznik jakości. Wyobraź sobie sytuację, że widzisz szyld reklamowy zakładu mechanicznego – „wszystkie śruby wkręcamy krzyżakiem”. Z jednej strony nie interesuje cię to, jakimi narzędziami usterka zostanie naprawiona – oczekujesz efektu końcowego, że auto będzie sprawne. Z drugiej strony co ze śrubkami z płaskim końcem? Ciężko będzie je wkręcić krzyżakiem
Tak samo jest z Agile/Scrum – nie wszystkie projekty nadają się do bycia prowadzone tą metodologią, w wielu przypadkach istnieją skuteczniejsze metody realizacji projektów. Nie zrozum mnie źle – nie jestem przeciwnikiem tej metodologii, jestem przeciwnikiem bezsensownego używania rozwiązań w miejscach, w których nie pasują.
Popularność Agile/Scrum
Agile/Scrum są popularne, tak samo jak pojęcie „chmura”. Jeśli coś jest „w chmurze” – to uznajemy za pewnik, że jest lepsze, bezpieczniejsze i bardziej elastyczne – nic bardziej mylnego. Wielu kierowników projektu dobiera właśnie tę metodologię do swoich projektów ponieważ są z nią oswojeni i wszędzie można o niej przeczytać, a każda firma chce być agile. Zjawisko to działa jak kula śnieżna – napędza się samo.
Agile/Scrum jest ciekawy
Scrum jest bardzo ciekawą metodologią, „dużo się w niej dzieje”. Mamy planowania sprintu, daily scrum, retrospekcję i podsumowanie. Sam podręcznik Scrum jest bardzo krótki – lakoniczne opisy elementów scrum sprawiają, że wydaje się być prosty. Natomiast według mnie jest to trudna metodologia, którą ciężko poprawnie zaimplementować, ale o tym później. Mam wrażenie, że wielu kierowników projektu wybiera właśnie Scrum ponieważ jest barwną metodologią, której mnogość elementów sprawia, że można ją ciekawie „sprzedać” m.in. klientowi.
(Złudne) poczucie kontroli
Scrum powinien być wykorzystywany przy projektach ze zmiennym zakresem (lub znanym tylko w krótkiej perspektywie czasu) – dlatego jest w nim mnóstwo spotkań, które są ogromnym pożeraczem czasu. Jeśli nasz projekt ma stabilny zakres – ta strata prędzej czy później obróci się przeciw nam. W związku z ogromną ilością spotkań zespołu – kierownik może mieć złudne poczucie kontroli – „bo skoro rozmawiamy codziennie będę szybciej wyłapywał potencjalne problemy i je rozwiązywał”. To niestety tak nie działa – (nawet dobrze poprowadzone) spotkania nie są profilaktyką przed wystąpieniem problemów. Nie wspominam o tym, że trudno przeprowadzić spotkanie w prawidłowy sposób, by wypłynęły z niego planowane korzyści.
Jak już wcześniej wspomniałem – trudno poprawnie zaimplementować scrum w projekt. Dlatego wielu kierowników projektu wybiera sobie tylko niektóre elementy tej metodologii. Częstym błędem jest mieszanie ról projektowych – bywa, że developer jest również scrum masterem. Dzieje się tak ze względu na to, że wszyscy żyjemy „w niedoczasie” i bywa, że brakuje zasobów, by przyznać dedykowanego scrum mastera do projektu.
Zdarzają się również sytuacje, że spotkania prowadzi kierownik projektu – wtedy daily scrum przeradza się w tzw. „konfesjonał”. Prędzej lub później dochodzi do tego, że cel takich codziennych spotkań jest zatracany i stają się spowiedzią dla programistów, ile zrobili poprzedniego dnia. Scrum wtedy traci sens. Mam wielu znajomych, którzy są w takiej sytuacji, którą opisuje. Jedni z nich otwarcie przyznają się do błędu i mówią, że kontynuują Scrum, bo chcą być konsekwentni, mimo że wiedzą, że ich sposób prowadzenia projektu ma już ze Scrum niewiele wspólnego.
Inni natomiast twierdzą, że to daje im „poczucie kontroli nad projektem” – moim zdaniem codzienne spotkania nie są w żadnym wypadku profilaktyką przed problemami. Rzadko zdarza się, że w projekcie jest „niedobór komunikacji” (niektórzy mówią „brak komunikacji”). Moim zdaniem częstszym przypadkiem są sytuacje, w których mamy nadmiar komunikacji w projekcie – wtedy komunikujemy się w niewłaściwy sposób. Zbyt częste spotkania tylko pogłębiają te problemy. Dlatego twierdzę, że codzienne spotkania dają złudne poczucie kontroli nad projektem.
Daily scrum – poranna prasówka dla kierownika projektu
Kolejną przyczyną cietrzewienia się na Agile/Scrum może być to, że jeżeli kierownik prowadzi np. daily scrum to tym samym dostaje codziennie informacje o projekcie (nie mylić z kontrolą nad projektem). To dla niego wygodne – taka poranna prasówka. Podejrzewam, że to może być powodem, dla którego ciężko odpuścić Scrum. Rezygnując z tego – będzie trzeba czerpać informacje o stanie projektu z innych źródeł, co wbrew pozorom może nie być takie łatwe jeśli chcemy się na to przestawić z dnia na dzień.
W związku z tym, że jedyny cel w takich spotkaniach widzi kierownik projektu – nie dostrzegają go inni uczestnicy spotkań (np. programiści). Często słyszę opinie od developerów: „ale o czym tu gadać przecież wszystko wiadomo” – mają rację. Dla programistów jest wszystko jasne i nie widzą celu takiego spotkania, co przekłada się na ich niechęć do uczestniczenia w cyklu scrum. Kierownik projektu nie patrzy na problem pod szerszym kątem – twierdzi, że skoro jemu te spotkania przynoszą korzyści to na pewno tak jest też z innymi członkami zespołu. Tak właśnie zataczamy błędne koło. Nie mówię, że posiłkowanie się informacjami na temat stanu projektu z daily scrum to coś złego – ale jeśli są organizowane tylko w tym celu to według mnie jest to bezsensem.
Podsumowanie
Powinieneś dobierać rozwiązanie do problemu, a nie odwrotnie. Decydując się na Agile/Scrum musisz pamiętać pod jaki typ projektu jest dedykowana ta metodologia. Pamiętaj, że częste spotkania mogą dawać złudne poczucie kontroli nad projektem – częste dyskusje nie są profilaktyką przeciw opóźnieniom, bardzo często to właśnie one je pogłębiają. Nie bój się zmiany metodologii jeżeli jesteś przekonany, że pierwotny wybór był nietrafiony (lub zmieniła się specyfika projektu).
Agile/Scrum jest trudną metodologią do implementacji w projekcie ć można popełnić wiele błędów. Największym błędem jest wybranie Scruma jako czołowej metodologii, która sprawdza się w każdym projekcie.
–
Karol Wójciszko
Założyciel Estee.me – platformy do wycen projektów IT. Na codzień bloguje na wojciszko.com, gdzie opisuje swoje doświadczenia i przemyślenia na temat zarządzania projektami IT i wykonywania analiz przedwykonawczych. Można go również znaleźć na YouTube.
