To Twój ostatni Sprint. Co robisz?

Wyobraź sobie, że Sprint, w którym właśnie bierzesz udział, jest Twoim ostatnim Sprintem. Twój szef to CEO całej firmy i właśnie podjął taką decyzję. Nie chce bowiem inwestować już więcej pieniędzy w produkt X, ponieważ aktualnie większy zwrot z inwestycji da firmie praca nad produktem Y. Brzmi całkiem sensownie.

Pierwsze wrażenie – szok. Jak to możliwe? Przecież miało być tak pięknie! Jednak chwilę później przypominasz sobie, że sam przekonywałeś go, że agile znaczy szybciej. Że agile to większa elastyczność. Mówiłeś o reagowaniu na zmiany ponad podążanie za planem.

Masz pecha – Twoje buzzwordy właśnie zamieniły się w rzeczywistość.

No cóż, czar prysnął. Idziesz więc do swojego zespołu przekazać im gorącą informację od CEO. Prosisz ich o przygotowanie ostatniego wydania.

Niestety, zamiast szampana oraz serpentyn pojawia się smutna lista problemów, które uniemożliwiają zakończenie prac nad produktem w aktualnym Sprincie:

  • „brakuje nam …. „
  • „mamy gotowe tylko … z …. kroków tego procesu”
  • „to co najmniej … tygodni dewelopmentu”
  • „potrzebujemy dodatkowy Sprint na …”
  • „nie wiedzieliśmy że …”
  • „zależymy od …”
  • „to nie będzie takie proste, bo …”
  • „nie da się” (w sensie ogólnym)

Jeżeli usłyszałeś choćby jedno z powyższych zdań, masz problem.

Bardzo łatwo jest powoływać się na „robienie Scruma” kiedy jest to wygodne. Bardzo łatwo jest wybiórczo rzucać wybrane cytaty ze Scrum Guide’a.

Przykładowo, łatwo jest wysłać osobę – która przychodzi o coś zapytać zespołu – na przysłowiowe drzewo, bo przecież „jesteśmy w środku Sprintu”. Unikać mówienia o datach, bo przecież „Product Owner to ogarnia”, a w ogóle to „będzie jak będzie”. Ignorować jakiekolwiek sygnały z zewnątrz, bo przecież „zespół się samoorganizuje”.

A co z tym fragmentem mówiącym o iteracyjnej oraz inkrementalnej pracy? Co z zawsze dostępnym, potencjalnie użytecznym produktem? Hmm…

Tak więc pytanie na dzisiaj brzmi – co by się stało, gdyby Twój aktualny Sprint miał być Twoim ostatnim?

PS. Za inspirację dziękuję @Kuba_Szc oraz @poddrzewem.

Photo by Andy Beales on Unsplash

 

Facebook
Twitter
LinkedIn
Picture of Jacek Wieczorek

Jacek Wieczorek

Jestem konsultantem zwinności i praktykiem podejścia agile. Napisałem książkę "Labirynty Scruma" o sprawdzonych sposobach na najczęstsze pułapki w Scrumie. Pomagam przekształcać organizacje w miejsca, w których efektywnie tworzone są wartościowe produkty. Prowadzę bloga jacekwieczorek.pl, współtworzę podcast Porządny Agile oraz portal Agile247. Na co dzień pomagam klientom działając jako konsultant w firmie 202 Procent, którą współtworzę z pasjonatami zwinności.

