5 pytań dotyczących wdrożenia Scruma

Organizacje nie stają się zwinne z dnia na dzień za sprawą magicznej różdżki. To znaczący proces zmiany, w którym każda osoba musi przemyśleć i dostosować swoją rolę. A wszystko zaczyna się od tego, że kierownictwo musi odpowiedzieć na kilka dość trudnych pytań.

Ze względu na wyzwania, którym muszą sprostać nowoczesne organizacje, Agile jest niezwykle kuszące. Kto nie chciałby częstszych wydań? Kto nie chciałby lepiej dostosowywać się do ciągle zmieniającego się otoczenia biznesowego? Zbyt wielu menedżerów rozważa jednak Scrum i rozpoczyna transformację agile bez zrozumienia wpływu, jaki Scrum może mieć na ich organizację, karierę i cele.

Scrum nie powinien być lekkomyślnie wdrażany w organizacji, a menedżerowie powinni zadać sobie kilka trudnych pytań. Scrum nie jest sprawą samych tylko zespołów programistycznych. Nie można go ograniczyć do jednego jedynego zespołu. Wdrożenie Scruma oznacza systematyczną zmianę w organizacji i jest regularnie opisywane jako trudne i zakłócające. Ale co to tak naprawdę oznacza? Jakie mogą być skutki Scruma?

Oto pięć pytań, na które należy odpowiedzieć, aby przygotować się na skuteczne i produktywne wdrożenie Scruma.

1) Jak reaguję na zmiany wpływające na moją rolę?

To pytanie musi zadać sobie każda osoba w organizacji, nie tylko zespoły, które mają pracować ze Scrumem. Scrum ma bezpośredni wpływ na zespoły; ale na tym się nie kończy. A co z przełożonymi? I jak zareagujesz, gdy Twoja rola lidera zostanie przez to naruszona?

Przykład: Scrum i średni szczebel zarządzania

Siedziałem z moim przyjacielem Johnem (imię zmienione) przy śniadaniu. John był menedżerem ds. rozwoju w dużej firmie świadczącej usługi finansowe, gdzie w ostatnich latach wdrożono Scrum.

Martwił się o to, jak jego rola w firmie jest teraz postrzegana. Zapytałem go, dlaczego się niepokoi, a on odpowiedział: „Na początku wszystko szło dobrze. Zespoły szybko robiły postępy, a środowisko pracy oparte na zespołach jest lepiej dostosowane do ludzi niż model usług wspólnych. Teraz mamy jednak zespoły, które w większości samodzielnie rozwiązują swoje problemy i same monitorują swoje wyniki."

Chciał wiedzieć, jaka jest jego rola w tym nowym, samozorganizowanym środowisku.

Funkcja menedżerów średniego szczebla w firmach wzorowanych na modelu „Scientific Management" (tayloryzm) koncentruje się głównie na wydajności i efektywności pracowników. Taylorizmowi przypisuje się dużą część wzrostu produktywności w XX wieku. Jest jednak mniej przydatny do tworzenia nowoczesnych, opartych na wiedzy produktów.

Jak więc zmienia się rola średniego zarządzania przy wdrożeniu Scruma?

Po krótkim omówieniu John zdecydował, że może wnieść wkład, pełniąc rolę mentora i komunikatora dla swoich zespołów, pokazując im, czego potrzebuje firma, i pokazując firmie, że jego zespoły mogą zaspokoić te potrzeby.

2) Jak postąpisz z najlepszymi pracownikami, jeśli nie chcą wyruszyć w tę podróż?

Nie każdy chce pracować ze Scrumem. Wielu ludzi lubi Scrum, bo pozwala im tworzyć produkt, na który mają bezpośredni wpływ, i to może być bardzo satysfakcjonujące. Ale nie dla każdego tak będzie.

Przykład: Zirytowana gwiazda

Jack był gwiazdą swojego zespołu i dawał to wszystkim odczuć. Gdy do zespołu zbliżał się termin, Jack często pracował 80 godzin tygodniowo, żeby zespół osiągnął swój cel. Często przebywał w biurze do 22:00 i wysyłał zarządowi e-maile nawet w weekendy. Kierownictwo go uwielbiało!

Jakość jego pracy była jednak wątpliwa. Produkował dużo kodu, który nie działał i wymagał znacznych poprawek. Po kolejnej nieprzespanej nocy w biurze pozostali członkowie zespołu przez dni zajmowali się usuwaniem błędów z jego kodu i integrowaniem go.

