Puzzle

Kiedy Scrum działa dobrze

Scrum jest frameworkiem (po polsku to „ramy postępowania”), który dzięki wykorzystaniu empiryzmu pozwala rozwiązywać złożone problemy w złożonym środowisku. Inaczej: to metoda, dzięki której radzimy sobie lepiej z nieprzewidywalnością i złożonością, które musimy jakoś okiełznać, aby osiągnąć sensowny i wartościowy cel.

„Metoda”, wspomniany „framework” – te słowa wielu osobom kojarzą się z gotowymi receptami, wręcz instrukcjami jak postępować. „Wdrażamy” metodę tak, jak nakazali nam to jej twórcy i automatycznie świat staje się prosty, prawda? Wystarczy twardo trzymać się Scrum Guide, to takie łatwe!

Nie, to nieprawda. Do zadziałania wspomnianego empiryzmu, bez którego Scrum nie miałby sensu, potrzeba czegoś więcej niż zestawu reguł, ról, artefaktów i zdarzeń procesowych. Takich składników potrzeba przynajmniej kilku. Opisuję je poniżej.

Od razu zastrzegam, że lista nie jest kompletna i wynika z moich obserwacji – jest więc całkowicie subiektywna. Są miejsca, gdzie do dobrego działania Scruma trzeba dużo więcej, są też i takie, gdzie metoda działa całkiem dobrze mimo braku kilku z wymienionych składników. Pisząc o tym, co pozwala użyć Scruma w najbardziej efektywny sposób, pragnę zainspirować czytelników do zastanowienia się, czego (być może) potrzebują w swoich zespołach i organizacjach, by to osiągnąć.

Składnik pierwszy: wizja i wynikające z niej cele

Scrum wymaga do dobrego działania zrozumiałej wizji tego, co chcemy osiągnąć. Wizji, która będzie źródłem zaangażowania dla ludzi, z których składa się zespół. Jeśli nie wiadomo co i po co robimy, lub jeśli nikt nie utożsamia się z potrzebami, na które odpowiada budowany produkt, to zaangażowanie zespołu bardzo szybko ulegnie erozji (o ile w ogóle się pojawi).

Sama wizja to za mało. Zdarza się, że jest atrakcyjna i dobrze określona, ale cele wyznaczone jako droga do jej osiągnięcia są niezrozumiałe, rozmyte lub w ogóle nie zostały nazwane. Wizja staje się wtedy mirażem majaczącym na horyzoncie, zaś w działaniu tu i teraz braknie „drogowskazu” pozwalającego skupić się na tym, co istotne i wartościowe. W efekcie zespół zacznie robić rzeczy zbędne, wybierać złe kierunki rozwoju – a gdy to odkryje, najczęściej traci wiarę w sens podejmowania dalszych wysiłków.

Klarowna i atrakcyjna wizja jako źródło motywacji i wynikające z bieżących uwarunkowań cele działania mogą być motorem napędowym Scruma i każdej innej metody (również nie-zwinnej). Oczywiście zaangażowanie nie wynika wyłącznie z wizji, ku której zmierzamy (tu zachęcam do przeczytania książki Daniela H. Pinka „Drive”). Natomiast brak dobrej odpowiedzi na pytanie co, po co i dla kogo robimy, podcina skrzydła.

Składnik drugi: kontekst

Nie wystarczy wiedzieć, co chcemy osiągnąć – trzeba również dobrać praktyki, jakimi będziemy się posługiwać, do środowiska, w którym działamy. Sam Scrum to za mało. Jego twórcy ogłaszając kolejne wersje Scrum Guide dają w nasze ręce nie szczegółowe instrukcje, ale definicje elementów i reguły spinające je w sensowną całość. Pisząc o jakimś zdarzeniu określają kto w nim uczestniczy, jaki jest jego maksymalny czas trwania (timebox), a przede wszystkim jaki jest jego cel. Autorzy nie piszą jak konkretny zespół miałby postępować, by ten cel osiągnąć. Dlaczego nie piszą?

