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.


Stworzyłem ebook o zarządzaniu projektami, analizie IT i startupach, który możesz bezpłatnie pobrać zapisując się na poniższą listę mailingową.


Na co dzień prowadzę fresh-apps.com.

Jeśli wpis ci się spodobał, udostępnij go lub śledź mnie na facebooku, twitterze, LinkedIn lub subskrybuj mój kanał na YouTube – twoja interakcja motywuje do dalszego pisania! Jeśli interesują cię podobne treści, dopisz się do newslettera (na górze strony) :).


Udostępnij

7 thoughts on “Dlaczego większość projektów prowadzonych jest Scrum?

  • 26 kwietnia 2017 at 13:48
    Permalink

    Scrum jest opisanym framworkiem (zespołem reguł, nie metodologią) i albo coś jest Scrumen albo nie jest, Jeżeli coś nie jest Scrumem, to trudno winić Scrum. Podobne dyskusje były w sprawie PRINCE2 ( to jest metodologia) ; ukuto wtedy pojęcie Prince tylko z nazwy (PON). Jak ktoś chce stosować własną firmową , to jest ok (np. IPMA dopuszcza takie rozwiazania; choć nie dale zupełnej dowolności; pokazując tz.. dobre praktyki), ale jak coś nie jest Scrum ani PRINCE2, to nie używajmy tych nazw. Jeszcze jeden problem, często o Scrumie i Prince (nie jest to zarzut do autora) wypowiadają się ludzie z bladym co najwyżej pojęciem (moim zdaniem ,żeby się wypowiadać, to warto mieć chociaż jakiś certyfikat tych organizacji, żeby mieć minimalną/brzegowa pewność, że wie o czym się mówi; choć posiadanie certyfikatów oczywiście nie daje nieomylności w tych sprawach). Wybór Scrum czy Prince2, sprowadza się do kwestii: czy metoda przyrostowa sprawdzi się lepiej w danej sytuacji czy kaskadowa? Coraz częściej, ze względu na okoliczności sprawdza się metoda przyrostowa, np. Scrum.Pozdrawaim

    Reply
    • 27 kwietnia 2017 at 09:31
      Permalink

      Dziękuje za komentarz – trafiony w punkt! 🙂

      Zgadzam się z tym, że jeśli nie robimy właściwych rzeczy we właściwy sposób to nie jest to problem narzędzi tylko kwestia niepoprawnego doboru lub użycia. Rozwijałem ten temat w tym wpisie: https://wojciszko.com/2016/02/22/scrum-nie-dziala/
      Nie jestem pewien czy certyfikat jest pewnikiem, że ktoś posiada wiedzę – moim zdaniem bardziej o tym by świadczyła np ilość zrealizowanych projektów w budżecie/na czas.

      Reply
  • 27 kwietnia 2017 at 09:35
    Permalink

    Niestety Scrum Scrumowi nie równy. Ciekawe jest to że piszesz o Scrumie który jako jedna z metodyk Agile podkreśla znaczenie samo-organizujących się zespołów, a z drugiej strony podkreślasz kluczową rolę jaką pełni kierownik/czka projektu. Myślę że jest to objaw większej choroby którą można zaobserwować w wielu dużych firmach. Otóż taka Firma zniesmaczona waterfall’em postanawia spróbować Scruma, w tym celu przeprowadza szkolenia, kilka osób dostaje dodatkową rolę “Scrum” mastera, pojawiają się stand-upy itp. Niestety firma podąża jedynie za literą Scruma a nie za jego duchem, który stawia na autonomie zespołów oraz ścisłą kolaboracje z biznesem. Kierownicy zespołów nadal stawiają na waterfall’owy tryb pracy, a więc nadal to nie zespół ale oni są odpowiedzialni np. za dotrzymanie terminów. Łatwo rozpoznać tego typu wypaczenie np. po tym że programiści, analitycy, testerzy są rozlokowani po innych pokojach, lub po tym że zespół jako całość nie ma kontaktu z klientem/biznesem. Taki Scrum to Scrum tylko z nazwy, Waterfall 2.0. Jest sporo firm które prowadzą niskiej jakości szkolenia które zaspokajają takie przejście na “Scruma” i tak wszyscy są zadowoleni, high level management bo ma “Scruma”, kierownicy niższego szczebla bo nadal mają kontrolę + “Scruma”, marketing, jedynie zespół może narzekać na dużą ilość “dziwnych” spotkań. Z punktu widzenia klienta – nie się pewnie w takiej firmie nie zmieni – nadal dostarczy ona niskiej jakości produkt…

    Reply
    • 13 maja 2017 at 07:35
      Permalink

      Ciekawie podsumowałeś – zgodzę się z tym – “taki scrum to scrum tylko z nazwy, to waterfall 2.0”. Żeby coś działało, trzeba wykonywać właściwe rzeczy, we właściwy sposób – często niestety albo dobranie metodologii jest nietrafione lub następuje jej niewłaściwe użycie.

      Reply
  • 30 kwietnia 2017 at 16:30
    Permalink

    już nie wspominając o tym że w prawdziwym scrumie nie ma takiej roli jak kierownik …
    jak masz kierownika to to nie jest scrum.

    Reply
    • 13 maja 2017 at 07:38
      Permalink

      Zazwyczaj jest jakiś PM, który odpowiada za cały “bałagan”. Podejrzewam, że chodzi ci o to, że kierownik projektu nie powinien być elementem scrumu.

      Reply

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.