Szacowanie, zaufanie i zero chaosu w organizacji

Na 89 spotkaniu Agile Warsaw Michał Nowostawski opowiedział o eksperymencie wykonanym w zespole programistów pracujących w grupie Allegro według reguł Scrum. W eksperymencie badano jak zmiana systemu rozliczania pracy wpływa na wydajność zespołu, jego zachowania i czas realizacji zadania.

Jak wiadomo w metodykach zwinnych często rozlicza się wykonaną pracę według czasu programistów. Rezultat zależy od tego jak dobrze Właściciel Produktu (product owner) określa co chce osiągnąć i jak dobrzy jest zespół. Scrum odwraca hierarchię, mamy X ludzi ile zrobią zależy od tego jak dobrzy są i jak dobrze pracują. Michał pokazywał doświadczenia z pracy w grupie Allegro. Wydaje się, że rozliczanie programistów według czasu pracy jest standardem w zespołach stosujących Scrum. Podobny system obowiązywał w centrum rozwoju aplikacji Nokia Semiens Network, o którego działaniu szerzej pisałem tutaj. Zarówno NSN jak i Allegro to duże organizacje zatrudniające kilkuset programistów. W Allegro działało około 50 zespołów po mniej więcej 10 programistów w każdym.

Eksperyment Michała miał początek w obserwacji pracy zespołu programistów przed świętami. Pomimo braków osobowych zespół zrealizował projekt w czasie wymaganym przez właściciela produktu. Pracował sprawniej niż zwykle bo zależało mu na punktualnym kończeniu pracy, wiadomo przed świętami nikt nie chce pracować po godzinach. Powstał pomysł sprawdzenia jak będzie pracował zespół w normalnych (nie przedświątecznych) warunkach jeżeli zamiast z czasu pracy rozliczać go z wykonania zadań i pozwolić na wcześniejsze zakończenie pracy jeżeli zadania wyznaczone na dany dzień zostały wykonane.

Kierownictwo Allegro wyraziło zgodę na eksperyment. W jednym (z 50 działających)  zespołów programistów wprowadzono czasowo zadaniowe rozliczanie pracy. Pierwszą ciekawą obserwacją była ogólna nieufność. Zespół obawiał się, że wynik eksperymentu będzie podstawa do podkręcenia norm pracy. Właściciel produktu sądził, że zespół będzie ograniczał zadania do wykonania w ramach sprintu żeby wcześniej wychodzić do domu. Najbardziej zainteresowany w przeprowadzeniu eksperymentu był chyba Scrum Master (Michał) i dlatego miał cierpliwość, dzięki której ugadał Właściciela Produktu (dobra, to nowy projekt nawet jeżeli jeżeli będzie obsunięcie to jakoś nadgonimy) i zespół (skoro kilka osób głosuje za to i ja też się przyłącze). Uwaga: twierdzenia w nawiasach to moje hipotezy co do motywacji uczestników. Ciekawa była też reakcja sali, która w eksperymencie upatrywała raczej podstępu kierownictwa i podzielała nieufność programistów. Może to i prawda, że w Polsce mamy powszechny brak zaufania budowany na bazie smutnych doświadczeń historycznych? Żeby ograniczyć ryzyko uczestników i innych interesariuszy uzgodniono następujące zasady eksperymentu:

  1. Eksperyment potrwa 3 tygodnie, w trakcie których odbędą się 3 sprinty.
  2. Sprinty planowane będą w ten sposób, żeby codziennie wytworzyć jakąś wartość dla Właściciela Produktu. Wartość rozumianą jako postęp prac, który może zobaczyć i ocenić.
  3. Zespół może wyjść wcześniej jeżeli wykona wszystkie zadania zaplanowane na dany dzień
  4. Nikt nie wychodzi z pracy dopóki wszystkie zadania nie zostaną wykonane.

Zespół uczestniczący w eksperymencie był dojrzały, miał za sobą około 2 lat wspólnej pracy i potrafił dobrze oszacować wartość zadania w Storypoint i ile pracy Storypoint wymaga. Średnia wydajność zespołu przed eksperymentem wynosiła 14-15 Storypoints na Sprint. Warto zwrócić uwagę, że zasady eksperymentu dzieliły ryzyko trochę niesymetrycznie. W związku z zasadą 4 zespół brał na siebie teoretycznie nieograniczone ryzyko. Wszyscy siedzą w pracy nawet jeżeli tylko jeden z członków zespołu ma problem. Jednak to był wspomniałem zespół był doświadczony i potrafił dobrze szacować pracochłonność poszczególnych zadań. Tabela poniżej pokazuje podsumowanie wyników pracy zespołu w poszczególnych tygodniach (sprintach). Dla każdego sprintu podano wykonany zakres prac liczony w Storypoints, najkrótszy i najdłuższy dzień pracy oraz łączny czas pracy zespołu w godzinach i minutach.

