Jednodniowe Sprinty w Scrumie

1-dniowe sprinty w Scrumie

1-dniowe sprinty w Scrumie

Od zawsze byłem fanem krótkich sprintów. Dostrzegam dużą wartość w skracaniu pętli feedbacku przy jednoczesnym minimalizowaniu niepewności związanej z wytwarzaniem oprogramowania.

Myślałem ostatnio o prostym eksperymencie – przez tydzień lub dwa chciałbym pracować z zespołem używając 1-dniowych sprintów.

Zakładając 8h dzień pracy, na właściwą pracę – po odjęciu czasu potrzebnego na zdarzenia scrumowe – pozostaje 378 minut, tj. 6h 18 minut.

Oto jak wyglądał by szkielet zdarzeń scrumowych:

  • Planning – 24 minuty
  • Refinement – 42 minuty
  • Review – 12 minut
  • Retrospektywa – 9 minut
  • Daily – 15 min

Patrząc na powyższe liczby, pierwsze co przyszło mi do głowy, to stwierdzenie „wymagające te timeboxy”. Po dłuższym zastanowieniu jednak, kiedy ponownie uzmysłowiłem sobie, że mówimy po prostu o organizacji jednego dnia pracy, wartości te przestały mnie zadziwiać.

Zakładam, że pewne założenia muszą zostać spełnione, aby takie podejście miało szansę powodzenia, do głowy przychodzą mi następujące punkty:

  • zespół realizuje w sprincie 1-2 naprawdę małe funkcjonalności
  • członkowie zespołu bardzo dobrze potrafią ze sobą współpracować i dzielić się pracą (wykorzystują np. swarming)
  • elementy Product Backlogu są bardzo małe, nie zależą od siebie, a jednocześnie przynoszą wartość
  • wykorzystywane jest podejście walking skeleton, tak aby na koniec sprintu pokazać coś potencjalnie zbywalnego, operując mocno głębią odwzorowania szczegółów
  • brak znaczących zależności zewnętrznych (np. oczekiwanie kilka godzin na jakiekolwiek zasoby odpada)
  • sprawny Scrum Master potrafiący moderować tak ekstremalne podejście do dewelopmentu

Co sądzicie? A może ktoś z Was pracował już z 1-dniowymi sprintami?

Fotografia użyta na licencji Creative Commons od użytkownika andrechinn.

Nie mów JAK robić, powiedz CO chcesz i DLACZEGO to jest ważne

Product Owner z wizją

Product Owner z wizją

Klocki Lego świetnie nadają się do symulowania pracy zespołów scrumowych. Gdy korzystam z nich podczas szkoleń oraz warsztatów, zapraszam uczestników do zbudowania miasta. Zazwyczaj jestem hostem tego ćwiczenia, a osoba współprowadząca przyjmuje rolę Product Ownera.

Na początku sprzedaje ona uczestnikom wizję. Opowiada, dlaczego chciałaby wybudować miasto, jak je sobie wyobraża oraz podaje kilka wstępnych ograniczeń, np. „przez środek miasta przepływa rzeka„. Następnie przedstawia zarys Product Backlogu, który składa się m.in. z domów, biurowców czy obiektów użyteczności publicznej. Uczestnicy w kilku sprintach budują miasto, samodzielnie decydując, jak zrealizować za pomocą LEGO wizję Product Ownera.

Czasem zdarza się, że uda się im zbudować wszystko, co zaplanował Product Owner w swoim Product Backlogu. W takiej sytuacji mówi im: „OK, wszystko co miałem w planach już wykonaliście, ale mam budżet na dalszą pracę – budujcie więc to, co uważacie za słuszne„. W tym momencie dzieje się ciekawa rzecz – w bardzo krótkim czasie powstają najciekawsze, najbardziej innowacyjne oraz imponujące budowle, które świetnie wpisują się w pierwotną wizję miasta.

Ci sami ludzie, ten sam produkt. Zupełnie nowa jakość, zupełnie inna energia w zespole.

Jest to dla mnie jeden z dowodów na to, że najlepsze produkty powstają w środowisku, w którym zespół:

  • zna wizję produktu, rozumie po co i dla kogo tworzony jest produkt,
  • wie co ma zrobić i samodzielnie podejmuje decyzję jak to wykonać,
  • otrzymuje przestrzeń do samoorozwoju oraz doskonalenia się.

