Scrum nie jest panaceum. Nie jesteśmy fanatykami tej metodyki*, aczkolwiek bardzo ją lubimy. Dlatego też dzisiaj prezentujemy 5 powodów dla których Scrum nie zadziała w Twojej firmie.
1. Wprowadzasz Scrum tylko z nazwy
Najgorszym i najczęstszym błędem przy wprowadzaniu jakichkolwiek zmian, jest pozostawienie wszystkiego po staremu.
Nie wystarczy, że z Kierownika zrobimy Product Ownera, że listę wymagań nazwiemy Backlogiem, że zaczniemy pracować w Sprintach, a wszystkich podzielimy na Zespoły Scrumowe liczące 5 osób. To są tylko i wyłącznie kosmetyczne zmiany.
Co gorsza, jeżeli faktycznie pozmieniamy tylko etykiety, bez przekazania wiedzy na temat metodyki, odpuszczając szkolenia Scrum, to zyskamy gwarancję porażki.
Typowym objawem tego nadużycia jest kompletna nieznajomość Scrum Guide’a i niezgodność zakresu odpowiedzialności poszczególnych ról z ich wzorami opisanymi w podręczniku. Scrum Master często potraktowany jest po macoszemu, a zakres poszczególnych Sprintów jest nienegocjowalny i ustalony z góry na najbliższy rok.
Nie da się ukryć, że Scrum jest modny i jest sporo organizacji, które za modą podążają. Nie interesuje ich osiągnięcie korzyści z wprowadzenia metodyki zwinnej, ale etykietka, jaką dzięki temu zyskają. Będą „nowocześni” i „zwinni”. Szkoda, że tylko z nazwy.
Jeżeli po wielkiej, agile’owej rewolucji nic się nie zmienia, a stare procesy zostały jedynie przypudrowane, to możemy mieć absolutną pewność, że wszystko pozostanie po staremu.Tak naprawdę przecież, do żadnych zmian nie doszło.
Zarówno transformacja agile, jak i skalowanie Scrum to poważne procesy, wymagające wsparcia i ogromnej pracy na każdym poziomie. Bez tego nawet i szczęście nie pomoże…
2. Ograniczasz Scrum tylko do Zespołów Scrumowych
Scrum nie jest tylko przepisem na działanie Zespołu Scrumowego. Sugeruje on, w jaki sposób powinien funkcjonować cały proces wytwórczy. W szczególności, jeżeli uświadomimy sobie, że produktem co Sprint jest wdrażalny inkrement. Chcielibyśmy przecież wdrażać go często.
Niestety, wprowadzenie Scruma tylko i wyłącznie w zespołach odpowiedzialnych za tworzenie oprogramowania rodzi wiele problemów. Z jednej strony co dwa tygodnie powstaje wdrażalny przyrost oprogramowania, a z drugiej leży on i czeka na „okienko wdrożeniowe”.
Cały zysk ze scrumowego działania jest niweczony przez skostniałą i archaiczną strukturę w firmie. Może się okazać, że co prawda działamy szybciej w obszarze dewelopmentu, ale czas do wdrożenia (ang. time to market) pozostaje niezmieniony.
Mówiliśmy już o tym w filmiku pod tytułem „Wdrożenie raz w roku„. Zastanawialiśmy się, czy w ogóle może być mowa o zwinności, gdy wdrażamy się w długich, wielomiesięcznych cyklach. Tracimy wtedy przecież większość zalet zwinnego podejścia: nie mamy weryfikacji naszych eksperymentów, nie wiemy jak użytkownicy reagują na nasz produkt, nie mamy możliwości maksymalizacji zakresu.
Nie ma mowy o Minimum Viable Product, jeżeli nie trafia on w ręce użytkowników końcowych. Bez nich nie dostaniemy informacji zwrotnych, które mogłyby zasilić nasz cykl Deminga.
3. ScrumBut
O ScrumBut mówiliśmy już w osobnym tekście. Dla przypomnienia: tą nazwą określamy wszystkie odstępstwa od podręcznika Scrum, które stosujemy z powodu specyfiki naszej działalności. Oczywiście, każdy lubi myśleć, że jest wyjątkowy, a rzeczona „specyfika” to tak naprawdę obawa przed zmianami.
Takie podejście często łączy się z naszym pierwszym zarzutem, czyli Scrumem tylko z nazwy. Ponieważ wymyśliliśmy sobie, że nasz przypadek jest szczególny, to zaczynamy modyfikować metodykę w taki sposób, żeby tak naprawdę nic się nie zmieniło.
Ot, wprowadzimy scrumowe role, zaczniemy działać w Sprintach i uczęszczać na standupy, ale po za tym nic się nie zmieni. Brzmi znajomo?
Nawet jeśli z pełną determinacją wprowadzimy podręcznikowy Scrum, to bardzo często wyciągnie on na światło dziennie problemy z organizacją naszych procesów. Tutaj zamiast refleksji, pojawi się chęć do ukrycia tych dysfunkcji właśnie przez modyfikacje Scruma.
Na Sprint Review okazuje się, że nie mamy żadnych nowych funkcjonalności? Przestańmy robić Sprint Review. Zespoły nie chcą robić codziennych spotkań? Róbmy je dwa razy w tygodniu.
Takie myślenie prowadzi do całkowitego wypaczenia metodyki. Nie może też więc być mowy o jakichkolwiek korzyściach.
4. Całkowity brak agile mindsetu w organizacji
Brak agile mindsetu w organizacji brzmi podobnie do punktu drugiego – ograniczenia Scruma tylko do zespołów. Jest to jednak znacznie głębszy i trudniejszy do zauważenia problem. Czasami dzieje się tak, że metodyki zwinne wprowadzane są w skostniałych firmach, gdzie „kontrola jest najwyższą formą zaufania”.
Nietrudno sobie wyobrazić jak taka sytuacja wygląda. Z jednej strony mamy „ładny” Scrum, działający jak w zegarku, ale z drugiej strony całkowity brak transparentności i ukrywanie faktycznego stanu projektu przed kierownictwem.
Nie może być mowy o jakiejkolwiek zwinności, jeżeli zarządzanie odbywa się wyłącznie za pomocą tabel, arkuszy kalkulacyjnych, liczb, kontroli i śrubowania takich wskaźników jak np. velocity. Jeżeli potrzebujesz wypełnić trzy formularze i odwiedzić dwóch kierowników, żeby postawić na biurku drugi monitor, to jak w ogóle możemy mówić o agile mindsecie?!
Są firmy, w których dzieje się jeszcze gorzej. Permanentne nadgodziny, brak poszanowania dla pracowników, ciężka struktura z mnóstwem poziomów, ingerencja w sposób realizacji prac („nazwij tę zmienną inaczej”, „przesuń to piksel w lewo”), zarządzanie przez gaszenie pożarów czy myślenie, że „każdego specjalistę można zastąpić skończoną liczbą studentów”.
Nie ma co się zastanawiać jak Scrum ma zadziałać w takiej organizacji. Trzeba się zastanowić jak taka organizacja w ogóle może funkcjonować.
5. Scrum w ogóle nie pasuje do Twojego projektu
Są takie przedsięwzięcia, do których Scrum nie pasuje. Nie ma ich znowu tak wiele, szczególnie jeżeli chodzi o działkę IT, ale nawet poza tą dziedziną znajdą się lepsze możliwości.
Po pierwsze, Scrum kiepsko sprawdzi się w przypadku inżynierii lądowej i dużych, fizycznych produktów. O ile nie widzę żadnego problemu ze scrumowym projektowaniem i produkowaniem t-shirtów, tak te podejście raczej nie sprawdzi się przy budowie tamy czy wiaduktu. Kolejność prac jest z góry zaplanowana i ściśle ustalona. Nie możemy zacząć konstruować budynku od dachu.
W takich sytuacjach znajdziemy jedno miejsce na podejście iteracyjne. To etap koncepcyjny – projektowania, gdy jeszcze nie czekają na nas ciężarówki z betonem, a harmonogram prac nie jest ściśle ustalony.
Drugi obszar, gdzie chociażby Kanban bije na głowę Scrum to ciągła, powtarzalna praca w dobrze rozpoznanej dziedzinie. Od razu nasze myśli skręcają w stronę fabryk i linii montażowych, ale do tej kategorii trafiają też ukończone projekty informatyczne, będące na etapie wsparcia i utrzymania.
Tutaj też musimy sobie uświadomić, że jeżeli nasze priorytety potrafią zmieniać się codziennie, jeżeli świadczymy usługi dla wielu klientów, z których każdy może mieć w dowolnej chwili krytyczny problem wymagający wszystkich naszych środków, to Scrum będzie nam tylko przeszkadzał.
Jeżeli z definicji zajmujemy się gaszeniem pożarów, to nawet tygodniowy horyzont czasowy może być zbyt odległy. I tu totalnie pomijamy to, czy taki sposób działania może w ogóle być skuteczny. Po prostu Scrum w żaden sposób go nie wesprze.
Mam nadzieję, że ten artykuł sprowokował do zastanowienia się nad Twoim następnym projektem scrumowym. Jeśli tak jest, to polecamy także nasze warsztaty Zarządzanie ryzykiem Scrum.
__
* Tę kontrowersyjną tezę wyjaśnialiśmy w artykule pod tytułem Metodologia, Metodyka, Metoda. Scrum jak najbardziej jest metodyką.
