Jak utrzymać timebox na Daily Scrum?

Jak utrzymać timebox na spotkaniu?

Jak utrzymać timebox na spotkaniu?

Limity czasowe dla wszelkiego rodzaju aktywności w Scrumie potrafią sprawiać nie lada problem. Szczególnie w nowych zespołach problematyczne jest przeprowadzenie Daily Scruma w ciągu 15-minutowego timeboxa.

Utrzymanie reżimu czasowego może być wyjątkowo trudne w zespołach, dla których praca z timeboxem jest czymś nowym. Przyzwyczajenia wyniesione z kiepsko moderowanych spotkań, również nie pomagają w zrozumieniu idei działania pod presją upływającego czasu.

Na szczęscie istnieje kilka prostych technik, które wspomagają zespół w utrzymaniu 15-minutowego ograniczenia czasowego – oto kilka z nich:

  • regularne informowanie o upływającym czasie – prosta, nieinwazyjna technika, polegająca na uświadamianiu zespołu, że czas upływa nieubłaganie. Scrum Master może co 5 minut o tym przypominać, mówiąc np: „Pięć minut za nami„. Można zwiększać lub zmniejszać częstotliwość informowania, w zależności od przebiegu wydarzeń na spotkaniu
  • limit czasowy na każdego członka zespołu – spotkanie trwa 15 minut, zespół składa się z 10 osób, tak więc każda osoba otrzymuje timebox w wymiarze półtorej minuty na swoją wypowiedź
  • przekazanie swoich obserwacji do zespołu – przez cały czas trwania spotkania, Scrum Master nie zabiera głosu w kwestii upływającego czasu. Po zakończeniu spotkania, które przekroczyło swój limit, przekazuje swoją obserwację do zespołu, mówiąc przykładowo: „Chłopaki, przekroczyliście limit czasu, przewidziany na to spotkanie. Co zrobicie jutro, aby wyrobić się w 15 minut?”
  • parking (ang. Parking Lot) – wymaga sprawnej moderacji ze strony Scrum Mastera. Za każdym razem, kiedy ktoś z zespołu zaczyna odchodzić tematycznie od formuły spotkania lub opowiada zbyt szczegółowo, albo nie na temat, interweniuje Scrum Master: „To interesujący temat, zaparkujmy go i omówmy po spotkaniu, OK?”. Tematy „zaparkowane” można omówić zaraz po Daily Scrumie albo w innym dogodnym terminie.
  • zakończenie spotkania (kontrowersyjne)– równo po 15 minutach Scrum Master mówi: „Panowie, czas nam upłynął. Koniec spotkania.” – licząc oczywiście, że zespół odczyta to zachowanie w pożądany sposób i zmodyfikuje swoje podejście do spotkania

Oczywiście nie ma jednej idealnej techniki, które zapewni sukces. Wszystko zależy od składu oraz doświadczenia zespołu. W dojrzałych zespołach nie ma konieczności kontrolowania przebiegu spotkania, ponieważ każdy z członków zespołu robi to niejako niezależnie, moderując spotkanie we własnym zakresie – w początkowym okresie rozwoju teamu podparcie się technikami może jednak okazać się pomocne.

Utrzymanie limitu czasowego to nie jedyna trudność podczas codziennego spotkania zespołu – poważnym wyzwaniem jest bowiem osiągnięcie celu spotkania, czyli przygotowalnie planu działań na najbliższe 24 godziny.

Udzielenie odpowiedzi przez każdego z członków zespołu na 3 podstawowe pytania ze Scrum Guide to tylko wierzchołek góry lodowej – ale o tym przy innej okazji.

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

Naprawdę szybkie szacowanie Rejestru Produktu

Szybkie szacowanie Rejestru Produktu

Szybkie szacowanie Rejestru Produktu

Planning poker jest świetną techniką estymacji zadań, jednak dosyć czasochłonną. Osiągnięcie przez zespół porozumienia, co do złożoności konkretnego zadania, wymaga czasu. Szacowanie Rejestru Produktu planning pokerem, który składa się z kilkudziesięciu elementów, zajęło by co najmniej kilka godzin.