Bo sposób działania zależy od kontekstu właśnie. Czy dałoby się realnie napisać instrukcję jak przeprowadzić planowanie sprintu w każdym możliwym kontekście, w jakim Scrum jest wykorzystywany? Oczywiście nie. A czy w ogóle byłoby to możliwe dla któregokolwiek ze zdarzeń Scrum? Też nie, z jednym wyjątkiem Daily Scruma, który jest naprawdę prosty, i w którym kontekst jest ściśle zdefiniowany (synchronizacja pracy grupowej). Ale nawet i w tym przypadku tworzenie „instrukcji” mogłoby prowadzić do bezmyślnego powielania schematu (oderwania od kontekstu sprintu). Dlatego chwała twórcom metody, że nawet nie podejmują takich prób, a framework jest jedynie szkieletem (wspomnianą wcześniej „ramą postępowania”), który wypełniamy własną treścią w myśl określonych zasad.

Treścią, czyli kontekstem. Jest nim oczywiście to, jaki produkt budujemy, po co i dla kogo (a więc wspomniana już wcześniej wizja i związane z nią cele). Ale też i to, jaki jest zespół i relacje w nim. To, jaka jest kultura organizacji, jakiej technologii używamy (o ile budujemy coś technologicznego), jakimi narzędziami się posługujemy i jakie praktyki znamy. Z jakimi problemami mierzymy się na co dzień i jak sobie z nimi radzimy. Mógłbym tak długo wymieniać.

Dobre zrozumienie kontekstu pozwala skutecznie korzystać z możliwości (wiedzy, umiejętności i narzędzi), które mamy obecnie i świadomie wybierać kierunek rozwoju tak, by za jakiś czas móc osiągać więcej.

Składnik trzeci: wartości

W niedawnym artykule o wartościach Scrum pisałem o wpływie skupienia, odwagi, otwartości, zaangażowania i szacunku na działanie metody a także o tym, jak wartości te zależą wzajemnie od siebie.

Jeszcze raz podkreślę, że wartości te niezbędne są do tego, by Scrum w ogóle zadziałał, a co dopiero mówić o dobrym wykorzystaniu tej metody. Bo jeśli, na przykład, nawet wewnątrz zespołu brak odwagi do mówienia sobie prawdy, to jak miałby zadziałać empiryzm oparty na przejrzystości?

Składnik czwarty: kultura organizacji

Absolutnym minimum jakiego potrzebuje Scrum jest obecność wartości (choćby w niewielkim wymiarze) w zespole scrumowym (nie tylko developerskim!). Ponieważ jednak zespół nie pracuje w próżni, nieuchronnie wystawiony będzie na wpływ otoczenia, pozytywny lub negatywny. Może z niego korzystać, ale czasami zmuszony jest się z nim borykać.

Scrum może działać w miejscu, które kulturowo dalekie jest od wszystkich pięciu wartości opisanych wcześniej, pod jednym warunkiem: kultura organizacji nie może negatywnie wpływać na relacje między ludźmi wewnątrz zespołu. Inaczej mówiąc w intymnej przestrzeni zespołu scrumowego musi być dość zaufania i odwagi, by zapewnić przejrzystość wystarczającą do zadziałania empiryzmu. Korzyści z użycia Scruma w takim środowisku będą zapewne ograniczone, ale wciąż może on działać.

Gorzej, jeśli zła kultura organizacji przenika do zespołu. W miejscu, w którym podejrzewa się ludzi o lenistwo, złe intencje, niekompetencję, i gdzie ciągle patrzy im się na ręce tak, by wychwycić każdy drobny błąd, nie ma ani krzty zaufania. Odpowiedzią na ten brak jest jedna z dwóch (albo obie) rzeczy: wzrost obaw i spadek motywacji. Im trudniej mówić „jak jest naprawdę” tym większa szansa, że ze Scruma wyparuje nam empiryzm.

Po przekroczeniu pewnej granicy mówienie prawdy zaczyna wymagać heroizmu – dążenie do przejrzystości w takim miejscu to wycieczka na pole minowe. I tam Scrum już nie ma szans w ogóle funkcjonować.

Spadek motywacji wywołany ciągłym krytykowaniem i wytykaniem błędów jest równie destrukcyjny, bo wymiata z ludzi chęć do podejmowania wysiłków, eksperymentowania z nowymi rozwiązaniami, dbania o to co robią. A gdy już po kolei obumrą wartości Scrum, za nimi w niebyt podąży empiryzm, bez którego metoda ma nikłe szanse przynieść jakiekolwiek korzyści.

Składnik piąty: przestrzeń do samoorganizacji

