Po części zaczepnie, a po części bardzo na serio. Jaka jest największa wada Scruma? Z punktu widzenia każdego konkretnego zespołu może to być coś innego. Ale jeżeli popatrzymy na problemy, z jakimi się mierzymy w naszym scrumowym życiu, to bardzo szybko dojdziemy do jednego wniosku. Największą jego wadą jest to, że Scrum nie jest dla każdego.
Największa wada Scruma
Temat wad naszej ulubionej iteracyjnej metodyki poruszaliśmy już wielokrotnie. Już trzy lata temu podaliśmy 5 powodów, dla których Scrum nie zadziała w Twojej firmie. Ostatnio nagraliśmy też film o problemach, jakie Scrum powoduje. Z kolei tydzień temu na naszej liście mailingowej rozesłaliśmy parę porad na temat tego, kiedy zdecydować się na Scrum, a kiedy patrzeć w stronę Kanbana. I tu mała dygresja, jeżeli dopiero teraz subskrybujesz naszą listę, a interesuje Cię ten temat, to po prostu odpowiedz na e-mail powitalny, a podeślemy Ci kopię tej wiadomości. Ale wróćmy do dzisiejszego tematu.
Scrum nie jest prosty do wdrożenia, to raz. Dwa – jego siła leży w korekcji błędów i odstępstw, a nie w ich zapobieganiu. Jeżeli ktoś szuka metody niezawodnej od startu, to może się srogo rozczarować. Po trzecie zaś, nie wszędzie da się go dopasować. Nie wszędzie też my damy radę dopasować naszą organizację i nasze zespoły do wymagań Scruma. I tu właśnie zmierzamy do sedna największej wady Scruma. Nie tylko nie nadaje się do wszystkiego, ale w dodatku nawet w swoim wąskim zakresie nie jest idealny. Wyciąga problemy, zmusza nas do zoptymalizowania naszych własnych procesów i bardzo często zupełnie innego spojrzenia na problemy niż jesteśmy przyzwyczajeni.
„Jeżeli szukamy takiej metodyki, która idealnie opisuje stan bieżący, to mamy fundamentalny problem. Nie szukamy usprawnień, tylko uzasadnienia status quo.” – #białko
Scrum w większości przypadków wymiana zmian nastawienia. Agile mindset to temat rzeka, a „Scrum mindset” dokłada do niego jeszcze więcej wymagań.
The Scrum Mindset
„Scrum to uproszczone ramy postępowania, które pomagają poszczególnym osobom, zespołom i organizacjom wytwarzać wartość poprzez adaptacyjne rozwiązywanie złożonych problemów.” – Scrum Guide
Adaptacyjne (iteracyjne i przyrostowe) podejście Scruma to jeden z pierwszych elementów, jaki jest opisany w Przewodniku po Scrumie (ang. Scrum Guide). To znaczy, że nasze rozwiązanie będzie powstawało etapami, w dodatku krótkimi i regularnymi (patrz: Sprint). Czyli to, czym się zajmujemy musi być możliwe do zrealizowania w taki właśnie sposób.
Po drugie, oczywiście, musimy mieć do rozwiązywania złożone problemy. Nie proste, ale takie, które musimy najpierw rozpoznać bojem, aby je rozwikłać. Z definicji nie możemy tutaj zrobić „szczegółowego planu całego projektu”, bo jest on złożony, tzn. niemożliwy do ogarnięcia przed zagłębieniem się w niuanse związane z jego realizacją. I żeby nie było niejasności, przez „zagłębienie się” mamy na myśli „rozpoczęcie realizacji”, a nie teoretyzowanie.
Im dalej będziemy czytać nasz Scrum Guide, tym więcej wymagań znajdziemy. A to chodzi o odpowiednie nastawienie osób, czyli Wartości Scrum, a to dla odmiany napotkamy na konieczność współpracy z otwartym i zaangażowanym klientem, który faktycznie chce uczestniczyć w tym całym zwinnym wytwarzaniu produktu. Sam backlog, czyli zmienna lista wymagań to też nie lada wyzwanie dla tych, którzy chcą z góry znać zakres i koszt złożonego przedsięwzięcia. Tego, które jak sobie przed chwilą powiedzieliśmy jest niedookreślone i jego ostateczna forma, jak to się pięknie mówi, „wyjdzie w praniu”.
Im dalej w las, tym więcej znajdziemy różnego rodzaju małych i dużych niuansów, które przy pierwszym zapoznaniu się ze Scrumem są zupełnie ignorowane. Gdzie znaleźć Product Ownera? Czy jesteśmy gotowi na to, że jakiś Sprint „nie pójdzie” i nie wytworzymy w jego trakcie żadnej znaczącej wartości? Co powiedzą na to nasi klienci? Czy mamy czas na wszystkie wydarzenia Scrum i ufamy samozarządzającym się zespołom? I tak dalej, i tak dalej…
Czy Scrum jest dla każdego?
Nie, Scrum nie jest dla każdego. Poza naszkicowanym powyżej nastawieniem, musimy też mieć odpowiednie warunki do scrumowej pracy. Cała organizacja musi nam pozwalać na to, abyśmy „nie do końca wiedzieli, co kiedy będzie robione” i abyśmy mogli pozostawać elastyczni i otwarci na zmiany. Zapomnijmy o Scrumie, jeśli załącznikiem do „rocznego budżetu” jest lista kilkuset „wymagań”, które mamy obowiązek w tym czasie zrealizować za te konkretne pieniądze.
„Scrum kiepsko sprawdzi się w przypadku inżynierii lądowej i dużych, fizycznych produktów. (…) Drugi obszar, gdzie chociażby Kanban bije na głowę Scrum to ciągła, powtarzalna praca w dobrze rozpoznanej dziedzinie. (…) jeżeli nasze priorytety potrafią zmieniać się codziennie, jeżeli świadczymy usługi dla wielu klientów, z których każdy może mieć w dowolnej chwili krytyczny problem wymagający wszystkich naszych środków, to Scrum będzie nam tylko przeszkadzał.” – #białko
Nie bawmy się w Scrum, jeżeli każdy projekt w naszej firmie trwa miesiąc lub dwa, a po nim zespoły są rozmontowywane, a ludzie zaangażowani w te prace wędrują do innych zadań. Nie wkurzajmy programistów Scrumem, jeżeli do realizacji przychodzą zadania, a nie wymagania i nikt nie może zmienić absolutnie niczego w otrzymanej specyfikacji. Dajmy sobie spokój, jeżeli nawet nie pracujemy nad niczym skomplikowanym, a nasz „zespół” to po prostu grupa niezależnych specjalistów, których łączy jedynie osoba przełożonego.
Jest mnóstwo wydajnych i efektywnych sposobów na pracę zwinną. Jako Agile Coache pomagamy organizacjom znaleźć ten właściwy i chociaż Scrum jest naszą ulubioną metodyką, to zawsze powtarzamy, że nie jesteśmy jego ewangelizatorami. I bardzo często z naszych ust można usłyszeć zdania typu „nie widzimy w tej chwili warunków do tego, aby wdrożyć Scrum” czy „Scrum nie wydaje nam się właściwym sposobem pracy w tym zespole”. I nie ma w tym nic złego.
Scrum nie jest dla każego i to jest jego największa wada. Dlaczego? Bo czasami mamy wrażenie, że obecnie każdy musi pracować w Scrumie, bardzo często „dostosowując go do organizacji” (czytaj: ignorując połowę zapisów ze Scrum Guide 2020) lub „robiąc jego własny wariant” (czytaj: zmieniając nazwy stanowisk na Scrum Masterów i Product Ownerów oraz bezmyślnie wprowadzając „ceremonie Scrum„). I potem wszyscy się z takim Scrumem męczą, słusznie utyskując na to, że jest on bez sensu i tylko przeszkadza. A wcale tak być nie musi. Tylko trzeba go stosować tam, gdzie ma to sens. A w innych przypadkach? No cóż, jeżeli już tak bardzo wierzymy w to, że praca scrumowa przyniesie nam więcej korzyści niż kłopotu, to musimy się zdecydować na trudną i często bolesną transformację.
Bo skoro Scrum nie pasuje, a my chcemy go stosować, to jedyna droga to zmiana siebie. Bo zmieniając Scruma wyjdzie nam przecież coś innego, niż to co tak bardzo pragniemy stosować. A nie chcemy przecież dołączyć do grona tych, którzy jęczą na to, że stosowana metodyka tylko przeszkadza im w pracy.
W zasadzie, to nie jest to wada scrum, a metodyk zwinnych ogólnie i to w zasadzie banał. Po artykule oczekiwałbym wad scruma w porównaniu do innych metodyk zwinnych. Bo prawda jest taka, że metodyki zwinne nie są dla każdego, co pokazałeś w artykule, ale w ramach zwinności, scrum nie jest dla każdego czego ludzie (biznes, interesariuszy, klienci, weekendowi scrum masterzy) zdają się nie wiedzieć, lub nie chcieć przyjąć do wiadomości.