Artur jest naszym ekspertem od developerskiej perspektywy na Scruma. Zobaczmy więc, co w ogóle Developerzy mają z tego Scruma. Czy Scrum pomaga Developerom, czy wręcz przeszkadza?
To kolejny tekst z cyklu „Scrum i Developerzy”. Mówiliśmy już o tym, dlaczego Developerzy nie rozumieją Scruma oraz jak przedstawić Developerom Scrum w ich języku. Dziś pójdziemy jeszcze dalej i zobaczymy plusy i minusy scrumowego podejścia. Oczywiście, z perspektywy Developerów.
Jak Scrum służy Developerom?
1. Work-life balance
W czasach waterfallu przewlekłe nadgodziny na projektach były bardzo rozpowszechnione. Teraz takie projekty są wyjątkiem. To w dużej mierze jest zasługą filozofii zwinnej, która jasno mówi, że na dłuższą metę przepracowywanie doprowadza do pogorszenia jakości produktu.
Musimy pamiętać, że to, jak zespół będzie mógł pracować w dużym stopniu zależy od tego, na co zgadza się organizacja i/lub interesariusze – czyli strona, która płaci. A „pogorszenie jakości produktu” jest o wiele mocniejszym argumentem dla tej strony, niż „ludziom nie podoba się praca po 12 godzin dziennie”.
2. Usuwanie przeszkód
Wszyscy byliśmy w sytuacji, gdzie jakiś manager lub klient dręczy Developerów pytaniami o status jakiegoś User Story, które powinno być gotowe „na wczoraj”. Nierzadko zdarza się to podczas Daily (trwającego godzinę), co jest zupełnie niezgodne z zasadami Scruma. Do tego często jest to Story niedowiezione właśnie z tego powodu, że czas na pisanie kodu ukradziono przez uciążliwe spotkania.
Obowiązkiem Scrum Mastera jest usuwanie przeszkód na drodze do osiągnięcia Celu Sprintu (i Celu Produktu). Dobry Scrum Master zapewni, że nikt nie będzie przeszkadzał Developerom w tworzeniu Przyrostu. To nie tylko podniesie jakość produktu, ale też istotnie zmniejszy frustracje członków zespołu i szanse, że zaczną szukać innej pracy.
3. Lepsze relacje międzyludzkie
Nikt nie życzy sobie pracować w zespole, gdzie panuje wrogie nastawienie lub gdzie ludzie są mocno obojętni względem siebie. O wiele lepiej pracuje się z kimś, gdy mamy wspólne zaufanie i szacunek. Oczywiście, to jest możliwe również w waterfallu i każdej innej metodyce, ale w metodykach zwinnych jest to absolutnie niezbędne.
I nie chodzi tu tylko o kolegów z zespołu – innych Developerów. Scrum każe nam rozwijać relacje z klientem, a Product Ownerowi – zaufać Developerom i nie wtrącać się w ich proces roboczy za bardzo (patrz: punkt 2).
4. Prawo do popełniania błędów
Nie zawsze da wytworzyć coś w przewidzianym terminie. Powodów do tego może być wiele i nie zawsze są to niedbałość czy brak kompetencji. Czasem jest to po prostu wynik zdarzenia oczekiwań z rzeczywistością. Jak mówił Mike Tyson: „każdy ma plan, póki nie dostanie w twarz”.
W Scrumie zakładamy, że nie możemy wiedzieć wszystkiego z góry i powinniśmy być gotowi na porażkę. Jednocześnie, błędy i porażki są dla nas źródłem wiedzy, z którego powinniśmy czerpać. Jeśli wykorzystamy tę wiedzę, to będziemy mieli o wiele lepsze wyniki, niż przy walce z rzeczywistością bądź harowaniu po nocach (patrz: punkt 1).
5. Bardziej sensowna praca
Jest różnica pomiędzy robieniem czegoś tylko dla pieniędzy, a pracą nad swoim powołaniem lub misją. W pierwszym przypadku zaspokoimy tylko jedną ze swoich ludzkich potrzeb (materialną), w drugim zaś załatwiamy też wyższe szczeble hierarchii Maslowa.
Może rozwiązujemy problem, na którym nam mocno zależy z powodów osobistych? Albo zmieniamy świat według własnej wizji? A może po prostu tworzymy najlepszy produkt w branży i czujemy się z tego powodu dumni? Scrum wymaga poświęcania się i ludziom, którzy patrzą tylko na stronę materialną raczej nie będzie odpowiadał.
Jak Scrum przeszkadza Developerom?
1. Wymaga zespołu ekspertów
Scrum zakłada, że zespół Developerski tworzą eksperci, którzy najlepiej się znają na wykonaniu pracy nad produktem. Dlatego np. sami najlepiej potrafią wyestymować i zorganizować tą pracę. A co, kiedy mamy zespół składający się z Juniorów?
Wtedy może być problem, ponieważ przez brak doświadczenia zawodowego mogą nie być w stanie ani oszacować pracy właściwie, ani wykonać jej według wysokich standardów. Mają duże szanse na popełnienie takich błędów, które doświadczony specjalista łatwo może przewidzieć. „Świeżym” w temacie też może zabraknąć asertywności i z tego powodu nie będziemy mieli proaktywnego zespołu, co jest konieczne w zwinnej filozofii.
2. Wymaga dużego poświęcenia
Dużo ludzi nie rozumie Scruma, a wiele organizacji nie potrafi go wdrożyć z tego powodu, że skupiają się na jego powierzchniowych aspektach (Sprinty, Daily Scrum, itd.), a nie na bardziej głębokich – inspekcji i adaptacji, zaufaniu, samozarządzaniu, itp.
Musimy mieć zaangażowanie i empatię, żeby działać według tych wartości. Developerzy muszą rozwijać relacje z klientem, a jednocześnie dobrze dogadywać się między sobą. Management musi ufać Developerom i wspierać ich w przypadku powstania problemów. Kiedy mamy myślenie „5 Developerów = 5 maszyn do produkowania X Story Pointów na Sprint” oraz „jeśli któraś wyprodukuje mniej niż X, to znaczy że się nie wyrabia” nie możemy mieć zwinności.
3. Nie rozwiązuje wszystkich problemów
Scrum nie jest idealny czy wszechmocny. Nie sprawi, że wszystko się samo ułoży, a żadne problemy nigdy nie powstaną. Po prostu jest to dobre narzędzie do konkretnego celu, czyli organizacji pracy nad produktem. Przez lata istnienia Scruma mamy dowody, że tworzenie produktów w tej metodyce jest o wiele skuteczniejsze, niż w waterfallu. Na przykład wiemy, że Scrum pozwala obniżyć koszty sukcesu w 4 razy! A to już coś!
I co teraz?
Podsumowując: Scrum ma swoje mocne i słabe strony. Jest sprawdzonym narzędziem do rozwiązania konkretnych problemów. Wiedząc to, możemy stwierdzić czy odpowiada ono nam, czy też nie. Jeśli tak i zdecydujemy się na wdrożenie go, musimy wiedzieć, jak to zrobić poprawnie, żeby uzyskać korzyści. Powtarzam to kolejny raz, bo jest to najważniejsza rzecz, którą trzeba wiedzieć o metodykach zwinnych. Agile wymaga od wszystkich uczestników zupełnie innego podejścia, niż waterfall.
Jakie podejście i nastawienie wymagane jest od Developerów? O tym opowiem w kolejnym artykule.
