Scrum is the new waterfall

Scrum jest modelem wytwórczym, który dominuje na rynku projektów informatycznych. Jednocześnie zachowuje sztywne zasady i "najlepsze praktyki" znane z waterfalla. Nie zrównuję obu podejść, ale zwracam uwagę na to, że obie potrafią być nieefektywne - pisze Radek Smilgin.

 

METODA DLA METODY

 

W czasach gwałtownego rozwoju metodyk agilowych podstawowym zarzutem, czynionym wobec podejścia kaskadowego było to, że jest ono zbyt wolne, nie reaguje wystarczająco na zmiany, generalnie jest nieoptymalne w dostarczaniu oprogramowania. Powiedzenie komuś, że pracuje w waterfallu było formą obelgi, a przyznanie się do pracy w nim stanowiło synonim uskarżania się na własny los. Dziś podobną rolę zaczyna przyjmować Scrum, bo choć jest to najpopularniejsza metoda wśród podejść zwinnych, to jednak obarczona dużą liczbą sztywnych reguł, które nie zawsze pasują do kultury wdrażających ją organizacji. I choć dowolny konsultant promujący Scrum powie, że w takim razie musicie zmienić swoją kulturę to... jednak bez przesady! Kulturę pracy możemy zmieniać nie po to aby zaimplementować ”jakąś” metodę, ale raczej po to, by stać się bardziej efektywnym w osiąganiu celów biznesowych.

 

Scrum jest frameworkiem, opartym o proces empiryczny. Bazuje na 3 charakterystykach - przejrzystość, inspekcja i adaptacja. Można, a nawet trzeba wielokrotnie dostosowywać go do celów biznesowych.

Scrum jest metodą bardzo trudną do wdrożenia, a w wielu przypadkach nawet niemożliwą. Często w organizacjach istnieje wyłącznie na papierze i nie działa w zespole/organizacji. Dlatego pojawiły się pojęcia, które charakteryzują nieudane wdrożenia jak "water-scrum-fall", albo częściowe wdrożenia "scrumbut". W tym drugim - "but" jest polskim "ale" - mamy Scruma, ALE np. zrezygnowaliśmy z prezentacji wyników pracy dla odbiorcy produktu. Polemizujący ze mną w dyskusji o Scrumie Rafał Stańczak mówi:

W wielu przypadkach jest tak, jak mówisz, ale są również zespoły, które osiągają dzięki Scrum hiperproduktywność.

Mówi również, że ludzie rezygnują z pewnych założeń bo mogą nie rozumieć po co coś się robi i nikt nie pokazał im wartości z tego płynącej. Pyta:

Na ile winny jest tu Scrum, a na ile brak dyscypliny i bylejakość?

 

Odpowiadam, że trzeba się jednak zastanowić, czy ludzie mają dostosować się do metod, czy metody powinny być adaptowane przez ludzi.

Oczywiście nie piszę tego aby bronić waterfalla. Zakładam, że była to ważna metoda, jedna z pierwszych, która próbowała systematyzować pracę twórców oprogramowania. Ewolucje i zmiany jakie zachodziły pokazały, że pojawiły się próby jej uzdrowienia i zrównoleglenia działań, które mamy stosować. Tak powstał model V czy W i inne jego modyfikacje. Również autorzy Scruma wielokrotnie odchudzali Scrum Guide, by wyrzucić z niego wszystko, co w ich ocenie nie jest niezbędne. Zmieniali kilka razy zdanie względem konceptu, który pierwotnie stworzyli. Dziś jednak wiemy, że model kaskadowy jest ciągle skrajnie nieefektywny i niedopasownay do oczekiwań współczesnych odbiorców. Jest to raczej część naszej historii, do której możemy wracać jedynie po to, by spoglądać na błędy i wyciągać dziękim nim wnioski. Czy podobny los czeka również Scruma?

 

DANE

 

Stwierdzam, że Scrum zaczął powoli stawać się podobnym obciążeniem dla zespołów wytwórczych, jakim kiedyś był dla nich waterfall. Członkowie zespołów zaczęli narzekać na zbyt dużą liczbę spotkań, które odciągają ich od pracy, czy pozorowanie niektórych działań w imię dopełnienia ceremonii scrumowych. Do tego problematyczne stało się to, że choć koderzy, testerzy i analitycy zmigrowali się do zwinności, to managerowie ciągle tkwią w mentalnym waterfallu – przykładowo, do backlogu można wrzucić wszystko i w dowolnym momencie. Scrum stał się buzzwordem, który miał przykryć wysublimowaną formę manipulacji zespołami. Zwieńczeniem nieadekwatności Scruma jest również Continuous Delivery (CD), dla którego dostawy w 14 dni to o wiele za wolno...

