5 sposobów na udany Sprint w Scrumie

Pomimo dużej popularności Scruma, organizacje nadal mają problem z regularnym dostarczaniem przyrostu produktu. Pracując jako zewnętrzny konsultant, niemal codziennie spotykam się z problemem nieudanych Sprintów, powodujących niezadowolenie zarówno Zespołu Scrumowego, jak i interesariuszy. W tym artykule przedstawię 5 praktycznych porad, które na bazie mojego doświadczenia, najskuteczniej zwiększają szanse na udany Sprint.

Oto one.

1. Przygotuj jasny i zrozumiały Cel Sprintu

Przyznam, że rzadko spotykam dobrze zdefiniowane Cele Sprintu.

Cele, jakie obserwuję najczęściej, są:

  • Zbyt ogólne, np. “Landing page”,
  • Hermetyczne, zrozumiałe tylko dla Zespołu Deweloperskiego (np. “Kiełbasa śląska” – nie żartuję),
  • Czysto ewidencyjne, np. “Sprint 7”, lub
  • Kompletnie przemilczane podczas Planowania Sprintu, co w praktyce oznacza, że nie ma ich wcale

Gdy zaczynałem przygodę ze Scrumem, nie przykładałem tak dużej uwagi do rozmowy o Celu Sprintu. Dzisiaj, na niemal wszystkich płaszczyznach moich działań, zaczynam od zadawania sobie, oraz innym, pytania “po co” coś robimy.

Tym bardziej nie wyobrażam sobie wartościowego planowania Sprintu, podczas którego nie jest dyskutowany oraz przygotowywany Cel Sprintu. Pomaga on m.in:

  • zrozumieć kontekst biznesowy,
  • wspiera pracę zespołową, oraz,
  • daje swobodę wyboru konkretnych rozwiązań w Sprincie.

O tym, jak w praktyce tworzyć wartościowe cele, pisałem w artykule tłumaczącym czym jest Cel Sprintu w Scrumie.

2. Opracuj porządny plan realizacji Celu Sprintu

Możliwości interpretowania pojęcia “zaplanowania pracy” są właściwie nieskończone.

Dla jednego zespołu zaplanowanie Sprintu to po prostu przerzucenie elementów z Backlogu Produktu do Backlogu Sprintu. 15 minut i po robocie.

Dla innego zespołu planowanie oznacza 2-3 godzinną dyskusję o tym, jak najmądrzej i efektywniej podejść do realizacji Celu Sprintu.

Czym dla mnie jest dobrze przygotowany plan pracy? Zwykle przyjmuje on postać diagramu, rysunku lub po prostu listy kroków, które trzeba wykonać, aby osiągnąć Cel Sprintu.

W mojej książce “Labirynty Scruma” rekomenduję czytelnikom rozważenie podczas Planowania Sprintu takich kwestii jak:

  • kolejność wykonywania zadań (np. od których zadań zaczynamy pracę), zależności zewnętrzne (np. od innych zespołów lub dostawców),
  • zależności wewnętrzne (np. zależności pomiędzy pracą osób wewnątrz zespołu lub zależności warstwy prezentacji aplikacji od warstwy logiki biznesowej),
  • dostępność Zespołu Deweloperskiego (np. nieobecność części zespołu ze względu na urlopy lub odbywane szkolenie),
  • dostępne kompetencje Zespołu Deweloperskiego (np. uwzględniające znajomość marketingu lub zasad projektowania interfejsów użytkownika),
  • wszelkie niejasności (np. brakujące szczegóły elementów Backlogu Produktu, które mimo wszystko nie blokują pracy),
  • ryzyko (np. związane z zależnością od usługi zewnętrznej).

Powyższe punkty warto mieć podczas planowania pod ręką, np. w postaci punktów wypisanych na flipcharcie.

Jak takie planowanie może wyglądać w praktyce? Szczegółowy opis przygotowania dobrego planu znajdziesz w moim artykule o wizualnym tworzeniu planu Sprintu.

—————

Najbliższy warsztat

Warsztat „Labirynty Scruma” — Warszawa — 23-24 września: podczas autorskiego warsztat na bazie mojej książki, przepracuję z Tobą najczęstsze pułapki w Scrumie oraz wskażę sprawdzone sposoby, jak sobie z nimi radzić.

—————

3. Wspieraj bliską współpracę osób w Zespole Deweloperskim

Każdy zespół składa się z grupy osób, ale nie każda grupa osób jest zespołem. Najlepsze efekty pracy doświadczałem lub obserwowałem w zespołach, które stanowiły zgraną, blisko współpracującą drużynę.

Gdy wspieram świeżo startujące Zespoły Scrumowe, lubię obserwować to, jak transformują się z grupy osób w zespół.

Na początku zwykle obserwuję brak zaufania, formułowanie bardzo ostrożnych wypowiedzi, unikanie różnicy zdań i dosyć powierzchowne dotykanie problemów.

Wraz ze zdobywanym doświadczeniem i dogłębnie przeprowadzanymi Retrospektywami Sprintu, zaczyna się pojawiać pierwiastek zespołowości. Ludzie zaczynają się otwierać i ufać sobie. Pojawia się większe poczucie odpowiedzialności za działania oraz pierwsze efekty bliższej niż zwykle współpracy.

Dojrzałe zespoły znają swoje słabe i mocne strony, nie boją się podnosić sobie poprzeczki i umieją wykorzystywać potencjał multidyscyplinarnej współpracy.

Na bazie mojego doświadczenia, rozwijanie umiejętności współpracy w zespole można wzmocnić poprzez:

  • Jasno określony cel – Każdą większą inicjatywę rozpoczynam od określenia jednoznacznego celu. Dobry cel potrafi skupić uwagę zespołu na tym, co ważne. Daje poczucia grania do jednej bramki, buduje poczucie odpowiedzialności i naturalnie przesuwa myślenie z “ja” na “my”.
  • Pracę w parach lub grupach – Bardzo dobre efekty w kontekście pracy zespołowej obserwuję w drużynach, w których nad konkretnymi tematami do zrealizowania pracują pary lub małe, 3-4 osobowe, grupy. W tak małych grupach sprawniej ujawniają się poszczególne talenty członków zespołu oraz szybciej rodzą się między nimi relacje. Warto w tym przypadku zwrócić uwagę na to, żeby wiedza zdobyta przez grupę została przekazana do zespołu, aby nie nie tworzyć lokalnych silosów wiedzy.
  • Zbudowanie kontraktu, umówienie się na zasady pracy – Brak przejrzystych zasad współpracy to pole do niedomówień i potencjalne ognisko konfliktów w zespole. Dobrą praktyką jest umówienie się wewnątrz zespołu na podstawowe zasady współpracy. Mogą one dotyczyć wielu aspektów, takich jak dzielenie się informacją zwrotną, umówione godziny pracy, punktualność, zarządzanie nieobecnościami czy sposób przeprowadzania spotkań.

Kontraktowanie to jeden z tematów, który poruszyliśmy z Kubą w naszym podcaście, a konkretnie w odcinku mówiącym o tym, co robi Scrum Master w nowym zespole. Warto tutaj wspomnieć, że zasady te są uniwersalne i niezależne od roli, w jakiej pracujemy w zespole.

4. Regularnie aktualizuj planu realizacji Sprintu

Bardzo często obserwuję dwie powiązane ze sobą pułapki, w które wpadają Zespoły Scrumowe:

  1. Podczas Planowania Sprintu nie powstaje porządny plan pracy,
  2. Codzienny Scrum nie daje odpowiedzi, jaki jest plan zespołu na nadchodzące 24 godziny.

O tym, jak uniknąć pierwszej pułapki i przygotować dobry plan, pisałem powyżej w punkcie “ Opracuj porządny plan realizacji Celu Sprintu”.

Nie wystarczy jednak jednorazowy akt planowania, aby zapewnić sobie sukces w Sprincie. Dlaczego tak się dzieje?

Każdy ma plan, dopóki nie zostanie trafiony” – powiedział Mike Tyson, bokserski mistrz świata wagi ciężkiej. Zespoły Deweloperskie, podobnie jak bokserzy, uczestniczą w złożonej rozgrywce, w której trudno precyzyjnie zaplanować, co się wydarzy. Cała sztuka polega na umiejętności reagowania na zmieniające się otoczenie.

Dojrzałe zespoły wykorzystują Codzienny Scrum do aktualizacji planu, który powstał podczas Planowania Sprintu. Na bazie bieżących wydarzeń w Sprincie, działań świata zewnętrznego, nowo zdobytej wiedzy produktowej czy materializacji ryzyk, członkowie zespołów zastanawiają się, jak zaktualizować plan, aby wspierał zespół w realizacji Celu Sprintu.