Próbowali wyjaśnić Jackowi, że jego zachowanie negatywnie wpływa na cały zespół – ale nie chciał słuchać i mówił: „Załatwcie to z kierownictwem".

Sytuacja zmieniła się, gdy w tym zespole wdrożono Scrum. Postępy i przejrzystość w zespole były omawiane każdego dnia podczas Daily Scrumu – dzienny postęp był więc permanentnie mierzony przez zespół. Ponieważ sam zespół mógł decydować, ile pracy skończy w iteracji, mógł przez cały projekt pracować w bardziej zrównoważonym tempie.

Podczas Retrospektywy zespół zakwestionował tworzenie kodu nie w pełni przetestowanego, który zabierał całemu zespołowi czas.

Jack nie przyjął dobrze wdrożenia Scruma. Dobra przejrzystość w Daily Scrumie wyraźnie pokazała, że Jack nie dostarczał kodu regularnie, lecz odkładał pracę na ostatni dzień Sprintu. Gdy zespół proponował rozwiązania problemu, Jack skarżył się na mikrozarządzanie.

Nie radził sobie z pracą w stałym i zrównoważonym tempie i zamiast skupiać się na jak największej wartości dla klienta, narzekał, że jego praca jest „nudna" lub „bez wyzwań".

Gdy zespół podczas Retrospektywy zobowiązał się do poprawy jakości kodu poprzez regularne testowanie, Jack groził odejściem z zespołu, a nawet z firmy. Pięć Sprintów po wdrożeniu Scruma Jack dobrowolnie odszedł z firmy. Wyniki zespołu stale się poprawiały i trzy lata później nadal produkowali wysokiej jakości produkt.

Przy wdrożeniu Agile firmy muszą przemyśleć, co zrobić, jeśli ich najlepsi pracownicy nie chcą pracować w Scrum Teamie. Czy pozwolisz im odejść? Czy powinni zostać w firmie i ewentualnie zakłócać działanie innych Scrum Teamów? Jeśli jesteś gotów pozwolić im odejść, jak uzasadnisz tę decyzję?

3) Jakich mechanizmów użyjesz, żeby doprowadzić do zmiany zachowań?

Scrum wymaga zmian zachowań; należą do nich samoorganizacja, większa współpraca i przejrzystość. Zmiana zachowań jest niezwykle trudna, szczególnie dla wieloletnich pracowników, którzy zostali przeszkoleni do zachowywania się w określony sposób. Jak teraz, gdy zmiana jest konieczna, upewnić się, że naprawdę się to wydarzy?

Ciągłe doskonalenie odgrywa tu dużą rolę.

Jako lider w zarządzaniu można wspierać pracowników szkoleniami, coachingiem i konferencjami i pomagać im w rozumieniu i stosowaniu nowoczesnych metod wytwarzania oprogramowania. A przez okazywanie zaangażowania dla pracowników, morale i satysfakcja zatrudnionych oraz firmy może się poprawić.

Istotna część tej zmiany zachowań związana jest ze zaufaniem w zespole. Jeśli współpracuję z kimś i ta osoba rozumie moją pracę, czy stanowi to ryzyko dla mojej oceny wyników? Czy stanowi to ryzyko dla mojego stanowiska? Jak budować zaufanie, jeśli na jedno z tych pytań można odpowiedzieć „Tak"?

Powszechnym podejściem jest zmiana zakresów odpowiedzialności i wskaźników, na podstawie których ocenia się pracowników. Aby promować zachowania kooperacyjne, pracy zespołowej przyznaje się większą wagę niż wynikowi poszczególnych osób. Można to osiągnąć poprzez feedback zespołowy lub 360°.

Przypisywanie mniejszej wagi wynikowi poszczególnych osób podważa indywidualną odpowiedzialność. Nikt nie chce być odpowiedzialny za określony obszar, jeśli jest oceniany na podstawie wyników całego zespołu. Dlatego oczywiście członkowie Scrum Teamów powinni otrzymywać odpowiedzialność za różne obszary. Oznacza to, że w każdym Sprincie powinni dostarczać część potencjalnie gotowego do wydania produktu.

Może się to wydawać nieistotne, ale ma duży wpływ na sposób działania firmy. Jak wpływa na Twoją strukturę organizacyjną to, że zespoły są odpowiedzialne za pracę w wielu różnych obszarach tematycznych?

4) Co myśleć będą działy wsparcia o zmianach wywołanych przez Scrum?

