Scrum w zarządzaniu produktem

Przyznam, że mam ze co do Scruma mam mieszane uczucia. Jest to świetny framework. Liczący zaledwie 19 stron oficjalny Scrum Guide jest doskonałym punktem wyjścia dla zespołów, które pracują nad projektami o dowolnej wielkości. Framework ten jest jasny, zwięzły i nie wymaga czarnego pasa lub (wbrew temu, co mówią niektórzy) certyfikatu, aby rozpocząć.

Mówię teraz do menedżerów produktu: używajcie Scruma, ale nie poświęcajcie zbyt dużo czasu na doskonalenie go.

Nie oznacza to, że Scrum nie jest ważny. Według Scruma zarządzanie projektami jest jedynie niewielką częścią roli Product Managera, a Scrum sam w sobie jest jednym z wielu solidnych frameworków do takiej pracy. Spędzanie za dużo czasu przy jego ulepszaniu może spowodować:

• W najlepszym wypadku- malejący zwrot z zainwestowanego czasu
• W najgorszym przypadku- negatywny wpływ na Twój zespół, ponieważ inne obszary pracy będą ignorowane, np. stworzą się wąskie gardła albo powstanie problem ze zbieraniem feedbacku od klienta.

Zarządzanie produktem, a Scrum

Zarządzanie produktem polega na patrzeniu na to, co tworzymy z szerszej perspektywy - dlatego jest to wymagające zadanie. To proces, w którym pomysł - nieważne czy chodzi o cały produkt, czy małą funkcję - zaczyna w fazie koncepcji, a następnie jest rozwijany, wdrażany i wspierany w miarę ewolucji. Jak widać na poniższym schemacie, z procesem tym wiąże się wiele zadań.

Scrum koncentruje się na poziomie detali w produkcie i jest naturalnie czasochłonnym procesem - codzienne ceremonie, ciągłe pisanie user story, dbanie o backlog i tak dalej, bo lista jest długa. W rezultacie spędzamy nad projektem bardzo dużo czasu. Należy pamiętać, że menedżerowie produktu są w równym stopniu odpowiedzialni za nadawanie kierunku na wysokim poziomie. Aby być skuteczni, muszą myśleć kontekstowo, czyli być w stanie zmienić punkt widzenia z wysokiego na szczegółowy w zależności od zadania, które trzeba wykonać. 

Przesadne skupianie się na szczegółach może spowodować, że product manager się zagubi. Co wiecej, straci koncentrację na tym, co najważniejsze: wizji, strategii i sytuacji finansowej produktu.

Dopieszczanie Scruma obniża wartość Product Managera

Pomiędzy przytłaczającą liczbą artykułów (włączając ten) a wieloma dostępnymi certyfikatami Scrum, w branży oprogramowania kładzie się nieproporcjonalnie duży nacisk na Scrum. W przypadku nowego menedżera produktu skupienie się na Scrumie zwiększa jego postrzeganą wartość.

Ostatecznie Scrum jest narzędziem, a użycie go pomaga skupić się na projekcie. Skupienie takie, jeśli nie jest kontrolowane, może prowadzić do koncentracji na celu wewnętrznym (np. backlogu), a wyznacznikiem sukcesu stanie się wydajność.

Chociaż Scrum jest zwinnym frameworkiem do zarządzania projektami, to, w ogólnym ujęciu, zarządzanie projektami jest narzędziem do poprawy wydajności, która jest wewnętrznie ukierunkowanym wskaźnikiem - najlepiej mierzyć ją prędkością i objętością. Ale celem jest nie tylko szybkie dostarczanie funkcji, a raczej rozwiązywanie problemów użytkowników i dostarczanie wartości. W zespole zorientowanym wewnętrznie celem jest wypuszczenie jak największej liczby funkcji. Testy oraz walidacja są ograniczone do tego, czy nowa funkcja działa, czy nie. Chociaż bardzo ważne jest zapewnienie działania nowych funkcji, ważniejsze jest również sprawdzenie, czy funkcja prawidłowo rozwiązuje problem klienta. Można tego dokonać jedynie przez skupienie się na tym, co na zewnątrz, czyli opiniach i feedbacku użytkowników.

Wydajność nie jest miarą wartości. Gdy user stories i feature requesty się piętrzą, naturalne jest, że chcesz przejść przez jak najwięcej z nich, by zmniejszyć ich liczbę. Celem jest jednak budowanie właściwych rzeczy, a nie robienie wszystkiego. Skupienie się na kliencie pozwala nam wybrać właściwie. Główną korzyścią z posiadania Product Managera jest pomoc, jaką zespół otrzymuje w zrozumieniu potrzeb klientów. Głównym celem jest stworzenie kontekstu i odpowiedź na pytanie, dlaczego coś jest w ogóle budowane. Stworzenie backlogu produktowego i user stories jest efektem znacznie większego procesu.

Ogólnie rzecz biorąc, tworzenie kontekstu pozwala zespołowi zrozumieć, w jaki sposób historie użytkowników wpasowują się w szerszą perspektywę. Można tego dokonać poprzez zaangażowanie zespołu w spotkania z klientami lub poprzez mapowanie user story. Efekt ponad wydajność.

Skupienie na zarządzaniu produktem

Im więcej czasu product manager spędza na doskonaleniu user stories, szukaniu sposobu na poprawienie szybkości działania zespołu (czy to w ogóle możliwe?) oraz na tym, jakiej metody użyć do szacowania (czy zespół powinien to w ogóle robić?), tym mniej czasu poświęca na ważne rzeczy. Jeśli wcześniejszy diagram nie podkreślał zakresu roli zarządzania produktem, poniższy schemat powinien przedstawiać dobry obraz zadań jako całości, wraz z proporcją zadań związanych i niezwiązanych z projektem.

