Czym jest ScrumBut? 

Większość scrumowych horrorów zaczyna się dokładnie w ten sam sposób – „używamy Scruma, ale”. Nazwa takiej „zmodyfikowanej” metodyki – ScrumBut – pochodzi właśnie od angielskiego „we use Scrum, but”. Zwrot ten zwykle poprzedza listę rzeczy, których podobno „nie da się” zastosować w tym konkretnym przypadku.

Lenistwo czy bycie zwinnym?

Jaka może być motywacja osób, które postanawiają zmodyfikować Scruma? Wspominaliśmy już o tym, że nikt specjalnie nie działa na swoją szkodę. Na pewno więc wszelkie ScrumBut-y mają na celu poprawę sytuacji w firmie czy na projekcie. Ale dlaczego akurat w ten sposób?

„Wiemy, jak powinno się robić, ale nasz przypadek jest na tyle specyficzny, że tu się nie da.” – absolutnie każdy stosujący ScrumBut

Jesteśmy tylko ludźmi i każdemu z nas wydaje się, że jest wyjątkowy. Tak samo sytuacja wygląda z naszymi działaniami, firmami i projektami – wydaje nam się, że są jedyne w swoim rodzaju. I chociażby jakaś metoda zadziałała dla stu podobnych inicjatyw, to przy okazji sto pierwszej ktoś na pewno stwierdzi, że „nasz przypadek jest szczególny i nie możemy zastosować standardowego podejścia”.

Oczywiście z perspektywy danej osoby, jest to prawdą – ta sytuacja jest wyjątkowa i spotyka się ona z nią pewnie po raz pierwszy. Natomiast dla obserwatora taka osoba jest po prostu jedną z wielu, a jej problemy i przeżycia nie są unikatowe, ale pospolite. Chociaż wcale nie umniejsza to ich wagi, to jednak daje nadzieję na standardowe rozwiązanie.

Jak pokazuje praktyka, o wiele częściej mamy do czynienia z przypadkiem standardowym niż szczególnym. I to niezależnie czy mówimy tutaj o wdrażaniu metodyk zwinnych czy o jakimkolwiek innym aspekcie naszego życia. Dlatego też doświadczeni trenerzy Scrum potrafią pokazać, jak przezwyciężyć przekonanie o wyjątkowości danego projektu.

Co to ten ScrumBut?

Cóż to jest ten ScrumBut? To metodyka, która jest bardzo podobna do Scruma i zawiera jakiś podzbiór frameworku opisanego na 18 stronach Scrum Guide’a. Rzeczy, które organizacja uznała za zbędne lub niepasujące do jej kultury zostały po prostu wyrzucone.

Najczęstszymi ofiarami takiego cięcia niestety są Product Backlog Refinement, Sprint Retrospective i Definition of Done. Idąc dalej możemy napotkać na Scrum Team większy niż 9 osób, Sprinty „techniczne” przeznaczone na poprawę błędów, osobne zespoły testowe i analityczne, brak wizualizacji Sprint Backlogu czy zmienną długość Sprintów.

Nie zapomnijmy też o wszędobylskich wrzutkach czyli nieustannym dorzucaniu nowych rzeczy do realizacji w już rozpoczętym Sprincie. Tak, to też jest ScrumBut.

Każdy ScrumBut podyktowany jest wygodą i niechęcią do zmian. Scrum ma to do siebie, że wydobywa na światło dzienne nieefektywne schematy działań w organizacji. Jeśli chcemy być zwinni i działać w zgodzie z metodyką, to nie możemy np. mieć osobnych faz testowych, bo Scrum wyraźnie mówi, że na koniec Sprintu powstaje wdrażalny (zintegrowany, przetestowany i gotowy do instalacji) produkt.

Tak samo kurczowe trzymanie się dwudziestoosobowych zespołów „bo tak pracowaliśmy od zawsze” to ScrumBut wynikający tylko i wyłącznie z lenistwa. A przecież nie możemy spodziewać się korzyści z wdrożenia nowej metodyki, jeśli nie weźmiemy jej w całości.

W zgodzie ze Scrum Guide

Oryginalny (angielski) Scrum Guide zapisany jest na 18 stronach. Mechanizmy Scruma są proste, chociaż bardzo trudne do wdrożenia. To jednak nie powinno być powodem do jego ograniczania czy modyfikowania.

Przede wszystkim musimy sobie uświadomić, że Scrum działa. To nie jest nowa metodyka, ma już ponad 25 lat. To nie jest niszowe podejście, tysiące firm na całym świecie stosują go z powodzeniem. Dlaczego niby organizacja w której się znajdujesz ma być szczególnym przypadkiem? Czym konkretnie ma się wyróżniać?

Scrum Guide mówi jasno – zacznij działać w sposób opisany w tym podręczniku, a zyskasz określone korzyści. Jeśli zaczniesz modyfikować Scruma, nie będziesz mógł spodziewać się tych samych rezultatów.

