Degradacja Scruma w waterfall

Nie da się zaprzeczyć, że Scrum stał się już dość popularny. Bardzo często jest to pierwszy wybór w firmie, jeśli chcą pracować z frameworkiem agile. Prawie każdy zna na pamięć wydarzenia i role scrumowe. Ponadto istnieje ponad milion certyfikowanych profesjonalistów Scruma; 684K+ ze Scrum.org i 400K+ ze Scrum Alliance. Przy takiej obfitości profesjonalistów na całym świecie, Scrum jest wyborem oczywistym. Co jednak zaskakujące, wciąż trudno nam korzystać z prawdziwej zwinności.

Jak często obserwujesz poniższe zjawiska?

• Zespoły Scrumowe skupiają się wyłącznie na implementacji i niczym więcej.
• Menedżerzy produktu określają, co należy zrobić, a Product Ownerzy upewniają się, że rzecz jest zrobiona właściwie.
• Programiści nie są zaangażowani w żaden z tych etapów. Skupiają się wyłącznie na wykonaniu.
• Programiści tęsknią za dobrze zdefiniowanymi wymaganiami i wiernie oddanymi prototypami.
• Menedżerzy produktu określają, co należy zrobić, UX uprzyjemnia, UI projektuje, a Dev koduje. Jak w fabryce, każdy jest odpowiedzialny za małą część produktu, a nikt nie dba o całość.

Chociaż wiele firm dąży do dobrego wykonywania Scruma, niektóre rzeczy wykolejają się po drodze dość szybko. Zamiast polepszyć współpracę i czerpać korzyści ze Scruma, zespoły wracają do trybu pracy opartego na metodzie waterfall. Efektem jest Scrum tylko z nazwy.

Zostańcie ze mną jeszcze na chwilę. Omówię, dlaczego tak się dzieje i co mogłoby pomóc zespołom być bardziej scrumowymi, a mniej waterfallowymi.

Czym jest metoda waterfall?

Przez dziesięciolecia rozwój oprogramowania wykorzystywał metodę waterfall jako standardową metodologię. Podobnie jest w fabryce; każdy jest rozliczany z pojedynczych części. Dopiero po zakończeniu jednej części można ruszać z kolejną.

Głównym problemem metody waterfall jest zakładanie przewidywalności. W przeciwieństwie do linii montażowych, rozwój oprogramowania jest nieprzewidywalny, a inwestowanie zbyt wiele czasu z góry na plan nieuchronnie wygeneruje straty. Poza tym czas wprowadzania na rynek jest zbyt długi, a uczenie się od rzeczywistych końcowych użytkowników trwa zbyt długo .

Przy waterfall, im dłuższy projekt, tym większy staje się problem.

Poniższy obrazek przedstawia typowe fazy, gdy zespoły korzystają z waterfallu. Jak widać, dyscypliny zostały rozdzielone. Proces był sztywny, a każdy z etapów nie mógł się rozpocząć, dopóki nie zakończył się poprzedni.

W porównaniu z waterfallem, Scrum różni się na kilku poziomach; najistotniejsze z nich to:

• Samozarządzające się zespoły: zespół Scruma organizuje swoją pracę w kierunku celów Sprintu i produktu. Nie potrzebuje nikogo, kto by im mówił, co mają robić; wymyślą to samodzielnie, ponieważ mają wszystkie wymagane umiejętności do wykonania takiej pracy.
• Dostarczanie przyrostowe: Sprint po Sprincie; zespół dąży do zapewnienia wartości użytkownikom końcowym i biznesowi.
• Zespoły interdyscyplinarne: Zespoły Scrumowe powinny posiadać wszystkie wymagane umiejętności, aby przekształcać pomysły w sensowne rozwiązania.

W teorii Scrum pomaga zespołom odkryć ukryte możliwości tworzenia wartości. Może się tak stać, kiedy organizacja opanuje zasady gry Scruma, co jednak często nie ma miejsca. Zespoły często używają czegoś w rodzaju „Scrum, ale”, a wtedy sprawy przybierają niekorzystny obrót i odbiegają od tego, co Scrum powinien w założeniu osiągnąć.

Co się dzieje z zespołami Scrumowymi?

Najczęstszą i opłakaną sytuacją jest używanie Scruma wyłącznie do wdrażania. Zespół Scrumowy jest jak robotnik w fabryce, który przesypuje węgiel, żeby utrzymać maszynę w ruchu. Nie ma uprawnień do podejmowania decyzji i musi podążać za tym, co zostało wcześniej określone. Czy nie jest to równoznaczne z konceptem waterfallu?

Z mojego doświadczenia wynika, że organizacje ekscytują się frameworkami agile, ale tak czy siak wracają do podejścia waterfallowego. Poniższy obrazek przedstawia to, co powszechnie obserwuję:

Dobrze jest mieć poczucie kontroli, a metody waterfallowe dają takie złudne poczucie.

Niestety, łatwo jest nadużywać doskonałych metod i pracować tak, jak to robiliśmy cztery czy pięć dekad temu. Wszystkie wymienione powyżej metody są świetne, gdy cały zespół współpracuje i staje się odpowiedzialny za efekt końcowy. Jednak stają się one bez sensu, gdy różne zespoły zaczną przekazywać zadania innym zespołom.

To, co doprowadza mnie do szału, to założenie, że zespoły Scrumowe powinny skupić się na wdrażaniu i pozwolić innym zespołom wykonać resztę pracy. To doskonały sposób na stworzenie kolejnego waterfallu. W dzisiejszych czasach częstym scenariuszem byłoby:

