Jedną z najbardziej niedocenianych zalet Scruma jest jego wyjątkowa zdolność do ujawniania organizacyjnych, procesowych, narzędziowych i komunikacyjnych niedociągnięć. Nie brzmi to atrakcyjnie, ale pamiętajmy, że wspomniane niedociągnięcia ograniczają efektywność prac Zespołów Scrum, zatem pośrednio wpływają na zdolność organizacji do realizowania i osiągania celów biznesowych. A żeby rozwiązać problemy, trzeba najpierw być świadomym ich istnienia.
Scrum często uznawany jest za przysłowiową srebrną kulę (ang. silver bullet), za pomocą której rozwiązane mają być wszystkie dotychczasowe problemy organizacji. Panuje nieuzasadniona wiara, że skoro w Scrumie Developerom pracuje się fajnie, to jego zastosowanie musi dać pozytywne rezultaty, a metoda jest prosta, więc łatwa do wdrożenia. Nic bardziej mylnego. Siła Scruma tkwi nie w łatwości stosowania lub fajności, ale w owej zdolności do wyciągania na powierzchnię wszystkiego, co spowalnia lub utrudnia development.
Często występującym zjawiskiem po zastosowaniu Scruma jest pojawienie się problemów, których wcześniej (pozornie) nie było. Paradoksalnie, im bardziej konsekwentnie stosowany jest Scrum, tym więcej i szybciej problemów ujawni. Powoduje to często paniczną ucieczkę do innych „skuteczniejszych” metod lub dopasowywanie Scruma do realiów organizacji bez oglądania się na zasady, na których metoda się opiera. W praktyce to ucieczka od problemów i dążenie do ich ukrycia.
Załóżmy jednak, że organizacja spróbuje ujawnione problemy rozwiązywać. Z czym przyjdzie jej się zmierzyć?
„Scrum utrudnia nam pracę”
Często okazuje się, że Zespół nie jest w stanie zrealizować żadnego wymagania bez pomocy zewnętrznych ekspertów lub innych Zespołów. A jeśli nawet się to udaje, w trakcie Sprintu Developerzy czekają na siebie wzajemnie, bo albo brak testera, albo specjalista UX jest zajęty kilkoma tematami naraz, albo jedyny grafik poszedł na urlop…
Bywa, że dramatycznie spada jakość produktu i efektywność pracy Zespołów, które grzęzną w organizacyjnym chaosie i nie potrafią wdrożyć żadnych usprawnień.
Najtrudniejszym do rozwiązania problemem, z którym zmagają się nawet całkiem dojrzałe Zespoły, jest rozmywanie się granic Sprintów; Zespoły realizują poszczególne wymagania ciągiem przez dwa lub więcej Sprintów.
Tych problemów bywa dużo więcej, wymieniłem trzy najczęstsze i jednocześnie najbardziej krytyczne z punktu widzenia Scruma. W istocie sprowadzają się one do trzech deficytów:
- samowystarczalności Zespołu,
- umiejętności lub zrozumienia potrzeby samozarządzania Zespołu,
- zrozumienia potrzeby empiryzmu.
Nihil novi sub sole
Można zapytać: po co komu Scrum, skoro powoduje takie problemy, mocno związane z wymogami, jakie metoda określa odnośnie do sposobu działania Zespołów? Są przecież metodyki obchodzące się bez wszechstronnych Zespołów, samozarządzania lub ograniczonych czasowo iteracji. Tam te problemy nie wystąpią… tylko czy aby na pewno? Czy też raczej zmieniając metodę, doświadczymy jedynie innych objawów tych samych problemów?
Bo w istocie tak właśnie jest. Owe „problemy” ujawniane przez Scrum w większości są jedynie objawami rzeczywistych ograniczeń i deficytów organizacji, Zespołów, narzędzi przez nie używanych, procesów etc. Czy użyjemy metodyki RUP, czy Scrum, czy Kanbana, w jakiejś formie zamanifestują się one, utrudniając i spowalniając pracę Developerów lub zwiększając ryzyko niepowodzenia biznesowego.
Eliminujmy przyczyny, zamiast pudrować skutki
Wróćmy do wspomnianego problemu braku wszechstronności Zespołu. Deficyt kompetencji technicznych i decyzyjności, duża ilość kanałów komunikacji, rozmycie odpowiedzialności, oczekiwanie na odpowiedzi (decyzje, informacje lub choćby feedback) to tylko objaw. Brak samowystarczalności Zespołu może być w rzeczywistości spowodowany złą strukturą organizacyjną, marną kulturą organizacji, nieprzemyślanymi procesami planowania i zarządzania na poziomie organizacji etc.
Spadek efektywności pracy i jakości produktu dostarczonego przez Zespół też jest objawem, nie problemem. Skoro trzeba z pracą wcisnąć się w krótki Sprint, nagle okazuje się, że narzędzia są mało pomocne, procesy czasochłonne, decyzje zapadają zbyt wolno, produkty są źle zdefiniowane itd.
Rozmywanie granic Sprintów często nie jest w ogóle postrzegane jako problem, a jest przecież objawem nieumiejętności działania w duchu empiryzmu. Praca w iteracjach stałej długości ma w Scrumie zmaksymalizować możliwość częstej oceny i adaptacji produktu (a także procesu); to pozwala reagować na zmiany rynkowe i technologiczne, więc daje organizacji przewagę konkurencyjną na rynku. Scrum bez empiryzmu jest niezwykle kosztowną zabawą w pracę iteracyjną. Skoro więc granice Sprintów się zacierają, efektem może być niewłaściwe definiowanie potrzeb biznesowych, a to potencjalnie zagraża istnieniu organizacji, gdy skupi się na budowaniu czegoś, co jest zbędne.
Dlatego zawsze należy pamiętać, by szukać i eliminować przyczyny, zamiast leczyć lub pudrować skutki. Scrum, jak napisałem na wstępie, skutecznie ujawnia objawy problemów, należy zatem użyć go jako narzędzia. Nie warto przy tym ulegać pokusie stosowania rozwiązań na skróty. Bo, na przykład, nie da się rozwiązać problemu niekończenia wymagań w czasie Sprintu poprzez jego wydłużenie, który rychło i tak okaże się za krótki.
Kiedy Scrum przestaje działać
Tym, co napędza zarówno Scruma, jak i inne metody Agile, jest pętla inspekcji-adaptacji, umożliwiająca empiryczne rozwijanie produktu, a także procesu jego wytwarzania. Nie jest możliwe osiągnięcie stanu, w którym nic już nie da się usprawnić, dlatego zmieniać się będzie jedynie skala możliwych zmian i trudność w ich wprowadzeniu. Moment, w którym organizacja lub Zespół uzna, że Scrum działa u nich idealnie i dalsze zmiany nie są potrzebne, jest jednocześnie chwilą, w której metoda całkowicie przestanie działać.
A jak Scrum działa u was?