8 odpowiedzi

  1. Hej,

    muszę przyznać, że bardzo ciekawy problem poruszyłeś (niestety w dzisiejszych czasach coraz bardziej popularny – „liczy się tylko pieniądz”). Myślę, że coraz więcej projektów będzie tak ucinanych, gdyż każdy chce szybki zwrot z inwestycji. Niestety jako że nie jest to ostatni sprint, w którym zamykamy projekt, bo klient uzyskał to co chciał, tak więc niestety nie będzie to powód do świętowania.

    Natomiast nie rozumiem tylko jednego, przecież produktem każdego sprintu jest coś powiedzmy „działającego”, tak więc nie wiem dlaczego nie można skończyć prac po tym właśnie sprincie. Wiadomo, że zawsze pozostanie coś w product backlog’u i tym chyba nie ma się co przejmować, bo jeśli lista nazwijmy to „nierozwiązanych spraw” jest widoczna dla każdego, to ktoś podejmując decyzję o zakończeniu prac, miał chyba świadomość w jakim stanie jest aktualnie projekt (czyli zapoznał się z listą product backlog’u). No chyba ze coś celowo było „zamiatane pod dywan” , to wtedy musimy zacząć analizować, dlaczego tak się stało.

    Dla mnie najgorsze w tym przypadku by było to, gdyby po tym sprincie, rozwiązany został całkowicie zespół. Zdecydowanie sprawiłoby to, że ponownie wrócilibyśmy do etapu formowania z nowym zespołem (jeśli takowy byśmy dostali). Jest to bardzo duży problem, bo tracimy czas kiedy Ci ludzie zaczną ponownie działać jako prawdziwy team.

    A na koniec odpowiedz na pytanie (co by się stało, gdyby Twój aktualny Sprint miał być Twoim ostatnim?)
    – nie ma co demonizować, przecież nic nie trwa wiecznie a nowy projekt to nowe możliwości. Problem jest wtedy, kiedy to jednocześnie jest Twój ostatni sprint w tej firmie :) Wtedy powodzenia w szukaniu pracy :)

    Pozdrawiam,
    Guest

    1. @Guest – dzięki za Twój komentarz.

      Nie koniecznie fakt, że robimy ostatni Sprint musi oznaczać, że klient nie otrzyma tego co chciał. Jeżeli od początku dostarczamy najbardziej wartościowe funkcjonalności z punktu widzenia użytkownika, to na końcu Product Backlogu powinny się znaleźć rzeczy najmniej istotne, z których możemy zrezygnować.

      Takie podejście zadziała jednak tylko wtedy, gdy elementy Product Backlogu to zbywalne, niosące w sobie wartość *dla użytkownika* kawałki produktu. Brzmi banalnie, jednak w rzeczywistości nie jest to takie proste.

      Pisząc „ostatni Sprint” mam na myśli ostatnią iterację pracy nad konkretnym produktem, zespół zostawiam ten sam.

  2. Zmiana jest jedyną pewną rzeczą, a zespoły scrumowe powinny być na nią przygotowane. Ostatni sprint? Kończę, a w następnym zaczynam pracę nad kolejnym produktem :)

  3. Trochę nie rozumiem w czym problem. Jeśli dzięki Scrum okazało się, że dalszy development produktu nie ma sensu to znaczy, że Scrum zadziałał świetnie. Eliminujemy waste. Owszem szkoda czasem porzucić coś nad czym się pracowało od dłuższego czasu, ale dzięki transparentości łatwo taką decyzje uzasadnić i zracjonalizować.

    Co do wymagań na backlogu i ich inkrementalności z poprzednich komentarzy. To właśnie inkrementalność (a nie tylko iteracyjność) jest podstawą Scrum. Owszem odpowiednie tworzenie wymgań nie jest banalne. Ba, wręcz z moich doświadczeń wynika, że tutaj jest pies pogrzebany w przypadku niepowodzeń wielu zespołów próbujących używać Scrum.
    Agile jest po to by zbliżyć biznes do IT, jak to już uda się osiągnąć to trzeba jeszcze nauczyć się razem rozmawiać wspólnym językiem, a język ten musi się przekładać na software i na jego architekturę. Scrum to tylko jedno z wielu narzędzi…

    1. @streser – postaram się wytłumaczyć.

      Problem jest wtedy, gdy okazuje się, że pomimo mechanicznego korzystania ze frameworka scrumowego, nie umiemy korzystać z jego pełnych możliwości.

      Wtedy, gdy sposób utrzymywania Product Backlogu powoduje, że wspomniany przez Ciebie „waste” jest równomiernie rozmasowany pomiędzy różne elementy naszego produktu, przez co nie możemy go wyizolować celem porzucenia jako bezwartościowy.

      Wtedy, gdy myślimy o rozwoju produktu komponentowo lub warstwami architektury, zamiast myśleć o nim jak o hamburgerze (http://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/) czy też jak o walking skeletonie (http://alistair.cockburn.us/Walking+skeleton).

      Celem tego wpisu było zwrócenie uwagi na powyższe problemy.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

This site uses Akismet to reduce spam. Learn how your comment data is processed.