Co zatem zrobić, jeśli mamy duży Rejestr Produktu pozbawiony estymat i chcemy szybko je uzyskać?

Jest na to prosty i sprawdzony sposób, wymagający zaangażowania całego zespołu, jednak efekty można uzyskać w czasie krótszym niż godzina.

Co potrzebujemy?

  • duże pomieszczenie
  • czyste kartki papieru z naniesioną skalą szacowania
  • wydrukowane bądź spisane elementy Rejestru Produktu na oddzielnych kartkach
  • pisaki / długopisy

Jak przebiega szybkie szacowanie Rejestru Produktu?

  1. Rozkładamy w rzędzie kartki z wypisaną skalą estymacji (ciąg Fibonacciego, kolejne potęgi liczby dwa, rozmiary koszulek, itp.) na podłodze
  2. Moderator ustala główną zasadę: uczestnicy nie rozmawiają podczas ćwiczenia – pomaga to w szybkim przeprowadzeniu szacowania
  3. Uczestnicy dzielą się pomiędzy sobą przygotowanymi kartkami z elementami Rejestru Produktu i przypisują je do wcześniej rozłożonych kartek z estymatami
  4. Każdy z uczestników powinien zapoznać się z propozycjami estymat wszystkich elementów
  5. W przypadku, gdy uczestnik nie zgadza się z przypisaniem elementu Rejestru Produktu do konkretnej estymaty, może przenieść element do innego rzędu, pamiętając, że zmiana estymaty powinna zostać oznaczona – np. kropką na przenoszonym elemencie
  6. Jeżeli element otrzyma 3 kropki (co oznacza, że estymata dla niego została zmieniona trzy razy), powinien zostać przeniesiony do kolumny oznaczonej jako znak zapytania – elementy takie wymagają wyjaśnienia
  7. Podobnie, jeśli element Rejestru Produktu jest nie jasny, uczestnik może przenieść go do kolumny ze znakiem zapytania
  8. Ćwiczenie kończy się, gdy wszyscy uczestnicy zapoznają się z wszystkimi elementami Rejestru Produktu wraz z ich estymatami
  9. Elementy niejasne, czyli przeniesione do kolumny ze znakiem zapytania powinny zostać objaśnione przez Właściciela Produktu, a następnie powinny zostać oszacowane przez uczestników w kolejnej rundzie ćwiczenia.

Na co zwrócić uwagę?

  • warto zachować proporcjonalne odległości pomiędzy kartkami z estymacjami, czyli np. jeśli stosujemy ciąg Fibonacciego, to fizyczna odległość pomiędzy kartką z wartością 1 oraz kartką z wartością 2 powinna być mała, natomiast odległość pomiędzy kartką z wartością 21 oraz kartką z wartością 34 powinna być zdecydowanie większa. Generalnie, im większa różnica pomiędzy sąsiadującymi estymatami tym większa fizyczna odległość kartek:

  1 2  3   5     8        13                 21                              34 …

  • konieczna jest silna moderacja ćwiczenia – pokusa porozmawiania z resztą uczestników w przypadku wątpliwości co do elementu Rejestru Produktu jest duża. Jeśli szacowanie ma być naprawdę szybkie, na rozmowy w trakcie szacowania nie ma miejsca
  • oszacowania nie będą tak dokładane jak przygotowane planning pokerem, ale mogą na etapie początkowym okazać się wystarczające – być może element Rejestru Produktu wyceniony na 144 punkty (zakładając, że to bardzo wysoka estymata) straci dla Właściciela produktu na znaczeniu ze względu na zbyt duży koszt
  • tak przygotowany Rejestr Produktu należy doprecyzowywać podczas jego cyklicznej pielęgnacji (ang. grooming), dzieląc jego elementy na mniejsze części, dodając kryteria akceptacji, ponownie estymująć, oraz – w razie potrzeby – zupełnie usuwając z Rejestru Produktu.

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

Dot voting, czyli nadawanie priorytetów głosując kropkami

Przykładowe głosowanie kropkami

Przykładowe głosowanie kropkami

Podczas Retrospektyw, często dochodzimy do momentu, kiedy konieczne jest wybranie obszarów, nad których poprawą zespół będzie pracował w kolejnych Sprintach. Skutecznie przeprowadzone spotkanie powinno zaowocować dużą liczbą pomysłów, spośród których trzeba wybrać kilka najważniejszych.

