Obsesja Velocity i jej skuteczna terapia

Jeśli istnieje jakieś słowo, które w zwinnym świecie wywołuje skrajne emocje, jest zarówno policzalne, jak i niepoliczalne, wyrażone liczbą, ale nieporównywalne, kochane przez managerów – tolerowane przez wszystkich innych i wreszcie – pożywne i toksyczne jednocześnie, jak ryba Fugu lub Zenek Martyniuk – to jest nim Velocity. Jestem pewien, że to właśnie słowo jest przyczyną wielu nieporozumień, konfliktów i wypaczeń w implementacji zwinnego podejścia. 

Mówiąc o wypaczeniach: przychodzi do Was Manager i pyta: jak tam wasza PRODUKTYWNOŚĆ, towarzysze? Pokażcie prędko wasze VELOCITY. Dlaczego macie MNIEJ niż w ubiegłym miesiącu? Dlaczego macie mniej niż TEN DRUGI ZESPÓŁ?
Jeśli czujecie, że w każdym zdaniu tkwi pułapka, to macie rację. Jak zareagować? Jak rozbroić taką bombę? Potrzebna będzie wiedza, odpowiedni dobór słów i alternatywne rozwiązania dla szukającego agile’owej bójki Managera. 

Co to jest Velocity? Ogólnie mówiąc, jest to liczba, która mówi o tym, jaki wynik zespół osiągnął na koniec sprintu. Najczęściej mówimy o sumie wartości w Story Pointach tych historyjek, które spełniły DoD. Zdarza się, że zespoły wliczają do Velocity tylko historyjki mające wartość biznesową. Zdarza się też, że wliczają bardzo szerokie spektrum historyjek – w tym improvementy, defekty, spike’y i owocowe czwartki. Najważniejsze, aby konsekwentnie trzymać się swojej definicji przez jakiś czas, bowiem Velocity to wartość empiryczna, tworzy trend z przeszłości i to ten trend bywa najbardziej przydatny. Do czego? Zwykle do planowania kolejnego sprintu lub serii sprintów. Czasami zespoły wyciągają średnią kroczącą za ostatnie kilka sprintów, czasami mówią: nasze Velocity nigdy nie było mniejsze niż X i większe niż Y, więc w tych granicach każda wartość jest dobra. Można też powiedzieć, że Velocity ma pewne odchylenie standardowe, więc nie można mówić, że Velocity = X tylko raczej Velocity = X±y. Zatem Velocity to de facto przedział, a nie liczba bezwzględna, o czym zapominamy zadając pytanie typu: dlaczego w tym sprincie Velocity było 10% mniejsze? Jeśli nie wiemy, jakie jest odchylenie, to te 10% może mieścić się w granicach błędu i powyższe pytanie nie ma żadnego sensu. A jakże często pada! 

Wiedząc, czym jest Velocity, czy można na tej podstawie oceniać Produktywność zespołu? Każdy przynajmniej raz doświadczył sytuacji, w której zespół ofiarnie pracuje w sprincie, czasem po godzinach, cudem jeszcze domyka końcówkę i co? Pada pytanie: dlaczego tak mało? Niejeden zespół odczytuje to, jako: dlaczego się obijacie? A mówiąc formalnie: dlaczego macie taką niską Produktywność?
Co to jest ta Produktywność w świecie wokół nas? Można powiedzieć, że jest to stosunek ilości wytworzonej produkcji do zasobów wejściowych. Zatem dla tych samych zasobów wejściowych w dwóch identycznych systemach ten, który dostarczy więcej, ma wyższą produktywność. Proste! Jeśli wyobrazimy sobie dwie linie produkcyjne biszkoptów, dwóch grabarzy kopiących doły lub dwie baterie zasilające króliczki, mamy pełne zrozumienie, czym jest Produktywność. Jak przełożyć to na software development? Prawdopodobnie systemem jest zespół scrumowy oraz sam produkt, zasobami jest czas sprintu, komputery, kawa w kuchni (aktualnie domowej, bo pandemia) oraz wymagania, zaś produktem końcowym jest przyrost działającego oprogramowania, często innowacyjny i niepowtarzalny. Mierzony poprzez Velocity. I tu zaczyna się katastrofa. Jeśli w styczniu naprawialiśmy defekty osiągając Velocity = 100, a w sierpniu dołożyliśmy 10 innowacyjnych funkcjonalności osiągając Velocity = 90, to kiedy byliśmy bardziej produktywni? Jeśli w sierpniu zamiast Agnieszki dołączyła Magda i jej 20 lat doświadczenia, to kiedy byliśmy bardziej produktywni? Jeśli w styczniu pracowaliśmy w biurze, a w sierpniu już hybrydowo, to kiedy byliśmy bardziej produktywni? Jaki jest sens mówić o produktywności, skoro nawet osiągając identyczne Velocity ani system, ani produkt, ani okoliczności jego powstania nie były do siebie podobne? A co dopiero, kiedy Velocity byłoby różne?

Można więc zadać sobie pytanie, czy praca twórcza o charakterze złożonym, często niepowtarzalna, wykonywana w zmieniających się okolicznościach może być określana słowem produktywna? Według mnie absolutnie nie. Dodatkowo, w pracy o takim charakterze często nie optymalizuje się kosztu na pierwszym miejscu. Istnieją inne wyzwania, takie jak ryzyka techniczne, zbyt rzadkie dostarczanie, niestabilne komponenty 3rd party – wszystkie one nie poddają się optymalizacji kosztów. Wysoka produktywność nie rozwiąże wielu znanych problemów przy wytwarzaniu oprogramowania. Dlatego termin produktywność najlepiej sprawdza się przy powtarzalnych, wysoko kontrolowalnych procesach wytwórczych o charakterze prostym lub skomplikowanym, ale nie złożonym w ujęciu Cynefin.

