Bez tego Scrum się nie uda 

Gdybyśmy mieli zdefiniować składniki niezbędne do tego, aby nasze scrumowe przedsięwzięcie się powiodło, byłby to zupełnie inny zestaw niż ten opisywany w Scrum Guide. Ale czy na pewno?

Co trzeba, żeby zacząć?

Scrum Guide 2020 mówi, że do rozpoczęcia pracy w tej metodyce nie jest potrzebne nam nic więcej niż Product Owner z pomysłami na pierwszy Sprint, Deweloperzy gotowi te pomysły zrealizować oraz Scrum Master, który jest w stanie zadbać o środowisko, w którym proces Scrum ma szanse zadziałać.

Brzmi to ambitnie i w głowie większości osób od razu przywodzi na myśl przedsięwzięcia typu start-upy. Ewentualnie myślimy o „projektach” z kategorii R&D robionych wewnątrz jakiejś organizacji. Innymi słowy – mamy po prostu fundusze na rozwój pewnego produktu i możemy się „bawić”. To nie jest do końca słuszne postrzeganie, ale nie da się ukryć, że takie myśli siępojawiają.

Na pewno Scrum nie brzmi jak coś, co pozwoli nam realizować zlecenia dla klientów albo zbudować od podstaw ogromny system centralny dla dużej korporacji. Tu akurat jest dużo prawdy. Do realizowania zleceń od klientów nadają się zupełnie inne podejścia. Do budowy ogromnych systemów potrzebujemy jakieś nakładki dla prostego Scruma. Musimy mieć coś, co pozwoli nam zapanować nad zależnościami i szczęśliwie doprowadzić wszystkie części przedsięwzięcia do szczęśliwego końca.

Scrum ma bardzo szerokie zastosowania, ale trzeba pamiętać, że nie jest uniwersalny i nie do każdego typu pracy się nada. Nie w każdym środowisku pozwoli nam też osiągnąć wszystkie jego korzyści.

Niezbędne elementy Scruma

Gdyby ktoś zapytał mnie, bez czego nie ma sensu pracować w Scrumie, to jednym tchem wymieniłbym: jasno zdefiniowany Produkt i umocowany Product Owner, który posiada wizję zarówno docelowego stanu jak i samego kierunku rozwoju tegoż Produktu. Dodajmy do tego stały w składzie i dedykowany Scrum Team, odpowiednią przestrzeń na refinement oraz na tyle dużo finansowania, które pozwoli nam na skupienie się na tym, żeby wytworzyć wartościowy produkt, a nie taki który jest po prostu najtańszy.

Powyższe wymaganie dotyczące Product Ownera pokrywa się z tym z podręcznika, ale tylko w pewnym zakresie. Moim zdaniem nie wystarczy tylko i wyłącznie zapas pomysłów na najbliższy Sprint. O wiele ważniejsze jest to, żebyśmy mieli jasno zdefiniowany Produkt. Musimy wiedzieć co chcemy wytworzyć i mieć jakąś wizję odnośnie tego jak on ma docelowo wyglądać. „Musimy” to oczywiście odpowiedzialność PO, który też powinien być umocowany do tego żeby decydować o kierunku rozwoju naszego rozwiązania.

W sytuacjach w których nasz PO jest tylko „sekretarką” (zarządcą Backlogu Produktu) i tylko realizuje zlecenia, które przychodzą do niego od interesariuszy czy klientów to nie ma szans na to żeby mechanizmy scrumowe zadziałał poprawnie. Jeszcze gorzej jest, jeżeli tak naprawdę nie pod siadamy żadnego Produktu, a po prostu świadczymy usługi, które dotyczą kilkudziesięciu różnych niezwiązanych ze sobą rzeczy.

Podobne rozważania mogą dotyczyć samego zespołu. Przede wszystkim skład Zespołu Scrumowego powinien być stały, a osoby które w nim się znajdują powinny być dedykowane do pracy tylko i wyłącznie w tym zespole. Nie znajdziecie tego nigdzie napisanego wprost w Podręczniku Scrum, ale wszędzie gdzie te warunki nie są spełnione można zauważyć pewne powtarzające się problemy.

Warunki konieczne Scruma

Pracując w Scrumie musimy mieć możliwość pozwolenia sobie na eksperymenty i próby zrobienia czegoś inaczej niż w utarty sposób. Dotyczy to zarówno samego sposobu wykonywania pracy, jak i Produktu który tworzymy. Zawsze chcemy móc eksperymentować i próbować rozwiązań, które nie do końca mogą się sprawdzić. Dzięki pozytywnemu lenistwu i idei MVP, szybko i w miarę tanio będziemy w stanie się wycofać z nietrafionych pomysłów. Podobnie rzecz się ma odnośnie sposobu wykonywania pracy – chcemy móc spróbować robić inaczej i sprawdzić, jak to się przekłada na naszą skuteczność i na efekty.

Aby spełnić powyższe warunki, nie da się ukryć, że potrzebne jest solidne zaplecze finansowe. Nie mówię tutaj o tym, że takie zespoły mają przynosić straty, ale nie możemy liczyć każdej złotówki. Nie możemy wymagać od członków zespołu, żeby byli w stanie opisać każdą godzinę swojego czasu i przypisać ją do konkretnego zlecenia realizowanego na żądanie konkretnego klienta. Scrum w ogóle nie jest sposobem, w którym możemy efektywnie realizować prace zlecone przez klientów, które wcześniej wyceniliśmy na konkretne i sztywne kwoty.

Elementy Backlogu Produktu w procesie scrumowym zaczynają swoje życie jako potrzeby bądź nieprecyzyjne wymagania. Następnie przechodzą przez proces refinementu, gdzie zespół zgłębia je pozbywa się ich zbędnych części oraz dzieli je na mniejsze fragmenty. Dzięki temu nie tylko poszczególne elementy mieszczą się w Sprintach, ale też Scrum Team poznaje je lepiej i lepiej. W ramach tego procesu zgodnie możemy próbować różnych rozwiązań. To czasami kosztuje i czasami zajmuje trochę więcej czasu, ale bardzo często zwraca się z nawiązką. Szkopuł w tym, że musimy być gotowi ponieść takie ryzyko i zaufać specjalistom w zespole.

To jak pracować w Scrumie?

Dzisiejszy tekst to kolejny post z cyklu „Scrum nie jest dla każdego„, czy „Największa wada Scrum„. Jest ku temu dobry powód. W wielu miejscach Scrum stosowany jest bezrefleksyjnie, bez zapoznania się z plusami i minusami tego podejścia. Często też bez spełnienia jakiegokolwiek z warunków, które pozwalają nam skutecznie pracować.

Warto podkreślić, że warunki wymienione w Scrum Guide to takie, które pozwalają nam w ogóle zacząć pracę z wykorzystaniem tej metodyki. Te dodatkowe, które poruszyłem w dzisiejszym tekście trochę o nie zahaczają, ale też wybiegają dalej. Nie chodzi tylko i wyłącznie o to żeby zacząć w ten sposób zacząć i jakoś tam będzie. Przede wszystkim miejmy na uwadze, aby ta praca była zarówno skuteczna, jak i efektywna.

Sugeruję, aby każda osoba rozważająca wdrożenie pracy w Scrumie w swoim zespole czy w jakieś części firmy, w której pracuje bądź którą zarządza, zadała sobie bardzo głośno pytanie: Po co nam w ogóle Scrum i co chcemy dzięki niemu osiągnąć? A potem niech odezwie się do nas i sprawdzi, czy i jak można to osiągnąć w tym konkretnym przypadku.