Dlaczego wdrożenie Scruma jest trudne?

Im dłużej pracuję i obserwuję transformacje agile’owe tym bardziej dojrzewa we mnie pewne przekonanie. Mianowicie: przez nieposkromione ego i brak pokory wdrożenie Scruma w organizacjach przekształca się w usilne próby wciśnięcia jego karykatury w istniejącą strukturę.

Przykładowe wdrożenie Scruma – historia zmyślona, oparta na faktach

Przyjrzyjmy się jak wygląda przykładowe wdrożenie Scruma w firmie IT. Pewna firma znana jako IT Best Company od nastu lat produkuje oprogramowanie, ma już kilka produktów i klientów. CEO zauważa w internetach tytuł książki Scrum: The Art of Doing Twice the Work in Half the Time i zarządza, że wdrażamy Scruma od razu. Jak zarządza, tak się dzieje. Firma zatrudnia Scrum Masterów, którzy realizują plan:

1. reorganizują zespoły na międzyfunkcjonalne [1],

2. ewangelizują managerów,

3. eskalują potrzebę bezpośredniej współpracy z klientem,

4. promują podejmowanie decyzji o rozwoju produktu w oparciu o dane,

5. zgłaszają konieczność obecności użytkowników na Sprint Review, oraz

6. usiłują zmienić strukturę organizacyjną.

Zwykle w ostatnim punkcie zostają sprowadzeni do parteru: zespoły mają dostarczać dwa razy więcej, ale struktura zostaje taka sama.

Hmm. To chyba trochę tak jakby wprowadzać demokrację do kraju z silną monarchią i obsadzić króla w roli prezydenta, jego brata w roli premiera, a pozostałe stanowiska oddać rodzinie na kadencję o długości „aż po grób”. W ostatnich latach mieliśmy przykłady takich „wdrożeń” demokracji choćby podczas Arabskiej Wiosny i – jak wiemy z doniesień medialnych – nie były one zakończone sukcesem. (Dla chętnych: ciekawą analizę tej sytuacji oferuje Nassim Nicholas Taleb w Skin in the Game oraz Yuval Noah Harari w Homo Deus).

Jak Scruma nie wdrażać

Scrum nie będzie działać w żadnej firmie odcinającej Zespół Scrumowy od klientów, interesariuszy, rzeczywistości, wizji, planów i ambicji CEO i jego najbliższych współpracowników. Scrum nie będzie działać w żadnej firmie, która utrzymuje niezmienioną strukturę organizacyjną (albo której zmiana polega na dodaniu kilku kolejnych poziomów zależności). Scrum nie będzie działać w żadnej firmie, która nad doświadczenie i wiedzę zespołów stawia ego managerów.

I tu bardzo istotna uwaga: działający Scrum NIE jest gwarancją sukcesu firmy ani produktu, który wytwarza. Wdrożenie Scruma nie zawsze ma sens. Zależy ono od wielu czynników takich jak wizja organizacji czy realia rynku. Może zamiast wdrażać Scrum wystarczy zaczerpnąć inspirację z Agile Manifesto i stosować Agile Principles? …

W przypadku firmy IT Best Company cały czas zakładamy, że wdrożenie Scruma ma sens i nie jest to tylko fanaberia CEO. Ale czy nasi Scrum Masterzy zapytali „po co chce pan Scruma?” i uzyskali szczerą odpowiedź? Zastanówmy się czy ta firma naprawdę potrzebuje Scruma. Budowana od kilkunastu lat wypracowała kulturę pracy i zwyczaje (niepisane normy zachowań), które każdy z pracowników podskórnie czuje. Regularnie dostarcza specjalistyczne rozwiązania dla klientów, których stopniowo przybywa. Czy wdrażanie Scruma będzie w jej przypadku zbytkiem (jap. muda w myśl „szczupłego zarządzania”) czy inwestycją? To zależy od wizji na przyszłość, potrzeb rynku, potrzeb firmy oraz jej gotowości do zmian.

Jeśli wciskamy zespołom Scruma na siłę, gdzieś między managera, tech leada, testera i backendowca, a nie robimy nic w zakresie organizacji (zmiany struktury i kultury) to jesteśmy na prostej drodze do frustracji. Bo Scruma tak na pewno nie wdrożymy.

Zacznijmy od podstaw

Role w Zespole Scrumowym są trzy: deweloper, Product Owner i Scrum Master. Nie ma leadów, testerów, backendowców, managerów, directorów, CEO, BA, DBA, TL i innych WTF. Hierarchii też nie ma. A Scrum Master (nie manager, jeśli ktoś odruchowo tak to odczytał lub zrozumiał) ma być liderem służebnym (ang. servant leader). Liderem. Służebnym. Nie szefem, nie Wujkiem Dobra Rada, nie Inkwizycją Świętego Scruma, tylko liderem służebnym.

Nie będę się tu rozpisywać o tym czym się różni lider od managera, bo materiałów w sieci i na półkach sklepowych (również tych wirtualnych) jest aż za dużo. Przykładowy artykuł z Forbes na ten temat dostępny jest tutaj. Dłuższy tekst z Harvard Business Review pod tym linkiem, a „książkowe” porównanie znajdziesz na BusinessBalls. I jeszcze nagranie inspirującego wystąpienia Simona Sineka na YouTube.

Jeśli już w zespole wprowadzimy wspomnianą równowagę i ukształtujemy postawy w myśl Scrum Guide’a (odwaga w braniu na siebie odpowiedzialności, eksperymentowanie, nauka na błędach, otwartość na feedback), to przychodzi czas na to by zmienić otoczenie Zespołu Scrumowego. Nie dla zasady lecz po to by mógł on sprawniej działać (na przykład dostarczać w Sprintach i mieć bezpośredni kontakt z klientem).

