Blog
Niedawno pisaliśmy o tym jak wdrożyć Agile, artykuł Wojtka skupiał się na tym, czy (i kiedy) warto dostosować metodykę do swojej organizacji. Jednak przejście na Scruma, to nie tylko przeplanowanie harmonogramu spotkań i zmiana nazw stanowisk. Żeby Scrum działał skutecznie, kultura firmy musi być do niego dostosowana. Przejście z metod klasycznych na zwinne często wymaga ogromnej zmiany w sposobie myślenia wszystkich, począwszy od najwyższych szczebli zarządzania, a kończąc na pojedynczych członkach zespołów developerskich.
Niedawno spotkałem się z negatywnymi opiniami znajomych, odnośnie Scruma, porozmawiałem z nimi, wysłuchałem ich zarzutów i szybko zrozumiałem, że ich niechęć do metodyki wynika właśnie z doświadczenia “Scruma” wdrożonego w firmie, której kultura nie została na to przygotowana. Dla tego postanowiłem zamieścić tutaj krótki poradnik dla menadżerów, którzy zastanawiają się nad wdrożeniem Scruma w firmie stosującej do tej pory metody klasyczne.
Kontrola
Jeśli uważasz, że ludzie są z natury leniwi i trzeba ich kontrolować, żeby pracowali wydajnie, twoje wdrożenie Scruma prawdopodobnie się nie uda.
Największym problemem w zdaniu powyżej nie jest zakładane lenistwo programistów (o tym za chwilę), problemem jest ta „kontrola”. Jeśli jesteś przełożonym dowolnego zespołu developerów i uważasz, że skutecznie ich kontrolujesz… mam dla ciebie nieprzyjemną nowinę. Programistów nie da się skutecznie kontrolować.
Permanentna inwigilacja! (żródło)
Możesz przez 8 godzin, bez przerwy patrzeć im na ręce… poddani takiej kontroli, programiści będą pracować (przez kilka dni, zanim się zwolnią), ale nie sprawdzisz już w ten sposób czy pracują dobrze (jestem przekonany, że kod który powstanie pod taką kontrolą będzie bardzo złej jakości). Taka kontrola sprawdza się na linii produkcyjnej, ale nie w informatyce.
Programista może siedzieć bezczynnie z zamkniętymi oczami, wykonując równocześnie dużo lepszą pracę niż jego kolega klepiący bez przerwy w klawiaturę… ale może też drzemać, dowiesz się o tym dopiero gdy zacznie chrapać.
Programista przez godzinę serfujący po internecie może zdobywać wiedzę niezbędną do rozwiązania ważnego problemu (nawet najlepsi to robią)… może też czytać kawały, lub plotki z życia gwiazd, dowiesz się dopiero czytając mu przez ramię.
Gdy dwóch programistów rozmawia ze sobą w czasie pracy, mogą ustalać ważne detale architektoniczne twojego systemu… mogą też umawiać się na piwo, pewność uzyskasz dopiero podsłuchując.
Kontrolowanie developerów w taki sposób byłoby bardzo zajmujące dla ciebie i demotywujące dla zespołu, ale przede wszystkim szalenie nieskuteczne.
Metoda „ekspercka”
Jeśli masz więcej doświadczenia, prawdopodobnie potrafisz w przybliżeniu określić ile dane zadanie powinno zająć czasu, możesz więc próbować kontrolować programistów porównując ich wydajność względem twoich oczekiwań, to już rozsądniejsza opcja, ale również daleka od ideału. Praca programisty polega na rozwiązywaniu serii problemów logicznych od wysokopoziomowych, jak opracowanie architektury systemu, przez pośrednie, jak np. dokładne rozpracowanie wymagań i zamiana ich na algorytm, aż po podstawowe, jak znalezienie metody, która wykonuje niezbędną operację… i na każdym etapie może pojawić się problem, którego nie sposób przewidzieć.
Może być potrzebna dużo bardziej złożona architektura.
Wymagania mogą się okazać niekompletne, lub jakiś ukryty w nich drobiazg, może zamienić zadanie w techniczny koszmar.
Może też się okazać, że metoda wykonująca daną operację nie istnieje lub działa inaczej niż początkowo zakładałeś.
Problem komplikuje się jeszcze bardziej gdy trzeba zmodyfikować kod już istniejący, w którym mogą się pojawić całe masy niespodzianek. Sam byłem świadkiem jak zadanie oszacowane przez przełożonego na tydzień pracy jednej osoby, zmieniło się w trzy miesiące ciągłego rozwiązywania kolejnych problemów, przez kilku programistów. Stało się tak pomimo szczerych chęci i wysiłków realizatorów. Wiem, bo byłem jednym z nich.
W obliczu tak wielkiej niepewności praktycznie nie będziesz w stanie określić czy opóźnienie wynika z powodu faktycznych problemów, czy lenistwa.
Paranoja
Możesz też zignorować te wszystkie niuanse, profilaktycznie przyjąć, że każde opóźnienie wynika z lenistwa i uparcie popędzać wszystkich pracowników. Pominę w ogóle kwestię tego, jak takie podejście wpłynie na morale programistów. Zamiast tego zwrócę wspomnę o innym, często ignorowanym, problemie, któremu na imię dług techniczny. Presja i poganianie prawdopodobnie skłonią programistów do pójścia na skróty (lub do zmiany pracy), kod powstanie szybciej, ale będzie mniej czytelny, słabiej przetestowany lub trudniejszy do późniejszej zmiany. Z każdym, wrzuconym w pośpiechu, nieprzemyślanym rozwiązaniem, będzie musiała się zmierzyć następna osoba, modyfikująca ten sam kod w przyszłości. Taka technika może sprawdzić się przez chwilę, jednak na dłuższą metę, może być katastrofalna w skutkach.
Scrum porzuca iluzję kontroli, na której często opierają się firmy pracujące w klasycznych metodykach, na rzecz samoorganizacji i transparentności. Jeśli chcesz, żeby twoje wdrożenie Scruma powiodło się, musisz stworzyć warunki, w których mogą się one swobodnie rozwijać. Developerzy nie mogą się bać mówić o problemach czy nawet o własnych błędach.
Jeśli zaś chodzi o to czy programiści są leniwi, to myślę, że bywają leniwi, tak samo jak wszyscy ludzie, ale w odpowiednich warunkach nawet lenistwo potrafi być dobre! Przecież to właśnie lenistwo potrafi popchnąć programistę do szukania, co raz to lepszych i prostszych rozwiązań, najbardziej nawet złożonych problemów. Wystarczy by był on odpowiednio zmotywowany… a skoro już przy motywacji jesteśmy
Motywacja
Jeśli uważasz, że premie finansowe przekonają programistów do cięższej pracy, twoje wdrożenie scruma prawdopodobnie się nie uda.
Premia finansowa za dobre osiągnięcia, motywuje do jeszcze lepszych osiągnięć. To stara prawda, którą wielu menadżerów uznaje za świętą. Jeszcze nie tak dawno temu, ładnie można było to zaobserwować w świecie wielkiej finansjery, gdzie ogromne premie szły w parze z gigantycznymi zyskami dla banków… a potem wyszło na jaw, że podstawą tych osiągnięć były bardzo ryzykowne zagrania, a często nawet oszustwa, ze strony bankierów na każdym szczeblu i cały system rozsypał się niczym domek z kart. W tym wypadku obietnice dużych prowizji skłoniły pracowników do podejmowania działań, które na dłuższą metę zadziałały na szkodę firmy.
Jeśli zastanawiasz się jak nieostrożne zachowania bankierów mają się do pracy w firmach IT, przypomnę tylko wspomniany już wcześniej dług techniczny. Finansowo motywowany programista może dużo chętniej zaciągać dług techniczny, zamiatać wszelkie spowalniające go problemy pod dywan. To w sumie najprostszy argument, jaki przychodzi mi do głowy. Całą masę innych przykładów, przekonujących, że premie finansowe nie są odpowiednie do pracy wymagającej kreatywnego myślenia, znajdziesz też w książce Daniela Pinka pod tytułem Drive. Znajdziesz tam też propozycję innego systemu, opartego na motywacji wewnętrznej. Pink wymienia trzy filary tej motywacji jako samodoskonalenie się (mastery), autonomię i poczucie celu.
Zgodnie z teorią przedstawioną w tej książce, możesz zyskać developerów, pracujących nie tylko wydajniej, ale przede wszystkim lepiej, dbając o następujące obszary w twojej firmie:
Samodoskonalenie
Zapewniając pracownikom przestrzeń do samodoskonalenia się zwiększysz ich zadowolenie z wykonywanej pracy. Wpłyniesz też pozytywnie na wydajność. Nie musisz zresztą robić w tym celu zbyt wiele. Nie musisz, na przykład, organizować szkoleń, czy wysyłać ludzi na branżowe konferencje (choć to też nie zaszkodzi). Ważniejsze jest stworzenie warunków, w których poziom trudności kolejnych wyzwań, będzie przypominał schody, po których twoi programiści sami mogą się wspinać, zamiast toru przeszkód, na którym co rusz natrafią na wysokie ściany lub głębokie przepaści. W idealnym przypadku pracownicy nie powinni być przytłoczeni problemami przerastającymi ich o głowę, ani znudzeni problemami niewymagającymi myślenia.
W Scrumie członkowie zespołu samodzielnie decydują o tym, jak rozdzielić pomiędzy siebie zadania sprintowe. Daje to dodatkowe pole manewru, które pozwala wybrać prostsze zadania mniej doświadczonym developerom, a trudniejsze problemy osobom spragnionym wyzwań. Na tym zresztą wachlarz możliwości się nie kończy, bo np. zespół może zdecydować, że problemy zbyt trudne, których nikt nie chce podjąć, będzie „atakować” parami (pair programming), a zadania zbyt monotonne, których nikt nie chce wykonywać (ale które i tak muszą zostać zrobione), będą przydzielane losowo (rotacyjnie, tak żeby nikt nie został na stałe „człowiekiem od brudnej roboty”). Możliwości są praktycznie nieograniczone.
Autonomia
Dając pracownikom autonomię, zwiększasz ich zaangażowanie. Dużo łatwiej jest się utożsamiać i czuć odpowiedzialność za produkt, na którego powstawanie ma się realny wpływ. Specjalista pozbawiony autonomii jest traktowany, jak bezmyślne narzędzie i często tak właśnie się zachowuje.
Scrum zapewnia autonomię na kilku poziomach. Członkowie zespołu developerskiego mają ograniczoną autonomię względem produktu, który rozwijają. Nie mogą co prawda decydować, które funkcjonalności zrealizują w sprincie – to rola PO. Mogą jednak decydować, jak należy je zrealizować i mogą mieć realny wpływ na ich wygląd. Przede wszystkim jednak, zespół Scrumowy ma autonomię względem organizacji własnej pracy. Może on, w sposób prawie dowolny, dostosowywać Scruma do własnych potrzeb. Autonomia zapewniona przez Scrum jest na tyle duża, że zespół może nawet zdecydować o… stosowaniu wewnętrznie metodyki innej niż Scrum… choć w tym przypadku, zalecałbym w pierwszej kolejności sprawdzenie mniej drastycznych środków.
Poczucie celu
Samodoskonalenie i autonomia same w sobie mogą zrobić sporo w dziedzinie motywacji. Jednak aby utrzymać ją na wysokim poziomie, na dłuższą metę, pracownikom potrzebna jest świadomość, że to co robią ma sens. Że w jakiś istotny sposób przyczyniają się do osiągnięcia większego celu. Sam cel nie musi być niczym bardzo wyniosłym. Pewnie, odkrycie lekarstwa na raka, czy likwidacja głodu na świecie, zmotywowałaby znacznie lepiej niż „obniżenie kosztów sprzedaży produktu o 2%”, ale jeśli tylko pozwolisz pracownikom utożsamiać swoją pracę z sukcesami firmy, nawet ten drugi cel potrafi pomóc. Poczucie celu jest niezbędne, żeby developerzy mogli na prawdę włożyć w swoją pracę serce.
Na temat metod motywacji, skuteczniejszych niż premie i nagrody, pisać można bardzo wiele. My sami poruszaliśmy ten temat już w artykule Pasja czy zaangażowanie – jak przyciągnąć i utrzymać najlepszych. Wnikliwych odsyłam też do wspomnianej już książki Daniela Pinka „Drive: The Surprising Truth About What Motivates Us.
Podsumowanie
Powyższe uwagi oparłem głównie na własnych obserwacjach. Błędów popełnianych w tym zakresie na pewno jest znacznie więcej (jeśli spotkaliście się z nimi osobiście, podzielcie się proszę przykładami w komentarzach). Próbując wdrożyć Scrum w firmie, której kultura nie jest do tego dostosowana, często kończysz z hybrydą mniej skuteczną niż prawdziwy Scrum, a czasem gorszą nawet od metodyki, od której zacząłeś. Cierpi na tym nie tylko twoja firma, ale też postrzeganie Scruma, który przez „ofiary” takiego wdrożenia jest później utożsamiana, nie z tym czym być powinien, lecz z chimerą, którą dane im było obserwować. Takich ludzi dużo trudniej jest potem przekonać do ponownej próby.
