.st0{fill:#FFFFFF;}

Przestań zaczynać, zacznij kończyć! 

 4 maja, 2021

Tomasz Dzierżek

„Stop starting, start finishing”, czyli „Przestań zaczynać, zacznij kończyć” to znane hasło z okolic podejścia Lean. Ma jednak ono znacznie szersze zastosowanie i o wiele głębsze konsekwencje.

 

Przestań zaczynać

Nie jest trudno zacząć. Może to brzmi jak banał, ale czasami banały to sama prawda i idealny punkt wyjścia. Jako #białko zaczynaliśmy niezliczoną ilość przedsięwzięć, z których większość skończyliśmy z sukcesem. Część naszych planów oczywiście rozchodziła się po kościach. Ale chyba najczęściej sami sobie robiliśmy krzywdę, biorąc na talerz więcej, niż jesteśmy w stanie zjeść.

Bo przecież rozpoczęcie czegoś to jest żaden problem. Wystarczy wykonać pierwsze ruchy, a w niektórych przypadkach li tylko to zaplanować. Tylko, że jak zrobimy tak wystarczająco dużo razy, to zostaniemy w sytuacji w której nie będziemy wiedzieli w co włożyć ręce.

Oczywiście, większość naszych pomysłów jest genialna, najlepsza i nie może czekać, ale tu właśnie prawdziwa „sztuka agile’a”, aby potrafić ułożyć backlog i odpowiednio go spriorytetować. Możemy co prawda zatrudniać coraz więcej i więcej osób, ale jak pokazuje praktyka i Prawo Brooksa – nic to nie zmieni. Istnieje ograniczona ilość rzeczy, którą możemy ogarnąć „na raz”. Dodając kolejne po prostu rozmieniamy się na drobne, tracimy skupienie i nie kończymy niczego.

Pamiętajmy, że wartość powstaje jedynie z kompletnych, zrealizowanych pomysłów i wymagań. 80% realizacji to zwykle 0% korzyści. A zaczynanie kolejnej rzeczy odciąga nas od tych 100% na których nam zależy. Oczywiście, zupełnie osobną sprawą jest ograniczanie rozmiaru tych „stu procent”, czyli podejście o nazwie MVP.

 

Słowa mają znaczenie

Przy tej okazji chciałbym też poruszyć temat, na który jestem wyczulony, a który dla wielu osób nie istnieje bądź nie wydaje się ważny. Mam na myśli nasz sposób wypowiadania się i słowa, jakich używamy. W tekście „3 sposoby na naprawę Daily Scrum” pisałem o tym, jak zwykła zmiana kolejności mówienia (najpierw o dzisiaj, a potem o wczoraj) potrafi wpłynąć na nasze wypowiedzi. W podobny sposób mogą zadziałać pojedyncze słowa.

Zawsze i wszędzie zachęcam wszystkich do mówienia w trybie dokonanym. Szczególnie, jeżeli chodzi o Daily Scrum, Cel Produktu czy Cel Sprintu. W moich oczach olbrzymim błędem jest uznawanie za Cel Sprintu czegoś w rodzaju „Chcemy zacząć pracę nad funkcjonalnością X”. Celem może być skończenie czegoś, osiągnięcie jakiegoś realnego kamienia milowego. „Zaczęcie pracy” nic nam nie daje, bo jak już sobie powiedzieliśmy, nie przynosi żadnych korzyści klientowi.

Są tacy, którzy uważają, że to nie ma znaczenia. Bo co za różnica, jak Celem Sprintu będzie „zainstalowanie na referencyjnym sprzęcie bazowej wersji aplikacji, która uruchamia się poprawnie i komunikuje z produkcyjną bazą danych”? To też jest tylko „zaczęcie pracy”, a klient nie będzie miał żadnych korzyści. Po części prawda, ale będziemy ją mieli my. Będziemy wiedzieli, że potrafimy zbudować i zainstalować aplikację, a wymagane kanały są drożne. Mamy jasne kryteria sukcesu i porażki.

Przy celu w rodzaju „zaczęcie czegoś” tak naprawdę zawsze odniesiemy sukces. Wystarczy, że napiszemy jedną linijkę kodu lub chociażby stworzymy repozytorium i już możemy powiedzieć, że „zaczęliśmy”. Tylko czy to jest sukces, czy po prostu planowana porażka?

Na Planowaniu Sprintu nie powinniśmy z góry zakładać porażki, czyli nieukończenia czegoś. Wspominaliśmy też o tym przy okazji tekstu o Defintion of Almost Done, czyli rzeczach prawie skończonych. Nie ma „prawie”, nie ma „zaczniemy” – zastanówmy się co zrobimy, co skończymy i czym będziemy mogli się pochwalić.

 

Zacznij kończyć

Kolejna obserwacja dotycząca „kończenia”, to sztuka kompromisu i trudnych wyborów. Zwykle mówimy o konsensusie, to jednak w przypadku wyboru, które wymagania poświęcić na rzecz których to zawsze jest kompromis. Osobą, która stoi przed tym wyzwaniem jest Product Owner.

Sytuacja jest dość typowa: zbliża nam się koniec Sprintu i z dziesięciu wymagań mamy skończone jedynie dwa. Co z pozostałymi ośmioma? Czy powinniśmy dążyć do tego, żeby „dowieźć” wszystko? Jak pokazuje praktyka, bardzo często próbując zrealizować te osiem wymagań osiągniemy spektakularną porażkę. Skończymy dwa, może trzy. Ta sama praktyka podpowiada nam, że gdy z góry poświęcimy kilka z nich, dajemy sobie szansę, żeby pozostałe dostarczyć bez większych problemów. Czyli, poświęcamy trzy, aby dowieźć pięć. Kto jednak zdecyduje się na taki krok?

W tym całym naszym zapracowaniu i dążeniu do perfekcjonizmu tracimy to, co jest najważniejsze. Nie chodzi o to, aby się narobić, ale aby zrobić. Czyli znów wracamy do trybu dokonanego. Co z tego, że pracowaliśmy w nadgodzinach próbując zrealizować całość Sprint Backlogu, skoro i tak się nie udało? Albo to co się udało wcale nie jest skończone, tylko wymaga dalszych prac?

Naszym celem nie jest kręcenie się w kółko, przebieranie nogami czy nawet wytężona praca ponad miarę. Liczą się efekty i to, co zostało skończone. Zamiast więc planować miliony rzeczy, mierzmy siły na zamiary. A jak się zaczyna robić gorąco – przede wszystkim skończmy to, co możemy skończyć szybko. Dzięki temu będziemy mieli mniej na talerzu i łatwiej będzie skończyć kolejne rzeczy. I dopiero wtedy będziemy mogli zacząć kolejne.

Dokładnie takie myślenie wspiera i promuje Cel Produktu, o którym pisaliśmy przy innej okazji. Jeżeli potrzebujesz praktycznych porad jak „więcej kończyć”, znajdziesz je właśnie w tekście o Product Goal.

Tomasz Dzierżek


23+ lat doświadczenia w IT, 15+ lat doświadczenia w Scrum i agile, PSM III (i inne), konsultant zwinnych procesów i zespołów, Agile Coach, trener

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}