Mapa drogowa pełna funkcjonalności nie jest błędem. Błędem jest spuszczenie jej na zespół bez kontekstu

Najważniejsze zdanie tej rozmowy pada dopiero pod koniec i brzmi zaskakująco łagodnie. Nikt nigdy nie powiedział, że zadania są niepotrzebne. Trzeba je wykonać, funkcjonalności trzeba dowieźć, backlog nie jest niczym wstydliwym. Rzecz w tym, że bez wiedzy o tym, jaki rezultat ma z nich wyniknąć, nie da się orzec, czy prowadzą w dobrą stronę, a wtedy cała robota robi się droga i ryzykowna. Rezultat nie zastępuje zadań, tylko jest ich kontekstem. Co do reszty nie mamy w tym odcinku jednej odpowiedzi i mówimy to wprost: przewodnika po mapie drogowej nie ma tak, jak jest przewodnik po Scrumie, więc każdy interpretuje ją po swojemu i stąd bierze się większość sporów. Jedyne uczciwe zalecenie brzmi: ustalcie u siebie, czym dla was jest mapa drogowa i co na niej ląduje.

Stąd druga teza, idąca wprost pod prąd temu, co się dziś o mapach pisze. Mapa pełna funkcjonalności nie jest sama w sobie błędem, o ile stoi za nią wartość i strategia. Pełni bowiem funkcję, której nic nie zastąpi: kiedy produkt, marketing i sprzedaż pracują osobno, nie ma innej platformy, na której uzgodnią, na kiedy coś będzie gotowe i od kiedy wolno o tym mówić klientom. Nawet przy pozycji wyglądającej czysto technicznie, jak uruchomienie środowiska czy praca nad architekturą, da się powiedzieć, jaką wartość niesie, bo odblokowuje zależności. Samo stwierdzenie, że trzeba to zrobić i tyle, bywa za mało, i to jest dokładnie ten moment, w którym rodzi się zgrzyt z marketingiem. Warto przy tym pamiętać, że mapa jest prognozą, a nie czymś wyrytym w kamieniu: punkt, który przestał mieć sens wobec celu biznesowego, wyrzuca się, zamiast go dowozić.

Błędem jest co innego i to rozróżnienie jest w tym odcinku ostrzejsze niż cała dyskusja o narzędziach. Lista funkcjonalności spuszczona na zespół pozbawiony kontekstu biznesowego nie da dobrego produktu, bo taki zespół nie ma z czego podjąć dobrej decyzji. Poziom wyżej działa to tak samo: klient przychodzi do wykonawcy z gotowym rozwiązaniem i poleceniem zrobienia go, a wartościowa rozmowa zaczyna się dopiero od pytania, co chce osiągnąć i co mają robić jego użytkownicy. W celu sprintu widać to samo w miniaturze. Cel jest nadrzędny, a elementy backlogu są środkiem do niego, więc dobry cel brzmi tak, że użytkownik może się zalogować i zobaczyć sumę swoich punktów, a rejestracja, logowanie i wyświetlenie listy są krokami po drodze, nie celem samym w sobie. Z tego wynika też długość iteracji: bierze się ona z czasu, w jakim zespół umie dostarczyć kawałek wartości, a nie z rozmiaru zadań ani z przyzwyczajenia. W praktyce najczęściej wychodzą z tego dwa tygodnie.