Co istotne, podejście polegające na mówieniu „co” zamiast „jak”, można stosować na różnych poziomach. 

Product Owner nie mówi zespołowi jak coś ma działać. Mówi, co chciałby uzyskać i dlaczego ma to dla niego znaczenie. Operuje na poziomie efektów, które chciałby osiągnąć (np. „zwiększenie konwersji z kont testowych do kont płatnych”), a nie na konkretnych rozwiązaniach (np. „wysyłajmy dodatkowy e-mail zachęcający do zakupu naszego produktu”).

Gdy skalujemy produkt na kilka zespołów, Chief Product Owner nie mówi Product Ownerom jak ma coś działać. Nie mówi też, w jaki sposób mają podzielić się pracą (np. „Janek zrób wyszukiwarkę, a Ty Krzysiek zrób listę przedmiotów”). Mówi, co chciałby uzyskać („użytkownicy mają mieć możliwość szybkiego dotarcia do naszych produktów”) i dlaczego to dla niego ważne.

CEO/zarząd/boss nie mówi, jakie konkretnie funkcjonalności ma dostarczyć dla niego Chief Product Owner wraz z zespołem Product Ownerów (np. „przygotuj możliwość integracji z Facebookiem„). Nie mówi też, jak mają się zoorganizować (np. „Jeden zespół integruje się z Facebookiem, a pozostałe modyfikują naszą aplikację„). Mówi jaki cel chce zrealizować („podwojenie liczby użytkowników do końca roku„) i dlaczego jest to istotne.

Nie prośmy zespołu, aby zbudował nam łódkę. Poprośmy, aby pomogli nam przedstać się na drugą stronę rzeki.

Fotografia użyta na licencji Creative Commons od użytkownika minivan1411.

Co to jest MVP (Minimum Viable Product) i jak zrobić to dobrze?

MVP - czy nasz produkt przeżyje crash-test z rynkiem?

MVP – czy nasz produkt przeżyje crash-test z rynkiem?

Powiedzmy to sobie wprost – nie mówmy o projekcie trwającym kilka miesięcy, z którego usunęliśmy kilka nikomu nie potrzebnych funkcji, że zbudowaliśmy MVP (ang. Minimum Viable Product). Sam popełniłem ten błąd kilka lat temu, zbyt długo rozwijając produkt w ukryciu, zanim zdecydowaliśmy się wypuścić go publicznie. Bardzo chcieliśmy uniknąć zażenowania po wypuszczeniu pierwszej wersji, co zdaniem założyciela LinkedIn oznacza, że najprawdopodobniej prezentujesz swój produkt zbyt późno.

MVP to nic innego jak wykonanie jak najmniejszego możliwego kroku, który pozwoli nam przetestować nasz pomysł na biznes i zdobyć wiedzę. Krok ten im mniej kosztowny tym lepszy, bo przecież nie mamy pewności, że ktokolwiek jest gotowy płacić za to, co planujemy stworzyć.

Nie ma to nic wspólnego z odchudzaniem gotowych produktów z mniej istotnych funkcji – taką strategię nazywamy raczej zdrowym rozsądkiem ;)