Scrum opiera się o specyficzny sposób zarządzania pracą ludzi: samoorganizację. Często bywa ona stawiana na równi z anarchią, brakiem zasad – a jest wręcz odwrotnie. Żeby zespół sam zaczął decydować o tym kto, jak i kiedy wykona konkretne działania, musi mieć trzy rzeczy:

  1. jasny cel (bo organizuje się po coś),
  2. motywację do działania (presję, rozumianą niekoniecznie jako coś negatywnego),
  3. oraz – uwaga! – zasady i ograniczenia, których musi się trzymać.

Ta rzekoma „anarchia i chaos bez zasad” jest w istocie uporządkowaną odpowiedzią zespołu na potrzebę osiągnięcia celu w granicach wytyczonych przez obowiązujące reguły. Cel i motywacja uruchamiają i napędzają proces samoorganizacji, a zasady nim sterują.

Opisany powyżej koncept Trójkąta Samoorganizacji sformułował Andy Brandt – więcej na ten temat można przeczytać na tej stronie – niestety, tylko w języku angielskim.

Dlaczego działa to lepiej niż klasyczne podejście z kierownikiem podejmującym większość decyzji? Jest tak, ponieważ członkowie zespołu najlepiej wiedzą jakie kompetencje mają i jak wykorzystać je skutecznie w określonej sytuacji. Jeśli w zespole są obecne wartości Scrum na wystarczającym poziomie i organizacja nie tłamsi ich swoją kulturą dzień po dniu, któż mógłby lepiej zdecydować o sposobie wykonania działań niż ci, co je będą wykonywać?

Ograniczenia (reguły) wytyczają przestrzeń, w której decyzje podejmuje zespół, przyjmując na siebie wynikającą z tego odpowiedzialność. Ta przestrzeń powinna rosnąć wraz z dojrzałością zespołu tak, by zawsze istniał obszar, w którym da się zrobić coś nowego bez konieczności wnioskowania do kierownictwa o pozwolenie. Ważne jest zatem dopasowanie „przestrzeni” do konkretnego zespołu, z uwzględnieniem jego specyfiki.

Czasem zdarzy się, że zespół wykorzysta całą daną mu przestrzeń samoorganizacji i „dojdzie do ściany”. Przestrzeń ta musi się wtedy szybko powiększyć (to wymaga managera będącego prawdziwym servant leaderem, zdolnym zauważyć potrzebę zespołu i zareagować na nią). W przeciwnym razie reguły stymulujące do tej pory samoorganizację (i rozwój) staną się kajdanami, które szybko zrujnują motywację zespołu i spowodują utratę zaangażowania. Dlaczego? I jak wygląda takie „dojście do ściany”?

Wyobraźmy sobie zespół, który zaczyna pracę ze złożonym produktem. Na początku doceni, że doświadczony architekt wspiera go w pracy i zatwierdza kluczowe decyzje technologiczne. Developerzy nie potraktują tego jako ograniczenie, ale jako pomoc. Jeśli zespół nauczy się od architekta jak rozwijać produkt, to posiądzie wiedzę i umiejętności by działać samodzielnie. Dalsza konieczność uzyskiwania aprobaty dla podejmowanych decyzji stanie się uciążliwa, a czekanie na opinię architekta już nie będzie pomagać developerom, tylko będzie ich spowalniać.

Ta „przestrzeń” wspomniana przeze mnie powinna być rozumiana bardzo szeroko – nie tylko jako zestaw reguł i ograniczeń determinujących o czym zespół decyduje, a o czym zdecydować nie może. To również wszystko co zespół dostał do wykorzystania w swej pracy, na przykład narzędzia, jakich używa oraz praktyki, jakimi się posługuje. Niedoświadczony, nowy zespół zazwyczaj z wdzięcznością przyjmie gotowe rozwiązania. Miarą rozwoju będzie coraz większa umiejętność poszukiwania własnych, lepszych rozwiązań i kształtowania samego procesu.

A gdy tego wszystkiego brak…?

Sporo zespołów widziałem, ale nigdy jeszcze nie trafiłem na organizację, w której brak byłoby wszystkiego, co pozwala Scrumowi działać. Sensowniej jest zresztą mówić nie o „braku wszystkiego” ale o odczuwalnym niedoborze składników napędzających empiryczny proces. Nawet tam, gdzie wspomniane niedobory są znaczące, Scrum będzie działał, jeśli ludzie, którzy go używają, będą dążyć do poprawy środowiska, w którym pracują.