Scrum jest w większości przypadków wdrażany w organizacji przez zespoły programistyczne. O zespołach wsparcia i architektury rzadko myśli się z wyprzedzeniem. Dzieje się tak, ponieważ wiele organizacji przyjmuje, że „Scrum to coś, co robią deweloperzy".

Faktem jest jednak, że Scrum zdecydowanie wpływa też na inne zespoły. Jak na przykład zareagują zespoły wsparcia, gdy pojawią się punkty tarcia z Scrum Teamami? Jak te problemy będą wtedy rozwiązywane?

Przykład: Nieporozumienia między różnymi działami

Sarah była starszą architektką Java Messaging Service (JMS) i odpowiadała za firmową wizję Enterprise Service Bus (ESB). Coraz bardziej frustrowała się tym, że Scrum Teamy „ignorują wytyczne firmy, omijając ESB lub dodając nowe funkcje niedostosowane do strategii firmy".

Gdy zapytano ją, dlaczego jej zdaniem zespoły tak się zachowują, stwierdziła, że zespoły potrzebują więcej dyscypliny i lepszego szkolenia w zakresie strategii ESB. A potem dodała: „Ale może też nie spełniamy ich wymagań".

Po dalszej dyskusji Sarah zdecydowała, że najlepiej byłoby dołączyć do Scrum Teamu, żeby zrozumieć ich wyzwania i pomóc im lepiej rozumieć cele firmy.

5) Na ile firma jest gotowa wydać na tę transformację? I jaką wartość dostarczy ten wysiłek?

Niewiele firm ma z góry jasne wyobrażenie o tym, ile zarobi dzięki Agile. Jest mało informacji o tym, jakiego obrotu można mniej więcej oczekiwać. Istnieją jednak coraz więcej dowodów na to, że dzięki Scrumowi można osiągnąć częstsze wydania, lepszą jakość produktu i bezpośredniejszy kontakt z klientami.

Dobrym rozwiązaniem jest stały roczny budżet na permanentne szkolenia i coaching pracowników. Staje się to jednak problematyczne, gdy wdrożenie Scruma postępuje szybciej, niż pozwala budżet. Trudno też uzasadnić, gdy nie można jasno powiedzieć, ile obrotu jest przez to generowane.

Lepszym rozwiązaniem byłoby mierzenie kilku kluczowych wskaźników, takich jak:

• Przychód na pracownika
• Zadowolenie klientów
• Zadowolenie pracowników
  Gdy menedżerowie obserwują, czy te wskaźniki poprawiają się dzięki Scrumowi, mogą zobaczyć, jak skuteczne jest wdrożenie Scruma i czy coś trzeba zmienić.

Istnieje jednak kilka interesujących rzeczy w tym podejściu, które warto wyróżnić:

Po pierwsze, ta metoda jest niezależna od używanego frameworka i mogłaby mierzyć wyniki firmy niekorzystającej z Agile. Po drugie, być może okaże się, że Scrum nie jest najlepszym podejściem dla Twojej firmy lub że istnieją skuteczniejsze frameworki niż Scrum. To rzadkie, ale oczywiście możliwe.

Właśnie to podejście do mierzenia Ken Schwaber niedawno uwzględnił w swoim „Evidence-Based Management" (zarządzanie oparte na dowodach). Jest jeszcze za wcześnie, by powiedzieć, jaki wpływ to podejście będzie miało na wytwarzanie oprogramowania, ale jest to bardzo interesujące rozwiązanie i ma potencjał, by dostarczyć firmom konkretnych dowodów na ich poprawę.

Podsumowanie

Wdrożenie Scruma to nie jest coś, co powinno odbywać się lekkomyślnie. Istnieje ryzyko zarówno dla organizacji, jak i dla poszczególnych osób. Rozumiejąc pytania, które ludzie zadają, można lepiej zrozumieć ich motywację, obawy i wątpliwości. A dzięki tej wiedzy można kształtować znacznie bardziej kompleksowe podejście uwzględniające potrzeby firmy i pracowników.

„Zdolność logicznego myślenia jest jedną z rzeczy, które czynią nas ludźmi. W świecie wszechobecnych informacji i zaawansowanych narzędzi analitycznych sama logika jednak nie wystarczy. To, co wyróżni ludzi sukcesu, to ich zdolność do empatii, budowania relacji i troski o innych."
– Daniel H. Pink, bestselerowy autor książki Drive

(Uwaga: To jest gościnny wpis trenera i coacha Scrum Kane Mara, założyciela Scrumology.com i Scrum101.com.) Ten tekst pochodzi z bloga Openview i został przez nas przetłumaczony na język polski.