IT eSky.pl

RSS

Panaceum czy puszka Pandory?

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 developerskich,  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ą „złotą kulę”, 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.

Klasycznym zjawiskiem po wdrożeniu Scruma jest pojawienie się problemów, których wcześniej (pozornie) nie było. Paradoksalnie, im bardziej konsekwentnie wdrażany jest Scrum, tym więcej i szybciej problemów ujawni. Powoduje to często ucieczkę do innych „skuteczniejszych” metod lub dopasowywanie Scruma do realiów organizacji bez oglądania się na zasady, na których metoda się opiera.

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 na raz, albo jedyny grafik poszedł na urlop…

Często 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 to 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 samoorganizacji 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 metody? Są przecież metodyki obchodzące się bez cross-functionalnych zespołów, samoorganizacji 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 Systemu Kanban, w jakiejś formie zamanifestują się one, utrudniając i spowalniając pracę developerów lub zwiększając ryzyko niepowodzenia biznesowego.

Eliminujmy przyczyny zamiast leczyć skutki

Wróćmy do wspomnianego problemu braku cross-funkcjonalnoś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ą, 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 sprintu często nie jest w ogóle postrzegane jako problem, a jest 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ą, przyczyną może być zły sposób definiowania potrzeb biznesowych, a to potencjalnie zagraża istnieniu organizacji.

Dlatego zawsze należy pamiętać, by szukać i eliminować przyczyny, zamiast leczyć 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 zadań w czasie sprintu przez jego wydłużenie, bo rychło i tak okaże się za krótki.

Kiedy Scrum przestaje działać

Tym, co nakręca zarówno Scruma jak i inne metody Agile (w tym i System Kanban, a jakże) jest pętla inspekcji-adaptacji, umożliwiająca empiryczne podejście tak do produktu, jak i 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?


Zobacz również