Scrum nie stawia warunków wstępnych związanych z kulturą organizacji, wizją produktu, czy poziomem, w jakim wykształcone są wartości Scrum. Gdyby mógł działać tylko tam, gdzie już jest świetnie, wtedy być może w ogóle nie byłby potrzebny. Jest wręcz na odwrót: metoda ma dużą zdolność wyciągania na wierzch wszystkich problemów i niedociągnięć, które utrudniają skuteczne budowanie wartościowych produktów. Dzięki temu możliwe jest eliminowanie ograniczeń, jedno po drugim. Ale trzeba o to zadbać.

Znam zespoły i firmy, w których na skutek zaniedbań i braku zaangażowania nie udało się osiągnąć wiele. Są takie, które z upływem czasu nie osiągnęły zupełnie nic. Są i takie, gdzie przekonanie, że „już jest świetnie” spowodowało regresję i powrót (albo raczej osunięcie się) w marazm pogrążony we mgle braku przejrzystości…

W miejscach o „toksycznej” kulturze, gdzie mało jest przestrzeni do samoorganizacji, Scrum będzie działał marnie, dając umiarkowane (a może i żadne) efekty. Tam, gdzie brak wartości Scrum, będzie podobnie. Konieczne jest nieustanne dążenie do jak najszybszego pozyskania składników dobrze działającego Scruma, o których piszę w tym artykule. Między innymi dlatego tak istotna jest rola Scrum Mastera (często niedoceniana i źle rozumiana), który pracuje nie tylko z zespołem, ale z całą organizacją. Bo chodzi nie o to, by tkwić w miejscu powtarzając, że „kiedyś będzie lepiej”, ale by „lepiej” stawało się co każdy sprint.

Ludzie oraz ich potrzeby i umiejętności

Scrum ma służyć ludziom, pomagając w rozwiązywaniu złożonych problemów. Nie są oni zatem kolejnym „składnikiem” – lepiej byłoby powiedzieć, że są „fundamentem”, w oparciu o który działa Scrum. Jest on przy tym metodą zwinną, a pierwszy punkt Manifestu Agile jasno mówi, że „(…) zaczęliśmy bardziej cenić (…) ludzi i interakcje od procesów i narzędzi. (…)”.

Z tego wynika kilka istotnych wniosków.

Pierwszy: Scrum najprawdopodobniej da największe korzyści ludziom, którzy chcą go używać i dążą do zrobienia tego dobrze. Ci, którym metoda została w jakiejś formie narzucona, lub którzy nie są przekonani do jej zastosowania, mogą nie mieć dość zaangażowania (pasji?) by w każdym sprincie dokonywać usprawnień. A przez to będą, być może, borykać się ze Scrumem.

Wniosek drugi jest taki: nie można oczekiwać od niedojrzałego zespołu (uczącego się dopiero jak korzystać z metody), by od razu wszystko robił w Scrumie idealnie. Wywieranie presji na „robienie książkowego Scruma” wywoła niechęć, a idący z nią w parze spadek zaangażowania spowolni, zatrzyma albo wręcz cofnie zespół w rozwoju. Dlatego to, jak Scrum jest robiony w konkretnym zespole powinno być odzwierciedleniem jego możliwości.

I ostatnia obserwacja: obecność wszystkich pięciu „składników” dobrego Scruma, które wcześniej wymieniłem, zależy od ludzi. Jest albo ich wytworem, albo emanacją ich potrzeb, obaw, przekonań, możliwości. To ludzie są nośnikami wartości, to od ludzi zależy kultura organizacji, to z potrzeb ludzi wynikają wszystkie wizje i cele. Dlatego jeśli jakiegoś składnika brak, wnieść mogą go tylko ludzie. Wszelkie formalne i nieformalne instrukcje opisujące „sposób wykonywania pracy” (ang. „way of working”) nic nie zmienią, jeśli brak zaangażowania uczestników procesu.

Więcej niż Scrum

Na koniec chciałbym zwrócić uwagę, że Scrum nie jest celem, tylko narzędziem do osiągania celów. Gdy już będziemy w stanie świadomie go używać i uzyskiwać dzięki temu korzyści, odkryjemy być może, że potrzebujemy czegoś więcej. Że Scrum to za mało. Wtedy, nie porzucając tego, co działa, pora wykonać kolejny krok i zacząć rozwijać metodę na własne potrzeby. Jeśli osiągnęliśmy mistrzostwo w Scrumie, zrobienie tego kroku będzie zupełnie naturalne i całkiem proste.

Dodaj komentarz

%d bloggers like this: