Blog

Scrum jest frameworkiem (po polsku to ramy postępowania lub metoda ramowa), 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 niestabilną złożonością (połączeniem zmienności i nieprzewidywalności), którą 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 elementów i reguł, które je wiążą w całość. 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, a 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ż niezwinnej). Oczywiście zaangażowanie nie wynika wyłącznie z wizji, ku której zmierzamy (tu zachęcam do przeczytania książki Daniela H. Pinka zatytułowanej Drive). Natomiast brak dobrej odpowiedzi na pytanie, co, po co i dla kogo robimy, podcina skrzydła.

Składnik drugi: kontekst Zespołu

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 tego nie robią?

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 Developerów). Nawet jednak 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 (wspomnianymi wcześniej ramami 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). Jest nim 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, jak miałby w nim 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 Scrum. 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 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ęć 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: możliwość samozarządzania

Scrum opiera się o specyficzny sposób zarządzania pracą ludzi: samozarządzanie (nazywane też czasami samoorganizacją). Często bywa ono stawiane 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 zarządza swoją pracą potop, by coś osiągnąć),
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ą.

Opisane powyżej pojęcie 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ć? Któż mógłby podjąć lepsze decyzje niż ci, co te decyzje będą wcielać w życie?

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 (poziomu autonomii) do konkretnego Zespołu, z uwzględnieniem jego specyfiki.

Czasem zdarzy się, że Zespół wykorzysta wszystkie dane mu możliwości samozarządzania i dojdzie do ściany. Poziom autonomii musi się wtedy szybko powiększyć (to wymaga kierownika 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 samozarządzanie (i rozwój) staną się kajdanami, które szybko zrujnują motywację. 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. Product Owner też nie będzie protestował, bo wsparcie architekta przyspieszy rozwiązywanie wielu problemów. Jeśli Developerzy nauczą się, jak rozwijać produkt, to będą w stanie działać coraz bardziej samodzielnie. Dalsza konieczność uzyskiwania aprobaty architekta dla podejmowanych decyzji stanie się uciążliwa, a czekanie na jego opinię już nie będzie pomagać Zespołowi, tylko go spowolni.

Możliwość samozarządzania wspomniana przeze mnie powinna być rozumiana bardzo szeroko – nie tylko jako zestaw reguł i ograniczeń determinujących to, 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. Trzeba o to jednak 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 i pogrążenie się we mgle braku przejrzystości…

W miejscach o toksycznej kulturze, gdzie mało jest przestrzeni do samozarządzania, 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, na którym opiera się działanie Scruma. 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 używany w konkretnym Zespole, powinno być odzwierciedleniem jego bieżących 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.