Możemy podejść do tego problemu w różny sposób, na przykład nadając priorytety pomysłom. Istnieje jednak inny, bardzo prosty sposób, który dodatkowo silnie angażuje zespół, a mianowicie – głosowanie kropkami (ang. dot voting).

Co potrzebujemy?

  • duże arkusz papieru, najlepiej z możliwością przyklejenia na ścianę (ew. tablica suchościeralna)
  • pisaki / długopisy

Jak przebiega dot voting?

  1. Przedstawiamy zespołowi listę pomysłów (usprawnień, obszarów, scenariuszy, itp.) które zostały wypracowane podczas Retrospektywy i zapisane na dużym arkuszu papieru
  2. Każdy uczestnik otrzymuje pisak i możliwość postawienia określonej liczby kropek przy wybranych pomysłach
  3. Moderator (najczęściej Scrum Master) zlicza głosy – „wygrywają” pomysły, które otrzymały największą liczbę głosów

Na co zwrócić uwagę?

  • liczba kropek do dyspozycji każdego uczestnika wynika z ustalenia przed rozpoczęciem głosowania – nie ma tutaj szczególnych reguł,
  • można głosować raz na określony pomysł, albo wzmacniać ważność jednego konkretnego, oddając na niego więcej niż jeden głos,
  • technikę można wykorzystać na każdym innym spotkaniu, podczas którego konieczne jest np.: wyłonienie zwycięskich pomysłów, nadanie priorytetów zdarzeniom, wybranie najważniejszych obszarów do poprawy, itd.

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

Pomysł na Retrospekcję Sprintu – technika 4L

Pomysł na retrospekcję - technika 4L

Pomysł na retrospekcję – technika 4L

Przeglądając ostatnio zagraniczne blogi, trafiłem na ciekawą technikę przeprowadzenia Retrospekcji Sprintu, nazwaną przez autorkę The 4L’s.

Ta pozornie prosta technika przeprowadza retrospekcji potrafi dać naprawdę ciekawe rezultaty, ze względu na odpowiednio dobrane słowa, które zachęcają do spojrzenia na przeszłość z różnych perspektyw.

Lekko zmodernizowaną wersję tego ćwiczenia znajdziecie poniżej:

Co potrzebujemy?

  • cztery duże arkusze papieru, najlepiej z możliwością przyklejenia na ścianę
  • cztery bloczki kartek samoprzylepnych w różnych kolorach
  • pisaki / długopisy

Jak przebiega Retrospektywa?

  1. Przygotowujemy cztery duże arkusze papieru i wpisujemy na górę każdego arkusza odpowiedni nagłówek, tworząc obszar, na którym chcemy się skupić:
    • podobało mi się… (Liked)
    • nauczyłem się… (Learned)
    • brakowało mi… (Lacked)
    • tęskniłem za… (Longed for)
  2. Każdy członek Zespołu indywidualnie zapisuje cztery osobne kartki, obrazujące co mu się podobało w trakcie Sprintu, czego się nauczył, czego mu brakowało oraz za czym tęsknił. Następnie przykleja swoje kartki do odpowiednich arkuszy na ścianie
  3. Dzielimy zespół na cztery grupy – każda grupa otrzymuje jeden arkusz, zapoznaje się z kartkami stworzonymi przez Zespół, a następnie grupuje podobne kartki razem oraz identyfikuje główne tematy
  4. Każda grupa przedstawia reszcie Zespołu główne tematy z ich obszaru
  5. Zespół – stosując np. technikę głosowania kropkami – wybiera 3 tematy, które chce omówić

Na co zwrócić uwagę?

  • można modernizować obszary w ramach których się poruszamy, jednak autorka zaleca, aby nie rezygnować z obszaru „tęskniłem za” i ma rację. Sprawdziłem tę technikę w Zespole i faktycznie obszar ten potrafi dostarczyć ciekawej wiedzy od Zespołu.
  • jeśli mamy więcej czasu, możemy spróbować omówić wszystkie zgłoszone tematy – wymaga to jednak sprawnej moderacji spotkania

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

