Teza na dziś: Scrum nie jest elastyczny. Możemy wypełnić pomysłami jego ramy, ale te są sztywne. Czy elastyczność (ang. flexibility) i zwinność (ang. agility, chociaż częściej po prostu agile) mają ze sobą cokolwiek wspólnego?
Agile vs Flexibility
Również w języku polskim „zwinność” i „elastyczność” są zbliżone znaczeniowo. W naszym światku IT przyjęło się, że zwinność i bycie agile odnosi się do reagowania na zmieniające się potrzeby i priorytety. Zakładamy, że w miarę postępów prac dowiemy się więcej zarówno o wymaganiach, jak i o życzeniach. Interesariusze, widząc częściowe rozwiązania (patrz: iteracyjne i przyrostowe tworzenie oprogramowania), mogą z większym zdecydowaniem stanowić o dalszym kierunku prac. Tyle zwinność.
Elastyczność znaczyła będzie coś zupełnie innego. Wyjaśnijmy ją na antyprzykładzie. Obsługa błędów lawinowo wpadających ze środowiska produkcyjnego (czytaj: wrzutki) nie należy w Scrumie do najłatwiejszych. Gdybyśmy byli elastyczni, moglibyśmy dostosowywać proces do aktualnych warunków (czytaj: długu technologicznego). Tymczasem Scrum mówi – nowa praca zawsze ląduje w backlogu, a jeśli już musi trafić na bieżący Sprint, to tylko w wyniku negocjacji Development Teamu i Product Ownera.
W podobny sposób, gdyby Scrum był elastyczny, moglibyśmy wydłużyć Sprint o jeden dzień, żeby „dowieźć” zakres bądź rozszerzyć go o kilka dni z powodu natłoku dni ustawowo wolnych od pracy.
Jeżeli chcemy pracować w zgodzie ze Scrum Guidem, mamy bardzo mało możliwości dostosowywania czy naginania zasad. Inaczej bardzo szybko lądujemy w czymś, co nazywamy ScrumBut.
Elastyczność w Scrum
Scrum nie jest elastyczny i kropka. Zawiera trzy role, trzy artefakty, pięć wydarzeń i kilka innych elementów, które razem dają kompletny przepis, dzięki któremu „ludzie mogą adaptacyjnie rozwiązywać złożone problemy tak, by w produktywny i kreatywny sposób wytwarzać produkty o najwyższej możliwej wartości.”
Sposób, w jaki możemy dostosować Scrum zasadniczo ogranicza się do detali. Możemy sami określić długości timeboxów dla wydarzeń przy Sprintach krótszych niż miesiąc. Mamy duży wpływ na formę przeprowadzania Product Backlog Refinementów. Także od zespołów zależy sposób utrzymania fizycznych reprezentacji niektórych artefaktów oraz korzystanie (bądź nie) z technik wizualizacji pracy i jej postępów (tablice, wykresy, itp.).
Co jeszcze? Możemy sami wybrać, w jaki sposób będziemy opisywać i szacować wymagania oraz jak dokładnie realizować cel Planowania Sprintu, Sprint Review i Retrospektywy. Znajdzie się pewnie jeszcze dosłownie parę rzeczy, w ramach których mamy dowolność i elastyczność.
Proces Scrum, łącznie z jego otoczką w postaci wydarzeń i ról, jest sztywny. Nawet rzeczy, które możemy zmieniać, jak długość Sprintu czy skład zespołów zawierają ostrzeżenia mówiące, żeby nie ruszać ich za często. Nie mamy też okazji zorganizować sobie życia poza Sprintami, bo wszystko musi być realizowane w ten sam, standardowy sposób. Nie mamy nawet „Sprintów wdrożeniowych”.
Flexibility, czyli zagrożenie
Większa elastyczność, to większe zagrożenie, że coś pójdzie nie po naszej myśli bądź niezgodnie z naszymi oczekiwaniami. Co do tego nie mamy żadnych wątpliwości.
Z naszego doświadczenia wynika, że typowe problemy z wdrażaniem Scruma wcale nie dotyczą elastycznej części metodyki, tylko tej sztywnej. Bo to najczęściej Daily Scrum staje się spotkaniem statusowym, Sprint Review degradowane jest do demo, a Sprint Retrospective jest pomijane. Idąc dalej – pracujemy z zadaniami, zamiast wymaganiami i tak naprawdę realizujemy „scrumowy projekt”, zamiast tworzyć produkt.
Strach pomyśleć, co by się stało, gdyby Scrum był faktycznie elastyczny i pozwalał na jeszcze większą dowolność. Zresztą, przykładów wcale nie musimy szukać daleko…
Podobną zależność obserwujemy chociażby w temacie naszych ulubionych User Stories. Im mniej szczegółów podamy w kryteriach akceptacji, tym większa szansa, że Zespół Deweloperski może nas zaskoczyć sposobem realizacji danego wymagania. A to znaczy, że może nas także zaskoczyć negatywnie. Z kolei przesadzenie w drugą stronę zupełnie zabije kreatywność.
Pomijając szukanie złotego środka, która opcja będzie dla nas lepsza?
Elastyczność na przykładzie DSDM
Jeżeli chcemy spojrzeć na bardziej elastyczne podejście zwinne, wcale nie trzeba szukać daleko. W agile’owym światku istnieje metodyka zarządzania projektami o nazwie DSDM. I tam faktycznie znajdziemy o wiele większą dowolność. Na przykład zapisane jest tam wprost, że Timeboxy (odpowiedni scrumowych Sprintów) mają „zasadniczo” stałą długość, ale mogą być skracane bądź wydłużane, szczególności w przypadku nieobecności bądź świąt.
Elastycznych elementów DSDM jest o wiele więcej. Sporo produktów tejże metodyki jest dobrowolnych i wcale nie jest powiedziane, że muszą powstać ich namacalne reprezentacje. Przykładów można by mnożyć wiele i patrząc na same zasady, DSDM faktycznie można określić mianem elastycznego. Tylko czy to dobrze?
Sprawa z DSDM wygląda o tyle ciekawie, że ta metodyka zwykle jest zupełnie nieznana fanom Scruma i Scrum Masterom. Z drugiej strony pełno jest osób posiadających certyfikaty z pod znaku AgilePM. Z trzeciej zaś, ze świecą można szukać projektów prowadzonych DSDM-em.
Moim zdaniem „sztywność” Scruma ułatwia zdecydowanie się na ten sposób pracy. Precyzyjny przepis sprawia, że nie musimy na starcie podejmować fundamentalnych decyzji, których konsekwencji możemy nie znać. Zbyt duża elastyczność powoduje, że tak naprawdę nie wiemy na co się zdecydować i w jaki sposób mamy działać.
Wydaje się, że „sztywny” Scrum, który można wypełnić i obudować swoimi praktykami sprawdza się lepiej, niż podejścia bardziej elastyczne jak chociażby wspomniany DSDM, Kanban czy „stare dobre” XP. O wiele łatwiej jest zaakceptować bądź odrzucić konkret.
Tylko tu już niebezpiecznie zbliżamy się do okolic przerośniętych metodyk w rodzaju SAFe’a, więc pora chyba kończyć dzisiejszy tekst.
Wesołych Świąt!
