Są problemy mniejsze i większe. Istnieją też problemy ogromne, które sprawiają ludziom, zespołom oraz firmom tyle kłopotów, że żyć się odechciewa. Opowiemy Wam dziś o najogromniejszym problemie ze Scrumem, czy też raczej – z jego wprowadzaniem.
Scrum Guide jako źródło problemu?
W zeszłym tygodniu opisaliśmy powszechną dla naszej branży sytuację, którą jest Scrum po swojemu. Właśnie ten potwór (bardzo często ScrumBut) powoduje, że tak wiele organizacji nie potrafi poprawić swoich wyników biznesowych korzystając ze sprawdzonych frameworków oraz praktyk Agile.
Nie jestem w stanie powiedzieć, ile widziałem zespołów, które twierdzą, iż pracują w Scrumie, lecz ich procesy pokazują coś zupełnie innego. Daily trwa ponad czterdzieści minut, Retrospektywy nie ma, a Product Ownerów jest więcej, niż Deweloperów. Zazwyczaj bardzo się dziwią, gdy dowiadują się, że to wszystko jest wbrew zasadom Scruma.
„Skoro jesteśmy Agile, to nie musimy przestrzegać żadnych zasad!” – wszyscy i wszędzie
Powstaje pytanie, skąd się to wszystko wzięło. Odpowiedź jest prosta – nikt nie czyta Scrum Guide. Ten dokument, oczywiście, ma swoje problemy i nie raz o tym wspominaliśmy. Jest bardzo abstrakcyjny, pozbawiony praktycznych przykładów i czytając go, trudno odnieść jego treść do swojej codziennej pracy. Niby wszystko jest, ale nie mówi on nic o tym, jak ta praca ma wyglądać.
Niemniej, niektóre części Scrum Guide są tak proste, że prościej się nie da:
„Każdy element frameworku służy do pewnego celu i jest niezbędny co do ogólnej wartości i rezultatów osiąganych ze Scrumem. Zmienianie kluczowych konstrukcji lub idei Scruma, pomijanie elementów lub nie przestrzeganie reguł Scruma prowadzi do ukrycia problemów i ogranicza zalety Scruma, potencjalnie nawet czyni go bezużytecznym.”
„Zespół Scrumowy składa się z jednego Scrum Mastera, jednego Product Ownera oraz Deweloperów. W drużynie Scrumowej nie ma podzespołów lub hierarchii.”
Idąc dalej, Scrum Guide nie podaje gotowych przepisów na skuteczną Retrospektywę, ale twierdzi jednoznacznie (chociaż nie wprost), że:
- Scrum Master to nie osoba do przeprowadzania Daily lub zarządzania Jirą
- Product Owner to nie Delivery Manager, ani nie Interesariusz
- Sprint Review to nie demo,
- Itd.
Tylko że nikt tego Scrum Guide nie czyta. Dlaczego?
Jak się uczy Scruma?
Osobom mało doświadczonym w swojej pracy można jeszcze pewne niezrozumienie czystego Scruma wybaczyć. Zaczynają oni swoją karierę w bardzo wymagającej dziedzinie i muszą opanować wiele różnych „twardych” umiejętności. Dla nich Scrum Guide jest daleko na końcu ich listy priorytetów. O ile w ogóle wiedzą, że taki dokument istnieje.
Natomiast bardziej zaawansowanym Deweloperom, Managerom i wszystkim innym tego już wybaczyć nie możemy. Po wielu latach pracy i obserwowania różnych (często nieskutecznych) praktyk można w końcu zadać sobie pytania:
- „Czy rozumiemy to, co robimy?”
- „Dlaczego robimy to tak, a nie inaczej?”
- „Po co nam ten Scrum i skąd się on wziął?”
A potem warto zrobić jakiś research na ten temat.
O tym, jak Juniorzy uczą się pracować w ScrumBucie pisałem bardziej szczegółowo w poście Dlaczego Deweloperzy nie rozumieją Scruma. Podsumowując krótko: oni absorbują tę kulturę pracy, która panuje w ich firmie i zakładają, że to właśnie jest Scrum. Ufają swoim bardziej doświadczonym kolegom – i się zawodzą. Bo oni też nie czytali Scrum Guide, tylko również „absorbowali kulturę”. Zamknięty krąg.
Tym razem musi zadziałać
Dlaczego tkwimy w zamkniętej pętli i ciągle powtarzamy to, co nie działa? Mówiąc krótko – nie jesteśmy tak inteligentni, jak nam się wydaje. Istnieje mnóstwo pułapek umysłu, które są integralną częścią natury ludzkiej, a jednocześnie nie są powszechnie znane.
Przytoczę przykład. Strasznie lubię historię, szczególnie średniowiecznej Europy. Żaden inny okres historyczny nie jest tak nieprawdziwie przedstawiony jak ten. Żaden inny nie jest tak mocno opętany przez błędne przesądy. Większość ludzi uważa, że średniowieczu towarzyszył upadek, a nawet cofnięcie się postępu naukowego. Jednocześnie ludzie wiedzą, kim byli średniowieczni rycerze, wyposażeni w pancerną zbroję, niemożliwą do przebicia przez broń z poprzednich epok.
Oba te stwierdzenia nie mogą być jednocześnie prawdziwe! Albo był upadek postępu, albo powstawał lepszy sprzęt militarny. Jedno wyklucza drugie. Niemniej, mnóstwo ludzi wierzy jednocześnie w oba z tych stwierdzeń i nie widzi w tym problemu. Ot, kolejna pułapka umysłu – nie jesteśmy tak inteligentni i rozsądni, jak nam się wydaje.
Otóż takie bugi w świadomości ludzkiej, o ile nie liczymy się z nimi, prowadzą do wielu problemów. Nierealistyczne plany nierzadko powstają z inicjatywy właśnie tych osób, które zbyt mocno kierują się własną domniemaną wiedzą i inteligencją. Nie raz widziałem jak projekt był skazywany na porażkę przez kierowników, którzy byli pewni, że wszystko wiedzą lepiej od innych. I nie liczyli się z informacją zwrotną. I nie czytali Scrum Guide.
Kontrola Empiryczna
Przeciwieństwem ufania intuicji i poleganiu na (nierozsądnym) rozsądku jest Kontrola Empiryczna, zalecana przez podejście zwinne. Zakładamy, że nie wiemy wszystkiego z góry – i nie możemy wiedzieć. Nie da się ułożyć precyzyjnego planг na rok do przodu. Rozwiązania, które podpowiada nam intuicja, nierzadko są błędne. Pracując w krótkich iteracjach, ciągle sprawdzamy wyniki i wyciągamy z nich wnioski. Podejmujemy decyzje na podstawie tego co jest, a nie co nam się wydaje. Empiryzm.
Oparcie się na niesprawdzonych (bo niemożliwych do sprawdzenia) założeniach było powodem tak licznych klęsk projektów waterfallowych. Agile jest stosowaniem wiedzy o naturze ludzkiej w celu osiągnięcia lepszych wyników. W tym – liczeniu się z pułapkami umysłu. A czasem i obracaniu ich na naszą korzyść.
Wracając do absorbowania kultury. Jest to jeden z kluczowych mechanizmów natury ludzkiej: uczenie się przez naśladowanie naszego otoczenia. Umożliwia to istnienie społeczeństw ludzkich, a więc i samej cywilizacji. Zakładam, że nikt z naszych czytelników nie sprawdzał, co się stanie, jeżeli włoży palce do gniazdka, tylko nauczył się tego przez taką właśnie absorpcję.
Uczenie się od innych czasami prowadzi jednak do absorbowania nieprawdziwej, a nawet szkodliwej wiedzy. Szczególnie jest to groźne, jeżeli nie zostanie ona potem sprawdzona. To tak jak w przypadku ze ScrumButem.
Obróćmy więc ten mechanizm na naszą korzyść. Zbudujmy lepszą, prawdziwą kulturę zwinności w naszych organizacjach – a pracownicy będą absorbować ją automatycznie.
Rozwiązanie problemu
Skąd wziąć ludzi do wprowadzania kultury zwinnej? Każda firma może zdecydować, czy znaleźć takie osoby i je zatrudnić, czy wysłać pracowników na szkolenia zewnętrzne. Tylko mało jest takich ludzi na rynku. Mało jest też dobrych szkoleń, inaczej wszyscy by już dawno z nich skorzystali. Rozwiązanie jest takie – potrzebujemy lepszego systemu nauki Scruma i podejścia zwinnego. Takiego, którzy potrafiłby połączyć to, co napisane w Scrum Guide, z tym, co mamy na co dzień w rzewczywistych firmach. Potrzebujemy nauczyć wszystkich: Scrum Masterów, Deweloperów, Managerów i innych uczestników korzystać ze sprawdzonych praktyk i narzędzi, ulepszać swoje procesy i rezygnować z tego co zbędne. I najważniejsze: na każdym kroku rozumieć co i po co robimy.
Dobra wiadomość jest taka, że my taki system mamy, a subskrybenci naszej listy mailingowej jako pierwsi o nim się dowiedzą. Warto się zapisać.