Pragmatic Marketing

Ponieważ zarządzanie projektami jest tak niewielką częścią tej roli, ważne jest, aby nie poświęcać jej przesadnej uwagi. Zwrot z inwestycji Twojego czasu będzie znikomy. Jest to sytuacja, w której "good enough" jest rzeczywiście wystarczająco dobre. Wszystkie zadania podlegają prawu malejących przychodów oraz Zasadzie Pareta - 80% wyników pochodzi z 20% wysiłków. Im bardziej skupiamy się na jednym elemencie, tym mniej będziemy z niego mieli. Ponadto nadmierna koncentracja na jednym zadaniu oznacza, że inne zadania pozostają w stagnacji. Ważne jest, aby w równym stopniu zająć się wszystkimi aspektami projektu, ponieważ zmniejsza to ryzyko jego stagnacji.

Mniej znaczy więcej

Im więcej procesów, tym mniej elastyczne staje się narzędzie. Zwinne narzędzia powinny być łatwe do dostosowania (lub wręcz do odrzucenia), gdy na horyzoncie pojawi się coś lepszego. Każda firma i produkt działają w unikalnym i złożonym środowisku. Zasadniczo nie można zoptymalizować złożonych narzędzi (takich jak Scrum) poza ich podstawowymi zasadami. Muszą one być optymalizowane lokalnie, ponieważ jedno narzędzie lub szablon nie pasuje do każdego środowiska.

Najlepsze usprawnienia procesów są często odkrywane przez sam zespół, dzięki przecieraniu nowych szlaków i popełnianym błędom. Wiele „najlepszych praktyk” Scruma może działać dla jednego zespołu, ale nie musi dla Twojego. Scrum może Cię nawet spowolnić. Ludzie mają tendencję do naprawiania sytuacji przez dodawanie kolejnych rozwiązań, podczas gdy tak naprawdę powinni usuwać bariery. Nazywa się to Intervention Bias.

Kiedy frameworki lub procesy wydają się nieefektywne, staramy się dodać pewne kroki, aby je przyspieszyć. W rzeczywistości naszym pierwszym krokiem powinno być ustalenie, które etapy bieżącego procesu powodują problemy i ich usunięcie. Im bardziej dane narzędzie jest złożone, tym trudniej jest dopasować je do zespołu. Zespół musi się wtedy dopasować do narzędzia, nawet jeśli wynik jest mniej wydajny.

Scrum i Agile to nie są synonimy

Przyjęcie Scruma nie sprawi, że będziesz od razu zwinny. Aby zespół był naprawdę zwinny, nie może ograniczać się tylko do zespołu programistów. Aby firma była zwinna w efektywny sposób, każda jednostka biznesowa musi przestrzegać pewnych zasad.

W firmie istnieje wiele zależności. Niektóre zadania wymagają wkładu z wielu jednostek biznesowych. Zwinność zależy od konsekwentnej komunikacji między tymi jednostkami oraz eliminacji wąskich gardeł. Jeśli wąskie gardła w ogóle powstają, to nie ma znaczenia, jakie narzędzie do zarządzania projektami jest używane, bo cała firma napotyka wtedy przeszkodę.

Większość głównych przeszkód w umożliwieniu zespołowi zwinnego działania występuje na szerszym poziomie organizacyjnym, który często pozostaje poza kontrolą zespołu. Ważnym aspektem zarządzania produktem jest możliwość budowania relacji i wpływania na organizację w celu usunięcia tych wąskich gardeł.

Scrum pozwala zespołom biznesowym i programistycznym na współpracę i działanie w zwinny sposób. Pod koniec każdego sprintu zespół ma okazję zastanowić się, czego się nauczył, a następnie się dostosować. Biorąc to pod uwagę, gdy zarządzanie projektami wpisuje się w ogólny obraz biznesu, największą zapewnioną wartością jest wtedy wydajność. Stuprocentowa zwinność jest nieefektywna. Ciągle pojawiają się nowe, ważne zadania i, jeśli się tego nie kontroluje, to zespół będzie stale skakał między zadaniami. Wykazano, że multi-tasking zmniejsza wydajność o 40%.

Uczenie się z opinii klientów oraz zdolność adaptacji (czyli praca nad tym, co ważne) plus wydajność (planowanie i realizacja) zapewniają wartościowe rezultaty.

Aby zespół programistów był w stanie dowozić wyniki, to musi w nim istnieć równowaga między zwinnością a wydajnością. Scrum umożliwia dowożenie wyników, ponieważ pozwala zespołowi skupić się na zadaniach i daje pewność co do tego, co jest w tym wszystkim najważniejsze. 

Skup się na nagrodzie

Przez zbyt duże skupienie na Scrumie lub innych aspektach związanych z zarządzaniem projektem, menedżerowie produktu mogą paść ofiarą:

• Ignorowania zadań, które są o wiele ważniejsze dla całego zespołu (na przykład, zbieranie feedbacku od klientów lub zapewnianie sukcesu produktu na rynku)
• Stawiania wydajności nad wynikami. Powstaje wtedy za dużo funkcji.
• Fałszywego przekonania, że zespół jest zwinny (a tak naprawdę tylko używa Scruma).

Menedżerowie produktu powinni szukać sposobów na zredukowanie czasu spędzonego na zadaniach Scruma.

Nie ma cudownego leku na uzdrowienie Scruma. Najlepsze ulepszenia wynikają z prób i błędów. Oznacza to drobne poprawki, czas i cierpliwość. Ta cierpliwość i czas dają wiele okazji, aby poświęcać się innym aspektom pracy.

Oryginał tekstu w języku angielskim możesz przeczytać tutaj.