Kiedy już się pali, to często jest za późno na podejmowanie racjonalnych działań. Jak określić, co jeszcze uda nam się dowieźć w Sprincie?
Po pierwsze – dlaczego?
Ostatni tekst dotyczył konsekwencji niezrealizowania zakresu Sprintu. Udało nam się scharakteryzować kilka miejsc, w których skutki niedowiezionego zakresu Sprintu są zauważalne. Dziś cofnijmy się dokładnie o jeden krok i zastanówmy się, co zrobić, kiedy już się pali. Jak nie doprowadzić do niezrealizowanego zakresu Sprintu, który spadnie i stanie się kłopotem.
Jak w ogóle dochodzi do tego, że zakres Sprintu, czyli Sprint Backlog zaczyna się palić? Mówiąc „palić” mam na myśli ten pierwszy moment, w którym widzimy, że to się nie uda. Po prostu tego nie zrobimy.
Pierwszy aspekt, który powinniśmy wziąć pod uwagę to złe zaplanowanie. Może ono wynikać z wielu przyczyn: nieplanowane L4, zaplanowany 6 miesięcy temu urlop, o którym zapomniałem powiedzieć, itp. A może po prostu brak Refinementu i wybuchające wymagania powodują, że wszystko właśnie się pali?
Wrzutki to temat rzeka, które faktycznie powoduje rozwalenie nawet najbardziej skrupulatnie ułożonego zakresu Sprintu. Jak sobie z nimi poradzić? Najprostsze rozwiązanie to nie przyjmować ich do realizacji. Ale kto z nas nie ulegnie, kiedy w kolejce do realizacji stoi krytyk z produkcji? Nie oszukujmy się, mało jest takich osób.
Kolejnym aspektem jest mikromanagement, a tak naprawdę niekończąca się lista drobnych wymagań i uwag do naszej pracy, które zgłaszane są przez senior management z terminem wykonania „na wczoraj”. Chciałem napisać „czasami słusznie” ale napiszę „nie, nie ma miejsca na takie zachowania”. Przecież najlepsze rozwiązania i projekty pochodzą od samoorganizujących się Zespołów. Ale czy znajdzie się ktoś, kto powie „nie, Twój pomysł musi poczekać do kolejnego Planowania Sprintu”?
Kiedy już się pali
Stało się. Już się pali. Dopuściliśmy do tego, że plan się rozsypał. Co teraz? Najgorszym doradcą jest pośpiech. Na spokojnie zastanówmy się, jakie w ogóle mamy wyjścia z tej sytuacji i jakie są ich konsekwencje. Przeanalizujmy, co możemy zrobić i jakim składem osobowym. Najgorszą z opcji o której możemy pomyśleć, to próba zrobienia wszystkiego. Nie jest ona zawsze skazana na porażkę. Co więcej, jak pokazuje doświadczenie, taki jednorazowy zryw może się udać. Ale musi on być jednorazowy.
Dużo lepszym zachowaniem będzie zaproszenie na spotkanie całego zespołu. Na nim nie powinniśmy zapomnieć, aby w pierwszej chwili zastanowić się nad tym, dlaczego to znów się stało. Dlaczego mimo tego, że spędziliśmy na planowaniu tyle czasu, znów nie jesteśmy w stanie w sposób komfortowy wykonać tego planu?
Ktoś może powiedzieć „A może lepiej poczekać na Retro?” Jeśli sprawa ma miejsce pierwszy czy drugi raz to może faktycznie, Retro będzie lepszym miejscem. Ale jeśli dzieje się to nagminnie – nie czekajmy. Nadajmy tej dyskusji właściwej powagi i zajmijmy się tematem teraz. Sprint Retrospective ma to do siebie, że odbywa się raz na 1-4 tygodni. Gwarantuje, że emocje opadną, złość minie, a my sami do końca nie będziemy już tak dokładnie pamiętali co to właściwie się stało.
Jaki jest więc modelowy sposób obsługi tego typu sytuacji?
Czas nie jest z gumy
Praca może się rozciągnąć do czasu, jaki na tę pracę przeznaczyliśmy. Zjawisko to nazywamy Prawem Parkinsona. Jednak nigdy nie występuje ono w drugą stronę. Nie można powiedzieć, że w tym oto Sprincie się nie wyrobimy, dlatego potrzebujemy tygodnia więcej. Jest to zaprzeczenie zwinnego podejścia i sposobu pracy, jaki zdecydowaliśmy się wykorzystywać. Powinniśmy pracować w iteracjach o stałej długości.
Jeśli więc nie możemy rozciągnąć Sprintu, zróbmy coś innego. Spróbujmy ustalić z naszym Product Ownerem czym powinniśmy się zająć w pierwszej kolejności – ukończyć zaplanowany Sprint czy zająć się nowymi, dodatkowymi elementami, które właśnie pojawiły się w Backlogu. Zastanówmy się, jaka jest kolejność rzeczy, które powinniśmy dokańczać.
Efektem tej rozmowy ma być realny plan na dokończenie naszych prac. Kiedy się pali, potrzebujemy zdecydowanych, ale jednocześnie możliwych do podjęcia działań. Kiedy widzimy, że ogień trawi całość konstrukcji drewnianego budynku, nie będziemy się na nim skupiać. Jego już się nie uda uratować. Możemy za to skupić się na ratowaniu otoczenia. Tak samo będzie z naszym Backlogiem.
Skupmy się na tym, co jest możliwe do dowiezienia do końca czasu, jaki mamy, biorąc pod uwagę skład i możliwości zespołu. Takie podejście gwarantuje nam ukończenie tych najważniejszych rzeczy, nawet jeśli nie były one wcześniej planowane. Oczywiście dzieje się to kosztem rzeczy „mniej ważnych”, ale skoro jasno określiliśmy priorytety i możliwości, to chyba nikt nie będzie miał z tym problemu?
To, że mamy plan na mitygację nie oznacza, że musi do niej dochodzić. Spróbujmy, postarajmy się ograniczyć do minimum tego typu sytuacje. A kiedy już się pali usiądźmy i zastanówmy się nad rozwiązaniem.