Wdrożenie Scruma vs ego

Scrum Guide nie porusza wprost kwestii zmian w organizacji. Jedyne role jakie definiuje to te najbliżej zespołu produktowego (deweloperskiego). W Scrum Guide cel jest jeden: regularne, przewidywalne dostarczanie (wartości dodanej do) produktu o niezmiennie wysokiej jakości. A reszta musi się do tego dostosować. Rolą Scrum Mastera jest ruszyć cztery litery i sprawić, że jeśli owa reszta nie ma ochoty się dostosowywać, to w krótkim czasie będzie ją miała. Zadanie to jest nietrywialne. Pomijając już wszystkie niewiadome prawno-organizacyjne (i pytania „to za co ja dostanę premię roczną?”), zostaje kwestia najtrudniejsza: ego.

Początki pracy Scrum Mastera z Zespołem bywają trudne. Nie każdy potrafi przyznać się do błędu albo braków w jakimś zakresie. A podczas Retrospektywy Sprintu [2] wszystko widać jak na dłoni. Początkowo to w tym obszarze Scrum Master ma najwięcej pracy: promowanie szacunku, otwartości, odwagi trwa. Budowanie Zespołu Scrumowego też. Czasem to kwestia tygodni, czasem miesięcy.

Skoro początki w małym Zespole są tak trudne, to co będzie z całym działem czy organizacją? Co się stanie jak taki manager czy director usłyszy „dziękuję za twoje krytyczne uwagi, ale taka jest decyzja Product Ownera i ma on prawo się mylić”?

Wyższe stanowisko = większe ego?

I tu znów ścieramy się z ego – władzą kryjącą się za tytułem managera czy dyrektora. W wyniku zmian struktury organizacyjnej (jej uproszczenia) może się okazać, że część z tych ról nie będzie potrzebna. Zmieni się zakres odpowiedzialności, a niektóre obowiązki będą realizowane przez inne role (na przykład to Product Owner będzie decydować o dodaniu funkcjonalności do produktu a nie jeden z dyrektorów). Dla niektórych będzie to jak zrzeknięcie się monopolu na „mam rację” i „zrobicie co wam każę!”.

Opisana przemiana to potężne wyzwanie: mamy tu do czynienia z poczuciem straty, niepewnością, nawykami oraz doświadczeniami, które… przez wiele lat wspierały rozwój firmy. Wszystko to generuje ogromne koszty. Strach przez nieznanym uruchomi lawinę działań sabotażujących wdrożenie Scruma. Do tego dojdą plotki, niezliczone (mityczne) osobomiesiące pracy, wolniejsza wydajność Zespołów, ewentualne odejścia z pracy by uciec przed wyimaginowanym toporem. Koszty emocjonalne, moralne, a nawet finansowe będą ogromne.

Decydując się na uczestnictwo w takim wdrożeniu, Scrum Masterzy powinni w szczególności pamiętać o szacunku (jednej z wartości Scruma). Co więcej, wszystkie osoby zaangażowane we wdrożenie potrzebować będą ogromnej dawki pokory. Będzie ona potrzebna do zaakceptowania zmian w obszarach, które ich wymagają, do przeanalizowania danych i poznania odmiennych punktów widzenia.

Pokora

Pokora nie jest wymieniana ani jako filar ani jako wartość Scruma, ale wyciągnęłabym ją gdzieś na piedestał. Jej obecność przewija się przez cały Scrum Guide. Zbieranie feedbacku na temat produktu i reagowanie na te informacje. Empiryzm, czyli uczenie się na podstawie zdobywanej wiedzy – często na błędach. Brak hierarchii, narzuconej roli managera czy lidera. Oddanie zespołowi Scrumowemu całkowitej odpowiedzialności za produkt. To wszystko wymaga przyhamowania ego (naszego, Zespołu, otoczenia), zaciśnięcia zębów i pokory.

Pokora jest niezbędna do tego by dostrzegać możliwości poprawy oraz by usunąć ego w cień. W przypadku Zespołu Scrumowego będzie to ego osób dzierżących niegdyś tytuł tech leada, którzy z tego tytułu uczynili mandat na nieomylność i egzekwowanie posłuszeństwa. Każdy z członków Zespołu Scrumowego może być liderem w innym temacie, dziedzinie czy przedsięwzięciu i nie potrzebuje do tego osobnego tytułu – musi na to zasłużyć w oczach swoich kolegów i koleżanek. W przypadku managerów będzie to samodzielność Zespołów, a w przypadku directorów (managerów średniego szczebla) będą to decyzje dotyczące rozwoju produktu.

Dobre rady do zastosowania od zaraz

Jaki wniosek wynika z powyższego? Jak chcesz wdrożyć Scruma to trzeba promować i budować taką strukturę, w której liderzy będą się wyłaniać naturalnie, bez względu na nazwę swojego stanowiska. Tworzyć kulturę organizacji, która wspiera rozwój pracowników i nie przeszkadza im w braniu odpowiedzialności. Promować zdobywanie szacunku poprzez czyny a nie nazwę stanowiska. Promować zachowania dając przykład a nie nakaz.

Oczywiście nie musimy od razu tworzyć turkusowej organizacji – nie jest to złoty środek na sukces. To co możemy zrobić to konsekwentnie odbarwiać pomarańczową strukturę i sprawdzać jak nasze działania wpływają na organizację [3]. Od czego zacząć? Od siebie. Zacznij od pracy nad sobą i Twoim najbliższym środowiskiem. Jasno określ sobie cele i konsekwentnie je realizuj. Nie ulegaj łatwym wymówkom jak np. „nie mam czasu” czy „to nie mój problem” albo „nie mam tego w umowie”. Miej w sobie cierpliwość i pokorę.