Scrum to nie są Sprinty, Daily i Retro, ani nawet nie Product Backlog, Scrum Master i Product Owner. Szok, horror i niedowierzanie. Niestety, „Zombie Scrum” jest bardziej popularny niż całe środowisko zwinne by tego chciało. A im więcej będzie jego implementacji, tym więcej będzie wynaturzeń.
Scrum to nie są Sprinty!
Czytelnicy naszej listy mailingowej pewnie zauważyli, że ostatnio mi i Łukaszowi się trochę ulewa. Nic w tym dziwnego, bo między innymi po to powstał ten nasz kanał kontaktu z Wami. Mamy też nadzieję, że przekazywane informacje są praktyczne i nie ograniczają się li tylko do narzekania. Bądź co bądź zawsze staramy się podsumować nasze e-maile poradami.
Zresztą, nawet tu na naszym blogu skręcamy ostatnio w ciemniejsze rejony, publikując teksty w rodzaju „Scrum nie jest dla każdego„, „Dlaczego Developerzy nie rozumieją Scruma?” czy „100% czasu Developera„, w których nie boimy się głośno mówić o nieporozumieniach i różnego rodzaju błędnych interpretacjach i nietrafionych wdrożeniach Scruma. I nadszedł czas, że odczuwamy potrzebę powiedzenia tego jeszcze raz.
Scrum to nie są Sprinty i Wydarzenia Scrum! Jeśli będziemy mieli te nieszczęsne Sprinty, Planowanie, Daily i Retro, a do tego Product Backlog i Scrum Mastera, to nie znaczy, że będziemy mieli Scrum, ani że pracujemy zwinnie! „[Scrum] pomaga poszczególnym osobom, zespołom i organizacjom wytwarzać wartość poprzez adaptacyjne rozwiązywanie złożonych problemów.” Przede wszystkim chodzi nam o rozwiązywanie problemów i wytwarzanie wartości. A nie o pracę w zgodzie z podręcznikiem!
Podkreślmy to jeszcze raz – liczą się efekty, najczęściej osiągane dzięki ciągłemu decydowaniu o tym, co jest najważniejsze w kontekście wytwarzanego produktu. Te decyzje potrafimy podejmować, bo pracujemy w krótkich iteracjach, gdzie wytwarzamy rozwiązania, które następnie weryfikują nasi odbiorcy. To jest esencja Scruma. I nie ma tu miejsca na stwierdzenia w stylu „pracujemy Scrumowo, ale mamy wdrożenie raz w roku„, bo to totalne nieporozumienie.
Zombie Scrum
W bardzo popularnym tekście „5 powodów, dla których Scrum nie zadziała w Twojej firmie” pisaliśmy, jak ważny jest mindset, czyli nastawienie. Że musi być ono zwinne na każdym szczeblu organizacji, że nie możemy się ograniczać tylko i wyłącznie do zespołów i do literalnego wypełniania wszystkich scrumowych powinności opisanych w Scrum Guide.
Choroba, o której dzisiaj piszemy często nazywana jest „Zombie Scrum”. Członkowie zespołów niczym zombiaki przychodzą odprawiać „ceremonie Scrum„, tylko i wyłącznie dlatego, że ktoś im tak kazał. Nikogo nie interesuje efektywność pracy, sensowność procesów, optymalizacja wartości biznesowej wytwarzanego produktu. Ważne jest Planowanie, Daily, Review i „sesja narzekania”, czyli Retro. No i ten dziwny „refajnment”.
Dlaczego pracujemy w dwutygodniowych Sprintach? Zombie Scrum mówi, „bo tak trzeba”. Po co spotykamy się na Daily czy Retro? „Bo trzeba”. Zero refleksji, zero zastanowienia się, zero celowości jakichkolwiek działań.
Ryzykując nadmierne powtarzanie się, napiszę, że wszystkie zasady Scruma są ważne, bo powstały po to, aby ułatwić dostarczanie realnej wartości. Jeśli jej nie dostarczamy, jeśli nie mamy efektów, to nikogo nie obchodzi, że jesteśmy w stu procentach zgodni z Podręcznikiem Scrum. Odwrotna sytuacja jest mniej niebezpieczna. Możemy pracować niezgodnie z zasadami i osiągać realne efekty, tylko nie nazywajmy tego Scrumem! Bo to, że u nas działa jakiś konkretny proces, to nie znaczy, że będzie on działał wszędzie. A Scrum jest względnie uniwersalny i całkiem skuteczny. O ile oczywiście jest robiony z głową, a nie jako „Zombie Scrum”.
„Mamy Scruma”
Żeby nie było tak zupełnie negatywnie, to spróbujemy na ten cały agile mindset spojrzeć pozytywnie. Zdarza się, że opowiadamy komuś o podejściu zwinnym, a w odpowiedzi słyszymy „My już mamy Agile„. I czasami faktycznie jest to prawda! Nie trzeba pracować formalnie, żeby pracować zwinnie. Bo, jak przypominamy o tym bardzo często, podejście zwinne (ang. agile) to pewien sposób myślenia, podejście, nastawienie, zasady którymi się kierujemy. Scrum to tylko jeden z dziesiątków (setek?) sposobów, w jaki można zwinne pracować. Tyle tylko, że najpopularniejszy.
Jak najbardziej można „być agile” bez konkretnej metodyki, spisanego procesu i sposobu pracy. To dość niezależne rzeczy. Nie da się jednak ukryć, że Metodyka YOLO nie służy jakości i efektywności. Więc w pewnym stopniu, jeżeli chcemy być bardzo zwinni to musimy jakoś zorganizować naszą pracę. I tu z pomocą przychodzą metodyki agile. I tak jak nie polecamy po prostu pracować bez ładu i składu, tak samo nie możemy do przesady trzymać się nawet najbardziej uniwersalnych zasad, kiedy wiemy, że one do nas nie pasują.
To być może jest źródłem problemu. Niektóre organizacje wykształciły sobie swoje rozwiązania, które Scrumem ani żadną inną metodyką nie są. Ale u nich, w tych konkretnych przypadkach działają i działają dobrze. I super! Tylko nie nazywajmy tego Scrumem, bo potem ktoś się tym zainspiruje (czytaj: skopiuje) i wdroży u siebie coś, co ani nie przypomina Scruma, ani nie pasuje do tego konkretnego przypadku. I będziemy mieli większość z problemów opisanych w dzisiejszym tekście.
Co chciałbym przekazać z obiecanych porad w tym temacie? Po pierwsze, musimy wiedzieć co chcemy osiągnąć. Po co nam jakaś zwinna metodyka? Czemu ma służyć? Jakie mają być efekty? Po drugie, musimy wiedzieć co robimy. Czy wdrażamy Scruma, czy budujemy jakieś własne rozwiązanie? Jeżeli to pierwsze, to czy na pewno go znamy i rozumiemy (czy potrzebujemy pomocy z zewnątrz)? Po trzecie, jak już się na coś zdecydujemy – zróbmy to porządnie, sprawdzajmy czy działa i nam służy oraz czy osiągamy założone rezultaty. Bo jeśli nie, to ryzykujemy robienie „Zombie Scrum”, bo wszyscy inni też robią „Zombie Scrum”. A to przecież kompletna głupota.