Pociski smugowe, czyli szybkie dostarczanie wartości

Pociski smugowe w grze

Pociski smugowe w grze

Zanim internet zawitał na stałe do naszych domów, zamiast grania online spotykaliśmy się we własnych domach i używając techniki gorącego krzesła spędzaliśmy czas grając w proste, ale strasznie miodne gry.

Jedną z takich gier, przy których spędziliśmy setki godzin, była gra Scorched Earth. Zasada była prosta – każdy gracz ma swój czołg, którym wystrzeliwał pocisk w pozostałych graczy. Wygrywał ostatni pozostały na placu boju. Celowanie odbywało się poprzez ustawienie kąta strzału oraz jego mocy. Charakterystyczna była smuga, która powstawała po wystrzale. Pozwalała ona precyzyjniej wycelować w kolejnej turze. Jej brak znacząco utrudniał grę i zmniejszał celność graczy.

Pociski smugowe w programowaniu

Pociski smugowe bywają wykorzystywane przez programistów – pomagają im one dosięgnąć celu w trudnych warunkach, które wynikają z niełatwego zadania kompletowania wymagań użytkowników.

Zasada ich działania jest bardzo prosta. Możemy podejść do rozwoju oprogramowania na dwa sposoby:

  1. określając na starcie bardzo precyzyjnie wymagania systemu, ograniczenia, niewiadome oraz ograniczenia środowiska, tak by za jakiś czas – po zakodowaniu oraz integracji wszystkich funkcji –  przekazać gotowe rozwiązanie użytkownikom,
  2. szukając rozwiązań, które w szybki i tani sposób przeniosą nas od koncepcji do działającego systemu, który – pomimo surowości oraz braku wszystkich funkcji – będziemy mogli wkrótce czasie pokazać użytkownikom, aby uzyskać od nich informację zwrotną i zadecydować, czy chcą rozwijać system dalej, czy to co zobaczyli jest dla nich wystarczające.

Drugie podejście jest nieco trudniejsze – wymaga od zespołu tworzenia kompletnych rozwiązań end-to-end w trakcie pojedynczej iteracji, jednak efekt wart jest wysiłku.

Co to oznacza w praktyce?

Załóżmy, że mamy stworzyć prosty proces zakupowy składający się z 3 kroków:

  • KROK 1: dodanie produktu do koszyka
  • KROK 2: wybór adresu dostawy, rodzaju płatności oraz sposobu dostawy
  • KROK 3: wysłanie zamówienia

Podejście pierwsze

Po określeniu precyzyjnych wymagań na starcie, efektem pierwszego tygodnia prac może być dobrze zaimplementowany pierwszy krok procesu – możemy dodać produkt do koszyka. Możemy podać liczbę przedmiotów, zwiększać oraz zmieszać ich liczbę, a także zobaczyć zdjęcia obrazujące produkt wraz z ich opisem.

Efekt: Nie możemy de facto zrealizować zamówienia – dysponujemy wyłącznie jednym krokiem z trzech.

Podejście drugie

Wystrzeliwujemy pocisk smugowy. W trakcie tygodnia pracy implementujemy kompletny proces, składający z trzech kroków, który pozwala nam faktycznie zrealizować zamówienie. Oczywiście, możemy dodać tylko jeden przedmiot do koszyka, nie wyświetlamy zdjęć produktu, musimy ręcznie wpisać adres dostawy (nie napisaliśmy jeszcze modułu logowania), a zapłacić można tylko przy odbiorze przesyłki.

Efekt: Pomimo surowości rozwiązania, możemy zrealizować zamówienie. Możemy również pokazać rozwiązanie użytkownikom i zapytać, czy zmierzamy w dobrym kierunku.

Na koniec…

Ważna sprawa – stosowanie pocisków smugowych nie oznacza rezygnacji z jakości. Pamiętamy o obsłudze błędów, dokumentacji czy ogólnej walidacji danych. Obszar, którym możemy sterować, to liczba funkcji, którą decydujemy się zaimplementować.

Życzę udanych strzałów :)

Źródło zdjęcia: http://en.wikipedia.org/wiki/File:Scorched_Earth_gameplay.png