W dyskusji Rafał Stańczak od razu zapytał o twarde dane na temat zadowolenia z metod. Bazuję jedynie na swoich obserwacjach i rozmowach z ludźmi. Zdecydowaliśmy się więc na ankietę (testerzy.pl i scrumdo.pl) o modelach wytwórczych. Wzięło w niej udział 234 osoby głównie testerzy i programiści.

Wyniki pokazały, że najwięcej ankietowanych uważa, że robią dopasowaną do siebie wersję Scruma (38%), a 30% przyznaje się do „właściwego” Scruma.

 

Z jednej strony pokazuje to dominację tej metodyki na rynku, ale z drugiej, że istnieje duża świadomość nierealizowania wszystkich wytycznych Scrum Guide. Prawdziwa patologia ujawnia się dopiero w kolejnym pytaniu. Tylko 10% ankietowanych uważa, że pracuje zgodnie z przyjętą metodyką.

 

W dalszej części zapytaliśmy o stosowanie w organizacji praktyki i poziomu satysfakcji z ich wdrożenia. Większość ankietowanych osób przyznało, że działają one OK. Wyjątkami było definiowanie wymagań, testowanie kodu i automatyzacja testów na interfejsie. W praktykach takich jak CI, CD czy spotkanie projektowe większość osób mówi, że realizowane są poprawnie.

Wnioski nasuwają się same. Większość projektów używa jakiejś formy Scruma, ale nie jest ona zgodna z wzorcem. Modyfikują praktyki pod siebie i są zadowoleni z otrzymanych wyników oraz z samych stosowanych metod wytwarzania oprogramowania.

 

JEŚLI NIE SCRUM TO CO?

 

Równolegle pamiętajmy, że Scrum ma bardzo wielu zwolenników i certyfikowanych konsultantów, którzy bronią go jak niepodległości. Nie chcą przyznać, że nadszedł czas by zostawić Scruma w jego podręcznikowej wersji tam gdzie zostawiliśmy waterfalla, czyli w historii informatyki. I trudno im się dziwić bo podcinaliby gałąź, na której siedzą. Niestety rozmowa z nimi często ma formę próby przekonania fanatyka, że może się mylić. Zwolennicy Scruma są głusi na argumenty i do swojej metody pracy podchodzą w sposób wręcz religijny - pewnie słyszeliście o ewangelistach? Prędzej czy później w polemice z nimi pojawi się znany z prawa Godwina [https://pl.wikipedia.org/wiki/Prawo_Godwina] argumentum ad waterfallum (od argumentum per hitlerum). Warto więc ostatecznie pozwolić im gotować się we własnym sosie i tkwić w przekonaniu, że jedynie oni mają rację, a cały świat zewnętrzny się myli.

 

Wychodzę z założenia, że słuchanie konsultantów Scrum, jako tylko jednej strony, jest błędem popełnianym przez zbyt wiele organizacji. Wyobraźcie sobie, że widzieliście świetną reklamę butów i myślicie sobie, że to obuwie mogłoby podnieść Wasz komfort chodzenia. Czy poszlibyście tylko do sklepu tej jednej reklamowanej firmy, by sprzedawca utwierdził Was w przekonaniu, że oto przed Wami są najlepsze dla Was buty? A może warto pójść do sklepu gdzie jest wiele butów i zapytać sprzedawcę jakie by polecił? A czy jeśli stać Was na naprawdę dużą inwestycję, nie wybralibyście się do szewca, który skroi buty do Waszych potrzeb? I tak powinno być z wdrożeniem każdej jednej metody prowadzenia projektów informatycznych. Nigdy nie powinniśmy płynąć z prądem, ale wybierać świadomie to, co jest najlepsze w danej chwili dla organizacji. Scrum zrobił wiele by zmienić mentalność i podejście do tworzenia oprogramowania. Nie powinniśmy jednak traktować go jako ostatecznego celu podróży, w poszukiwaniu docelowej metody pracy. Każda metodyka zwinna opiera się na tym, by dobierać metody i narzędzia najbardziej efektywne. Pamiętajmy też, że Scrum sam w sobie nie jest bardzo odkrywczy, bo składa się z elementów znanych już we wcześniejszych modelach. Można więc i z niego wyciągnąć kilka praktyk lub ceremonii, które u nas zadziałają i stworzyć z nich własną metodę tworzenia oprogramowania.

 

 

Dziękuję Rafałowi Stańczakowi za pytania, kwestionowanie moich założeń i wspólną ankietę.

 

Autor: Radek Smilgin

 

Inspirowane przez i polecane do zapoznania się:

 

Najbliższe terminy szkoleń

 

18-20 listopada - Katowice

ISTQB Poziom Podstawowy


20-22 listopada - Wrocław

ISTQB Poziom Podstawowy


20-23 listopada - Kraków

Dobry Przypadek Testowy - Laboratorium

 

Partnerzy

Narzędzia testerskie