Bardzo często myśląc o efektywności mówimy o realizacji jak największej liczby zadań w określonym czasie (ang. output). Często nasuwają nam się również miary pokroju Velocity czy Capacity. O ile nie ma nic złego w mierzeniu prędkości zespołu, o tyle mówimy tutaj bardziej o wydajności, a nie efektywności.
Prawdziwą efektywność należy utożsamiać z efektem naszej pracy jakim jest produkt. Powinniśmy więc mówić o wartości jaką dostarczamy końcowemu użytkownikowi (ang. outcome), czy też ujmując inaczej z mierzalną zmianą w zachowaniu użytkownika.
Co wpływa na efektywność i jak możemy ją poprawić?
Pamiętajmy o celu produktu
W kontekście efektywności chodzi nie tyle o posiadanie samego celu produktu, co o filtrowanie wymagań przez ten cel produktu (przy okazji warto spojrzeć do najnowszego Scrum Guide 2020 gdzie cel produktu został bardzo mocno podkreślony). Zadanie sobie pytania dlaczego robimy daną funkcjonalność i jaki ma być jej finalny efekt? Czy ona rzeczywiście wspiera cel produktu czy jest tylko kolejnym elementem backlogu zdjętym z góry kolejki lub zleconym przez interesariusza.
Róbmy właściwą rzecz
Powinniśmy zadać sobie pytanie czy robimy właściwą część danego wymagania. W tym celu najlepiej dokonać dekompozycji na mniejsze elementy np. na sesji Refinement. Pamiętajmy, że słynna zasada Pareto mówi, że 20% nakładu odpowiada za 80% efektu. Znajdźmy więc te 20% najważniejszych rzeczy, w przeciwnym razie może okazać się, że przepalimy czas w sprincie na nikomu nie potrzebne dodatki.
Bądźmy blisko biznesu
Jeśli oczekujemy od zespołu developerskiego aktywnego i kreatywnego wkładu w projektowane rozwiązanie, zespół powinien być blisko biznesu. Developerzy powinni dobrze rozumieć potrzeby końcowego użytkownika, tylko wtedy będą w stanie prowadzić wyrównany dialog z Product Ownerem i interesariuszami, a tym samym dobrać najlepsze możliwe rozwiązanie.
Pozostańmy skupieni
W sytuacji gdy wspieramy wiele wersji tego samego produktu możemy dojść do miejsca gdzie zbyt dużo czasu będziemy poświęcać na ich utrzymanie, naprawę błędów i szeroko pojęte wsparcie. Może nam fizycznie brakować czasu na dostarczanie nowych funkcjonalności i co ważniejsze chęci na eksperymentowanie.
Drugim przypadkiem, zaburzającym skupienie zespołu, jest praca w kilku obszarach na raz. Czas potrzebny na przełączenie między nimi ma negatywny wpływ zarówno na samą wydajność jak i ogólne zaangażowanie zespołu.
Dążmy do autonomii
Jeśli Product Owner dysponuje ograniczonym poziomem decyzyjności, wynikającym np. z takiej a nie innej struktury organizacyjnej lub zbyt silnym umocowaniu interesariuszy w produkcie. Kiedy potrzebuje pozwolenia na każdą nawet najmniejszą zmianę kierunku, wtedy cały produkt traci na zwinności, a w efekcie cierpi końcowa efektywność.
Miary efektywności
Mówiąc o miarach efektywności najlepiej skierować się w stronę Evidence Based Management (EBM). Jest to empiryczny framework, mające swoje korzenie w medycynie, a obecnie szeroko stosowany w organizacjach w celu poprawy ich efektywności w dostarczaniu wartości klientom i realizacji strategicznych celów.
EBM wyróżnia 4 główne obszary (ang. Key Value Areas):
Current Value (CV) - jaką wartość dostarcza nasz produkt, w chwili obecnej, w odniesieniu do celu produktu
Unrealized Value (UV) - potencjalna przyszła wartość którą możemy zrealizować w odniesieniu do celu produktu
Time-to-Market (T2M) - jak długo zajmuje nam dostarczenie nowej wartości
Ability to Innovate (A2I) - jak skuteczni jesteśmy w dostarczaniu nowych możliwości, które mogą lepiej zaspokoić potrzeby klientów
Każdy z obszarów zawiera szereg miar (po szczegóły odsyłam do EBM Guide). W kontekście efektywności chciałbym wyróżnić kilka z nich.
Z obszaru Current Value:
Usage Index - ile osób, tak naprawdę, korzysta z naszych nowych funkcjonalności i czy poświęcają na nie tyle czasu ile oczekiwaliśmy
Customer Satisfaction - ocenia zaangażowanie i ogólne zadowolenie klienta z produktu bądź jego części
Z obszaru Ability-to-Innovate:
Innovation Rate - ile czasu procentowo poświęcamy na utrzymanie lub poprawę bugów, a ile na nowe funkcjonalności
Version Index - ile wersji danego produktu utrzymujemy. Zarówno w kontekście wysiłku jaki wkładamy w zarządzanie poszczególnymi wersjami jak i faktu, że nie wszyscy użytkownicy są w stanie skorzystać z najnowszych funkcjonalności.
Referencje: