Metodyka Scrum

Scrum jest frameworkiem i to właśnie uparcie powtarzamy na szkoleniach, postach, artykułach, książkach i innych materiałach. Pomimo tego, bardzo ciężko jest przestawić się ludziom z mówienia, że Scrum to metodyka lub nawet metodologia Agile. W języku polskim framework, metodyka i metodologia mają zupełnie różne znaczenia i żadne z nich nie oddaje tego, czym jest Scrum. Kiedy się to zrozumie, od razu widać dlaczego Scrum nie daje wielu odpowiedzi wprost. Jednakże, nie wyklucza to zbudowania własnej metodyki w ramach Scruma. Czym dokładnie jest Scrum i skąd się wziął opisałem już w poście Scrum — czym jest, skąd pomysł i czym nie jest. Tutaj skupię się na tym dlaczego to jest framework a nie metodyka Scrum.

Framework a metodyka

Gdyby twórcy Scruma, Jeff Sutherland i Ken Schwaber chcieli, żeby Scrum był metodą albo metodyką to po prostu użyliby słowa method albo methodology. Spójrzmy jak bardzo różnią się te definicje w języku angielskim.

Scrum zatem jest niezbędna strukturą do zbudowania procesów zarządzania produktem i procesem wytwarzania produktu. Można powiedzieć, że na Scrumie można dopiero zbudować metodykę.

Framework po polsku

Trudno jest przetłumaczyć słowo framework na język polski bo tak naprawdę nie mamy odpowiednika, można powiedzieć szkielet, rusztowanie ale te słowa nie oddają sensu. W niektórych książkach z dziedziny IT proponuje się zrąb. Przewodnik po Scrumie proponuje ramy postępowania i to chyba jest najlepsze przybliżenie tego, o co chodzi. Nadal również zgodnie ze słownikiem języka polskiego nie można powiedzieć, że Scrum to metoda, a tym bardziej metodyka.

Dlaczego Scrum to framework

Scrum nie może być konkretną metodyką z prostej przyczyny. Scrum został zaprojektowany do działania w sytuacjach złożonych. Sytuacja jest złożona kiedy jest więcej niewiadomych niż wiadomych. W tej sytuacji nie można z góry zaprojektować sposobu działania i nie można rozwiązać problemu przez wdrożenie najlepszych praktyk. Nie można zatem stworzyć z góry planu (planowanie predykcyjne), który doprowadzi do osiągnięcia celu. W sytuacji złożonej możemy skorzystać z procesu empirycznego. Wykonujemy różne techniki, sprawdzamy jaki skutek przynoszą i dostosowujemy się. Jeśli technika zadziała, to ją zostawiamy. Jeśli technika nie działa to próbujemy innej. Scrum nie proponuje konkretnych technik, bo w zależności od kontekstu mogą się sprawdzić albo nie.

Scrum wymaga jedynie zachowania pewnych ram. Skup się na jednym produkcie. Zrób jedną listę rzeczy do zrobienia dla produktu (Product Backlog). Umocuj jedną osobę do podejmowania decyzji (Product Owner). Próbuj budować przyrosty produktu z małym zespołem (Development Team) w stałych odcinkach czasu (Sprint). Najpierw zaplanuj co i jak chcesz zrobić (Sprint Planning). Na koniec każdego takiego odcinka czasu sprawdź jak Ci idzie budowanie produktu (Sprint Review) i sprawdź czy możesz usprawnić proces (Sprint Retrospective). Ktoś powinien przyglądać się procesowi i zapewniać zespołowi to co potrzebne (Scrum Master). 3 role, 3 artefakty, 5 wydarzeń. Tyle wystarczy. Środek wypełnij swoimi praktykami.

Framework Scrum specjalnie zostawia wiele pustych obszarów do wypełnienia swoimi praktykami z dwóch powodów. Jeden został opisany już wyżej. Nie istnieje coś takiego jak najlepsze praktyki do rozwiązywania złożonych problemów i nie można zdefiniować jednego sposobu działania, który zawsze się sprawdzi.

Drugi powód to uniwersalność zastosowań Scruma. Od pewnego czasu obserwuje się coraz więcej zastosować Scrum poza IT. Na świecie ze Scruma korzystają już miliony ludzi, więc nie można napisać Metodyki Scrum, która  zadziała w tak bardzo wielu różnych kontekstach, które różnią się produktem, zespołami, technologią i kontekstem biznesowym. Przeglądając wersje Scrum Guide od 2009 do 2017 można zauważyć, że framework został odchudzony.

Zbuduj metodykę w ramach Scrum

Zbuduj własną metodykę w ramach Scrum. Jak to zrobić? Wypełniając framework praktykami Agile, które u ciebie mogą zadziałać. Spójrzmy czego Scrum nie definiuje i trzeba to samodzielnie określić.

• Jaka jest optymalna długość Sprintu?
• Skąd się bierze Product Owner?
• Skąd Product Owner ma budżet?
• Jak powstaje Product Backlog?
• W jaki sposób zapisywane są Product Backlog Items?
• Jak określana jest wartość Product Backlog Items?
• W jaki sposób są określane priorytety i w końcu porządek Product Backlog?
• Skąd się bierze Zespół Deweloperski?
• Jak przebiega Planowanie Sprintu?
• Jak zespół wizualizuje swoją pracę?
• Kiedy i jak Zespół Deweloperski komunikuje się z Product Ownerem i interesariuszami?
• Jak przebiega Daily Scrum?
• Kiedy jest i jak wygląda Product backlog Refinement?
• Jak przebiega Przegląd Sprintu?
• Jak przebiega Retrospekcja Sprintu?
• Jak wygląda ustalanie Definition of Done? Co standardowo powinno się tam znajdować?
• Jak planujemy wydania i kiedy wdrażamy się na produkcję?

W ramach transformacji do Agile czasem potrzebny jest playbook, żeby ustalić wspólny standard dla całej organizacji jako punkt startu. Z czasem taki playbook stanie przestarzały albo zbyt opasły, żeby był użyteczny. Zwykle na początku organizacja ma duży nacisk na standaryzowanie Scruma, a z czasem wraca do podstaw i najprostrzych rzeczy, które mogą zadziałać.

Implementacja Scruma może różnić się pomiędzy zespołami i to jest naturalne. Co zadziałało w jednym zespole nie koniecznie zadziała w drugim tak samo dobrze. W dużej organizacji może być potrzeba uspójnienia pewnych elementów takich jak synchronizacja Sprintów czy standard Definition of Done. Ale nadal trzeba pozostawić przestrzeń do eksperymentowania zespołom.

Podsumowanie

Nie ma czegoś takiego jak metodyka Scrum. Scrum to framework, czyli zbiór niezbednych elementów wyznaczających ramy. Nic jednak nie stoi na przeszkodzie, żeby zbudować własną metodykę w ramach Scruma. Każdy zespół może mieć własną metodykę z pewnymi elementami narzuconymi przez organizację. Z czasem ta metodyka Scrum będzie ewoluwała, bo przecież w ramch Scruma mamy też ciągłe ulepszanie.