Poniżej kilka przykładów obrazujących, co to znaczy stworzyć MVP:

  • IBM* rozważał wprowadzenie na rynek systemów sterowanych głosem. Zamiast spędzić miesiące/lata nad budową skomplikowanych algorytmów, przeprowadził prosty i genialny zarazem eksperyment: zaprosił ludzi do testowania nowego systemu, który reagował na polecenia głosowe. Biorący udział w eksperymencie nie wiedzieli, że to nie maszyna wykonuje ich polecenia, a żywy człowiek, siedzący w pokoju obok. Pomimo 100% skuteczności w rozpoznawaniu komend przez „komputer”, ludzie biorący udział w eksperymencie wypowiadali się negatywnie o całym pomyśle – woleli bowiem sterować komputerem ręcznie, przy pomocy klawiatury oraz myszy.
  • Buffer – zanim aplikacja powstała, autor przygotował stronę, na której w paru słowach opisał działanie aplikacji oraz umieścił przycisk „Plans and Pricing”. Dowiedział się w ten sposób, czy ktokolwiek jest zainteresowany jego aplikacją. Kolejnym krokiem nie było napisanie aplikacji, tylko dodanie kolejnej podstrony z dostępnymi abonamentami. Zainteresowani eksplorowali stronę, odpowiadając w ten sposób na pytanie, czy ktokolwiek jest gotowy zapłacić za jego software.
  • startup ze Stanford – grupa osób chciała użyć dronów do wykonywania super-szczegółowych zdjęć plantacji rolniczych, aby później sprzedawać te zdjęcia rolnikom, którzy na ich podstawie mogliby ocenić ogólny stan ich pól (choroby, brak wody, inne szkody). Zamiast budować drona od podstaw, zachęcono ich, aby na początek wypożyczyli działający egzemplarz, zrobili zdjęcia i gdy okaże się, że rolnicy są gotowi im za nie zapłacić, to wtedy dopiero zastanawiać się nad budowaniem własnego drona.
  • Dropbox – zanim autor na poważnie zaczął rozwijać aplikację, przygotował nagranie video, w którym zaprezentował ideę działania aplikacji. Aplikacja bowiem wbrew pozorom nie jest banalna z technicznego punktu widzenia – wiele różnych platform sprzętowych, bezpieczeństwo danych, proces synchornizacji danych itd. Feedback jaki otrzymał od potencjalnych użytkowników zafascynowanych jego nagraniem upewnił go w przekonaniu, że aplikacja może być strzałem w dziesiątkę i warto ją dalej rozwijać.

Znasz jakiś inny, warty wspomnienia przykład MVP? Napisz o tym w komentarzu.

* – nie dam głowy, że chodziło o IBM, ale nie znalazłem w sensownym czasie źródła

Fotografia użyta na licencji Creative Commons od użytkownika lincolnblues.

To Twój ostatni Sprint. Co robisz?

Ostatni Sprint

Ostatni Sprint

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.

Fotografia użyta na licencji Creative Commons od użytkownika Hans.

Zmiany vs. eksperymenty

Zróbmy mały eksperyment

Zróbmy mały eksperyment

Prowadziłem ostatnio retrospektywę w zaprzyjaźnionym zespole. Spotkanie zmierzało powoli do końca – mieliśmy już bowiem zidentyfikowane problemy wraz z potencjalnymi rozwiązaniami. Wystarczyło tylko podjąć decyzję, które rozwiązania wybrać.

10-osobowy zespół, ze względu na specyfikę produktu złożony głównie z programistów, rozpoczął dyskusję nad wyborem rozwiązania do jednego z problemów. Z puli potencjalnych rozwiązań pozostały dwa najciekawsze, które podzieliły zespół na dwa obozy.

Rozpoczęła się dyskusja. Wymiana zdań była długa, pełna nieoczekiwanych zwrotów akcji i pomimo moderacji – trudna do opanowania, ze względu na emocje panujące w zespole.

Jednak z mojej perspektywy najciekawsze w tym wszystkim było to, że zespół przez cały czas operował na poziomie teorii. Dyskutowali o tym, co się wydarzy na skutek podjęcia takiej, a nie innej decyzji. Trochę tak, jakby wybór był wiążący na całe życie.

Dlaczego moim zdaniem nie warto było poświęcać więcej czasu na dyskusję nad zmianą, a zamiast tego zdecydować się na eksperyment?

  • to tylko teoria – rzeczywistość może okazać okaże się zapewne nieco inna, aniżeli została opisana przez zwolenników oraz przeciwników rozwiązania,
  • złożoność środowiska – na poziomie ludzi, zespołu, produktu oraz firmy. Gotowe rozwiązania czy najlepsze praktyki nie działają w złożonym otoczeniu, być może rozwiązanie wyłoni się dopiero na skutek pracy zespołu,
  • łatwość zmiany decyzji – nie trzeba czekać do kolejnej retrospektywy, żeby zmienić raz wybrane podejście. Jeżeli coś nie działa, możemy to zmienić od razu,
  • zdobywanie wiedzy – traktowanie rozwiązania jako mały eksperyment z wartościowym rezultatem (jakikolwiek by nie był), nauczy zespół więcej, aniżeli najciekawsza wymiana zdań.

A Ty jak traktujesz zmiany? Zapraszam do komentowania.

Fotografia użyta na licencji Creative Commons od użytkownika snre.