Dlaczego Developerzy nie rozumieją Scruma? 

Dziś na naszych łamach po raz pierwszy mamy występ gościnny. Artur Komendatskyi opowiada o tym, dlaczego Developerzy nie rozumieją Scruma i czemu to nie jest ich wina! A to dopiero początek, Artur odgraża się, że ten tekst jest pierwszym w cyklu o Scrumie z punktu widzenia programisty. Zapraszamy!

„Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.” – Scrum Guide

Jak przypomina nam powyższy cytat ze Scrum Guide’a, dla otrzymania korzyści z tej metodyki konieczne jest jej zrozumienie oraz poprawne stosowanie. A w celu osiągnięcia korzyści przecież stosujemy ten framework, który powstał w celu ulepszenia procesu wytwarzania produktów, w tym oprogramowania. Jakie konkretnie są to zyski? O tym można by mówić bardzo długo, ale najczęściej wymieniane są zyski dla klientów lub organizacji. Często się zapomina, absolutnie niesłusznie, iż Scrum powstał z myślą o wszystkich uczestniczących stronach, w tym – o Developerach. A więc, co powinni zyskiwać Developerzy na stosowaniu Scruma i dlaczego w praktyce nie znajdują tych zalet?

Na początku swej kariery developerskiej nie wiedziałem o Scumie zbyt wiele. Słyszałem o dwóch różnych podejściach i koncepcji „Waterfall kontra Agile„. Ten pierwszy, nieskuteczny i przestarzały, miał skazywać zespół na lata wykonywania sztywnego planu, który ma ustalone terminy zakończenia poszczególnych etapów projektowania, wytwarzania, testowania, itp. Tego planu nigdy nie dało się wykonać na czas. Drugie podejście, modne i współczesne, rezygnowało ze sztywnego planu zalecało plan zwinny. Wszystkie wymienione przed chwilą działania miały odbywać się w krótkich odcinkach czasu nazywanych Sprintem.

Na rozmowie kwalifikacyjnej po której dostałem swoją pierwszą pracę w IT, były tylko dwa pytania dotyczące Scruma: czym jest Sprint oraz ile powinien trwać. To było mniej więcej wszystko, co wiedziałem wtedy o Scrumie. Scrum to kiedy pracujemy w Sprintach, mamy Daily Stand-up i tickety w Jirze – tak to widziałem. Oczywiście, będąc juniorem, zakładałem, że moja wiedza jest bardzo ograniczona i powinienem poszerzać ją, pracując z bardziej doświadczonymi ludźmi. Tak też się stało – w ciągu kolejnych 4 lat nauczyłem się od nich wielu rzeczy. Niestety, „edżajl” nie był jedną z nich, choć każdy projekt na którym pracowałem uważał się za scrumowy.

Typowe aspekty, które na tych projektach widziałem, to:

• brak samozarządzania dla zespołów – wszystko było narzucane z góry przez managera bądź team leadera
• Sprint jest traktowany jako „bardziej modna” nazwa zwykłego deadline’u – podejście pod tytułem „Za 3 tygodnie to musi być gotowe za wszelką cenę.”
• Manager zamiast Product Ownera – gdzieniegdzie przynajmniej istniało stanowisko PO, mimo że on lub ona zachowywała się jak zwykły manager; na innych projektach w ogóle brakowało tej roli

Na szczęście, trafiłem w końcu na projekt z prawdziwym Scrumem i po roku pracy znana już teoria połączyła się z praktyką. I tu właśnie się kryje to, co powoduje, że Developerzy nie do końca rozumieją, czym tak naprawdę jest Agile oraz Scrum.

Ludzie, którzy tak jak ja mają poniżej 10 lat doświadczenia w branży, raczej nigdy nie pracowali w prawdziwym waterfallu. Nawet te organizacje, które nie odważają się na porządne wprowadzenie Scruma wciąż zostały mocno ukształtowane przez filozofię zwinną. Można powiedzieć, że nie pracują już w waterfallu, ale i nie zostali jeszcze agile. Zatrzymali się gdzieś w połowie tej transformacji.

Agile Manifesto powstał 20 lat temu. W tych czasach nie były rzadkością ciężkie crunche, gdzie zespoły wyciskały 60-80 godzin pracy w tygodniu. I to wiedząc, że i tak nie uda się dowieźć projektu przed deadlinem! W 2001 roku zasady zwinne były rzeczą rewolucyjną. Dziś wydają się po prostu zdrowym rozsądkiem. Skoro to jest zdrowy rozsądek, to czego tu jeszcze można się uczyć?

A więc, młody Developer dołącza do firmy, która niby stosuje Scruma (w rzeczywistości jest to ScrumBut) i utrwala sobie, że to jak się tu pracuje to jest właśnie Scrum. Powiedzmy, że później sięga po teorię – Agile Manifesto, Scrum Guide lub jakieś kursy na Pluralsight. Wygląda to jako opis tego, co widzi w pracy. Raczej nie zwróci uwagi na różnice i niuanse. Bo ta teoria jest nudna, a on czy ona to wszystko już wie i w tym pracuje. Ten „edżajl” to po prostu zdrowy rozsądek i codzienność. Nie ma tu czego się uczyć.

I teraz możemy odpowiedzieć na to pytanie z tytułu postu. Po pierwsze, większość firm stanęła gdzieś w połowie pomiędzy waterfall, a agile. To powoduje brak środowiska, gdzie Developrzy mogli by uzyskać praktykę z prawdziwym Scrumem. Po drugie, kiedy uczymy się zwinnych frameworków, skupiamy się tylko na powierzchownych aspektach („pracujemy w Sprintach i mamy Daily”), a nie na tych głębokich: samozarządzanie, inspekcja i adaptacja, gotowość na porażkę, produkt zamiast projektu, etc. Po trzecie, nie wiemy, co jako Developerzy możemy zyskać, jeśli będziemy rozumieć Scrum oraz stosować go poprawnie.

O tym, jak to zrobić – jak pokazać Developerom korzyści płynące ze stosowania metodyki – opowiem w następnym poście. Jeżeli jednak już teraz macie jakieś pomysły bądź przemyślenia, podzielcie się nimi w komentarzu.