1. Menedżerowie produktu, analitycy biznesowi i UX Designerzypracują od początku powstania produktu, aby stworzyć model biznesowy i propozycję wartości.
2. Po ustaleniu modelu biznesowego menedżerowie produktu i UX Designerzy przeprowadzają eksperymenty, aby zweryfikować założenia i wyciągnąć wnioski z doświadczeń użytkowników końcowych.
3. Wnioski wyciągnięte z eksperymentów prowadzą do zmiany modelu biznesowego i propozycji wartości.
4. Gdy menedżerowie produktu i UX Designerzy nauczą się wystarczająco dużo, do akcji wkracza UI Designer, który tworzy wiernie oddane prototypy.
5. Po zakończeniu wszystkich poprzednich etapów, do akcji wkraczają zespoły Scrum i rozpoczynają wdrażanie, gdy tylko menedżerowie produktu przekażą im wykonanie zadania.

Im więcej wymian w zespole, tym większe zamieszanie.

Ograniczenie Scruma do samej realizacji jest ogromnym błędem i w ten sposób Scrum staje się kolejną metodą waterfallową.

Jak zespoły mogłyby być bardziej Scrumowe, a mniej waterfallowe?

Scrum to przede wszystkim empiryzm i współpraca. Nietrudno to rozumieć. Problem polega na tym, że Scrum będzie działał dobrze tylko wtedy, gdy zespoły będą w stanie ogarnąć niepewność i będą miały odpowiednie uprawnienia. Do tego czasu będzie to tylko kolejne „Scrum, ale”

Tradycyjne zarządzanie uważa, że kontrolowanie i zarządzanie zespołami jest sposobem na uniknięcie niepożądanych rezultatów. Strach przed niepewnością zmusza ludzi do tworzenia procesów i ograniczania odpowiedzialności. Uważam, że im więcej procesu dodajesz, tym bardziej ograniczasz kreatywność.

Oto moje wnioski z niepowodzeń, z którymi już się zmierzyłem:

1. Nie ograniczaj zespołów Scrumowych jedynie do realizacji zadania. Takie zespoły nie będą miały szans na sukces, jeśli będą podążać jedynie za planem zamiast rozwiązywać problemy, które mają znaczenie. Samodzielność to tutaj klucz do sukcesu. Daj zespołowi głos, angażując go w cały proces.
2. Wykorzystaj Scrum do tworzenia wiedzy wykraczającej poza funkcje. Wielofunkcyjność oznacza, że zespół jest odpowiedzialny za całość działań. Takie obowiązki nie powinny być dzielone między różne grupy. Powinni wykorzystywać swój czas na odkrywanie możliwości i tworzenie wartości.
3. Nie miej obsesji na punkcie wyników. Kolejne nowe funkcje nie znaczą nic, jeśli lecisz na oślep. Zanim zaczniesz zajmować się pisaniem kodu, potrzebujesz dowodów, że jest to właściwa rzecz do zrobienia. Co ważniejsze, ten sam zespół powinien ustalić, co należy zrobić i jak to zrobić.
4. Prostota ponad złożonością. Zamiast zwiększać złożoność pracy, szukaj okazji do jej uproszczenia. Przykładowo, zamiast przekazywać zadania, przekaż odpowiedzialność zespołowi Scrumowemu i daj możliwość osiągania wyników.
5. Traktuj porażki jako konieczny krok w kierunku sukcesu. Porażka boli; wszyscy o tym wiemy. Jednak kiedy zespoły robią wszystko, aby uniknąć porażki, kończą również na unikaniu innowacji. Uważam, że porażka powinna być postrzegana jako nieunikniony krok do stworzenia czegoś wybitnego. Zamiast obwiniać zespoły za niepowodzenia, zachęcaj je do wyjścia poza strefę komfortu i uczenia się na błędach.

„Porażka nie jest złem koniecznym. W rzeczywistości nie jest to wcale zło. Jest to konieczna konsekwencja robienia czegoś nowego” - Ed Catmull, współzałożyciel Pixara

Podsumowanie

Nowe frameworki powstają, kiedy ludzie są zdenerwowani lub sfrustrowani znanymi frameworkami Agile. Pewnie słyszałeś o Shape Up, Scrumban, Lean Development, Crystal. Ta lista wciąż rośnie.

Nie chodzi o to, żeby zmieniać framework, kiedy robi się gorąco, ale żeby zrobić krok wstecz i zrozumieć, dlaczego ten framework nie działa. Z mojego doświadczenia wynika, że w większości przypadków problemem są nasze modele mentalne, a nie frameworki, których używamy. Łatwo ulegamy utartym zachowaniom i przekształcamy metody agile w waterfall.

Metody waterfallowe powinny spoczywać w pokoju; i nie powinny wracać zza grobu.

Zrozumiałem, że zespoły będą miały większe szanse na wyróżnienie się, jeśli:

• Będą dążyć do prostoty, a nie do złożoności
• Będą skupiać się na maksymalizacji możliwości zamiast na minimalizacji ryzyka
• Będą dążyć do rozwiązywania problemów zamiast ich unikania
• Zaakceptują niepewność, zamiast próbować tworzyć plany, dzięki którym powstanie iluzoryczna przewidywalność.
• Będą mieć wsparcie kierownicze, które umożliwi im przejęcie odpowiedzialności, zamiast stosowania poleceń i kontroli

„Jeśli chodzi o kreatywną inspirację, tytuły stanowisk i hierarchia są bez znaczenia” - Ed Catmull, współzałożyciel Pixara