Skutki upartego dążenia do produktywności w świecie IT mogą być złe. Wyobraźmy sobie, że chcemy, aby deweloperzy pisali jak najwięcej linii kodu na godzinę (były zresztą takie miary). Dużo linii, to potencjalnie dużo defektów, dłuższe review pull requestów i tak dalej. Czy o to nam chodziło? Presja na wysokie Velocity z kolei może prowadzić do nieskończonych historyjek (niektórzy ze strachu dzielą historyjki na PART1 i PART2, byle tylko coś zaliczyć na koniec sprintu). Czy o to nam chodziło? Dodatkowo, znane są przypadki zawyżania Velocity przez wrzucanie tam różnych zadań, które zespół wykonał, niektórych naprawdę absurdalnych, np. udział w szkoleniu BHP itp. Tak kończy się często presja na ciągłe wzrosty Velocity i utożsamianie jej z Produktywnością. 

Jeśli więc nie Produktywność, to co w zamian? Najnowszy Scrum Guide wskazuje na odpowiedzialność Scrum Mastera za Efektywność zespołu, nie tłumacząc przy tym niestety, czym ona jest. W zamian dostajemy bardzo dużą elastyczność tej definicji, z której możemy skorzystać już teraz. Na początek załóżmy, że odchodzimy od mierzenia Velocity w Story Points, a jedyne co robimy, to zliczamy sztuki zamkniętych (ukończonych i odebranych przez PO) historyjek. Czym to w zasadzie się różni od zliczania Story Pointów? Otóż liczenie sztuk ma kilka niepodważalnych zalet i stosowane jest powszechnie również w mojej firmie:

  • Kieruje uwagę organizacji na dostarczanie Wartości (skojarzonej z każdą historyjką) zamiast dostarczania punktów
  • Zachęca do definiowania małych historyjek, bo liczą się tak samo, jak te duże, a można je szybciej zakończyć 
  • Upraszcza proces planowania
  • Utrudnia (szkodliwe) porównywanie między zespołami

Zaraz, zaraz, zapyta ktoś – jak można liczyć sztuki, skoro historyjki różnią się wielkością?! Nie umiemy zdefiniować wszystkich historyjek w tym samym rozmiarze, więc dochodzi tutaj do przekłamań. Z moich obserwacji wynika, że każdy sprint to dość losowa mieszanina historyjek małych, średnich i dużych, z czego najwięcej jest tych średnich. Myślę nawet, że ta mieszanina podlega pewnemu rozkładowi, np. Normalnemu. Przy większej liczbie historyjek typu 20+ liczenie sztuk ma sens, bo każdy sprint ma z grubsza podobne proporcje tych rozmiarów, które przy tej liczbie historyjek już widać. Na dowód słuszności tej tezy, zamieściłem poniżej dwa przykłady dużych organizacji, które zliczają sztuki historyjek. Warto zauważyć, że sumowanie wszystkich zespołów z tej samej organizacji na jednym wykresie, daje zaskakująco przewidywalne wyniki Velocity, pomijając 1-2 sprinty, kiedy coś dziwnego się wydarzyło.

Czy zliczanie sztuk wystarczy, aby określić Efektywność? Albo inaczej, czy pokazywanie, ile Wartości dostarcza zespół, daje dobry obraz Efektywności? Chyba nie. Dlatego równolegle można dołożyć drugi wymiar Efektywności: szybkość dostarczania historyjek, który zresztą widać na powyższych wykresach słupkowych. A zatem w każdym sprincie pokazujemy nie tylko ile sztuk historyjek ukończono, ale też jak długo trwał ich cykl życia, od umownego stanu początkowego (np. InProgress) do umownego stanu końcowego (np. Completed). Pokazywanie cyklu życia ma przynajmniej jedną, niezaprzeczalną zaletę: zachęca do takich zachowań i praktyk w zespole, które ten cykl skracają. Wśród nich znajdziemy redukowanie pracy w toku (WIP), sprawne identyfikowanie i usuwanie przeszkód oraz zamykanie historyjek już w trakcie sprintu, o czym zresztą też mówi najnowszy Scrum Guide.

Dlatego następnym razem, zamiast złościć się na dziwne pytania dotyczące Velocity, warto zastosować konstruktywne podejście:

  • Wyjaśnić, czym jest Velocity
  • Wyjaśnić, czym jest Produktywność
  • Pokazać, że Produktywność nie pasuje do warunków pracy twórczej
  • Zaproponować alternatywę w postaci Efektywności
  • Pokazać konkretną implementację Efektywności i pozytywne zachowania, jakie może kreować w zespole i jego otoczeniu.

Powodzenia!

Velocity i jego zastosowanie to wyzwania, z jakimi mierzy się każdy – od dewelopera, po Product Ownera. A opowiadają o tym Scrum Masterzy. Wszystkie te role i pokrewne tematy znajdziecie w dniach 14 – 15 kwietnia podczas konferencji Agile Swarming 2021. Zapisy: https://agileswarming.com/#registration. Zapraszamy!

Artykuł dla Agile Polski napisał Michał Rosołowski.
Michał jest ekspertem Motoroli Solutions w tematyce Agile oraz jednym z organizatorów cyklicznej, międzynarodowej konferencji  Agile Swarming. Na co dzień pomaga liderom i zespołom krakowskiego oddziału firmy wprowadzać bardziej zwinny sposób pracy.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *