Blog

Bez trudu można znaleźć wiele podpowiedzi odnośnie do tego, jak wybrać pomiędzy Scrumem lub Kanbanem – osobiście uważam je za chybione o tyle, że można użyć obu tych narzędzi równocześnie. Dużo trudniej o sensowne wskazówki dla osób, które rozważają użycie Scruma, ale nie są pewne, czy to dobry pomysł. Oto więc moja propozycja listy kryteriów, jakimi można się posłużyć przy podejmowaniu decyzji.

Kryterium 1: cel wykonywanej pracy

Jeśli celem jest rozwój produktu poprzez wprowadzanie w nim kolejnych modyfikacji, dopóki ktoś tych zmian potrzebuje, wtedy Scrum może mieć sens. Jeśli nie, lepiej sięgnąć po inne metody.

Wynika to wprost z faktu, że wszystkie elementy Scruma mają pomagać w rozwoju produktu w sposób iteracyjny i przyrostowy. Jeśli w centrum uwagi Zespołu nie znajdzie się produkt, niektóre z elementów metody mogą stać się niepotrzebne, a rezygnując z nich i tak przestanie się pracować w Scrumie.

Kryterium 2: charakter wykonywanej pracy

Jeśli praca polega na realizowaniu ściśle z góry zdefiniowanych zleceń (zadań), spora część mechaniki Scruma stanie się zbędna.

Przykładowo, gdyby np. instalatorzy telewizji kablowej uparli się, by pracować w Sprintach, ich Planowanie sprowadzałoby się do rozdzielenia między siebie listy zleceń, a Przegląd Sprintu byłby zbędny, bo kogo mieliby zaprosić jako interesariuszy? Klientów, których już obsłużyli, czy tych wciąż oczekujących na wizytę instalatora? Nawet gdyby jakimś cudem tacy klienci zgodzili się na udział, to czego miałaby dotyczyć dyskusja? Tego, czy opłaca się nowych klientów obsłużyć? A może oceny, czy warto było realizować już wykonane instalacje?

Scrum nadaje się natomiast dobrze do poszukiwania rozwiązań problemów i odpowiedzi na zidentyfikowane potrzeby interesariuszy Zespołu.

Kryterium 3: faktyczne istnienie produktu

Produktem w rozumieniu Scruma może być proces biznesowy w banku, cały cykl wydawniczy książki, kampania reklamowa, oprogramowanie, receptura nowego leku i wiele innych rzeczy. Łączy je to, że ich zbudowanie wymaga znalezienia właściwych rozwiązań, a nierzadko uprzedniego odkrycia potrzeb, na które produkt ma odpowiedzieć.

W szczególności produkt powstawać musi dla kogoś i po coś, czyli istnieć muszą interesariusze, którym realnie zależy na tym, by produkt powstał.

Użycie Scruma do rozwoju tak definiowanych produktów ma głęboki sens, bo metoda po to właśnie powstała.

Jeśli produkt tworzony jest na siłę jako zlepek różnych rzeczy tylko po to, by zamiast wielu list zadań do wykonania powstała jedna, nad którą pracować będzie wskazana grupa ludzi, to Scrum niezbyt się do tego nadaje.

Metoda będzie też straszliwie kuleć wszędzie tam, gdzie nie wiadomo nad czym, dla kogo i po co wykonywane są takie czy inne działania. Lub gdy poszczególne rzeczy, które realizowane są rzekomo w ramach rozwoju jednego produktu, są ze sobą zupełnie niepowiązane albo wręcz sprzeczne.

Kryterium 4: rozwój produktu, nie produkcja

Scrum zupełnie nie nadaje się do wytwarzania kolejnych egzemplarzy jakiegoś produktu, np. do produkcji krzeseł na zamówienie. Nie jest bowiem metodą organizacji pracy i brak w nim mechanizmów niezbędnych do zarządzania Zespołami wytwórczymi tego typu.

Można natomiast Scruma zastosować nawet w takich miejscach do czegoś zupełnie innego, czyli do przejścia od pomysłu na produkt do faktycznego uruchomienia jego produkcji. Dlatego, chociaż Scrum nie nadaje się np. do zarządzania drukarnią, to można się nim posłużyć w procesie wydawniczym książki. Choć nie można Scruma użyć do zażądania linią produkcyjną, to da się z jego pomocą taką linię produkcyjną stworzyć.

Kryterium 5: rozwój produktu, nie projekt

Ciężko z sensem użyć Scruma tam, gdzie od samego początku dąży się do uzyskania jakiegoś ściśle zdefiniowanego końcowego produktu, który od tego momentu będzie już tylko używany. Jeśli kryteria zakończenia prac i sukcesu są z góry ustalone, bardziej adekwatnym narzędziem od Scruma będą metodyki projektowe.

Natomiast jeśli nawet dąży się do uzyskania takiego konkretnego produktu, ale nie do końca wiadomo, jaki właściwie powinien on być w szczegółach, Scrum jak najbardziej jest dobrym narzędziem, które pozwoli to odkryć. Przy czym wtedy zostanie on użyty nie do zorganizowania prac developerskich, ale przede wszystkim do podejmowania decyzji o tym, co powinno stać się częścią produktu.

Kryterium 6: możliwość wybierania, co zostanie zrobione

Jeśli Zespół z rozległego zbioru problemów i potrzeb stara się wyłuskać te, których rozwiązanie lub zaspokojenie będzie najbardziej opłacalne, to Scrum idealnie się do tego nadaje.

Natomiast jeśli Zespół z obiektywnych przyczyn nie dokonuje takiego wyboru i co najwyżej może żonglować kolejnością, w jakiej podejmie zlecone prace, Scrum nie jest najlepszą metodą dla niego. Nie oznacza to automatycznie, że posłużenie się frameworkiem nie przyniesie żadnych korzyści, ale będą one ograniczone.

Podkreślam, że chodzi o obiektywne przyczyny, a nie ograniczenia narzucone przez management lub interesariuszy Zespołu, które pozbawiają go wpływu na to, co i jak ma być robione.

Kryterium 7: potrzeba istnienia Zespołu

Czy w ogóle potrzebny jest Zespół? Jeśli nie, lepiej sięgnąć po inne metody niż Scrum. Z drugiej strony samo istnienie Zespołu nie wystarcza, by posługiwać się Scrumem – konieczne jest posłużenie się dodatkowymi kryteriami, bo o tym zdecydować.

Kryterium 8: możliwość zaistnienia wspólnoty pracy

Jeśli wytworzenie czegoś wartościowego dla interesariuszy wymaga od Zespołu łączenia różnych kompetencji, w tym zaistnienia tzw. wspólnoty pracy, Scruma da się użyć, o ile spełnione są inne warunki do tego. Jeśli praca zespołowa ani wspólnota pracy nie jest konieczna, ale przynosi wymierne korzyści, Scrum wciąż może mieć sens.

Jeśli natomiast wykonywanie pracy indywidualnie od początku do końca jest jedyną rozsądną opcją, Scruma ciężko będzie zastosować w sposób dający jakiekolwiek korzyści. Przy czym znów chodzi tu o obiektywne powody wyboru takiego czy innego sposobu pracy, a nie o preferencje członków Zespołu.

Kryterium 9: możliwość planowania iteracji

By praca mogła być wykonywana w iteracjach, których cel ustalany jest na początku, muszą być spełnione jednocześnie trzy warunki:

1. Jest możliwe ustalenie jednego sensownego celu, który nie będzie się zmieniał w trakcie iteracji.
2. Zakres prac w iteracji może być skupiony na osiąganiu ustalonego celu i dostosowywany do niego, a nie na odwrót.
3. Da się ustalić taką długość iteracji, która Zespołowi zagwarantuje wystarczającą stabilność i przestrzeń do osiągnięcia wytyczonego celu, a która nie będzie skutkować zbyt wolnym reagowaniem na pojawiające się nowe problemy.

Jeśli da się pracować iteracyjnie, Scrum może być użyty, o ile nie wykluczają tego inne przyczyny.

Jeśli Zespół musi reagować na bieżąco na pojawiające się w nieprzewidywalny sposób zlecenia i jest to zasadnicza część jego pracy, Scruma zastosować się nie da.

Oczywiście tak jak poprzednio, gdyby nie dało się pracować iteracyjnie tylko dlatego, że uniemożliwiają to jakieś decyzje organizacyjne, to po ich usunięciu Scrum może być zastosowany.

I tak na przykład, Zespół budujący oprogramowanie może robić to iteracyjnie i inkrementalnie, natomiast helpdesk obsługujący klientów dzwoniących do firmy nie jest w stanie zaplanować, kiedy i jakie problemy przyjdzie mu rozwiązać.

Kryterium 10: istnienie niestabilnej złożoności

Jeśli Zespół zmaga się z nieprzewidywalnością i zmiennością tego, czym się zajmuje, to zastosowanie empirycznej kontroli procesu do inkrementalnego i iteracyjnego rozwiązywania problemów ma sens. Scrum może być wówczas użyty, zwłaszcza jeśli celem jest rozwój produktu.

Jeśli charakter problemów, z jakimi zmaga się Zespół, jest inny – Scrum może nie mieć sensu. Przy pracach niezwykle skomplikowanych zwykle wciąż będzie się to opłacać mimo braku niestabilności i nieprzewidywalności. Do rozwiązywania problemów prostych lepiej posłużyć się innymi narzędziami, np. gotowymi procedurami.

Czy da się Scruma użyć w domenie chaotycznej, w której w zasadzie nic nie wiadomo i każde działanie jest podejmowane w praktyce po omacku? I tak i nie. Na skraju chaosu Scrum wciąż będzie dobrze działał, natomiast nie da się go użyć tam, gdzie Zespół nie będzie w stanie nawet sformułować hipotezy odnośnie do tego, co jest możliwe do zrobienia.

Uwaga: pisząc o chaosie, mam na myśli obiektywny stan spraw, a nie sytuację, która jest wynikiem posłużenia się niewłaściwymi narzędziami, błędów decyzyjnych, marnego managementu lub braku dbałości o dobrą organizację pracy przez Zespół. Jeśli takie są źródła chaosu, to po ich usunięciu, powinno dać się użyć Scruma, o ile nie wykluczają tego inne przyczyny.

Kilka zastrzeżeń na koniec

Przedstawiona lista to zbiór wskazówek, a nie algorytm. Wszystko zależy od kontekstu konkretnego Zespołu, organizacji, która go stworzyła, charakteru rzeczy, które będą robione oraz od ludzi, ich motywacji, umiejętności itd.

Zwracam uwagę, że większość moich podpowiedzi nie ma charakteru jednoznacznie rozstrzygającego. O ile nie da się użyć Scruma tam, gdzie niemożliwa jest praca iteracyjna, albo gdzie nie ma żadnego produktu lub Zespołu, to już np. bez wspólnoty pracy wciąż może on mieć sens. Ba, być może dzięki Scrumowi zmieni się sposób działania Zespołów i zaczną być one skuteczniejsze, gdy odkryją, że wspólnota pracy jest korzystna? Kto wie.

Przypominam też, że cały czas piszę o kryteriach sensowności lub możliwości użycia Scruma, a nie wyłącznie Scruma, albo Scruma zamiast innej metody. Scrum jest na tyle minimalistycznym frameworkiem, że można z powodzeniem skojarzyć go z wieloma praktykami, technikami, strategiami itd., czego przykładem jest duża korzyść z łączenia Scruma z Kanbanem.

Dlatego proszę czytelników o nietraktowanie tego artykułu jako podpowiedzi, jak wybierać między Scrumem a czymkolwiek innym. Z czegokolwiek korzystacie, ten artykuł może wam jedynie pomóc w ocenie, czy miałoby sens sięgnięcie również po Scrum.