„Przepraszam, ale Agile nie poprawia Twoich produktów"
Opublikowaliśmy już wpis na blogu Jeffa Sutherlanda, w którym reaguje na post Adama Pisoniego, twierdzącego, że Agile w rzeczywistości nie poprawia Twoich produktów. Oto teraz właśnie ten post Adama Pisoniego, współzałożyciela i byłego dyrektora technicznego Yammera oraz założyciela Responsive.org.
Jeśli nie czytasz regularnie prac Steve'a Denninga, polecam to robić. Jest jednym z najlepszych autorów piszących o przyszłości pracy. W artykule napisanym dla Forbesa stwierdza, że zwinne tworzenie produktów stało się powszechne, ale stawia też pytanie, czy nie stało się ono równie ulotną modą jak wiele innych teorii zarządzania. Jego wniosek jest taki, że Agile naprawdę nie jest modą, ponieważ
„Agile i Scrum bezpośrednio odpowiadają na aktualne pytania biznesowe, którym inicjatywy XX wieku unikały. W Agile i Scrum klienci dostają głos poprzez Product Ownera, a kompetencje są stawiane ponad autorytetem."
Chociaż zasadniczo zgadzam się z wieloma rzeczami w jego artykule, muszę nie zgodzić się z jego wnioskiem. Agile naprawdę zrobiło dobry krok w dobrym kierunku, ale mnie to nie wystarczy. Zanim pojawiło się Agile, zdarzało się zbyt często, że zespoły potrzebowały ogromnych ilości czasu i zasobów, aby zbudować coś, by w momencie ukończenia odkryć, że klient tego wcale nie chciał.
Agile miało przede wszystkim umożliwić budowanie udanych produktów w świecie, który zmienia się zbyt szybko, aby móc przewidzieć, czego ludzie chcą i jak najlepiej to dla nich zbudować.
Chociaż Agile nauczyło całe pokolenie programistów, jak ważne są eksperymenty i opinie klientów, Agile nie zdołało zmienić starego scentralizowanego systemu zarządzania opartego na poleceniach i kontroli, co stanowi dużą część problemu. Nawet z Agile programiści mający zbyt mały wpływ i zbyt mały kontekst potrzebują zbyt dużo czasu, aby tworzyć produkty, których klienci tak naprawdę nie chcą. Skutkuje to niezadowolonymi klientami, niemotywowanymi programistami i sfrustrowanymi menedżerami.
Dla informacji: od 1995 do 2014 roku byłem zawsze – z krótką przerwą po pęknięciu pierwszej bańki dot-com – albo pełnoetatowym programistą, albo liderem zespołów programistycznych. W 1997 roku kierowałem zespołem, który korzystał z metody waterfall (poprzednika Agile). W waterfall wykonywało się całą pracę projektową i planistyczną z góry, zakładając, że następnie będzie można podzielić pracę i ją ukończyć.
W 2004 roku pracowałem dla firmy, która mocno polegała na analizie i testach A/B, a nawet miała cotygodniowe wydania – tym wszystkim wyprzedzała swoje czasy. Pamiętam, kiedy ludzie po raz pierwszy mówili o Scrumie i pamiętam, że miałem jasny obraz problemu, który próbowałem rozwiązać: złe zarządzanie.
Uczciwości wymaga, że ponownie przeczytałem Manifest Agile i jego zasady i zgadzam się z każdym punktem. Są dziś równie dobre i trafne jak w 2001 roku, kiedy zostały napisane. W Agile należy budować coś iteracyjnie i nieustannie się przy tym uczyć, zamiast realizować duży plan. Ponadto klient powinien być przez cały czas bliskim powiernikiem, aby móc uczyć się od niego przez całą fazę rozwoju. Ponieważ celem powinno być stałe wchłanianie nowych informacji, należy też zakładać, że regularnie będziemy zmieniać kierunek.
Zanim pojawiło się Agile, kierownictwo tworzyło plan, który dokładnie dokumentował (przewidywał), co ma być zbudowane, jak to ma być zbudowane i ile to zajmie – przy czym to ostatnie było chyba najważniejszą częścią. Jak wiemy, plany te były trudne do przewidzenia i rzadko można było ich się trzymać. Efektem były nierealistyczne oczekiwania i terminy.
Na domiar złego, z powodu opóźnienia między ukończeniem planu a dostarczeniem produktu, bardzo prawdopodobne było, że kierownictwo bez żadnego zrozumienia kosztów zmieni zdanie na temat produktu. To oczywiście denerwowało wielu programistów, których zadaniem było wykonywanie „planu". Oznaczało to, że sytuacja z nierealistycznymi terminami tylko się pogarszała i zmuszała wiele zespołów do jeszcze większego planowania, aby późniejsze zmiany były jak najmniejsze. Paradoksalnie, przez brak przejrzystości w procesie programowania, zespoły deweloperskie zyskiwały większą autonomię w decydowaniu, w jakiej kolejności będą wykonywać prace, jak je budować, kto to zrobi itd. Naturalnie, konsekwencją tego rodzaju autonomii i braku przejrzystości jest często nieufność między kierownictwem a zespołem deweloperskim. Na końcu nikt nie był szczęśliwy.
I wtedy przyszedł SCRUM. Miał on zwiększyć przejrzystość procesu i poprawić efektywność w programowaniu. Co tydzień menedżerowie mogli decydować, które Stories (czyli funkcjonalności) chcą mieć następne, a programiści mogli oszacować, ile czasu i zasobów będą potrzebować. Zespół mógł wtedy określić łączny koszt wszystkich priorytetowych Stories i sprawdzić, ile z tej pracy może wziąć na siebie w następnym Sprincie.
Scrum drastycznie zwiększył przejrzystość i utrudnił menedżerom żądanie więcej, niż można było zrealizować. Uwzględniono też potrzebę iteracyjnej aktualizacji planów. Jednak dzięki zwiększonej przejrzystości w Scrumie programiści mają nawet mniejszą autonomię niż wcześniej. Uprawnienia programistów zostały zredukowane do określania, ile czasu zajmie coś zrobić, i wybierania następnej Story z listy, która jest w większości narzucana przez kierownictwo.
Programista pracujący nad Story może nie mieć żadnego pojęcia o związkach i o tym, dlaczego ta Story jest tak ważna lub jaka w ogóle jest za nią inicjatywa.
Choć Scrum zdołał okiełznać impulsywnych menedżerów, ostatecznie skończyło się na tym, że chciało się wywierać większą kontrolę nad programistami i ich pracą.
Kierownictwo nadal podejmuje decyzje, priorytetyzuje funkcjonalności i decyduje, kto w jakim zespole nad czym pracuje. Ze swoim skupieniem na szacowaniu nakładu pracy dla narzuconych zadań i małym kontekstem, Scrum cofa się do przełomu wieków, kiedy Frederick Taylor dawał pracownikom fabrycznym szczegółowe instrukcje.
W taylorizmie zakłada się, że menedżerowie są tymi, którzy posiadają wiedzę ekspercką i kontekst, aby narzucać, nad czym należy pracować. Dlatego ich zadaniem było dawanie pracownikom szczegółowych planów, aby ci musieli podejmować jak najmniej własnych decyzji.
Prawie na końcu Zasad Agile pojawia się dość niepasująca zasada, która jest ignorowana przez Scrum:
Najlepsze architektury, wymagania i projekty wyłaniają się z samoorganizujących się zespołów.
Teoretycznie możliwe jest używanie Scruma do śledzenia pracy w samoorganizujących się zespołach, jednak nie jest to zamierzone i dzieje się niezwykle rzadko. Większość książek o Scrumie podchodzi do tego z perspektywy zarządzania odgórnego, a nie przez samoorganizację.
Agile był ważnym krokiem w rozpoznaniu znaczenia testowania i iteracyjnej pracy opartej na opiniach klientów. Jednak w dużej mierze skupia się na zwiększonej efektywności i kontroli vs. empowermencie względnie samoorganizujących się zespołach. Jeden z autorów Manifestu Agile, Andy Hunt, widzi to podobnie.
Oczywiście można twierdzić, że Agile nie jest problemem, lecz metody takie jak Scrum. Ta subtelna różnica jednak ginie, ponieważ Scrum i Agile stały się prawie synonimami. Gdy Agile stało się bardziej znane, niestety zostało przywłaszczone przez tradycyjne modele zarządzania opartego na poleceniach i kontroli, z czego wyłoniły się metody takie jak Scrum.
Jaka jest alternatywa? Przyjrzyjcie się metodom programowania Spotify lub strukturom Yammera. Zamiast narzucać pracę poszczególnym osobom, dawajcie zespołom większą autonomię, aby mogły decydować, co chcą budować i jak. Te zespoły składają się również z osób z różnych dyscyplin, aby mieć pewność, że mogą zrobić wszystko, co konieczne, bez czekania na pozwolenie lub wsparcie innych.
Bez względu na to, czy aktualnie pracujesz w swojej organizacji ze Scrumem czy nie – jeśli masz poczucie, że posuwasz się zbyt wolno i nie budujesz tego, czego chcą Twoi klienci, istnieją różne możliwości eksperymentowania z nowymi modelami bez konieczności zmieniania wszystkiego naraz.
Wybierz projekt i stwórz mały, zaangażowany zespół z ludźmi, którzy mają wszystkie niezbędne umiejętności, nawet jeśli ci ludzie mają różnych menedżerów. Przedstaw im problem i daj im możliwość rozwiązania go w sposób, który uznają za właściwy.
Idealne byłoby, gdyby ten projekt był wystarczająco krótki, aby szybko sprawdzić, czy eksperyment działa. Jeśli niechętnie dajesz zespołowi tę samodzielność, albo wybrałeś niewłaściwych ludzi, albo problem może leżeć po Twojej stronie. Nazywanie tego „eksperymentem" może pomóc Ci sprzedać pomysł. Bardzo prawdopodobnie odkryjesz, że małe, zaangażowane i wielofunkcyjne zespoły ekspertów mogą osiągnąć niezwykle wiele w bardzo krótkim czasie.
Następnym wyzwaniem jest odkrycie, jak można to przenieść na większą skalę, jeśli zadziała. Zazwyczaj wymaga to nowych rozwiązań, co prowadzi do nowych problemów, dla których znów potrzeba nowych rozwiązań. Nie jest to łatwe, ale warto.
Zobaczysz, że działa, gdy Twój zespół będzie mógł przedstawiać klientom więcej nowych pomysłów szybciej niż wcześniej. To jest cel.
Autonomia wymaga zaufania, a zaufanie wymaga wspólnego kontekstu. Dlatego te nowsze modele opierają się na pełnej przejrzystości, gdy każdy musi być na bieżąco. W Yammerze mamy krótkotrwałe zespoły projektowe, dzięki czemu ludzie mają więcej możliwości do rzeczywistej pracy i uczenia się od jak największej liczby różnych ludzi – ale to tylko jedna z możliwości podejścia do tego.
Nie wystarczy, że kierownictwo jest jedynie wyrazicielem potrzeb klientów. Programiści i projektanci muszą sami rozumieć i internalizować potrzeby i cele ludzi, dla których coś budują.
Agile był ważnym krokiem od organizacji i metod epoki przemysłowej. Jeśli jednak chcesz stworzyć organizację na XXI wiek, będziesz musiał wyjść poza Agile i spojrzeć na nowsze modele, które rozdzielają władzę, są samoorganizujące się i naprawdę zapraszają Twoich klientów, partnerów i pracowników do bycia „właścicielami" procesu.
Niniejszy tekst pochodzi z bloga First Round i został przez nas przetłumaczony na język polski.
Dla Scrum Masterów oferujemy następujące szkolenia i bezpłatne możliwości doskonalenia:
