Podczas pracy z zespołami wielokrotnie słyszę pytanie o to, jak radzić sobie w trakcie Sprintu z pracą, która nie jest zaplanowana i pochodzi spoza zespołu. Do głowy przychodzi mi kilka możliwości, różniących się od siebie łatwością implementacji oraz długofalową skutecznością działania.
Co to jest wrzutka?
Na potrzeby tego artykułu, jako wrzutkę będę traktował pracę, która pojawia się w Zespole Deweloperskim i nie jest powiązana z realizacją Celu Sprintu. Wrzutka to coś, czego co do zasady nie planujemy realizować na etapie Planowania Sprintu i zwykle są to tematy nie związane bezpośrednio z aktualnie trwającym Sprintem. Warto zwrócić uwagę, że za wrzutkę nie uważam pracy, która wyłania się na skutek realizacji Celu Sprintu i zdobywania przez Zespół Deweloperski nowej wiedzy na temat realizowanego Przyrostu.
Przykładowo — dla zespołu, który w aktualnym Sprincie pracuje nad przeprowadzeniem eksperymentu związanego z poprawieniem jakości udzielanej w organizacji informacji zwrotnej, wrzutką będzie pojawienie się w trakcie Sprintu nieplanowanego, dodatkowego zadania dotyczące przygotowania raportu wolnych dni urlopowych wszystkich pracowników organizacji.
Inny przykład — dla zespołu pracującego w aktualnym Sprincie nad dodaniem nowego sposobu płatności w aplikacji, wrzutką będzie niespodziewana prośba o zmianę wszystkich banerów marketingowych w związku z nadchodzącymi świętami Wielkanocnymi.
Ważne założenie wstępne
Zanim przejdę do rozwiązań, dwa słowa dotyczące kontekstu artykułu. Skupiam się w nim wyłącznie na możliwych strategiach działania i nie oceniam “instytucji wrzutek” jako takiej. Nie poruszam też potencjalnych zagrożeń z nich wynikających, takich jak m.in. potencjalna demotywacja zespołu, wydłużony czas realizacji planowanych działań czy koszt przełączania kontekstu. Odrębnym tematem jest też dyskusja o tym, kto powinien decydować a kto faktycznie decyduje o tym, że dana wrzutka zostanie wykonana przez zespół.
Po tym krótkim słowie wstępu, zapraszam do zapoznania się z pierwszą strategią.
Eliminacja systemowej przyczyny powstawania wrzutek
Każda nowa praca ma swoje źródło pochodzenia. Managerowie, inne departamenty, inne zespoły, PMO, Właściciel Produktu, biznes czy interesariusze — w każdym z tych obszarów może pojawić się pomysł, aby przekazać do realizacji zespołów coś, co jest dla nich “najwyższym priorytetem”, “krytyczną zmianą” i czymś, nad czym należy “bezzwłocznie rozpocząć pracę”.
Jeżeli takie wrzutki pojawiają się sporadycznie, to zwykle nie jest to duży problem dla zespołów. Niestety, spotykam też organizacje, w których kultura generowania wrzutek jest domyślnym sposobem pracy, mającym negatywny wpływ na organizację pracy Zespołów Deweloperskich. To, co warto rozważyć jako rozwiązanie w takim przypadku, to systemowa eksploracja problemu: Skąd pojawiają się wrzutki? Dlaczego się pojawiają? Z czego wynikają? Jaki jest pełen obraz tej sytuacji? Jakie zależności występują między zaangażowanymi stronami?
Przykładem systemowej przyczyny generowania wrzutek przez zespół marketingowy może być brak narzędzia typu CMS do zarządzania treścią stron marketingowych. W konsekwencji, aby zaktualizować stronę na skutek pojawienia się nowego pomysłu marketingowego, konieczne jest zaangażowanie Zespołów Deweloperskich, które wyprodukują zmianę.
Systemowym rozwiązaniem tego problemu mogłoby być spojrzenie na problem z szerszej perspektywy i odkrycie, że od miesięcy odkładana zmiana wykonana w jednej części organizacji (napisanie prostego CMS’a przez zespół X), pozwoli innej części organizacji wykonywać swoją pracę bez angażowania innych (dział marketingu).
Przeanalizowanie kosztu opóźnienia (ang. Cost of Delay)
Rozmawianie o koszcie opóźnienia to podejście, w którym dyskutujemy wpływ czasu na na rezultaty, które chcemy uzyskać. W podejściu tym, każdą zmianę do wykonania moglibyśmy omówić z dwóch perspektyw:
- Ile będzie nas kosztować zrealizowanie tej zmiany miesiąc później?
- Ile moglibyśmy zyskać, gdybyśmy zrealizowali tę zmianę miesiąc temu?
Przykładowo — firma wysyła do klientów faktury zwykłymi listami, korzystając z usług firmy pocztowej. Co miesiąc, koszt wydruku faktur, zakupu kopert i znaczków, a także koszt pracy ludzkiej, to 30 tys PLN. Stąd, każdy miesiąc zwłoki w implementacji mechanizmu pozwalającego na cyfrowe pobranie faktury kosztuje nas 30 tys PLN, dwa miesiące opóźnienia to 60 tys itd. Patrząc z drugiej strony, każdy miesiąc dostarczenia wcześniej tego rozwiązania, będzie dawał łatwe do wyliczenia oszczędności. Dokładając do tego opcje wykonania alternatywnych zmian można policzyć, którymi rzeczami z punktu widzenia finansowego opłaca się zająć w pierwszej kolejności.
Ten sposób myślenia możemy zastosować również w kontekście obsługi wrzutek. Najprostszym sposobem użycia kosztu opóźnienia jest dyskusja o tym, co się stanie, jak nie zrealizujemy wrzutki teraz, w trakcie trwającego Sprintu, tylko za kilka dni, gdy rozpoczniemy nową iterację, lub jeszcze później.
Przykładowo — drobna zmiana sposobu działania silnika decyzyjnego decydującego o tym, na jakich warunkach przyznać kredyt może mieć znaczący wpływ na zysk już od pierwszego dnia implementacji. W tym przypadku istnieje wyraźna korelacja między czasem a otrzymaną wartością. Alternatywnie, dodanie kolejnej z wielu zakładek informacyjnych na stronie banku, być może mogłoby poczekać kilka dni lub nawet Sprintów bez znaczącego wpływu na wartość, jaką niesie za sobą tego rodzaju zmiana.
Ostatnia uwaga na koniec: dyskutując o koszcie opóźnienia Warto być gotowym na pełne spektrum odpowiedzi — od kompletnego ignorowania merytorycznej wartości pytania (“Prezes kazał robić, jak chcesz to idź do niego i mu powiedz, że tego nie zrobisz, mądralo”) do głębokiej dyskusji o tym, jaki jest faktyczny wpływ upływającego czasu na pracę, która czeka na wykonanie.
Ustalenie, z czego rezygnujemy, żeby zrealizować wrzutkę
Wymienione wcześniej rozwiązania mogą dla wielu czytelników okazać się bądź zbyt trudne w implementacji (zmiana systemowa), bądź kulturowo niemożliwe do wykorzystania (dyskusja o wartości w czasie). Stąd proponuję trzecie rozwiązanie, które wprawdzie nie rozwiązuje problemu, ale potencjalnie pozwala w przemyślany sposób obsłużyć pojawiające się zmiany.
Podejście to polega na tym, że każdorazowo, gdy pojawia się wrzutka, Zespół Deweloperski omawia z Właścicielem Produktu, z których elementów Backlogu Sprintu zrezygnuje, żeby stworzyć przestrzeń na realizację innej pracy. Podejście to zakłada, że zdolność wytwórcza zespołu — zwana często pojemnością — jest stała i aby dołożyć pracy w zespole, najpierw musimy zastanowić się, z czego zrezygnować.
Przykładowo: Zespół Deweloperski ma zaplanowane pięć zadań do realizacji (A, B, C, D, E). Pojawia się wrzutka (X), która po omówieniu w zespole, kosztować będzie zespół rezygnację z dwóch uprzednio zaplanowanych zadań (np. D oraz E). W konsekwencji, po przyjęciu wrzutki, zespół prognozuje, że na koniec Sprintu zrealizuje zadania A, B, C oraz X.
Pokrewnym rozwiązaniem do omawianego jest zaplanowanie buforu na nieprzewidziane wrzutki już na etapie Planowania Sprintu. Czyli zamiast dyskutować o tym, z czego rezygnujemy, świadomie, z wyprzedzeniem, przygotowujemy na tego rodzaju pracę miejsce w Sprincie. Jednakże to rozwiązanie w mojej ocenie jest pewnego rodzaju akceptacją tego, że wrzutki były i będą, a Zespół Deweloperski musi być na nie przygotowany. Widzę jakiś sens tego rodzaju rozwiązania w ujęciu krótkoterminowym, jednak w dłuższej perspektywie szukałbym bardziej systemowych rozwiązań.
Co jeszcze można zrobić?
Wymieniłem trzy rozwiązania, które warto rozważyć, gdy w trakcie pracy w Sprincie pojawiają się niezaplanowane wrzutki. Rozwiązań jest oczywiście zdecydowanie więcej. Przykładowo, może edukować osoby generujące wrzutki, skracać długość Sprintów czy też przywoływać w dyskusji wpływ wrzutki na realizację Celu Sprintu.
Jako przykład niekonwencjonalnego pomysłu na zarządzanie problemem wrzutek, chciałbym przedstawić rozwiązanie, który spotkałem na profilu LinkedIn Ewy Gowin:
Jakie znacie inne sposoby na radzenie sobie z wrzutkami? Zapraszam do dyskusji w komentarzach.
Polecamy też do posłuchania odcinek #084 podcastu Porządny Agile – Jak radzić sobie z wrzutkami w Scrumie?
Źródło zdjęcia: bonneval sebastien on Unsplash