Dlaczego Scrum nie jest metodyką?

Pracujemy w metodyce Scrum. Na pewno?

Spierający się pracownicy nie mogli dojść do porozumienia. Temat przerodził się w dowcip, zaczął krążyć po firmie i stał się źródłem wzajemnych docinków. Kulminacją  sporu okazało się spotkanie, na którym przedstawiciele różnych działów mieli ustalić  sposób i zakres współpracy. Dowcip o metodologii był już tak popularny, że wszyscy zebrani znali jego genezę. Nie zabrakło więc kąśliwych uwag o poziomie wiedzy tych, którzy używali słowa “metodyka” zamiast “metodologia” (lub odwrotnie).

W połowie spotkania nadszedł czas na prezentację pana X. Pan X, który po przeczytaniu wielu książek o teorii prowadzenia projektów informatycznych przodował w wytykaniu innym niepoprawnej terminologii, zaczął opowiadać, w jaki sposób jego zespół organizuje pracę. Wszystko szło dobrze do momentu, gdy pan X stwierdził, że pracują w zespole w metodyce Scrum. Pani Y momentalnie podłapała temat i skierowała przeciwko panu X jego własną broń. “A czy to nie jest aby framework, a nie metodyka?”

No właśnie, kolejny termin… To jak to w końcu jest?

Więcej niż zwykłe “ramy pracy”

Niejako na przekór powyższej historii nie zamierzam rozwiązać tu problemu nomenklatury, który w połączeniu z różnicami językowymi i tłumaczeniem z angielszczyzny tworzy mieszankę wybuchową. Myślę, że to wyzwanie bardziej dla profesora Miodka. A może problem najzwyczajniej nie istnieje i skupiamy się na rzeczach mało istotnych?

Zapomnijmy teraz o klasycznej terminologii. Od tej chwili będę rozróżniał tylko dwa terminy: metodyka (w uproszczeniu oznaczać będzie metodologię, metodę lub metodykę – możecie wybrać, co Wam bardziej pasuje) i framework.

Framework, tłumacząc wprost z języka angielskiego, oznacza “ramy pracy”. Metodyka natomiast jest zbiorem zasad, norm postępowania – zawiera pewnego rodzaju instrukcje lub sama w sobie jest dużą instrukcją. Skąd więc twierdzenie, że Scrum nie jest metodyką? Co powoduje, że – nie skupiając się zbytnio na samym terminie “ramy pracy” – odróżniamy Scruma od innych klasycznych metodyk tworzenia systemów informatycznych?

Scrum, owszem, zawiera instrukcje, ale nie ogranicza się do nich: skupia się także, a może przede wszystkim, na wartościach.

To stwierdzenie nie wydaje mi się przekłamaniem. Czytając Scrum Guide, można z łatwością zauważyć, że duży nacisk położony jest właśnie na wartości (tzw. The Scrum Values). Te wartości to:

• odwaga,
• skupienie,
• zaangażowanie,
• szacunek,
• otwartość.

Wspominają o nich nie tylko twórcy Scruma, ale także osoby, którym zawodowo “blisko” do Scruma. Sam również przekonałem się, że Scrum może działać lub nie i w dużej mierze zależy to od tego, czy zespół te wartości podziela.

Wartości w Scrumie

Scrum nie sprawdzi się (a przynajmniej takie są moje doświadczenia), jeśli zespół nie będzie miał wystarczająco dużo odwagi, np. do przeciwstawienia się zbędnej dokumentacji lub do pracy nad problemem, który wydaje się nie do rozwiązania. Każdy w zespole powinien mieć odwagę, by otwarcie stwierdzić, że robimy coś źle i można to zrobić lepiej, prościej, inaczej.

Samoorganizujący się zespół musi być również skupiony, bo dzięki temu ma szansę stworzyć nie tylko zaplanowaną funkcjonalność, ale również coś “ponad plan”, co w efekcie końcowym przyniesie dodatkową wartość dla użytkownika. Wydaje mi się to trudniejsze, niż wygląda na pierwszy rzut oka, a dobrym przykładem jest praca zespołu deweloperskiego. Skupiony na celu zespół, podczas tworzenia określonej  mechaniki potrafi “przy okazji” naprowadzić na inną, która zwiększa wartość projektu, a nie zdefiniowali jej ani użytkownicy, ani Product Owner. Brak skupienia może kosztować pominięcie istotnego elementu w projektowej układance. Skupiony na celu Product Owner będzie perfekcyjnie znał swój produkt, a dzięki temu ustalenie priorytetów okaże się prostsze i, co ważniejsze, bardziej trafne.