Sprint Storypoints Najkrótszy dzień Najdłuższy dzień Łączny czas
1 19 5:40 10:00 37:40
2 21 6:35 9:05 39:10
3 14 4:00 8:30 32:05

Wnioski z eksperymentu:

  1. Zespół przy nowym modelu pracy nie dążył do ograniczania zakresu, brał do wykonania więcej niż dotychczasowa średnia (14-15) punktów. W ostatnim Sprincie ustalono limit na przyjmowane Storypoints (14), zespół zrealizował zadanie w czasie 20% krótszym niż dotychczasowa średnia
  2. Głównym źródłem wzrostu produktywności było ograniczanie czasu traconego na wewnętrzną komunikację i interakcję z innymi zespołami. Przed eksperymentem wysyłano mail z prośbą o sprawdzenie kodu do innego zespołu a przy braku reakcji (raczej norma) proszono o interwencję Scrum Mastera. W nowym systemie pracy zamiast wysyłać maile programiści szli do zespołu, którego wkład był wymagany i prosili osobiście o wykonanie zadania. Stary metoda zabierała godziny, nowa kwadranse
  3. Nastąpiła spontaniczna organizacja ludzi wykonujących podobne zadania w pary szczególnie widoczna w przypadku programistów. Programowanie w parach uważane do tej pory za fanaberię Scrum Mastera zostało naturalnie przyjęte jako skuteczna metoda pracy w nowych warunkach
  4. Nie nastąpiła spontaniczna wymiana pomiędzy obszarami kompetencji w zespole. Nawet jeżeli tester pracował sam i cały zespół czekał na jego wynik żeby wyjść nikt nie kwapił się do pomocy. Być może zespół uznawał, że niewykwalifikowana pomoc szkodzi i wydłuża czas pracy.
  5. Nikt nie próbował naginać nowej metody i oszukiwać, nikt też nie czuł się oszukiwany. W nowej metodzie zespołowi nie podobał się brak przewidywalności na poziomie pojedynczego dnia pracy. Dłuższa praca dezorganizowała życie prywatne, z dodatkowy wolny czas nie zawsze dało się zagospodarować.
  6. Właściciel produktu w nowej metodzie cenił to, że zespół zmuszał go do precyzyjnego określenia oczekiwań co do wyników każdego dnia pracy co w sumie usprawniało realizację produktu.
  7. Nowy model rozliczania nie wpłynął na jakość wykonywanej pracy. Nie było pomysłów na to by zrobić gorzej ale szybciej. Pojawiło się za to dedykowana część planowania (30 minut), w trakcie której ustalano co można zrobić żeby zrobić to samo szybciej i wyjść wcześniej.

Organizacja nie zdecydowała się na szersze wdrożenie takiej metody pracy. Michał twierdził, że nowa metoda bardziej podobała się kierownictwu niż pracownikom, ale konserwatyzm zwyciężył. Być może obawiano się organizacyjnych komplikacji związanych z nową metoda rozliczania. Wszyscy członkowie zespołu uczestniczący w eksperymencie uznali, że gdyby wprowadzono zmianę w postaci maksymalnego dziennego czasu pracy np. 10 godzin wraz z możliwością przeniesienia części zadania na dzień kolejny to woleli by model zadaniowy rozliczania od zdefiniowanego czasu pracy. Oczywiście zadaniowe rozliczanie wymaga umiejętności oszacowania ile pracy dane zadanie zabierze a ta na ogół przychodzi z doświadczeniem zespołu. Co prowadzi do niezbyt odkrywczego wniosku, że dobry zespół osiąga znakomite rezultaty w przewidywalnym czasie niezależnie od sposobu rozliczania pracy. Dobry zespół pracuje dobrze bo tak chce. Moim zdaniem ciekawszym wnioskiem jest, że wyścig z czasem wynikający z nowej metody rozliczania prowadzi do spontanicznego przyjęcia nowych metod pracy (np, programowanie w parach, usprawnienie komunikacji, świadome planowanie usprawnień). Dobrym pomysłem było też wprowadzenie zasady, że zespół zaczyna razem i kończy razem, co uświadomiło ludziom, że ich sukces zależy w dużej mierze od pracy innych i dlatego warto dbać o skuteczną komunikację z tudzież pomagać sobie nawzajem. Oddanie kompetentnym ludziom władzy nad czasem, za który płaci organizacja nie tworzy chaosu lecz nową jakość.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *