Scrum jest trudny...

Sam nie wiem od czego zacząć:) Może najpierw przeczytaj artykuł Kiedy Agile nie zadziała

Zawsze gdy chciałbym z pełną odpowiedzialnością powiedzieć Tak, Scrum Wam pomoże. Go! mam pewien dreszcz niepewności. Wynika on stąd, że osoba która jest odpowiedzialna za wdrożenie Scruma chciałaby wiedzieć: po czym konkretnie poznam, że Scrum działa? po czym konkretnie poznam, że jest lepiej niż poprzednio? jak długo potrwa zanim zobaczę konkretne efekty? no i, ile to mnie będzie kosztować?.

Może się zdarzyć, że po wdrożeniu w jednym zespole, w drugim oraz po przeszkoleniu, jak to się ładnie mówi" propagatorów zmiany, nic się nie dzieje. Dlaczego? Mam parę tropów.

Samoorganizujący się zespół

Samorganizujacy się zespół jest możliwy. Nawet dwa czy trzy takie zespoły w życiu widziałem, a w jednym miałem przyjemność pracować. Ale to jest naprawdę duże wyzwanie stworzyć samoorganizujacy się zespół. Aby zespół się samoorganizował najpierw trzeba go świadomie zaprojektować, wyhodować. Mimo dużej wiary w ludzi trzeba uznać, że nie wszyscy ludzie w zespole mają jednakowe kompetencje. Nie każdy zespół, nie każdy jego członek podejmie odpowiedzialność.

Samoorganizujace zespoły się zdarzają. Najczęściej dziwnym zbiegiem okoliczności odpowiedni ludzie spotkają się w odpowiednim miejscu, gdyż tak jak wspomniałem, rzadko kiedy konstruuje się zespół w planowy sposób nie tyle pod kątem kompetencji technicznych, lecz pod kątem kompetencji "zespołowych" właśnie. Konstruowanie zespołu to kosztowna akcja wymagająca zaawansowanej wiedzy HRowej albo superwymiatacza z doświadczeniem, który zrobi to "na wyczucie".

Zawiązywanie się zespołu, przejście procesu grupowego to jakieś trzy miesiące. Scrum nastawia się na hodowanie zespołów i przydzielanie do nich projektów. W ilu organizacjach proces biznesowy jest tak ustawiony, że to jest możliwe? A w ilu zespół jest powoływany per projekt i rozwiązywany zanim jeszcze zdąży okrzepnąć.

Samoorganizaujacy się zespół to naprawdę wspaniała idea. I w dodatku idea, która bardzo dobrze działa. Ale to jest trudne...

Iteracje

Gdy zapytałem jednego kolegę w trakcie szkolenia, czy nie może odmawiać wykonywania zadań spoza iteracji (wszak Odwaga to jedna z wartości Agile), odpowiedział następująco: "Kiedyś próbowałem, ale mój manager powiedział ::Ok, pośmialiśmy się, a teraz do roboty::".

Iteracje pozwalają na wybranie najistotniejszych rzeczy "na teraz", dostarczenie ich z możliwością używania. Acha, no właśnie: potentially shippable increment - czy Twoi klienci rzeczywiście używają funkcjonalności w swojej pracy, od razu gdy im dostarczysz? Czy pracują może "na starym" a "testowy" używają do poklikania?
Albo jak często zdarzają się wrzutki w trakcie iteracji i co one powodują? Jak bardzo można skrócić iteracje, aby być bardziej responsywnym? Na ile można je skracać, zanim się okaże, że testy, testy regresji itd. są zbyt kosztowne przy tak krótkich iteracjach?

Praca w zamkniętych iteracjach jest świetna. W dodatku to naprawdę działa w niektórych organizacjach. Ale to jest trudne...

Dlaczego trudny?

Dlatego, że wymaga dość dużych zmian organizacyjnych, nie mówiąc już zmianie w sposobie myślenia. Scrum daje gotowy framework, który należy zaaplikować. A co ze skalowaniem? Tak, wiem, że wymyślono dobrze brzmiące nazwy. Ale skalowanie Scruma jest wciąż w powijakach. Czasem w ogóle się nie udaje i Scrum jest tylko z nazwy, czasem udaje się wystarczająco dobrze z pewną pomocą Prince2 albo PMI, a czasem udaje się znakomicie. Tak, są organizacje, którym udało się przeskalować Scruma. Ale to jest trudne...

Zmiany organizacyjne są długie, kosztowne i mogą się nie udać. Tak jak napisałem, Scrum jest naprawdę super, ale często okazuje się zbyt trudny do wdrożenia z zachowaniem oczekiwanych rezultatów.

A może Lean?. Nie chcę przypinać się do konkretnej implementacji Lean w wytwarzaniu oprogramowania, więc piszę po prostu Lean.
Punktem skupienia Lean jest optymalizacja procesu dostarczania, nie gotowy proces do wdrożenia, lecz jego optymalizowanie. Wychodzi nam, że dużo łatwiej zespołowi przestawić się na Lean. Ok, zespół jest również ważny, ale skupienie się na procesie dostarczania, pozwala jakoś żyć gdy zespół jednak trudno się samozorganizuje. Zazwyczaj pierwszym kluczowym krokiem jest przekonanie zainteresowanych do zredukowania WIP i coś już zaczyna działać. Gwoli wyjaśnienia: Lean nie jest oczywiście remedium na całe zło, ale po prostu start jest łatwiejszy niż ze Scrumem.