Dlaczego większość projektów prowadzonych jest Scrum?

Rozwiązanie powinno zostać dobrane do problemu, niestety wielu kierowników projektów dobiera problem do rozwiązania – a czasami (co gorsza) nie dobierają, tylko stosują jedno rozwiązanie niezależnie od problemu. Mam wrażenie, że tak właśnie się dzieje z popularną ostatnio metodologią „Agile/Scrum” – jest użyta w każdym projekcie. 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 planowania projektu. To właśnie na tym etapie powinniśmy ustalić jaką metodologią poprowadzimy nasz projekt – w tym miejscu (niestety) wielu kierowników projektu odpowiada bez zastanowienia: Scrum! Jeśli źle dobierzemy narzędzia do rozwiązania naszego problemu to w większości przypadków przynosi 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 śrubokrętem 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 ją 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.  Więcej na ten temat możesz znaleźć w wpisie Scrum nie działa!. 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, analogicznie jest z pojęciem „chmura” w dzisiejszej technologii. 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. Negatywne skutki takiego działania opisałem w tym wpisie: Czy powinniśmy łączyć metodologie zarządzania projektami?. 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ż sytuację, że spotkania prowadzi kierownik projektu – wtedy daily scrum przeradzają 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ą racje. 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 szerszym spojrzeniem – 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 metodologi 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. Nie jestem przeciwnikiem tej metodologii, jestem przeciwnikiem bezsensownego używania rozwiązań w miejscach, w których nie pasują.

Pierwotnie artykuł napisałem na mamstartup.pl – tutaj znajduje się oryginalne źródło.