Wartości w Scrumie łączą się ze sobą i łączą także członków zespołu: wokół nich  tworzy się spójny zespół, który poradzi sobie z najtrudniejszymi wyzwaniami. Zaangażowanie łączy się ze skupieniem: żeby stworzyć coś lepszego, niż pierwotnie zakładano (a w gruncie rzeczy dlatego używamy Scruma) potrzeba ludzi, którzy są zaangażowani w pracę. Idealnie, jeśli utożsamiają się z tym, co robią i potrafią odnaleźć w tym sens. Zaangażowanie zespołu jest kluczowe w każdym projekcie IT.

Szacunek dla innych oraz dla ich pracy jest nie mniej istotny. To pewnego rodzaju “baza” dla wszystkich scrumowych wartości, bez niej cała reszta jest nieosiągalna: gdy w zespole panuje wzajemny szacunek, można stworzyć “ekosystem”, w którym wartości Scruma to coś więcej niż puste frazesy. Samoorganizacja może ucierpieć, gdy członkowie zespołu nie doceniają nawzajem swojej pracy, czasu i odrębności (indywidualizmu).

Zespół pracujący w Scrumie powinien być otwarty  i świadomy realiów, w których działa. Dotyczy to bieżących zadań, jak i wyzwań, które pojawiają się w projekcie. Wyobraźmy sobie zespół, który zmienia tryb testów: kończy z klasycznym testowaniem manualnym i postanawia spróbować np. Test Driven Development. Zmiana trybu pracy może potrwać i zanim przyjdą efekty, najpierw prawdopodobnie pojawi się lekkie spowolnienie. Tu właśnie niezbędna jest otwartość: pomoże zaakceptować zmianę oraz czas potrzebny na jej poprawne wdrożenie.

Scrum scrumowi nierówny

Wartości, które opisałem, z reguły nie są opisywane w metodykach. Z drugiej strony, można znaleźć wiele przykładów zespołów, które osiągają sukcesy dzięki współdzieleniu wartości, jak i równie dużo przykładów Scruma, który nie działa z powodu ich nieprzestrzegania. I jest to zapewne jedynie czubek góry lodowej niekończącej się dyskusji o metodykach, frameworkach i ich definicjach.

Dla mnie Scrum to znacznie więcej niż instrukcja. Oprócz opisu kroków wykonywania działań, dostrzegam również jego “warstwę psychologiczną”, związaną właśnie z wartościami. Powodzenie projektu zależy nie tylko od jego organizacji czy wiedzy technicznej członków zespołu: to solidne zaplecze, ale nie wystarczy, gdy zabraknie umiejętności miękkich. Czasami są pomijane, czasami niedoceniane. Według mnie, są nie do przecenienia.

Odwaga, skupienie, zaangażowanie, szacunek i otwartość. Przywołam je raz jeszcze na zakończenie, bo miałem przyjemność pracować z ludźmi, którzy te wartości dzielili. To oni byli często twórcami i pomysłodawcami najlepszych usprawnień, najbardziej przydatnych dla użytkowników końcowych wdrażanego rozwiązania. Jestem więc przekonany, że Scrum może działać jedynie w zespole, który respektuje powyższe wartości. Tylko taki zespół zamieni ogólne “Jako admin chcę zarządzać prawami użytkowników” w realną wartość. Planowanie co sprint ma sens jedynie, gdy zespół jest zaangażowany i chętny do tworzenia mitycznego “value”. Połączenie wszystkich elementów Scruma, takich jak sprinty, codzienne spotkania, ciągłe ulepszanie założeń, natychmiastowa informacja zwrotna od użytkowników – ta mieszanka zadziała, gdy zespół współdzieli nie tylko reguły i instrukcje, ale również idee i wartości.