Przekładając to na język fundamentów Scruma, zespół dokonuje inspekcji planu i adaptuje go w ramach potrzeb.

Jedną z moich ulubionych technik, która pomaga wyjść z Codziennego Scruma z dobrym planem, jest użycie parafrazy. Technika ta polega na poproszeniu wybranej osoby z zespołu, aby na koniec popularnego “daily” opowiedziała własnymi słowami, jaki jest plan zespołu na nadchodzący dzień. Bardzo szybko można wyłapać w ten sposób niedomówienia, niewłaściwe zrozumienie intencji innych oraz zbytnie skupienie się na wyłącznie na swojej pracy.

O inspekcji i adaptacji pisałem jakiś czas temu, zdecydowanie szerzej niż tylko w kontekście Codziennego Scruma.

5. Ucz się od pierwszego dnia prac nad produktem

Charakterystycznym wyróżnikiem podejścia zwinnego jest akcent na wczesne uczenie się w trakcie rozwijania produktu. Każdy Sprint to okazja, aby nauczyć się czegoś nowego.

W przeciwieństwie do wielomiesięcznych projektów, gdzie określoną wiedzę zdobywamy dopiero w momencie wdrożenia rozwiązania, w podejściu zwinnym chcemy otrzymywać je na jak najwcześniejszym etapie.

Alistair Cockburn w swoim artykule “Disciplined Learning The Successor to Risk Management” opisuje cztery kategorie, w których możemy uczyć:

  • Biznesowa – kategoria ta odpowiada na pytanie “Czy budujemy właściwy produkt?”. Przykładowe strategie, które pozwalają uzyskać tę odpowiedź to product discovery oraz wczesne dostarczanie działającego produktu o obniżonych możliwościach.
  • Ludzka – odpowiada na pytanie “Czy zespół potrafi ze sobą współpracować?”. Przykładowe strategie to szybkie dążenie do małych zwycięstw i celebrowanie ich oraz skupianie się na dostarczaniu w pierwszej kolejności najprostszych rozwiązań, które będą rozgrzewką przed poważniejszymi problemami w przyszłości.
  • Techniczna – odpowiada na pytanie “Czy wiemy jak go zbudować?” Przykładowe strategie wspierające to tworzenie spike’ów (proste kawałki kodu, które pomagają Zespołowi Deweloperskiemu zdobyć wiedzę konieczną do dalszych działań) oraz dzielenie historii użytkownika na małe kawałki.
  • Kosztowa – odpowiada na pytanie “Czy wiemy, ile to będzie kosztować?”. Przykładowa strategia to próbkowanie, czyli wyodrębnienie z tworzonego produktu obszarów, co do których istnieje dużo znaków zapytania i pracowanie na tych obszarach celem zrozumienia ich złożoności.

Tego rodzaju spojrzenie na proces budowania produktów może być zaskoczeniem dla wielu organizacji, które pomimo deklaratywnego stosowania podejść zwinnych, w rzeczywistości stosują wyłącznie nowe nazwy na stare role, nawyki i przyzwyczajenia. Jak widać na powyższych przykładach, każdy Sprint może być narzędziem pomagającym nie tylko wytwarzać produkt, ale także uczyć się i na bieżąco zarządzać ryzykiem.

Podsumowanie

Udany Sprint w Scrumie to suma wielu drobnych decyzji oraz strategii, które połączone razem dają namacalne efekty. Aby osiągać satysfakcjonujące rezultaty, warto regularnie poddawać analizie sposób w jaki pracujemy, wyciągać wnioski i odważnie eksperymentować z alternatywnymi sposobami realizowanie codziennej pracy.

Chcesz dowiedzieć się więcej?

Tematy podobne to tych w artykule, będę poruszał 23-24 września w Warszawie, na moim pierwszym autorskim warsztacie na bazie książki “Labirynty Scruma”. Przez 2 dni będziemy przepracowywać najczęstsze pułapki w Scrumie oraz omawiać sprawdzone sposoby, jak sobie z nimi radzić. Jeśli chcesz w praktyczny sposób pogłębić swoją wiedzę o Scrumie, zapisz się na warsztat.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

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

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x