Wprowadzając ScrumBut tracisz możliwość krytykowania „metodyki Scrum”, bo przecież wcale z niej nie korzystasz!

A przecież Scrum Guide zostawia naprawdę dużą dowolność. Określa jedynie pewne ramy, w których bez problemu powinniśmy się zmieścić. Gdy napotykamy jakieś problemy, to zwykle oznacza to, że nasza organizacja działa nieefektywnie, a nie, że „Scrum jest do niczego”.

Czym nie jest ScrumBut?

Lekkość metodyki może stać się też jej wadą. Rzeczy, które nie są ściśle określone w scrumowym podręczniku, mogą być interpretowane dowolnie. A to znaczy, że możemy na przykład rezerwować część czasu zespołu na tzw. „overhead” (wrzutki, poprawy błędów) i dalej pozostaniemy w zgodzie z metodyką.

Jest wiele głupich rzeczy rzeczy, które możemy zrobić, ciągle pozostając w zgodzie ze Scrum Guide. Tylko po co?

Możemy wyceniać wymagania w man-dayach, możemy też oddelegowywać osoby do Zespołów Scrumowych na 50% albo łączyć w jednej osobie role SM i PO. Na pewno utrudni nam to pracę i nie będzie efektywne. Wydaje się, że pomimo tego wciąż będziemy w stanie „działać scrumowo”, ale ewentualne korekty procesu będą proste i bezbolesne. Zdrowy rozsądek pomoże nam uniknąć tych pułapek.

Z drugiej jednak strony, to wspomniane wcześniej „zdroworozsądkowe” ScrumBut-y najczęściej prowadzą do wypaczenia metodyki. Wtedy rezultaty zwykle są bardzo dalekie od oczekiwanych. Zwykle wiąże się to z powstawaniem „mini-waterfallów” wewnątrz sprintów, zabijaniem transparentność i pogorszeniem jakości pracy.

Jeśli jednak nie odzieramy Scruma z jego podstawowych założeń, to nasze zmiany mogą przynieść też dobre skutki.

ScrumAnd

Nie każda modyfikacja Scruma, to zło. Zarówno User Stories, jak i szacowanie wymagań w punktach korzystając z ciągu Fibonacciego nie są elementami Scruma. Te techniki zyskały jednak na tyle dużo popularności, że ciężko znaleźć Scruma, który nie został o nie wzbogacony.

W większych organizacjach zwykło się delegować rolę Product Ownera do zespołów pod postacią proxy-PO. Alternatywnie dodawany jest kolejny poziom PO pod postacią Tribe Leadera czy Senior PO. Obie te modyfikacje, to typowe rozszerzenia metodyki Scrum. Nie mamy tu jednak do czynienia ze ScrumBut, ale wręcz przeciwnie – ze ScrumAnd.

W ostatnich latach popularność zyskuje ScrumBan (nie mylić ze ScrumBut) – czyli połączenie Scruma i Kanbana. To też bardziej ScrumAnd niż ScrumBut.

Każde podejście skalujące Scrum – LeSS, Nexus czy Scrum@Scale to nic innego jak ScrumAnd. Mówią one „ta metodyka świetnie działa dla jednego-dwóch zespołów, ale dodajmy jeszcze kilka elementów, żeby działa w dużej skali”. Podejrzewam, że dokładnie tego twórcy Scruma oczekiwali, gdy określili go mianem „frameworku” – ramy, którą wypełniamy konkretnymi zastosowaniami.

Jako #białko stoimy na stanowisku, że nawet jeśli coś jest niezgodne z metodyką, ale działa, to warto to zostawić. Jednocześnie zawsze sugerujemy, żeby zastanowić się dlaczego coś, co działa dla tysięcy organizacji (Scrum ze Scrum Guide’a) nie sprawdza się u nas. Takie ćwiczenie często obnaża mało zwinne aspekty naszego przedsięwzięcia.

Nie każdy ScrumBut będzie wynikał z lenistwa lub niewiedzy. Czasami znajdujemy się w takiej rzeczywistości, w której stajemy przed wyborem – albo wdrażamy „prawie Scrum”, albo zostajemy przy klasycznym waterfallu. W takich przypadkach oczywiście najlepiej jest stać się tak zwinnym, jak to możliwe, a następnie dzięki Scrum Masterom i Agile Coachom doprowadzić organizację do pełnej zwinności.

Trzeba podkreślić, że takie sytuacje są niezwykle rzadkie. Pamiętajmy, że na każdą „wyjątkową” sytuację przypadają setki „standardowych”. Więc jeśli myślisz o zrobieniu swojego ScrumBut-a, to spróbuj zacząć od czystego Scruma. Jeżeli wdrożysz go dobrze, to na nim pozostaniesz.

Zespoły już działające w Scrumie często nieświadomie modyfikują go lub zapominają o niektórych aspektach. Jeżeli chcesz wykorzystać metodykę Scrum w 100%, to polecamy nasze dwudniowe warsztaty Scrum, gdzie pokazujemy jak to zrobić w Twojej organizacji.