Piszę książkę o sprawdzonych sposobach na pułapki w Scrumie #labiryntyscruma

Od kilku miesięcy skupiam się niemal wyłącznie na najważniejszym dla mnie projekcie w 2017 roku – książce, w której dzielę się sprawdzonymi sposobami na najczęstsze pułapki w Scrumie. Nazwałem ją “Labirynty Scruma”, właśnie zbieram feedback od recenzentów i planuję ją wydać w modelu self-publishing. Zacznijmy jednak od początku, czyli od pytania “why”. Czytaj dalej

Scrum & agile: zestaw startowy dla początkujących

Agile & scrum: jak zacząć?

Wielokrotnie spotkałem się z pytaniem Scrum Masterów lub Product Ownerów – którzy dopiero rozpoczynają swoją przygodę z agile oraz Scrumem – co robić, aby rozbudować swoją wiedzę. Kiedy kilka dni temu, po przeprowadzeniu rozmowy rekrutacyjnej w poszukiwaniu doświadczonego Scrum Mastera, osoba biorąca w niej udział poprosiła mnie o feedback i sugestie co do dalszego rozwoju, stwierdziłem, że czas na napisanie poniższego wpisu.

Obszary, którymi warto się zainteresować, można podzielić na kilka grup:

1. Lokalne społeczności agile – w kilku dużych miastach w Polsce funkcjonują inicjatywy, które skupiają entuzjastów agile, chętnych do dzielenia się wiedzą oraz doświadczeniami. Najczęściej formuła takich spotkań to prezentacja prelegenta (zazwyczaj ok. 1h), która przeobraża się następnie w dyskusję w mniejszych grupach. Jeżeli szukasz inspirujących dyskusji, zdecydowanie zainteresuj się, czy w pobliżu Ciebie funkcjonuje już taka grupa. Jeśli nie, to może warto założyć takową?

2. Książki

3. Publikacje

  • Scrum Guide – kilkanaście stron o tym, czym jest Scrum, napisane przez Jeffa Sutherlanda oraz Kena Schwabera – twórców Scruma. Warto czytać ten dokument co jakiś czas, bo wraz z upływającym czasem (oraz zdobytym doświadczeniem) zaczyna się coraz więcej z niego wyciągać. Do dzisiaj potrafi mnie coś zaskoczyć czy zainspirować.
  • Product Owners Manual – krótka, lecz treściwa pozycja, zawierająca zbiór podstawowych informacji związanych z rolą Product Ownera

4. Materiały video

Powyższe materiały to tylko przykład punktu, z którego można wystartować. Dalszy rozwój to połączenie własnych doświadczeń, dyskusji z praktykami agile oraz kolejnych lektur – dobieranych według własnego uznania. Powodzenia!

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

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.

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.

Podwodny świat zespołów scrumowych

Budowa peryskopu

Budowa peryskopu

Wyobraźmy sobie nowoczesną łódź podwodna, wyruszającą na misję bojową. Świetnie przygotowana załoga doskonale radzi sobie z obsługą okrętu. Wszystkie systemy są naszpikowane elektroniką, a całość spina wysokiej jakości oprogramowanie.

Okręt zbliża się w strefę walki. Pomimo sugestii doradcy, że warto by było ocenić, co znajduje się na horyzoncie, oficer dowodzący jest zdania, że łódź jest tak nowoczesna, iż nie ma sensu użyć peryskopu. Uważa, że wszystko co ważne, wskazuje nam aparatura pokładowa, a załoga nie raz już płynęła na misję, więc wiedzą doskonale, co mają robić.

10 minut później łódź zostaje trafiona torpedą wystrzeloną z wrogiego okrętu. Łączność z naszym statkiem zostaje utracona. Znajdująca się w pobliżu jednostka potwierdza jego zatonięcie. Misja kończy się niepowodzeniem.

Jak to się ma do Scruma?

Ta niepozorna historia ma wiele wspólnego z pracą nad rozwojem produktu. Poznałem ostatnio zespół, który pracuje w nowoczesnej technologii. Starają się wytwarzać kod wysokiej jakości. Mają dostęp do narzędzi oraz wiedzy, która pozwala im dobrze wykonywać swoją pracę. Rozmowy zespołu dotyczą zazwyczaj szczegółów technicznych, rysowane są diagramy, omawiane interfejsy oraz komponenty.

W tym wszystkim jakby zapominali, że istnieje świat nad powierzchnią wody. Że użytkownika nie interesuje jak coś jest zrobione, tylko co mu to daje. Że ma być użytecznie oraz intuicyjnie. Że w ogóle jest jakiś użytkownik, który nie jest systemem, komponentem czy klasą, tylko żywym organizmem, który ostatecznie będzie z tego korzystał.

Zapominają użyć peryskopu, aby wyjrzeć na powierzchnię i ocenić, jak ich praca ma się do sytuacji na polu bitwy. Tracą przez to informacje, które pomogły by im lepiej przeprowadzić misję. Ryzyko niepowodzenia wzrasta. Świat pod wodą wygląda inaczej, niż ten rzeczywisty.

A może zamiast używać peryskopu, lepiej wykonać pełne wynurzenie?

Fotografia użyta na licencji Creative Commons ze strony Wikipedia.